Top 10 (or so) Client Security Tweaks

Limiting Malicious Code

We combine things a little differently for clients. The most important "tweak" to do on clients is to make malicious code less likely to run. Basically, there are three objectives, in decreasing order of desirability:

1. Prevent malicious code from getting onto the system.

2. Prevent malicious code from running.

3. Prevent malicious code from communicating.

Obviously, we would prefer to keep the malicious code off the system in the first place. However, if it gets on the system, we want to prevent it from running, and if it should happen to run, let us try to keep it from infecting anyone else. Four technologies (not necessarily tweaks) are critical here.

Firewalls

Host-based firewalls are becoming all the rage. Windows XP includes a free host-based firewall, and Windows XP Service Pack 2 includes a very good, free host-based firewall, called Windows Firewall (WF). WF includes some very sophisticated management functionality that affords network administrators great control over the firewall. For instance, they can configure it to behave one way when on the internal network, another way when not. They can open up an authenticated IPsec bypass allowing all authenticated IPsec traffic to bypass the firewall, and they can set up program-based exceptions that allow certain firewall-unfriendly programs, such as instant messenger programs, to work properly. In all, the firewall has only one real or imagined shortcomingit does not perform outbound filtering. There are three reasons why: (1) Users do not understand it and therefore it will not help. As we mentioned earlier, if a dialog asking the user to make a security decision is the only thing standing between them and dancing pigs, security does not stand a chance. (2) Given that outbound filtering is a delay feature for the vast majority of users, why expend the limited available resources on that instead of giving administrators a great centrally manageable firewall? (3) Outbound filtering is available in IPsec already.

This does not, of course, mean that outbound filtering is not a worthwhile feature, just that it is not worthwhile for all users. For those who do need it, outbound filtering can be had through third-party firewalls.

We recommend using host-based firewalls on all your clients because they help stop malicious code from getting on the system in the first place.

IPsec Filters

IPsec filters can be used in many different ways on clients. Between the discussion about IPsec filters on servers above, and the discussion in Chapter 10, however, we have probably beaten that horse to death. As a general recommendation, we recommend that you use IPsec filters to prevent your clients from talking to each other.

Software Restriction Policies

SRP is more difficult to use on clients than on servers, because clients are more general-purpose machines. Setting up SRP to allow a client to actually function is a significant upfront time investment. However, if you spend the time doing this, you will be rewarded with a much more secure machine. We recommend that you use SRP as much as possible to protect clients from malicious code.

Anti-Malware

Antivirus software is the traditional malicious code prevention technology. The problem with antivirus software is that it is only signature based. It cannot prevent viruses that it does not know about, which SRP can by allowing only trusted code to run. As a defense- in-depth measure, antivirus is tremendously important, but it is important to understand its limitations.

Do not forget about other types of anti-malware programs either. Anti-spyware is rapidly becoming a requirement as well. Of course, if you run as LUA (see Chapter 13, "Protecting User Applications"), it is unlikely you will get much spyware on the system, but it is very useful if you have to run as an administrator.

There is also the problem that not all machines can use antivirus tools. For instance, we do penetration testing, and the antivirus products delete the tools we use in that job. Therefore, we cannot run them. As a general rule, however, we recommend using antivirus products on most, if not all, clients.

SafeDllSearchMode

Remember the summer and fall of 2001? The world was changing, significantly. There were attacks from everywhere. On the Internet we had Code Red. When you finally had cleared that off all your systems, your boss came running into the office screaming that there was another worm on the loose. No worries, you responded; IIS was already patched. There was only one problem: This one spread other ways, too. The next thing you knew you had Nimda on your hands, and it spread through file shares.

Nimda searched all available file shares it could find for Microsoft Word documents. The reason was that one of those "security researchers" who believe the world is safer if he tells all the script kiddies how to exploit something without giving the vendor a chance to fix it first had posted a treatise on how to load and execute code when users double-clicked Word documents. The issue stems from how the operating system searches for dynamic link libraries (DLLs). DLLs are used to allow programs to share common functionality. Programs load them by calling LoadLibrary or LoadLibraryEx. When a program calls this function specifying just the name of the DLL, as opposed to a full path , the OS will search to find the right version in the following way:

1. Memory If the program is already running and has the DLL loaded, it will not load it again.

