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.

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
• 03/01/1999

In the past several months it seems that “security” and “NT” have become mutually exclusive terms. If you’re like me, you regularly scan the Microsoft security Web site, Windows NT Bug Traq, and the like—where it seems that someone discovers some new vulnerability every day. You’re 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 don’t 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, isn’t there some way we can sleep soundly at night now?

Fortunately for you, the answer is yes. In fact, it’s 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 doesn’t say, “How to Bulletproof NT.” As such, we’re going to specifically target IIS security here. (See Roberta Bragg’s “Hardening NT” feature in the October 1998 issue, along with her monthly column, for more on NT-related security.) However—and this is a big however—many elements of a secure Web site are rooted in NT. Therefore, don’t 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, we’ll 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! I’m not here to judge. I’ll be politically correct. Your site’s not vulnerable, it’s “security-challenged.” It’s 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. I’ll start with the easiest to implement and move on to the most secure. No matter what you do, though, there’s 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 they’ll get frustrated or bored and search for an easier target. Redundancy is key.

OK, so much for the disclaimers. Let’s go!

Step 1. Secure IIS.

One of the first things you’re 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 you’ve 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 computer—a 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:

• Write—This one should be obvious! We don’t want anyone changing our files (or adding their own files, complete with attached viruses).
• Directory Browsing Allowed—This setting is somewhat subjective. It’s possible to leave this option selected and never experience trouble, but I don’t recommend it. Here’s what happens if you allow directory browsing and don’t specify a default document: When a user doesn’t 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.
        “So what?” you may be asking. “They can’t open the files, so what harm does it do that they know they’re there?” Answer: Maybe no harm at all. However, we’re 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 Access—With 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 there’s 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 you’re already ahead of me, I’ll get to NT auditing in a minute. Redundancy, remember?)
• Application Settings—If 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). Don’t allow script or execute permission if your site doesn’t use it. This brings me to my next step…

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 wasn’t really a bug. Because, you see, scripts (including .ASP files) should always go in a scripts directory—one 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 we’re on the subject of NTFS permissions, this is the perfect time to segue into…

Step 3. Put your server on a FAT-free diet.

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. (I’ll 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 you’re thinking here. “But, Chris, Internet users attach via the IUSR_computername anonymous account. How can NTFS permissions help when they apply to everybody?” I’m 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” permission.

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 Everyone—Full 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 won’t 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… clear!

OK, so we’ve got a secure partition, NTFS permissions in place, and the virtual directories locked down. We’re good to go, right? Not quite. Up to this point, we’ve 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. What’s the best way to handle this? Again… 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 don’t 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 user’s password. Obviously, you can’t control the browser that your users will use to access the “Members Only” area, so you would need to enable “Basic Authentication.” Bad idea.

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 don’t want anyone to be able to intercept and read those packets.

What to do?

Fortunately, there’s 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 don’t want to use this for every page in your site, just the sensitive pages. Here are the steps:

1. Obtain a server certificate from VeriSign or another authority (or make your own with Microsoft Certificate Server). Once you’ve registered your certificate, you’ll be able to configure a virtual directory to require SSL (see Figure 4).
2. Instruct clients to connect via “HTTPS” or simply provide them with a shortcut that already has the correct URL.
3. 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 don’t have NT accounts on your computer. While the former is very important, the latter is even more so—particularly if you don’t know all of your “secure” users personally. It’s 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, you’ll be better off. (Psst… it’s also easier to administer.)

Figure 4. Secure Communications lets you configure a virtual directory to require a server certificate.

While we’re on the subject of administration, let’s move on to our next step.

Step 5. “You want a hot fix with your order?”

As of this writing, there are already four post-SP4 hot fixes on the Microsoft Web site. If, by chance, you haven’t upgraded to SP4, you’re 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 there’s no reason to install them. I recommend that you read all accompanying documentation for existing hot fixes (and new ones as they’re released). If they contain anything regarding TCP/IP or IIS, install ‘em.

The good thing about service packs is that they’re cumulative. Once you’ve 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 don’t 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 isn’t intended to help you bulletproof NT. Nor does it profess to help you secure your LAN. I don’t know what your network consists of in the way of firewalls, proxy servers, and so on. I told you—I’m 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 I’ll write an article on Proxy Server and we can cover them all. Today, though, we’re 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 server’s 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 you’re providing SSL connections, consider running a separate proxy server for those. You’ll 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 good!

Step 7. Don’t forget your data.

Let’s be honest. If your Web sites consisted simply of static pages, you’d 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. Let’s look at some ways we can protect our SQL data, yet still make it available to those who need it.

1. 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 we’re talking about anonymous Internet access, integrated security isn’t an issue. If we keep these two machines separate, we gain the advantage of segmenting server load (SQL doesn’t 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.
2. 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 doesn’t gain access to all of your data by breaking a single password. (Layers, remember?)
3. Configure your IIS server to use a network protocol other than TCP/IP to communicate with the SQL server—Named Pipes, for example. (You’ll 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. Don’t install what you don’t need.

I know you. You’re like me. You want it all. It doesn’t matter what it is. It doesn’t even matter if you know what it does. You want it.

You can’t 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 don’t 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 doesn’t 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 we’ve 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 server.

Step 9. You’re 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. He’ll then have to decide if it’s worth finding another way in, or if he should move on to a site less security-conscious than yours.

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:

1. Configure your security log not to overwrite audit events when the log is full.
2. 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. You’ll 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 system.

Be sure you make the security log large enough so that you aren’t 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.

We’ve talked about how to configure the services of your Web server. We know what it is. Now, let’s talk about what it isn’t:

1. It isn’t a file server, so unbind the Server service from the network card.
2. It doesn’t use WINS, so unbind that service as well.
3. There are a dozen other unnecessary services as well. Check Knowledge Base article Q189271 for the roster.
4. It isn’t remotely administered (or shouldn’t be), so don’t allow it to be. In REGEDIT, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   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 article Q153183.)
5. According to Microsoft Security Bulletin MS98-004, “Unauthorized ODBC Data Access with RDS and IIS,” the Web server shouldn’t 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. Visit www.microsoft.com/data/ado/rds/custhand.htm, 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 explode.)
6. Don’t place applications and/or development environment programs on the IIS box! I’ve already stated this, but I want to make sure it’s pounded into your skull!

Where security is concerned, it’s 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 that’s preferable to letting an intruder in. You can assuage the customer with a free month of access or a gift. Believe me, it’s better than explaining to your boss that the entire customer database has been deleted by a hacker. Don’t be penny-wise and security-foolish.