Header Shadow Image


Web and Networking: Securing the Apache HTTPD (port 80) configuration from malicious scans.

It's still a surprise to most just how much scanning and probing by either hackers or malicious software is going on on the web when they do find out.  I mean, do you really know how many times your workstation or home network get's hit by attempted intrusions and invasions?  I was never able to find this sort thing out or to see it until I ran Linux.  This, imho, makes the Linux OS a bit more open to reporting such things, which is one of the things I like about it. 

Just recently looking over my logs I see there is a large 0-Day scan hitting boxes around the web with regards to the roundcube webmail application. The scan has been spreading over the web and has now been hitting my box since yesterday.  Initially I responded with an ad-hoc solution to this and I've blocked some IP's namely the ones below:

 92.48.127.158 – - [08/Jan/2009:04:52:44 -0500] "GET /nonexistenshit HTTP/1.1" 301 326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 – - [08/Jan/2009:04:52:45 -0500] "GET /mail/bin/msgimport HTTP/1.1" 301 330 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 – - [08/Jan/2009:04:52:45 -0500] "GET /bin/msgimport HTTP/1.1" 301 325 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 – - [08/Jan/2009:04:52:45 -0500] "GET /rc/bin/msgimport HTTP/1.1" 301 328 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 – - [08/Jan/2009:04:52:45 -0500] "GET /roundcube/bin/msgimport HTTP/1.1" 301 335 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
92.48.127.158 – - [08/Jan/2009:04:52:46 -0500] "GET /webmail/bin/msgimport HTTP/1.1" 301 333 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 – - [08/Jan/2009:05:08:59 -0500] "GET /nonexistenshit HTTP/1.1" 301 326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 – - [08/Jan/2009:05:09:00 -0500] "GET /mail/bin/msgimport HTTP/1.1" 301 330 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 – - [08/Jan/2009:05:09:01 -0500] "GET /bin/msgimport HTTP/1.1" 301 325 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 – - [08/Jan/2009:05:09:01 -0500] "GET /rc/bin/msgimport HTTP/1.1" 301 328 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
61.19.252.4 – - [08/Jan/2009:05:09:02 -0500] "GET /roundcube/bin/msgimport HTTP/1.1" 301 335 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"

But this is just one small set of them.  In addition to the above, earlier I've been noticing these as well:

209.163.188.49 – - [06/Jan/2009:17:19:00 -0500] "GET /user/soapCaller.bs HTTP/1.1" 301 330 "-" "Morfeus Fucking Scanner"
82.215.135.141 – - [27/Dec/2008:20:16:26 -0500] "GET /user/soapCaller.bs HTTP/1.1" 404 295 "-" "Morfeus Fucking Scanner"
78.109.23.224 – - [02/Jan/2009:06:24:46 -0500] "GET /user/soapCaller.bs HTTP/1.1" 301 330 "-" "Morfeus Fucking Scanner"

And these:

61.119.173.150 – - [30/Jan/2009:13:36:51 -0500] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 311 "-" "-"
195.250.148.253 – - [30/Jan/2009:14:11:34 -0500] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 311 "-" "-"
87.59.40.54 – - [30/Jan/2009:21:42:40 -0500] "GET http://proxytest.pr.funpic.de/ HTTP/1.0" 400 313 "-" "-"

and they just kept coming!  Some of the IP's can be blocked with these lines in iptables however these appear to come from infected systems themselves (ie victims):

$ iptables -A INPUT -s 195.184.65.90 -i eth0 -p tcp -m multiport –dports 80,25,110 -j REJECT –reject-with icmp-host-unreachable

Above iptables command line blocks the IP simulates an unavailble host, basically making your PC invisible to the IP you've blocked.  This can keep your box from getting scanned or attacked further from this IP, which is probably what you want.  However, unless you have the application the scans are probing or hackers are trying to exploit, likely you may not be vulnerable.  In the event your box is not mission critical, it may be worth stopping HTTPD on stand alone workstations just to be safe.  But run and hide isn't an option for all.  If you have the Apache HTTPD application or any other web server like IIS, try to apply paches or upgrade your version to the latest available from the owner of the app

One less noticable side effect of the above scans is that the foreign server is also exposing those IP's on the web actively running httpd, which could make victims prone for other attacks.  Not good!

OVERVIEW

The first basic way to keep your workstation secure is to have a good firewall.  Here's our how to on The Linux Firewall Configuration.  I took it upon myself then to secure my own Apache HTTPD installation with ModSecurity.  Turns out this was fairly easy and came out of the box, nearly fully configured.  This is an absolutely great module that anyone can install and I highly recommend it.  It's really like a firewall for your web applications and probably one of it's kind.  Below code will assume usage of the module.  More on this further down.

Following the above ModSecurity installation, I automated above with this little script that blocks IP's for a duration of time then unblocks after a certain amount of time has expired (one day or seven days, depending on severity and frequency), as in cases such as above (You can tweak the variables for your own tastes) Here are the features of the script:

  • Monitors the HTTPD log file from cron, ModSecurity and other traffic on port 80 / httpd.
  • Works from within HTTP ModSecurity using the
  • Starts a server.
  • Allows client connections to the server from non previlidged accounts.
  • Actively monitors, blocks and unblocks (After a period of time) offending IP's that match various criteria.
  • Keeps track of when IP's were blocked and unblocks them according attack frequency from a single IP.
  • Logs messages to various log files including messages, access_log with regards to what the script is doing.
  • A script remotely intelligent to be able to function as a server / client, be able to detect it's surroundings sufficiently and take different actions depending on it's running environment.
     

The script blocks the trouble IP's from scanning your system further and blocks the IP's of the attacking host for a length of time.  Of course as with any script, you will need to customize for your own tastes and needs and usage is at your own risk, as mentioned. 

To figure out where a hack came from, who has done it, etc, is a vast topic that I'll leave for another time.  I'm not particularly eager to setup a honey pot server or figure out who done it and start some sort of investigation.  Just interested in keeping these things from consistently hitting my workstation.

Currently, the attacks have been coming from the following locations, so it may be worth your time to check the scans from your location:

24.102.58.189
131.162.130.185
131.162.130.187
131.162.130.189
131.162.130.191
131.162.169.77
148.244.120.4
155.100.137.112
173.45.68.130
193.138.172.14
195.184.65.90
195.245.119.150
195.3.206.45
201.116.17.162
203.211.130.68
203.81.48.126
208.111.34.21
209.160.20.34
209.163.188.49
209.92.24.221
210.245.123.177
211.136.184.138
212.68.34.107
212.95.37.126
213.251.174.41
216.245.195.90
217.147.30.185
220.233.179.199
24.102.58.189
24.213.90.168
58.215.88.10
61.19.252.4
66.154.97.57
66.36.243.132
66.79.162.235
67.159.44.179
67.202.54.191
67.205.76.148
67.207.74.76
67.210.225.242
67.210.235.154
67.215.231.250
67.228.238.194
69.162.117.108
69.60.117.215
72.20.4.254
72.233.93.144
78.110.173.247
80.18.145.59
85.112.3.165
86.34.134.162
87.233.139.98
87.233.176.117
87.98.132.141
87.98.222.87
87.98.228.69
89.108.124.239
89.149.244.134
89.163.145.92
91.196.169.226
92.48.127.158
94.76.206.2
 

The script will continue to detect new intrusion attempts and block them as they happen.  Previously blocked IP's will be unblocked after one day (86400 seconds) or seven days (604800 seconds).  Script will reblock any previously blocked IP's if the same scan is again detected from an IP.  So it's a self-maintaining script, which, if no further attempts are detected, will unblock all the IP's it blocked.

As briefly mentioned earlier, in this case, the ideal solution would be to use mod_security which we will be briefly discussed here.  Naturally the Apache mod_security is a preferred way because it would be handling these at the time when they happen.  Before we look into adding rules for mod_security have a look at Apache: Configuring mod_security (modsecurity) for Apache on Fedora. for configuring the basic ModSecurity setup on your workstation prior to any custom ModSecurity configuration.

Below is a script to handle the above issues.

INSTALLATION

Reveiw then copy the script source found at the link below (as a .tar.gz file or .sh file, whichever) into some file such as /root/bin/imr.sh, set permissions and follow configuration instructions below:

http://microdevsys.com/WordPressDownloads/imr.sh
http://microdevsys.com/WordPressDownloads/imr.sh.tar.gz
 

 

 INSTALLATION ( crontab )

WARNING: This will block all non local IP's so you should take note before adding it to crontab.  If you need to customize which sorts of IP's you need to exclude/include, at this time you may need to modify the script to do so though I do plan to add the feature at some point in time.  

Here's how to add the script to run every 5 minutes within cron:

$ crontab -e
$ Add line "*/5 * * * * nice -n 10 /root/bin/imr.sh" to the configuration to run every 5 minutes.

The script will now scan your apache log files for any remote activity generated and take action.  Again, this isn't the best sort of option unless you want to block all non-local incoming IP's but is fine if you are doing some testing / development and don't want to have your box overly exposed on port 80 (HTTP). 

INSTALLATION ( ModSecurity )

