From nobody Sat Sep 24 13:32:50 2022 X-Original-To: freebsd-pf@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 4MZVMB6dsTz4cgS8 for ; Sat, 24 Sep 2022 13:32:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MZVMB5svlz41fY; Sat, 24 Sep 2022 13:32:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664026374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eM8RZUsIL9v2B8UVxl77FfqPtXIMcJZZESrurYsIEOc=; b=TnFnS4F905c+dnBf7Do6WQaMlK0ZlwPTF/CrjtjXU+UmTgMf55OP2Q6HIxfZ2Cf5EAnYN9 97yr0AnUxpBjBY7F+2E/FMT+hbklyD6gi1aUjd9QfRxTlBHv9oFuyzS9JHKTqPa5orPP52 6TlG4GCN0NQEgcNykKEIUHA4aksV4mKa1R+01IHRW+vT8CD9TTJIEOTc9aT89Owj6Qs3C+ uI+UThgRKZZ6T5E3ZUdtTemQDNLpjVkq1/Yklb0WvsHUU3RmMhxHlHaZQypuCkRdeOl+hQ NqLwrdCv+jGCDcyQykaFQ6Cu41AMDRK9EieyqDd2L6a6+oFxfcd4lsoSgwcS1A== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MZVMB3M1KzWnH; Sat, 24 Sep 2022 13:32:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id D1E7E2C53B; Sat, 24 Sep 2022 15:32:51 +0200 (CEST) From: Kristof Provost To: FreeBSD pf Cc: Eirik =?utf-8?q?=C3=98verby?= Subject: RFC: enabling pf syncookies by default Date: Sat, 24 Sep 2022 15:32:50 +0200 X-Mailer: MailMate (1.14r5852) Message-ID: List-Id: Technical discussion and general questions about packet filter (pf) List-Archive: https://lists.freebsd.org/archives/freebsd-pf List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B0ABA760-8B22-4E97-877C-F6677A50B102_=" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664026374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eM8RZUsIL9v2B8UVxl77FfqPtXIMcJZZESrurYsIEOc=; b=Esb+NfeYl1Yl8lPOCt/+NaEd91EkS/7EGHYKXmK4TJGv3ldgiV/ZXc3QrtgqFedqB7jYx/ dvzfQzL9L8PZQ8ZraB9XjSMgSB1HCxglOwHwySfW3mxAJSoZOHGKPl+r164veZSI4DhvNk GZSoj5krMzuHV1cYJZPbz1y66f7xsohLR4gWfr3zbj1gTJ5RYh2GeJTpGjePEd6NYYUoZR iRCBQTxjhz8KA3e/Qf7Zl1xhjyLYv12oxNl9D3g5f1Az2HgRobkuZSUoKeu9yjmDxocH/f AjDgdgAABqzlmm2F/sEmMOB9pYILYekJsNNtI7Y95+cPOM+Xi5aTtVZNggkdew== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664026374; a=rsa-sha256; cv=none; b=YEmNMhR+MSjOHmaaMF0Zwn+7C+lepYkBc1zUEmD5c3o+BmiRL/H8xcxqExqtQsk+Wx/FPL H9NuYiKXVs3J4wg8Rno6t8UeBDEsPt9jARr3WQKJOhWyl877Ters91ioYmT/xMzIUwMD6a yt8GC+PAYYq92vNUp9Vg3fBqTusxzevBZ5D62nvL1i+6TVq87cXqb/JZIQzPDCZ4uyEUFE qwseGGgZyoBZWqa0F7nYP1L8eQ3tXPqpqB9TxSdgHj2u/IG7fqZ/A7IQbaNgwNp6s7CvRl t6nFipY+/ugyOLrfkCLSpLNlH1xyyV4fJFtE3jNQuX01KzaWcVrUUTk9cynRyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=_MailMate_B0ABA760-8B22-4E97-877C-F6677A50B102_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Hi, During EuroBSDCon 2022 Eirik asked why we don’t enable pf’s syncookie feature (in adaptive mode) by default. I don’t really have a good answer, so I’m inclined to make this change. 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. In adaptive mode all pf does is track the number of half-open states (as created when a SYN packet arrives). If that exceeds a set limit the syncookie feature activates. The upside of that is that all we pay for is the counting of the number of half-open states, which has no meaningful performance impact, at least until we exceed the high water mark. Does anyone see a good reason not to do so? Best regards, Kristof Proposed patch: commit 77b5994c89945e52eb23ec6f5810a1186abc6df4 (HEAD -> main) Author: Kristof Provost Date: Sat Sep 24 14:49:25 2022 +0200 pf: default syncookies to adaptive mode The cost of enabling syncookies in adaptive mode is very low (basically a single atomic add when we create a new half-open state), and the payoff when under SYN flood is huge. So, enable adaptive mode by default. Suggested by: Eirik Øverby diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c index 84235031f8e6..4e1eafe016f1 100644 --- a/sys/netpfil/pf/pf_ioctl.c +++ b/sys/netpfil/pf/pf_ioctl.c @@ -311,6 +311,8 @@ pfattach_vnet(void) { u_int32_t *my_timeout = V_pf_default_rule.timeout; + bzero(&V_pf_status, sizeof(V_pf_status)); + pf_initialize(); pfr_initialize(); pfi_initialize_vnet(); @@ -379,7 +381,6 @@ pfattach_vnet(void) my_timeout[PFTM_ADAPTIVE_START] = PFSTATE_ADAPT_START; my_timeout[PFTM_ADAPTIVE_END] = PFSTATE_ADAPT_END; - bzero(&V_pf_status, sizeof(V_pf_status)); V_pf_status.debug = PF_DEBUG_URGENT; V_pf_pfil_hooked = 0; diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/pf/pf_syncookies.c index 6a375411d8ea..c16d9f3509fd 100644 --- a/sys/netpfil/pf/pf_syncookies.c +++ b/sys/netpfil/pf/pf_syncookies.c @@ -126,7 +126,12 @@ pf_syncookies_init(void) { callout_init(&V_pf_syncookie_status.keytimeout, 1); PF_RULES_WLOCK(); - pf_syncookies_setmode(PF_SYNCOOKIES_NEVER); + V_pf_syncookie_status.hiwat = PF_SYNCOOKIES_HIWATPCT * + V_pf_limits[PF_LIMIT_STATES].limit / 100; + V_pf_syncookie_status.lowat = PF_SYNCOOKIES_LOWATPCT * + V_pf_limits[PF_LIMIT_STATES].limit / 100; + pf_syncookies_setmode(PF_SYNCOOKIES_ADAPTIVE); + PF_RULES_WUNLOCK(); } --=_MailMate_B0ABA760-8B22-4E97-877C-F6677A50B102_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

