Securing Your Windows Server Systems

Securing Your
Windows Server
Systems
a Jupiterweb Security eBook

™
Securing Your Windows Server Systems
ike the Windows desktop operating system, the Windows Server System suffers from its share of bad press
L 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
popular choice for server computing for small businesses and large enterprises alike.
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.
Eight Steps to a More Secure Windows 2003 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.
1. Change Port Numbers
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.
2. Check Logon Auditing
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–or even better, daily–basis to look for occurrences that might be of concern.
1 Securing Your Windows Server Systems, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
3. Isolate Domain Controllers
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.
4. Disable Unnecessary Services
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.
5. Run MBSA Regularly
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.
6. Configure Account Lockout Policy
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.
7. Rename the Administrator Account
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
that reason, a hacker who gains access to the system can try as many passwords on the Administrator account as
they like without triggering a lockout. Renaming the account will make this, the most important of accounts, consid-
erably less vulnerable as an attack point. Also, remember to change the password for the Administrator account (or
whatever you have renamed it to) on a regular basis, and always use a complex password.
8. Password Protect Backups
Whether you use the back-up utility that comes with Windows Server 2003 or a third-party product, password pro-
tecting your backups is a simple way to provide an increased level of protection for your data. Backups represent a
big risk because they often contain a complete set of data from your server. If the backup media were to be lost or
stolen, there is little to prevent someone from examining the tape and looking at the data. The need for backup
security is even more acute than normal if, as you should, you store backup tapes offsite for disaster recovery pur-
poses.
How Software Restriction Policies Work

