From nobody Fri Sep 5 11:14:59 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cJDPR67PPz67ST4 for ; Fri, 05 Sep 2025 11:18:51 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJDPR1ktSz3Q7l for ; Fri, 05 Sep 2025 11:18:51 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; none Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.1/8.18.1) with ESMTPS id 585BI73s013369 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Sep 2025 13:18:07 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1757071089; cv=none; b=JRLkM0yYqGikuGJ7Oul72XkzGrt/qx7tM56aV344Rb7/aJJ/4xF1Fa+hF2HNnxAiMEKWDFk7GuyklanqaSjZKZqBnVcVUa7PZ9ME+rEddyDBFEBUDY6VBbRN4pBE6bPLM0A4MbW/USS/Kmtds6ROp8mQSPEvcKXixQwSq4HKbGk= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1757071089; c=relaxed/simple; bh=v3OoKiKVfNwfA9ThSSpGmPFuHnJdGgcUNUiU6FxCvmI=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:X-Milter:X-Greylist; b=AVasQhpE+Rej0GjDLBUKPVKtbm65OAqMKjc7IJhPdxZvMyHImcd29iDqd/VACF2BL0D7uced+pqKEk2zrdByMSUEwmQWcTvmtTMlGRU38/26yxgklHGgcuq2Iov+YsHNynCO3/zAUzSWK916tR3PdohTTs3PHVBGZKNS/AbYoyQ= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.1/8.18.1/Submit) with UUCP id 585BI7kt013368; Fri, 5 Sep 2025 13:18:07 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 585BHnQ3068236 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Fri, 5 Sep 2025 13:17:50 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 585BExWt031902 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Sep 2025 13:15:00 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.18.1/8.18.1/Submit) id 585BExKq031901; Fri, 5 Sep 2025 13:14:59 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Fri, 5 Sep 2025 13:14:59 +0200 From: "Peter 'PMc' Much" To: Michael Tuexen Cc: freebsd-net@freebsd.org Subject: Re: Successful syn flooding DoS Message-ID: References: <742A470C-1309-491B-A9F1-98CA402B6176@lurchi.franken.de> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <742A470C-1309-491B-A9F1-98CA402B6176@lurchi.franken.de> X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Fri, 05 Sep 2025 13:18:09 +0200 (CEST) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cJDPR1ktSz3Q7l On Fri, Sep 05, 2025 at 12:03:48PM +0200, Michael Tuexen wrote: ! > On 5. Sep 2025, at 00:26, Peter 'PMc' Much 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