During EuroBSDCon 2022 Eirik asked why we don=E2=80=99t e= nable pf=E2=80=99s syncookie feature (in adaptive mode) by default.

I don=E2=80=99t really have a good answer, so I=E2=80=99m= inclined to make this change.

For those not familiar with it, syncookies are a mechanis= m to resist syn 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 ex= haust pf=E2=80=99s state table, even if the network stack itself could co= pe.

In adaptive mode all pf does is track the number of half-= open states (as created when a SYN packet arrives). If that exceeds a set= limit the syncookie feature activates.
The upside of that is that all we pay for is the counting of the number o= f half-open states, which has no meaningful performance impact, at least = until we exceed the high water mark.

Does anyone see a good reason not to do so?

Best regards,
Kristof

Proposed patch:

commit 77b5994c89945e52eb23ec6f5810a1186abc6df4 (HEAD ->=
; main)
Author: Kristof Provost <kp@FreeBSD.org>
Date:   Sat Sep 24 14:49:25 2022 +0200

    pf: default syncookies to adaptive mode

    The cost of enabling syncookies in adaptive mode is very low (basical=
ly
    a single atomic add when we create a new half-open state), and the
    payoff when under SYN flood is huge.

    So, enable adaptive mode by default.

    Suggested by:   Eirik =C3=98verby

diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c
index 84235031f8e6..4e1eafe016f1 100644
--- a/sys/netpfil/pf/pf_ioctl.c
+++ b/sys/netpfil/pf/pf_ioctl.c
@@ -311,6 +311,8 @@ pfattach_vnet(void)
 {
        u_int32_t *my_timeout =3D V_pf_default_rule.timeout;

+       bzero(&V_pf_status, sizeof(V_pf_status));
+
        pf_initialize();
        pfr_initialize();
        pfi_initialize_vnet();
@@ -379,7 +381,6 @@ pfattach_vnet(void)
        my_timeout[PFTM_ADAPTIVE_START] =3D PFSTATE_ADAPT_START;
        my_timeout[PFTM_ADAPTIVE_END] =3D PFSTATE_ADAPT_END;

-       bzero(&V_pf_status, sizeof(V_pf_status));
        V_pf_status.debug =3D PF_DEBUG_URGENT;

        V_pf_pfil_hooked =3D 0;
diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/pf/pf_syncookie=
s.c
index 6a375411d8ea..c16d9f3509fd 100644
--- a/sys/netpfil/pf/pf_syncookies.c
+++ b/sys/netpfil/pf/pf_syncookies.c
@@ -126,7 +126,12 @@ pf_syncookies_init(void)
 {
        callout_init(&V_pf_syncookie_status.keytimeout, 1);
        PF_RULES_WLOCK();
-       pf_syncookies_setmode(PF_SYNCOOKIES_NEVER);
+       V_pf_syncookie_status.hiwat =3D PF_SYNCOOKIES_HIWATPCT *
+           V_pf_limits[PF_LIMIT_STATES].limit / 100;
+       V_pf_syncookie_status.lowat =3D PF_SYNCOOKIES_LOWATPCT *
+           V_pf_limits[PF_LIMIT_STATES].limit / 100;
+       pf_syncookies_setmode(PF_SYNCOOKIES_ADAPTIVE);
+
        PF_RULES_WUNLOCK();
 }
--=_MailMate_B0ABA760-8B22-4E97-877C-F6677A50B102_=--