Date: Thu, 29 Aug 2024 15:53:36 -0400 From: mike tancsa <mike@sentex.net> To: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= <olivier@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: dropping udp fragments with ipfw Message-ID: <7bcc26a1-4dcc-43bd-bfdb-48f732f646d0@sentex.net> In-Reply-To: <CA%2Bq%2BTcpj7OY0HpUuw7uDGzLQW_GUcXoNkAg2ACDJ65dK7ZDUjg@mail.gmail.com> References: <790fcb38-db6c-41ce-8222-8146be5dbe3b@sentex.net> <CA%2Bq%2BTcpj7OY0HpUuw7uDGzLQW_GUcXoNkAg2ACDJ65dK7ZDUjg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------K040u0YVLnYsANkqqx04x1zg
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 8/29/2024 3:45 PM, Olivier Cochard-Labbé wrote:
>
> On Thu, Aug 29, 2024 at 8:52 PM mike tancsa <mike@sentex.net> wrote:
>
> 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 ?
>
>
> When a packet is fragmented, only the IP header (not the UDP header
> that includes the port number) is copied for all subsequent fragmented
> packets.
> To fix this behavior, you can instruct the firewall to reassemble the
> packet before performing UDP/TCP port filtering.
> Refer to the ipfw(4) man page on the "reass" keyword, which provides
> the following example:
> ipfw add reass all from any to any in
>
> I hope this helps!
Thanks very much, it does! Under DDoS attack, how "expensive" would
this be I noticed there are some default queue limits that probably
would be exhausted fairly quickly. I might look instead for this use
case to use the chelsio NIC rules (via cxgbetool) and just drop with
something like this
cxgbetool t5nex0 filter 10 sip 0.0.0.0/0 sport 53 dip 192.168.1.1/32
proto 17 action drop
cxgbetool t5nex0 filter 11 sip 0.0.0.0/0 dip 192.168.1.1/32 proto 17
frag 1 action drop
to protect the customer downstream and then get rid of rule 11 once the
pps rate drops back to normal.
---Mike
--------------K040u0YVLnYsANkqqx04x1zg
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 8/29/2024 3:45 PM, Olivier
Cochard-Labbé wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+q+Tcpj7OY0HpUuw7uDGzLQW_GUcXoNkAg2ACDJ65dK7ZDUjg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:"courier new",monospace"><br>
</div>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2024 at
8:52 PM mike tancsa <<a href="mailto:mike@sentex.net"
moz-do-not-send="true" class="moz-txt-link-freetext">mike@sentex.net</a>>
wrote:</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But this would kill all UDP fragments. If the host has some
other UDP <br>
application that needs to deal with fragmented packets, is
there a way <br>
to get around that and only drop packets with a certain port
in the <br>
first fragment ?<br>
<br>
</blockquote>
<br>
When a packet is fragmented, only the IP header (not the UDP
header that includes the port number) is copied for all
subsequent fragmented packets.<br>
To fix this behavior, you can instruct the firewall to
reassemble the packet before performing UDP/TCP port
filtering.<br>
Refer to the ipfw(4) man page on the "reass" keyword, which
provides the following example:<br>
ipfw add reass all from any to any in<br>
<br>
<div>I hope this helps! <br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Thanks very much, it does! Under DDoS attack, how "expensive"
would this be I noticed there are some default queue limits that
probably would be exhausted fairly quickly. I might look instead
for this use case to use the chelsio NIC rules (via cxgbetool) and
just drop with something like this <br>
</p>
<p>cxgbetool t5nex0 filter 10 sip 0.0.0.0/0 sport 53 dip
192.168.1.1/32 proto 17 action drop<br>
cxgbetool t5nex0 filter 11 sip 0.0.0.0/0 dip 192.168.1.1/32 proto
17 frag 1 action drop</p>
<p>to protect the customer downstream and then get rid of rule 11
once the pps rate drops back to normal.<br>
</p>
<p> ---Mike<br>
</p>
</body>
</html>
--------------K040u0YVLnYsANkqqx04x1zg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7bcc26a1-4dcc-43bd-bfdb-48f732f646d0>