Outwit hackers with this 10-step guide for Web securityguaranteed to provide layers of security protocols to keep intruders frustrated and bored, yet allow legitimate users access.
Crowd Control! 10 Steps to Securing Web Sites
Outwit hackers with this 10-step guide for Web security—guaranteed to provide layers of security protocols to keep intruders frustrated and bored, yet allow legitimate users access.
- By Chris Brooke
- March 01, 1999
In the past several months it seems that security
and NT have become mutually exclusive terms.
If youre like me, you regularly scan the Microsoft
security Web site, Windows NT Bug Traq, and the likewhere
it seems that someone discovers some new vulnerability
every day. Youre probably left wondering if you
should go into a safer line of work. Fire-walking, maybe?
Thank heaven for Service Pack 4. At least now I dont
have to apply two years worth of security hot fixes
every time I build or rebuild a Web server. And sure,
Windows 2000 promises to be the most secure Windows yet.
Still, isnt there some way we can sleep soundly
at night now?
Fortunately for you, the answer is yes. In fact, its
not even very difficult. All this security recipe calls
for is an ounce of prevention, a spoonful of diligence,
and, of course, my 10 easy steps. Bake at 450MHz for 24
hours a day. Serves millions.
The Ground Rules
First of all, the title doesnt say, How to
Bulletproof NT. As such, were going to specifically
target IIS security here. (See Roberta Braggs Hardening
NT feature in the October 1998 issue, along with
her monthly column, for more on NT-related security.)
Howeverand this is a big howevermany elements
of a secure Web site are rooted in NT. Therefore, dont
be surprised if some of my suggestions take place outside
the Internet Service Manager console. Heck, we may even
tweak a registry setting or two.
Also, well focus more on Internet servers than
on intranet sites. Although similar in most respects,
intranet sites are generally easier to secure (via NTLM
authentication, extensive auditing, or both).
Oh, yeah, one more thing: Security is a very subjective
concept. What one person sees as necessary for security,
another sees as overkill. Hey! Im not here to judge.
Ill be politically correct. Your sites not
vulnerable, its security-challenged.
Its up to you to decide how far you want to take
things. Some of my steps have varying levels to which
you can apply them. Ill start with the easiest to
implement and move on to the most secure. No matter what
you do, though, theres probably a hacker out there
who can break in anyway. The only way to completely secure
a computer is to unplug the network cable. Short of that,
what we want to do is provide layer upon layer of security
protocols to wear down a potential hacker, so that theyll
get frustrated or bored and search for an easier target.
Redundancy is key.
OK, so much for the disclaimers. Lets go!
Step 1. Secure IIS.
One of the first things youre required to do when
you set up an Internet Web server is to establish the
security settings for the server (from an IIS standpoint).
Once youve configured the server root
permissions, these are propagated to individual virtual
directories as you add them. This is the first level of
security and one that needs to be carefully implemented.
If you look at Figure 1, you can see the Default Web Site
Properties screen in Internet Service Manager. The Home
Directory tab is where we configure the basic security
settings of the Web share. Why is this step is so important?
Because a virtual directory can point anywhere. The actual
directory could even be on another computera computer
where we have no administrative control (not necessarily
a good idea, but it happens). Therefore, whatever security
settings we need to control will have to be applied here.
|Figure 1. Default Web site properties
in the Internet Service Manager.
Things to turn off:
- WriteThis one should
be obvious! We dont want anyone changing our files
(or adding their own files, complete with attached viruses).
- Directory Browsing AllowedThis
setting is somewhat subjective. Its possible to
leave this option selected and never experience trouble,
but I dont recommend it. Heres what happens
if you allow directory browsing and dont specify
a default document: When a user doesnt specify
a document, he or she receives a listing of the files
in the directory. If your Web site uses Active Server
Pages and a GLOBAL.ASA file for data access, the user
will be able to list these files.
you may be asking. They cant open the files,
so what harm does it do that they know theyre
there? Answer: Maybe no harm at all. However,
were talking about security here, and when dealing
with a potential hacker, the less information they have
by default, the better!
Things to turn on:
- Log AccessWith this
option enabled, all Web site usage is logged. These
logs are stored in the %systemroot%\system32\LogFiles\w3svc1
directory and contain information about the requestor,
including IP address, file requested, and so on. Generally,
this data is used to generate site usage statistics,
but theres no law against using it to help you
monitor security. If you see a massive number of continual
hits from the same IP address within a short time, there
may be a hacker out there trying to poke a hole. (If
youre already ahead of me, Ill get to NT
auditing in a minute. Redundancy, remember?)
- Application SettingsIf
your site consists of simple HTML pages, leave this
set to None. If you use Active Server Pages or VB and
Java script files, set it to Script. If you need to
execute programs, set it to Execute (including script).
Dont allow script or execute permission if your
site doesnt use it. This brings me to my next
Step 2. A place for everything, and everything
in its place.
Back in July 1998, Microsoft released a hot fix in response
to a discovered vulnerability. It seemed that
IIS would send an Active Server Page to a client without
processing the embedded server-side scripts. These would
be sent along with the page. This allowed anyone with
read access to the NTFS directory (including the IUSR_computername
anonymous account) to see your ASP code. If, by chance,
you embedded any security information in your scripts,
they would see that, too. All the client had to do was
append ::$DATA to the end of the URL. Microsoft released
a fix for this, even though it wasnt really a bug.
Because, you see, scripts (including .ASP files) should
always go in a scripts directoryone to which the
user does not have read access (only execute).
This is practically the first thing they taught us in
my How To Be An IIS God class: Always keep
your scripts separate! (Just for the record, go ahead
and install the hot fix anyway, just in case.) While were
on the subject of NTFS permissions, this is the perfect
time to segue into
Step 3. Put your server on a FAT-free
The virtual directory settings we established in Step
1 apply to that virtual directory and all files it contains
(no matter where they reside). Think of these settings
like Access Through Share (ATS) permissions in NT. While
these settings are important, we need to get more specific.
When we talk about securing a Web server, our primary
concern is securing the files contained in IIS shared
directories. (Ill get to databases in a minute.)
The best way to secure these files is to store them on
a volume that offers a reasonable level of security. The
FAT file system offers one level of security: None! The
NTFS file system allows for granular control over resources.
You can assign access to directories and individual files
for various users and groups separately.
I know what youre thinking here. But, Chris,
Internet users attach via the IUSR_computername anonymous
account. How can NTFS permissions help when they apply
to everybody? Im glad you asked that. In addition
to providing different levels of access for different
users, NTFS permissions also allow us to assign different
levels of access to different resources for the same user.
In Step 2 we talked about separating our files into different
directories. NTFS permissions allow us to assign specific
permissions to the directories (and files) that reside
in the virtual directory that we set up in Step 1. We
can assign Read Only to the directory where
our HTML files are stored, and Execute Only
to the scripts directory. This requires a teensy bit of
finesse, since execute permission is included with read
permission (in the standard NTFS permissions).
Figure 2 shows you how to assign execute only permission
to directories or files using the Special Access
|Figure 2. Assign execute only
permission using the Special Access dialog.
All this control comes at a price. You have to be very
diligent in your administration efforts when using NTFS
permissions. The default permission for the wwwroot directory
(and all its subdirectories) is EveryoneFull Control.
You should remove Everyone and explicitly
assign access to the anonymous user account. Assign access
to other users individually as needed. This way, if a
hacker happens to circumvent your guest account, at least
he or she wont have Full Control.
One last note on NTFS permissions: Go through your entire
partition and remove the Everyone group from
access. Replace this with the Authenticated Users
group. This is just an additional layer of protection
to thwart a would-be intruder.
Step 4. Clear text is, well
OK, so weve got a secure partition, NTFS permissions
in place, and the virtual directories locked down. Were
good to go, right? Not quite. Up to this point, weve
been assuming that the whole world has access to every
page in our site. Realistically though, there may be times
when we want to provide access to a specific page for
only a select few people. A Members Only page,
if you will. Whats the best way to handle this?
glad you asked!
The standard IIS setting for controlling access is under
the Directory Security tab in the virtual
directory properties. Figure 3 shows this window. If either
Basic Authentication or Windows NT Challenge/Response
is selected, then the user is prompted for a password
whenever NTFS permissions restrict (or dont implicitly
allow) access to the anonymous account. This presents
two very real problems.
|Figure 3. The Authentication
Methods dialog allow you to control access; make sure
you understand your options.
First, the password is encrypted only if the client is
using IE (or Netscape with the Netscape Authentication
Proxy installed) and the NT Challenge/Response
box is checked. All other browsers transmit the password
in clear text. Yes, that is as bad as it sounds!
Anyone watching packets traverse the network (this is
where all hackers start) can see the users password.
Obviously, you cant control the browser that your
users will use to access the Members Only
area, so you would need to enable Basic Authentication.
Second, even if NT Challenge/Response is used, the data
is still visible. If the content is sensitive enough to
require a password, you probably dont want anyone
to be able to intercept and read those packets.
What to do?
Fortunately, theres a better way. Most Web browsers
allow users to establish Secure Sockets Layer (SSL) connections
with Web servers. Granted, the server must have a valid
security certificate and the load on the server is increased,
but the added security is well worth the cost. You certainly
dont want to use this for every page in your site,
just the sensitive pages. Here are the steps:
- Obtain a server certificate from VeriSign or another
authority (or make your own with Microsoft Certificate
Server). Once youve registered your certificate,
youll be able to configure a virtual directory
to require SSL (see Figure 4).
- Instruct clients to connect via HTTPS
or simply provide them with a shortcut that already
has the correct URL.
- Establish a database of users that authenticates
login after the SSL connection is in place. This kills
two birds with one stone: a) The passwords are encrypted
and b) the users dont have NT accounts on your
computer. While the former is very important, the latter
is even more soparticularly if you dont
know all of your secure users personally.
Its not beneath a hacker to pay for membership
to a secure site in order to benefit from the increased
trust. If you keep NT accounts separate from your secure
Web users, youll be better off. (Psst
its also easier to administer.)
|Figure 4. Secure Communications
lets you configure a virtual directory to require
a server certificate.
While were on the subject of administration, lets
move on to our next step.
Step 5. You want a hot fix with
As of this writing, there are already four post-SP4 hot
fixes on the Microsoft Web site. If, by chance, you havent
upgraded to SP4, youre likely spending the better
part of a day installing all of the post-SP3 hot fixes.
Many of them may not pertain to Internet security, in
which case theres no reason to install them. I recommend
that you read all accompanying documentation for existing
hot fixes (and new ones as theyre released). If
they contain anything regarding TCP/IP or IIS, install
The good thing about service packs is that theyre
cumulative. Once youve installed SP4, you no longer
need to worry about post-SP3 hot fixes. Hot fixes, on
the other hand, are not cumulative. Furthermore, they
must be applied in the order that they were released,
since they sometimes address the same components. If you
dont monitor this carefully, you could apply a hot
fix that undoes a previously installed hot
fix that should have been installed afterwards.
Step 6. Hide your light under a bushel.
I mentioned earlier that this article isnt intended
to help you bulletproof NT. Nor does it profess to help
you secure your LAN. I dont know what your network
consists of in the way of firewalls, proxy servers, and
so on. I told youIm not here to judge. Nonetheless,
if you use a proxy server as part of your LAN security
configuration, we can use that to our advantage.
Microsoft Proxy Server 2.0 contains many improvements
over version 1.0. Someday Ill write an article on
Proxy Server and we can cover them all. Today, though,
were just interested in Reverse Hosting. Reverse
Hosting allows you to put your Web servers behind the
network firewall. Wait! It gets better! Since Proxy Server
performs Network Address Translation (NAT), you can have
private IP addresses for your Web servers. This one feature
protects us from a myriad of IP attacks. The proxy server
configuration is simple. The only additional step is to
update your external DNS servers to point to the proxy
servers external network card. Proxy does the rest.
If you host a lot of Internet servers, you might want
to set up several proxy servers or a proxy server array
to eliminate the bottleneck and avoid a single point-of-failure.
If youre providing SSL connections, consider running
a separate proxy server for those. Youll have to
reconfigure the ports used to listen for HTTP and HTTPS
(see Knowledge Base article Q184030).
By putting our Web servers behind the network firewall,
we take advantage of the added security provided by the
firewall. Repeat after me: The more layers of protection
we have, the more secure our server will be. Very
Step 7. Dont forget your data.
Lets be honest. If your Web sites consisted simply
of static pages, youd be fairly limited in what
you could include. Most business Web sites require real-time
access to data. There are a variety of ways to provide
this access, but the most popular Microsoft solution is
SQL Server. Lets look at some ways we can protect
our SQL data, yet still make it available to those who
- Install IIS and SQL Server on
separate machines. If IIS and SQL reside on the
same machine, you can use integrated security to access
SQL data. However, since were talking about anonymous
Internet access, integrated security isnt an issue.
If we keep these two machines separate, we gain the
advantage of segmenting server load (SQL doesnt
like to share its resources) and increased security
for both SQL and IIS by requiring separate authentication
(provided by the application). The Web application provides
connection information within a GLOBAL.ASA file. These
credentials must match a SQL user name in the destination
database. Permissions must be assigned to tables, SPs,
views, and the like.
- Configure each Web application
to connect to SQL Server via standard security
using a randomly generated strong password
(lots of upper and lowercase letters, numbers, characters,
etc.). Additionally, each application should have a
separate user account on the SQL server, so that a would-be
hacker doesnt gain access to all of your data
by breaking a single password. (Layers, remember?)
- Configure your IIS server to use
a network protocol other than TCP/IP to communicate
with the SQL serverNamed Pipes, for example.
(Youll find this covered in the NT Server 4.0
Resource Kit, Chapter 3: Server Security On the
Internet, and Protocol Isolation.)
This completely isolates your SQL server from the Internet
and prevents a hacker from speaking to it directly.
Step 8. Dont install what you dont
I know you. Youre like me. You want it all. It
doesnt matter what it is. It doesnt even matter
if you know what it does. You want it.
You cant have it!
Whenever we configure a Web server, the temptation is
there to completely install all of the components in the
NT Option Pack. Not a good idea. The functionality provided
by some of these components is contrary to our security
needs. A perfect example of this is FrontPage Server Extensions.
If you use Microsoft FrontPage or Visual Interdev to design
your Web applications, this component is required on your
server if you want to take advantage of all of the neat
development tools that FP and VID offer. If you have a
secure development server that you use while designing
your Web applications, then by all means, install the
Front Page Extensions. But, please-oh-please dont
put it on your production Web servers. Yes, I know that
it has its own security built in, but it opens up an access
method that we would just as soon keep closed.
FTP is another excellent example. The FTP Server service
doesnt support NT Challenge/Response authentication.
Nor does it support many other security features that
the WWW Service utilizes. If you feel that you simply
must have an FTP site, set up a Web virtual directory
and include instructions for saving the files it contains.
By using FTP via IIS, you gain the advantage of all the
IIS security weve been working on.
Always evaluate the purpose of your Web applications
prior to building your server. Install only the components
that you need to accomplish the mission at hand. If, in
the future, you develop an application that requires additional
components, you can install them at that time. If nothing
else, it conserves disk space and reduces load on your
Step 9. Youre being audited!
In Step 1 we talked about the IIS logs. NT auditing is
an additional way for you to keep an eye out for an intruder.
In many cases, you can uncover an attempt before said
intruder gets very far and lock him out. Hell then
have to decide if its worth finding another way
in, or if he should move on to a site less security-conscious
Auditing is enabled in the Policies menu
of User Manager (see Figure 5). When looking
for an intruder, you want to focus on auditing failures,
since most hackers use trial and error in their attempts
to gain access. If you audit a lot of successes, your
logs can fill up quickly. It should be part of your administrative
duties to regularly dump these logs. To ensure adequate
auditing, you should:
- Configure your security log not to overwrite audit
events when the log is full.
- Install the C2 Security Manager from the Resource
Kit and enable Halt System when Security log is
full. (See Knowledge Base article Q140058 for
instructions.) This does a registry edit. If the log
becomes full, no one but administrators will be allowed
to log on. Youll then have to log on and archive
the security log, clear the security log, and edit the
registry (changing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Lsa\CrashOnAuditFail back to the value 1) to reset their
Be sure you make the security log large enough so that
you arent dumping it every day (unless you like
that sort of thing).
|Figure 5. The Audit Policy dialog
lets you set which events to track.
Step 10. Being in Nothingness.
Weve talked about how to configure the services
of your Web server. We know what it is. Now, lets
talk about what it isnt:
- It isnt a file server, so unbind the Server
service from the network card.
- It doesnt use WINS, so unbind that service
- There are a dozen other unnecessary services as well.
Check Knowledge Base article Q189271 for the roster.
- It isnt remotely administered (or shouldnt
be), so dont allow it to be. In REGEDIT, go to
Control\SecurePipeServers\winreg and delete the value
Description. This effectively disables remote
access to the registry. If you wish to remove the capability
to access the registry remotely, you can restrict access
to this key through the security menu by
using no access permissions. Since the check
on who can access the registry remotely is done using
the server service, restricting access here is an excellent
additional layer of security. (Check out Knowledge Base
- According to Microsoft Security Bulletin MS98-004,
Unauthorized ODBC Data Access with RDS and IIS,
the Web server shouldnt provide implicit RDS functionality,
so turn that off. Delete the three registry keys RDSServer.DataFactory,
AdvancedDataFactory, and VbBusObj.VbBusObjCls from Services\W3SVC\Parameters\
ADCLaunch. This disables implicit RDS functionality
and requires a specific handler in order to use RDS.
which explains how to set up custom handlers or modify
the default handler. You might also consider talking
with your in-house Visual Basic expert to find out what
business objects need accessing. (The fact is, if you
edit the registry, you risk causing the universe to
- Dont place applications and/or development
environment programs on the IIS box! Ive already
stated this, but I want to make sure its pounded
into your skull!
Where security is concerned, its always better
to be excessively paranoid. Lock the system down so tight
that only the required services will run. You may occasionally
lock out a valid user, but thats preferable to letting
an intruder in. You can assuage the customer with a free
month of access or a gift. Believe me, its better
than explaining to your boss that the entire customer
database has been deleted by a hacker. Dont be penny-wise