Microsoft's IIS and SQL Server can provide tempting targets for malicious people. Our security checklist will help you lower your risk of attack.
In the first part of our look at securing distributed Windows apps, we covered how authentication
and authorization are typically handled in Windows-based applications. Today, we'll
cover some very specific recommendations for locking down IIS and SQL, both of which
are often a large part of Windows-based distributed application environments.
IIS Specific Security Recommendations
There is a programming 'hook' in IIS known as ISAPI that associates
files having certain extensions with DLLs. These are known as ISAPI extensions (define) .
ISAPI extensions handle functions such as Active Server Pages,
.NET web services and Web-based printer sharing. However, many of these extensions
are not required, particularly if you're still using IIS 5.0 or earlier. The problem
is that many of those extensions (filters) are exploitable. The notorious
Code Red is an example of just one malicious program that takes advantage of
these extensions. Enable only the ISAPI extensions the Web server and application
need, and restrict the HTTP options that can be used with each extension. (Server Properties,
WWW Service, Edit, Home Directory tab, Configuration)
Configuring ISAPI Options in IIS|
(Click for a larger image)
Most IIS installations include some sample applications and 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
The IIS Lockdown Tool
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 websites and latest security bulletins for any
needed patches or new exploits in these add-ons.
IIS Security Checklist
- 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.
- Install host-based anti-virus and intrusion detection software. Keep them
current on patches and review the log files frequently.
- Disable unused script interpreters and remove their binaries. For
- Use logging and review the logs frequently, preferably through an
automated process that summarizes the events and reports
exceptions and suspicious events.
- 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).
- Limit the services running on the web server to the HTTP
service and its supporting services.
- Be aware of and minimize any type of connection into the inner network that
enter through public web server(s). Disable File and Printer Sharing
and NETBIOS name resolution on Internet-facing systems.
- Use a separate DNS server in a DMZ to service Internet-facing Web servers. Direct
any unresolvable queries outside the DMZ to other public DNS servers or those of your service
provider - never to your internal DNS servers.
- 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.
- Block all TCP ports to the DMZ except 80 or 443, if needed.
- Install the operating system on one drive and Web sites on a different drive to help
thwart directory traversal attacks.
- 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)
Continued on page 2: Tools for Securing IIS
Continued From Page 1
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.
Microsoft Baseline Security Analyzer (MBSA)
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
maliciously 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
Changing the Default Port SQL Uses|
(Click for a larger image)
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. You can
download a program from eEye Digital Security that scans your network
for SQL Servers with blank SA accounts.
SQL Server Security Checklist
- 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 anyone who knows it leaves the company. Use eEye's tool to
scan your network for SQL servers with no SA password.
- 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.
- Remove BUILTIN/Administrators from the sysadmin role and give sysadmin rights in SQL to specific domain accounts that need it.
Windows Authentication and Windows Only Mode if possible. This way, a
potential hacker must authenticate to the domain first instead of just
to SQL Server.
- Do not run SQL Server on a Domain Controller.
- Change the SQL Server service startup account to something besides LocalHost.
the Failed Login option (Server Properties | 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
NETSEND or email, if possible.
- Keep up to date on patches and service packs for the operating system and SQL. See Tools for Securing IIS for some options.
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. See Part I of this article for more information.
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.
- Make sure the Everyone group doesn't have write access to SQL Server registry keys.