As of last week there wasn't a new kernel out for our relay's distro, so I implemented an IPTables-based mitigation in our relay as such:
-A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j LOG --log-prefix "TCP_SACK_PANIC: " -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
Over the weekend we logged hits to this rule. I checked a few of the source hosts, and they were not relays at least as they are listed in https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 .
I'll pull the rule out once the kernel is patched, but yeah. Things that make you go hmm.
Hi,
On 6/24/19 2:13 PM, tor@t-3.net wrote:
As of last week there wasn't a new kernel out for our relay's distro
switch to Gentoo Linux :-)
-A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j LOG --log-prefix "TCP_SACK_PANIC: " -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
Interesting - never thoughtm that iptables is able to do that - the doubled SYN is needed, right?
Over the weekend we logged hits to this rule. I checked a few of the source hosts, and they were not relays at least as they are listed in https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 .
Whilst I gave up loging IPs at all - why didn't you checked non-exit relays?
tor-relays@lists.torproject.org
-
tor＠t-3.net -
Toralf Förster