Setting HoneyTraps with ModSecurity: Unused Web Ports

This blog post will show an easy configuration update that you can make to your web servers running ModSecurity so that you can catch automated web attack tools that are scanning IP network ranges looking for web ports.

Instead of developing and deploying an entirely new honeypot web server or application, we can easily reuse the existing legitimate web server platform you are already running. We will implement our honeytrap by adding more network ports that will accept HTTP request traffic. These ports have no legitimate purpose, so any traffic we receive is suspect by definition. This blog post shows you how to enable these honeytrap ports using the Apache web server. This process, however, can be duplicated on any other web server software.

Apache Listen Directive

The Apache Listen directive allows us to define on which port(s) or IP address and port combinations we want to accept incoming requests. By default, the httpd.conf file enables one Listen directive that listens on the standard HTTP port 80:

#
# Listen: Allows you to bind Apache to specific IP addresses and/or 
# ports, instead of the default. See also the  
# directive. 
# 
# Change this to Listen on specific IP addresses as shown below to 
# prevent Apache from glomming onto all bound IP addresses. 
# 
#Listen 12.34.56.78:80 
Listen 80

For our honeytrap port implementation, we want to add Listen ports to catch auto- mated attack probes that are scanning our IP address space, looking for web services. There are three other common alternative HTTP ports:

• 8000
• 8080
• 8888

We can now add the following new Listen directives to tell Apache to open listeners on these ports:

#
# Listen on additional honeytrap ports: 
# - 8000 
# - 8080 
# - 8888 
# 
Listen 8000 
Listen 8080 
Listen 8888

ModSecurity Rule To Tag Malicious Client

We now add a new ModSecurity rules file that instructs Apache to listen on these new ports and then generate alerts on all traffic:

# 
# Generate Alerts for all requests that we receive and 
# set a variable in the IP Collection to mark the client 
# as malicious. 
# 
SecRule SERVER_PORT "^(8000|8080|8888)$" \
"id:'999004',phase:2,t:none,log,block,msg:'HoneyTrap Alert: Traffic Received on Fake Port.',\
setvar:ip.malicious_client=1"

Notice the bold setvar action at the end of the rule?  If a client sends any traffic to this port, we set a variable in the IP persistent storage collection that flags this client as malicious.

Check Malicious Tag on Real Web Site

The advantage of this approach is that we can quite easily identify automated malicious clients and then use this intelligence within ModSecurity rules for our normal production web application. Here are some sample rules that you could include in your ruleset that alert and block based on the existence of the ip.malicious_client variable:

# 
# Check IP Collection for the ip.malicious_client variable. 
# 
SecRule &IP:MALICIOUS_CLIENT "@eq 1" \
"id:'999005',phase:2,t:none,log,block,msg:'HoneyTrap Alert: Known Malicious Client.'"

This honeytrap port technique serves as an early warning system for your real application, because you know that a client is most likely malicious as soon as she sends a request. With this intelligence, you may choose to block the client immediately or place him on a watch list and increment an anomaly score. 

WASC Distributed Web Honeypots Project Participation

While this "Honeypot Port" technique works fine on its own, we are encouraging ModSecurity users to help with shared intelligence by using the following configurations to participate within the Web Application Security Consortium (WASC) Distributed Web Honeypot Project.  We recently added some honeypot configurations to the OWASP ModSecurity CRS to allow the ModSecurity user to easily contribute data to the project.  The main difference between this configuration and the one presented in the previous section is that the ModSecurity audit log data generated by these alerts is automatically forwarded to the central WASC honeypot console for analysis by the project team.

Here are the contents of the modsecurity_crs_10_honeypot.conf file:

#
# Add in honeypot ports.  
# - These are common proxy ports used by attackers
# - All traffic accepted on these ports are suspicious.
# 
Listen 8000
Listen 8080
Listen 8888

#
# Create basic virtual host containers that will forward all traffic received
# to the official ModSecurity Project honeypot logging host.
#
# - You should adjust the Document root location to an empty directory on your server
# - Also adjust the path to your local ModSecurity mlogc program and for the 
#   mlogc-honeypot-sensor.conf file.
# - Make sure you main SecAuditLogType is set to concurrent mode.
#
<VirtualHost *:8000 *:8080 *:8888>
ServerName www.example1.com
DocumentRoot "/usr/local/apache/honeypot-htdocs"
<Directory "/usr/local/apache/honeypot-htdocs">
    Options none 
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
SecAuditEngine On
SecAuditLog "|/usr/local/apache/bin/mlogc /usr/local/apache/conf/mlogc-honeypot-sensor.conf"
</VirtualHost>

This virtual host setup will forward all alerts for this site to the central WASC honeypot logging host using the ModSecurity mlogc client program.  The beauty of this approach is that the ModSecurity admin does not have to worry about sanitizing any potentially sensitive user data as they would with forwarding ModSecurity alerts generated from protecting the real web application.  Due to the fact that there is no web application at all being hosted on these ports, the traffic will not be a real user.  With this configuration in place, the ModSecurity audit log data is automatically forwarded to the WASC logging host.  Here is an example of an event received from a test honeypot when it received an RFI attack:

Please consider activating this honeypot configuration and contributing data to the WASC Distributed Web Honeypot Project.  By deploying these sensors, we will be more able to identify new attack trends and notify the community.

Comments

[Ryan Barnett]

If you are are using the OWASP ModSecurity CRS the setup config file checks for those proxy headers - https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/modsecurity_crs_10_setup.conf.example

You could update the rules to check TX:REAL_IP instead of REMOTE_ADDR.

[Gérard Le Comte]

Hi Ryan,
What can You do use X-Forwarded-For Http header instead of the IP address when the suspicious trafic comes from a proxy (or Akamai like Internet service)?
Regards
Gérard