Mailing List Archive

Howdy on my phone so no detail but the Flow being reported will be due to fragments and not necessarily port 0
The below link has details on how to block fragments

<https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html>
Access Control Lists and IP Fragments<https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html>
cisco.com<https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html>
[favicon.ico]<https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html>

D’Wayne Saunders

On 6 Dec 2023, at 08:27, Hank Nussbacher via cisco-nsp <cisco-nsp@puck.nether.net> wrote:

?[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

We encountered something strange. We run IOS-XR 7.5.2 on ASR9K platform.

Had a user under udp/0 attack. Tried to block it via standard ACL:


ipv4 access-list block-zero
20 deny udp any any eq 0
30 deny tcp any any eq 0
40 permit ipv4 any any


Applied to interface:

ipv4 access-group block-zero ingress
ipv4 access-group block-zero egress


Yet, based on Kentik, we had no effect and the udp/0 attack just
continued - as if the Cisco ACL is totally ignored. Or am I missing
something in the ACL listed above?


Thanks,

Hank

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Tue, Dec 05, 2023 at 11:27:21PM +0200, Hank Nussbacher via cisco-nsp wrote:
> We encountered something strange.? We run IOS-XR 7.5.2 on ASR9K platform.
>
> Had a user under udp/0 attack.? Tried to block it via standard ACL:
>
>
> ipv4 access-list block-zero
> ?20 deny udp any any eq 0
> ?30 deny tcp any any eq 0
> ?40 permit ipv4 any any

D'Wayne Saunders already pointed at this most likely being fragments -
large packet reflections, and all non-initial fragments being reported by
IOS* as "port 0" (so you should see 1500 byte regular UDP as well, with
a non-0 port number)

IOS XR syntax for fragment blocking is

deny ipv4 any any fragments

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

On 05/12/2023 23:44, Gert Doering wrote:

> D'Wayne Saunders already pointed at this most likely being fragments -
> large packet reflections, and all non-initial fragments being reported by
> IOS* as "port 0" (so you should see 1500 byte regular UDP as well, with
> a non-0 port number)
>
> IOS XR syntax for fragment blocking is
>
> deny ipv4 any any fragments
>
> gert

To both D'Wayne and Gert - thx!

Regards,
Hank
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Dec 6, 2023, at 04:45, Gert Doering via cisco-nsp <cisco-nsp@puck.nether.net> wrote:

deny ipv4 any any fragments

This is approach is generally contraindicated, as it tends to break EDNS0, & DNSSEC along with it.

If the target is a broadband access network, you can use flow telemetry to measure normal rates of non-initial fragments destined for it (said rates are generally minimal). You can then implements a QoS policy to police down non-initial fragments in excess of the rate you’ve decided upon, ensuring that you leave some headroom for normal variations in traffic rates.

It would be a good idea to exempt the well-known, well-run open resolvers like Google DNS, Quad9, OpenDNS, et. al. from this policy, as well as your own on-net resolvers.

If the target is a downstream transit customer, something sitting in an IDC, etc., more research & nuance in terms of tACLs, policies, & rates is likely necessary.

--------------------------------------------

Roland Dobbins <roland.dobbins@netscout.com>

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Wed, Dec 06, 2023 at 09:00:58AM +0000, Dobbins, Roland wrote:
> On Dec 6, 2023, at 04:45, Gert Doering via cisco-nsp <cisco-nsp@puck.nether.net> wrote:
>
> > deny ipv4 any any fragments
>
> This is approach is generally contraindicated, as it tends to break EDNS0, & DNSSEC along with it.

I'd argue that the DNS folks recommend using EDNS0 with 1232 bytes, which
works just fine to avoid fragments...

http://www.dnsflagday.net/2020/

... but of course you are right that unconditionally dropping all fragments
is not a recommended approach unless acutely under attack.

What we do here is exactly what you recommend - rate-limit fragments to
some 200Mbit/s per network ingress, which is ~50x the normal peak rate
of fragments seen, and closely monitor drop counts.

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

On Dec 6, 2023, at 17:46, Gert Doering <gert@greenie.muc.de> wrote:

I'd argue that the DNS folks recommend using EDNS0 with 1232 bytes, which
works just fine to avoid fragments...

Of course, the last true Internet flag day was in 1994, flag days aren’t possible anymore, & this is far from universally implemented. ;>

I know you know this, just stating it for the record. Concur 100% otherwise, of course.


--------------------------------------------

Roland Dobbins <roland.dobbins@netscout.com>

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/