121–130 of 134 posts
Earlier quoted context omitted.
Good catch, I totally missed that.
I did miss it at first also, but wondered why it didn't increase the value.
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…
And ipv6? Fragmentation and mss are handled somewhat differently, iirc
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.
Some solution: echo 0 > /proc/sys/net/ipv4/tcp_sack https://github.com/Netflix/security-bulletins/blob/master/ad...
Earlier quoted context omitted.
https://github.com/Netflix/security-bulletins/blob/master/ad... is the advisory by the party that discovered the issue. (Disclosure: I have met Jonathan Looney and know some of the Netflix engineering staff, but I don't work for Netflix.)
This mentions FreeBSD impacts as well which the RedHat link doesn't.
Will any Android phones be affected, or they don't support segment offloading?
This might be fun...
Edit: Don't know if segmentation offloading is on by default in Android, but on my default Arch kernel it is, so I wouldn't know why not.
Earlier quoted context omitted.
And ipv6? Fragmentation and mss are handled somewhat differently, iirc
IP 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.
From 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)
Earlier quoted context omitted.
Here's a golden oldie from 1996: https://packetstormsecurity.com/files/15507/CA-96.26.ping.ht... My favorite of that era was simply the working-as-designed simplicity of sneaking the Hayes modem hangup sequence into various protocols: actual Hayes modems used +++ with a time-delay to send commands such as ATH0 (hangup) but everyone else skipped that time-delay in an attempt to avoid the patent so you could disconnect…
IRC was a fun venue for that one ~25 years ago. Pop into some random channel, send "/ctcp #channel ping +++ATH0", and wait patiently... a moment or two later you would be rewarded with a flood of "signoff" messages as the users' TCP sessions to the IRC server timed out (by responding to the CTCP, they had, in effect, told their modems to hang up). The goal, of course, was to get the highest "body count" possible from…
Earlier quoted context omitted.
Good catch, I totally missed that.
I did miss it at first also, but wondered why it didn't increase the value.