I have recently implemented this solution and tested it using 3 VMs. The attacker uses Kali, the web server uses Ubuntu 14.04 and the honeypot actually uses HoneyDrive 3. I had to change it a little bit.
So basically what this architecture does is receive a packet, check it agains the firewall (iptables) rules and log it. Fwsnort converts Snort rules into iptables rules, making the firewall a kind of IPS. The log monitor (psad) then analyses the log, identify malicious IPs and block then. From this point on, every incoming packet from these IPs will be forwarded to the Honeypot.
Here are the main rules that do it:
###### forwarding ######
ipset create banned_nets hash:ip hashsize 4096
iptables -t nat -A PREROUTING -p tcp -m set --dport 8181 -j DNAT --to-destination $HONEYPOT_ADDR:443 --match-set banned_nets src
iptables -t nat -A POSTROUTING -p tcp -s $HONEYPOT_ADDR --dport 443 -j SNAT --to-source $SERVER_ADDR:8181
iptables -t nat -A PREROUTING -p tcp -m set -j DNAT --to-destination $HONEYPOT_ADDR --match-set banned_nets src
iptables -t nat -A PREROUTING -p udp -m set -j DNAT --to-destination $HONEYPOT_ADDR --match-set banned_nets src
iptables -t nat -A POSTROUTING -p tcp -m set -j SNAT --to-source $SERVER_ADDR --match-set banned_nets src
iptables -t nat -A POSTROUTING -p udp -m set -j SNAT --to-source $SERVER_ADDR --match-set banned_nets src
echo "[+] Activating IP forwarding"
echo 1 > /proc/sys/net/ipv4/ip_forward
I had to update the tricky part of forwarding blocked IPs. At first, psad would only drop packets incoming from blacklisted IPs. These IPs are listed in auto_blocked_iptables text file. So I wrote a script to get these IPs and insert them in an ipset. I called this the update_daemon With this feedback mechanism the firewall is able to forward packets by checking their origin with the ipset elements.
Here is how I did it:
#!/bin/bash
#ipset banned_nets must already exist
AUTO_BLOCKED_IPTABLES_PATH=/var/log/psad/auto_blocked_iptables
update_set(){
ipset flush banned_nets
grep -E -o '^([0-9]{1,3}[\.]){3}[0-9]{1,3}' $AUTO_BLOCKED_IPTABLES_PATH | while read -r line ; do
echo "Processing $line"
ipset add banned_nets $line
done
}
while true #run indefinitely
do
inotifywait -e modify $AUTO_BLOCKED_IPTABLES_PATH | update_set
done
The hole project is available at 2.
So answering my own questions:
Will this architecture be effective?
Yes, it does forwards pre identified attackers to a honeypot, then protecting the server.
Are honeypots a good idea?
Honeypots seem to be an interesting idea. With a honeypot we can better understand the attacker, his methods, main targets, exploits, wordlists and a lot more.
If so, should I run them on a VM?
According to 3, running honeypots in VMs does is a good idea. Since honeypots are supposed to be low interactive, they do not require too much hardware resource. On the other hand, the system gets vulnerable to vulnerabilities in the honeypot software and in the VM itself.
Can I guarantee QoS? Or will my server be overloaded?
I did not test sufficiently the system for QoS. Still it seems to me the forwarded traffic will increase data flow.
What else am I missing (about anything related)?
Forwarding is not so simple as it seems the server must act as a transparent proxy and the update_daemon was a tricky part, since it dynamically monitors a file.
Also, the solution does not shows good results when suffering DoS attacks. In this case the best option seems to be removing the honeypot and just dropping the attacker. This partial solution is also available at GitHub.
You will find more information at 2 and 4
