From nobody Thu Aug 29 19:53:36 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 4WvsR91zNYz52WHg for ; Thu, 29 Aug 2024 19:53:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (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 (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WvsR84qtdz4DQv; Thu, 29 Aug 2024 19:53:40 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 47TJrbF5068646 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Thu, 29 Aug 2024 15:53:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:2cb6:5364:1034:9781] ([IPv6:2607:f3e0:0:4:2cb6:5364:1034:9781]) by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 47TJrZpE030637 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 29 Aug 2024 15:53:36 -0400 (EDT) (envelope-from mike@sentex.net) Content-Type: multipart/alternative; boundary="------------K040u0YVLnYsANkqqx04x1zg" Message-ID: <7bcc26a1-4dcc-43bd-bfdb-48f732f646d0@sentex.net> Date: Thu, 29 Aug 2024 15:53:36 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: dropping udp fragments with ipfw To: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= Cc: FreeBSD Net References: <790fcb38-db6c-41ce-8222-8146be5dbe3b@sentex.net> Content-Language: en-US From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== In-Reply-To: X-Scanned-By: MIMEDefang 2.86 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:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Queue-Id: 4WvsR84qtdz4DQv 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 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
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--