Hardening Microsoft Windows

		Chapter 4 - Windows Honeypot Deployment Honeypots for Windows by Roger A. Grimes Apress 2005

You may think hardening Windows is the last thing you want to do when creating a honeypot, but this is a false first impression. If you’re hosting your honeypots on a system with VM software, you’ll want to harden the host so it cannot be compromised, and all honeypots need security beyond the defaults, if only to protect the system against unexpected compromise. You want hackers to compromise the honeypot, but not with a method that completely compromises the value of the honeypot. You want hackers to compromise particular applications, but you don’t want them wiping monitoring log files or disabling monitoring utilities. You might not want to let hackers bring down the honeypot using a simple DoS attack or allow hackers to randomly delete files.

The rest of this chapter details the different Windows OS hardening steps you can take to secure your honeypot. Which steps you need to take will be determined by your honeypot goals and requirements.

Physically Securing the Honeypot

The honeypot’s physical location should be protected against physical compromise. If intruders can gain physical access to the honeypot computer, then it is game over. They can modify and change anything.

Using the CMOS BIOS settings, disable booting from removable media, such as floppy drives and CD-ROM drives. This will prevent malicious code from being introduced to the computer system prior to Windows taking control, preventing boot viruses, OS modification, and booting around NTFS file permissions. On the same note, disable, in the CMOS BIOS, unneeded USB ports. USB “thumb drives” are almost more common than floppy drives and may be used to introduce malicious code or remove data. Unfortunately, USB ports are not easy to permanently disable in Windows. On a related note, password-protect the CMOS BIOS from unauthorized modification to make sure the boot sequence and other settings are not changed. The CMOS BIOS password should not be the same password used for the Windows administrative account.

Installing Necessary Patches

You should install the appropriate patches as dictated by your honeypot goals. Regardless of the patch state you want to leave the honeypot in, it’s helpful to understand Microsoft’s patch nomenclature and how to patch properly.

Microsoft has different levels of patches:

• A service pack is an all-inclusive maintenance and security patch package. It contains all security patches and fixes since the OS was released for general distribution through the date of the service pack. Service packs are cumulative. You need to apply only the latest service pack, not any of the previous service packs or security fixes.

• Microsoft occasionally releases security roll-ups, which include all security fixes since the last service pack. These are often released in response to there being a large amount of hot fixes to apply and also to fix numerous, previously unpatched, exploits.

• Microsoft frequently (at least once a month) releases security updates or hot fixes to remedy one or more specific issues. Security updates are ranked according to criticality, with the highest priority patches awarded a Critical priority. Microsoft also creates “private” fixes that are available only to customers experiencing a particular reported problem. Private fixes are not available to the general public, but are frequently included in later publicly available patches.

• Microsoft also occasionally releases feature packs for specific applications, which introduce new functionality. At one time, Microsoft developers said that they would not release new functionality in service packs, but this stated position appears to have waned, as service packs frequently contain new features.

To fully patch a Microsoft OS, you must install the latest service pack available, install the last security roll-up (if any), and also install all updates and hot fixes since the last service pack or security roll-up, whichever came last. Figure 4-2 illustrates the patching steps.

Figure 4-2: Microsoft patching pathway

With OSs prior to Windows 2000, you should reapply all service packs and updates after installing new software. This requirement has been alleviated, for the most part, starting with Windows 2000.