Some of the most significant threats to your network's security and stability come from worms and trojan malware.
These network threats can be transmitted through executable files attached to e-mails, via Internet downloads, or
from Web pages. Although virus checkers are increasingly effective at protecting against threats embedded in exe-
cutable files, there are still other measures you can use to protect the systems on your network. One of the most
effective is to simply prevent people from opening unknown executable files in the first place. Windows Server 2003
provides a feature called Software Restriction Policies that allows you to do just that.
In simple terms, Software Restriction Policies allow you to define what applications can or cannot be run on a com-
puter. The restrictions are configured and applied through Group Policy, so there is no additional software to install,
nor is there any major reconfiguration of Active Directory.
First we're going to examine how you can use software restriction policies to provide an additional level of protection
to your network. Then we'll look at how you go about configuring and implementing software restriction policies on
your network.
Policies can be applied in one of two modes - "unrestricted" or "disallowed." After configuring the default mode for
the policy, you can then create exceptions for software you do or do not want to run.
For example, if you configure a software restriction policy with a default level of "unrestricted," you can configure
exceptions that define those kinds of applications you don't want users to run. Conversely, if you configure a default
level of "disallowed," you can specify exceptions for the applications you do want users to run. As you can imagine,
the "disallowed" setting involves considerably more administrative overhead than "unrestricted," but it also provides
a much more restricted, and thus secure, environment.
Which applications can be run in a "disallowed" environment, or cannot be run in an "unrestricted" environment, are
defined through a set of rules. These rules provide different evaluation criteria by which a file that is attempting to be
opened can be evaluated. There are four types of rules that can be created–hash, certificate, path, and Internet
zone. Each takes a different approach to determining whether a file will be permitted or prevented from running.
Hash Rule
The hash rule works by using a hashed value of the executable file as criteria to determine if it should run. When an
attempt to start the executable is made, the hash value for the file is calculated and compared to the hash value
stored when the rule was created. If the two match, then the file is allowed or disallowed based on the default secu-
rity level that is configured. If the hash value does not match because, for example, a virus has infected it since it
was created, the hash values won't match and the file will be pre-
vented from opening.
"Secure by Default" is one of the slogans describing
Microsoft's design strategy applied to Windows
Certificate Rule
Server 2003 and IIS 6.0, in particular. Unlike previous
versions, which favored ease of use and out-of-the-
Certificate rules use digital certificates to determine whether or not box functionality over security, the new version of
a file should be allowed to open. The certificate you use for the the Web server requires the admin to do some extra
rule must be supplied to you by the software creator, and is then work to get all the features needed.
used to verify the validity of the executable when you attempt to
use it. Like the hash rule, a certificate verifies that the software To begin with, the IIS 6.0 component is not installed by
has not be altered or manipulated since it was created. default (with the obvious exception of Windows 2003
Web Server Edition). However, adding it is as easy as
in the past, with the Add/Remove Programs Control
Path Rule
Panel applet (IIS is listed as subcategory under
Application Server item). Upgrade behavior has also
The path rule uses the location from which the executable is been modified. World Wide Web Publishing service is
launched as the criteria for determining whether access is permitted. disabled after upgrade from Windows 2000, as long as
For example, if you were using the "disallowed" default rule, you the IIS is configured with default settings.
could provide access to certain folders from which users are permit-
ted to run an executable file. An attempt to run a file from another The default installation allows only static Web pages
location would be blocked. To increase the flexibility of path rules, to be served. If the goal is to provide other functionali-
you can use folder variables such as %windir% and %userprofile%. ty, you must install and enable it manually. This
includes features related to serving dynamic Web con-
tent, such as Active Server Pages and Server Side
Internet Zone Includes, as well as these simplifying development
and Web server management, such as FrontPage
The Internet zone rule uses the zones defined in Internet Explorer Server extensions and Web Distributed Authoring and
to identify from where a file is retrieved, and then determine Versioning (WebDAV). In addition, by default, all
whether a file can be executed. To view the zones and get an unknown ISAPI and CGI extensions are prohibited. To
idea of locations and objects included in each zone, open Internet modify this setting, use the Web Services Extensions
Explorer and click Tools --> Internet Options. Then choose the node in the IIS Managers MMC snap-in.
Security tab.
Like the previous version, IIS 6.0 offers two graphical
interfaces for managing Web servers -- via Internet
By configuring rules based on Internet zones, you can override Information Services Manager MMC snap-in and via
the default setting for the Software Restriction Policy on executa- IIS Administration Web site. The first one is available
bles obtained from that zone. So, for example, if you configured as soon as the World Wide Web Service component
an Internet zone rule when the default security level was "unre- is installed; the second one requires the installation
stricted," any software run directly from the Internet, perhaps as of the Remote Administration (HTML) item listed as
part of a Web page, could be prevented from running. It should one of the subcomponents of World Wide Web
be noted, though, that at this time only Windows Installer pack- Service in the Windows Components Wizard (which
ages are covered by Internet zone rules. is invoked by running the Add or Remove Programs
Control Panel applet). Once the installation is com-
pleted, you can administer the Web server remotely
In some cases it is possible for an executable file to be subjected by connecting from a Web browser to https://server-
to more than one rule. When this happens, the rules are applied in name:8098.
order starting with the hash rule, followed by the certificate rule,
then the path rule, and finally the Internet zone rule. More significant from an administrative point of view is
the ability to control the installation of the IIS compo-
Another configurable aspect of Software Restriction Policies is the nent with Windows 2003 Group policies. The relevant
specification of what files types are covered by the policy. By setting is located in the Computer Configuration -->
default a wide range of executable files types such as BAT, COM, Administrative Templates --> Windows Components --
> Internet Information Services container.
VBS, EXE, and MSI are included. You can choose to add or
remove file types as needed. The advantage of a configurable list --Marcin Policht, ServerWatch
is that as new programs become available or new threats are
identified, you can add that file type to the list.
A Word of Caution
It should go without saying that implementation of Software Restriction Policies should only take place after consid-
erable testing. The basic premise behind the technology is that it prevents people from opening files that they
shouldn't. With this comes the inherent risk that a misconfiguration will result in people not being able to open files
that they need.
Also keep in mind that many complex applications, like Microsoft Office, invoke other smaller applications or compo-
nents as they run. As a result, you should test all aspects of an application, not just the main program.
Although the implementation of Software Restriction Policies can require a reasonable amount of administrative
overhead, particularly on a large network, there are few other methods of providing such comprehensive control
over what applications can be run and from where.
We're going to look at the basic configuration process, and you can take the information provided here and use it as
platform from which to plan your own software restriction policy deployment.
Getting Down to Business
To start the configuration process for a software restriction policy, first locate a group policy object (GPO) on a site,
domain, or organizational unit for which you want to configure a policy. For the purposes of our demonstration, we'll
configure the software restriction policy for computers within an organizational unit (OU). You can either use the
properties of an existing GPO for your chosen object, or create a new GPO specifically for your software restriction
policy. Creating a new GPO is a good idea, because if you have a problem with the policy settings, you can simply
disable the entire GPO without affecting any of your other group policy settings.
The software restriction policies node of the GPO is located under Computer Configuration --> Windows Settings --
> Software Restriction Policies. When you first open the GPO to the software restriction policies node, you will see
the screen shown in Figure 1.
As you can see, there are no policies assigned by default. To create a policy, right click the Software Restriction
Policies node and select New Software Restriction Policies from the menu. After the policy is created, you will see
the screen shown in Figure 2.
Figure 1 Figure 2
The first step in configuring your actual Figure 3

