ACK Storm protection?

[Jov]

​​
freebsd-net@ added.

After google "ack storm freebsd" I find a very old SA:
https://www.freebsd.org/security/advisories/FreeBSD-SA-98%3A07.rst.asc
mentions:
​

+ * In the SYN-RECEIVED state, don't send an ACK unless the

+ * segment we received passes the SYN-RECEIVED ACK test.
> + * If it fails send a RST. This breaks the loop in the
> + * "LAND" DoS attack, and also prevents an ACK storm
> + * between two listening ports that have been sent forged
> + * SYN segments, each with the source address of the other.
> + */
> + if (tp->t_state == TCPS_SYN_RECEIVED && (tiflags & TH_ACK) &&
> + (SEQ_GT(tp->snd_una, ti->ti_ack) ||
> + SEQ_GT(ti->ti_ack, tp->snd_max)) )
> + goto dropwithreset;​


Not sure in the established state there also has ACK storm protection.

2017-07-22 2:57 GMT+08:00 Matt Riffle <matt at pair.com>:

> Hello,
>
> Starting on July 11, I’ve started to see an increasing number of what
> appear to be “ACK storms” affecting a number of FreeBSD boxes I’m
> administering.  There are a few unsupported releases mixed in, but, this is
> also happening on boxes running 10.3-RELEASE-p3.
>
> In the cases we’re seeing, it begins with legitimate TCP traffic
> requesting something over HTTP, but soon thereafter we get an out of window
> packet and get in to a loop.  If anybody is interested or especially if
> they’ve experienced something similar, there are a few more details I could
> share privately.
>
> Setting aside the cause, I’m interested in trying to mitigate the
> problem.  None of my Ubuntu boxes appear to be affected, I presume because
> of these patches Google made to the kernel there:
>
> https://www.ietf.org/mail-archive/web/tcpm/current/msg09445.html <
> https://www.ietf.org/mail-archive/web/tcpm/current/msg09445.html>
>
> Is there any equivalent protection for FreeBSD?  In my own research I’ve
> been unable to find anything.  In fact, beyond the message above you can’t
> find very much about ACK storms at all.
>
> Right now we’re mitigating with custom code that is sniffing packets and
> adding temporary firewall rules whenever it sees a loop start, and that’s
> working well enough, but, I’d prefer to handle it at a lower level if
> possible.
>
> Thanks,
>
> Matt R.
>
>
>
>
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org
> "