Date: Fri, 5 Sep 2025 13:14:59 +0200 From: "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org> To: Michael Tuexen <michael.tuexen@lurchi.franken.de> Cc: freebsd-net@freebsd.org Subject: Re: Successful syn flooding DoS Message-ID: <aLrGM9BcUDiXR2o4@disp.intra.daemon.contact> In-Reply-To: <742A470C-1309-491B-A9F1-98CA402B6176@lurchi.franken.de> References: <aLoSANVhfontVd3e@disp.intra.daemon.contact> <742A470C-1309-491B-A9F1-98CA402B6176@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 05, 2025 at 12:03:48PM +0200, Michael Tuexen wrote: ! > On 5. Sep 2025, at 00:26, Peter 'PMc' Much <pmc@citylink.dinoex.sub.org> wrote: ! > ! > Folks, ! > ! > today I fell victim to a syn flooding party; one of my machines ! > went offline and needed a full reset to recover. ! > ! > Why: ! > If somebody sends me a SYN (might be spoofed), I reply with SYN-ACK. ! > If there is a portforwarder in the path, then libalias will ! > consider this state of affairs a fully established connection, and ! > preserve the record, for... a day. ! > ! > If somebody send me 100 SYN packets per second, then after a few ! > hour the libalias will have accumulated millions of these records. ! > They go into a tailq. And at that size, the network receiving ! > thread searching through that will run at 100% CPU. ! > ! > That receiving thread is a network interrupt, prio 8, so if the ! > machine is a single vcore KVM, it won't do much else anymore. ! > ! > As a quick measure I have now tried to change libalias to require a ! > bit more data before making the timeout that long. But in the ! > meantime the idiots have stopped their nonsense, so there is no ! > test. ! > ! > Comments, anybody? ! That seems to be a problem of libalias. I agree. But then, what would be the correct solution? A. Given somebody sends a SYN, and receives SYN-ACK, and then does nothing for the next few hours, considering the connection established, would that be legal? I don't think so; I would think that at least another ACk from the originator is necessary. If I'm right, then libalias should reflect that and only consider the connection established after the responder's SYN-ACK has also been acknowledged by the originator. B. Probably libalias should notice when it has accumulated a vast amount of stored connections, and do something to protect itself? ! What middlebox setup are you ! using? That question is not so easy to answer. In fact I have put some tooling on top of ipfw, to obtain a means to plug arbitrary filters into arbitrary flows, dynamically. NAT is just one of these filters. Currently I'm using ng_nat(4) via ng_ipfw(4). So far as I have seen earlier, it doesn't matter much which implementation of NAT is used, as the libalias is apparently always the same code. best regards, PMc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aLrGM9BcUDiXR2o4>