2. Application directory To allow programs to keep their own copies of DLLs so they can load specific versions, those have very high priority.

3. Current working directory This allows programs to use SetCurrentDirectory to load a particular DLL.

4. System directories These are the %systemroot%, %systemroot%\system, and %systemroot%\system32 directories.

5. Path Some DLLs are found along the path.

This list can be modified by various technologies such as manifests and .local files, but that is beyond the scope of this book. This has been the way Windows has worked since the very first versions of the OS. What the "researcher" figured out was that Word will load certain DLLs at startup. If you dropped a copy of one of those, the one he used was riched20.dll, into a directory with documents, it would be loaded by Word when the user double-clicked one of the documents. Nimda used this exact issue as one of the ways to spread.

Several interesting observations can be made here. First, neither the person who discovered how to use this for malicious purposes nor the writers of Nimda (we are not aware of any connections between the two) understood nearly as much about the OS as they have been given credit for. Riched20.dll is the "rich text editor" DLL. It is used to provide bolds, italics, and so on. It is actually loaded by the OS automatically for an awful lot of programs. In other words, they could have looked for almost any file they wanted and dropped it there. At one point, we swear we saw WinZip load this DLL. Second, this is core operating system functionality. It has worked this way for years . The fact that no bad guys had made use of it until 2001 was astounding. Third, the basic functionality is really broken. If you go tell any decent UNIX administrator to put a period (.) as the first thing in his path, he will claim you are smoking some funny tobacco . They all know not to do that. Yet, that is how Windows was always designed to work.

This all changed with Windows XP Service Pack 1. Starting with that release, the SafeDllSearchMode setting switched items 3 and 4 in the load order, protecting system DLLs from spoofing. To understand how important this switch is, consider that it would have stopped Nimda in many cases!

The SafeDllSearchMode functionality is available and turned on by default in Windows XP Service Pack 1 and higher, and in Windows Server 2003. It is available but turned off by default in Windows XP RTM and Windows 2000 Service Pack 3 and higher. We highly recommend turning on SafeDllSearchMode in Windows 2000 as well. (Windows XP RTM should be upgraded to Service Pack 2 or higher.) To turn it on, set a REG_DWORD called SafeDllSearchMode to 1 under HKLM\System\CurrentControlSet\Control\Session Manager. On Windows Server 2003, this value does not exist, but if it is absent the default value is 1.

When you make a fundamental change to how the operating system works, like this, there is always some breakage. In this particular case, surprisingly, the number of breaks was low. SQL 2000 includes a component known as the Starfighter Foundation Classes in SFC.DLL. Unfortunately, SQL Server instead loaded SFC.DLLthe system file checkerfrom the system directory. That was fixed in SQL Server 2000 Service Pack 3. The only other breakage we are aware of was with Outlook 2000 loading add-ins.

This setting protects against an extremely common scenario whereby an internal attacker drops binaries in file shares. The breakage caused by turning it on is minimal. For these reasons, we believe SafeDllSearchMode is one of the most important settings to turn on to protect clients.

Local Administrator Account Control

We have a confession to make. Up until now, we have pretty much made an implicit assumption that we are dealing with clients in an enterprise. Although it has made no particular difference in how we configure the systems up until now, it changes how you deal with accounts. On a client in an enterprise, there is usually a domain controller, which means that clients really only have one account locallythe built-in Administrator account. This is important, because the policies we set from now on will be different in an enterprise versus a small business or a home office. For more specific details on how to run systems in small businesses, see Chapter 15, "Security for Small Businesses."

Do Not Store LAN Manager Hash Value

The first thing to do to protect the local Administrator account is to keep the LM hash from being stored (see Chapter 10 for more detail on the LM hash). In a home or small business, this may be harder to do using the NoLMHash switch if there are accounts defined on the system that have to be accessible by Windows 9x clients. However, if no accounts defined on the system are used by down-level clients, we recommend turning off storage of LM hashes.

NOTE: Although you can technically turn off LM hash storage even if you have Windows 9x machines in your environment, doing so requires installing and configuring the DSClient on your 9x machines. Frankly, we recommend you spend your time getting rid of 9x instead. Your time will have been better spent and your environment will be more secure if you do.

Password Policies

