"Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues"

[seed]

This might be interesting:

https://www.openwall.com/lists/oss-security/2019/06/17/5

"Netflix has identified several TCP networking vulnerabilities in FreeBSD
and Linux kernels.

The vulnerabilities specifically relate to the minimum segment size (MSS)
and TCP Selective Acknowledgement (SACK) capabilities. The most serious,
dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent
Linux kernels.

There are patches that address most of these vulnerabilities. If patches
can not be applied, certain mitigations will be effective. We recommend
that affected parties enact one of those described below, based on their
environment.
"

"Description: An attacker can force the Linux kernel to segment its
responses into multiple TCP segments, each of which contains only 8 bytes
of data. This drastically increases the bandwidth required to deliver the
same amount of data. Further, it consumes additional resources (CPU and NIC
processing power). This attack requires continued effort from the attacker
and the impacts will end shortly after the attacker stops sending traffic.

Fix: Two attached patches (“PATCH_net_3_4.patch” and “PATCH_net_4_4.patch”)
add a sysctl which enforces a minimum MSS, set by the
net.ipv4.tcp_min_snd_mss sysctl. This lets an administrator enforce a
minimum MSS appropriate for their applications.

Workaround: Block connections with a low MSS using one of the attached
filters. (The values in the filters are examples. You can apply a higher or
lower limit, as appropriate for your environment.) Note that these filters
may break legitimate connections which rely on a low MSS. Also, note that
this mitigation is only effective if TCP probing is disabled (that is, the
net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the
default value for that sysctl).


Note: Good system and application coding and configuration practices
(limiting write buffers to the necessary level, monitoring connection
memory consumption via SO_MEMINFO, and aggressively closing misbehaving
connections) can help to limit the impact of attacks against these kinds of
vulnerabilities.

An advisory has been published
at https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
"

[schnipp]

If I am right, the TCP Rack stack has been introduced with FreeBSD 12. Opnsense v.19.1 relies on FreeBSD 11.2 and should not be affected by this problem.

Can anybody confirm?

[qinohe]

Yep, I was going to say, and still will , OP did you even bother to check? 

Code: [Select]

sysctl -a | grep net.inet.tcp.rack

[seed]

Sorry. I did not check. 

[qinohe]

No worries mate, better one time to much the forgetting about these important things, thanks anyway