Secure your Web server

Imagine bringing your organization's home page up on your browser and finding that it has been modified with offensive words and graphics. The unauthorized alteration of a Web site is called a "defacement" and is usually done to make some political or personal statement. In most cases, someone remotely gained Administrator privileges on the Web server, allowing them to modify, copy, or delete any file on the server.

In 2000, Rik Farrow wrote an article "How to secure your Web server" in which he cited statistics from two primary Web page defacement mirrors ( www.attrition.org and www.alldas.org [no longer operational]) that show that thousands of Web page defacements occur every year. He found that Windows IIS servers were six times as likely to suffer a Web page defacement as server running Apache (Windows or Unix), even though (at the time) there were three times as many Apache servers as Windows IIS servers! The Alldas site today shows that 57% of all Web page defacements occur on servers running the Windows operating system.

Statistics on the UW network are similar. Web page defacements and compromises resulting from the "sadmind-IIS worm", Power bot, Code Red, Code Red II, and Nimda worms, occurred on hundreds of campus Windows IIS Web servers. During the same time period, only a handful of Unix Apache Web servers were compromised. Does this mean that Windows is less secure than Unix? Does it mean that Microsoft IIS is less secure than Apache? Does it even mean that Unix administrators are more skilled than Windows administrators? The answer to all three questions is a resounding "NO!" Windows/IIS can be just as secure as Unix/Apache.

Common causes of Web page defacements on campus

So what do the statistics and UW experience mean? We often see the following in security incidents on campus:

• Many people on campus switched from Linux/Apache to Microsoft Windows/IIS because they felt they understood Windows better than Unix, and that Unix was more complex. They found that Windows IIS was just as complex, and so it may not have been properly configured, properly patched, or properly protected. Many of these systems were compromised.
  
  
• Many people on campus switched in order to use front-end Microsoft SQL server databases (which add complexity and introduce even more possible vulnerabilities), and needed Front Page and ASP maintenance functions. Adding all these functions to one system, which is on a wide-open network, increased the complexity yet again, as well as the potential for compromise. Many of these systems were compromised.
  
  
• Many people purchased Windows systems that came pre-installed with Web servers that they didn't need. Often, the owners didn't even know the servers were installed, so they failed to disable or patch them. (The owners are not system administrators, they are just "normal" people who want to get their homework or research done.) These servers sat vulnerable until they were compromised -- not only once, but in some cases FOUR times (once by sadmind-IIS, then used for DoS attacks with the "Power" bot, then compromised again by Code Red, and finally compromised again by Nimda)!
  
  
• Despite being considered "more secure" and simpler to use, many Linux/Apache servers have been defaced or otherwise compromised. Sure, some of these were because of vulnerabilities in un-used PHP CGI scripts, but in some cases the attack was against a vulnerable NFS mount daemon, or BIND name server, or by sniffed passwords--not a direct attack on the Apache Web server.
  
  
• Finally, many departments on campus have limited resources for staffing, so instead of having one person maintaining Unix and another maintaining Windows, they opted to have one Windows expert handle two or three times as many Windows systems. This makes it difficult to keep up with the complexity of patching all those systems each time a new vulnerability is discovered (and Windows NT/2K and IIS both have very high patch rates). The result is that patches don't get applied quickly enough, or thoroughly enough, so automated scanning tools and worms can easily find the vulnerabilities. (Code Red and Nimda are both still active on campus, some nine months after they first appeared.) Many of these systems were compromised.
  
  

So you see, it is not really the choice of operating system or server that caused most of these problems, nor did the choice always prevent problems. It was more mundane things, like mis-configuration of services, inadequate patching, loading too many services on a single system (or too many systems on a single administrator), or the owner of the system simply not being ready, willing, or able to properly secure the server.

Tips for securing your Web servers

For these reasons, we suggest the following to most effectively secure your Web servers:

• Ensure that your computing staff are properly trained in system administration and security procedures. Have backup procedures in place, as well as incident handling roles defined and filled.
  
  
• Try not to overload administrators with too many system to manage or too many tasks to perform. This will inevitably lead to things being missed and intruders finding (and compromising) vulnerable systems before they are patched.
  
  
• Minimize the number of services on any given system. For example, only have your Primary Domain Controller be a PDC, only have your Web server serve Web pages, and only have your file server serve files. The more services you combine on one system, the more avenues for attack and the further the attack will spread.
  
  
• Turn off services and features you don't need.
  
  
• Make sure you keep up-to-date with hotfixes and security advisories for those services you do need to keep on your server.
  
  
• Make sure that your CGI programmers learn secure programming and know how to develop safer interactive sites.
  
  
• Use programs like Microsoft's Baseline Security Analyzer to check the configuration of your system and server.
  
  
• Follow Microsoft's " 7 Steps to Personal Computing Security."
  
  
• Consider putting your Web server behind an NDC logical firewall.

Other resources

• Rik Farrow's " Defending your Web Server" on Microsoft's Technet
• Windows NT Configuration Guidelines
• Unix Configuration Guidelines

UW Technology
Contact Us
Modified: January 25, 2008