Re: Ingress filtering on transits, peers, and IX ports

[Brian Knight via NANOG <nanog () nanog org>]

Randy, thank you for the reminder to look also at what services (L4 
ports) should be generally blocked.

As I was implementing a similar rule for logging purposes, I discovered 
an oddity with $VENDOR_C_XR ACLs.  I created the following:

object-group port TCPUDP-BLOCKED
  eq 0
  eq sunrpc
  eq 445
  range 137 139
exit

ipv4 access-list IPV4-INET-IN
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols PERMIT FOR NOW ***
  210 permit udp any port-group TCPUDP-BLOCKED any log
  211 permit udp any any port-group TCPUDP-BLOCKED log
  212 permit tcp any port-group TCPUDP-BLOCKED any log
  213 permit tcp any any port-group TCPUDP-BLOCKED log
[snip]

ipv4 access-list IPV4-INET-OUT
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols PERMIT FOR NOW ***
  210 permit udp any port-group TCPUDP-BLOCKED any log
  211 permit udp any any port-group TCPUDP-BLOCKED log
  212 permit tcp any port-group TCPUDP-BLOCKED any log
  213 permit tcp any any port-group TCPUDP-BLOCKED log
[snip]

After I did this, logs on our syslog server started growing like crazy.  
It was full of entries like:

2020-10-21T01:47:17-05:00,info,RP/0/RSP1/CPU0:Oct 21 01:47:17.972 CDT: 
ipv4_acl_mgr[305]: %ACL-IPV4_ACL-6-IPACCESSLOGP : access-list 
IPV4-INET-OUT (210) permit udp on.net.ip.adr(0) -> off.net.ip.adr(0), 5 
packets
2020-10-21T02:01:08-05:00,info,RP/0/RSP0/CPU0:Oct 21 02:01:08.490 CDT: 
ipv4_acl_mgr[263]: %ACL-IPV4_ACL-6-IPACCESSLOGP : access-list 
IPV4-INET-IN (210) permit udp off.net.ip.adr(0) -> on.net.ip.adr(0), 58 
packets

After wondering why in the world my customers were sending so much data 
on port 0, I found a few different sources saying that port 0 is 
commonly used in place of valid information when dealing with fragments. 
 Turns out that $VENDOR_C_XR does this too.

It wasn't clear why fragments would be matching that rule until I found 
the right vendor doc.  The router will pass IP fragments with a "permit" 
ACL line as long as that fragment's layer 3 info matches the layer 3 
information in the ACL.  The router logs the packet similar the above: 
L4 protocol with source and dest port = 0.  From the doc:

-----

For an access-list entry containing Layer 3 and Layer 4 information:
• The entry is applied to non-fragmented packets and initial fragments.
• If the entry matches and is a permit statement, the packet or
fragment is permitted.
• If the entry matches and is a deny statement, the packet or fragment
is denied.

The entry is also applied to non-initial fragments in the following
manner. Because non-initial fragments contain only Layer 3 information,
only the Layer 3 portion of an access-list entry can be applied. If the
Layer 3 portion of the access-list entry matches, and
• If the entry is a permit statement, the non-initial fragment is
permitted.
• If the entry is a deny statement, the next access-list entry is
processed.
The deny statements are handled differently for non-initial
fragments versus non-fragmented or initial fragments.

-----

Since my rule's L3 info was permit any source to any destination, any IP 
fragment would match the rule, be passed, and be logged.  The solution 
was to add rules explicitly permitting fragments above the layer 4 
rules:

ipv4 access-list IPV4-INET-IN
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols PERMIT FOR NOW ***
  203 permit ipv4 net-group IPV4-CUST any fragments
  204 permit ipv4 net-group IPV4-BACKDOOR-HOSTS any fragments
  205 permit ipv4 any net-group IPV4-BGP-AGG fragments
  206 permit ipv4 any net-group IPV4-CUST fragments
  210 permit udp any port-group TCPUDP-BLOCKED any log
  211 permit udp any any port-group TCPUDP-BLOCKED log
  212 permit tcp any port-group TCPUDP-BLOCKED any log
  213 permit tcp any any port-group TCPUDP-BLOCKED log

Logs are a lot calmer now in terms of new lines per minute, and far more 
relevant.  When we switch those rules to deny statements, we can 
eliminate the rules specifically permitting fragments.

Looks like $VENDOR_J makes things so much simpler for this task.

Thanks,


-Brian


On 2020-10-20 00:18, Randy Bush wrote:
> term blocked-ports {
>     from {
>         protocol [ tcp udp ];
>         first-fragment;
>         destination-port
> 	    [ 0 sunrpc 135 netbios-ns netbios-dgm netbios-ssn 111 445 syslog 
> 11211];
>         }
>     then {
>         sample;
>         discard;
>         }
>     }
>
> and i block all external access to weak devices such as switches, pdus,
> ipmi, ...
>
> randy