Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

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 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 8000Listen 8080Listen 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.comDocumentRoot "/usr/local/apache/honeypot-htdocs"<Directory "/usr/local/apache/honeypot-htdocs">    Options none     AllowOverride None    Order allow,deny    Allow from all</Directory>SecAuditEngine OnSecAuditLog "|/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.

Latest SpiderLabs Blogs

Search & Spoof: Abuse of Windows Search to Redirect to Malware

Trustwave SpiderLabs has detected a sophisticated malware campaign that leverages the Windows search functionality embedded in HTML code to deploy malware. We found the threat actors utilizing a...

Read More

The Sentinel’s Watch: Building a Security Reporting Framework

Imagine being on shift as the guard of a fortress. Your job is to identify threats as they approach the perimeter. The more methods you have for detecting those threats, the better your chances of...

Read More

Fake Advanced IP Scanner Installer Delivers Dangerous CobaltStrike Backdoor

During a recent client investigation, Trustwave SpiderLabs found a malicious version of the Advanced IP Scanner installer, which contained a backdoored DLL module. Our client had been searching for...

Read More