software restriction policy is to set the
default security level from within the
Security Levels subfolder. A black circle
with a tick mark, as shown in Figure 3,
indicates the currently selected security
level. As you can see the level is set to
"Unrestricted," which is the default.
After configuring the default security

level, you can now set up the excep-
tion rules. As mentioned earlier, the
exception rules determine which soft-
ware will be allowed to run if the default
level is "Disallowed," or not to run if the
default security level is set to
"Unrestricted." For the purposes of this
Figure 4
discussion, we'll leave the level as
"Unrestricted," and configure an excep-
tion that will prevent a specific applica-
tion from running.
Creating an Exception Rule
The rule creation process is very

straightforward, so for the purposes of
this discussion we'll just look at creat-
ing a hash rule.
To create a hash rule, first locate the

"Additional Rules" subfolder under
Software Restriction Policies node. As
you can see in Figure 4, a number of
path rules are created by default. Figure 5
Right-click the "Additional Rules" subfolder and select New Hash

Rule from the menu. The "New Hash Rule" dialog will appear. For our
new rule, we'll prevent the Calculator program (Calc.exe) from being
run.
First, use the Browse button to find the executable associated with
the file you want to block. When you have selected the file, the hash
value of the file is created and listed in the "File Hash" field. In addi-
tion, properties like the name, version, etc. of the file will automatically
appear in the "File Information" field. The completed rule should look
like the own shown in Figure 5. Once you click OK, the exception rule
will be created.
The process for creating the other rules is essentially the same,
though in each case you configure the appropriate criteria (certificate,
path, or Internet zone name) for each of the respective rules. Once
you have configured all of the required exceptions, you Figure 6

are ready to configure the Enforcement rules, and the
Designated File Types.
Enforcement rules, which again are configured from with-

