On 2013-10-29 08:00:53 (-0700), Gordon Morehouse wrote: > > 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')? I don't think so. *glances over the iptables man page* Ah, check the 'recent' module ;). Seems to be what you need to get rid of fail2ban. After playing with it for a while I got this: iptables -N RECENT iptables -I INPUT 1 -p icmp -s somehost -j RECENT iptables -A RECENT -m recent --name pa --rcheck --seconds 10 -j DROP #iptables -A RECENT -j LOG --log-prefix "not recent dropped: " iptables -A RECENT -m limit --limit 2/s --limit-burst 2 -j ACCEPT #iptables -A RECENT -j LOG --log-prefix "rate limited, set recent: " iptables -A RECENT -m recent --name pa --set -j DROP Then: user@somehost $ ping -i 0.3 172.26.8.85 PING 172.26.8.85 (172.26.8.85) 56(84) bytes of data. 64 bytes from 172.26.8.85: icmp_req=1 ttl=63 time=0.286 ms 64 bytes from 172.26.8.85: icmp_req=2 ttl=63 time=0.264 ms 64 bytes from 172.26.8.85: icmp_req=3 ttl=63 time=0.255 ms 64 bytes from 172.26.8.85: icmp_req=37 ttl=63 time=0.263 ms 64 bytes from 172.26.8.85: icmp_req=38 ttl=63 time=0.282 ms 64 bytes from 172.26.8.85: icmp_req=39 ttl=63 time=0.292 ms 64 bytes from 172.26.8.85: icmp_req=73 ttl=63 time=0.278 ms 64 bytes from 172.26.8.85: icmp_req=74 ttl=63 time=0.287 ms 64 bytes from 172.26.8.85: icmp_req=75 ttl=63 time=0.283 ms ^C --- 172.26.8.85 ping statistics --- 89 packets transmitted, 9 received, 89% packet loss, time 27031ms rtt min/avg/max/mdev = 0.255/0.276/0.292/0.022 ms You want the '-j RECENT' rule in chain INPUT not to be in position 1, but after the '--state ESTABLISHED' one, otherwise it will affect your established circuits. I suggest you play with this in another box, then edit the relay firewall accordingly when you're comfortable (consider that I limited my test to ICMP packets from a specific host while you're going to check everything). I'm afraid further questions on this (or even this very message) could be considered off topic, though. Lastly, this may give additional ideas: http://thiemonagel.de/2006/02/preventing-brute-force-attacks-using-iptables-recent-matching/ -- David Serrano GnuPG id: 280A01F9
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays