OMG. This is network security poetry. It is the most exquisitely beautiful solution to Denial of Service (DoS) attacks I’ve ever seen. If excessive connections are made to select ports in a certain timeframe, the source IP is added to an escalated list of iptables rules which eventually lock that IP out for over a month!
Initially I blocked attacks on an IP-by-IP basis, but this resulted in hundreds of separate iptables rules which as you can imagine became unwieldy quickly. Next, I implemented iptables rules using the iptables recent module (ipt_recent), which stopped attacks in a certain timeframe but did not prevent the same IP address from starting a new attack a short time later, scot free. The solution below keeps a long-term memory of offending IPs and thus really punishes attackers by putting their zombie hosts on the sidelines for a long time. It is also better than the IP-by-IP way I used to do it because after the longest ban (monthlong or whatever) expires, the IP is trimmed from the list.
Brilliant! I will soon adapt my rules to implement these clever ideas.
I have previously written a bit about using IPTables to limit brute-force attacks. For the past month, that system has been working quite well. The typical attack pattern resembled that in [graph 1, graph2]. A few days ago, however, an attack was implemented which ‘fell under the radar’, so to speak – instead of being a short-lived, high volume (60/min for 5 min) attack, this one was a slow and prolonged attack (1/2 min for 11 hrs) [graph 3, graph 4].
Improvements
Due to this, I have decided to augment my IPTables ruleset somewhat. There are a couple of points I found lacking in the previous revision. Firstly, repeat offenders did not have any extra consequences – whether you attacked for the first time or the tenth time, you were treated equally. Secondly, a slow attack was not effectively dealt with. Thirdly, the nature of the attack (quick vs slow) was not considered in the consequence. Finally, I wasn’t that pleased with the logging implementation – the log file was not exclusive, and no log rotation was setup. All of the above are addressed in this revision.
Source: Escalating Consequences with IPTables « That’s Geeky