Securing a Standalone Windows Server 2003 Workstation

Installation and Configuration Guide

Document Formats:

Contents:

Title
Contents

Introduction
    Preamble
        Why workstation-ize a Server OS?
    Readership
    Disclaimer
    Background
        Document raison d'être
    Assumptions
    Requirements
    Methodology
        Resultant Baseline

Security Overview
    Analysis
        Network Attack Vector Elucidation
        Discussion

Planning and Installation
    Hardware Selection
    Partitioning
        Configuring a Functional Install Across Multiple Partitions
    Installing

Post-installation Configuration
    Firewalling
    Configuring UI
        Neowin's guide
    Hardware Recognition
    User Account Management
    Temporary Storage
    Closing Open Network Ports
        Open Ports Ownership Discovery
        Default Open Ports
        Closing TCP Port 135
        Closing TCP Port 445
        Closing TCP Port 1025
        Closing TCP Port 1026
        Closing UDP Port 500
        Closing UDP Port 4500
        Closing UDP Port 123
        The DNS Cache ports
    Disabling Windows Shares
        The doggoned IPC$ Share
    Other Settings
        BIOS
        Disable Autorun

Post-Configuration Analysis
    Wrapping up
    Known Existing Risks
        Microsoft Windows Certificate Chain vulnerability
        It'll be just our little secret—You, me, ...and the NSA

References
    Primary
    Consulted
    Software Utilised
    Software Cited
Acknowledgements
Endnotes
Appendices
Document Information
 

1. Introduction

Preamble

This guide will assist interested persons in setting-up, and configuring, an installation of Microsoft's Windows Server 2003^® operating system in a high-security desktop or workstation mode.

Why 'workstation-ize' a Server?

The first thing that's likely to be asked is "Why run a Server operating system as a workstation?!?". In fact there might be a few good reasons why someone might be interested.

Firstly, you might be a professional, who needs a secure, standalone workstation, but with one or more elements of functionality that only the Server version of Windows currently provides. Modules such Kerberos, or the Certificate Server. Perhaps you might be studying for your MSCE; need to practise and familiarise yourself with the Server version of Windows, but still needing to use that same computer for day-to-day use, and without the added pain of setting up a multi-boot system. Or you might be a new System Administrator of a small company network, and simply want a guide for setting up a secure minimally configured baseline from which you can then turn on any additional services "as needed".

By contrast you might be a student or a an unemployed person who can't afford a retail copy of Windows and who just needs a copy of Windows to "get by" for the next six months. Given that Microsoft kindly makes available a 180-day trial version of Windows Server 2003 for free, if you don't mind trashing your OS installation at the end of that period and moving on; then this represents a viable stop-gap option for you. Or you might be an individual who purchased a computer from a company in liquidation, acquiring a copy of a Server 2003 licence as part of that transaction, but not of Xp!