in the software restriction policies node, allow you to
configure whether local administrative users are exempt-
ed from the policies, and also to define whether library
files (such as dynamic link libraries [DLLs] are included in
the policy. The key consideration here is that if you do
include DLLs, and the default rule is "Disallow," you will
need to create an exception for each and every DLL
associated with the applications you use. Considering
that a single application can have hundreds of associated
DLLs, this would be a daunting task. Alternatively, you
can exclude DLLs from the rule. This means you only
need to concerned with the applications themselves. You
can see the "Enforcement" configuration dialog in Figure
6.
Designated File Types

Like enforcement rules, the "Designated File Types" dia-
log is accessed through the main software restriction
policies node. The configurable list allows you to specify
the types of files that will be affected by the software
restriction policy. This list is of less concern if you are Figure 7
using the Unrestricted default security level, as the
exceptions explicitly define what applications cannot be
run.
In contrast, when using a default security level of disal-

lowed, the designated file types list becomes critical, as it
determines whether or not an application is subjected to
the software restriction policy. The default list of file types
is very comprehensive, but if you do want to add or
remove a file type you can do that from within the
"Designated File Types" dialog shown in Figure 7.
Once you have completed your configuration, you can

test your policy by attempting to run the blocked applica-
tion. Remember, though, that as software restriction poli-
cies are applied through Group Policy, you must either
wait for the policy to be refreshed automatically, or trigger
a manual update using the Gpupdate.exe command line
utility. If the policy is configured correctly and refreshed,
an attempt to run a blocked application will result in an
error message like the one shown in Figure 8 (next page).
As we discussed earlier, implementation of software

restriction policies should only be completed after exten-
Figure 8
Windows Server Longhorn is Microsoft's next-genera-

tion server platform, now slated for release in 2007.
The most notable new features to be included concen-
trate on enhanced security and performance. New
Longhorn features in the queue are "secure-at-
install," which is designed to help secure new installa-
tions of the operating system by automatically finding
and applying security updates, and a "self-healing"
filesystem in which the system will fix itself on the fly
(e.g., if there is a bad sector on a hard disk). "Self- sive testing. However, even the most comprehensive test may
healing" means Microsoft's defrag and chkdsk tools hide an issue that becomes immediately apparent in a live environ-
are always running in the background. ment.
Network Access Protection (NAP) is a new policy If you do find yourself experiencing problems, an easy way to get
enforcement platform in Windows Server Longhorn.
around the software restriction policy is to reboot into safe mode.
Network Access Quarantine Control, currently part of
Windows Server 2003, is not the same as Longhorn's The policies are not applied in safe mode, so at the very least you
NAP. Network Access Quarantine Control provides only will be able to determine whether or not it is the policy that is
added protection for remote access connections. In causing a problem. If the problem appears to be with the software
contrast, NAP provides added protection for virtual pri- restriction policy, consider disabling the GPO. As discussed earlier,
vate network (VPN) connections, Dynamic Host this is much easier to do if you have created a separate GPO for
Configuration Protocol (DHCP) configuration, and the software restriction policy.
Internet Protocol security (IPsec)-based communica-
tion.
Locking Down IIS
NAP prevents unpatched devices from accessing the
network. When a machine connects to the network, and SQL Server
NAP performs a health check to make sure the system
has the required security patches, virus signatures, Let's now cover some very specific recommendations for locking
firewall, and so on. If it doesn't, NAP can redirect the down IIS and SQL, both of which are often a large part of
device to a quarantined network, where update Windows-based distributed application environments.
servers either bring the PC into compliance and allow
it onto the network or keep it quarantined.
IIS Specific Security Configurations
Windows Server Longhorn has the following enhance-
ments compared to the current Windows Firewall: There is a programming 'hook' in IIS known as ISAPI that associ-
ates files having certain extensions with DLLs. These are known
• Supports both incoming and outgoing traffic as ISAPI extensions.
• New Microsoft Management Console (MMC) snap-in
for graphical user interface configuration ISAPI extensions handle functions such as Active Server Pages,
• Firewall filtering and Internet Protocol security .NET Web services, and Web-based printer sharing. However,
(IPsec) protection settings are integrated many of these extensions are not required, particularly if you're still
• Exceptions that can be configured for Active
using IIS 5.0 or earlier. The problem is that many of those exten-
Directory directory service accounts and groups,
source and destination IP addresses, IP protocol num- sions (filters) are exploitable. The notorious Code Red is an exam-
ber, source and destination Transmission Control ple of just one malicious program that takes advantage of these
Protocol (TCP) and User Datagram Protocol (UDP) extensions. Enable only the ISAPI extensions the Web server and
ports, all or multiple TCP or UDP ports, specific types application need, and restrict the HTTP options that can be used
of interfaces, Internet Control Message Protocol (ICMP) with each extension by visiting Server Properties J WWW Service
and ICMP for IPv6 (ICMPv6) traffic by Type and Code, J Edit J Home Directory tab J Configuration.
and for services.
Most IIS installations include some sample applications and
-Deann Corum, ServerWatch
scripts that are designed to demonstrate the functionality of the
Web server. They are not designed to operate securely, particularly
in Version 5.0 or earlier. These can be exploited to allow overwriting of files or remote viewing, and even remote
access to other sensitive server information, such as system settings and paths to binaries. You should at least
remove the /InetPub/iissamples directory prior to putting any IIS server into production, and either remove, move or
restrict access to the /InetPub/AdminScripts directory. The IIS Lockdown Tool, which you can find at
http://www.microsoft.com/technet/security/tools/locktool.mspx, is very useful for tightening IIS security.
Any Web server installation that is not kept patched and up to date is a prime target for malicious activity. Regular
and timely patching of publicly accessible Web servers is crucial.
Web add-ons such as ColdFusion and PHP can introduce vulnerabilities in a Web server installation too. Carefully
configure these and check the source Web sites and latest security bulletins for any needed patches or new exploits
in these add-ons.
IIS Security Checklist
1. Apply the latest operating system service packs and security updates for IIS and any applications loaded on
the same host. Consider using Automatic Updates to automatically install patches.
2. Install host-based antivirus and intrusion detection software. Keep them current on patches and review the
log files frequently.
3. Disable unused script interpreters and remove their binaries. For example: perl, perlscript, vbscript, jscript,
javascript, and php.
4. Use logging and review the logs frequently, preferably through an automated process that summarizes the
events and reports exceptions and suspicious events.
5. Remove or restrict system tools commonly used by attackers to compromise a system. For example;
tftp(.exe), ftp(.exe), cmd.exe, bash, net.exe, remote.exe, and telnet(.exe).
6. Limit the services running on the Web server to the HTTP service and its supporting services.
7. Be aware of and minimize any type of connection into the inner network that enter through public Web serv-
er(s). Disable File and Printer Sharing and NETBIOS name resolution on Internet-facing systems.
8. Use a separate DNS server in a DMZ to service Internet-facing Web servers. Direct any unresolvable queries out-
side the DMZ to other public DNS servers or those of your service provider -- never to your internal DNS servers.
9. Use different account naming conventions and unique passwords on public facing systems than on internal
systems. Internet-facing IIS servers should be in a DMZ behind a firewall, with a second firewall between the
DMZ and the internal network. Internet-facing IIS servers should not be part of an internal Active Directory (AD)
domain or use accounts that are part of an internal AD domain.
10. Block all TCP ports to the DMZ except 80 or 443, if needed.
11. Install the operating system on one drive and Web sites on a different drive to help thwart directory traversal
attacks.
12. If you must use RDP (Terminal Services, Remote Desktop Protocol) to administer the server, change the
default port of 3389 to something else hackers won't be looking for. (See Microsoft Knowledge Base Article
187623 for details)
Tools for Securing IIS
Use Windows Update and Automatic Updates for single-server installations. Use Systems Management Server
(SMS) or Windows Server Update Services (WSUS) for managed environments or where administrators that have
responsibilities for multiple disparate systems. MBSA, which we mentioned earlier, assists the system administrator
in scanning local or remote systems for current patches. This tool works on Windows NT 4, Windows 2000,
Windows XP, and Windows 2003.
Use the IIS Lockdown Tool or Security Configuration Wizard (SCW) to harden your IIS installation and server. Use
URLScan to filter HTTP requests. URLScan is part of the IIS Lockdown Tool and can be configured to reject mali-
ciously formed HTTP requests, such as those in Code Blue and Code Red, before the server even attempts to
process them.
Download these tools to another machine and copy them to your IIS server before connecting it to the Internet.
Avoid connecting your IIS server to the Internet until it is completely analyzed and patched.
SQL Specific Security Recommendations
The most widespread SQL attack isn't even covered by a security bulletin. It's a straightforward login attempt made
on the SA account with a blank password. Microsoft SQL Server installs with a blank SA account password by
default and this should be the first thing you change.
Another common cause of the blank password is products. For example, some versions of Visio install Microsoft
SQL Server 2000 Desktop Engine (MSDE) and never change the SA password. A user may not even know that they
have MSDE running.
SQL Server Security Checklist
1. Set a password on your SA account and restrict its use. Also, change the password periodically to keep it
from propagating and being used by developers or too many administrators. Change the SA password if any-
one who knows it leaves the company.
2. Place your SQL Server behind a firewall, separate from your IIS or Web servers. Only allow connections to the
SQL server from those designated Web servers. Your SQL server should never be Internet-facing or publicly
accessible.
3. Remove BUILTIN/Administrators from the sysadmin role and give sysadmin rights in SQL to specific domain
accounts that need it.
4. Use Windows Authentication and Windows Only Mode if possible. This way, a potential hacker must authenti-
cate to the domain first instead of just to SQL Server.
5. Do not run SQL Server on a Domain Controller.
6. Change the SQL Server service start-up account to something besides LocalHost.
7. Enable the Failed Login option (Server Properties J Security tab) so you can look for failed logins to see if an
unauthorized person is trying to access the server. Monitor the SQL logs and set up alerts in SQL using NET-
SEND or email, if possible.
8. Keep up to date on patches and service packs for the operating system and SQL. See Tools for Securing IIS
for some options.
9. Protect any Extended Stored Procedures. Control all data access through stored procedures and grant
access to those instead of giving blanket db_datareader and db_datawriter permissions to the data itself.
10. Change the standard SQL Server port under the Server Network Configuration Utility and block the default
port of 1433. Have your network administrator allow the new port instead.
11. Make sure the Everyone group doesn't have write access to SQL Server registry keys.
This content was adapted from EarthWeb's Enterprise Networking Planet Web site. Contributors: Drew Bird and
Deann Corum.
Copyright 2006 Jupitermedia Corp.
JupiterWeb eBooks bring together the best in technical information, ideas and coverage of important IT trends
that help technology professionals build their knowledge and shape the future of their IT organizations. For more
information and resources on IT security, visit any of our category-leading sites:
www.esecurityplanet.com
www.antionline.com
www.internetnews.com/security
www.earthwebnews.com/security
www.enterpriseitplanet.com/security
www.insideid.com
www.smallbusinesscomputing.com
www.linuxtoday.com/security/
For the latest live and on-demand Webcasts on IT security, visit: www.jupiterwebcasts.com/security

