We Don’t Need No Extra Services
Beyond the HTTP service itself, many computers used as Web servers host a number of other network services. Perhaps the most common are FTP and SMTP. As a general security rule, try to avoid running these services on your Web server. In particular, avoid the default FTP and SMTP services in Microsoft IIS. Despite the convenience of integrated services, there is no reason to have Web, FTP and SMTP services interlinked. This is not an issue for Apache, since the Web server is not associated with FTP and SMTP services through a common administrative service. If you do use these services, be aware that they will advertise your IIS server's identity.

When a connection is established with an SMTP service, the recipient server sends a human-readable greeting to the client, the "SMTP banner". What the SMTP banner displays has no effect on e-mail service, but, like the HTTP Server header, it divulges details about the software running on the box. The default Windows SMTP service exposes such information. To find out how to change the SMTP banner, check here.

The default Microsoft IIS FTP server also presents a known banner. Since modifying the FTP banner is a more involved process than modifying the SMTP banner (plan on hacking several system DLLs), your best bet is an alternate FTP server like RhinoSoft's Serv-U FTP server that can display any text message in the FTP banner. As an added bonus, third-party FTP servers like Serv-U are more configurable than the IIS FTP service when it comes to security measures like assigning users their own login directories.

Unsanitary Inputs
Many platform-specific exploits use complex URL strings to gain access to a shell or CGI program, from which a hacker can easily get a directory listing revealing the OS’ default file structure. Once a shell or CGI program is hijacked and the file system revealed, the door is wide open. The best defense against this trial-and-error exploit is a user-input filter or "sanitizer" that removes unacceptable characters (such as meta-characters and their various possible encodings) from user-supplied data. For IIS, the current standard is IISLockDown/URLScan. A new generation of application firewalls extend this protection to the application layer behind the Web server. In the Apache world, user input sanitizing is traditionally the responsibility of CGI authors. Here is the classic CERT article on the topic, with examples in Perl and C. If you are setting up a new box, consider changing the default file structure as well. Input sanitizing and rearranged file structures do double duty -- helping to disguise the box and neutralize common exploits simultaneously.

Combing Through the Stacks
Even when all telltale signs are removed from your Web server's application layer, there remain detection weaknesses at lower network layers. Any server with a network connection has a network protocol stack subject to being scanned and identified. The best stack scanners (like NMAP from insecure.org) can ID most operating systems by using a variety of techniques to fingerprint the system's TCP stack. OS-specific IP stacks are also vulnerable to detection via the Internet Control Message Protocol (ICMP), used by the popular Ping utility. Good resources on ICMP vulnerabilities can be found here. The first line of defense against these kinds of network scanning vulnerabilities is a good, well-administered firewall. However, careful network analysis can still identify a box by examining the packets a firewall must permit a Web server to pass through in response to HTTP requests.

Netcraft is Watching
Take a look at the "What's that site running?" tool on Netcraft. If you point the site profiling tool at your own Web site, it will probably correctly report both your Web server and OS. Changing your HTTP Server header will cause Netcraft to report a false value for your Web server -- or just "unknown" if the header is completely removed (the change is not immediate, as Netcraft caches results for a time).

Still, your OS will probably be correctly identified -- even behind a good firewall. To get Netcraft to report your OS as "unknown", you will have to tinker with some of your default TCP/IP settings, such as the receive window size (RWIN), the maximum transmission units (MTU), the maximum segment size (MSS), and/or the IP header time-to-live (TTL). Altering these settings will affect your server's performance in diverse ways, depending on network conditions, so considerable care should be taken when changing these defaults. In the hands of a skilled network administrator, however, this strategy can be an effective countermeasure to information leakage through stack scanning.

Let's Be Careful Out There
No combination of detection avoidance succeeds in completely anonymizing your Web server -- just as no combination of firewalls, IDS, and other security countermeasures can completely defeat a skilled and determined cracker. Like server hardening, server anonymization can help defeat the majority of would-be attackers. And like all aspects of network security, it’s a never-ending battle to stay ahead of the bad guys.

About the Author
Joe Lima is the Director of Product Development for Port80 Software. He has worked for a variety of Internet, wireless and software development companies, specializing in research and development for server-centric technologies. Visit port80software.com.