Conventional Defenses

Although this book is full of unique, unconventional tips, conventional wisdom is still needed. This section covers over a dozen common security recommendations, plus a few more less commonly known suggestions.

Don't Give Users Admin Access

In order for most malware to work, it must be executed locally by the end user. After execution, the malware typically works in the security context of the end user who executed it. This means whatever the user can do, the malware can do. Unfortunately, most administrators allow their end users to be logged in with administrator-level privileges. Most often the user is logged in with an account that is added to the local Administrators group. This is done so that normal end users can install software and configure their computers. In general, administrators have Full Control permissions to all local computer resources.

Non-administrative users (known as Limited User Accounts or LUAs) cannot do a host of normal administrative activities, including the following:

• Install or uninstall programs, including Internet Explorer programs

• Configure Windows system settings

• View or change security permissions

• Change network configuration settings (sometimes cannot view settings)

• Create new shares (but can map to existing shares)

• View the security log (but can view Application and System logs). They cannot clear any of the Event logs.

• View local computer policy settings

• Stop, start, load, or pause services

• Change most things in the System applet

• Add non-Plug-and-Play hardware or drivers

• Modify drivers in the Control Panel

• Add or change hardware profiles

• Change page file parameters

• Manipulate many taskbar programs

• Change system time or time zone

• Create new Performance logs, Counters, or Alerts

• Configure Remote Desktop/Assistance (but can request Remote Assistance if so enabled)

LUAs can usually manipulate anything to do with their desktop profile, including delete and add desktop icons, change desktop background and screensaver, and map and disconnect drive shares. They can execute existing programs, run commands, modify Internet Explorer security settings (strangely enough), change folder options, schedule tasks, add printers, and encrypt files.

Whereas administrative accounts have Full Control permissions to all local system resources, LUAs have only Read or Read & Execute permissions to most Windows system files and areas. They usually also have Write permissions to personal areas, such as their profile, home directories, My Document folder, and temporary file locations. We will cover this in more detail in Chapter 3. LUAs have mostly Read-only permissions to most registry keys, including the ones most popularly attacked by malware. They also have Write permissions to the Current User registry keys (covered in Chapter 6).

Computer administrators often give regular end users Administrator rights so they can install software and change Windows settings, when needed. To be fair, prior to the forthcoming Windows Vista (see the "Windows Vista" sidebar later in this chapter), Microsoft didn't give administrators an easy way to allow regular end users to install software without being an administrator, and in many cases all new user accounts are added to the Administrators group by default.

The net effect is that once malware is executed, it is running in the context of the local Administrator and can do nearly anything it wants to the system. Because of this risk, system administrators should not allow end users to be logged in with administrator-privileged accounts. If this rule were followed, it would defeat 70–90% of today's malware attacks. The truth is that there are many ways for malware to spread and do harm without needing administrator permissions, but most rogue programs are coded with the expectation that the user will be logged in as an administrator.

If your end user isn't an administrator, an account with administrative permissions will be needed to install software or reconfigure Windows system settings. This can be accomplished as follows:

• By having an administrator install all software and configure system settings

• Using the group policy software install feature to install program (covered in Chapter 14)

• Giving the user a second, more privileged account to install and configure with

With the latter option, users can be told of a second account that they should use when installing software and reconfiguring the system. You can rename the Administrator account something similar to the user's normal login account (such as Ray2, where Ray1 is used for normal operations) or call the account something like Software Installs. Although this technique would decrease the potential attack risk if utilized correctly, the propensity for the user to always be logged in as the elevated privileged account is high.

RunAs

Another option is to teach nonadmin users how to use the RunAs feature to invoke their higher privileged, admin account when needed. Microsoft created the RunAs feature in Windows 2000 and has increased its functionality in every version of Windows since. RunAs was developed so that even system administrators could stop being logged in full-time with administrative privileges. Microsoft realized that even administrators spend the majority of their time doing non-admin tasks, such as writing documents and picking up e-mail. Administrators are often responsible for accidentally running malware programs, and should therefore only be logged in as administrators when administrative permissions are needed.

The RunAs feature can be executed within the Windows GUI or at the command line. From within the GUI, you need only right-click any executable to get a RunAs option. Select The following user radio button (see Figure 2-3), and then fill in the name of the administrative account you want to use, preceded by the machine or domain name to which the account belongs, type in the password, and select Enter or click the OK button.

