Hardening Systems
Although hardening a server is a tedious process, it is relatively easy to do, and it incurs no additional software or hardware expense. First, you must harden the base operating system. Then, you must take similar precautions for any services you intend to run on the box. It does not help to harden the base OS and leave gaping holes in the Web or Database server installations. Remember: Every product you install has the potential to allow intruders to gain access to your server. A firewall will not stop an intruder from attacking the shopping cart application running on your Web server.
Windows NT 4.0
Windows NT 4.0 has been the workhorse for Microsoft for years now. And although its more feature-rich replacement is now available, there are many reasons why Windows NT 4.0 might still be deployed. The current dearth of firewall applications for Windows 2000 is one such reason. As such, hardening guidelines for the elderly flagship product are discussed first. Many options apply to Windows 2000 as well, so reading through is still worthwhile.
Hardening Installation Guidelines
When installing Windows NT 4.0 Server, try to follow these guidelines as closely as possible. Some of these changes might remove a needed functionality that your application requires. If this is the case, you will have to work harder to protect the server.
Do install on NTFS partitions, not FAT. NTFS provides additional control via access control lists (ACLs). Do not install to FAT and then convert to NTFS after installation because this will not apply the default ACLs.
Do install as a standalone server, and do not install as a domain controller. There is no conceivable need to have a firewall or DMZ Web, mail, or DNS server participate in a domain.
Do not install any extra software that is not needed. By default, the Windows NT installation includes many accessibility support tools, accessories, multimedia applications and themes, and communication applications. The more software you install, the more that can possibly be exploited. Follow the Tao of Security: simplicity, starting with installation.
Do not install Internet Information Server (IIS) v2.0, which comes with Windows NT, even if this server is to be a Web server. Upgrading earlier versions of IIS does not remove unused files—files that can still be exploited in the newer IIS installation. Until the upgrade process removes old files, it is often better to uninstall IIS and install the new version rather than upgrade in-place.
Do not install other networking protocols other thanTCP/IP. Additional protocols cause additional problems. NetBEUI is not useful outside of a workgroup, and IPX is often not handled properly by firewalls. One of the biggest and most common security problems is allowing IPX to run over NetBEUI. This can let intruders through your firewall to desktop machines.
Do not add additional services, unless of course this is to be a DNS server. Web servers, mail servers, and firewalls generally should not run DNS. The only possible service to add is Simple Network Management Protocol (SNMP) for remote monitoring of the firewall and DMZ services. Be certain to block those ports externally, and change the read and write community strings from the defaults. SNMP can easily give away more information than you intend if you leave that service accessible from the Internet.
Do not install WINS. If you need to have NetBIOS resolution outside of DNS, use the LMHOSTS file.
Do not do DHCP relaying. In general, there is no need for DMZ servers to relay anything (unless, of course, it is a mail server acting as a smart hub for internal hosts.)
Do not enable IP Forwarding, unless this server will be the firewall. A firewall is not achieving its potential if it never forwards IP traffic.
Do use a nonexistent workgroup. There is no reason for a firewall or DMZ server to participate in domain or workgroup activities.
Do not install Internet Explorer 5 or 5.5; they provide way more additional functionality than you need on the average server. Remember that any additional functionality can be exploited in non-obvious ways. IE 5 and 5.5 are not a single program, but a collection of reusable components. That means that any program on your system can reuse that functionality. Don't give intruders additional tools to attack you with. If you need to update IE on your Windows NT 4 firewall or DMZ server, install IE 4.01 Service Pack 2. IE 4.01 SP1 comes on the Windows NT Option Pack CD, but IE 4.01 SP2 is available for download.
Do install the most recent Service Pack and hotfixes appropriate to your platform and installation. As of this publication, Service Pack 6a was available, along with several additional hotfixes.
Do remove unnecessary services installed automatically during the install process. These services include the following:
Remote Procedure Call (RPC)
NetBIOS
Computer browser
These additional services can be removed, but might impact the functionality of the server. You should check with your software's requirements, or, better yet, perform a lab install and test the configuration before deploying in a production environment. These services can be removed by choosing Control Panel, Network, Services.
Workstation—Impacts services such as at.
Server—Might impact some servers' performance.
Do unbind WINS from TCP/IP. Choose Control Panel, Network, Bindings. Select All Protocols from the drop-down menu. Click WINS Client (TCP/IP) and then Disable/Remove.
Do ensure that the following services are disabled:
Alerter—A notification service to deliver messages to users of certain administrative events.
ClipBook—Allows clipbook contents to be seen by remote clipbooks.
DHCP Client—Allows the network settings to be configured by remote means.
Messenger—Sends and receives messages sent by administrators or the alerter service.
NetBIOS Interface—Provides NetBIOS over TCP/IP
Net Logon—Provides pass-through (workstation) or authentication and domain security database synchronization (server) to other machines in a domain.
Network DDE—Provides dynamic data exchange in a networked environment to remote machines.
Network DDE DSDM—Manages the shared database of DDE connections.
TCP/IP NetBIOS Helper—NetBIOS over TCP/IP provides name-to-IP address mapping.
Although convenient for remote server administration, it is best to not add additional services, including remote management services such as telnetd and FTP. Neither provides encryption; so accounts, passwords, and other information can be gleaned via the network. If these services must be enabled, be sure to take precautions, such as allowing access only through the firewall from the internal network, and applying IP security filters on the servers running the services.
Do enable IP security filters on the DMZ servers. Firewalls have their own IP filtering, and do not need or require native Windows NT IP filters. Choose Control Panel, Network, Protocols, TCP/IP Protocol, Properties, Advanced. Check Enable Security and then select Configure. Add the inbound ports you want to accept, as shown in Figure 1.
){kind=link}
Figure 1. Windows NT 4.0 TCP/IP Security Filter configuration dialog box.
Do remove the right for users to allow access to the server from the network; force console access only.
Do assign individual admin accounts if you have multiple admin accounts. This helps the auditing process.
Do rename the Administrator account to another name.
Do create a dummy Administrator account with no privileges. As intruders try to compromise this account, they will be logged in the audit logs.
Do reduce the number of groups that have access to the server to only those necessary for operation and administration of the server. You should be able to reduce the groups down to Administrators and Power Users.
Do enable more secure system policies. Use User Manager to modify the Account, User Rights, and Audit system policies:
Account policies control user password and lockout settings. Passwords should expire according to the timeframe set by corporate policy. Minimum password length should be at least nine characters, while remembering 24 previous passwords. Account lockout should occur after three bad logon attempts. The counter can be reset after 30 minutes.
All User Rights should have the Everyone group removed. Remove all groups and users from Access This Computer From the Network, and limit the users and groups that can Log on Locally. Make sure to pay special attention to Manage Auditing and Security Log.
Turn on auditing of success and failure of at least these events: Logon and Logoff; Security Policy Changes; and Restart, Shutdown, and System.
Do enable the blank screen saver with a low inactivity timer—say five minutes. Enable password-protection on the screen saver.
Do run the SYSKEY utility to enhance the security of your Security Accounts Manager (SAM) database. The SYSKEY utility became available with Service Pack 3, so after you've applied Service Pack 6a or newer, SYSKEY will be available.
Do remove the OS/2 and POSIX subsystems. This can be done by running the C2SECURITY tool from the Windows NT Resource Kit, or manually by editing the following Registry keys.
Remove this key, which will remove all subordinate keys pertaining to the OS/2 subsystem:
HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\OS/2 Subsystem for NT
Remove the Os2LibPath value from the Environment key:
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\Session Manager\Environment Os2LibPath
Remove the Optional, POSIX, and OS/2 keys from the Session Manager SubSystem key:
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\Session Manager\SubSystems
After the Registry changes, you must manually remove the %WINNT%\system32\os2 directory and any subdirectories.
Registry Modification Guidelines
There are some functions and features of Windows NT that are controlled solely through Registry settings. Take care in modifying the Registry because you can easily cripple your system. The following various Registry changes make Windows NT have a more secure default stance.
Set this key to 1 to clear the last used username from the login dialog box:
HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows NT\CurrentVersion\Winlogin DontDisplayLastUserName
Set this key to 1 to restrict anonymous connections from listing account names:
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\Lsa RestrictAnonymous
Create the following key to restrict network access to the Registry, so Registry modifications must be made from the local system. Service Pack 3 or higher needs to be installed for this Registry entry to work.
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\SecurePipeServers\winreg
Set the following key to 1 to disable the creation of 8.3 names for compatibility on NTFS partitions. The 8.3 names are normally only used by Win16 applications so this should not be a concern. Additionally it provides a slight performance gain by reducing the overhead of generating and writing the 8.3 name.
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\FileSystem NtfsDisable8dot3NameCreation
Set to 0 to disable the automatic sharing of administrative shares (ADMIN$, C$, and so on). Make sure you delete the shares manually by using the net share /d command.
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\LanmanServer\Parameters AutoShareServer
Set the Application, Security, and System keys to 1 to prevent Guest and null sessions (sessions with no username or password authentication) from viewing the event logs specific to that log:
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\Eventlog\Application \CurrentControlSet\Services\Eventlog\Security \CurrentControlSet\Services\Eventlog\System RestrictGuestAccess
Set this key to 0 to prevent any caching of user credentials (credentials of the last 10 users to interactively log on to the system are normally cached locally by Windows NT):
HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows NT\CurrentVersion\Winlogon CachedLogonsCount
Commonly attacked Registry keys should have their access restricted via ACLs. The following Registry keys at the very least should be protected by providing read-only access to Everyone, and Full-Control to Administrators and SYSTEM only. Creator Owner should be given Full-Owner control:
HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows\CurrentVersion\RunOnce HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows\CurrentVersion\RunOnceEx HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows NT\CurrentVersion\AeDebug HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Windows NT\CurrentVersion\WinLogon
Windows 2000 Server
At the time of publication, Windows 2000 is the current production flagship server product from Microsoft. Windows 2000 is a much larger, more complex product than Windows NT 4.0, and as such will take more time to fully analyze its default security stance and guard against any weaknesses. These guidelines should be taken as a snapshot in time, and might not always be correct. There are several living documents published by Microsoft in its Technet library that should be referenced for up-to-date information.
Hardening Installation Guidelines
Do install on NTFS partitions, not FAT. NTFS provides additional control via access control lists (ACLs). Do not install to FAT and then convert to NTFS because this will not apply the default ACLs.
Do try to reduce the number of Windows 2000 components you are installing. Windows 2000 offers many more features by default than Windows NT 4.0, many of which you do not want to offer the denizens of the Internet. By default, the Windows 2000 installation includes many accessories, utilities, multimedia applications and themes, and communication applications. It might be tempting to just install the default software selections; however, take the time to determine what should and should not be installed. The more software you install, the more that can possibly be exploited.
For most firewall and DMZ server builds, there will be no need for Terminal Services, Remote Installation Services, Networking Services, or File and Print Services. Do select only the components and services necessary for the server's specific purpose. For example, ensure that FTP support in the IIS server is not being loaded if this server is to serve HTTP pages only. If you will not be serving streaming media, there is no need to load Windows Media Services.
Do not load Certificate Services; that should be an internal-only service because the CA (Certificate Authorities) private key should be kept secret, and you generally aren't offering Certificate enrollment to various Internet users. As a general rule, corporate Certificate Authorities are kept in a tightly controlled and secure environment on an isolated internal network.
If you need system monitoring, install SNMP from Management and Monitoring Tools, but be sure to change the read and write community strings.
When configuring the Network Settings, select Custom settings to manually configure the networking components. Do remove File and Printer Sharing for Microsoft Networks. If this server is going to be a Web or SMTP mail relay, disable Client for Microsoft Networks by unchecking it, but leave it installed. Apparently, the RPC Locator Service used to perform authentication is only available with the Microsoft Networking Client installed. Without this service installed, you cannot start the IIS or SMTP services.
Then, select IP Protocol Properties. Do not use DHCP to configure the IP address and DNS information automatically. After you have manually configured the network settings, click the Advanced button, and make the following changes:
Select the DNS tab. Uncheck Register This Connection's Addresses in DNS.
Select the WINS tab; disable WINS by removing any WINS addresses. If you must enter NetBIOS names, use the LMHOSTS entry. Disable NetBIOS over TCP/IP by selecting Disable NetBIOS over TCP/IP.
Select the Options tab to configure any TCP/IP filtering, as described in the previous Windows NT 4.0 section.
Do not install into a domain or Active Directory structure. Do install into a nonexistent workgroup. There is no conceivable need to have a firewall or DMZ Web, mail, or DNS server participate in a domain.
After Windows 2000 finishes the install and reboots, you might notice some additional errors in the Event Log. At the time of publication, this affected Windows 2000 both with and without Service Pack 1. The most common is Event ID 31 or 36, relating to the Windows Management Instrumentation (WMI) ADAP service being unable to load a performance library. You might be able to resolve this problem by executing the following commands:
winmgmt /clearadap winmgmt /resyncperf -p processID
processID is the process ID of the running WINMGMT process from the task list. If this does not solve the problem for you, you can either ignore the error (not the best habit to get into), or disable the performance counter by setting the following Registry value to 0x0:
HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\Spooler\performance WbemAdapStatus
This turns off the performance counter.
Finally, if you continue to receive errors in the Application Event Viewer, you can disable individual performance counters. Using the ExCtrlst utility found in the Windows 2000 resource kit (or downloaded from ftp://ft.microsoft.com/reskit/win2000/exctrlst.zip), you can disable individual performance counters such as Spooler, RAS, perfnet, perfdisk, perfmon, and so on.
Windows 2000 Does Policies Right
If hardening Windows NT 4.0 seemed a little haphazard, you're right. There is no easy way to define and apply all Registry, file system, network, and user/group policy changes. Even worse, there is no easy way to audit your changes to ensure that the policy changes have not been undone by intruders, installed software, or applied Service Packs.
With the release of Windows 2000, Microsoft introduced a wonderful set of snap-in tools for the Microsoft Management Console (MMC). The Security Templates Tool allows you to select, review, and even define custom security policy templates. The Security Configuration and Analysis Tool allows you to not only apply all those policies in one simple action, but it also allows you to audit those changes to see what has changed.
By default, the Security Templates Tool and Security Configuration and Analysis Tool are not visible in the MMC. Add those two snap-ins to manage your server's policies and settings.
There are many bundled security templates, including High Security for Workstations, as defined in the template HISECWS.INF. Additionally, Microsoft has made available a High Security Template targeted for Web servers. The security template includes most of the policy and Registry changes you made previously for Windows NT 4.0. The HISECWEB.INF security template is available from Microsoft at http://mssjus.www.conxion.com/download/win2000srv/scm/1.0/nts/hisecweb.exe. Copy the downloaded file to %WINDIR%\security\templates, and you can use it in the Security Templates Tool.
Take the time to browse through and read the individual templates using the Security Templates Tool or manually using a text editor such as WordPad. Read through the suggested changes to determine if they make sense for the deployment of your particular application. You can use the Security Templates Tool to develop your own security template using an existing template as a basis (see Figure 2). After you have a template that meets your needs, the next step is to do an analysis of how this will affect the server.
){kind=link}
Figure 2. Auditing the state of the server's security policies and settings using the Analyze Computer Now menu of the Security Configuration and Analysis Tool.
Use the Security Configuration and Analysis Tool to load your template, right-click Security Configuration and Analysis Tool, and select Analyze Computer Now. The findings will be displayed in the right-hand pane, showing you the template setting, the current server setting, and any inconsistencies. Review Findings, and, if necessary, adjust your template.
After you have tweaked the security template to include all the appropriate permissions, policies, Registry settings, and restrictions, right-click Security Configuration and Analysis Tool, and select Configure Computer Now. Sit back and watch the magic.
A nice command-line equivalent of the Security Configuration and Analysis Tool is available. SECEDIT can be used from the command-line to analyze, configure, refresh, and validate the server's current policy against your known template. This is convenient because it can be run from a Telnet session, not that you should be managing a server with an unencrypted remote session.
Secure or Disable telnetd Service
Be sure to disable the telnetd service. If you must allow Telnet into the box, be sure to restrict Telnet users to authenticated users of the TelnetClients group. Just create the TelnetClients group, add the users you want to grant Telnet access to, and the telnetd service automatically restricts Telnet access to TelnetClients group members.
Lock Down Your DNS Server
Restrict zone transfers to only authorized servers. Use the DNS Manager to modify the zone properties (see Figure 3). On the Notify tab, check the option Only Allow Access From Secondaries Included on Notify List. Be sure to protect primary zones as well as secondaries.
){kind=link}
Figure 3. Lock down the DNS server by restricting DNS Zone Transfers.
Unfortunately, the built-in DNS servers that come with Windows NT and 2000 do not have controls to restrict query requests. If you want to use this feature, you can use the ISC BIND (Internet Software Consortium Berkeley Internet Name Daemon) reference implementation that is used in most UNIX installations. You lose the integrated GUI administrative features, but you will have all the granularity and control available in the BIND implementation. The source code and binary packages can be found at the ISC site at http://www.isc.org/products/BIND/.
Application-Specific Hardening
Application-specific servers that reside on the firewall will need to run additional services that you are offering to the Internet population. Because there are numerous applications and an incredible combination of ways that those applications can be configured, it is well beyond the scope of this book to attempt to cover configuration of even common applications such as HTTP, FTP, and SMTP. If you do nothing else, however, remove the sample applications installed by default with IIS and the various components. Sample applications and directories are listed in Table 1.
Table 1: IIS Sample Application Install Locations
|
Application |
Installed Directory |
|
IIS |
\inetpub\iissamples |
|
IIS SDK |
\inetpub\iissamples\sdk |
|
Admin Scripts |
\inetpub\AdminScripts |
|
Data Access |
\Program Files\Common Files\System\msadc\Samples |
There are living documents that provide an excellent starting point for properly configuring the more common DMZ server application services:
In part two, we'll look at hardening your UNIX/Linux servers, protecting your firewalls and DMZ servers from common network attacks using TCP/IP options and features, and utilizing a centralized logging server.