TCP SACK PANIC type kernel vulnerabilities: logging some packets
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?
-- Toralf PGP C4EACDDE 0076E94E
participants (2)
-
tor＠t-3.net -
Toralf Förster