A secondary reason why some users might be interested in running Server 2003 on the desktop relates to the stability of the release. Whilst Windows Xp was specifically targeted as a desktop/workstation operating system, it was released to manufacturing 24 Aug 2001. Windows Server 2003, by contrast, was RtM on 28 March 2003. It therefore has the (in this case) benefits of coming from a later and more stable code-base. This matches the author's own experience of using both operating systems. And now it seems that Microsoft agrees too, having recently scrapped plans to build it's next version of Windows ("Vista", formerly known as "Longhorn") on the Windows Xp code-base, and instead, use the Windows Server 2003 code. [http://www.winsupersite.com/reviews/longhorn_5048.asp]

Lastly, there might be a performance benefit too. A base Windows Server 2003 instantiation, configured as a normal workstation, seems to use around only 80MB of RAM. On the other hand, XP (configured the same way, except with NOD32 virus scanning) takes up well over 120MB. Other users by contrast, however, have reported that some of their performance-hungry game applications, showed less benefit under Server 2003 than when run under Xp. (Exact configurations of these OS instances was unstated, and therefore of uncertain usefulness as a real benchmark. But at least be aware, nonetheless, that such reports have occurred.)

Whilst you might be in need some of the Server 2003 features; by the same token, some features that appear in Xp are absent in Windows Server 2003, so while there are still workarounds to most of these, be aware of this corresponding fact, too. 

If all you want to do is set-up Windows Server 2003 as a desktop (i.e. Xp -like) workstation operating system, then a number of guides already exist to assist you in accomplishing this task. One of the seemingly better ones around seems to be the Neowin Windows Server 2003 as a Workstation Guide. If this is all you want to do, then one of these other guides may be better suited to your needs.

If, however, you are in need of a guide that not only accomplishes this, but also with an eye for a maximally secure configuration too, then keep reading.

Readership

This guide is for experienced Windows users and Administrators who are comfortable digging around in the bowels of their system (e.g. the Windows Registry). It is expressly not a beginners tutorial.

It is specific for Windows Server 2003, however much of the security-related information can also be applied to Windows Xp with some forethought.

Disclaimer

Some of the procedures described could render your Windows installation unusable or unstable, if incorrectly performed or if this document contains an error. Whilst every care is taken for factual correctness, some errors may still remain, especially in early versions of this document. If in doubt about something, don't do it! You assume all liability for anything that might go wrong as a result of the information contained herein.  Always have a recent backup of any important data on your computer.

This guide is not authorised, approved by or connected to Microsoft in any way. All respective related trademarks belong to them and are appear herein for the purposes of fair educational-use comment only.

Background:

The Microsoft Windows family of operating systems has come in for a lot of criticism in the past with regards to almost anything that involves the word "security". From their default out-of-the-box configurations to susceptibility to hacking attacks, worms, and other exploits. Much of this criticism was deserved, but some of it was simply due it it being the dominant desktop OS in the world, and therefore the most common target for authors who write and craft targeted hacks and malware. [http://www.microsoft.com/windowsserversystem/facts/analyses/vulnerable.mspx] & [http://www.theregister.co.uk/2004/10/22/linux_v_windows_security/]

In seeming response to it's plummeting reputation (along with some high-profile worm attacks at the time), Microsoft's Chairman Bill Gates issued a company directive in 2002 that security was to be the company's "number one priority" [http://www.eweek.com/article2/0,1895,128158,00.asp]. This lead to what began to be marketed as their "Trustworthy Computing" initiative; and culminated with the eventual release of the Windows Server 2003 product, billed as their "most secure operating system to date" [http://www.microsoft.com/presspass/features/2003/apr03/04-14ws03security.mspx].

Windows Server 2003 certainly incorporated a good number of welcome security-related changes. Changing the default global user privilege assignments (i.e. the "everyone" group), reducing the amount of activated services when installed, and improved anonymous enumeration restrictions; just to name a few.

However, even this improved default installation configuration (quite properly) assumes that the machine it will be installed on will actually be used as a server; so naturally some server features are enabled by default. Since it is a desktop configuration that we are aiming for here in this guide, it should be expected that will still be some things that we can improve upon over the default installation.

Document raison d'être

Guides already exist to turn your Server into a Workstation. Many Security guides exist too. However being a non-trivial issue with no one-size-fits all, some well-meaning treatments end up, not surprisingly, being a little unwieldly. (the same fate might befall this one too!).

As well, some previously useful Security Guides seem to have disappointingly disappeared, (e.g. UKSecurity Online, Black Viper's Windows Services guide, — just to name but two). And few seem to present everything in one place.

Cyberdelic was documenting some of it's own procedures, and decided that under the circumstances, a generalised version might be of use to others. So although for an expressly limited problem domain, it is hoped that this guide will assist in plugging a portion of the gap that presently exists. It's provided free to the wider community to assist anyone who might find it useful.

At the time of it's original authoring, none of the information contained herein was available in one place. This has since changed somewhat, and this document has been updated to point to other known references (see the Bibliography section).

Should there be sufficient interest, this guide might continue to be further expanded at a later stage; perhaps to include more meaningful templates, or perhaps even generate additional guides as part of a series. (Hint: Can we say "feedback"?)

Assumptions

• you want to configure an installation of Windows Server 2003 to run as a desktop operating system
• you want to configure it with maximum security but without trading-off normal desktop functionality
• you're able to do a new, fresh install from scratch (though this step is optional)

Requirements

You will need:

• a copy of Microsoft's Windows Server 2003 (and a computer system capable of running it)
• a software firewall of your choice (e.g. Zone Alarm, Sygate, etc.)
• a backup of your current system (or important files, etc. that you want to keep)
• emergency boot media (a Windows 98 boot floppy will do at a pinch)
• this document and any related setup information that you might require (e.g. your Internet settings)
• Two utilities from Microsoft's

Optional:

• a third-party partitioning utility (such as Partition Magic or Partition Expert)
• a third-party process interrogation tool such as fPort or Process Explorer
• a router between you and the Internet

Methodology

The aim of this document is to achieve a secure, standalone desktop/workstation configuration based on the Windows Server 2003 operating system. This result will be achieved via both a pre-configuration / installation phase, as well as the more conventional post-configuration phase.

Some steps may be omitted at your discretion. What's presented here is merely the author's own recommendations for a sensibly secure setup.

Resultant Baseline:

Assuming all recommendations in this guide are followed: You will end up with a copy of Windows Server 2003 configured as workstation, spread across four partitions (optional), with normal Internet and application functionality, and with only one nominal open port (Time services) and (optionally) only one active 'share' ($IPC).

You may then turn on any additionally needed services from this baseline, as required.

So let's get underway...

(Skip all the niceties — Just give me the things to do Checklist summary! [under construction])

Security Overview

Analysis

Part of this guide is getting Windows Server operate in a Workstation mode. The other part is securing it in a way that does not unduly limit it's desktop functionality. In order to properly secure it, we need to understand how it might be compromised.

Fortunately because we are starting off with a clean install, we have the opportunity to start off from a basis of known assumptions. Further, we can consider the likely attack vectors in general terms, and then relate these back to our known default configuration.

From the broadest perspective, we have just two attack vectors. Our machine may be compromised either physically or via it's network connection.

Physically securing a desktop machine is not going to be easy. We normally can't stick it in a secure locked computer room the way conventional large server systems normally are. For now we'll have to assume for the moment that your local physical desktop environment is safe. We will, however, revisit physical security again, a couple of times later on.

This leaves us with our network attack vectors then, as our primary concern. We should now break these down into a little more detail to assist us in knowing what we might need to do in order to reduce our exposure to these types of attacks.

Network Attack Vector Elucidation

Essentially, these are going to break down into services running on our computer that are accessible to the outside world; that are misused, misauthored, malicious, misinstalled, or misconfigured. Let's deal with each of these in turn.

Legitimate Services that are Misused

An example of this might be an FTP server that has it's password broken, and is then used to store illegal 'warez' on. Or a Telnet server that is then used as a jumping point to break into other systems. Logs on these other system will naturally show such an attack as originating from your system.

Legitimate Services that are Misconfigured

Running a service that is misconfigured is surprisingly common, both in terms of applications and Operating Systems as well. Routers with default unchanged Admin passwords; applications set to allow weak user authentication by default, Mail servers that allow SPAM to be routed, and so on.

Software that is Misauthored

This category does not only apply to services that a computer runs, but it's very operating system too. Examples in this category include unintentional bugs, such as buffer-overrun flaws, weakly employed (breakable) encryption, and so on. Whilst some of this reflects on poor programming practices, it is also to be expected since proving that a program is 'correct' in any mathematical sense, is exceedingly difficult. Windows Server 2003 contains over 50 million lines of programming code; therefore some unexpected or unaccounted for behaviours,  just on probability alone, seem not unlikely.

Because of this, due caution therefore, should demand that we proceed from the outset on the premise (correctly or otherwise) that a component is insecure. Run (and therefore, expose) only the minimum that we need to.

However, there is a second type of misauthoring within this category too that is frequently missed. That is, the deliberate introduction of compromises such as hidden back-doors, or concealed time-bombs (or perhaps key-escrow might even qualify?). The software, however, is stated to (and does) perform largely as intended besides these hidden compromises. As we'll see at the very end of this document, this distinction might not be just academic.

Software that is Malware

Similar to the misauthored software category, except that in this case,  it's deliberately written to perform undesirable activities. Malware such as: Trojan horses,  Spyware, covert Adware, or rootkits; all obviously qualify. (The exploitation of bugs in an Internet browser to install software on a user's computer is, for the purposes of this document, considered malware, though a proportion of blame must rest in the mis-authoring category too). The distinction here is that the software was designed to be subversive from the outset, and any seemingly useful function that it might perform is often simply to just encourage a user to install it.

Software that is Misinstalled

Obviously if a piece of malware is installed on a system, it will attempt to execute its malicious payload. Depending on what that payload is, it might attempt to  open a back door to the outside world, propagate a virus, or perhaps activate hidden keystroke logging. This guide is about configuring the Operating System and obviously can't help you past the point that you decide to install your own particular applications onto it. But since no-one except for virus hunters and the like, actually desire to install deliberately compromised software; we're calling any arrival of such programs on your computer a result of "mis-installing". (Though technically speaking, someone else could deliberately install it there too.) However, the point to note is that it doesn't arrive on your PC by accident. Either you install it unwittingly (or someone else does) or it arrives by some other means over the network (in this case, the Internet) via some kind of exploit. Either way, you didn't mean to put it there.

Denial of Service

Lastly, we should at least still be aware that there exists a non specifically hardware or software compromise  attack vector too; that of the Denial-of-Service attack. This most usually takes the form of flooding a target computer with network requests to the point where it spends all of it's CPU time (and available bandwidth) trying to process them. It's an attack vector that gets used in the real world, but not one not really one that the scope of this guide can cover.

Just don't piss-off any hackers who happen to control an army of Internet connected zombie-drone computers and you should be fine.

Discussion

A cursory overview of the above list indicates a few clear "protection vectors".

1. Don't run unneeded services that open ports to the outside network. Run as few services as possible, in fact. Obviously we are going to have to run some software in order to do anything! But approaching it from this perspective should help us from taking unnecessary risks.
2. Take time to configure your system properly, and take a baseline snapshot (a backup) of it at this point should things go wrong later.
3. Only install trusted software.
4. Run anti-virus and anti-Trojan checking scans over your system regularly
5. Use, at very least, a software firewall preferably in conjunction with a router or hardware firewall
6. Physically secure your computer if possible

You may have heard most of the above before in different terms. But they're worth restating, since we're all guilty from time to time of not following these to the letter. Common sense isn't always common practice.

So, from here we can now plan our installation and what we might need to do to secure it after completing our install of it, in order to achieve our "baseline".

2. Planning and Installation

Hardware Selection

Obviously you're expected to have a physical computer system that's capable of running Windows Server 2003. The Hardware Compatibility List for Windows Server 2003 is actually a thing of the past, believe it or not. But it's substitute, the Windows Server Catalog, is still a place to start and cross-check if you're yet to acquire any any physical gear for this project.

However, more importantly for the purposes of having a secure workstation, you need to consider what level of physical security you require.

As Microsoft themselves point out in their immodestly (but probably accurately) titled Ten Immutable Laws of Security, "If a bad guy has access to your computer, it's not your computer anymore".  [http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx#EIAA]. This is normally taken care of in a real medium to large server environment, since the computer systems tend to live in their own restricted-access server room. However, this is usually not the case, almost by definition, for workstations or desktops.

Therefore if security is really important to you you might want to consider selecting or using hardware that incorporates some sort of case-access lock that requires a key. Other additional options are possible too. This matter will be discussed further at the end of this document.

Partitioning

Many operating systems install onto, and use, separate partitions for different functions. Windows, however likes to install everything onto one partition, and use folder-access security for functional demarcation. Thus it requires some cajoling in order to segregate its functional file-usage over more than one partition.

Partitioning components within an operating system installation—even Windows, which wasn't seemingly designed for it—offers some advantages, however. For example, data can generally be more easily backed up and restored when on its own partition and the OS can be wiped and reinstalled easily without affecting user data stores. There are others too. The downside is of course, that configuration space needs to be carefully considered since such an arrangement will invariably waste some space as a balance between immediate requirements vs. future growth, gets struck. Getting this wrong will be the source of a major headache as repartitioning can be time consuming.

The security benefits can be quite major in a true server system [F], less so with desktop workstation.  However some unintelligent malware still tries to target the C: drive specifically (rather than interrogating an environment variable), and as well, it still provides some protection in the event of some kinds of directory-traversal exploits.  So whilst the security benefits in a desktop situation are mild, the author finds it still worth seriously considering this option even for just the backing-up convenience. 

With the availability of cheaper and larger drives, the wasting of some drive space as a result seems less of a penalty to pay. 

So if we're going to do this, let's go all the way...

Configuring a Functional Install Across Multiple Partitions

The author's own installation is partitioned into four partitions:

• the Windows OS itself
• swap and temporary files
• Program files
• User files

The traditional user "Documents and Settings" folder can be left on the system drive, with a redirection of your "My Documents" folder on the  new separate partition. [F: on how to do this with Power Toys] Since each user (besides the "Administrator" account) gets a unique UserId number known as a SId (Security Identifier), that gets associated with their account, it actually seems like a good idea to actually keep the documents and settings folder with the OS. (Since each new OS installation will result in different unique UserID's that will in turn, be associated with the permissions on the Documents and Settings folder). However it's also possible to install the actual documents and Settings folder entirely onto a separate partition itself, should you desire. This has certain advantages too. The author decided to do it this way, and the rest of this guide will assume that this latter option, is the case.

It's technically possible to move the Program Files folder location post installation, but requires quite a bit of registry search and replacing, and is error prone. (There is also another alternate but untried method purportedly available). In any case, it's definitely much less hassle to sort this out upfront, pre-installation.

Determining Required Space

The system partition needs to be large enough to hold the OS files themselves, which is on average, around 1.5Gb (2Gb for the 64-bit version of Windows). However, Service packs will also create uninstall directories that reside on here, and as well, the Hibernation file (if used) is normally stored on this drive too. Subsequently installed application Program DLL's will also add an additional overhead. As well, if you plan on keeping the same drive for a while, it might be prudent to allow enough room for any additional space that might be required for the next version of Windows (i.e. Longhorn/Vista). So far, the author has gotten away with using a 3Gb system partition, though this appears to be incrementally nearing capacity (currently 250Mb left free. I'd allocate a minimum of 3.5Gb if starting over, and if you can budget it; maybe go for 4Gb).

The sizing of the Program Files directory will naturally be dependent on the specific programs (and amount) that you will need.

For the Swap files partition, allow for three times the amount of physical memory in your computer. If you also want to move the  Temporary Internet Files store here too, then allow for much more as appropriate. (Though going this far with the idea seems a little overkill to me).

Finally, for the Documents and Settings partition, just allocate the remaining drive space (unless you need something additional for other operating system partitions, or whatever else, of course)

Partition Creation

With the required space requirements now defined by you, these partitions need to be created. A copy of Fdisk from Windows 98 should be able to accomplish this, or alternatively the target drive could be temporarily installed into an existing NT-based system and done from within the Drive Manager program. Of course a third-party utility like Partition Magic or Partition Commander could be most usefully employed here at this point, too.

Configuring the pre-install

To get Windows to install correctly into our desired target partitions, we need to tell it "where", before starting the install. This is accomplished via an "unattended install" configuration file.

Using the "Unattend" Facility

In the \Support\Tools folder of the Windows 2003 product CD is a compressed folder named Deploy.cab. This file contains various tools that can be used for deploying Windows using unattended and Sysprep installs.

1. Extract the programs DEPLOY.CHM (help file) and SETUPMGR.EXE (main program)
2. Run SETUPMGR and answer the prompts.
3. This will create both an unattend.bat and unattend.txt file you can use for automated installs.

The batch file might need some minor modification but it is fairly basic. You can see (or use, with appropriate changes) a sample  unattend.txt by the author. Or head over here for more detail on using and Customising the Unattended Setup. There are also a couple of help files included with the "unattended install" support tools package which you've extracted, which would be advisable for you to read.

Notable Options

Because we're configuring this system as a standalone internet-connected workstation, the only networking protocol that should be installed is TCP/IP. We especially do not want NetBIOS installed. This can be seen in the "[params.MS_TCPIP.Adapter1]" section of the unattend.txt file where "WINS=No" and "NetBIOSOptions=2" (i.e. no NetBIOS)

Which Drive?

Via your unattend.txt file, you've told windows where the user and Program Files directories are going to go; but what about the actual Windows system directory? Easy. Place your unatend.bat and .txt file in the root directory of your target system partition, and run the .bat file from that location. Windows will assume that, that's the place to install itself.

Installing

Once you feel comfortable that you have the unattend file configured properly, you can proceed with installing your new fresh copy of Windows Server 2003, which should correctly organise itself across three of your four targeted partitions. (The swap file location will need to be manually assigned, post installation).

Note!: During or immediately your post-install, do not connect to the Internet straight away before taking further precautions! (outlined in the next section). The lifespan of an unprotected, unpatched Windows PC connected to the Internet has been estimated at about 4 minutes before being compromised by Hacker Bots!! So don't undo all your good setup work immediately by ignoring this warning.

Post Installation Configuration

Firstly, confirm that your files and folders have now been installed into the correct partitions and folders. You can do this by just using Windows Explorer or by executing the set command at the command prompt and examining the contents of the appropriate environment variables.

You may also wish to take a backup/system image at this point so that you don't have to reinstall Windows from scratch should something go wrong in the following sections. Use your favourite backup or imaging program for this task. (You will need to install it, of course too, at this point).

Firewalling

Despite this documents best intentions, you might be wanting to connect to the Internet straight away. In which case, install your preferred software firewall now. Zone Lab's ZoneAlarm seems to work well, Sygate's too. For the really paranoid, install both! :p (And before you ask; no I'm not, yes you can, and yes, it does actually work).

Desktop Usability

Whilst there might be arguably more important things to do first, actioning them from a server-performing look-and-feel user-interface might get tiresome rather quickly. So why not adjust all of the relevant UI and performance settings to workstation mode now?

The first and best guide to accomplishing this, is Neowin's Windows Server 2003 as a Workstation Guide. Ideally, you should be following those instructions instructions from your printed-out hard-copy, since it would be nicer to wait until you've finished this guide before connecting to the big, bad, Internet proper, right?

The Neowin Server->Workstation Guide : Quick Summary:

• Disable the "Manage Your Server" screen
• Create a new user account with Admin privileges
• Logout and login again using this new account
• Leave the Shutdown event tracker operating (this author's own recommendation contrary to Neowin's)
• Disable Internet Explorer Hardening if you intend to do normal internet activities with this PC
• Enable Video Hardware Acceleration
• Enable Themes and Audio Services
• Disable the following Services immediately (more to follow)
  - Remote Registry
  - Task Scheduler
• Enable Audio Hardware Acceleration
• Adjust Visual Effects "for Best Appearance"
• Configure Processor and Memory settings for "Programs"
• Install DirectX

Checkpoint

• If you've followed most of the above guide, you should now have an Xp-like desktop user-interface and functionality, with two user accounts with administrator privileges ("Administrator" and the one you should be using now), along with one guest account and one vendor support account that are installed by default by the system.

Hardware Recognition

This is probably the point in our post-install configuration where you should also check that all the hardware devices in your system have been recognised by Windows and have drivers installed for them. Navigate from your Start menu to the Control Panel -> System -> "Hardware" tab -> "Device Manager" to see if everything's ok here.

If you need to install drivers for your video card or any additional hardware like scanners, webcams, or USB powered toothbrushes, and the like, you should probably do that now. Your system should be "hardware stable" before we plough into configuring all the OS settings.

Account Management

New Administrator Account

Many security guides recommend renaming the administrator account because you can't delete it or disable it. Whilst at least this is the minimum desirable, it is ultimately only of limited use since the "Administrator" account can still be identified by it's SId which always will begin with S-1-5- and end with -500. A much better solution is to create another account for your system administration tasks (naturally giving it Administrator privileges), and then dumb-down the original "Administrator" account by removing all of its privileges. You can always do both and rename it too, I guess.

And whilst you should always use a strong password for your real Administrator account, give the new dumbed-down Administrator account an extra-long, random one too — just on the off-chance that it might keep some of the script-kiddies busy one day ;-)

As a side benefit, this will also provide protection from local programs which offer to change the Administrator password for you.  You should be aware that should you ever be in need of such a program, that you will only regain access to your system via an admin account that now has no privileges! Bottom-line: Don't forget your new Admin account's password!

Your Own User Account

Aside from your new, secondary Admin account, which you should only use when required (i.e. when installing new programs, or configuring your system, like you are now) you should create a new user account for yourself for day-to-day use. This should have only default "User" privileges associated with it. If you need to run a program requiring Administrator privileges, you should use the Windows secondary logon facility.

Other Accounts

Obviously if you have another user or two who needs an account on this machine as well, you can set up their accounts now too.

But more importantly, at this point you should make sure that both the "Guest" and 'Vendor support' accounts are disabled.

All Accounts

By default, all accounts are allowed remote access control. As a matter of course this should be disabled for every account:

1. Whilst still in the User Account MMC, right-click on each user in turn and select "Properties".
2. Select the "Remote control" tab and deselect the "Enable remote control" option.
3. Repeat for each account present on your system

Whilst there, you might as well goto the "Dial-in" remote access tab and ensure "Deny access" is selected in the "Remote Access Permission" section. (Again, for each account, whether active or not)

Temporary Storage

Moving the swap file to it's own partition

We mentioned that the Unattend process does not configure the swap-file to run on a separate drive or partition. Therefore, assuming that all your other folders are located in the correct places, we can assign the swap-file to the appropriate partition, now.

Navigate from your Start menu to the Control Panel -> System -> Advanced tab, "Performance" section. Click "Settings", Advanced tab -> "Virtual Memory" section. Click "Change". A list of available drives/partitions will be presented, select the target partition for the swap file location, and enter your desired sizing for it (or use the default). And click the "Set" button.

In the same dialog window, select the current swap file location partition (on the Windows system drive) and click delete. Click "Ok". These changes will be implemented when you reboot.

Changing swapfile default directory

By default, the Windows swapfile "pagefile.sys" is located in the root directory of each drive that you've elected to have one. If you wish to locate this file in a specific folder too (and not just a different drive), you need to make an appropriate change in the registry. If you really desire to do this, navigate to:

Note that this is a Multi-string variable, so you must use the RegEdit32 (and not just RegEdit) program in order to alter it. Obviously make sure the path you enter is valid! Changes will be applied when you reboot.

Clearing the Swapfile on Shutdown

For additional peace of mind, you might also want to ensure that the swap file is cleared of any data that it might contain, every time you shutdown. This can be done from the Group or Security Policy Editor or via a registry key. In case you need the registry method, the key is:

This will increase the shutting-down time of your system by about 20 seconds (depending on the speed of your system and the size of your swapfile). But hey, you'll make that back on a more peaceful sleep each night :p

Print Spool Directory

This is not critical in any way, and you'll obviously need enough space on your swap partition to cope with this, but if you want to move the default temporary files location for the print spooling system, you can enter the new drive/path location in the following registry location

Note too that each printer also has it's own individual SpoolDirectory entry, which you might also have to change as well. So, if you're still keen:

Verify that the target folders that either of the above paths points to (you did create a folder, right? ;p), has it's ACL permissions set to grant "Full Control" to Creator/Owner, Administrators and to the System account as a minimum. Add desired permissions for the Everyone or Authenticated users group (generally "Full control" too) as desired.

Either restart the Spooler service for the desired changes to take effect, or else they will take hold naturally on the next reboot.

Other Temporary File locations

Per User

By default, each user in addition to the system itself, also has an assigned temporary files folder. This is normally located in the %USERPROFILE%\Local Settings\Temp directory. Two System-User environment variables are set to point to that folder. They can be changed (i.e. reset) to any other folder by opening the Control Panel and navigating to -> System -> Advanced (tab) -> Environment Variables (button). Enter your new desired path for your temp folders. You will have to do this for each user.

Internet Explorer Temporary Files

By default, temporary internet files (the html and graphics files cache) are stored at in the folder %USERPROFILE%\Local Settings\Temporary Internet Files. You can redirect these files to any other folder location from within the IE "Options" menu, or using the following Registry changes:

Closing Open Network Ports

Out-of-the-box, Windows Server 2003 does much better than any of it's predecessors at reducing it's default online 'surface' profile. However, for our purposes this can still be much improved.

Executing a "netstat -ano" at the command line to show us what ports and services are listening, shows us that the following ports are open by services, by default:

Well, it's much better than the default Xp install. Nevertheless, it still looks like we have some work to do :-)

To be fair, some ports are "worse" than others, notably TCP ones in a "Listening" state. But given that as per our earlier analysis in section 1, that we want to reduce our unnecessary services exposure as much as possible, knocking down a few UDP ones too is not just security 'window dressing' since UDP exploits do exist.

Methods

Unfortunately disabling all of the open ports that we'd like to, isn't as easy as just going into the "Services" manager and disabling a handful of unneeded Services (though this still pays very handsome dividends). We have a few approaches we can take:

1. Disable as many ports as we can via the Services Manager, and put up with the few remaining afterwards, that are still left open.
2. Do whatever it takes to reach our objectives even if it means delving into the registry.
3. Use a third-party tool that claims to accomplish these goals.
4. Use the new Security Configuration Wizard tool called that comes with the Windows 2003 Service Pack 1 that also claims to accomplish these same goals.

This guide was tentatively prepared before any tools to accomplish this kind of task were known to be in existence. Therefore the steps outlined will largely take the form of option 2, above.

None of tools of options 2 and 3 have been extensively tested yet. If they subsequently are, this document will be updated to report on the findings. Nevertheless, it might still be worthwhile briefly outlining these latter two options quickly.

Third-party port-closure tools

At the time of writing, two are currently known by the author. There may be more by the time you read this.

• A very nice little utility called the Windows Worms Door Cleaner promises to close five of the major Windows ports: the DCOM RPC, RPC locator, NetBIOS, UPNP, and the messenger service. (Ports 135, 445, 137, 5000). We might even make use of this ourselves later.
• Another is the StopListening utility which claims to close all wide-open TCP and UDP server ports on Windows 2000/XP. (If it works on XP should still be useful with 2003 though the author has not yet tested, that this is indeed true, yet)

The Service Pack 1 Security Configuration Wizard

The Windows 2003 SP1 incorporates some security changes to the DCOM which is also one of the services that we'll be dealing with shortly. More notably, however, SP1 also adds a new administrative enhancement, the Security Configuration Wizard, which lets you let us quickly shut down services that are not being used as well as identify and block unused ports. Which is exactly what this section of this guide below, is going to be stepping through manually.

The author had already configured his system using these manual techniques in the rest of this guide, below (pre-SP1), and has not yet evaluated the extent to which the SCW might suppliant or replace these individual instructions. Initial examination of the SCW indicates it to be an worthwhile tool and it's almost certainly worth running initially to determine if it can accomplish what the instructions below, do. If not, you can roll-back to your earlier system-image backup perhaps, and then start the 'manual' methods as per below; or just follow the appropriate section instructions for any remaining exposed ports that SCW leaves outstanding.

In any case, installing SP1 requires the Distributed Transaction Coordinator Service to be running, which this guide shortly recommends disabling. So if we're going to install SP1—and we should, since it also contains roll-ups of past critical updates!—then now is probably the time to do it.

After completing the install of SP1 and rebooting, a re-run of our "netstat -ano" command finds that we still have the same ports open. If you really won't be needing any major server functionality, and are desirous of trying the SCW way of disabling ports, then now's the time to run the SCW. Else, it would be prudent to wait until you've also installed all of your applications that might need Internetworking access, and then run the SCW after that point.

The remainder of this section will assume that you now want to manually start locking down your exposed ports (instead of trying the SCW). Some of it will still be relevant to Windows Xp users still (who don't yet have an SCW), so let's continue.

Open Ports Ownership Discovery

The only positive way to tell which application or service is opening the ports shown in our above netstat screen, is to correlate the port with the applications process ID ("PID" on the RHS of the above screen dump). Surprisingly, this is not as straightforward as it might/should be.

In theory, we should be able to accomplish this by executing a "tasklist /svc" from the command line. This will show us a corresponding process that is associated with the PID.  Executing it on our freshly installed system shows the following:

(You can also use the free fPort tool or Process Explorer to correlate your running processes to open ports, directly.)

You'll notice that many services piggyback off the svchost service. This is because svchost.exe allows DLL's to run as a Service. If some of those services need a port, this will be sometimes dynamically assigned to them. It's this dynamic nature of some of the ports that are assigned that makes it difficult to sometimes pin-down which service is actually responsible for opening a particular port.

We're somewhat lucky here in that we're supposedly starting off from a known good default new installation. So the same ports are likely to be used in the same way fresh out-of-the-box for your system too. Further, Microsoft has just published a list of all the ports that their software uses, so we're still in business even if we didn't have a fresh default install to work with.

However just in case at some latter stage you need to actually actively discover your application's port-usage on a currently existing system, a quick overview on how will be presented now. Otherwise just skip off to the next sub-section.

Update!: Windows Service Pack 1 now includes a new netstat option, the "-b" switch which can directly display the Windows service or process that can open sockets. [footn: marchand] Our output with the new "netstat -anb" on our default Windows Server 2003 system with SP1 shows:

Oooh, this is a very useful addition :)

(as a bonus: with SP1 installed, it seems that the Task Scheduler no longer opens a TCP port for it's RPC services)

Interrogating the RPC PortMapper

So if we have some ports that are dynamically assigned, then there must still be some kind of register of which services have been assigned to which port. The RPC portmapper stores this information and we can examine it via the use of the rpcdump tool.

<the remainder of this section is under construction>

Default Open Ports Summary

Fortunately, however, because this is a fresh, known default installation, and that many standard services still do use known port numbers, we can be pretty sure of the following culprits (services) are responsible:

TCP ports:

• 135 : RPC Portmapper and the COM Service Control Manager
• 445 : CIFS protocol using the NetBT driver
• 1025 : Distributed Transaction Coordinator Service and/or the Task Scheduler
• 5000 : SSDP Discovery Service

UDP ports:

• 123 : Windows Time service
• 135 : Messenger Service (note: This is unrelated to the MSN Messenger Service)
• 445 : CIFS protocol using the NetBT driver
• 500 : Internet Key Exchange Protocol as used by the IPsec service
• 1026 : Caching DNS Service
• 1027 : Messenger Service (note: This is unrelated to the MSN Messenger Service)

Jean-Baptiste Marchand of Hervé Schauer Consultants in France, presented an excellent general guide to the Minimization of network services on Windows 2000 and Xp. We're going to adapt much of that here but specifically for Windows Server 2003 and present them in the correct order to be performed.  (Update: He's just released a similar overview especially for Windows Server 2003.)

Most of these ports have been disabled without ill effect on the authors own test system. But of course, your own mileage might vary. Therefore keep a couple of system-state backups handy just in case you find that you need to undo something at a later stage.

TCP port 135

Firstly, let's deal with port 135. (This is the port that the Blaster worm used to wreak its havoc). It's used by the Remote Procedure Call portmapper as well as the COM service control manager. This also means that other services might be responsible for opening it (i.e. piggy-backing their needs through the RPC and DCOM) as well, so we may have to revisit it more than once, but let's deal with that possibility one at a time.

First up is the DCOM (Distributed COM) service.

Many programs "support" Distributed Communication (DCOM) but hardly ever use it. It's therefore usually quite safe to disable it. However simply disabling it wont close this port, we also need to remove the protocol sequences from a list that DCOM can use. The simplest way to do this is as follows:

1. From the command line, type dcomcnfg. This will bring up the Component Services MMC.
2. Select the following: Component Services -> Computers -> My Computer
3. Right Click on "My Computer" and select the Properties menu item
4. Navigate to the Default COM security tab
5. Uncheck "Enable Distributed COM on this computer" option.
6. Now also go to the Default Protocols tab and remove all protocols especially "Connection-oriented TCP/IP".
7. Though not required as part of closing port 135; whilst we're still here in the DCOMfig MMC, it might be also prudent to check on the DCOM Remote Access permissions.
   - Click on the COM Security tab
   - Select the "Edit Limits" button in the "Access Permissions" section
   - Select "Deny" for "Remote Access" for "Anonymous Login"
8. click on "OK" to apply all these changes

A reboot will be required for our revised configuration to take effect.

Note too, that this may cause the scheduler service to fail to start. However, if you've followed Neowin's server to desktop guide above, then you should already have the scheduler service in a disabled state.

TCP port 445

This port is used by a couple of things, most notably, "File Sharing". However, if you've followed this guide so far, then file sharing shouldn't be currently enabled. This means that it's currently opened by the NetBT driver. It can therefore be closed by disabling the NetBT driver in the "Device Manager" of the Windows Control Panel. However, doing so will prevent the DHCP client service from working. Most cable Internet services (and others) rely on DHCP in order to allocate user IP addresses. Therefore if your Internet connection relies on DHCP, you should not try and close this port by disabling the NetBT driver.

Instead, the work-around is to disable the raw SMB transport which uses port 445 and leave the NetBT driver running. This can be accomplished by setting the following registry value:

After a reboot, both TCP and UDP ports 445 will no longer be opened by the NetBT driver.
 

TCP port 1025

Port 1025 can be another tricky one as it is another one of those Windows 'ephemeral' ports (a port in a range that gets opened by different Windows services when required). Anything that's here could also appear in port 1026 too (and vice-versa).

However, from a default installation, this is likely to be opened by the DCOM service. Our procedure for closing port 135 should have also closed this port as well.

Should the port still be open, then there is one other service that it's likely to be: the Windows update service. Now, we should definitely ensure that we keep our computer patched with the latest updates, but we just mightn't want to do it by keeping this port open 24 x 7. So after we disable this service, we should make a commitment to ourselves check the Windows Update site regularly (around once per week).

1. Open the Windows Control Panel, select "System"
2. click the "Automatic Updates" tab
3. select the "Turn off automatic updates" option

Port 1025 should now be closed.

Don't forget to visit the windows update site regularly, now!

(Note that some users have reported activity from the Windows update service even when supposedly disabled. So keep your eye out for this.)

TCP port 1026

This is another port in the Windows' dynamically assigned range. As per above, anything that appears in here might instead be using port 1025 in a given instance (and vice-versa). However, once again, because we're proceeding from a new default install installation, it's very likely that these same ports will be used in the same way by the same services.

And in this case the culprit is likely to be the Distributed Transaction Coordinator service. Stopping and disabling this service should close the dynamic port that it's opening (in this case TCP port 1026).

Port 1026 should now be closed.

UDP port 500

This is used by the IKE (Internet Key Exchange) protocol, and can be closed by stopping the IPsec Services, service.

Do this, and UDP Port 500 should now be closed.

This will also close port 4500 which is also opened by the IPsec services for NAT-T support.

Obviously you're going to want to leave this service running if you require IPsec services. Even if you don't there is at least one advantage in leaving it running; in that it may help prevent worms from infecting your computer on other open ports. If you enable it but set it's use to "preferred" instead of "required", it means that the first three syn's coming to your computer will be met with ISAKMP, which the originating computer is most likely not running. Therefore your computer will appear non-existent until the second series of connection attempts, where it will decide the sending computer cannot talk IPSec. However worms scanning for hosts are unlikely to interrogate it for a  second time And might be a good tactic for remote access if you don't have a firewall or NAT router, and will stop Netsky, BOT's etc, unless they are repeatedly sweeping from the same IP. However given that we are intending to close almost all other ports that we can in this guide, this apparent advantage might be considered moot to some. (i.e. we're closing off our potentially worm-able ports, so we don't need this advantage as far as I can see.) However, now that you know; you can decide for yourself.

UDP port 4500

This port is opened by the IPsec services for NAT-T support and will be closed by setting the IPsec service to disable and should be done already if you've followed the closing port 500 instructions above.

UDP port 123

This is used by the Windows Time Service and is required if you intend to keep your computer synchronised time-wise to a time server on your network (in this case, one over the Internet). If you don't need or want this kind of facility, you can disable the Windows Time Service and UDP ports 123 will be closed.

The author, however, finds that this is quite an innocuous and useful low-risk service, and is quite happy to keep it running. (Your mileage might vary of course). However you could also chose to set the service start-up state to "Manual". This way the port will be normally closed until you require it to start by instigating a manual time synchronisation.

The DNS cache

Our final ports to consider don't show up until we attempt to surf/connect/use the Internet; and are opened by the Windows DNS Caching service and Internet Explorer.

If we open a browser and surf to a couple of sites, we may get some entries like this added to our netstat output:

<example output to come>

Employing our new-found tasklist skills shows us that our browser along with the DNS Cache is responsible.

This is because the Windows DNS Client service is a caching DNS resolver and binds a UDP socket to communicate with DNS servers on port UDP port 53. The more DNS resolving that we do for new lookups will progressively bind additional UDP ports that will show up on our netstat. To date, this appears to be non-security threatening behaviour. but we need to be aware of it so that we don't completely 'flip out' when we do a netstat one day after a long evening's surfing.

One 'flip-out prevention' solution is to change the way that the DNS Cache works and force it to only bind to a single port. This is the case with Windows Xp. However, I'm sure that there must be some sensible reason why different sockets are being used each time, and I'm reluctant to suggest constraining this behaviour without better understanding the reasons behind it being different on Windows Server 2003. In short then, if this behaviour is bothersome, the only way to prevent it is by disabling the DNS Client service. This could have other repercussions if DHCP is required and would need to be tested on your own connection/system. However if you can disable it and your Internet connectivity still works fine, then you might wish to consider this option.

Section Discussion

Assuming that you've followed this so far to the letter, you should now have all your ports closed with the possible exception of the Windows Time Service.

Running a "netstat -ano" again shows...

...only our one Time-services port open. Whoo-hoo!

While we still have some more things to do yet, this milestone deserves at least a little celebration. I correspondingly present Mr. Dancing Banana for your edification.

Disabling the Windows Shares

By default, Windows automatically creates default administrative system shares of all the drives (and some resources e.g. Fax, Printer drivers) on your computer to assist in streamlining some administrative functions.

In the past, the existence of these shares was a definite security risk because the access control on restricting anonymous enumerations of these shares was weak. However, the art of 'good security' is "defence in depth" so if we have no need for the system default shares, then we should disable them even though access control security on them has improved somewhat. Be aware, however, that turning them off will 'break' industrial-esque applications like Exchange, MOM and SMS that rely on their existence; however if you're really building a workstation Windows 2003 system, you're highly unlikely to be requiring this kind of application calibre.

There's a registry setting that we can use to accomplish this, but first we might want to examine the default security permissions for our shares generally and confirm that they're set to the highest level before we proceed ("defence in depth", remember). Probably only one of these two keys will need to be changed.

First check that the following registry keys are set as follows:

So by default, Windows Server 2003 (and Windows Xp) allows anonymous enumerations of Shares, but not of users. The combination of the above settings disallows both.

The ‘RestrictNullSessAccess’ registry key value determines if anonymous access is allowed to named pipes and shares:

We should ensure this is set to one. (Note that some past Microsoft documentation listed this key as "RestrictNullSessionAccess". This is incorrect and the above key name is the correct one) [http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58643.asp]
 

Finally, we come to the registry location that will actually disable the automatic creation of the administrative shares

Set this key's value to "0" (zero) to disable automatic Shares creation.

For client computers (e.g. Windows Xp Professional) there is also a counterpart key called AutoShareWks. It may also be present in your registry, in which case, it too should be set to "0" (zero) . Some other security guides recommend creating this latter key and adding it even if it doesn't yet exist. (The author is currently looking into the pros and cons of this advice)

The doggoned IPC$ share

Note that even with these above key-values in place; one last administrative share the "inter-process communication" share ("IPC$") will still remain. This share is considered essential for communication between programs running on inter-connected servers, and will recreate itself each boot.

Assuming that the anonymous restrictions that we've set up work correctly (i.e. there are no bugs in the implementation of this section of the Windows security system or exploit work-arounds) then this final Share should be quite safe to leave in place. However, if you don't happen to relate to this same warm and fuzzy secure feeling, then it can only be disabled by one of two means:

1. executing a manual command from the command-line to remove the share each time you boot your computer ("net share /delete IPC$ /y"), or putting this command in a batch file that gets executed at boot-time.
2. Disable the actual "Server", service. (This will also stop the "Computer Browser" service)

This guide was deliberately prepared to maximise security whilst leaving these services running in case they might be needed. But the "Sever" and "Computer Browser" service can be quite safely disabled in our stand-alone environment, for added security. If you don't need to share any files or folders over a network then it's strongly recommended to disable the Server service. (If you have problems as a result, you can always re-enable it later)

If you have to leave it running, ensure that your Internet router or firewall blocks ports 139 and 445.

Other Settings

We mentioned before about the need to keep an eye on our physical security.

BIOS

You should make sure that you have your BIOS password protected. Further, I recommend that you don't just password protect it for settings changes, but for whenever the computer gets booted. Whilst this is relatively trivial to defeat when in local physical proximity to the machine, it means that if you were to leave your computer on overnight and connected to the net, and a hacker disables your firewall and initiates a reboot (required usually, post- such a disable) the computer will be stuck on awaiting a password from you when you return the next morning. As opposed to completing its reboot and granting unfettered net access whilst you were away. The author speaks from fortunate experience on this one.

Disable Autorun

Autorun is the feature that either plays a CD automatically when placed in the drive or pops-up an installation program (etc.) if a software CD is inserted. It's potentially 'dangerous' because anyone can create an autorun program that gets executed when that CD is inserted and automatically install a potentially harmful piece of software without even having to log on! (Another good reason not to run your own user account with administrative privileges).

Whilst there are two registry keys that can be altered to accomplish this, their key values are not so straightforward to translate. [http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/autorun/autoplay_reg.asp?frame=true]

So the easiest way to disable the autorun feature is to download the Tweak UI Power Toy from Microsoft and navigate to the My Computer -> Autoplay -> drives, option within it and deselect it for all drives.

The autorun feature should now be disabled.

Post-configuration analysis

Ok, all the above is what the author considers the minimum required to get a good nights sleep. But it's perhaps worth considering just how secure are we now?

Wrapping up

We've disabled our default system shares, tightened our physical desktop security somewhat, and we've closed pretty well all our possible ports. If you've gone so far as to disable the Time Service and DNS Client, then you will have zero ports open until you run an application that requires 'net access.

This is a pretty slim network profile to present to the outside world, and pretty well reduces all our network attack vectors to only misauthored or mal- software. No-one can predict where the next loophole exploit might be found, the best way to reduce these latter two risks is to keep uptodate with the latest patches and run trusted software. Regular scans with a good anti-malware suite of programs and moderate vigilance at our open ports will continue to keep our risk low.

Going Further

However this has been a basic security risk reduction procedure. There is further that we could go. We haven't covered installing a Group security Policy yet, nor using any features such as configuring a software restriction policy for our machine. Neither have we covered Auditing configuration which is generally accepted as a very important security prerequisite.

Encrypting Files

Further our system is still vulnerable to physical compromise. This is always going to be an issue to some extent given that we have a desktop system that can't exactly be squirreled away into a locked server room. If you have particularly sensitive files on your system (perhaps you're a self-employed contractor for the Defence department?) then you should consider using the Encrypted File System for those documents.

This still doesn't protect us, however, from the physical installation of compromised operating system files (i.e. via drive removal and overwriting target files using our drive temporarily installed in another system); as it's not possible to encrypt all of the Operating Systems own files, since it needs to first get into a state where is can load the security sub-system to decrypt them. The only solution therefore is a third-party disk encryption product that encrypts at boot time. (i.e. the whole drive, from the first moment that it gets accessed at start-up. This product shouldn't store the key anywhere on the hard-disk either, of course.)

Known Risks?

So besides the fact that new security risks will continue to crop up from time-to-time and be shortly thereafter (hopefully) patched; is there anything else we should be aware of in our quest for security related piece-of-mind?

Well, from the authors perspective, besides the general ones already covered, there exists two potential weaknesses that might still exist. They're remote, to be fair, but as default security around the web gets less weak, we can expect attacks to become more sophisticated over time. Hence, despite their remoteness, they're still worthy of at least mentioning in passing; and as far as I'm aware, still exist as potential exploits.

Microsoft Windows Certificate Chain vulnerability

This vulnerability, is based around the way the Windows file protection system operates. In a nutshell, WFP trusts any digital signature whose certificate chain is rooted at any one of the Trusted Root Certification Authorities (who have certificates that automatically come preinstalled with Windows). This means that any attacker in possession of a valid code signing certificate signed by any Root CA can apply a digital signature to malicious code and deploy it without detection to any Windows box that relies on WFP for malicious code/Trojan detection.

Although originally posted in 2002, the vulnerability is still indicated to apply to Windows Xp, and I suspect that Windows 2003 is therefore similarly vulnerable. The work-around to this problem is somewhat extreme (see the original above link) and we can only hope that a future version of WFP is redesigned to eliminate this shortcoming.

As a stop-gap method, it might be advisable to reduce the number of automatically trusted root certificates on our system. Microsoft provides a list of the minimum certificates that are required to be present in order for Windows to function properly, but the author has followed this removal guide only to receive a system hang as a result. So if you want to try this too (maybe you'll have better luck), have a current system-state backup handy first.

It'll be just our little secret—You, me, and the NSA

This one's an 'oldie'. But if true, then there's every reason to suspect that something similar would still applicable today.

In late 1999, all hell broke loose within the security community when Andrew Fernandes, Chief Scientist of Cryptonym corporation was investigating security within Service Pack 5 for Windows NT (this is "Windows NT version 4" that we're talking about) and discovered that there were in reality two—and not just one, as previously believed—code signing keys for this Windows sub-system. Further, whilst embedded within the programming code itself, the first known key was just called "KEY" this second key carried with it the label of "_NSAKEY".

Now the questions that naturally arose were: Why were there two keys when only one was needed? And what do the letters NSA mean??

Well, anyone who is remotely involved in the encryption or security field knows that the letters NSA are likely to stand for only one thing: The United States National Security Agency. This is likely because there are no common security acronyms called "NSA", and the NSA is in fact, the governmental organisation charged with code-breaking and communications interception. They happen to be the largest user of super-computers in the world, presumably for this effect. So the connection seems to make logical sense.

Why worry?

According to Fernandes of Cryptonym, the result of having the secret key inside your Windows operating system "is that it is tremendously easier for the NSA to load unauthorized security services on all copies of Microsoft Windows, and once these security services are loaded, they can effectively compromise your entire operating system". (Once again, "assuming this is correct" then) this would allow the NSA to install any software on a Windows machine at their own leisure, opening your machine's entire contents to them. This second "NSA" code-signing key is contained inside all versions of Windows from Windows 95 OSR2 onwards. 

Whilst Microsoft strenuously denied that this was what the second key was for, many (though probably not 'most') industry insiders still didn't buy it. So again, if true, then it's likely that later versions of Windows might also contain similar mechanisms to provide for either covert compromising, or covert access to targeted machines as desired by your local 'spook'.

What to do?

Given that the source-code for Windows is not public, there's really not much that can be suggested to work around this particular issue unless specific compromises actually get identified (again, presupposing their genuine existence in the first place).

So basically if you're a CEO of a major overseas bank, for example; you had perhaps better consider switching to a secure Linux distribution for your desktop.

• An expanded discussion of the "NSA key" issue will be available from this location shortly

References:

Primary

Gene Goldring; Windows Xp Services, (no date), "Beemerworld"

Torsten Mann; Configuring NT-services more securely,

Jean-Baptiste Marchand; Minimization of network services on Windows, Sept 2002, Hervé Schauer Consultants

Jean-Baptiste Marchand; Minimizing Windows Server 2003 network services, v. 1.10, April 2005, Hervé Schauer Consultants

Microsoft; How to remove administrative shares in Windows Server 2003, June 2005, Microsoft Knowledge Base

Microsoft; How to create and delete hidden or administrative shares on client computers, Jan 2005, Microsoft Knowledge Base,

Microsoft; How to Disable Client-Side DNS Caching in Windows XP and Windows Server 2003, May 2003, Microsoft Knowledge Base, 318803 .

Microsoft; Windows Server 2003 Security Guide, April 2003, Windows Server 2003 Product & Technology Security Center

Microsoft; Service overview and network port requirements for the Windows Server system, v. 12.0, August 2005, Microsoft Knowledge Base,

sec_ware; Towards understanding listening ports, SvcHost.exe, System and Services, March 2004, AntiOnline forum

Black Viper; Windows XP Pro Services Configuration, Oct 2004 (via Internet Archive)

Consulted

Kevin Beaver; Null session attacks: Who's still vulnerable?, Sept 2004, SearchWindowsSecurity.com.

David Chernicoff; Take Care When Disabling Windows' Default Shares, Jan 2003, WindowsITPro

INAA; Ports Listing Assignments,  Aug 2005, INAA

Mark Russinovich; Running Windows with No Services, July 2005, Sysinternals Blog,

Microsoft; The Antivirus Defense-in-Depth Guide, August 2004, Microsoft TechNet

ATW; Task List Programs, June 2005, AnswersThatWork

Software Utilised

Microsoft; Microsoft Baseline Security Analyzer (MBSA) version 2.0, July 2005, Microsoft TechNet.

BindView; RPC Toolset; March 2001, BindView Razor team

Software Cited

Acknowledgements

Endnotes:

Appendices:

Document Information

Usage

Revision History

Feedback

Comments, suggestions, error reports, marriage proposals or offers of hard-currency can be directed to the author at: