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.
On 27 Nov 2017, at 03:59, tor@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@lists.torproject.org
-
teor -
tor＠t-3.net