Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SACK Panic – Multiple TCP-based remote denial-of-service issues

access.redhat.com

Post reply on HN
Print view View original

111–120 of 134 posts

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#111

Post by isodude »

LinuxBender wrote: post #25

This is the way I block such things on my own VM's (not at work) using iptables: iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP Here it is in action: iptables -L -n -v -t raw | grep mss 84719 3392K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 tcpmss match !640:65535 My settings may be a little aggressive and may block some old pptp…

How about stripping MSS instead? Like so:

iptables -t mangle -I PREROUTING -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j TCPOPTSTRIP --strip-options mss

I experimented with a host that sends out mss 216 and the communication was still ok with the above, but not while dropping the traffic.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#112

Post by CloudNetworking »

londons_explore wrote: post #107
chupasaurus wrote: post #60

Earlier quoted context omitted.

FYI Debian Security Team recommends setting new sysctl value net.ipv4.tcp_min_snd_mss to 536, even though they (Debian) are preserving the default kernel value of 48 for compatibility.

It's worth noting that lwIP, the network stack used by most microcontroller based IoT devices, has a very low MSS. It's configurable, but typically defaults to 512.

That's very interesting. I have only seen those defaults in some... "special" satellite links.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#113

Post by CloudNetworking »

pas wrote: post #106
wademealing wrote: post #65

Earlier quoted context omitted.

Disclaimer: I worked on initial Red Hat article linked above. In my personal AWS instance from the last few days less than half a percent of the traffic had hit the firewall rule to log the error. Most of that traffic seemed to come from the China, this was possibly port probing / portscans or really old hardware accessing my the server. I would say that the iptables rule is a 'better' solution than dropping sack as…

So far on 3 VMs where I've checked (all are public facing, on is fairly high traffic MX, the other is a webhost), netstat -s informed me that SACK is barely used.

I'm guessing an MX sees mostly server to server traffic, so I kind of expect that; however for services used by consumers around the world it might be a very bad idea to disable SACK.

The bigger impact will be for users far away, with increased risk of packet loss and higher latency.

It's too easy to drop packets with very low MSS and, unless you've got specific needs (someone mentioned IOT), there's no reason to not drop packets with MSS < 536 or so. I believe Window's smallest MTU (MSS + IP and TCP headers) size is 576 bytes for example.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#115

Post by CloudNetworking »

fortran77 wrote: post #84

Will there be a big performance hit if I just turn sack off (for now) until I finish running all our tests on the new kernel?

Depends on your traffic, but in general terms you might want to instead drop packets with low MSS.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#116

Post by LinuxBender »

isodude wrote: post #111
LinuxBender wrote: post #25

This is the way I block such things on my own VM's (not at work) using iptables: iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP Here it is in action: iptables -L -n -v -t raw | grep mss 84719 3392K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 tcpmss match !640:65535 My settings may be a little aggressive and may block some old pptp…

How about stripping MSS instead? Like so: iptables -t mangle -I PREROUTING -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j TCPOPTSTRIP --strip-options mss I experimented with a host that sends out mss 216 and the communication was still ok with the above, but not while dropping the traffic.

Thats a great idea. That would certainly help if someone unwittingly had some malware that enabled this behavior on their host, but you still wanted them to reach you.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#117

Post by LinuxBender »

isodude wrote: post #110
LinuxBender wrote: post #92

Earlier quoted context omitted.

In the event anyone needs this, you can also override outbound mss in case someone is telling your client to use a low mss. This goes in the mangle table. DO NOT use this example unless you know for sure what you are doing. iptables -t mangle -I POSTROUTING -o eth0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m tcpmss --mss 1:100 -j TCPMSS --set-mss 1360 This example should work for most use cases, but don't do this un…

I read in a note just below --set-mss in man iptables-extensions that iptables will not increase mss if it's already lower than what set in --set-mss.

Good catch, I totally missed that.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#118

Post by isodude »

LinuxBender wrote: post #116
isodude wrote: post #111

Earlier quoted context omitted.

How about stripping MSS instead? Like so: iptables -t mangle -I PREROUTING -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j TCPOPTSTRIP --strip-options mss I experimented with a host that sends out mss 216 and the communication was still ok with the above, but not while dropping the traffic.

Thats a great idea. That would certainly help if someone unwittingly had some malware that enabled this behavior on their host, but you still wanted them to reach you.

Or a totally unrelated misconfiguration, I assume this is why this particular host is sending a low MSS.

I just assume that stripping MSS should be enough, looking through the information that is available.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#119

Post by isodude »

LinuxBender wrote: post #117
isodude wrote: post #110

Earlier quoted context omitted.

I read in a note just below --set-mss in man iptables-extensions that iptables will not increase mss if it's already lower than what set in --set-mss.

Good catch, I totally missed that.

I did miss it at first also, but wondered why it didn't increase the value.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#120

Post by LinuxBender »

ilikepi wrote: post #98
LinuxBender wrote: post #25

This is the way I block such things on my own VM's (not at work) using iptables: iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP Here it is in action: iptables -L -n -v -t raw | grep mss 84719 3392K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 tcpmss match !640:65535 My settings may be a little aggressive and may block some old pptp…

The iptables commands listed in the Mitigation section of the RedHat article lists only SYN in the tcp-flags mask section: iptables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP If I interpret the man page correctly, the above is more broad because it does not care about the presence or absence of other flags, whereas your rule explicitly requires the other listed flags to be unset. In fact it see…

Theirs is just more specific. Both should mitigate the attack, but I would follow theirs instead of my example. They are certainly a better authority on the subject. If something goes wrong, much better to say "Followed vendor suggestions" than random HN poster. :-) That said, I would still use the raw table vs input.
Post reply on HN