Doing business in today's world seems to create an ongoing need to set up a new Web server. For everything from...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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 the path you take will lead to a secure Web server that's less likely to be compromised by external hackers or rogue insiders?
Step 1: Understanding the issues of Web server security
There are certain 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 email server product. For configuration settings, your goal should be to have a server ready to be placed "in the wild" that's resilient to common Web server operating system and application attacks and vulnerabilities:
- Exploitable vulnerabilities due to missing patches
- Null sessions
- Weak share and NTFS permissions
- Weak passwords and authentication systems
- Parameter manipulation
- Default scripts and services such as Frontpage Extensions and WebDav
- Buffer overflows
- Cross-site scripting
- SQL injection
This is not an exhaustive list of issues, but it covers the main areas at both the OS and Web server software levels.
Note that 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.
Next 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 perspective and cover the common weaknesses that occur during Web server security assessments.
The following critical areas need to be addressed to ensure the utmost Web server security:
Web server software/hardware location
1. Install your Web server on a partition (or drive) separate from the Windows OS. Malware and exploitable vulnerabilities that obtain/grant access to the C: drive or main partition may not affect the D: drive or separate partition. Every layer of security counts.
2. Place the server on the network in a semi-trusted area such as a DMZ or at least a separate VLAN that's not easily accessed from the main user network. This can isolate the Web server itself and also help restrain an attacker from reaching into your network further if they gain access to the Web server.
1. Ensure Windows and theWeb server software are fully patched. As with weak passwords, I'm amazed every time I see missing patches on production systems. Critical system or not, periodic and consistent patching has to take place on the server. Also, don't forget to patch third-party applications such as Adobe Acrobat, Firefox, VNC, etc.
2. Remove any unneeded shares and make sure the default share and NTFS permissions are changed on your drives. By default, Windows Server 2003 and 2008 systems are very secure in this area, but I often see permissions that have been changed to facilitate "convenience".
3. Disable null session connections to Windows if possible. Unless you're doing some in-depth network management or fancy scripting, there's probably no reason anyone on the internal network should be able to enumerate your servers in this way.
4. Minimize the number of local Windows accounts as well as accounts that have administrative access to the machine.
5. Disable all but the most essential services on the system. This includes Terminal Services, FTP, SMTP, and Routing and Remote Access. This will free up a lot of resources for the Web server software and reduce the attack surface of the Web server system, making it less susceptible to security breaches.
6. Enable the Windows Firewall. If possible, consider installing a host-based. IPS This is especially important for publicly accessible Web servers. If it's not a good option for you, consider a Web application firewall (WAF) instead. Even though it's a bit dated, 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.
Web server software
2. Enable any other buffer overflow, input filtering, connection throttling and intrusion protection measures (ModSecurity for Apache and the secure TCP/IP registry settings for Windows come to mind).
3. Disable unnecessary dynamic content modules like ASP and WebDAV
4. Use secure authentication methods when possible (such as Advanced Digest Authentication in IIS 6.0 and above).
5. Set specific access controls on your server directories and only allow browsing and enumeration of the minimum files necessary to do the job.
6. Remove default scripts, miscellaneous files and even Front Page Extensions if they're not needed.
7. Be careful with any robots.txt files that may divulge sensitive areas of your server to an attacker.
8. 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 anti-reconnaissance tool for IIS called ServerMask.
9. Install anti-virus software to help prevent infections from malware uploaded via Web application forms, etc.
10. Disable SSL version 2 and low encryption ciphers (key lengths less than 128 bits) and require SSL version 3.
For detailed steps on hardening Windows and IIS, check out Microsoft's Windows Server 2008 Security Compliance Management Toolkit, the Center for Internet Security's IIS and Windows benchmarks for some good tips and tricks. For Apache, the Center for Internet Security's Apache is a good guide. Contact your other niche vendors for specifics on locking down their Web servers. A good guide for general Web server security is NIST's Guide to Securing Public Web Servers.
The final step in this process is testing the security of your Web server.
Step 3: Testing your Web server for security
It is a common oversight to assume that a secure configuration always equals a secure server. That's hardly the case. 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:
- HTTrack site mirroring tool and Google to see what others can glean from your site
- GFI LANguard Network Security Scanner and QualysGuard vulnerability scanners to find OS weaknesses, missing patches and much more
- Metasploit to exploit OS, Web server or other vulnerabilities discovered via your vulnerability scans
- Acunetix Web Vulnerability Scanner, N-Stealth Security Scanner and WebInspect for in-depth testing of the Web server and any associated applications
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.
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, you've now gone through the process once -- with a few tweaks here and there – and you can simply repeat it time and time again.
Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go.