Posted by enduser666 on May 2, 2009
Even if you’re just a casual site administrator who isn’t responsible for safeguarding masses of sensitive corporate data, you need to be concerned about security. The widespread impact of the Code Red and Nimda worm viruses is the latest evidence that security remains an afterthought in too many cases.
Not only do all Web servers have some security holes, but in the end, keeping corporate data and resources safe from snooping, intrusion, or misuse is about people and processes as much as it is about products. Installing a high-quality deadbolt lock on the door of your house won’t do much good if you leave the key right under the mat.
The topic of security fills entire books, but here we summarize a few basic measures that anyone running a Web server should consider essential.
1. Don’t run unnecessary servers or interpreters. If you don’t need the FTP (File Transfer Protocol) server that’s bundled with your Web server, don’t give hackers another target: Disable it, or don’t install it at all. Similarly, disable scripting languages and sample scripts that you don’t absolutely require.
2. Subscribe to your server vendor’s security alert list. Or at least monitor its Web site regularly for patches and apply them immediately. The Computer Emergency Response Team advisory list at http://www.cert.org/advisories/ can be a useful resource. Don’t forget to watch out for alerts and patches for your OS as well as for the Web server itself.
3. Practice good password habits. Avoid simple, easy-to-guess passwords, particularly for privileged administrator accounts. On the other hand, don’t make your password rules so draconian that users resort to writing them down. Always change default passwords and eliminate unnecessary accounts (such as guest). Make sure passwords are actually enabled for sensitive areas and administration functions.
4. Know what’s happening on your network. Many Web servers are free and easy to install, so watch out for well-meaning but ill-informed users who may inadvertently create security holes.
5. Use your operating system’s permission mechanism. Usually the Web server runs with the permission of a particular user. Make sure that user has appropriately limited access.
6. Monitor your logs. Your Web server keeps track of every request; review your logs regularly for signs of out-of-the-ordinary behavior.
7. Segregate public and private data. Don’t store sensitive data on the same machines as public Web servers if you don’t have to do it. For an extranet, you might consider a “sacrificial lamb” configuration, where a Web server sits outside the firewall so that it doesn’t jeopardize corporate data behind the firewall.
8. Be careful with your server configuration. Limit executable files to specific directories, and make sure their source codes can’t be downloaded. Turn off features such as automatic directory indexing and WebDAV publishing support if you don’t need them. Run any security tools your OS or Web-server vendor provides, such as Microsoft’s IIS Lockdown Tool, to identify potential weak spots.
9. Check programs for security holes. CGI scripts on Web servers are particularly prone to security breaches, especially if they don’t validate user-supplied data before accessing files or operating-system services.