[tor-relays] Pretty sure our exit was being synflooded

[teor]

> On 27 Nov 2017, at 03:59, tor at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171127/92ce5a7a/attachment.html>