Skip site navigation (1)Skip section navigation (2) 
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 

[-- Attachment #1 --]
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

[-- Attachment #2 --]
<!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:&quot;courier new&quot;,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 &lt;<a href="mailto:mike@sentex.net"
              moz-do-not-send="true" class="moz-txt-link-freetext">mike@sentex.net</a>&gt;
            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>

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7bcc26a1-4dcc-43bd-bfdb-48f732f646d0>