
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 27 Nov 2017, at 03:59, <a href="mailto:tor@t-3.net">tor@t-3.net</a> wrote:<br><br></div><blockquote type="cite"><div><span>I spoke too soon, it seems - the exit is struggling again, with some time spent destroyed today.</span><br><span></span><br><span>As I look at what it's doing, it's clear that someone is relaying SYN packets</span></div></blockquote><div><br></div><div>It's not possible for Tor clients to relay SYN packets: a RELAY_BEGIN</div><div>cell from a Tor client asks an exit to attempt to open a TCP connection</div><div>from that exit to a remote destination. If the TCP connection fails, a</div><div>response is sent back to the client.</div><br><blockquote type="cite"><div><span>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.</span><br></div></blockquote><div><br></div><div>Have you tried adjusting your kernel parameters to recycle</div><div>local ports more quickly?</div><div><br></div><div>Do you have a separate IP address you can use for exit</div><div>connections, using OutboundBindAddressExit?</div><br><blockquote type="cite"><div><span>I'm going to reject a few more trojan listen ports, it might help but it isn't a real fix.</span><br></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">Have you tried one of the reduced exit policies?</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><font color="#000000" style="background-color: rgba(255, 255, 255, 0);"><a href="https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy" style="background-color: rgba(255, 255, 255, 0);">https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy</a></font></div></div><div><br></div><div>If you have, I suggest you reduce your exit policy down to a few</div><div>high-traffic ports. 80 and 443 are essential to support web</div><div>browsing. Other ports are nice, and you can experiment with</div><div>restoring them over time.</div><br><blockquote type="cite"><div><span>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.</span><br></div></blockquote><br><div>This isn't how Tor works: clients send RELAY_BEGIN cells to open</div><div>streams at exits, and these cells are encrypted at the guard.</div><div><br></div><div>Exits could rate-limit the number of streams per circuit (or the</div><div>number of stream requests), but this would only help if the</div><div>client is using the same circuit for its streams. And Guards</div><div>could rate-limit circuits. But this would be a long-term fix,</div><div>requiring code changes.</div><div><br></div><div>(Exits can't rate-limit per client, because Tor's design makes sure</div><div>Exits can't identify clients.)</div><div><br></div><div>T</div></body></html>