Web Application Defender's Cookbook

Recipe 14-7: Proxying Traffic to Honeypots

This recipe shows you how to use ModSecurity’s proxy action to transparently forward traffic to a separate honeypot web application.

Ingredients

• ModSecurity
  • setvar action
  • proxy action

Recipe 14-6 demonstrated how to use deception methods to make our web application appear to be vulnerable to SQL Injection. We can take this concept a step further and choose to send identified attacker traffic away from our site and instead have attackers transparently interact with a separate web honeypot application system.

One method of implementing this proxy technique is to simply modify the existing anomaly scoring evaluation rule. By adding the following directive to our configuration, if the anomaly score value for a transaction exceeds our threshold, it sets a new variable in the IP persistent storage:

SecRuleUpdateActionById 981176:3 "setvar:ip.proxy_to_honeypot=1"

This updated rule flags malicious traffic from this client and sets the IP variable. Any future requests from this client then trigger the following rule, which proxies the connections to our honeypot web application at IP address 192.168.1.110:

SecRule IP:PROXY_TO_HONEYPOT "@eq 1" "id:'999888',phase:2,t:none,
log,msg:'Proxying Known Attacker Traffic to Honeypot Host.',
proxy:'http://192.168.1.110%{REQUEST_URI}'"

To test how these rules work, let’s look at an example where a malicious client starts a SQL Injection attack against our WordPress login page. We receive the following ...