{"id":3598,"date":"2021-04-17T10:38:19","date_gmt":"2021-04-17T14:38:19","guid":{"rendered":"https:\/\/infotechguy.net\/?p=3598"},"modified":"2025-02-22T12:37:56","modified_gmt":"2025-02-22T17:37:56","slug":"internet-edge-drop-device-acl","status":"publish","type":"post","link":"https:\/\/infotechguy.net\/?p=3598","title":{"rendered":"Cisco ACL — Dedicated Internet Edge Drop Device"},"content":{"rendered":"

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.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

Where to start…<\/h5>\n

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 be added 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!”\u00a0 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.<\/p>\n

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

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.<\/p>\n

Adding a Wider Range of items to the List…<\/h5>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Basic IP Host and Ranges<\/strong><\/span><\/td>\n<\/tr>\n
RFC-1918 “Private Address Space”<\/a><\/td>\n\n
10.0.0.0\/8\r\n172.16.0.0\/12\r\n192.168.0.0\/16<\/pre>\n<\/td>\n
Private Ranges, not routable on the internet. Prevent spoofing.<\/td>\n<\/tr>\n
RFC-3927 “Link Local Address Space”<\/a><\/td>\n\n
169.254.0.0\/16<\/pre>\n<\/td>\n
Commonly used on windows machines when DHCP\/BOOTP is not used on a LAN network.<\/td>\n<\/tr>\n
RFC-5737 “Test Network Address Space”<\/a><\/td>\n\n
192.0.2.0\/24\r\n198.51.100.0\/24\r\n203.0.113.0\/24<\/pre>\n<\/td>\n
These are IP address ranges used in public documentation TEST-NET-1, TEST-NET-2,TEST-NET-3<\/td>\n<\/tr>\n
RFC-3330 “Special-Use Reservations”<\/a><\/td>\n\n
0.0.0.0\/8\r\n127.0.0.0\/8\r\n255.255.255.255\/32<\/pre>\n<\/td>\n
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.<\/td>\n<\/tr>\n
RFC-3068 “6to4\u00a0 Relay Anycast”<\/a><\/td>\n\n
192.88.99.0\/24<\/pre>\n<\/td>\n
Reserved by IANA to help with migration from IPv6 to IPv4 via 6to4 anycast relaying.<\/td>\n<\/tr>\n
RFC-2544 “Internet Benchmark”<\/a><\/td>\n\n
198.18.0.0\/15<\/pre>\n<\/td>\n
Block of IP address to be used for benchmark interconnected devices and documentation.<\/td>\n<\/tr>\n
RFC-1112-SECTION-4 “Reserved for Future User”<\/a><\/td>\n\n
240.0.0.0\/4\r\n255.0.0.0\/8<\/pre>\n<\/td>\n
Huge block of IP addresses dedicated for future use by IANA, but never used. SMH.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Crafting a basic Drop ACL brew…<\/h5>\n

Putting the above two(2) sections into IOS format, I arrived at the following ACL.<\/p>\n

ip access-list extended DropACL\r\npermit icmp any any traceroute\r\npermit icmp any any echo-reply\r\n!\r\nremark *******Block Routing Protocols*******\r\ndeny ospf any any\r\ndeny eigrp any any\r\nremark *******Block Mgmt Services*******\r\ndeny udp any any eq bootpc\r\ndeny udp any any eq bootps\r\ndeny udp any any eq snmp\r\ndeny tcp any any eq snmp\r\ndeny udp any any eq syslog\r\ndeny tcp any any eq syslog\r\ndeny udp  any any eq snmptrap\r\ndeny tcp any any eq snmptrap\r\ndeny tcp any any eq telnet\r\ndeny udp any any eq tftp\r\ndeny tcp any any eq 22\r\ndeny tcp any any eq tacacs\r\ndeny udp any any eq tacacs\r\ndeny tcp any any range 1812 1813\r\ndeny udp any any range 1812 1813\r\nremark *******RFC1918 Spoofing*******\r\ndeny ip 10.0.0.0 0.255.255.255 any\r\ndeny ip 172.16.0.0 0.15.255.255 any\r\ndeny ip 192.168.0.0 0.0.255.255 any\r\nremark *******RFC3330 Spoofing*******\r\ndeny ip 0.0.0.0 0.255.255.255 any\r\ndeny ip 127.0.0.0 0.255.255.255 any\r\ndeny ip 192.0.2.0 0.0.0.255 any\r\ndeny ip 169.254.0.0 0.0.255.255 any\r\ndeny ip 192.88.99.0 0.0.0.255 any\r\ndeny ip 198.18.0.0 0.1.255.255 any\r\ndeny ip 240.0.0.0 15.255.255.255 any\r\ndeny ip 255.0.0.0 0.255.255.255 any\r\nremark *******Unallocated Spoofing*******\r\ndeny ip 128.0.0.0 0.0.255.255 any\r\ndeny ip 191.255.0.0 0.0.255.255 any\r\ndeny ip 192.0.0.0 0.0.0.255 any\r\ndeny ip 223.255.255.0 0.0.0.255 any\r\n!\r\nremark *******Multicast Spoofing*******\r\ndeny ip 224.0.0.0 31.255.255.255 any\r\n!\r\nremark ***********************************\r\nremark ***Allow Transit Traffic***********\r\npermit ip any any<\/pre>\n
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.<\/p>\n
Ask my Dad the ISP for help…<\/h5>\n
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\/<\/a><\/p>\n
This will not really protect you, but it is you doing your part to help in case an asset of yours becomes comprised.<\/p>\n
Sources:<\/h5>\n