Securing Your Windows Server Systems

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Securing Your Windows Server Systems

Încărcat de

Drepturi de autor:

Formate disponibile

Securing Your

a Jupiterweb Security eBook

Eight Steps to a More Secure Windows 2003 Server

1. Change Port Numbers

2. Check Logon Auditing

3. Isolate Domain Controllers

4. Disable Unnecessary Services

5. Run MBSA Regularly

6. Configure Account Lockout Policy

7. Rename the Administrator Account

8. Password Protect Backups

How Software Restriction Policies Work

Getting Down to Business

The first step in configuring your actual Figure 3

After configuring the default security

Creating an Exception Rule

The rule creation process is very

To create a hash rule, first locate the

Right-click the "Additional Rules" subfolder and select New Hash

you have configured all of the required exceptions, you Figure 6

Enforcement rules, which again are configured from with-

Designated File Types

In contrast, when using a default security level of disal-

Once you have completed your configuration, you can

As we discussed earlier, implementation of software

Windows Server Longhorn is Microsoft's next-genera-

IIS Security Checklist

Tools for Securing IIS

SQL Specific Security Recommendations

SQL Server Security Checklist

5. Do not run SQL Server on a Domain Controller.

Copyright 2006 Jupitermedia Corp.

S-ar putea să vă placă și