I am begining with network security and after studying for a while about often used technologies I got to this architecture for my home server (sorry it is not in english).

I considered 3 basic general security principles for this 2:

  • Defense in-depth (many security barriers backing each other up)
  • Choking point (a narrow channel through which the attacker must pass)
  • Minimum privilege (any object should only expose the necessary and nothing else)

A restriction is that I can use no other physical machines at first. There are also no other machines in this subnetwork. All those components should be kept in the same ubuntu server. The components are mainly based on 3:

  • Firewall (iptables) > implemented in order to protect the network against external threats.
  • IDS (Snort) > establishes rules for network monitoring in case the external attacker bypasses the firewall
  • fwsnort > a tool to convert snort rules into iptables rules
  • psad > a tool for iptables log monitoring with e-mail alerting resource
  • Honeypots (Artillery) > along many other functionalities, Artillery is used here as a honeypot to deceipt attackers and allow me to get info about them.

Host-based security components for a web server

Some questions:

  • Will this architecture be effective?
  • Are honeypots a good idea?
  • If so, should I run them on a VM?
  • Can I guarantee QoS? Or will my server be overloaded?
  • What else am I missing (about anything related)?

1 Answer 1


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.

Packets data flow

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:

#ipset banned_nets must already exist


    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

while true #run indefinitely 
     inotifywait -e modify $AUTO_BLOCKED_IPTABLES_PATH | update_set

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .