5 ms·
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,RS
by LinuxBender 7y ago
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/ppoe users. Perhaps 520 would be a safer low end. As a funny side note, this also blocks hping3's default settings (ping floods) as it doesn't set mss. This also blocks a slew of really poorly coded scanners.
For everything else at work, we are behind a layer 7 load balancer that is not vulnerable.
You may also find it useful to block fragmented packets. I've done this for years and never had an issue:
iptables -t raw -I PREROUTING -i eth0 -f -j DROP
If you have the PoC, then feel free to first verify you can browse to https://tinyvpn.org/ https://tinyvpn.org/ then send the small MSS packets to that domain, then see if you can still browse to it. I don't care if the server reboots or crashes. Just don't send DDoS please, as the provider will complain to me.
To see the counters increase, here is a quick and silly cron job that will show you the MSS DROPs in the last minute, that I will disable after a couple days: [1]
[1] - https://tinyvpn.org/up/mss/ https://tinyvpn.org/up/mss/
- peterwwillis 7y agoAnd ipv6? Fragmentation and mss are handled somewhat differently, iirc
- LinuxBender 7y agoGood point. I don't have a place to test ipv6. You would also have to create ip6tables rules to test that. If you have a test server on ipv6, please apply the rule and link it here. Well, test first, then link here. :-)
- topranks 7y agoIP fragmentation is different in IPv6 true. MSS is a TCP parameter, however, and operates at layer 4. Won’t matter if the protocol underneath is IPv4 or IPv6 in this case.
- peterwwillis 7y agoActually, it does behave differently. Never underestimate the weirdness of IPv6 ;-) From https://en.m.wikipedia.org/wiki/Maximum_segment_size https://en.m.wikipedia.org/wiki/Maximum_segment_size : "To avoid fragmentation in the IP layer, a host must specify the maximum segment size as equal to the largest IP datagram that the host can handle minus the IP and TCP header sizes.[2] Therefore, IPv4 hosts are required to be able to handle an MSS of 536 octets (= 576[3] - 20 - 20) and IPv6 hosts are required to be able to handle an MSS of 1220 octets (= 1280[4] - 40 - 20)." So it seems like one needs to clamp tcpv4 to at least 536, and tcpv6 to at least 1220. (tcpv6 is common shorthand for TCP over IPv6, similar to udpv6 and icmpv6)
- chupasaurus 7y agoFYI 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.
- LinuxBender 7y agoThats cool. In CentOS the default is 256. The settings are a little different though. net.ipv4.route.min_adv_mss = 256 net.ipv4.tcp_base_mss = 512 net.ipv6.route.min_adv_mss = 1220
- londons_explore 7y agoIt'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.
- CloudNetworking 7y agoThat's very interesting. I have only seen those defaults in some... "special" satellite links.
- hackersword 7y agoHow 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/advisories/third-party/2019-001/block-low-mss/iptables.txt https://github.com/Netflix/security-bulletins/blob/master/ad...
- LinuxBender 7y agoThe raw tables does not contain INPUT. For the raw table you would have to use PREROUTING. If you are using the default table of filter, then you can use INPUT. So for the raw table, it would be iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss --mss 1:500 -j DROP For the default (filter) table iptables -t filter -I INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss --mss 1:500 -j DROP Generally speaking, if you know you are going to drop everything that matches a pattern or address, it is useful to put that in the raw table, so that malicious traffic can't spike your CPU load as easily. Every packet to the filter table will incur potentially CPU expensive conntrack table lookups. As your conntrack table gets bigger, this gets more expensive. The reason I use the opposite method is that we not the normal range we want. Programs can also set super high values or not set mss at all (which is not the same as 0). I explicitly set the interface, so that we don't match interfaces such as lo, tun, tap, vhost, veth, etc... because you never know what weird behavior some program depends on. In my example, eth0 is directly on the internet. In your systems, that might be bond0.
- ilikepi 7y agoIt'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 https://github.com/Netflix/security-bulletins/issues/4
- LinuxBender 7y agoIn 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.
- isodude 7y agoI 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.
- LinuxBender 7y agoGood catch, I totally missed that.
- isodude 7y agoI did miss it at first also, but wondered why it didn't increase the value.
- LinuxBender 7y agoI'd have to dig into the source code of that module. It makes sense to not raise it artificially higher than the requesting host. I just didn't expect them to have that logic. IPTables usually blindly does whatever bad idea I give it. :-)
- Avamander 7y agoHow does one do this with nftables?
- LinuxBender 7y agoI've not done this in nftables, but this might give some ideas: [1] [1] - https://wiki.nftables.org/wiki-nftables/index.php/Mangle_TCP_options https://wiki.nftables.org/wiki-nftables/index.php/Mangle_TCP...
- ilikepi 7y agoThe 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?
- LinuxBender 7y agoTheirs 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.
- isodude 7y agoHow 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.
- LinuxBender 7y agoThats 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.
- isodude 7y agoOr 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.