From nobody Thu Aug 29 19:59:12 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 4WvsYj5TYWz52X2H for ; Thu, 29 Aug 2024 19:59:21 +0000 (UTC) (envelope-from SRS0=jWsS=P4=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4WvsYj33M6z4FTZ for ; Thu, 29 Aug 2024 19:59:21 +0000 (UTC) (envelope-from SRS0=jWsS=P4=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Thu, 29 Aug 2024 21:59:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1724961554; 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: in-reply-to:in-reply-to:references:references; bh=EniEv/KpCvFOI96WGrVv+G3lZrlN1S1UYvPdMZ0RDjg=; b=Rx+c5Hq9iJAoN/Sivh1/zjZKCllSWqX69XtYSckXby+y4rOZR+mZV1cbuaDCg/4kq2f/wk 3v8dEgwICFTNGMal20wQzeVaG5bmWrhNXWhnYee/UDHokmPSTszFVrlOIeiZ78Ibj7R6hP YlPyyyUtzwYITZ7DeijxG2ZtyhXCRrShuKkipOaYp0+FtiZqJodpeRSmuTv1ah94xgPaqk K6hA1+VfgQC9qCszb6h4XoLii81Lpfey1L5y5Rxsh6cAHyODyZ+4joye9RfA8Ei/ptcTLO jD0m6QZW/VXwZwOSfo7tHmkpmkJZG84/gi08aymDcwaSN1+7MF5nBT+E2rmYnw== From: Ronald Klop To: mike tancsa Cc: FreeBSD Net Message-ID: <844983132.8139.1724961552115@localhost> In-Reply-To: <790fcb38-db6c-41ce-8222-8146be5dbe3b@sentex.net> References: <790fcb38-db6c-41ce-8222-8146be5dbe3b@sentex.net> Subject: Re: dropping udp fragments with ipfw 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-Type: multipart/alternative; boundary="----=_Part_8138_2135212535.1724961552047" X-Mailer: Realworks (718.41) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Queue-Id: 4WvsYj33M6z4FTZ ------=_Part_8138_2135212535.1724961552047 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: mike tancsa Datum: donderdag, 29 augustus 2024 20:51 Aan: FreeBSD Net Onderwerp: dropping udp fragments with ipfw > > 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 > > TARGET=192.168.1.1 > > ipfw add 5 deny log udp from any 53 to $TARGET > > But if that packet is say 2000 bytes and is fragmented, the fragment passes through. I have to add a subsequent rule > > ipfw add 10 deny log udp from any to $TARGET fragment > > 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 ? > > ---Mike > > > > > Fragmentation happens on IP level. As far as I know ipfw does not keep state of fragments. You can use "reass" to let the firewall reassemble the fragmented IP packet and only forward it when it is complete. The manual page of ipfw describes this. Another option I can think of, but which I didn't try is setting up dummynet rate limiting and directing the fragments through it. Regards, Ronald. ------=_Part_8138_2135212535.1724961552047 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: mike tancsa <mike@sentex.net>
Datum: donderdag, 29 augustus 2024 20:51
Aan: FreeBSD Net <freebsd-net@freebsd.org>
Onderwerp: dropping udp fragments with ipfw

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

TARGET=192.168.1.1

ipfw add 5 deny log udp from any 53 to $TARGET

But if that packet is say 2000 bytes and is fragmented, the fragment passes through. I have to add a subsequent rule

ipfw add 10 deny log udp from any to $TARGET fragment

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 ?

     ---Mike

 


Fragmentation happens on IP level. As far as I know ipfw does not keep state of fragments.
You can use "reass" to let the firewall reassemble the fragmented IP packet and only forward it when it is complete. The manual page of ipfw describes this.
Another option I can think of, but which I didn't try is setting up dummynet rate limiting and directing the fragments through it.

Regards,
Ronald.
  ------=_Part_8138_2135212535.1724961552047--