Figure 2-3

Note 

If the RunAs option does not appear when you right-click a file, try holding down the Right-shift key and then right-clicking the file. For reasons unknown to me, the Right-shift key makes the RunAs option appear when it doesn't without the right-shift key trick. Sometimes, the RunAs option will not appear with some executables, such as Format.com, either way.

Note 

The Secondary Logon service must be running on the machine where RunAs is executed.

In Windows XP and later, RunAs uses the impersonated user's desktop profile (in Windows 2000 it used the Default Users' profile instead). At first, this might not seem like a big deal, but because drive mappings and other desktop settings are saved to a user's profile, there is a potential for the inputted command not to work.

Administrators can create desktop icons with the RunAs feature already selected by right-clicking on any desktop icon, choosing Properties, selecting the Shortcut tab, and then clicking the Advanced button. You will then be able to select the Run with different credentials option (see Figure 2-4). Then, when you click on the icon, you will be allowed to run the selected program with different credentials. Unfortunately, the new credential account will always need the password typed in, but security-wise this is desired.

Figure 2-4

Command-Line RunAs

If run at the command line, RunAs has even more features and flexibility. Running RunAs at the command prompt without any parameters results in the following output:

 C:\>runas RUNAS USAGE: RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]         /user:<UserName> program RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]         /smartcard [/user:<UserName>] program    /noprofile        specifies that the user's profile should not be loaded.                      This causes the application to load more quickly, but                      can cause some applications to malfunction.    /profile          specifies that the user's profile should be loaded.                      This is the default.    /env              to use current environment instead of user's.    /netonly          use if the credentials specified are for remote                      access only.    /savecred         to use credentials previously saved by the user.                      This option is not available on Windows XP Home Edition                      and will be ignored.    /smartcard        use if the credentials are to be supplied from a                      smartcard.    /user             <UserName> should be in form USER@DOMAIN or DOMAIN\USER    program         command line for EXE.  See below for examples Examples: > runas /noprofile /user:mymachine\administrator cmd > runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc" > runas /env /user:[e-mail] "notepad \" my file.txt\"" NOTE:  Enter user's password only when prompted. NOTE:  USER@DOMAIN is not compatible with /netonly. NOTE:  /profile is not compatible with /netonly. 

In the simplest form, you can type in syntax similar to this example:

 Runas /user:<domain>\<username> <pathname\programname> 

It is important to remember to put in the domain name before the user name if you intend to use a domain account. The program name must be inside quotes if it includes long file names or spaces. An example command might look like this:

 Runas /user:banneret\tgrimes "mmc g:\windows\system32\dsa.msc" 

This example command would launch the Active Directory Users and Computers console in the context of the user account TGrimes in the domain Banneret.

The default RunAs command line allows the current user to use the impersonated user's profile and environment instead of his own. Running with the /noprofile switch can save time on most commands, but can cause problems. Try both ways. Starting with Windows XP (but not shown in the Windows XP command-line syntax listing) is a new feature called /savecred. Using the /savecred command, you can instruct Windows to save the impersonated user's logon name and password to be used next time when RunAs executes the same command. This feature requires the Stored User Name and Password functionality to be left enabled (it can be disabled with Group Policy, as covered in Chapter 14). You can use the command-line version of RunAs in desktop shortcuts to gain the additional functionality offered in the command-line version on the desktop GUI.

For an administrator to use RunAs routinely means learning how to execute many Windows GUI commands at the command line. For example, to change the system time or time zone, use RunAs with Timedate.cpl. Running Sysdm.cpl will launch the System applet. Or launch an administrative console using cmd.exe and then run the needed program or functionality.

RunAs Issues

Unfortunately, RunAs isn't perfect. Possibly most distressing is that it cannot run Windows Explorer, the utility often used by administrators to view and modify NTFS and Share permissions. A common solution dedicated administrators can implement is to use Remote Desktop and connect to the same desktop with administrative privileges. It's crude, but it works. Second, RunAs doesn't work with all installs. While RunAs can be used to run and install many programs, many install programs will not install. If you have problems, try running the Add/Remove Programs wizard using the Appwiz.cpl command. Lastly, it refuses to work with many programs for reasons unknown, and the failure often doesn't give you a good error message to troubleshoot. For instance, even when you start Internet Explorer (Iexplore.exe) using RunAs in an administrative context, Windows Update will not work. It will appear to be working and just fail.

