Although network administrators generally
focus on server-level security, which protects data stored on the
server itself, the administrators must keep in mind that the server
they are attempting to protect is connected to a local area network
(LAN), and usually the Internet, to allow it to function to its full
potential.
To properly protect a server
from attack, administrators should implement multiple layers of
defense, each reinforcing the other, and each specializing in repelling
certain types of attacks. Firewalls, network perimeters, accessibility
options for users, security policies, and more are integral components
that must be well designed and properly implemented to be effective.
A
phrase coined by the military, “defense in depth,” is used to describe
this strategy. Defense in depth increases a server’s security by
creating multiple layers of protection between the server and potential
attackers. An attacker who successfully maneuvers through the first
line of defense finds himself faced with a second challenge, one
requiring different skills and tools to bypass, and then a third, and
so on.
Hardening Windows Server 2003
Exchange
Server 2007 is designed to run on Windows Server 2003. No matter what
steps you take to secure your Exchange Server 2007 servers, if the
underlying operating system (OS) is not secure, the Exchange
installation is vulnerable to attack. Therefore, it is critical that
you secure Windows Server 2003 by utilizing a combination of your
organization’s security standards and industry best practices.
Layered Approach to Server Security
When
discussing security measures, whether server-level or transport-level,
protective measures work best when they are applied in layers. For
example, if a thief were to attempt to steal your car, it might not be
very challenging if all they had to do was break the window and
hot-wire the vehicle. However, if you were to add a car alarm, or
install an ignition block that requires a coded key, the level of
difficulty is increased. Each of these obstacles takes additional time,
as well as additional skill sets, to overcome.
This
same principle applies to both server- and transport-level security
methods. By applying multiple layers of security, you can effectively
decrease the likelihood of a malicious user successfully tampering with
your systems.
Many security features are already built in to Windows Server 2003. Among these are the following:
Kerberos authentication—
Windows Server 2003 uses the Kerberos version 5 authentication protocol
to provide a mechanism for authentication between a client and a
server, or between two servers.
NTFS file security—
Utilizing the NTFS file system provides improved performance and
reliability over traditional file allocation table (FAT) file systems.
NTFS has built-in security features, such as file and folder permissions and the Encrypting File System (EFS).
Windows
Server 2003 also includes built-in security tools and features to help
secure your environment. Among these are object-based access control,
automated security policies, auditing, Public Key Infrastructure (PKI),
and trusts between domains.
Physical Security Considerations
The
first layer of security for any server, and one that is often
overlooked, is preventing physical access to the computer. It takes
very little skill or knowledge to simply unplug a computer or to remove
it from the network; however, this could have a serious impact on your
environment even if the intruder was not able to access your data. In
addition, just as security professionals have tools and utilities to
assist with the defense of computer systems, hackers have tools and
utilities to assist them with their attacks. If a hacker can get
physical access to a server, he can use a variety of methods to
circumvent basic password security.
At a minimum, servers should be physically secured behind locked doors, preferably in an environmentally controlled area.
Some common physical security methods are the following:
Configure the server BIOS so that it will not boot from a floppy disk drive or CD-ROM.
Password protect the BIOS so that it cannot be reconfigured.
Lock the server case to prevent access to the BIOS jumpers on the motherboard.
Enclose the server in a locked cage or locked room that has limited access.
Restricting Logon Access
All
servers should be configured so that only administrators can log on
physically to the console. By default, Exchange Server 2003 does not
allow any members of the domain users group local logon privileges.
This prevents nonadministrators from logging on to the server even if
they can gain physical access to the server.
Auditing Security Events
Auditing
is a way to gather and keep track of activity on the network, devices,
and entire systems. By default, Windows Server 2003 enables some
auditing, but there are many additional auditing functions that must be
manually turned on to be used. This control allows your system to
easily be customized to monitor those features that you desire.
Although
the primary use of auditing methods is to identify security breaches,
this feature can also be used to monitor suspicious activity and to
gain insight into who is accessing the servers and what they are doing.
Windows Server 2003’s auditing policies must first be enabled before
activity can be monitored.
Auditing Policies
Audit
policies are the basis for auditing events on a Windows Server 2003
system. Bear in mind that auditing can require a significant amount of
server resources and can potentially slow server performance,
especially if the server does not have adequate memory or CPU bandwidth
available. Also, as more and more data is collected by auditing
policies, it can require a significant amount of effort to evaluate.
Administrators should be cautious, as gathering too much data can
sometimes be overwhelming, effectively diminishing the desired
benefits. As such, it is important to take the time to properly plan
how your systems will be audited.
Audit
policies can track successful or unsuccessful event activity in a
Windows Server 2003 environment. These policies can audit the success
and failure of events. The types of events that can be monitored
include the following:
Account logon events—
Each time a user attempts to log on, the successful or unsuccessful
event can be recorded. Failed logon attempts can include logon failures
for unknown user accounts, time restriction violations, expired user
accounts, insufficient rights for the user to log on locally, expired
account passwords, and locked-out accounts.
Account management—
When an account is changed, an event can be logged and later examined.
Although this pertains more to Windows Server 2003 than Exchange Server
2007, it is still very relevant because permissions granted in Active
Directory can have an effect on what data or services an individual has
access to in Exchange.
Directory service access—
Whenever a user attempts to access an Active Directory object that has
its own system access control list (SACL), the event is logged.
Logon events— Logons over the network or by services are logged.
Object access— The object access policy logs an event when a user attempts to access a resource such as a printer or shared folder.
Policy change—
Each time an attempt to change a policy is made, the event is recorded.
This can apply to changes made to user rights, account audit policies,
and trust policies.
Privilege use—
Privileged use is a security setting and can include a user employing a
user right, changing the system time, and more. Successful or
unsuccessful attempts can be logged.
Process tracking—
An event can be logged for each program or process that a user launches
while accessing a system. This information can be very detailed and
take a significant amount of resources.
System events— The system events policy logs specific system events, such as a computer restart or shutdown.
The audit policies can be enabled or disabled through either the local system policy or Group Policy Objects (GPOs).
To
open the Group Policy Object Editor, which is a snap-in to the
Microsoft Management Console (MMC), perform the following steps:
1. | Click Start, Run, type MMC in the Open text box, and click OK.
|
2. | In the MMC Console, click File, Add/Remove Snap-in.
|
3. | On the Add/Remove Snap-in page, click Add.
|
4. | Select the Group Policy Object Editor, and then click Add.
|
5. | Under
the Group Policy Object section, click Browse, and select the default
domain policy. Click OK to continue, and then click Finish.
|
6. | Close
the Add Standalone Snap-in page by clicking Close, and then click OK to
continue. On the Mail Flow Setting tab, select Message Delivery
Restrictions and click Properties.
|
7. | Check the Accept Messages: From Authenticated Users Only check box.
|
Audit policies are located within the Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy folder of the Group Policy Object Editor, as shown in Figure 1.
