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 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!” 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:
- https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook/appendxA.html
- https://tools.ietf.org/html/rfc6890
- https://tools.ietf.org/html/rfc6441
- https://media.defense.gov/2020/Aug/18/2002479461/-1/-1/0/HARDENING_NETWORK_DEVICES.PDF
- https://www.cisco.com/c/en/us/support/docs/ip/access-lists/44541-tacl.html
- https://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/
