Internet Edge Drop Device ACL

A dedicated drop device is a network appliance, usually a router or L3 switch that sites at the very edge of your network infrastructure. Beyond the firewall, and usually acts a as either layer 2 or 3 transit devices for your ISP interconnect uplinks for public or untrusted segments. Distinguishing a dedicated drop devices in your infrastructure interconnected chain of paths can enhance and offload many irrelevant packet transactions from ever hitting your Firewall mitigation appliances. The thought around this approach is to remove processing cycles away from your more expensive security appliances such as firewalls or IPS, allowing said devices to dedicate their efforts toward more complicated session and/or application driven attacks.

Where to start…

A common trend I’ve seen over the years at multiple business is to create such a ACL on the perimeter edge device to block way too much. ACL length kept a short as possible. I’ve seen some grow to over 100 lines, which is unnecessary. The justification is usually an outbreak or single malicious actor caused said actors IP to beadded the Drop ACL. In my opinion this is not the point of this Drop ACL. The Drop ACL should be static, well thought-out and compared against services you offer to the public internet, not a “o crap block it now!”  access-list. A common counter argument I hear is “our Drop ACL has grown over time to form our own reputation based blocklist”, I believe this should be handled by your firewall or IPS device. Most Firewalls or IPS now-a-days have built in reputation based intelligence, and if needed a user-defined blocklist can be managed much easier as well. The table below is a basic table to document the Drop ACL creation process, this should be brainstormed with NetAdmins, Security Officers, and select business owners to arrive at a well established drop list without negatively impacting your business. For example, you will want to talk with your business owners to know if you do indeed need ICMP or PING because it is used by a legitimate third-party to monitor your network health and status.

Simple Starting List
ICMP IP Proto 1 Does your business or app require to expose ICMP messages to public/untrusted network?
PING IP Proto 1 Type 0 Does your business or app require any public endpoint to ping your global IP?
SNMP TCP/UDP 161/162 Management Service, should not be coming from public/untrusted network
BOOTP UDP 67/68 BOOTP from external source, common with residential or business ISPs. Not usually seen with dedicated ISPs.
TFTP UDP 69 Management Service, should not be coming from public/untrusted network
TELNET TCP 23 Management Service, should not be coming from public/untrusted network
SSH/SFTP TCP 22 Management Service and Secure File Transfer, should not be coming from public/untrusted network, check with business.
EIGRP IP Proto 88 More likely then not, you won’t be using OSPF on your Internet Edge, more likely BGP
OSPF IP Proto 89 More likely then not, you won’t be using OSPF on your Internet Edge, more likely BGP
RADIUS UDP/TCP 1812/1813 AAA mechanism for user-based authentication/access/accounting. Should never be used on public interfaces. Use on internal OOB management network.
TACACS+ UDP/TCP 49 AAA mechanism for user-based authentication/access/accounting. Should rarely be used on public interfaces. Use on internal OOB management network.
SYSLOG TCP/UDP 514 Forwarding and transferring syslog based messages. Should not be on public interface for DLP reasons.
etc…

You can see that there is not a “one size fits all” approach, however there are several common overlaps and many of the items on this basic Drop ACL tend to be management or routing protocols. For example from the list above, you should never see SNMP coming from a public endpoint, even if you have a external third-party monitoring your assets via SNMP for you. Another example is, I once worked for a consulting company that used TACACS based connections over the public internet to encrypt user-logins of managed devices. This was scene as acceptable to the business because TACACS is an encrypted protocol. Therefore you will need to decide with your team(s) what makes the most sense.

Adding a Wider Range of items to the List…

Just like the previous section, the Drop ACL should not be a massive list of IP hosts and ranges. I would even argue against things like Geo Blocklist being on this list as most modern Firewalls have this ability built in.

Basic IP Host and Ranges
RFC-1918 “Private Address Space”
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Private Ranges, not routable on the internet. Prevent spoofing.
RFC-3927 “Link Local Address Space”
169.254.0.0/16
Commonly used on windows machines when DHCP/BOOTP is not used on a LAN network.
RFC-5737 “Test Network Address Space”
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24
These are IP address ranges used in public documentation TEST-NET-1, TEST-NET-2,TEST-NET-3
RFC-3330 “Special-Use Reservations”
0.0.0.0/8
127.0.0.0/8
255.255.255.255/32
These are special IP address reservations that should not be internet routable, and are common with spoofing and source-less based attacks. 255.255.255.255/32 should never be forwarded outside the subnet source.
RFC-3068 “6to4  Relay Anycast”
192.88.99.0/24
Reserved by IANA to help with migration from IPv6 to IPv4 via 6to4 anycast relaying.
RFC-2544 “Internet Benchmark”
198.18.0.0/15
Block of IP address to be used for benchmark interconnected devices and documentation.
RFC-1112-SECTION-4 “Reserved for Future User”
240.0.0.0/4
255.0.0.0/8
Huge block of IP addresses dedicated for future use by IANA, but never used. SMH.
Crafting a basic Drop ACL brew…

Putting the above two(2) sections into IOS format, I arrived at the following ACL.

ip access-list extended DropACL
permit icmp any any traceroute
permit icmp any any echo-reply
!
remark *******Block Routing Protocols*******
deny ospf any any
deny eigrp any any
remark *******Block Mgmt Services*******
deny udp any any eq bootpc
deny udp any any eq bootps
deny udp any any eq snmp
deny tcp any any eq snmp
deny udp any any eq syslog
deny tcp any any eq syslog
deny udp  any any eq snmptrap
deny tcp any any eq snmptrap
deny tcp any any eq telnet
deny udp any any eq tftp
deny tcp any any eq 22
deny tcp any any eq tacacs
deny udp any any eq tacacs
deny tcp any any range 1812 1813
deny udp any any range 1812 1813
remark *******RFC1918 Spoofing*******
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
remark *******RFC3330 Spoofing*******
deny ip 0.0.0.0 0.255.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 192.0.2.0 0.0.0.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 192.88.99.0 0.0.0.255 any
deny ip 198.18.0.0 0.1.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
deny ip 255.0.0.0 0.255.255.255 any
remark *******Unallocated Spoofing*******
deny ip 128.0.0.0 0.0.255.255 any
deny ip 191.255.0.0 0.0.255.255 any
deny ip 192.0.0.0 0.0.0.255 any
deny ip 223.255.255.0 0.0.0.255 any
!
remark *******Multicast Spoofing*******
deny ip 224.0.0.0 31.255.255.255 any
!
remark ***********************************
remark ***Allow Transit Traffic***********
permit ip any any

Look at that, we kept it under 50 lines! Most of the duplicate lines are because many of these protocols can use either UDP or TCP as transports.

Ask my Dad the ISP for help…

The IETF derived a “best pratice” to further assist in the fight against spoofing attacks. IETF came up with Ingress Filtering in RFC 2827 and RFC-3704. These are not hard tangible items throughout the internet, but a best practice “honor” based method to reduce source address spoofing of internet traffic. In basic terms it documents that ISPs acting as upstream providers for customers should filter packets entering their(ISP) network from these customers and discard them that do not match the source addressing agreed upon and allocated to that customer. See https://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/

This will not really protect you, but it is you doing your part to help in case an asset of yours becomes comprised.

Sources:

I'm an Engineer with over 15 years experience in IT infrastructure. A DIY woodworking hobbyist and avid tennis player!

Leave a Reply