Third-Party Privilege Escalation Apps

Consider using a third-party utility to accomplish elevated privileges, such as MakeMeAdmin (http://weblogs.asp.net/aaron_margosis/archive/2004/07/24/193721.aspx). When you run it, you get a command-line prompt running under your normal user account profile, but in a new logon session in which it is a member of the Administrators group. This command prompt and any programs started from it use your regular profile, authenticate as you on the network, but have full local administrative privileges. All other programs continue to run with your regular, unprivileged account. There is also a MakeMePU.cmd (PowerUser mode).

Extending LUA Protections

Often, the reverse behavior is wanted. Administrators who do need administrative credentials the majority of the time wish they could run some programs using an LUA account. For instance, many administrators realize the increased risk of using Internet Explorer and wish they could run just that program as a non-admin user. You can use RunAs to accomplish this or use another third-party application called RunAsAdmin (https://sourceforge.net/projects/runasadmin). RunAsAdmin allows you to utilize XP's and 2003's SAFER API (covered in Chapter 9) to run at a lower privileged logon token. It has a per-user startup interactive configuration option that enables the user to choose what restriction level to use on the fly. It was designed by a Microsoft MVP and can be trusted.

Keep Patches Updated

Many of today's popular attacks only work because administrators have not kept their Windows system patches up to date. Recently, a friend of mine who is a very knowledgeable and respected administrator for a Fortune 500 company called me to report an Internet worm outbreak in his organization. He said that over 1,500 computers were infected across multiple county offices and that his antivirus software was not detecting it. From his description of what the worm was doing (i.e., crashing the RPC service), I knew this meant that worm was attacking a vulnerability patched over a year ago. After I helped him repair his systems, we learned that the worm used three different vulnerabilities, but all were patched by Microsoft over a year ago. One of the vulnerabilities was over three years old. In my eyes, he was to blame for his company's downtime.

Sadly, I also understand the practical world. There are many companies who can't keep patches updated. For instance, another Fortune 500 company I work with has several hundred Windows NT 4.0 workstations and servers running in their production plants. They run a critical manufacturing program and the vendor refuses to warranty the software if it is patched beyond its installed Service Pack (SP) 2 level. The software has been paid for and does its job perfectly. To replace the functionality would cost tens of millions of dollars. The company weighed the potential risk of being down from a virus or worm against the replacement cost of the system. Security is always a formula of cost versus benefit measured in dollars.

Many other companies have overly small staffs already overburdened with current support duties. To do thorough regression testing on big patches is beyond their current staff's workload, especially if they aren't being hacked a lot currently. Many companies still haven't deployed Windows XP's Service Pack 2 even though it has been out since August 2004, and even though its application closes hundreds of attack holes. Again, I could complain about the lack of foresight, but this is the practical reality that many organizations face. And ultimately, this is how some organizations become extremely vulnerable to Internet attacks and worms.

Although there is no hard and fast rule, organizations should strive to deploy Windows system and other third-party application security patches within a reasonable window of time based upon the patch's criticality and the company's likely risk of exposure. Microsoft rates each patch it delivers with a severity rating of critical, important, moderate, or low (see www.microsoft.com/technet/security/bulletin/rating.mspx for more details). Before determining whether a particular patch applies, an organization should decide ahead of time how quickly it needs to deploy a patch based upon its severity rating. Table 2-1 shows an example of a patching deployment time line.

Table 2-1

If Patch Severity Rating Is…	Patch Should Be Deployed Across All Applicable Computers Within…
Critical	1 day—2 weeks (less than 1 week for high risk attacks)
Important	1–3 weeks
Moderate	3–8 weeks
Low	4 months

Patch Regression Testing

Of course, patches need testing prior to production deployment. The patch deployment team should create multiple test workstations that mimic the production environment. Ideally, there would be a test machine to match every configuration within the enterprise. When new patches come out, the team should deploy them to the test workstations and check for application compatibility. Microsoft is doing a better job of testing their patches before deploying, but at least once or twice a year a patch is released that causes widespread problems to a fair percentage of users.

After the patches have been deployed and tested on the nonproduction machines, they should be deployed in a limited fashion to selected production computers within the environment. The production machines testing should absolutely test all computer configurations and applications deployed across the enterprise. If the patch is determined to cause few or no problems, it should then be widely deployed across the enterprise using a patch management tool. The patch deployment team should have a patch rollback plan prior to deploying any patch in case something goes wrong. Consider reading Susan Bradley and Anne Stanton's excellent ebook, The Complete Patch Management Book (www.ecora.com/ecora/jump/pm99.asp) or Microsoft's patch management document (www.microsoft.com/technet/security/topics/patchmanagement.mspx).

Microsoft Patch Management Tools

Although there are many better third-party tools, Microsoft has many free and commercial patch management deployment tools, including System Management Server, Windows Update Service, Microsoft Update, Automatic Updates, and Microsoft Baseline Security Analyzer. I'll summarize each here:

• System Management Server (www.microsoft.com/smserver/default.asp)

  System Management Server (SMS) is Microsoft's premier software deployment and desktop management tool. Although it can do far more than just deploy software patches, it is an excellent tool for doing just that. It has excellent fine-tuning controls, management flexibility, and excellent reporting. However, it is an expensive commercial tool and requires significant experience to operate.

• Windows Server Update Service (www.microsoft.com/windowsserversystem/updateservices/default.mspx)

  Windows Server Update Service (WSUS) replaced the less functional Software Update Services (SUS) server product in June 2005. WSUS, like SUS, is Microsoft's best free tool for patch management. Although not as feature rich as other third-party products, WUS is a solid patch management competitor. You must install it on a Windows 2000 or 2003 server and have the appropriate client access licenses (CALs). It supports Windows 2000 and later clients. The clients must have the Automatic Updates service installed and configured to pull from the WSUS server. Then patch management administrators download and approve patches on the WUS server, which then deploys to the workstations.

• Microsoft Update (http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en-us)

  Microsoft Update replaces Microsoft's Windows Update web site. Whereas Windows Update could only check for and update the Windows operating system and a small subset of applications (i.e., Internet Explorer, Outlook, Outlook Express), Microsoft Update will check for and install patches to a wider range of applications (including Exchange, IIS, Microsoft Office, and SQL Server). Previously, with Windows Update, you had to visit additional web sites to patch all those applications. Microsoft promises to include additional applications at the Microsoft Update web site. Unfortunately, like Windows Update, Microsoft Update requires that the installer be logged on as an administrator, the process is manual, one machine at a time, and lacks any centralized control or reporting.

• Automatic Updates (www.microsoft.com/downloads/details.aspx?FamilyID=&DisplayLang=en)

  Automatic Updates is a client-side service first installed with Windows XP Pro Service Pack 1, but later installed in Windows 2000 Service Pack 2 and in Windows Server 2003. It can be installed manually by downloading from the link above. Automatic Updates connects to either Microsoft's Windows Update site or to a corporate WUS or SUS server. It can be instructed to check for new patches every day or once per week. Patches can be downloaded and installed automatically, or just downloaded or the end user notified. Automatic Updates installs patches using the LocalSystem context, and as such the end user does not need to be an administrator. If patches are downloaded directly from Microsoft's Windows Update web site, there is no centralized control or reporting.

• Microsoft Baseline Security Analyzer (www.microsoft.com/technet/security/tools/mbsahome.mspx)

  Microsoft Baseline Security Analyzer (MBSA) cannot patch a Windows computer, but can be used to check for common security misconfigurations and missing critical patches. It can be run against Windows NT 4.0 and later machines (but it cannot be installed on Windows NT) and the person using it must have local administrator credentials on the machines being scanned. The File and Printer and Remote Registry services need to be running for MBSA to work remotely. It can be run against a single PC or against a network of machines. MBSA provides a nice XML-formatted report, but there is no easy way to get a single summary report for multiple machines.

Don't forget to patch your non-Microsoft applications. Some third-party applications, such as Sun's Java and Macromedia's Adobe Acrobat, seem to need patching as frequently as Windows. Also, don't forget to update and patch your hardware drivers, disk controller cards, and computer BIOSs. Keeping up on your patching is a significant way to prevent malicious attacks and exploitation.

Use a Host-Based Firewall

Every Windows PC should have a host-based firewall installed. Windows XP and Windows Server 2003 come with a Microsoft-built firewall called Windows Firewall (it was called Internet Connection Firewall in Windows XP pre-SP2 and Windows Server 2003 pre-SP1). Windows Firewall blocks all inbound connection attempts not initiated by an outbound connection or previously defined as an allowed inbound service. Because the Windows Firewall cannot block outbound connections, many security experts (including this author) have written about how poor it is. Now, however, after years of solely relying on it, I've come to appreciate it. I removed all my other firewalls, including my old favorite, ZoneAlarm (www.zonelabs.com/store/content/home.jsp), and my network perimeter firewall, SonicWall (www.sonicwall.com). Verdict? Even though my network is under constant attack and I travel constantly and attach to grossly infected networks, my machines have remained clean. Windows Firewall works! It's not the best host-based firewall, but it is free and it works.

Windows Firewall is a basic stateful firewall. It will block all inbound, unauthorized connections. If any connection prompts are displayed, they are concerning whether to allow an application to set up new inbound listener ports (called exceptions). Exceptions (see Figure 2-5) are the ports or applications that can accept inbound connections not initiated by an outbound connection. Windows Firewall has three main states: On (with exceptions allowed), On (with no exceptions allowed), and Off. Whether or not ICMP traffic should be allowed is also configurable. Disabling all ICMP traffic may prevent some legitimate programs from working. For instance, Active Directory uses ICMP probes to determine whether a slow link is detected for group policy purposes (www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/.mspx).

Figure 2-5

Windows Firewall allows you to configure different firewall settings for different network connections. Thus, you can set one policy for laptop computers connected to your LAN and another for when they are away from the corporate network. In most cases, you would want the firewall policy to be more relaxed when connected to your LAN so that you can administrate the machine remotely but put its defenses up when away so that malicious code does not compromise it. In the corporate environment, you can use group policy to define particular groups of people that can access Windows Firewall-protected machines without being filtered by the firewall as long as they use IPSec. For more information on Windows Firewall group policy settings, read the document located at http://download.microsoft.com/download/6/8/a//wf_xpsp2.doc.

New Features of Windows Firewall

When Microsoft's Internet Connection Firewall was updated in XP SP2 and Windows Server SP1 to Windows Firewall, many new features were introduced, including the following:

• Firewall enabled by default for all network connections

• Firewall can be configured per connection or globally

• Improved exception definitions (by IP address or subnet, by executable)

A default firewall policy is enabled during Windows startup, allowing only basic traffic, such as DHCP and DNS, to pass until the firewall is fully functionality (ICF did not protect during Windows startup). This default policy cannot be modified.

Can completely control using group policy

New Windows Firewall applet in Control Panel

PV6 support

IPSec support, and IPSec is Windows Firewall aware

IPSec traffic can be routed past the firewall without inspection, and can be done by Windows group (covered in Chapter 8)

Netsh support

• You can query the state of your firewall using the Netsh.exe command, as shown in the following commands:

   Netsh firewall show state (will document the firewall's overall settings) Netsh firewall show logging (will tell you if logging is enabled and how it is configured) Netsh firewall show allowedprogram (will list program files listed as Exceptions) 

IAnother interesting feature is the capability to define specific groups of users or computers that can bypass the Windows Firewall inspection process. The specified user's computers must use IPSec to communicate with the intended host. The idea is that if the traffic is already protected and authenticated by IPSec, then the duplicative filtering abilities of the firewall aren't needed. This could be used to allow admin users to bypass the firewall or to allow use of remote management tools. Unfortunately, this sort of feature would also allow malware or a hacker to take advantage of the additional trust if they compromised a IPSec-connected computer.

On the downside, Windows Firewall has some significant weaknesses when compared to its competitors:

• It cannot block outbound connections (which means locally executed malware can connect to outbound to notify its originator, infect other computers, or update its own programming). The forthcoming Windows Vista firewall will block outbound connections.

• Logging is not turned on by default and even when turned on is very poor.

• It cannot send alerts to the user on unauthorized inbound connection attempts. Sometimes it is helpful to know when your machine is under attack

• It does not do application-layer inspection or identify specific attacks. Thus, if your machine were under a massive denial-of-service attack, Windows Firewall would only log each attempt separately, and is not able to aggregate the smaller attacks into one large, cohesive attack

Note 

A short Microsoft summary article on Windows Firewall can be found at http://support.microsoft.com/default.aspx?kbid=875357.

For those administrators looking for a better host firewall, consider the following products:

• ZoneAlarm (www.zonelabs.com/store/content/home.jsp)

• McAfee Personal Firewall Plus (http://us.mcafee.com/root/package.asp?pkgid=101&WWW_URL=www.mcafee.com/myapps/firewall/ov_firewall.asp)

• Norton Personal Firewall (www.symantec.com/sabu/nis/npf)

• Tiny Firewall (www.tinysoftware.com/home/tiny2?la=EN)

There are dozens of good host-based firewalls to choose from. My personal favorite is ZoneAlarm. It was recently purchased by CheckPoint (www.checkpoint.com). ZoneAlarm could be overly intrusive at times, but contained a feature unique to the host-based firewall world. Many host-based firewalls will block outbound attempts by executables not previously allowed. Unfortunately, most users aren't knowledgeable enough to know what should and shouldn't be allowed. Heck, most security people don't really know what they should allow. For example, should Microsoft Office and VMware be initiating outbound connections when they are installed? If you don't allow them, will you miss a security update or something else desirable? ZoneAlarm has a feature that consults a centralized database that makes the decision or tells the user what most people choose when faced with a similar decision about the same program. This feature is not included in the free product. After ZoneAlarm, I liked Tiny Firewall. It works well, has a small footprint, and has the least impact on legitimate communications. McAfee and Norton firewalls can also be installed in a wider suite of vendor offerings (i.e., antivirus, anti-spam, etc.).

No matter which host-based firewall you choose, you should install and use one. It is not enough to have only a firewall on the network's edge.

Use Antivirus Software

Most organizations are already using antivirus software, but there are some best practices to reinforce. Here are some antivirus recommendations:

• Administrators should make sure each end-user computer has a running, real-time scanning antivirus program with an updated signature database.

• An antivirus program should consistently rank high in terms of current and overall accuracy. Several web sites report on the accuracy of the most popular antivirus scanning products, including The Virus Bulletin 100 (www.virusbtn.com/vb100/about/index.xml).

• The antivirus product should have consistently accurate repairs when it removes malware.

• The signature update should be automated, either directly to the vendor (for laptops) or down-loaded from a centralized corporate definition server.

• Antivirus software should be installed on e-mail servers (at least until malicious e-mail traffic subsides).

• If antivirus software is installed on a network edge gateway device, it should scan all ports allowed through the firewall and not just the default ports (usually 21, 25, 80, and 110).

• Antivirus software should cause minimal/acceptable slowdown on end-user computers.

• The antivirus vendor should have timely tech support and report on suspicious submitted files in a timely manner.

• The antivirus product should prevent regular end users from disabling the product.

• Antivirus software should allow all files or just selected file types to be scanned.

• Antivirus software should scan file headers to identify files and not just rely on the file extensions.

• With the proliferation of peer-to-peer (P2P) programs, any installed antivirus software should inspect P2P traffic.

• Antivirus software should recursively inspect all compressed file types.

Very few things in the computer security world are "rock-science," but antivirus scanning is. Today's scanners are a far cry from their early versions. They use incredibly efficient scanning techniques to look through tens of thousands of files per minute, they contain emulation environments to catch polymorphic and stealth works, they and contain accurate heuristic scanning engines. I rarely recommend a new, untested antivirus product to clients. I prefer to stick with the tried-and-true antivirus scanner vendors that have proven their accuracy and mettle over multiple years.

Use Anti-Spam Software

As reported in Chapter 1, spam is still a major problem. All e-mail should be protected by an anti-spam software program or device. Anti-spam defenses can be deployed at four locations:

• Desktop

• E-mail server

• Network gateway

• E-mail service provider

Interestingly, spam accuracy goes up the further you get away from the desktop. Desktop anti-spam products (currently) have the worst accuracy in detecting spam of any of its competitors. This is the exact opposite of the results I find in antivirus software. Anti-spam software deployed on e-mail servers is better, but still, in my opinion, unacceptable. If your anti-spam product isn't approaching 99% accuracy, then you need a better product.

Dozens of anti-spam products and appliances deployed on the network's edge have proven to be very accurate and efficient. Personally, I use an appliance called the Barracuda Spam Firewall (www.barracudanetworks.com). Like many other of its competitors, it is highly accurate (99% or above), feature-rich, fast, and highly customizable. The only downside is that the spam e-mail must reach the device, and hence, your network, in order to be filtered. Several companies, such as MessageLabs and Postini, filter out spam before it reaches its destination networks. They are the most accurate anti-spam services available and are relatively low cost (per-seat pricing starts at $15 per year). These services tend to be less feature-rich and customizable compared to network gateway solutions, and you must route your e-mail (by repointing your mail MX record) to the provider. Even though they sign a confidentiality agreement, you will have to allow management to agree to third-party inspection of your e-mail. No matter which anti-spam solution you choose, you need to implement one. Spam is a leader in spreading malicious malware, spyware, and adware.

Use Anti-Spyware Software

Sadly, even though the major antivirus vendors are positioned to be the best spyware detectors, none of the major players seem to be taking the threat of spyware seriously. With antivirus programs running on the desktop inspecting all traffic headed to and from the PC, you would think the antivirus programs could add signatures for spyware and thoroughly protect the desktop. Maybe one day, but not now. You should select and use an accurate anti-spyware solution. There are dozens of free products on the market, including Lavasoft's Ad-Aware (www.lavasoftusa.com), one of my favorites, and Microsoft's own solution (www.microsoft.com/athome/security/spyware/software/default.mspx). Microsoft bought Giant Software's anti-spyware product. The Microsoft beta release has consistently tested among the most accurate products. Per Bill Gates, the individual version will remain free, but an enterprise-managed version will be commercially supported.

A big plus for Microsoft's product is that it is one of the few free products that blocks, as well as detects, spyware. Most free anti-spyware programs detect spyware after the fact, but do nothing to prevent new infections. Usually you have to buy the commercial versions in order to receive proactive protection.

There are dozens of anti-spyware product reviews—just be sure not to be fooled by the many bogus "spyware sites" that are really looking to add more spyware to your system. Here are two trusted legitimate spyware detector review sites:

• www.pcmag.com/category2/0,1874,1639157,00.asp

• http://windowssecrets.com/comp/050127

In a nutshell, no single anti-spyware product catches everything. And all products catch things that the others miss. Combining two anti-spyware products increases accuracy, but I can't seem to talk myself into using two different products even if it results in slightly better accuracy. Maybe it's because I'm already using/paying for a firewall, anti-spam, and antivirus software. Some antivirus vendors offer anti-spyware products as well, but I haven't found them to be very accurate in my testing. Anti-spam appliances, such as the Barracuda Spam Firewall, are also checking for spyware, but I haven't completed my testing to give an accuracy rating.

Physical Security

As discussed previously, if a hacker has physical access to your computer assets, there isn't much you can do to prevent malicious exploits, theft, or data destruction. All computers containing sensitive information should be protected by physical security measures. This includes building security, locks, doors, and passwords.

Boot-Up Passwords

Portable computers, such as PDAs, cell phones, and laptops should be protected with boot-up passwords. That way, if they are stolen, the thief will have a more difficult time accessing the computer. Most laptop thieves don't know how to disable the boot password and end up junking the stolen goods—better than some random criminal accessing your corporate or personal information. When PDAs and cell phones are boot password protected, it requires that the criminal wipe out all permanent memory in order to access the device. This, again, protects your data.

Boot Only from the Primary Hard Drive

All computers should be prevented from booting from any media except the primary hard drive. Many malicious hacks depend on the intruder being able to boot around Windows (using special tools or Linux boot discs), bypassing Microsoft's built-in security. By preventing booting from anything but the primary hard drive, you have significantly reduced your risk from a physical attack. On a related note, this will also prevent boot viruses from infecting the computer. If you need to boot on a floppy disk or CD-ROM disc for troubleshooting purposes, you can always modify the BIOS back to the appropriate setting.

Password-Protect the BIOS

After configuring the computer's BIOS to only boot on the primary hard drive, password-protect the BIOS from unauthorized changes. This will prevent a physical attacker from switching the computer back to booting on malicious media. Sure, a knowledgeable attacker can open the computer case and disable the BIOS password option, but if the intruder has that much access and time, you've got other problems to worry about as well. The BIOS password should not be the same password that you use for your Windows administrators. The BIOS password is likely to not be changed on a regular basis, and because of remote troubleshooting, is more likely to be given out to a regular end user.

Harden the TCP/IP Stack

The TCP/IP stack is the network software that takes packet data handed to it by the network interface card software driver and passes it to the operating system for further processing. Microsoft Windows has its own TCP/IP stack drivers, although additional drivers can be added by installed programs (such as Ethereal or Winpcap) or by Layered Service Provider (LSP) programs.

The TCP/IP stack can be attacked by remote hackers, usually in the form of a denial-of-service attack. Microsoft hardened the default stack in XP Pro SP2 and Windows Server 2003 SP1. Microsoft has registry settings you can use to strengthen the Microsoft TCP/IP stack on previous Windows versions against attacks using massive volumes of malformed network packets. Table 2-2 shows Microsoft's recommended registry keys and values to protect against DoS attacks directed at the TCP/IP stack.

Table 2-2

Value Name	Value (REG_DWORD)
The values below are located beneath the registry key HKLM\SYSTEM\CurrentControlSet\Services
SynAttackProtect	2
TcpMaxPortsExhausted	1
TcpMaxHalfOpen	500
TcpMaxHalfOpenRetried	400
TcpMaxConnectResponseRetransmissions	2
TcpMaxDataRetransmissions	2
EnablePMTUDiscovery	0
KeepAliveTime	300000 (5 minutes)
NoNameReleaseOnDemand	1
The values below are located beneath the registry key HKLM\System\CurrentControlSet\Services\AFD\Parameters
EnableICMPRedirect	0
EnableDynamicBacklog	1
MinimumDynamicBacklog	20
MaximumDynamicBacklog	20000
DynamicBacklogGrowthDelta	10
The values below are located beneath the registry key HKLM\System\CurrentControlSet\Services\Tcpip\Parameter
DisableIPSourceRouting	1
EnableFragmentChecking	1
EnableMulticastForwarding	0
IPEnableRouter	0
EnableDeadGWDetect	0
EnableAddrMaskReply	0

The values listed in Table 2-2 are not the default values, and if the various registry keys do not exist, they will need to be created. You can get more detailed information about each setting at http://support.microsoft.com/default.aspx?scid=kb;en-us;324270.

Note 

Not all of the recommended settings in Table 2-2 are implemented in XP Pro SP2 and Windows Server 2003 SP1, but the new TCP/IP stacks are sufficiently hardened so that in most cases, no modification is needed on these versions of Windows or later.

Malware, as discussed in Table 1-1 in Chapter 1, can also hide as LSP software by manipulating Windows' normal Winsock functionality. By injecting itself as LSP software, the malware effectively becomes part of the TCP/IP stack. When network traffic is intercepted by the network card on the way in or is sent by the operating system or applications on the way out, it is passed along the LSP software programs. Each LSP program can inspect and manipulate the reviewed data streams. I've seen this trick used more by spyware than by viruses and trojans, but it can completely disconnect a system from a network. This risk is often greatest when such malware is imperfectly removed!

Once while I was manually removing a particularly difficult NewDotNet adware program (http://securityresponse.symantec.com/avcenter/venc/data/adware.ndotnet.html), the system I had cleaned could no longer connect to the network. After researching the program some more, I realized that it had injected itself as an LSP program and caused network problems when I removed it. I downloaded a program called LSPFix (www.cexx.org/lspfix.htm). It revealed the hiding adware and enabled me to remove it. Figure 2-6 shows a snapshot of a normal XP Pro SP2 system without malware installed.

Figure 2-6

Several trojan and spyware programs, such as Riler (http://securityresponse.symantec.com/avcenter/venc/data/trojan.riler.html) and Daqa (http://secunia.com/virus_information/10835/win32.daqa.a), also use the LSP as a hiding place.

Note 

The LSP networking API has been strengthened in XP Pro SP2 and Windows Server 2003 SP1 to make it more resilient when nonstandard LSP programs are removed.