Securing Web servers in Windows environments |
 |
| 12 Apr 2006 | SearchWindowsServer.com |
 |


|
Doing business in today's world seems to create an ongoing need to set up a new Web server. For everything from development to marketing to training to e-commerce, the desire to load up static pages or networked applications is endless. But how can you be sure that the path you go down will lead you to a secure Web server that's less likely to be compromised by malicious outsiders or rogue insiders?
Step 1: Understanding the issues
There are certain must-have baseline configuration settings every Windows-based Web server needs regardless of whether it's Internet Information Services (IIS), Apache or some no-name software built into your niche e-mail server product. Your goal for configuration settings should be to have a server ready to be placed "in the wild" that's resilient to common Web server OS and application attacks and vulnerabilities:
- Null sessions
- Weak share and NTFS permissions
- Weak passwords and authentication systems
- Exploitable vulnerabilities due to missing patches and other OS misconfigurations
- Fingerprinting
- Parameter manipulation
- Default scripts
- Buffer overflows
- Cross-site scripting
- SQL injection
- Denial of Service due to missing critical layered defenses
This is certainly not an exhaustive list of attack methods, but it covers the main areas at both the OS and Web server application levels. Notice I've differentiated Web server OS and actual Web server software. It's important to consider both areas of the server. If you focus solely on the Web server software (IIS, Apache, etc.) itself, the "visible" part of your server may be secure, but you'll have a weak foundation (the underlying OS) and, consequently, still be susceptible to attacks.
Now, let's take a look at critical Web server configuration elements.
Step 2: Installing and configuring your Web server
Rather than attempting to provide specific configuration settings and instructions that are different for practically every version and platform of Web server available, I'll approach this from a layered security lockdown perspective and common weaknesses I see when I perform security assessments. The following are critical areas you need to address to ensure the utmost security of your Web server:
Web server software/hardware location
- Install your Web server on a partition (or drive) separate from the Windows OS.
- Ideally, place the server on the network in a semi-trusted area such as a DMZ or separate VLAN. This can help restrain (but not prevent) an attacker from reaching into your network further by breaking into the Web server.
Operating system
- Ensure Windows and your Web server software are fully patched.
- Remove any unneeded shares and make sure the default share and NTFS permissions are changed on your drives. This is especially true for Windows 2000 and earlier systems where everyone is granted full access by default.
- Disable null session connections to Windows if possible.
- Minimize the number of local Windows accounts as well as accounts that have administrative access to the machine.
- Disable all but the most essential services on the system. This includes Terminal Services, FTP, SMTP, Routing and Remote Access and more. You'll free up a lot of resources for the Web server application and, in Microsoft's words, reduce the attack surface of your Web server system making it less susceptible to security breaches.
- Seriously consider installing a host-based personal firewall -- ideally one with built in intrusion prevention capabilities. This is especially important for publicly accessible Web servers. If it's is not a good option for you, then consider an application layer firewall instead. The following figure shows various worm propagations, port scans, and other potential hack attempts against a plain old Web server on the Internet. It's absolutely amazing what's happening on the average Web server that you wouldn't be aware of without such protection.
Figure 1

Web server software
- Run/enable IIS Lockdown for any pre-IIS version 6.0 servers you're operating (IIS 6.0 comes locked down out of the box).
- Enable any other buffer overflow, input filtering, connection throttling and intrusion protection measures (Mod_Security for Apache and the secure TCP/IP registry settings for Windows come to mind).
- Use any built-in security features for process isolation and other access controls (such as those built into IIS 6.0).
- Disable dynamic content modules like ASP and WebDAV if they're not needed.
- Use secure authentication methods when possible (such as Advanced Digest Authentication in IIS 6.0).
- Run other publicly available lockdown scripts for IIS where possible -- such as those found here.
- Set specific access controls on your server directories and only allow browsing and enumeration of the minimum files necessary to do the job.
- Remove default scripts, miscellaneous files and even Front Page Extensions if they're not needed.
- Be careful with any robots.txt files that may divulge sensitive areas of your server to an attacker.
- Change default headers to block, obscure or mimic Web server version information. This isn't foolproof, but it is another layer of security. Port80 Software has a neat tool for IIS called ServerMask.
- Run the Web server service using something other than IUSR_ or Local System keeping in mind any minimum requirements and local service dependencies. The following figure shows where you can configure this for Apache.
Figure 2

For detailed steps on hardening IIS, check out Microsoft's Windows Server 2003 Security Guide and the AttackPrevention site for some good tips and tricks. For Apache, this Center for Internet Security benchmark tool and this Web site and book have good information as well. Contact your other niche vendors for specifics on locking down their Web servers.
Now, let's take a look at the final step in this process: testing the security of your Web server.
Step 3: Testing your Web server
It is a common oversight to assume that a secure configuration always equals a secure server. It isn't necessarily so: You need to validate your security settings to be sure you've left no stone unturned. When testing your Web server's security, there are various techniques and tools that will give you confidence in your rock-solid system before you put it into production. Here are some of my favorites for testing the security of Web servers:
The following figure shows a WebInspect scan of a default IIS install. Hopefully, after all your hardening efforts, your test results won't show quite as many holes!
Figure 3

Also, don't forget to test the security of all Web servers on your network -- not just the highly visible ones. It's the little-known systems that attackers often hack to give themselves an in to your network that you may not have considered. To find other Web servers running on your network -- as shown in the following figure -- you can use a tool such as SuperScan to quickly scan your subnet(s) to look for ports 80, 443, 8080 and other non-default ports that may point to a potential Web server.
Figure 4

Now that you've run your final security validation tests, it's time to lock things down even further by plugging the holes you found. Once you do that, you're all done -- that is, until any changes are made and any new vulnerabilities or threats emerge. On the bright side, the good news is now that you've gone through the process once -- with a few tweaks here and there -- you can simply repeat it time and time again. That's what it'll take for ongoing Web server security.
');
// -->

|
 |
| Hyper-V - Windows Server Virtualization Solutions |
|
 |