When
Check for Web server vulnerabilities no less than monthly; update your Web server security policy annually or each time you upgrade or patch.
Why
Web servers are your organization's public face and provide an easy way into your network. All Web servers have associated security issues, some more than others. SecurityFocus recently listed 116 security issues with Microsoft's IIS server, while the open-source Apache had 80.
Strategy
Many Web servers come with sample Common Gateway Interface (CGI) programs installed by default, which can be used to execute malicious commands. Since they're simple to find and often operate with root privileges, hackers exploit vulnerable CGI programs to vandalize Web pages, steal credit card information and set up backdoors for future intrusions. As a general rule, remove sample programs from production systems, delete CGI script interpreters in bin directories, remove unsafe CGI scripts, write better CGI programs and determine if your Web servers need CGI support at all.
Dedicate your Web server so only information to be distributed should reside on the server. Assume all information placed here will be available to the Internet public should your server be compromised.
Don't run Web servers as root -- run them with as little privilege as necessary. This issue is sometimes misunderstood. Most servers are launched as root so they can open port 80 and write to log files.
They then wait for an incoming connection on port 80. Receiving this connection, they fork a child process to handle the request and go back to listening. The child process changes its effective user ID to the user "nobody" and processes the request. All actions taken in response to the request, such as executing CGI scripts, are done as the unprivileged "nobody" user. This isn't the scenario people warn about when "running the server as root." This warning is about servers configured to run their child processes as root, (e.g. by specifying "user root" in the server configuration file). Every CGI script launched with root permissions will have access to your system.
Run your Web server in a "chroot" environment. You can increase your Web server's security significantly in a Unix environment by running the chroot system command, as it places the server in a "bubble" that can't see any part of the file system beyond a directory tree that you set aside for it. The directory you designate becomes the server's new root "/" directory -- anything above this directory is inaccessible. To run a server in a chroot environment, you have to create a whole miniature root file system that contains everything the server needs to access, including special device files and shared libraries. You also need to adjust all the path names in the server's configuration files so they're relative to the new root directory.
Remember also the potential for "cascading" lawsuits if your system is used to attack another. If you can't repel every attack, at least ensure your audit files record information you'd need to trace malicious activity. Finally, ensure your Web server policy addresses:
code installation; administration/permissions; authentication; content and version control; patches/hot fixes/alerts; logging; e-commerce transactions; e-commerce transactions reporting; and privacy policy/personal information collection.
More information
Compare servers at http://www.serverwatch.com and also look for their current Web server survey. Want to know what your site says you're using? Go to http://www.netcraft.com, a nifty site for many Web server resources. For more on Apache, see http://www.apache.org. You can download and run the Microsoft Baseline Security Analyzer, which contains detection procedures for IIS, and the current version of the IIS Lockdown Wizard can be found here. If you use third-party add-ons like ColdFusion, PerlIIS or PHP, check their respective Web sites for patches and configuration tips.
About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to mailto:securityplanner@infosecuritymag.com.
Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.
