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

91–100 of 134 posts

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

#91

Post by LinuxBender »

bhauer wrote: post #71

Sorry, this is probably a bit simplistic, but I am curious: How likely is this to affect embedded devices? E.g., hardware firewalls, routers, IoT devices that all use a Linux kernel?

If you are not exposing any tcp ports or reaching out directly from those devices to a malicious host, then very unlikely. Either way, it's best to check the vendors site or open a ticket with them, if that is an option.

An alternate option would be to put the device behind another firewall or load balancer or proxy that you know is not vulnerable.

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

#92

Post by LinuxBender »

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…

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 unless you for sure know the implications. Dropping bad inbound options is easy, but outbound can get more complicated. I am just showing this in case anyone asks and I am asleep. :-) Talk to your network admins and ask what is the highest mss/mtu your VPN's and 3rd party networks support.

This may not even help, as the packet has already been generated and we are too late in the process. I just figure someone might ask. There are probably use cases where this may help (for proxies, edge firewalls, hypervisors, docker hosts, maybe)

Or just log and drop the connections, or send yourself (your app) a tcp-reset.

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

#93

Post by Avamander »

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 does one do this with nftables?

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

#94

Post by xyzzy_plugh »

LinuxBender wrote: post #91
bhauer wrote: post #71

Sorry, this is probably a bit simplistic, but I am curious: How likely is this to affect embedded devices? E.g., hardware firewalls, routers, IoT devices that all use a Linux kernel?

If you are not exposing any tcp ports or reaching out directly from those devices to a malicious host, then very unlikely. Either way, it's best to check the vendors site or open a ticket with them, if that is an option. An alternate option would be to put the device behind another firewall or load balancer or proxy that you know is not vulnerable.

I guess a question I have is then: can I hose you during a TLS handshake? If I can forge DNS, then I can DoS, right? Which makes BGP a prime target right now?

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

#95

Post by LinuxBender »

xyzzy_plugh wrote: post #94
LinuxBender wrote: post #91

Earlier quoted context omitted.

If you are not exposing any tcp ports or reaching out directly from those devices to a malicious host, then very unlikely. Either way, it's best to check the vendors site or open a ticket with them, if that is an option. An alternate option would be to put the device behind another firewall or load balancer or proxy that you know is not vulnerable.

I guess a question I have is then: can I hose you during a TLS handshake? If I can forge DNS, then I can DoS, right? Which makes BGP a prime target right now?

Well, anything that gets a vulnerable device to talk to a malicious device would be an issue. Probably best to check with each vendor and see what their story is if you can't filter the traffic between your devices and potentially malicious devices.

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

#96

Post by LinuxBender »

Avamander wrote: post #93
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 does one do this with nftables?

I've not done this in nftables, but this might give some ideas: [1]

[1] - https://wiki.nftables.org/wiki-nftables/index.php/Mangle_TCP...

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

#97

Post by xyzzy_plugh »

LinuxBender wrote: post #95
xyzzy_plugh wrote: post #94

Earlier quoted context omitted.

I guess a question I have is then: can I hose you during a TLS handshake? If I can forge DNS, then I can DoS, right? Which makes BGP a prime target right now?

Well, anything that gets a vulnerable device to talk to a malicious device would be an issue. Probably best to check with each vendor and see what their story is if you can't filter the traffic between your devices and potentially malicious devices.

I'm just thinking how an attacker could disrupt e.g. IoT devices. Pretty terrific.

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

#98

Post by ilikepi »

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 seems like the above might be broad enough to include incoming SYNACK response packets that are the result of outgoing connections.

Am I understanding this correctly, and if so, do you have a thought about why they suggest this?

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

#99

Post by ilikepi »

hackersword wrote: post #86
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 would you do that for the INPUT table (not a VM)? Just: > iptables -t raw -I INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP ?? here [1] gives example of ... is your just inverting/negating the DROP rule ? >iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP [1] https://github.com/Netflix/security-bulletins/blob/master/ad...

It's worth noting that use of -A instead of -I in your example from [1] likely makes this rule ineffective, since it will be appended to the end of the INPUT chain. This has already been reported as an issue[2].

[2]: https://github.com/Netflix/security-bulletins/issues/4

Post reply on HN