Ingress filtering on transits, peers, and IX ports

Thu Oct 22 07:34:37 UTC 2020

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