Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Sep 2022 11:44:25 +0200
From:      Kristof Provost <kp@FreeBSD.org>
To:        "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
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:  <C6D440A0-3E9C-480C-8210-0D7D63D8EAA3@FreeBSD.org>
In-Reply-To: <ba35872719a2d75e@orthanc.ca>
References:  <BF7E3C1C-CC06-4874-821E-2B3BBDC2F467@FreeBSD.org> <ba35872719a2d75e@orthanc.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Sep 2022, at 21:24, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> Kristof Provost writes:
>
>> For those not familiar with it, syncookies are a mechanism to resist s=
yn
>> flood DoS attacks. They=E2=80=99re enabled by default in the IP stack,=
 but if
>> you=E2=80=99re running pf a syn flood would still exhaust pf=E2=80=99s=
 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.
>
Thanks for this update. Henning told me about the fast re-use issue durin=
g EuroBSD, and I had looking at that on my todo list.

I=E2=80=99ve not yet heard any reports of similar issues on FreeBSD, but =
that doesn=E2=80=99t mean they don=E2=80=99t exist of course.

At a minimum I=E2=80=99ll hold off on making this change until I=E2=80=99=
ve had a chance to work out if we=E2=80=99re affected by the issue Hennin=
g fixed or not.

Eirik, do you have instrumentation to work out if this is happening to yo=
u?

Best regards,
Kristof



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C6D440A0-3E9C-480C-8210-0D7D63D8EAA3>