Internet Information Server hacks are legendary, including
many into Microsoft itself. Here's how to keep your Web
sites from becoming famous for the wrong reasons.
9 Steps to Securing IIS
Internet Information Server hacks are legendary, including
many into Microsoft itself. Here's how to keep your Web
sites from becoming famous for the wrong reasons.
- By Roberta Bragg
- August 01, 2001
When IIS is involved, I feel kind of like
the writer of the now infamous pamphlet 99 Ways to
Cook Hamburger. This booklet was published in the
early '60s when hamburger was cheap (less than a quarter
a pound!) and got served a lot.
Writing about securing IIS allows me to generate
my own such long list. Not because IIS is inherently insecure,
but because its entire purpose is to be open for business.
To ignore this fact and not invest heavily in protecting
it on an on-going basis is like not continually inspecting
the employees of a bawdy house for disease.
My list won't be 99 items long, but I'll
give you potential IIS trouble areas and point you to
excellent resources where you can dig out more specifics.
Before I get to my nine steps, I should remind
you of a few things. You need to have a strong security
policy, written and subscribed to by management. You also
need to follow sound security practices. No quick-fix
list applied after install and ignored henceforth will
do. These steps will not only help you create a secure
Web server, but maintain one as well.
1. Harden the OS
Do a minimal, clean install of Windows 2000, using the
NTFS file system, and install only the things that you
need. Phil Cox has a good article available at www.systemexperts.com/win2k/hardenW2K11.pdf.
(Its base is an abstract from his book Windows 2000
Security Handbook.) I like this list a lot. It's not
that you can't find his recommendations elsewhere (many
can be found on Microsoft's site, in list advisories,
and other security books); it's just that he's pulled
them together in such a nice way, added original thoughts,
and kept it updated with additions and corrections. Best
of all, he does what few do: He cautions that some of
his recommendations may break applications and possibly
kill your system. To that end, he recommends that you
work on a test server. In his article he details not only
how to do a minimal install, but also how to remove some
unnecessary elements like client applications, services
and OS/2 and Posix subsystems after the install.
Server components of your basic install also
deserve tightening. Doing some of these simple things
can go a long way:
- If you're going to use the indexing service,
set it to index only documentationnot your Web
- If you're using a multi-homed server,
remove Microsoft Networking and File Sharing services
from the external interface.
- Inspect all shares for necessity. Are
file system shares necessary? Not to allow Web access,
- Inspect the file system and tighten access
to all files and folders. Especially evaluate default
file shares and permissions settings.
- Turn on auditing and configure audit
files so there's adequate room for growth.
2. IIS Install and Initial
Install IIS on an NTFS file system. Install only the Web
services you need.
Examine installation directories and script
mappings. Sample IIS files aren't installed by default;
but just in case you or some enthusiastic developer has
installed them, remove them. Even sample files that can
only be accessed from http://local should be removed.
Look specifically in the directories \IISSamples, \IISHelp
Remove any development tools! This begs the
question "Where should development work be done?"
On a separate development system, that's wherenot
on the production Web server. Development tools should
never be placed on the production Web server! Yeah, yeah,
I know. You would never do that; but is all your staff
clear on the concept? This is an area you should continually
return to. At some point there will be that quick fix
for which a tool is loaded for "just a minute,"
and then not removed by the user.
Look for and remove script mappings linking
file extension to execution, in other words, .printer
for Internet printing or password reset .htr. Double-check
all extension mapping. If you don't use them, remove them.
To see what's currently available, look in the Web server
under properties\master properties\www service\edit\ homedirectory\configuration.
If you'd followed this advice and removed
the .ida and .idq mappings or if you had installed the
hotfix provided by Microsoft (as recommended in Microsoft's
checklist for hardening IIS available from www.microsoft.com/security)
you would have protected your web site from the Code Red
Disable the IP address in the Content Location
header of static .html pages. Not doing so can expose
internal IP addresses. See Q218180,
"Internet Information Server returns IP address in
HTTP Header (Content-Location)," for details.
3. Use Security Configuration
Review your OS settings against those in the high security
server/workstation template located in %system folder%\security\templates.
Review hisecWeb.inf, the security template
for Web servers provided by Microsoft, http://download.microsoft.com/download/win2000srv/SCM/1.0/
NT5/EN-US/hisecweb.exe. Many of the security recommendations
touted by independent security experts are part of this
template. To use the template, you'll need to copy it
to the \security\templates folder on
the IIS server. Use the Security Configuration and Analysis
console to examine the template, analyze your current
IIS server against it, andif you agree with its
changesapply the template. Before proceeding with
this step, it's critical you understand the changes that
will be made to your system. If not, you may find your
system locked down too tight.
Your best bet, as always, is to find the
right settings for your Web server and create a baseline
template, which may be a combination of these templates
and the ideas expressed here and by others. Once you know
the template's effective on a Web server, it can easily
be applied to others and used to audit the server to determine
if settings are being maintained in a secure state. If
Web servers are in an Active Directory (AD) domain, the
template can even be imported into a Group Policy Object,
linked to a "Web server" Organizational Unit
(OU), and pushed to all.
|To understand which trusted
root certificates to remove and which
to keep requires an understanding of what
certificates are used for. Having lots
of trusted root certificates allows the
typical user to be able to identify Web
sites and other authorities they may wish
to trust or do business with (register
with the Web site or make a purchase from,
for instance) A Web server, on the other
hand, should only trust a few appropriate
sources. There's no need for a large assortment
of trusted root certificates to exist
in the store.
Before you begin removing trusted root
certificates willy-nilly, make sure
you understand which ones are absolutely
necessary for your Web server to function.
Microsoft lists the following minimum
collection of trusted root certificates
required for Win2K to function.
Issued to and by Microsoft:
- Microsoft Timestamp Root, expiration
- Microsoft Authenticode Root, expiration
- Microsoft Root Authority, expiration
Issued to and by VeriSign:
- VeriSign Time Stamping CA, expiration
- VeriSign Commercial Software Publishers
CA, expiration date 1/7/2004
For more information, try Q293781,
"Trusted Root Certificates That
Are Required By Windows 2000."
4. Choose The Best Authentication
Method for The Purpose
While anonymous access may suit most Web sites, you may
want to restrict it to some areas of your Web site. If
you're going to configure authentication to allow users
with accounts to access this otherwise restricted data,
understand and use the most secure form available.
When basic authentication's used, the password
is "encoded," not encrypted. A network sniff
can capture this information, which can be easily decoded.
You might wish to ensure protection of these passwords
by using Secure Sockets Layer (SSL.) With SSL, the entire
session, including the password transmission, can be encrypted.
Use Integrated Windows authentication to
allow negotiation of the appropriate Windows method (Kerberos,
NTLM, and the like), but realize that not all browsers
are capable of performing this type of authentication,
and it isn't passed through a firewall by default. Digest
authentication, which can be performed by other Web browsers
and does work through a firewall, and certificate authenticationwhich
requires clients to possess trusted certificatesare
other choices. They require additional changes in your
IIS, and possibly your AD, infrastructure.
Don't make the IUSR_computername (the default
anonymous user created during IIS installs and used whenever
a user anonymously access the Web site) or IWAM_computername
(the account used by out-of-process Web applications,
which run in a separate memory space) a member of privileged
groups or give them additional user rights or privileges.
On the Web site root, deny access to the
IUSR_computername and IWAM_ computername name account.
At the folder level where you wish to allow anonymous
users access, give them the same. Clear the "Allow
inheritable permissions from parent to propagate to this
object" check box.
Require authenticated access to the Web site
root. IIS by default uses the local user database. To
modify this, change to domain user database, if necessary,
in the IIS snap-in.
For those command-line OS or other tools
that can't be removed, deny "execute" access
to the ISUR_computername and IWAM_computername accounts.
IIS CodeSpecific Uses
Writers of code to be
implemented on Web servers have a special
responsibility. As administrators we
may not be able to validate every line
of this code, but we should be checking
for adherence to proper practices, including:
Is user input validated? You can't
assume that users won't make mistakes,
sometime malicious mistakes. Many failures
to validate user input result in buffer
overruns. Need I say more?
Does code call functions such as MapPath
that might allow users to operate outside
the regular IIS structure? You can prevent
this by unchecking the "Disable
parent paths" box. Allowing use
of parent paths allows use of calls
to functions such as MapPath. The check
box is found within IIS properties\homedirectory\configuration\app
Are Web applications following proper
procedures as outlined in the certification
specifications for Win2K? While these
procedures and processes aren't specifically
Web server-based, they do ensure that
default security doesn't have to be
weakened in order to support applications,
and ensure compatibility with Win2K
functionality. Don't know the specs?
and download them. Check out www.rational.com
for a product that can help during the
5. Use NTFS and Virtual
Set Directory Access Control Lists (DACLs) on IIS virtual
directories. Set DACLs on files and folders. Think of
virtual directory or Web share permissions like you do
network share permissions. If there's a conflict between
the share and the underlying folder permission, the most
To make the most effective use of DACLs,
make sure that directories hold like filesone folder
for html, one for scripts, one for executables, one for
images; you get the idea. If you like, create folders
for different applications, then create subfolders to
hold the different types of files. If a folder holds multiple
file types, you can't set the strongest permission settings.
If they're separated, you can allow only the action required
(execute for executable, read for .html, and so on). If
you must allow writing to IIS folders, you can remove
or even deny execute permission on those folders to prevent
the intentional saving and executing of malicious code
there. Make sure you account for inheritance. Here's some
suggestions from Microsoft's downloadable document on
securing IIS 5.0, located at www.microsoft.com/
- In all areas, provide Admins and SYSTEM
Full Control (you may want to restrict administrative
access to a limited set of administrators).
- Folders that contain executables or scripts
(and these should be separated) should give Everyone
execute, but disable other types of anonymous access
(disable read, write and directory browsing).
- Folders that contain static content such
as .gif, .jpg, .html, and .txt should have DACLS set
to Everyone read.
- For executables like .exe, .dll, .cmd,
and .pl, Web permissions should be set to "none."
Don't allow scripts to run.
- For scripts (.asp), set Web permission
to "script." Executable permission isn't necessary
as long as the script extension is mapped to a script
- For static content Web permissions can
allow anonymous access and read permissions. You may
also want to allow directory browsing. Remember to use
advanced permission pages to assign only R, as the generic
Read permission is RX (read and execute). Should you
forget and use RX, you're allowing executables erroneously
or maliciously placed here to be executed.
- Secure Front Page server extensions using
NTFS permissions. Use the FrontPage Tools\Security\Permissions
property sheet and remove the Everyone group. On the
Users tab, select "Everyone has browse access."
This assures that the IUSR_computername account, which
is a member of Everyone, doesn't have Author access
and can't open the Front page Web site. On the root
Web site and sub-Webs, use unique permissions. (For
more on this, see Chapter 8 of the Windows 2000 Server
Resource Kit, "Internet Information Services IIS
5.0 Resource Guide." Also see the Front Page Server
Extensions Resource Kit.)
- Place tighter control on inetpub\ ftproot
and inetpub\mailroot. Default DACLS are Everyone Full
Control. You'll want to change this, but your changes
should reflect your intended usage of these folders.
6. Install Hotfixes and
Subscribe to Microsoft Security Notification service at
net/security/notify.asp. Once you've done that, respond
to the alerts. There have been many Web site defacements,
much information theft, and other successful hacks to
IIS Web servers that could have been prevented had the
administrators installed the available hotfixes.
7. Evaluate Other Security
Consider using IPSec to filter packets entering the Web
server. Allow only those necessary. Also consider using
IPSec to secure communications between your Web server
and back-end servers.
There are other tools available too. Review
the tools that ship with the OS, those on Microsoft's
Web site, or from the Resource Kit. (See "I Didn't
Know You Could Do That!")
Didn't Know You Could Do That!
As I'm sure you know,
setting security on Web sites can be
a nightmare. You make sure you've properly
hardened the OS, removed sample IIS
files, kept development tools out of
the live production environment, chosen
the correct authentication methods and
set permissions properly on every folder
and site. Then, just when you thought
you'd caged your princess and protected
her from the slobbering, raging, spittle-dripping
beasts that lie in wait to ravish her,
along comes another bug report, sending
you scurrying to patch the harem walls.
Microsoft tried to help you by providing
standard security templates for IIS
5.0, including the secureinternetWebserver.inf
and secureintranetWebserver.inf templates
available in the Resource Kit, and the
Win2K Internet Server Security Configuration
Tool, available for download from the
list at www.microsoft.com/TechNet/security/
But I'd like to tell you about three
tools, one recently made available at
the same site and two in the Resource
Kit. I'm talking about the hotfix checker,
the IIS Permission Wizard Template Maker
and IIS performance testing with WCAT.
Setting Web Permissions Across the
If you've been working with IIS 5.0,
you've no doubt discovered the Permission
Wizard. This handy tool steps you through
setting Access Control Permissions,
authentication methods and IP address
restrictions for properties on a site.
The setting generated is stored in the
metabase with the rest of your IIS settings
and can be manually changed through
the normal Web site interface. The concept
is simple. Instead of having to remember
all of the areas that need to be addressed,
you manage them all by following the
wizard steps. You don't have to use
it, but it can make life easier, especially
for the newbie.
But what if you have multiple sites
to manage? Running wizards can be tedious,
and with or without this tool you might
still question whether the same standard
settings (where applicable) have been
applied uniformly across all servers
So quit your complaining, shove that
anxiety and stop that compulsive behavior
pattern of continuously double-checking
your site settings. A simple tool existsand
you've probably already got it at hand.
This tool, the IIS Permissions Wizard
Template Maker, can be found in the
on the Resource Kit CD-ROM. To install,
double-click setup.exe and follow the
directions. Documentation exists in
the docs folder at the same location.
Making Sure Your Defenses are Mended
It's not enough anymore to follow a
list of steps and expect this to forevermore
create an IIS impenetrable fortress.
You've got to keep alertthat is,
you must follow the announcements of
hotfixes specifically directed at IIS.
That's not easy. IIS is a popular Web
server, and hackers love to attack Microsoft,
so this will always be a growing list.
Fine. No worries, mate. It's HFCheck
(hotfix checker) to the rescue. This
handy tool, available online, scans
your Web server and lets you know if
it's up to date.
You can configure it to display a dialog
or write messages to the event log.
While it can be run by connecting to
the Web site, administrators can download
the tool and run it under their own
network controls. The tool, HFCheck.exe,
can be run continuously or set to run
at a preconfigured frequency.
A Cool WCAT
All this security is a good thing, right?
Well, some will tell you that security
will slow things down. And, yes, some
for examplewill reduce performance.
Others will tell you that the degradation
caused by encryption can be compensated
for by adding an SSL accelerator board
or special network cards that can offload
IPSec encryption. So the issue isn't
whether security decreases performance,
but whether it slows it enough to warrant
external and/or optional devices to
improve it. WCAT can help you determine
that. This tool can be used to test
how well your server responds to various
workloads. Use it when your Web server
is first installed to get a baseline,
then test after adding security. That
will tell you what impact security is
having on performance. WCAT is on the
Resource Kit CD-ROM. If you find a need
for increased hardware spending, remember:
While additional hardware improvements
cost money, they're inexpensive in terms
of the gains in security they make possible.
8. Enable Logging (And
Use The Results)
Let's do this step-by-step: Right click the site. Chose
properties. Click the Web site tab. Check enable logging.
Then read the logs! Some things to watch for:
- Multiple failed commands, especially in
the /scripts directory or other directories that hold
- Attempts to upload files, especially
to /script directories.
- Attempts to access .bat, .exe or .cmd
filesespecially attempts to modify or use them
in invalid ways.
- Attempts to send .bat or .cmd commands
to the /scripts directory.
- An excessive amount of requests from
a single IP address might be a hacker attempting to
overload the server or cause a denial of service failure.
- "Error 5access denied"
messages. Use Net helpmsg error_number_of_the_ error_you_want_to_know
to find information.
9. Review The Machine
Load the computer Certificates console and remove certificates
from companies you don't recognize or from those you do
but see no need for a Web server to trust. This list of
trusted root Certificate Authorities (CA) means a certificate
issued by them is automatically trusted on this machine.
By removing unknown certificates, you're following the
same principle as removing unused services, files and
applications. If the certificate isn't present, an attack
relying on it won't be successful. Be careful not to remove
necessary certificates, such as those provided by Microsoft,
by software you're using, or by the CA for your SSL certificate.
To remove unnecessary certificates, open
an MMC console and add the Certificates snap-in. When
prompted, select the computer account radio button, and
choose "Select this machine."
Expand the Trusted root certification authorities.
If you're using SSL, make sure you don't remove the root
certificate for the issuing CA for your IIS Server's certificate.
Words to The Wise
Finally, don't just rely on one author, columnist, security
guru or Microsoft to provide you with the ultimate guide
to hack-proofing your Web site. You must continually be
alert for new ideas, and after appropriate confirmation
and testing, use them if appropriate to your situation.
Remember, Chicken Little was right. One last thing: Never,
never, never store users" credit card numbers on
your Web server!