Hi Griffin, my comments below.
On 11/20/12 3:11 PM, Griffin Boyce wrote: > Hi Fabio, > > To recap the discussion for everyone else, we were talking about > blocking portscans on exit nodes. While it's possible to block a > targeted portscan by limiting what ports can be accessed in iptables, > blocking a broad vulnerability scan with many targets is trickier. > > I'm rather curious as to how a circuit would be effectively defined in > this case. While Tor circuits do rotate every 10mins, it wouldn't > really be possible to map traffic to a single abusive user. It would be > more of a guess. So instead any rules apply to everyone using the exit > node. > > One solution could be something like either: > iptables -A inbound -p tcp -m state --state NEW -m limit \ --limit > 5/s --limit-burst 3 -j ACCEPT > iptables -A outbound -p tcp -m state --state NEW -m limit \ --limit > 5/s --limit-burst 3 -j ACCEPT This would not scale for two reason: 1 - This is not specifically targeting "Exit Traffic" because currently there is no way to distinguish between OR traffic and Exit Traffic. 2 - This would hurt "valid traffic too" because it's absolutely reasonable for a 10Mbit Tor Exit Node to have big spike of new connections So a "polite" approach to "block/mitigate" outgoing portscan should goes: - only match Tor Exit Node traffic (and not Tor Relay or Directory traffic) - be dynamic, in order to handle normal burst of traffic On 1st point we would probably need some kind of Tor patch to have "ExitAddress" configuration settings in a similar way to "OutBoundAddress" (that also does OR/relay traffic). On 2nd point, it's a quite complicated stuff, as we need some-how need to link iptables actions to the originating Tor-client activity, otherwise we will hurt real user traffic. What do you think? Fabio _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