Administrator accounts should have very strong passwords. We recommend that they should be 10 to 14 characters long and appear essentially random. You can configure the local password policy on all systems in a domain by setting a password policy on the Organizational Units that those systems are in. Password policy on an OU only applies to local accounts on the member systems of that OU. Therefore, it is ideal for controlling the local Administrator account. If there are user accounts on the clients, you may need to adjust the password policy to make it palatable to users. For more details on password policies, see Chapter 11.

SMB Message Signing

We discussed SMB message signing at length both above and in Chapter 11. Therefore, we do note reiterate that discussion here. We do recommend turning on SMB message signing and setting it to required on both the Workstation and Server services on all clients.

LAN Manager Authentication Level

The LAN Manager authentication level issue has been discussed at length already. For clients, the main concern is emanating LM responses, which can be much more easily cracked. To prevent this, we recommend configuring the "LAN Manager Authentication Level" to 4 or "Send NTLMv2 response only/ refuse LM" as well as configuring security on the NTLM SSP, as mentioned previously in this chapter.

Limit Local Account Use of Blank Passwords to Console Logon Only

One of the coolest features with Windows XP is how it handles blank passwords. By default, if an account has a blank password it can only be used at the console, not over the network. This is designed as a home-user feature to allow them to have the same experience they would have with Windows 9x, where passwords provide no real value. The Group Policy setting is there only to enforce this functionality. It is important to ensure that it stays on.

For the record, you can use this functionality with Windows Server 2003 as well. We have recommended its use in cases where we have servers locked in physically secure racks. Setting a blank Administrator account password allows physically trusted personnel to access the systems in case of severe failure, but those Administrator accounts cannot be used across the network by an attacker.

Anonymous Restrictions

Clients should look like black holes on the network to all systems other than management points. The authenticated IPsec bypass in the Windows XP Service Pack 2 firewall is a great way to make that happen, but the same lockdown should also be done with respect to anonymous restrictions. Pure clients have no business volunteering anything to anonymous users, and we recommend configuring all the anonymous settings discussed above.

We have even gone so far on some particularly threatened clients as turning off the Server service. This will, however, render the machine unmanageable since the Server service is used by virtually all remote management tools. On a system that is particularly threatened where remote management is not a requirement, however, this may be a reasonable course of action.

Enable Auditing

How much auditing you really want to do on clients depends on a lot of factors, such as the threats, management processes in place for audit logs, the number of clients, etc. Generally speaking, however, you probably do not want to collect gigantic logs from clients. However, a few events can prove very useful in forensics.

Logon Events

Logon events are recorded when someone logs on to the system, regardless of the account used. In other words, if you log on to a domain member using a domain account, you get a logon event recorded on the domain member. You would also get a logon event recorded if you log on with a local account.

Account Logon Events

Account logon events are recorded when someone authenticates using an account defined on this system. In other words, if you log on to a domain member using a domain account, the account logon event gets recorded on the domain controller, not on the client. If you log on to the domain member using a local account, the account logon event gets recorded on the client.

One of the authors once was in a situation of doing forensics on a system that had been hacked by a student in his lab. The student had logged on to the machine, shut it down, set a boot and BIOS password, and changed the system clock. The student had then booted the system to ensure everything worked, logged on again, shut down the system, and then left. The logon events on the system itself were incorrectly ordered due to the system clock change. However, by correlating those events with the account logon events on the domain controller, we were able to determine conclusively both who had performed the attack and when. This information was enough to take action against the student. Thus, logon events can be very useful on clients. Other useful types of events include object access auditing. For any object access events to be recorded, however, you need to first configure system ACLs (SACLs) on objects, because none are configured by default.

We recommend configuring audit settings that are consistent with your security policy and audit needs.

Allowed to Format and Eject Removable Media

The right to format and eject removable media hardly sounds like a security setting, does it? Besides, it is granted only to administrators by default, so why change it? This right allows a user to burn CDs and DVDs. Doing so is increasingly becoming a job requirement for many people. Without changing this setting, that means that all those people would need to be administrators on the system. By granting this permission (which is a security option, not a privilege, in Group Policy) to interactive users, you allow those users who need to burn CDs to do so without having to make them administrators. This improves the overall security posture of the system, which is why we include it as the last of the client security tweaks we recommend.