If you are trying to maintain a particular level of patching status for your honeypot, it is always best to confirm that the correct patches and software file versions are still installed. You can do this using any of the commercial patch–management software systems or vulnerability assessment tools available, or by using Microsoft’s own patch-management tools. The Microsoft Security Baseline Analyzer tool (http://www.microsoft.com/technet/security/tools/mbsahome.mspx) can be used to check the patch status on Windows NT and later OSs. It comes with GUI and command-line (MBSAcli.exe) versions that reliably detect the patch status of the OS and various applications.

There are several ways to keep your honeypot OS up-to-date with the latest security patches and fixes. Again, you can use commercial patch-management software or use Microsoft’s free tools. Starting with Windows 9x, you can use the Windows Update feature available in Internet Explorer (and other places in the OS, such as Help and System Tools). Windows Update connects the computer to a centralized Microsoft web site, installs an ActiveX control, checks the patch status of the system, and allows you to install missing patches. Windows Update is a great tool for managing a single honeypot or a small honeynet, but it can be cumbersome. It requires manual intervention; there is no automated way to tell it to work.

Starting with Windows 2000 Service Pack 2 and XP Professional Service Pack 1, a service called Automatic Updates can be used to keep Microsoft OSs up-to-date. Automatic Updates does not require that the logged-in user be an administrator (updates are applied using the LocalSystem context, discussed in the “Disabling Unneeded Services” section later in this chapter), and updates can be downloaded and installed automatically. Updates can be downloaded from Microsoft’s centralized Windows Update web site or from SUS.

SUS (http://www.microsoft.com/windowsserversystem/sus/default.mspx) is a free patch-management tool that allows all updates to be downloaded to one or more distribution servers, which are then polled by Windows OSs using Automatic Updates. SUS is an excellent way to keep multiple honeypots, and the entire honeynet, up-to-date. The SUS administrator must approve all updates and patches prior to their deployment to the client systems. SUS has some deficiencies, most notably its lack of flexibility, granularity, and reports. These are being addressed with Microsoft’s newer version called Windows Update Services (WUS). Although still in beta (http://www.microsoft.com/windowsserversystem/sus/wusbeta.mspx) at the time of this writing, WUS is an excellent way to keep any Windows system patched. There are also dozens of commercial patch-management solutions, including Microsoft’s own System Management Server (SMS), which can be used to maintain patch status.

Of course, keeping a honeypot or any computer system secure requires more than patch management. Microsoft security bulletins often recommend Registry edits and configuration changes to protect against exploitation. I will cover OS hardening in more detail in the “Hardening Microsoft Windows” section later in this chapter. Don’t forget to patch installed applications. Currently, Microsoft does not have a one-stop-shop web site for determining all needed patches for the OS and installed applications. However, Microsoft has announced an updated version of Windows Update called Microsoft Update that promises to be a single web site for detecting and patching all Microsoft OSs (Windows XP and above) and applications.

Also, don’t forget to patch any installed non-Microsoft applications and hardware firmware. For instance, if you have Nullsoft’s Winamp or Adobe’s Acrobat Reader installed, make sure you have the latest versions. Both products have been updated recently to prevent known buffer overflows. Regarding upgrading hardware firmware, most motherboards and mass storage controller cards have programming instructions stored on a CMOS chip. Updated firmware code is often available from the vendor to fix bugs and to give added security. For example, when the CIH computer virus (http://securityresponse.symantec.com/avcenter/venc/data/cih.html) began erasing CMOS ROM/BIOS instructions and causing motherboard failures, vendors created new firmware code that required a password to erase the ROM/BIOS instructions.

Rejecting Defaults

For any software or application you don’t want compromised, don’t install to the default folder locations or listening ports. For instance, if your honeypot is running IIS, but you don’t necessarily want the hacker to compromise it (maybe your monitoring tool uses IIS to report its statistics or uses IIS’s virtual SMTP service to send alerts), install IIS to nondefault directories and to nondefault TCP/IP ports. By default, IIS installs to C:\Inetpub\wwwroot and is contactable over TCP port 80. Install the necessary web site files to another, nondescript folder location (maybe C:\Temp\14532). This will help prevent many exploits, because most exploits are automated and rely on programs being installed in their default directories. By simply changing at least one character of the installation folder’s default name, you will defeat tons of automated scripts and exploits. Many of the largest worm exploits would have been defeated by this trick as well, because their coding relies on the use of default installation directories.

Configure the web server to run over any port other than port 80. I typically choose a high port number, well above 10,000. If you really want to confuse the hacker, configure the service to run on another “well-known” port number normally assigned to a different service and change the banner text to claim to be that service. For example, you can instruct the SMTP service to run on port 21 (normally the FTP service port) and change the SMTP and POP banners to mimic an FTP banner reply. Not only will the hackers’ exploits not be successful against the wrong port, but you’ll confuse them a bit as well.

Hardening the TCP/IP Stack

If you don’t want hackers to bring down your honeypot successfully using a DoS attack, harden the TCP/IP stack. Since Windows NT, Microsoft has had Registry settings you can make to strengthen the Microsoft TCP/IP stack against attacks using massive volumes of malformed network packets. Table 4-3 shows Microsoft’s recommended Registry keys and values to protect against DoS attacks directed at the TCP/IP stack.

Table 4-3: Recommended Registry Entries to Harden the TCP/IP Stack

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

The values listed in Table 4-3 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.

Removing or Securing Network Shares

Make sure to remove any nondefault network shares prior to making the honeypot live. Occasionally, honeypot administrators will create network shares between the honeypot and the production network when installing software and applications. Accidentally leaving network shares between your honeynet and production network would be a huge mistake. On the same note, don’t delete Windows default administrative shares, like admin$ and IPC$. These are used by Windows, and their absence may cause operational problems. Removal of the IPC$ administrative share, in particular, will make it difficult to use remote-monitoring utilities.

Filtering Network Traffic

If you don’t want all 131,072 (65,536 × 2) TCP and UDP ports on your honeypot open to the Internet and potential hackers, filter network traffic to allowable ports. You can use the firewall that is in front of the honeynet or use a software-based firewall installed on the honeypot host.

Both Windows XP and Windows Server 2003 come with Internet Connection Firewall (ICF), which is being updated and renamed Windows Firewall (in Windows XP Service Pack 2 and Server 2003 Service Pack 1). ICF and Windows Firewall are fine basic firewalls. Both firewalls will block all incoming traffic not generated by an outgoing request. However, Microsoft’s client-based firewalls cannot block outgoing traffic! This means if malicious code is executed on the honeypot, you cannot use a Microsoft firewall to prevent outbound connections. On a related note, if you use a host-based firewall, don’t forget to allow the ports you want the hacker to use or the ports you need for your monitoring utilities. Figure 4-3 shows an example of specifying these exceptions (obviously, on a live honeypot you would not want to name your monitoring port exceptions something like Remote Monitoring Tool or Sebek).

Figure 4-3: Windows Firewall remote-monitoring port exceptions

On Windows 2000 and above, you can also use IPSec as a firewall. IPSec is versatile enough to allow certain ports from one connection and only particular ports from another. For example, you can use IPSec to block all traffic from the Internet to all ports except 80 and 443, and to allow the remote monitoring ports, but only between the honeypot and the remote monitoring workstation; all other port connections are blocked. For a more detailed discussion on IPSec, download the excellent white paper, “Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server,” available at http://www.microsoft.com/downloads/details.aspx?FamilyID=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&DisplayLang=en.

All Microsoft Windows NT–based operating systems (NT, XP, 2000, and 2003) have a feature called IP Filtering, which is accessible under the TCP/IP protocol properties page under Network Neighborhood. It can be used to block all not explicitly allowed incoming TCP/IP traffic. IP Filtering has basic firewalling capabilities, but it is not stateful. It will not allow traffic back into the computer on which it is enabled, even if first established by an outgoing connection, unless the port is explicitly allowed.

Restricting Unauthorized Software Execution

You should install and enable only the software, applications, services, and ports that you intend to protect the integrity of the honeypot. Although this might sound like common sense, it can be more difficult than it seems.

For instance, if your honeypot computer is running an OS installed by an OEM vendor (such as Dell, Gateway, or Compaq), it probably contains software installed by the OEM to allow remote diagnostics and management. These types of utilities are often unsecured ActiveX controls, and they have been implicated in many exploits over the years (see http://www.kb.cert.org/vuls/id/34453 for an example). Many of the ActiveX controls allow an unauthorized person to take complete charge of the remote-control mechanism. The intruder can collect information, download files, and even format the hard drive. You would want to remove the unneeded ActiveX controls or disable scripting and ActiveX controls altogether in Internet Explorer.

Often, the software doesn’t even need to be used or active, only installed, to be exploitable. Many software programs can be activated and exploited simply by clicking on a malicious web link. For example, an HTTP link beginning with aim:// will launch the AOL Instant Messenger (AIM) client if it is installed. A past exploit was able to launch the instant messaging client and initiate a file-download sequence that culminated with a buffer overflow that allowed the hacker to control the remote system. Just do an Internet search on the term AIM buffer overflow to reveal almost a dozen such exploits. AIM is not alone in being remotely exploited from a maliciously composed web link. Internet Explorer and Outlook Express are the most frequently exploited targets. Of course, these types of exploits take active participation on the part of the honeypot administrator. The administrator would need to use Internet Explorer or an e-mail reader and open a malicious web page or e-mail message to activate the exploit. To ensure that unneeded applications aren’t exploited, uninstall them.

Restricting Access with NTFS Permissions

If you don’t want to uninstall the software, but you still don’t want the hacker to see the software (such as the monitoring software), you can use NTFS permissions to restrict access to the application folder and files. For example, if you don’t want the hacker to use the Format.com program file to format the honeypot’s hard drive, deny Full Control to the file to the Everyone group. This will make it more difficult for the hacker to use the file in a malicious way.

Note 

Starting with Windows Me and Windows 2000, you can no longer delete or rename potentially dangerous files like Format.com, because Windows File Protection (WFP) will replace the file with its original name.

When hardening a Windows system, secure any file that has a better chance of being used maliciously against the system than being used for legitimate means. For example, the Debug.exe file can be used to assemble malicious code. It is rarely or never used by legitimate end users, but by default, Windows security permissions allow end users to Read and Execute the file. So, to offset this potential weakness, use NTFS permissions to remove regular end users’ ability to Read and Execute the file.

You can even remove the administrator’s and SYSTEM account’s access to files and folders using NTFS permissions. Yes, administrators can always give themselves ownership of the files and folders again, but most hackers aren’t expecting this trick, and they just won’t see the software or folder.

The following are the files that I consider to be potentially dangerous, with more of a chance to be used maliciously than legitimately. These are executable files that most users don’t use, but malicious hackers love:

• Format.com

• Edit.com

• Bootcfg.exe

• Cacls.exe

• Cscript.exe

• Wscript.exe

• Debug.exe

• Diskpart.exe

• Edlin.exe

• Exe2bin.exe

• Expand.exe

• Ftp.exe

• Mshta.exe

• Progman.exe

• Regsvr32.exe,

• Replace.exe

• Rsh.exe

• Runas.exe

• Taskkill.exe

• Tlntsvr.exe

You will need to choose which utilities to allow and deny, depending on the goals of the honeypot or host computer. Of course, if hackers gain SYSTEM or administrator control, they can always take ownership of the file and reset the permissions in a favorable way. But there is a way to stop even that approach, as described in the next section.

Using Other Methods to Restrict File Access

In Windows 2000 and above, you can use Encrypting File System (EFS) to encrypt and protect files. EFS can be enabled on a file or folder level. Once enabled, EFS-protected files are nearly impossible to use or read, unless the intruder compromises the account password of the user who enabled EFS on the folder or file, or of the EFS data recovery agent (DRA). In Windows XP or Windows Server 2003, you can even disable the need to use a DRA, offering even less of a chance for compromise. See http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx for more details.

With Windows XP Professional and Windows Server 2003, you can also use Software Restriction Policies (SRP) to prevent unauthorized software execution if you have Active Directory working on the honeypot or host. SRP is not an optimum method for restricting hackers. The most important problem is that there are many known ways to circumvent these policies, and a knowledgeable hacker will probably be able to defeat SRP if it is the only defense mechanism being used. Still, SRP offers another way to prevent software execution. For details about SRP, see http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx.

Disabling Unneeded Services

Take a look at services that are running on the honeypot computer. In Windows 2000 and above, right-click the My Computer object and choose the Manage menu option. In the Computer Management window, expand the Services and Applications object and click the Services object. On the right side of the Computer Management window, you will see the services and their status, as shown in Figure 4-4.

Figure 4-4: Windows Computer Management Services console

The Status column shows Started, Paused, or blank for each service. A service with blank under Status has not been started yet. Just as important is the Startup Type field. It can be set to one of three types:

• Automatic: This means the service starts when the OS starts.

• Disabled: This means the service will not and cannot be started unless its Startup Type is changed to Automatic or Manual.

• Manual: This means the service can be started after the system is running, either by another service or by the user.

Double-click a service to configure it. Configure any unneeded services as Disabled to prevent them from starting.

You may be wondering which services are necessary to run Windows. Unfortunately, there are no definitive answers (every computer may be different, depending on its requirements and what is installed). Table 4-4 shows the possible default services on a Windows Server 2003 computer and the recommended Startup Type settings for a hardened host computer.

Table 4-4: Recommended Windows Services Startup Type Settings

Service	Description	Recommendation
Alerter	Notifies selected users and computers of administrative alerts	Can be disabled unless you are using it for your alerting mechanisms. If the service is stopped, programs that use administrative alerts will not receive them.
Application Layer Gateway (ALG)	Used by vendors as an Internet Connection Sharing (ICS) and Internet Connection Firewall (ICF) API	Can be disabled in environments not using ICS or ICF.
Application Management (AppMgmt)	Works with Group Policy Object (GPO) software installations	Can be disabled in any environment not needing it.
ASP.NET State Service (Aspnet_State)	Used in ASP.NET for out-of-process session states	Can be disabled in most environments.
Automatic Updates (Wuauserv)	Automates software patches	Should be enabled if you are using it for automatic updates.
Background Intelligent Transfer Service (BITS)	Used to limit background downloads (during IIS, SUS, Automatic Updates, and other sessions)	Can be enabled or set to manual in most environments.
MS Software Shadow Copy Provider (SwPrv)	Volume Shadow copy service, which allows the backing up of open files and previous versions clients	Can be disabled unless used on the honeypot.
ClipBook (ClipSrv)	Used by some programs as a universal, industrial-sized clipboard (but not the same as the Clipboard application [for cut and paste] that most users are familiar with)	Can be disabled in most environments.
COM+ Event System (COMSysApp) and COM+ System Application (EventSystem)	Involved with distributing and running COM-based objects and programs	Unless you know of COM-based applications being used, both of these services can be disabled.
Computer Browser (Browser)	Used by Windows to find computer and network resources	Should be enabled in most environments.
Cryptographic Services (CryptSvc)	Heavily involved with providing the OS and applications access to cryptographically protected files and resources	Should be enabled.
Distributed File System (DFS)	Used by domain controllers and DFS servers	Should be enabled on domain controllers in most environments, but can usually be disabled on member servers and clients. Test this one first before disabling it, if you have DFS enabled for client files.
Distributed Link Tracking Client (TrkWks)	Used to keep track of non-domain controller shared files and directories around the network when OLE is involved	Can be disabled on most honeypots.
Distributed Link Tracking Server (TrkSvr)	Used to keep track of shared files and directories on domain controllers	Can be disabled on most honeypots.
Distributed Transaction Coordinator (MSDTC)	Responsible for coordinating transactions that are distributed across multiple computer systems or resource managers, such as databases, message queues, file systems, or other transaction-protected resource managers	Can be disabled in most environments.
Error Reporting Service (ERSvc)	Reports Windows application errors to Microsoft	Can be disabled.
Event Log	Allows events to be recorded to event logs	Should be enabled.
Fax	Allows faxes and modems to use the TAPI interface	Can be disabled unless needed.
File Replication (NTFrs)	Used heavily by Active Directory and domain controllers for Active Directory and group policy replication	Usually not needed on honeypots.
FTP Publishing (MSFTPSvc)	FTP server	Should be disabled unless needed.
Help and Support (HelpSvc)	Help and support services	Should be disabled unless needed to open help files. However, be aware that there are malicious help files (.chm files).
HTTP SSL (HTTPFilter)	Used by IIS in HTTPS mode	Should be enabled on IIS servers if needed; otherwise, it should be disabled.
Human Interface Device Access (HidServ)	Interfaces with multimedia keyboards and the like	Should be disabled unless needed.
IMAPI CD-Burning COM (IMAPService)	Used by CD-R burners	Should be disabled unless needed.
Indexing (CISvc)	Allows fast indexing of local and remote files and content	Should be disabled unless needed. Test if you have any performance issues.
Infrared Monitor (IRMon)	Allows infrared devices to be installed and used	Should be disabled unless needed.
ICS/ICF (SharedAccess)	Used by ICS and ICF	Should be enabled if used.
Intersite Messaging (IsmServ)	Used for intersite Active Directory SMTP replication	Should be disabled unless needed.
IP Version 6 Help (6to4)	Allows IPv6 connectivity over IPv4 services	Should be disabled unless needed.
IP Policy Agent (Policy Agent)	Used by IPSec	Should be disabled unless needed.
Kerberos Key Distribution Center (KDC)	Used for Kerberos authentication (Windows 2000 and above default)	Should be enabled on all domain controllers unless Kerberos is not needed.
License Logging Service (LicenseService)	Keeps track of CALs	Should be disabled unless needed.
Logical Disk Manager (DMServer and DMAdmin)	Used in disk management operations	Should be set to manual.
Message Queuing (MsMq)	Used for developing messaging applications	Should be disabled unless needed.
Message Queuing Down Level Clients (MqDs)	Used to send Active Directory messages to older clients (Windows NT and 98)	Should be disabled unless needed.
Message Queuing Triggers (MqtqSvc)	Used in messaging applications	Should be set to manual or disabled unless needed.
Messenger	Used to send Alerter messages between server and clients	Should be disabled unless needed.
MSSQL$UDDI	Used to find and identify new web services	Should be disabled unless needed.
MSSQLServerADHelper	Used by SQL Server services when SQL Server isn’t running in a local system context	Should be disabled unless needed.
.NET Framework Support Service (CORRTSvc)	Provides .NET client runtime environment	Disable unless .NET programming exists on your honeypot.
NetLogon	Used for network authentication	Should be enabled.
NetMeeting Remote Desktop Sharing (MnmSrvc)	Used for NetMeeting services	Can be disabled if not being used.
Network Connections (NetLogon)	Used to manage network connections folder	Should be enabled or set to manual.
NetworkDDE and NetDDEDsDMs	Used by Dynamic Data Exchange (DDE) programs, which aren’t as popular anymore, but still used by many programs	Should be disabled if not used.
Network Location Awareness (NLA)	Used by network services that depend on detecting new network locations to function properly (DHCP, auto-routing, ICF, etc.)	Should be disabled unless needed.
NTLM Security Support Provider (NTLMSsp)	Needed for NTLM authentication, which is still used by many servers and clients at one point or another	Should be enabled if installed.
Performance Logs and Alerts (SysMonLog)	Used by Performance Monitoring snap-ins	Should be set to enabled if used for monitoring the honeypot.
Portable Media Serial Number (WmdmPmSN)	Reports media player’s serial number if requested	Should be disabled.
Protected Storage (ProtectedStorage)	Used in many different cryptographic mechanisms	Should be enabled.
Remote Access Service Administration (RASAuto, RASMan, Remote Access, SrvcSurg)	Used by RAS	Should be disabled unless RRAS is used.
Remote Desktop Help Session Manager (RDSessMgr)	Works with Remote Assistance, not Remote Desktop	Should be disabled unless needed.
Remote Installation (BINLSVC)	Used only in RIS installs	Should be disabled.
Remote Procedure Call (RPC and RPC Locator)	Used by Windows and its many services and applications to communicate with each other	Should be enabled.
Remote Registry	Works with many remote services (i.e., MBSA, SUS, and other automation tools)	This service is not just for remotely modifying the Registry. It should be enabled unless proven unneeded.
Remote Server Manager (AppMgr)	Used by WMI programs and scripts	Depends on environment. It’s used by many tools, so when in doubt, leave it on.
Remote Server Monitor (AppMon)	Provides monitoring of critical system resources and manages optional watchdog timer hardware on remotely managed servers	Depends on environment. It’s used by many tools, so when in doubt, leave on.
Remote Storage Notification and Remote Storage Server (Remote_Storage_User_ Link and Remote_ Storage_Server)	Used only with HSM secondary storage solutions	Can usually be disabled.
Removable Storage (NtmsSvc)	Used by tape drive and removable media indexes	Should be enabled with any backup solution.
Resultant Set of Policy Provider (RSoPProv)	Used with Group Policy RSoP tool	Can be disabled.
SAP Agent (NWsSAPAgent)	Used when connecting to Novell NetWare networks	Should be enabled if needed.
Secondary Logon (SecLogon)	Allows the RunAs command to be used	Should be enabled if needed. It may help with honeypot administration.
Security Accounts Manager (SAMss)	Accesses and protects the SAM security database	Should be enabled.
Server (LANManServer)	Used in file and print sharing and RPC support	Should be enabled on servers. You may be able to disable it on nonsharing workstations. Test first.
Shell Hardware Detection (ShellHWDetection)	Allows auto-play features to work	Should be disabled.
Simple TCP/IP (SimpTCP)	Provides Echo, Discard, Character Generator, Daytime, and Quote of the Day services	Should be disabled unless needed.
Single Instance Storage Groveler (Groveler)	Used only by RIS	Should be disabled.
Smartcard (SCardSvr)	Allows smart card logins	Should be disabled unless needed.
SNMP and SNMP Trap	Provide SNMP functionality	Should be disabled or uninstalled unless needed.
Special Administration Console Helper (SacSvr)	Used by Windows Server 2003 new Emergency Management Services feature	Should be disabled unless used.
SQLAgent$* (SQLAgent$WEBDB)	Used for SQL Server applications, like tape backups	Should usually be enabled if found and used.
System Event Notification (SENS)	Allows system event logging to occur	Should be enabled.
Task Scheduler (Schedule)	Used by Windows Task Scheduler	Should be disabled unless used (and many programs use it).
TCP/IP NetBIOS Helper (LMHosts)	Needed for NetBIOS over TCP/IP	Should be enabled.
TCP/IP Print Server (LPDSvc)	Allows Unix LPD emulation	Should be disabled unless used.
Telephony (TAPISrv)	Used by modems, voice-over-IP, and other telephony devices	Should be disabled unless used.
Telnet (TelnetSvr)	Telnet Server	Should be disabled unless used.
Terminal Services (TermSvr)	Used in Terminal Services Application and Remote Administration (Remote Desktop) modes	Usually should be enabled.
Terminal Services Licensing (TermServLicensing)	Needed for Terminal Server licensing application mode	Should be disabled unless used.
Terminal Service Session Directory (TSSDis)	Used with Terminal Services	Can be disabled.
Themes	Used to manage Windows Themes	Should be disabled.
Trivial FTP Daemon (TFTPd)	Unsecurable FTP (no user name or password needed)	Should be disabled unless used. RIS uses this service.
Upload Manager (UploadMgr)	Used to upload and download files between client and server	Should be set to manual.
Virtual Disk Service (VDS)	Used to manage RAID storage	Can usually be disabled.
Volume Shadow Copy (VSS)	Used by the Volume Shadow Copy feature	Should be disabled unless used.
WebClient	Used by WebDAV	Should be disabled unless needed. It’s definitely not needed if Internet Explorer 5.01 or Microsoft Office 2000 and above is installed.
Web Element Manager (ElementMgr)	Used for web site remote administration	Should be disabled unless used.
Windows Audio (AudioSrv)	Used for sound	Should be disabled unless used.
Windows Image Acquisition (WIA)	Used by scanners, digital cameras, etc.	Should be disabled unless needed.
Windows Installer (MSIServer)	Used for automatic installation services and installing MSI files	Should be enabled or set to manual.
Windows Management Instrumentation (WMI, WmiApSrv, and WMIMgmt)	Used for WMI	Should be enabled unless you know it isn’t needed.
Windows Media (WMServer)	Used by Windows Media Services	Should be disabled unless needed.
Windows Time (W32Time)	Used for Windows time synchronization	Should be enabled.
WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc)	Used for automatic proxy server discovery	Should be disabled.
Wireless Zero Configuration (WmiApSrv)	Used by the Windows Wireless Zero Configuration feature	Should be disabled unless needed.
Workstation (LANManWorkstation)	Used to connect to remote services and resources using Named Pipes	Should be enabled.
World Wide Publishing Service (W3Svc)	Used for IIS	Should be disabled unless IIS is needed.

It is also important to consider the service account the service uses to execute. A service account is much like a normal user account, except it is used as the security context in which to run the service. By default, most Windows services run in the LocalSystem service account context. Unfortunately, the LocalSystem (or SYSTEM) account is the most powerful “user” account on the system. It has more permissions than the administrator account. And if hackers can successfully create a buffer overflow on a service running in the LocalSystem context, they will usually have the same privileges as the service account that was used to start the service. In many cases, because of the widespread use of the LocalSystem account, this means the hacker gets ultimate control of the system.

For nondefault Windows services, consider configuring the service to run in a less privileged context. To configure the service account that the service uses, click the Log On tab in the service Properties dialog box. For the Log On As setting, choose the This Account option and fill in the service account and password for the service to use. You can use any existing security account here. Figure 4-5 shows a new service account called GCastanza created for the FTP Publishing service. You shouldn’t name your service accounts something that suggests their nature, such as ServiceAcct1.

Figure 4-5: Configuring a service logon

Windows XP and Server 2003 have two new service accounts created explicitly for use as service accounts with significantly fewer privileges and permissions than the LocalSystem account. Both of these new accounts have only the permissions normally granted the guest account and/or generic machine accounts:

• The LocalService account is a low permissions service account that can be given to any service needing access to only the local machine.

• NetworkService is a service account that can be used for services needing a bare minimum of local access plus the ability to connect over the network to other remote computers.

Unfortunately, most application vendors don’t understand the importance of giving their services the least amount of privileges necessary to do their job, and they install their service to run in the context of the LocalSystem account. To complicate matters, even if you call them and ask what permissions the service needs, they really haven’t researched it and will always claim that the service “needs system access” in order to function. In reality, most services need only Change permissions to a particular Registry key or folder to do their job, not Full Control to the entire system and network. It’s a sad state of affairs for a Windows security or honeypot administrator.

The key to securing and hardening services is to let them run in the security contexts with the least amount of permissions and privileges needed to do their job. Unless you really know what you’re doing, most people leave the default Windows services set to their assigned defaults. But with nondefault Windows services and add-on services, you can usually tighten the security even more securely than the usual LocalSystem context. To do so, use the following steps:

1. Determine what permissions, privileges, and access the service needs to the local computer and remote computers. You can usually do this by running the service in its default context and monitoring its file and Registry accesses using Sysinternal’s Filemon and Regmon utilities.

2. Once you have determined the necessary permissions, create a service account (which is just a user account) with only those permissions.

3. Open the service in the Computer Management Component Services console and edit the Log On dialog box entries to use the new service account.

4. Restart the service and make sure it runs as expected.

Following these steps is a time-consuming process. In general, I recommend that you accept the vendor defaults, unless elevated security levels are needed or a particular service has a known hole being actively exploited.

Note 

If you use service accounts besides the system defaults (LocalSystem, NetworkService, or LocalService), you will need to enter and change the password in the user management utility (Active Directory Users and Computers console or User Manager applet) and within the Computer Management Component Services console. Service account passwords in the Computer Management Component Services console are stored in the Registry and must be entered, changed, and manually synchronized with the passwords stored in the user account management database.

For my honeypots, I even configure many default Windows services to run in a more secure service account context. For example, I often run the FTP Publishing and World Wide Web Publishing services with a service account that does not have complete control of my system.

Protecting User Accounts

You can take several steps to protect user accounts: rename the administrator and guest accounts, use complex passwords, and disable anonymous enumerations.

Renaming the Administrator and Guest Accounts

The administrator and guest user accounts are often the subject of malicious attacks. Rename the administrator and guest user accounts if you don’t want them compromised. Considering that 99.9% of the attacks against your honeypot are automated and expecting the administrator account to be called Administrator, you can significantly reduce the risk of malicious compromise of those accounts by renaming them.

Typically, I rename the administrator and guest accounts to names that appear to be normal user accounts (for example, EBennis), and I create two new dummy accounts in their place. Be sure to remove the old descriptions from the renamed accounts and re-create them in the new dummy accounts. Then remove all permissions and privileges from those accounts. Using Windows Explorer and NTFS permissions, explicitly deny those two user accounts Full Control permissions to all files and folders on the computer. Consider disabling them. You want to secure both dummy accounts in order to fool the hackers. Also, if they are compromised, the hackers have no privileges to work with. The hackers will wish they had the access given by the normally low-privileged guest account!

Some security experts think renaming the guest and the administrator accounts is weak security (“security through obscurity”). They know that hackers could enumerate the security identifiers (SIDs) of user accounts and find out which ones are really the administrator and guest accounts. But most hackers don’t enumerate account SIDs, and 99.9% of the attacks are automated. By renaming those two accounts, you will defeat many exploits and add another layer to your defense-in-depth strategy.

Using Complex Passwords

To secure user accounts on your honeypot host computer, make sure the user accounts use long, complex passwords. For Windows, this typically means using a password at least 8 characters long—and at least 15 to 40 characters as the minimum size would be even better—using uppercase and lowercase characters, numbers, and symbols. Passwords using common dictionary-based words or fewer than 15 characters are considered easy to crack by brute force. Passwords longer than 14 characters are harder to crack, with 40-character or longer passwords (called passphrases) estimated to be unbreakable in the near future.

Consider enabling Account Lockout policies so that if someone begins trying to guess passwords, the user account will be disabled, at least temporarily. Also, disable or remove inactive user accounts. These are often targets for hackers, who enable them, and then use them to “sneak below the radar” while performing malicious deeds.

Disabling Anonymous Enumerations

You should disable anonymous enumerations on Windows NT 4.0 systems and above. The anonymous user account (also called the NULL user or NULL connection) is a default Windows account that cannot be deleted or disabled. It is needed throughout legacy Windows systems (prior to Windows 2000) to list user accounts and group accounts, to access remote Registry keys, and to list Windows trusts and network shares. Unfortunately, hackers can use the anonymous account (the anonymous user account has no relationship to the IIS anonymous user account) to connect to a Windows system and learn the same information.

In Windows Server 2003, anonymous enumerations are disabled by default on all computers except domain controllers (unfortunately, it is necessary for domain controllers). If you are trying to secure a host computer, disable anonymous enumerations. This can be done using a group policy object or the Registry key HKLM\System\CurrentControlSet\Control\LSA\ RestrictAnonymous. In general, a value of 0 allows unrestricted anonymous enumeration, and a value of 1 disables anonymous enumeration, unless otherwise specified.

Securing Authentication Protocols

When a security principal account (user, group, computer, or service account) logs in to a Microsoft Windows computer or accesses a Windows resource (such as a network share, file, or program), it must be authenticated. In the early days of Windows networking, the LAN Manager (LM) protocol was used. The LM protocol was subsequently found to be easy to compromise. Starting with Windows NT 4.0, Microsoft started using the NTLM protocol. Although stronger, it was also found to be easily compromised. NTLM version 2 (NTLMv2) was released with Windows NT 4.0 Service Pack 4, and it made the NTLM protocol harder to exploit. NTLMv2 is installed on Window 98 computer systems and above, if you have the latest patches applied.

With Windows 2000, Microsoft released its strongest authentication protocol to date: Kerberos, which is an open-standard protocol developed originally by MIT. It is significantly stronger and more secure than any of Microsoft’s previous attempts, and, to date, has not suffered an exploit. Consequently, when trying to harden a Windows machine, you should always use Kerberos when possible. Unfortunately, Microsoft is compelled by its customers to offer backward compatibility, and even Windows Server 2003 can use any of the previous protocols. In fact, all of Microsoft’s OSs still store, by default, the easily broken LM password hash.

Note 

Weak LM password hashes are automatically disabled on any account using a 15-character or longer password.

Although all Windows 2000 and above computers will attempt to use Kerberos by default for authentication events, these computers will use NTLMv2 (or earlier authentication protocols) if the following situations exist:

• The Windows client instructs the server to use an earlier authentication method.

• The Windows client logs in to a Windows NT 4.0 domain.

• The user logs in with a local user account instead of a domain user account.

• The Windows client was released prior to Windows 2000.

You should disable LM password hashing and disable all authentication protocols except Kerberos and NTLMv2. You should not allow LM or NTLM protocols to be used. By default, the client can force the server to use the lesser protocols, unless the server is configured to refuse the older authentication protocols. You can use Registry entries or Group Policy Objects (discussed in the next section) to disable LM hashing and to force NTLMv2 and Kerberos protocols (see http://support.microsoft.com/default.aspx?scid=kb;en-us;147706).

Automating Security

All Windows 2000 and later computers come with integrated tools for automating security. First, they have a Local Computer Policy object (accessed through Start All Programs Administrative Tools Local Security Policy), which can be customized. It contains over a hundred entries, which will be enforced every time the computer boots. If the computer participates in Active Directory, you can also use Group Policy Objects (GPOs), security templates, and administrative templates to enforce security.

GPOs have hundreds of settings that can be configured to apply to users or computers when they log in to an Active Directory domain. Figure 4-6 shows an example of GPO settings. You can enforce every option mentioned previously for hardening your OS, including software execution restrictions, NTFS permissions, renaming administrator and guest accounts, enforcing newer authentication protocols, and disabling LM hashes. If you’ve never used GPOs before, once you have, you’ll never go back to the older, manual method of securing Windows systems. Go to the Group Policy Resource Center located at http://www.gpanswers.com for more information about GPOs.

Figure 4-6: Example of Group Policy Object security settings

Although you should not join a honeypot computer to your production Active Directory domain, you can still install a separate Active Directory domain for your honeypots or use the Local Computer Policy object.