-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
David Serrano:
On 2013-10-27 16:35:43 (-0700), Gordon Morehouse wrote:
And, after the boot, I've simulated an aggressive host from another machine using hping, and here's the output of 'iptables -L' after fail2ban banned the host (LAN IP partly redacted to settle my paranoia): http://pastebin.com/1L62z23b
That resulting ruleset will break circuits. Packets from flooding hosts won't have a chance to reach the '--state ESTABLISHED' rule since they are dropped before that, from within the fail2ban-tor-syn-flood chain.
Thanks - I really don't understand yet with iptables how to tell in what order the chains are processed.
However, do you need fail2ban now that you are throttling SYNs without affecting circuits?
Uncertain. I'd added it as an adjunct to the throttling, hoping a temporary placement into the DROP chain would save cycles and memory as REJECT ICMP packets would no longer be sent
But you can drop packets in the SYN_THROTTLE chain instead of rejecting them, without fail2ban. Or you can accept them until a threshold is reached, then log/reject them up to a second threshold, then silently drop them.
Currently this is how it works:
1. accept to the 3/sec burst 6, then reject (iptables) 2. 4 logs of iptables reject in 75 sec = 90 sec ban (fail2ban)
I'd love to do all of the above purely in iptables and eliminate fail2ban, but is it capable of maintaining state like that (e.g. the 75 second 'watch time' and 90 sec 'ban time')?
This is very new to me, I've always used off-the-shelf iptables-based packages. If there are docs I should read which cover this use case without me having to read for 2 hours before I get there, I'd really appreciate a link. And I say that not to be a jerk, but because my time is stretched really really thin.
Thanks for all your iptables help. You'll definitely be credited.
Best, - -Gordon M.