Three Steps to Lowering the Attack Surface

Three Steps to Lowering the Attack Surface

Much of the hardening we can do on services and service accounts falls into three categoriesall designed to reduce the attack surface of the host. Attack surface is a generic term that denotes anything that could potentially be attacked . Attack surface does not mean that a component has a vulnerability, nor that it could be exploited. Attack surface just means the host is presenting some interface that an attackershould she be able to find a way to exploit itcan use. In essence, attack surface reduction (ASR) is about reducing the interfaces available to an attacker. There are three basic steps, which we review in the next few paragraphs.

Uninstall Unnecessary Components

The first step in ASR is to uninstall unnecessary components where they can be uninstalled . You should always try to uninstall things because they can otherwise sometimes be turned on by an attacker. Some components also have multiple pieces, and not all of them can be turned off. Consider IPv6. It does provide some compelling functionality, but it also provides some new features that you should be careful with. For instance, netsh interface portproxy provides a port redirector, much like the ones attackers used to have to customize to perform tasks such as circumventing IPsec policies and tunnel Terminal Services through open firewall ports, as we did in Chapter 2, "Anatomy of a Hack: The Rise and Fall of Your Network." If you do not need IPv6, turn it off.

Saying you should remove or turn things off is easy to say but not so easy to operationalize. First, some components cannot be easily uninstalled. We need to disable those instead. The harder part is to figure out what is unnecessary. For a year or so, we have lobbied to tag services, for instance, with better information on this. Consider, for instance, the Alerter service, the "porn advertisement service" as we like to call it from its most frequent use these days. If you go into the Services Control Manager (SCM), the description for the Alerter service is as follows :

Notifies selected users and computers of administrative alerts. If the service is stopped , programs that use administrative alerts will not receive them. If this service is disabled, any services that explicitly depend on it will fail to start.

That sure helps you tell whether you can disable it doesn't it? We tried to get this changed to something more descriptive:

Notifies selected users and computers of administrative alerts. This service is primarily used to advertise new porn sites, and is completely useless in just about every environment. You can freely turn it off without disrupting legitimate functionality.

The program manager in charge of the service was not all that amused, but we found this description to be a lot more useful. Unfortunately, this points to a frequent problem. How do you determine that something is unnecessary? The simple answer is that you turn it off. If everything still works, you did not need it. A lot of people will tell you that you should turn off everything and then turn stuff on again until everything works. The problem is figuring out what you can turn off and still boot the system. Either way works, but we find that starting with a system that boots gets us where we are going faster.

Things to uninstall include all optional services. For example, on Windows Server 2003, IIS is not installed by default, but on the Windows 2000 Server family, it is. The majority of Windows 2000 servers do not need IIS and should have it turned off and uninstalled. The Network Monitor tool is not needed on most systems. Remove it. Basically, if it is optional, turn it off and see whether everything still works. If it does, remove it if you can.

TIP: To determine whether a component is necessary, turn it off. If everything still works, you did not need it.

Disable Unnecessary Features

For those things that can be uninstalled, do so. If they cannot be uninstalled, turn them off or disable them. For example, the aforementioned Alerter service is already disabled on Windows Server 2003 and Windows XP SP2. It can be freely disabled on most other systems as well, but it cannot be uninstalled. The Messenger service can go along with the Dodo bird and the Alerter service. The Workstation service is needed on most systems, but many systems can live without the Server service. For instance, laptops almost certainly do not need to be file servers, nor do many Web servers. Keep in mind, however, that if you turn off the Server service, you can no longer scan the machine for security patches remotely with MBSA. On the other hand, it is likely you need a lot fewer patches on that system.

Block Access to Unnecessary Interfaces

If you cannot uninstall or disable a component, but you still do not need it, block access to it. How you do this depends on the component. For example, binaries that you do not need or want can sometimes not be removed because they are under Windows File Protection. If you try to delete them, they will be automatically restored by the OS. This applies, for instance, to tftp.exe, which we used in Chapter 2 to upload our warez to a hacked system. (Not that you could achieve the same effect with a different tool, but tftp.exe is just so darn convenient for attackers.) Not to worry, however; we can fix that problem a different way. Use software restriction policies (SRPs) the second most powerful security feature in the OS (after IPsec)to block execution of these files. Open up the Group Policy Editor, go to Software Restriction Policies, right-click it, and select Add Software Restriction Policies. Now right-click the Additional Rules node and add the rule you want. There are several types. One way is to add a hash rule, which will block execution of the file even if it is renamed . Another is to add a path rule, which will block execution of the file if it is replaced with a new version. We recommend adding both rules for each binary that you want to block, just to be on the safe side.

Software restriction polices can certainly be tremendously useful, but they are not bulletproof. Code that executes as an administrator or as local system can easily get around them, for example. Therefore, to get full effect of them, you must also make sure that your software runs with least privilege.

The astute reader might have wondered why we did not recommend just blocking everything and then unblocking specifically those things that were required for the system to function. That is the correct way to do things, but it is nontrivial to accomplish. Enumerating all the binaries used by a system simply is very hard, and SRP has the unfortunate side-effect that it is very easy to, and pretty likely that you will, end up with a system that does not boot. However, for the reader who puts in the time to figure out exactly what the minimum set is, the effort is well worthwhile.

There are a couple of shortcuts to help you determine exactly what needs to run. First, use System Internals' File Monitor (http://www.systeminternals.com) to log the system during startup. (Note that by the time you read this, File Monitor and Registry Monitor may have been replaced by Process Monitor, but that tool was not yet available at the time we wrote this.) That should give you a good idea of which files to unblock to make a system bootable. Second, findstr is your friend. Findstr is a built-in command-line tool that works much like grep on UNIX. Dump the File Monitor log to a text file, and then use findstr to find files that get executed. If you have a copy of the Interix tools (if you do not, why not? They are free!), use the cut command to parse the output and sort and uniq to remove duplicates.

By the way, SRP does not exist in Windows 2000 (or Windows XP Home Edition for that matter), so do not bother looking for it there. Yet another great reason to upgrade to Windows Server 2003.