Yes, I like to hide my webserver software information. What good does it do anyone anyway, other than the script kiddie, or his electronic minion, querying my server to determine where its holes might lie.
In Apache, it’s trivial to hide your server details. For example, your default server header might be:
Linux Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.3.0 Rivet FrontPage/5.0.2.2510 mod_perl/1.26
but changing just one directive in httpd.conf:
ServerTokens Prod
results in the following server info being provided:
Apache
Big difference, right? Find out what YOUR server is running: http://www.netcraft.com
There are also tools to make Microsoft IIS report that it is running Apache, like Server Mask from Port 80 Software. Talk about misleading the hackers!
For more information on why this is becoming more important, and how hackers are using your web server identity characteristics against you, see the excellent paper Detecting and Defending Against Web-server Fingerprinting by Dustin Lee, Jeff Rowe, Calvin Ko and Karl Levitt, of the UC Davis Computer Security Laboratory and Network Associates, Inc.
I finally got fed up with the level of spam coming into one of my accounts. I was spending half an hour every morning reporting them to SpamCop. The inspiration came when I noticed that SpamCop was showing that some of the spam sources I was reporting were already listed on open-relay or open-proxies databases. Why hadn’t I noticed this before? I put two and two together and realized that if I had been using these databases proactively, my server could have stopped the spam before it even reached me.
Most of my hosting is done on Cobalt servers, which are pretty much a standard Linux build with a hosting control panel and a bunch of other useful tools thrown on top. It took a little while to nail down the exact commands, but I understood the process:
First, locate the .mc file that was used to generate your sendmail.cf file. In standard Linux builds, this would be called sendmail.mc, but in the Cobalt, it was called cobalt.mc, and was located in /usr/lib/sendmail-cf/cf/.
Next, add the lines for the blacklists you wish to use. I was feeling aggressive and rather like an anti-spam vigilante, so I chose five different blacklists. On a heavy mail server, you might want to trim this down a bit, or you might not. Choosing blacklists is a highly personal decision and should be researched carefully. Some blacklists are more responsible about maintaining their data than others. Some are so strict that it’s nearly impossible to get a server de-listed, even after it has stopped sending or relaying spam. This causes headaches all around. I’m not naming names, I’ll just say I’m comfortable with this group:
FEATURE(`dnsbl’,`relays.ordb.org’, `Rejected - see http://ordb.org/’)dnl
FEATURE(`dnsbl’,`bl.spamcop.net’,`Rejected - see http://spamcop.net/’)dnl
FEATURE(`dnsbl’,`sbl.spamhaus.org’,`Rejected - see http://spamhaus.org/’)dnl
FEATURE(`dnsbl’,`blackholes.mail-abuse.org’,`Rejected - see http://mail-abuse.org/’)dnl
FEATURE(`dnsbl’,`dnsbl.njabl.org’,`Rejected - see http://njabl.org/’)dnl
Because of the way the M4 (macro processor, which expands the .mc file into a .cf file) was provisioned, I soon learned I had to execute the m4 command from the /usr/lib/sendmail-cf directory:
m4 /etc/mail/sendmail-new.cf
I deliberately didn’t overwrite my original sendmail.cf, because I wanted to make sure I had a backup first. Good thing I did, too, because rebuilding the sendmail.cf file broke pop-before-smtp, which I guess had been installed in a crude semi-automated manner by the Cobalt package. So I just took the lines in SBasic_check_relay from the blacklist version of sendmail.cf I created and inserted them in the proper section in my sendmail.cf. Then I stopped and restarted sendmail. The results speak for themselves.
The final result, which I could have started from, was adding the following lines at the END of the SBasic_relay_check section: (remember, sendmail.cf likes TABS, not spaces).
| # DNS based IP address spam list relays.ordb.org |
| R$* | $: $&{client_addr} |
| R::ffff:$-.$-.$-.$- | $: $(host $4.$3.$2.$1.relays.ordb.org. $: OK $) |
| R$-.$-.$-.$- | $: $(host $4.$3.$2.$1.relays.ordb.org. $: OK $) |
| ROK | $: OKSOFAR |
| R$+ | $#error $@ 5.7.1 $: Rejected - see http://ordb.org/ |
| # DNS based IP address spam list bl.spamcop.net |
| R$* | $: $&{client_addr} |
| R::ffff:$-.$-.$-.$- | $: $(host $4.$3.$2.$1.bl.spamcop.net. $: OK $) |
| R$-.$-.$-.$- | $: $(host $4.$3.$2.$1.bl.spamcop.net. $: OK $) |
| ROK | $: OKSOFAR |
| R$+ | $#error $@ 5.7.1 $: Rejected - see http://spamcop.net/ |
| # DNS based IP address spam list sbl.spamhaus.org |
| R$* | $: $&{client_addr} |
| R::ffff:$-.$-.$-.$- | $: $(host $4.$3.$2.$1.sbl.spamhaus.org. $: OK $) |
| R$-.$-.$-.$- | $: $(host $4.$3.$2.$1.sbl.spamhaus.org. $: OK $) |
| ROK | $: OKSOFAR |
| R$+ | $#error $@ 5.7.1 $: Rejected - see http://spamhaus.org/ |
| # DNS based IP address spam list blackholes.mail-abuse.org |
| R$* | $: $&{client_addr} |
| R::ffff:$-.$-.$-.$- | $: $(host $4.$3.$2.$1.blackholes.mail-abuse.org. $: OK $) |
| R$-.$-.$-.$- | $: $(host $4.$3.$2.$1.blackholes.mail-abuse.org. $: OK $) |
| ROK | $: OKSOFAR |
| R$+ | $#error $@ 5.7.1 $: Rejected - see http://mail-abuse.org/ |
After releasing the previous article on battling HTTP floods, I decided that a more aggressive approach was in order, one that didn’t rely on me getting out of bed to stop the attack in its tracks. I did some more research, and came across a couple of very powerful tools for Apache:
mod_dosevasive maintains its own IP and URL request database, and will deny repeated requests for the same URL by the same IP within a short period of time. This is particularly useful when your flooder knows enough about web servers to launch an especially resource-intensive CGI, because after the first couple, the CGI will no longer launch, he will just be thrown an HTTP error.
mod_security is a much more configurable solution, designed to stop specific types of attacks in their tracks, for example SQL injection hacks, administrative script attempts, etc.
I highly recommend that Apache users take a look at these two fine modules. Both are installable as DSOs, which means you won’t have to recompile Apache to install them.