This is the preferred means of handling such issues.  The problem IP is blocked when the incident happens and even prevents intrusion.  This script, as mentioned, supports a basic client/server model through nc.  In so doing, it can be used in ModSecurity to issue directives between HTTPD ModSecurity and the server which can then take action on an IP.  Here are the steps to set this up:

  • As before, ensure you copied above script into a folder somewhere accessible by root and now also by Apache HTTP such as /usr/bin/shared/imr.sh.
  • Run the script.  It should create a work folder under /tmp/ called imr.sh.  The folder may contain several files:
    imr.sh.log              # Script log messages, if script could not write to standard log files.
    imrArchive.txt        # List of all IP's encountered since script was initially ran.
    imrIPSet.txt            # List of currently blocked IP's coupled with the time when they were blocked.
  • Run /usr/bin/shared/imr.sh –server start to start the server:
    # /usr/bin/shared/imr.sh –server start
    #
  • Run /usr/bin/shared/imr.sh –server status to check that the server is running.
    # /usr/bin/shared/imr.sh –server status
    Tue Feb 3 13:56:42 EST 2009 Status of service on port 11235 is:
    Tue Feb 3 13:56:42 EST 2009 ONLINE and listening
    #
  • To stop the server at a later date, issue /usr/bin/shared/imr.sh –server start
  • Add the text in green below to the corresponding ModSecurity rule and file below:
    /etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf
    .
    .
    # Check that the host header is not an IP address
    #
    SecRule REQUEST_HEADERS:Host "^[\d\.]+$" "phase:2,t:none,deny,log,auditlog,status:400,exec:/usr/bin/shared/imr.sh,msg:'Host header is a numeric IP address', severity:'2',id:'960017',tag:'PROTOCOL_VIOLATION/IP_HOST'"
    .
    .
  • Optionally create your own rule inside this file or within your own file (Click links on below mind map mockup for an explanation of what they do in the rule):
    # cat /etc/httpd/modsecurity.d/modsecurity_localrules.conf
    # Drop your local rules in here.

     

    SecRule  REQUEST_URI_RAW "(/mail/bin/msgimport|/nonexistenshit|/bin/msgimport|/rc/bin/msgimport|/webmail/bin/msgimport|w00tw00t.at.ISC.SANS.DFind|proxytest.pr.funpic.de)" " phase:2,t:none,t:lowercase,t:normalisePath,deny,log,status:404,exec:/usr/bin/shared/imr.sh,msg:'RoundCube Webmail scan from %{REMOTE_ADDR}.  Blocked.  More on RoundCube Webmail found at http://roundcube.net.  See site for possible further news on this.',id:99999"
    #

  • Add the below lines to have the server started at each boot up time:
    # vi /etc/rc.d/rc.local
    .
    .
    .
    /usr/bin/shared/imr.sh –server start
    /usr/bin/shared/imr.sh –server status
  • You're done!

WORKING SAMPLE

Here is a few samples of how the script will work.  Recently, this attack occurred from 210.245.123.177 and here is what the script did:

# cat /var/log/httpd/access_log|grep 210.245.123.177
210.245.123.177 – - [29/Jan/2009:14:19:04 -0500] "GET /nonexistenshit HTTP/1.1" 400 304 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
#

The subseuent lines following the text /nonexistenshit no longer appear as we saw them above, which is a good sign.  Corresponding to the above, you should see a line similar to:

Thu Jan 29 14:19:05 EST 2009 imr.sh : (Blocking the IP) : Blocking IP:|210.245.123.177|

To test the rules, you can issue http://localhost/nonexistenshit and see if the rules, and script pick up the test intrusion:

Tue Feb 3 14:44:29 EST 2009 imr.sh: Invoked from ModSecurity. The following IP (127.0.0.1), if not local type, will be blocked.
Tue Feb 3 14:44:29 EST 2009 NOTE: Either the IP to block is local, or you are within modsecurity where iptables is inaccessible. No actions performed

CONCLUSION

I suppose there may be some sort of means available now to do this with another app however looking for some sort of functionality in the zoo of software packages available today seamed more daunting to me then simply writing one.  Best of all this gives me some sort of integrated option for keeping my workstation secure without having to cost me much of my time.  Just like doing things manually with a GUI firewall, I prefer to script this sort of stuff to decide on a best sort of action to take under certain conditions, keep my box secure and free my time for other stuff.

Hope you enjoy.  Don't forget to leave a comment.

HF! Cheers!

One Response to “Web and Networking: Securing the Apache HTTPD (port 80) configuration from malicious scans.”

  1. This is really useful article to make aware newbe about necessary security for their site or atleast how to be safe from some internet attacks that can destroy your server at any time. Furthermore, it is not time consuming.

Leave a Reply

 


     
  Copyright © 2003 - 2013 Tom Kacperski (microdevsys.com). All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License