When it comes to your company’s Web server, there’s no such thing as being too concerned with security. IIS has become something of a whipping boy for hackers who are constantly trying to find new ways to compromise security. As a network administrator running IIS, you need to know how to secure IIS while still allowing it to serve Web pages. Here are some techniques to prevent hackers from vandalizing IIS and to make sure your Web server isn’t used as a portal for hacking your network.
Planning the architecture
When it comes to your Web server’s security, architecture is everything. Your goal is to keep people from hacking your Web server, but you don’t want to lose sight of the big picture: overall security of your network. If someone is able to hack your Web server, there’s a chance he or she could gain access to the rest of your network. It’s extremely important that you design your network so that such a hack is difficult, if not impossible.
To prevent someone from hacking your Web server to gain access to your network, make sure the Web server isn’t part of the network. If your company uses a simple corporate presence Web site, consider making the Web server a stand-alone member server. You can further isolate the server by making sure it isn’t connected to the rest of the network physically or logically. However, isolating a Web server in this way won’t prevent an attack on it.
Unfortunately, companies with more complex Web sites may not be able to isolate their Web servers. For example, e-commerce applications almost always require access to various databases, such as customer and inventory databases. Often, these databases are also used by other applications and can’t be isolated from the network.
In such situations, you can’t physically isolate your Web server, but you can make a hacker’s job a bit more difficult. Try placing any servers exposed to the outside world, such as Web servers and e-mail servers, into a domain separate from everything else. You can then tighten the security for that domain. Remember to plan your domain trust relationships carefully, because if the domain that contains your Web server is compromised, domains that have trust relationships with that domain are also at risk.
The next step is to evaluate Windows 2000’s security. Although Internet Information Server (IIS) is hosting the Web site, it rides on top of Windows 2000. If Windows 2000 is configured with a weak security policy, IIS will also be insecure as a result. Therefore, it's important to consider Windows-related security issues. I could easily write a book on Windows 2000 security, but there are a few particular security settings that directly effect IIS’s level of vulnerability.
Depending on your network’s architecture, it’s possible that your Web server may have two or more network interfaces. Typically, one network card would connect the server to the rest of your network, while the other would connect to a router connected to the Internet. If you’re using a separate machine as a firewall server, this layout might be different. When you have multiple network interfaces in your Web server, it’s important to disable IP routing, because if it's enabled, it would be easy for an Internet-based user to access your private network by passing through your Web server.
Another step to securing Windows is to convert all volumes on the server to NTFS. NTFS has the capability of applying file-level security, which is more secure than share-level security. So create your Web shares as you usually would but apply security at the file level.
I also recommend being more protective than you might normally be when assigning permissions. When most people assign permissions, they simply select the group to which they want to grant access and then apply the desired level of permissions to the group. However, one of the most underused security features in Windows 2000 is the explicit deny, which always overrides an explicit permission. So be sure to issue an explicit deny to anonymous users. This will prevent Internet-based users or anyone without a permitted user ID from accessing that particular area of the server.
Guarding the Administrator account
If someone is attempting to hack your Web server to gain access to your private network, he or she will probably target the Administrator account. By doing so, they can create their own account with administrative privileges or grant administrative access to another account. So it's important to protect your Administrator accounts.
If you have created a dedicated domain to contain your Web servers, there won’t be any accounts in the domain other than the ones built into Windows 2000. In such a case, it's easy for a hacker to figure out which account belongs to the Administrator. I recommend renaming the Administrator account using a naming convention that's inconspicuous, like last name, first initial, as in PoseyB. Next, create a bunch of dummy accounts that blend in with the administrator’s account. The dummy accounts should be disabled and have absolutely no permissions assigned to them. Their only purpose is to confuse a hacker and make it more difficult for him or her to discover the real Administrator account.
If creating a separate domain is out of the question, you can still obscure the Administrator account by renaming it. Because actual users will be using the domain, you don’t need dummy accounts to help disguise the Administrator account. But don’t actually use the Administrator account. Instead, create separate accounts for your support staff. By having support staff use their own accounts for administrative tasks, the audit log will clearly display which individual account made each change. If suspicious changes begin to appear on your Web server, you can see who supposedly made the changes. If the person whose name shows up on the log didn't make the change, you can also tell which account may have been hacked.
You can also create the support staff’s accounts so that they have no greater permissions than that of a typical user account. Then, when someone on the support staff needs to make an administrative change, he or she can use the Run As option to execute the command as the Administrator, without ever fully logging in as the Administrator.
Don’t forget that you can also use the more common protection methods, such as using a strong password that is set to expire frequently. The strongest passwords are composed of a combination of uppercase letters, lowercase letters, numbers, and keyboard symbols, like so: f5^.</lO9(sdf3542. Of course, strong passwords are hard to remember. To help your staff remember such passwords, make up silly acronyms to go with them.
Protecting Windows 2000's security
Establishing basic Windows 2000 security is only half of the battle. The other half of the battle is to continuously maintain a secure environment.
First, remember the server’s purpose: Web server. Don’t try to run any unnecessary applications or services on the server. Anytime you add an additional application or service, there’s a chance that it could contain weak code that can be exploited to gain access to the server.
Although running unnecessary services or applications can present hidden dangers, there are some applications or services that you should run. You should always run antivirus software on your server. Use an antivirus suite capable of automatically updating the virus definition database, such as Symantec’s Norton AntiVirus.
You should also make a habit of frequently checking the Microsoft Web site for service packs and hotfixes. Look for patches to both Windows 2000 and to IIS. Because service packs and hotfixes are designed to fix bugs and to patch security holes, it’s important to stay on top of them. And create a full system backup before installing any new patches, since you can never be too sure about how a particular patch will affect your system.
I also can’t stress enough the importance of frequent backups. This is especially true for Web servers, since they are constantly subjected to hacker vandalism, like changing the Web page or redirecting your Web page to a hacker's site.
You should also enable auditing. The trick to doing so is to know which events to audit and to make time to review the audit logs. It’s easy to just audit everything that happens on the entire server, but the logs produced by such an audit would be useless because they would be too large to review. It’s better to just audit administrative actions such as account creations, password changes, and the assignment of permissions. Whatever you choose to audit, be sure to review the audit logs daily or even more often if you detect any suspicious activity.
Need to know more?
For more information on auditing, see my Daily Drill Down "Know what's happening on your Windows 2000 server with auditing."
Finally, I recommend using Windows 2000’s security templates. After you create the final security settings for your Web server, create a security template based on those settings. You may then occasionally compare the template against the actual security settings to make sure none of the security settings have changed. I recommend making a habit of comparing the template against the actual security when you read your audit logs.
It’s important to carefully design your IIS’s architecture with security in mind. As well, there are many security settings that you can apply to the underlying Windows security subsystem to help keep IIS secure. Such efforts can help eliminate an attack on your server, or worse, on your network.