Re: [tor-relays] Pretty sure our exit was being synflooded
> On 27 Nov 2017, at 03:59, t...@t-3.net wrote: > > I spoke too soon, it seems - the exit is struggling again, with some time > spent destroyed today. > > As I look at what it's doing, it's clear that someone is relaying SYN packets It's not possible for Tor clients to relay SYN packets: a RELAY_BEGIN cell from a Tor client asks an exit to attempt to open a TCP connection from that exit to a remote destination. If the TCP connection fails, a response is sent back to the client. > to random ports and also random destination addresses that aren't even alive. > The destination hosts and ports continually vary - it never hits multiple > destinations on 1 port, and it does not hit multiple ports on 1 host. I > presume it is an attack that is intended to degrade this relay's service > quality, or otherwise more broadly, degrade Tor. Have you tried adjusting your kernel parameters to recycle local ports more quickly? Do you have a separate IP address you can use for exit connections, using OutboundBindAddressExit? > I'm going to reject a few more trojan listen ports, it might help but it > isn't a real fix. Have you tried one of the reduced exit policies? https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy If you have, I suggest you reduce your exit policy down to a few high-traffic ports. 80 and 443 are essential to support web browsing. Other ports are nice, and you can experiment with restoring them over time. > My thought btw was for Tor to rate-limit syn scanning activity between the > client and the first onion router, with the function taking place in that > first-hop router, not at the exit. This isn't how Tor works: clients send RELAY_BEGIN cells to open streams at exits, and these cells are encrypted at the guard. Exits could rate-limit the number of streams per circuit (or the number of stream requests), but this would only help if the client is using the same circuit for its streams. And Guards could rate-limit circuits. But this would be a long-term fix, requiring code changes. (Exits can't rate-limit per client, because Tor's design makes sure Exits can't identify clients.) T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pretty sure our exit was being synflooded
I spoke too soon, it seems - the exit is struggling again, with some time spent destroyed today. As I look at what it's doing, it's clear that someone is relaying SYN packets to random ports and also random destination addresses that aren't even alive. The destination hosts and ports continually vary - it never hits multiple destinations on 1 port, and it does not hit multiple ports on 1 host. I presume it is an attack that is intended to degrade this relay's service quality, or otherwise more broadly, degrade Tor. I'm going to reject a few more trojan listen ports, it might help but it isn't a real fix. My thought btw was for Tor to rate-limit syn scanning activity between the client and the first onion router, with the function taking place in that first-hop router, not at the exit. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pretty sure our exit was being synflooded
> On 26 Nov 2017, at 21:06, t...@t-3.net wrote: > > Thanks for the configuration suggestions. I intentionally set the conntrack > limit high, maybe that was not the best thing. I think I'll be putting it > back. > > Removing my extra IPTables code plus adding a reject for : has made the > exit behave properly again. > > I wonder if the best possible course of action for this sort of thing would > be within Tor itself. I don't know that it was a single client connection > into Tor that was causing all this trouble, but maybe it was. One would think > that one client should not be allowed to do something so severe with the TCP > that it can single-handedly ruin a fast exit. Maybe a code change that forces > a rate-limit that significantly slows down the ability of a single client to > roll port scans should be considered by the devs. Tor has code that limits the bandwidth of a single circuit, but it isn't active because the consensus parameter isn't set. But I think you're talking about limiting the number of streams per circuit (no existing code for that). Or limiting the number of circuits per client, which is very hard, because the exit doesn't know which circuits belong to the same client. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pretty sure our exit was being synflooded
Thanks for the configuration suggestions. I intentionally set the conntrack limit high, maybe that was not the best thing. I think I'll be putting it back. Removing my extra IPTables code plus adding a reject for : has made the exit behave properly again. I wonder if the best possible course of action for this sort of thing would be within Tor itself. I don't know that it was a single client connection into Tor that was causing all this trouble, but maybe it was. One would think that one client should not be allowed to do something so severe with the TCP that it can single-handedly ruin a fast exit. Maybe a code change that forces a rate-limit that significantly slows down the ability of a single client to roll port scans should be considered by the devs. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pretty sure our exit was being synflooded.
syncookies and -m connlimit limiting /24 always worked for me. some players with access to /24 can be pretty annoying sometimes. x9p > Was anyone else's exit being synflooded yesterday and today? I put > some iptables code in to help, it might have mitigated it. > > I'm pretty sure our exit "Libero" was being synflooded. > > Managed to lose all our flags shortly after the instability was > (finally) resolved, go figure =p > > > > > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pretty sure our exit was being synflooded.
Same happened to me. ISP sent me 2 messages in 10 minutes about outgoing 8Kpps/4Mbps flood and then quickly frozen my VPS. 2017-11-25 2:02 GMT+02:00 Paul Templeton <p...@coffswifi.net>: > Happening to middles as well - I get black hold all the time - ISP has > auto rules. > > Paul > > - Original Message - > From: t...@t-3.net > To: tor-relays@lists.torproject.org > Sent: Saturday, November 25, 2017 10:23:24 AM > Subject: [tor-relays] Pretty sure our exit was being synflooded. > > Was anyone else's exit being synflooded yesterday and today? I put > some iptables code in to help, it might have mitigated it. > > I'm pretty sure our exit "Libero" was being synflooded. > > Managed to lose all our flags shortly after the instability was > (finally) resolved, go figure =p > > > > > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Pretty sure our exit was being synflooded.
Happening to middles as well - I get black hold all the time - ISP has auto rules. Paul - Original Message - From: t...@t-3.net To: tor-relays@lists.torproject.org Sent: Saturday, November 25, 2017 10:23:24 AM Subject: [tor-relays] Pretty sure our exit was being synflooded. Was anyone else's exit being synflooded yesterday and today? I put some iptables code in to help, it might have mitigated it. I'm pretty sure our exit "Libero" was being synflooded. Managed to lose all our flags shortly after the instability was (finally) resolved, go figure =p ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
