Server Hardening
Server Hardening
Server hardening consists of creating a baseline for the security on your servers in your
organization. The default configurations of a Windows Server 2003 computer are not designed
with security as the primary focus. Rather, a default installed computer is designed for
communication and functionality. To protect your servers, you must establish solid and
sophisticated security policies for all types of servers in your organization.
In this section, we will discuss the basic security baseline for a member server that is running in
a Windows Server 2003 Active Directory domain. We will also discuss the best-practice security
configurations in the security templates, starting with the generic best practices that apply to
most member servers in the organization. We will then move on to the specific types of member
servers, as well as domain controllers. We will discuss which services, ports, applications, and so
forth need to be hardened for different server roles, and compare this to the baseline security for
simple member servers.
c
Member servers
Domain controllers
File and print servers
Web servers
You must establish a baseline of security for all members servers before creating additional
security templates and policies to tailor security for specific types of servers. One of the most
important aspects of applying hardening settings to member servers is developing the OU
hierarchy that will support the security template and policies that you develop. You must also
understand the various levels of security that are routinely used to develop and deploy security to
all servers.
The only way to efficiently and successfully deploy security to the different server roles in your
enterprise is to design Active Directory to support those roles. The design should not only
provide an efficient method to deploy security, but it should also organize the computer accounts
into OUs for easier management and troubleshooting.
Although Active Directory design is extremely flexible, you must consider a number of factors
when organizing servers into OUs based on server role. The first factor is Group Policy
application. For example, if you have two server roles that each need different security policy
settings, you should separate the computer accounts into different OUs. The second factor is
administration of the computer accounts within Active Directory. Even though you have only
two different server roles, you might have two different administrators controlling the same type
of server role. This might force you to have OUs not only for server roles, but also for server
roles based on the administrator in charge.
Figures 5-7 illustrates an OU structure that does not consider location or administrative needs but
does consider server roles. Figure 5-8 illustrates an OU structure that has a different set of
administrators for the Main Office and Branch Office, where each office also has the same types
of server roles.
!
" #
$% OUs are also commonly organized by physical location -- for example, the Main Office
and Branch Office model. For more information on organizing OUs based on GPO
deployment, see Chapter 4.
Member server security environments are based on the operating systems of the clients and
servers in your enterprise. Legacy clients and servers can't take advantage of the robust features
and functions that Active Directory provides, such as Group Policy, Kerberos, and other security
features. As the operating systems of domain members rise to levels that support all Active
Directory functions and features, it becomes possible to raise the overall security for the
enterprise and thus create a solid security environment.
There are three different security environment levels typically found in an enterprise
environment:
D
! When you have a mixed operating system environment of new and older
versions, you must provide adequate security that will not constrain the operation of
legacy clients. This is the lowest security level, but it needs to be that way for
communication to occur and legacy applications to work properly. This business
environment might include legacy clients such as Windows 95, Windows 98, or
Windows NT 4.0 Workstation. You should limit this environment to having only
Windows 2000 Server and Windows Server 2003 domain controllers. You should not
support Windows NT 4.0 Server domain controllers, although you can have Windows NT
Server computers configured as member servers.
D & This security level removes the legacy operating systems and uses
only those that support the features and functions that Active Directory offers. This
includes clients running Windows 2000 Professional and Windows XP Professional.
These clients all support Group Policy, Kerberos authentication, and new security
features that the legacy clients don't support. The domain controllers must be Windows
2000 Server or later. There will not be any Windows NT Server computers, even as
member servers.
D · c ! This security level is basically the same as for Enterprise Client -- it
changes only the level of security that is implemented. This level enhances security
standards so that all computers conform to stringent security policies for both clients and
servers. This environment might be constrictive enough that loss of functionality and
manageability occurs. However, this must be acceptable because the higher security
levels are a good tradeoff for the functionality and manageability that you are losing.
This section will cover some common security settings that apply to standard member servers in
the domain. These settings are best created in a GPO that is then linked to the top-level server
OU. In Figure 5-7 or 5-8, this would be the Member Servers OU.
Table 5-7 provides a full list of security settings for a member server.
Account Policies, which include Password Policy, Account Lockout Policy, and
Kerberos Policy, are not specified in the member servers security baseline outlined here. This
is because Account Policies must be defined at the domain level in Active Directory, while the
member servers security baseline is defined in GPOs linked to OUs where member servers are
found. For best practices concerning domain Account Policies, see "Account Policies" under
"Sections of the Security Template" earlier in this chapter, and also refer to the á
described in the "Windows Server 2003 Security Guide" sidebar.
For a member server to function on the network with other computers, specific ports must be
opened. Table 5-8 presents a list of those critical ports. As we investigate specific server roles,
additional ports will need to be added to ensure the server functions properly.
"%-
% 0 &
137 (NetBIOS name Used by the browse master service. This must be open
service) for WINS and browse master servers.
Must be open to accept inbound datagrams from NetBIOS
138 (NetBIOS datagram
applications such as the Messenger service or the
service)
Computer Browser service.
Must be closed unless you run applications or operating
systems that need to support Windows networking (SMB)
139 (NetBIOS session
connections. If you run Windows NT 4.0, Windows
service)
Millennium Edition, Windows 98, or Windows 95, this
port must be open on your servers.
Used by basic Windows networking, including file sharing,
445 (CIFS/SMB server)
printer sharing, and remote administration.
3389 (Remote Desktop Must be open if you are using Terminal Services for appli-
Protocol) cation sharing, remote desktop, or remote assistance.
Return to Table of
0 Contents
Domain controllers are the heart of any environment that runs Active Directory. These
computers must be stable, protected, and available to provide the key services for the directory
service, user authentication, resource access, and more. If there is any loss or compromise of a
domain controller in the environment, the result can be disastrous for clients, servers, and
applications that rely on domain controllers for authentication, Group Policy, and the LDAP
directory.
Not only should these domain controllers be hardened with security configurations, they must
also be physically secured in locations that are accessible only to qualified administrative staff. If
domain controllers are stored in unsecured locations due to limitations of the facility (such as in a
branch office), you should apply additional security configurations to limit the potential damage
from physical threats against the computer.
Security settings that apply specifically to domain controllers are best created in a GPO that is
then linked to the Domain Controllers OU. The settings for domain controllers should be based
on those we reviewed in the earlier "Member Servers" section. Of course, a domain controller
also has additional functions or features compared to a member server, and this requires
additional open ports and security configuration. You must review the security settings list to
ensure that you are not restricting a key feature for your domain controller.
Table 5-9 lists the settings that differ from those specified in Table 5-7. In other words, the
baseline security settings for domain controllers as outlined below should be incrementally added
to the baseline security settings for member servers described previously.
Domain controllers are responsible for specific functions, as seen in the different settings listed
in Table 5-9. Many of these different security template settings are due to required services to
authenticate users and maintain consistency of the Active Directory database between other
domain controllers. Table 5-10 lists additional ports that you must open for domain controllers.
2*%-
% 0 &
The Kerberos protocol is used by Windows 2000 and later
88 (Kerberos) operating systems to log on and retrieve tickets for accessing
other servers.
This port provides time synchronization for network clients
123 (NTP)
using the Network Time Protocol (NTP).
135 (RPC endpoint This port allows RPC clients to discover the ports that the RPC
mapper/DCOM) server is listening on.
This port the primary way that clients access Active Directory
389 (LDAP) to obtain user information, e-mail addresses, services, and
other directory service information.
464 (Kerberos This port provides secure methods for users to change
Password Changes) passwords using Kerberos.
This port is needed if LDAP will use SSL to provide
636 (LDAP over SSL) encryption
and mutual authentication for LDAP traffic.
This port provides the means for clients to search Active
3268 (Global Catalog)
Directory information that spans multiple domains.
3269 (Global Catalog This port is needed because the Global Catalog uses SSL to
over SSL) provide encryption and mutual authentication for Global
Catalog traffic.
If your domain controller is running DNS, you will need to also open port 53.
&
File and print servers are responsible for resource storage and controlling access to these
resources throughout the enterprise. These servers house the company's documents, trade secrets,
financial data, and much more. If these computers are not protected, the entire company might be
in jeopardy. These computers must be stable, protected, and available to provide users and
applications access to resources stored on these computers.
Like the domain controllers, these servers must be physically protected. If someone were to get
hold of a file server, they could potentially use other tools to gain access to the resources on the
server. You should take action to protect against this.
Table 5-11 lists security settings for file and print servers that differ from the settings in the
Member Servers section earlier in the chapter. In other words, the baseline security settings for
file and print servers as outlined here should be incrementally added to the baseline security
settings for member servers described previously. These settings are best created in a GPO that is
then linked to the OU that contains the file servers.
.$ For more information on hardening file and print servers in different
enterprise environments, see the á
.
(
Microsoft Internet Information Services (IIS) is the service that provides Web services on a
Windows server. Web servers must be properly secured from malicious attackers, while still
allowing legitimate clients to access intranet or public Web sites hosted on the server.
IIS is not installed by default on the Windows Server 2003 family of servers, and when you do
install IIS, it installs in "locked" mode -- a highly secure mode that protects IIS against threats.
Beyond the best-practice security settings presented in this section for IIS, be sure to protect your
Web servers by monitoring security using some form of intrusion detection system, and by
implementing proper incident response procedures.
Security settings for Web servers are best created in a GPO that is then linked to the OU that
contains the Web servers. Table 5-12 lists only the settings that differ from those in the Table 5-
7. In other words, the baseline security settings for Web servers as outlined here should be
incrementally added to the baseline security settings for member servers described previously.
.$ For more information on hardening Web servers in different enterprise
environments, see the á
.
Web servers should have limited ports available, to reduce their exposure to attacks from the
local network and the Internet. The fewer the ports that are open, the better. Table 5-13 is a list of
additional ports that you will need to open for Web servers.
2+%-(
% 0 &
The standard HTTP port for providing Web services to users. This
can be easily changed and is not required. If you do change the port
80 (HTTP)
for HTTP, be sure to add that new port to this list and configure
that
setting within IIS.
Allows HTTP to have a higher level of security that provides
443 (HTTPS) integrity,
encryption, and authentication for Web traffic.