From owner-freebsd-questions@freebsd.org Mon Jan 25 06:08:07 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 16B684EA804 for ; Mon, 25 Jan 2021 06:08:07 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DPKD61Swnz56xy for ; Mon, 25 Jan 2021 06:08:05 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ot1-x331.google.com with SMTP id a109so11747871otc.1 for ; Sun, 24 Jan 2021 22:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NDXLs39kPwoZz2QdaVFJ4ZHGMfqay8Apj3xtzXraTzw=; b=CK+udIkP3+3O8eXTCIw3h2nbVXU2MIWfFqZLjdMqv4hDhZVEF9m2n8bQgFNjRCE5RL JMevQM6ALrvS7aIAh0mVfTfPXzdxauvELDkKkBidvU+GaWwt1cK/4OVmE9ig/E33Qd14 opWpah/mqUDgNsGbxYbpj3d7xi8sabn17gDDKEekUAZUM5rEB5vUV7JN5B8EEA2lOhFt eeOiJ2yQl4/PekdOe5TFrNf0Ot1kmOGu9G4QuXN3WVtHDn2b9YS1DQe+yvGXp3bxhwH/ doS0TgBq7pRcjhD0CKDT2sV8n7Y29YLvY8lIgPUYmOsZqU3/LxvNvPlzrqNVHrtTxEVu Sdxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NDXLs39kPwoZz2QdaVFJ4ZHGMfqay8Apj3xtzXraTzw=; b=JdO6Aq3i2QbFhQNTlnXLIZfpn9uW/wu4j37EDX45mBS7l40kC2VLj2gtQU7Z4xN0Hq GSyh0S7y6/UhkLlQoYu8uUO/MyHii2/AFcJhxhOgKezypoUcmM4xk+XrqQfxcRgGusJV xnNQjtUmq6L8YYSfIKkRy4wQbhUVcUG73M6JhtVnaDK5abRCBisEuqTrjQkJkuJ/BkIp B2c9LnWdW1XxwerpqK1K+A3yWMFfaC1CIeVgeeU5j0wYPFbYvcSI/cZ7ganBsI3gypvb atHnlNXm1UuEzLxhH8TRynhW3EDARO64YpKC+4dekC6T25QPw5bhlTCcTcBvWk+pMcVU RbqQ== X-Gm-Message-State: AOAM530h804aQuKNGTxCnDKCGyZhTcZJyw5belfOR/5OVVsGrb3+/nVN kMZ/ZdYAb6mfJN/uQybuQxbFkPVgzIRrYk4HaN2cfWKillT6IA== X-Google-Smtp-Source: ABdhPJzuhVywk7dsbqegyF9WfRVExQdVgiZY2kbEKetPaUZZ9zmh31CHYSjeLXZCUMi9TEN5FWKIgqjwypzxw6Px+NM= X-Received: by 2002:a05:6830:30a8:: with SMTP id g8mr363575ots.271.1611554884926; Sun, 24 Jan 2021 22:08:04 -0800 (PST) MIME-Version: 1.0 References: <3cfe3c72-453b-e54e-3c56-9abf80f45be3@cloudzeeland.nl> In-Reply-To: <3cfe3c72-453b-e54e-3c56-9abf80f45be3@cloudzeeland.nl> From: Kevin Oberman Date: Sun, 24 Jan 2021 22:07:48 -0800 Message-ID: Subject: Re: IPFW | Too many dynamic rules? To: Jos Chrispijn Cc: Michael Sierchio , FreeBSD Mailing List X-Rspamd-Queue-Id: 4DPKD61Swnz56xy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=CK+udIkP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::331 as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::331:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::331:from:127.0.2.255]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::331:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 06:08:07 -0000 On Sun, Jan 24, 2021 at 3:08 AM Jos Chrispijn wrote: > Thanks for your help, Michael. > > Knowing so little about ipfw, I think it will be time to raise my > learning curve on it. Can you hint me where I can get more information > on nub level? Especially the remark Michael made > > "The lifetime of dynamic rules is, by default, way too long." > > intriques me. What is the exact result shortening them? Do I undermine > ipfw protection by giving it too less or too much time to check incoming > requests? > > Best, Jos > > Op 22-1-21 om 1:58 schreef Michael Sierchio: > > > > Vell succes! > > > Dank je! > ___ > No, you don't undermine security. You enhance it a tiny bit, but significantly. A stateful firewall works by creating a temporary rule allowing traffic that would be rejected. Simple example is a DNS query. It is sent out and, in typical ipfw setups, outgoing UDP packets create a dynamic entry to allow for the reply. To make dynamic rules work efficiently, space is reserved for the maximum number of concurrent dynamic rules that are to be allowed. Unless there is further traffic for a given rule, a dynamic rule is deleted after a preset lifetime. You can look at all ipfw dynamic parameters with 'sysctl net.inet.ip.fw | grep dyn_'. You can get the description of a sysctl with the "sysctl -d OID". The default lifetimes are long for the "modern" Internet. The most significant one is probably dyn_udp_lifetime. It would be unusual for it to take anywhere near the default 30 seconds to get a response, but setting it too short will result in failures. Shortening it will clear out old entries more quickly and reduce the chance of running out of space for dynamic rules. A number of years ago, one of the developers wrote a code that sent out UDP packets to a large number of remote systems. A very short time later it did the same thing, but from new sockets. That meant a whole new set of dynamic rules was created every second and sat there for 30 seconds. This quickly filled the available space and replies to further queries were blocked. Not just for his program, but for the whole system. Oops! -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683