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:
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.
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.
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.
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.
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:
Microsoft Windows NT 4.0 and IIS 4.0:
http://www.microsoft.com/technet/security/iischk.asp
Microsoft Windows 2000 Server and IIS 5.0:
http://www.microsoft.com/technet/security/iis5chk.asp
Microsoft
SQL Server:
http://www.microsoft.com/technet/SQL/Technote/secure.asp
and
http://www.sqlsecurity.com/faq.asp
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.