From nobody Mon Sep 02 06:53:55 2024 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 4Wxzxf550Dz5MdCQ for ; Mon, 02 Sep 2024 06:53:58 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from util.redbarn.org (util.redbarn.org [24.104.150.222]) (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 "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wxzxd5BFbz54pB for ; Mon, 2 Sep 2024 06:53:57 +0000 (UTC) (envelope-from paul@redbarn.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=redbarn.org header.s=util header.b=Ag2gzz78; dmarc=pass (policy=reject) header.from=redbarn.org; spf=pass (mx1.freebsd.org: domain of paul@redbarn.org designates 24.104.150.222 as permitted sender) smtp.mailfrom=paul@redbarn.org Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (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 "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id 8897C160BB0; Mon, 02 Sep 2024 06:53:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1725260035; bh=J+7JazWmIcHznfYAtlAHwpz4Te9OgRaYlVM8QahfeWs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Ag2gzz78anp9P+ZmC7Q4s2Wb1Safg2eg7NIckTmnPv05IkJWinmR61+ddLGPkQ4gc k0pKsV4QqLb9O8jlz+rZcURwRKycYU5xk4dPlhtvccj0pcXPx5Yv3G2ohgHvg+VsLv RdPKG1wBxGATY0mmPOAmvoZMbIKe7Fq+WsbB5Iwg= Received: from heater.srcl.tisf.net (heater.srcl.tisf.net [IPv6:2001:559:8000:cc::111]) (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 did not present a certificate) by family.redbarn.org (Postfix) with ESMTPS id 4F8DBC3F22; Mon, 02 Sep 2024 06:53:55 +0000 (UTC) From: Paul Vixie To: FreeBSD Net Cc: mike tancsa Subject: Re: dropping udp fragments with ipfw Date: Sun, 01 Sep 2024 23:53:55 -0700 Message-ID: <2645251.Lt9SDvczpP@heater.srcl.tisf.net> In-Reply-To: <790fcb38-db6c-41ce-8222-8146be5dbe3b@sentex.net> References: <790fcb38-db6c-41ce-8222-8146be5dbe3b@sentex.net> 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.90 / 15.00]; DWL_DNSWL_MED(-2.00)[redbarn.org:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[redbarn.org,reject]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.40)[24.104.150.222:from,24.104.150.213:received]; R_SPF_ALLOW(-0.20)[+ip4:24.104.150.0/24]; R_DKIM_ALLOW(-0.20)[redbarn.org:s=util]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[paul]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33651, ipnet:24.104.150.0/24, country:US]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[redbarn.org:+] X-Rspamd-Queue-Id: 4Wxzxd5BFbz54pB with "add pass udp" one creates a rule that permits initial fragments of a= =20 datagram, or unfragmented datagram, to pass. if this doesn't happen, then n= o=20 subsequent fragment will matter even if allowed through -- because there wi= ll=20 be no endpoint state to allow those fragments to be reassembled. so: add allow ip from any to any frag works pretty well. per ipfw(8), the "frag" option means non-initial fragmen= ts: Fragmented packets which have a non-zero offset (i.e., not the first fragment) will never match a rule which has one or more port specifications. See the frag option for details on match= ing fragmented packets. and: frag spec Matches IPv4 packets whose ip_off field contains the comma separated list of IPv4 fragmentation options specified in spec. The recognized options are: df (don't fragment), mf (more fragments), rf (reserved fragment bit) offset (non-zero fragme= nt offset). The absence of a particular options may be denoted w= ith a =E2=80=98!=E2=80=99. Empty list of options defaults to matching on non-zero fragment offset. Such rule would match all not the first fragment datagrams, both IPv4 and IPv6. This is a backward compatibili= ty with older rulesets. i won't use "reass" on a firewall for the same reasons i don't use LRO: > LRO should not operate on machines acting as routers, as it breaks the en= d- to-end principle and can significantly impact performance.[13][14] (https://en.wikipedia.org/wiki/TCP_offload_engine#Large_receive_offload) if your question is about endpoint ipfw rather than IP firewall ipfw, reass= is=20 fine. if what you want to do is drop large UDP attacks you probably do not= =20 care whether fragments are involved and you should be looking at "pipe" and= =20 "queue" from dummynet(4). if you really want to send only non-initial=20 fragments to some special pipe or queue you can do that, of course. =2D-=20 P Vixie On Thursday, August 29, 2024 11:51:37 AM PDT mike tancsa wrote: > I was working on some firewall rules to drop large UDP fragment attacks > and noticed there is no easy way to drop fragments based on port ? e.g. > if someone sends a UDP packet of 1400 bytes, I can drop it with >=20 > TARGET=3D192.168.1.1 >=20 > ipfw add 5 deny log udp from any 53 to $TARGET >=20 > But if that packet is say 2000 bytes and is fragmented, the fragment > passes through. I have to add a subsequent rule >=20 > ipfw add 10 deny log udp from any to $TARGET fragment >=20 > But this would kill all UDP fragments. If the host has some other UDP > application that needs to deal with fragmented packets, is there a way > to get around that and only drop packets with a certain port in the > first fragment ? >=20 > ---Mike