Date: Tue, 27 Sep 2022 12:24:50 -0700 From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca> To: Kristof Provost <kp@FreeBSD.org> Cc: FreeBSD pf <freebsd-pf@freebsd.org>, Eirik =?utf-8?q?=C3=98verby?= <eirik.overby@modirum.com> Subject: Re: RFC: enabling pf syncookies by default Message-ID: <ba35872719a2d75e@orthanc.ca> In-Reply-To: <BF7E3C1C-CC06-4874-821E-2B3BBDC2F467@FreeBSD.org> References: <BF7E3C1C-CC06-4874-821E-2B3BBDC2F467@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kristof Provost writes: > For those not familiar with it, syncookies are a mechanism to resist syn > flood DoS attacks. They’re enabled by default in the IP stack, but if > you’re running pf a syn flood would still exhaust pf’s state table, > even if the network stack itself could cope. I'm not sure of the lineage of pf's syncookie code in FreeBSD, but before you do this you should look at the recent set of patches Henning committed to the OpenBSD -snapshot pf source. We found an evil bug lurking in pf where, if a single source address was recycling source ports fast enough to re-use the same source addr:port pair while the old connection still had a FINWAIT2 state table entry, the new connection attempt would get dropped on the floor. The patch cleaned up most of the problem, but when we recently put the patched pf into production we were still seeing dropped connection requests. We haven't been able to specifically reproduce the problem yet, but if you're front-ending a busy web site, e.g., I would be wary of enabling syncookies at the moment until this bug gets stamped out once and for all. --lyndon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ba35872719a2d75e>