ike the Windows desktop operating system, the Windows Server System suffers from its share of bad press
related to its security. Whether you think it's an inherent problem with the code, or whether you believe the
popularity of Microsoft's products makes them a target, the fact remains that the Windows Server System is a
Microsoft built its server software with many of the same goals of its desktop operating system. One of the keys of the Windows Server System's popularity is its ease of administration. But in trying to make computers easy to use, both the desktop and server operating systems leave some security gaps.
Microsoft made security a major priority of its Windows Server 2003 release. The company added a Common
Language Runtime software engine, which reduces the number of vulnerabilities for attackers to exploit. There's a
software-based firewall, a RADIUS server, and support for wireless security protocols. Other improvements include a
credential manager, increased Web server security, and software restriction policies.
In this guide we're going to examine how to make the most of the security features included as part of the Windows
Server 2003 System. (Windows Server 2003 is the current version of the system, and thus is our focus. For more
information on securing Windows 2000 servers using security templates, visit http://www.intranetjournal.com/win-
dows-servers/.) We're going to cover the use of software restriction policies in Windows Server 2003, highlight sim-
ple practices you can use to secure your system, discuss malware, and look at securing IIS and SQL Server.
Securing a Windows Server 2003 system can be a complex task, even though Microsoft provides the operating sys-
tem in a locked down state. There are still many security weaknesses and loopholes that can be exploited, and
while basic security measures like file permissions and password policies do a great job of making your server
secure, it's often the more obscure loopholes that allow unauthorized access to the system. Here are just a few sim-
ple strategies and practices that you can use to increase the security of your Windows Server 2003 system, and
subsequently your network.
Many Windows Server 2003 applications, such as Remote Desktop and Internet Information Server (IIS), use TCP/IP
ports to receive and send traffic. Changing the default port numbers used by these applications may be all that is
needed to thwart some of the more rudimentary worms, and less sophisticated attackers. In some cases, you can
change the default port number in the management tool that comes with the application. With other applications,
like Remote Desktop, you'll need to edit the registry.
What you change the port number of applications to is largely up to you, but make sure that you are not encroach- ing on a port used by another application. A complete list of port numbers used by Windows applications and serv- ices can help (there's one available at http://support.microsoft.com/default.aspx?scid=kb;en-us;832017), but there may be other, non-Windows (or Microsoft) applications on your server that use other port numbers.
By default, a Windows Server 2003 domain controller implements a basic set of logon auditing. However, if you
don't check the Security Event Viewer logs where related events are recorded, you'll have no way of knowing
whether there have been log-on related issues or not. Get into the habit of checking the Security Event Viewer log
on a weekly\u2013or even better, daily\u2013basis to look for occurrences that might be of concern.
Because of the function they perform on the network, domain controllers are worthy of extra attention when it
comes to security. Not only are hackers more likely to go after a domain controller because they hold the user
account information, they are also crucial to the operation of the network. For this reason, domain controllers make
an attractive target for a hacker who is trying to perpetrate a Denial of Service (DoS) attack.
If you have an environment with more than one server, consider not running any applications (other than Active Directory, of course) on your domain controllers. You can then implement a packet-filtering firewall so that only Active Directory related traffic is allowed to and from that server.
Each and every service that runs on a Windows Server 2003 system increases the attack surface of the system. Of course, many of the services are essential and should not be disabled. Others, though, can often be disabled with- out any negative effect on the operation of the server. Exactly which services you can disable will depend on what applications and functions the server is supporting. A server that is only providing file and print server services, for example, does not need the Routing or Remote Access Service, or the Remote Access Connection Manager serv- ice. Likewise, a server acting as a dedicated remote access gateway will most likely not need the Spooler service.
Be aware, though, that some services have dependencies, which means that they won't run unless another service is also running. If you do choose to disable unnecessary services, do it one service at a time, and keep an eye and ear out for any unexpected results.
The Microsoft Baseline Security Advisor (MBSA) is a free tool from Microsoft that will scan your Windows Server
2003 system for a range of vulnerabilities, including excessive permissions and accounts without a password. But
perhaps the most significant feature of MBSA is that it will scan the system to see what security updates have been
installed. It compares this list to one from Microsoft's Web site that details the updates available for the operating
system. Any updates that are not installed are flagged, and you can subsequently install them. In addition to your
server, you can scan Windows 2000 and Windows XP systems across the network.
You can download MBSA from Microsoft's site at
http://www.microsoft.com/technet/security/tools/mbsahome.mspx. Considering that MBSA is free, there really is no
good reason not to use it on a regular basis.
Considering the ease with which the Account Lockout Policy is configured, it is surprising at how many networks do
not have it configured. The Account Lockout Policy defines what actions the system will take if an incorrect pass-
word for a user account is entered more than a specified number of times. It is accessed through the Account
Policies Node of the Domain Security Policy, which you can access from the Administrative Tools menu.
The appropriate lockout policy will depend on the environment. A small business application without sensitive data
can be protected with a simple password. A large business application with sensitive data should use strong pass-
word policies and have account lockout enabled.
Again, a very basic measure, but you would be surprised at how many networks still have the Administrator user ID in place, relying instead on a complex password to secure the account. In reality, such measures are relatively inef- fective. The administrator account is purposely not covered by the Account Lockout policy mentioned earlier. For
Now bringing you back...
Does that email address look wrong? Try again with a different email.