Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
> From: igor.n.mitrofa...@gmail.com > Sorry for the spam. One more link to a tuning guide that I have found Contributions are good but since we're on the same list how about trimming quoted messages? ___ 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 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] Detecting Network Attack [re: exit synflooded]
On Sat, Nov 25, 2017 at 5:15 PM, teor wrote: > need a privacy-preserving aggregation scheme > (Otherwise, anyone who can remotely trigger a rare protocol > violation can find out which relays a client or onion service is using.) The above don't necessarily lead to each other. > scheme in Tor so we can do these counts That's thinking of 'in tor' code, which is good way and project to see some things only visible there, and way to count and submit them over tor. I'm more thinking using external tools to watch the network interface itself... Attackers will read / fuzz the source code till they exploit via tor's open ports anyway. Though it could still be good to instrument those ports with both tor protocol analyzer, and a raw packet statistical analyzer / classifier to see what's incoming. Instrumenting the IP itself to look for debilitating inbound packet bursts from the internet indicating node pruning segmentation attacks. Would be interesting discovery. Though attackers might find the method redundant given already ways to deanon hidden services and fewer to deanon users. And all the usual IDS type of tools that could be deployed and collected to see who / what is probing away at the network itself and how. Might want to look for modulation patterns in OR traffic proving existance of certain known attack methods. Not talking about content of exit traffic in any of this. It's exposing attacks from clearnet, not users of tor. Operators could opt in. Prebuilt tool packages could be created. Someone with a handful of relays could always do the research project on their own, and like silent attackers, may already be. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Detecting Network Attack [re: exit synflooded]
> kernel: nf_conntrack: table full, dropping packet If rules are dropping exit traffic based on other than traffic content, it's very hard to say other users are not adversly affected with the same, likely quite unsophisticated, hammer. And doing it based on content usually comes with major legal hurdles, besides being arbitrary. And both ways can get you dropped with badexit flag. Further, kernel dropping of packets is not signaled back into tor daemons for exitpolicy management therein, much less back to clients to avoid the censorship. And dropped packets hurts performance. Exitpolicy reject is the preferred method. Don't like the exit traffic, don't advertise to clients that you will carry it outbound in the first place. Please move this talk about tor exit traffic to a new thread or put it back to the first one where it came from. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
