[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] max TCP interruption before Tor circuit teardown?



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