In today’s world of focused client side device attacks, many security analysts and network security engineers have lost sight of defense configurations that can really make a sizable impact in slowing down network intrusion activity. This article is about network infrastructure precautions that, when sensibly deployed, can assist greatly in defense posture. I will focus both on general recommendations and specific Cisco features in the enterprise LAN space.
Network Access / Layer 2 Defenses
1. DHCP Protocol Snooping
The DHCP snooping feature is very effective at preventing rogue DHCP servers from operating on a network. A rogue DHCP server is most dangerous for its ability to deliver alternative Domain Name Server (DNS) addresses. The alternate DNS servers will of course deliver whatever custom DNS responses needed to intercept important traffic, re-direct traffic to fake websites etc. Typically, rogue DHCP server responses will always beat the response time of a central DHCP server due to its layer 2 network adjacency.
Most networks will have centrally deployed DHCP server(s) for IP address delivery. The DHCP snooping feature ensures that DHCP responses can only be transmitted from “trusted” network interfaces, usually interfaces which are uplinks to the core network infrastructure. This technology can be deployed on a per-Virtual LAN (VLAN) basis assuming the feature is present on the specific switch model in hand. (Cisco 3560/3750 switches make this feature available)
If a “non-trusted” switch port receives a DHCP RESPONSE, or DHCP ACK packet, it can be configured to shutdown.
A side effect of deploying this feature is that a tracking table is built within the switch containing details such as the client IP address and MAC/Ethernet address information.
2. Dynamic Address Resolution Protocol (ARP) Inspection (DAI)
DAI leverages the DHCP snooping table to ensure that IP address to MAC address mapping is consistent. It also has a denial of service (DoS) prevention feature to limit the rate of ARP packets on a network segment. DAI is very effective against broadcast gratuitous ARP traffic, typically used for traffic interception purposes by tools like “Ettercap”, and “Cain N’Able”.
3. IP Source Guard
Again, we leverage the DHCP snooping table and place a dynamic IP access list on ingress traffic to ensure that the source IP address for all packets on any one switch interface is indeed the system connected to this port.
4. Switchport Security
Essential to prevent the Content Addressable Memory (CAM) table from being flooded. All network switches track the bridging destination of a packet by it’s destination MAC address. The MAC addresses are placed into the CAM table which has a fixed / limited maximum size. On a typical Cisco switch, the CAM table defaults to 6,000 MAC address entries in the switches default mode. If the switch is optimized for desktop VLAN based switching, higher end switch models (such as the Catalyst 3750) can contain a maximum of 12,000 CAM entries.
When the CAM table on a switch is filled up, the switch will flood/transmit all Ethernet frames out of all switch ports. It is a relatively trivial matter to write code to generate packets to random Ethernet destinations and thus quickly fill a switch CAM table. The goal is to effectively turn the switch into a hub and enable traffic interception.
If a switch can be configured to limit the number of CAM entries permitted on any single port, the CAM flooding attack is defeated.
5. Broadcast Suppression (storm control)
End devices generate broadcasts that are typically associated with ARP traffic. On a gigabit enabled Ethernet port, a 1% broadcast suppression level still leaves open the potential for up to 10Mbps of broadcast traffic. On a Cisco device, we can suppress down to 1% of link speed using “storm-control broadcast level 1”. Multicast can also be suppressed independently from broadcast on some devices.
In environments where multicast is in production use, network engineers need to assess the level of multicast required to/from any one access port and then suppress at that level.
Broadcast suppression is critical in avoiding denial of service (DoS) conditions that can either be created by operational errors, or by a security incident / malware.
Routing / Layer 3 Defenses
Thinking in terms of “defense in depth”, layer 3 defenses act as a backup to the layer 2 defenses in place at the access layer of the network. Layer 3 defenses can be sub-divided into routing device protection (denial of service and infrastructure mapping protection), and network infrastructure protection. We will first consider the network infrastructure category.
1. Disable Proxy ARP (no ip proxy-arp)
Proxy ARP is a feature which allows the router to act as proxy for any host in its adjacent sub-network. When enabled, proxy ARP allows an end host, with an IP address that falls within the sub-network address range, to set its sub-network mask (and broadcast) to almost anything, and still be able to communicate on the network. An end host could even set the smallest mask possible, eliminate a router gateway setting, and still be able to surf the entire IPv4 address space.
The end host is allowed to logically appear on almost any network due to the router “proxying” address resolution of all things for that host. It can be used for denial of service attacks amongst other things.
2. Unicast Reverse Path Forwarding (uRPF) Sanity Check
The uRPF check ensures that the source IP address is reachable from the router interface that received the IP datagram. Cisco devices implement two forms of uRPF check; the strict form which looks at the specific interface the datagram is received on, versus the looser check which will match on any connected interface. The uRPF check is another critical measure which forms a “belt and suspenders” style backup to the IP Source Guard feature in order to defeat source IP address forgery/spoofing.
Two Cisco IOS statements can be used to enforce uRPF sanity checking as follows:
ip verify source reachable-via rx
ip verify source reachable-via any
3. Disable forwarding of IP Options (no ip options)
There are virtually no IPv4 datagrams on the network that require any IP options. The most dangerous IP options from a security perspective are:
Strict Source Route: dictate which router hops a datagram must traverse, and record them.
Loose Source Route: specify optional router hops a datagram can traverse and record them.
Record Route: simply record the router hops a datagram must traverse.
If record route IP options are permitted to be forwarded, they can be used for both reconnaissance and traffic interception purposes. In multicast rich environments, operators need to take note that the “Router Urgent” IP option is used within Internet Group Management Protocol (IGMP) transactions.
4. Disable generation of ICMP type 3, destination unreachable messages (no ip unreachables)
A router that generates ICMP type 3 (unreachable) messages becomes a source of network reconnaissance information. For example:
(a) Type 3, code 0 – “Network Unreachable” can be used to map the internal sub-netting of a network.
(b) Type 3, code 1 – “Host Unreachable” can be used to discover individual hosts within a sub-network.
(c) Type 3, code 13 – “Administratively prohibited” is generated in the context of router Access Control List (ACL) deny statements, and thus can be used to fully map an access control list.
5. Disable directed broadcast (no ip directed-broadcast)
A directed broadcast is generated when a datagram is address to a network address or to a network broadcast address. If we take the class C network of 192.168.99.0/24, and send a datagram to either the 192.168.99.0 or 192.168.99.255 address from outside of that sub-network, then the router interface will typically broadcast the datagram within the network segment/broadcast domain.
This represents security risk in terms of potential network amplification attacks. A common attack from past history was to generate an ICMP ECHO datagram with a spoofed source IP address to a network broadcast address, and subsequently have ALL hosts within that sub-network respond with ICMP ECHO REPLY datagrams. This attack was commonly referred to as a “Smurf” attack.
There are some protocols which depend on directed broadcast to function properly. Wake ON Lan (WOL) is one particular protocol which depends on being able to send UDP datagrams that contain MAC address payloads to a network broadcast address. If your environment requires WOL functionality, you can either filter directed broadcast by source address (for limited risk mitigation), or ensure that the WOL traffic is only generated within the network broadcast domain that will receive it.
In general, having the “no ip directed-broadcast” statement on all router interfaces is a best practice and has in fact become the Cisco IOS default. As stated above, you also have the option of “ip directed-broadcast ACLNAME” to exert more control. Note that you can make an ACL be very specific, down to layer 4 protocol and destination ports if you like however you are still risking DoS by allowing any directed broadcast.
6. Protect your router control-plane from DoS
In the commonly deployed Catalyst-6500 line of router/switches, there are various rate limiters available to assist in protecting the control plane of the router. There are also some useful limits built into the dynamic world of multicast routing. Here are a few items that can be researched further and deployed to any one site's taste:
ip pim register rate-limit
ip multicast route-limit
- can apply to unicast, multicast, bridged traffic, or all traffic
- can be applied in sub-systems such as ACL's, IP forwarding, and CEF
Note that in the hardware based router models such as the Cat-6500, some of these rate limiters also impact ICMP transmission behavior, and interact with the switch virtual interface or routed interface configurations (such as: ip unreachables, and ip redirects).
Internet Access Layer / Border Router Filtering Policy
1. Anti-spoofing and Layer 4 Protocol Filtering
Anti-spoofing is a simple concept that needs to be a standard security practice. No datagram with a source address of your site’s IP address allocation should originate from outside of your network. Additionally, you should never send a datagram with your internal allocated network outside of your network.
Anti-spoofing controls can additionally be combined with Layer 4 protocol filtering to ensure that only the desired layer 4 protocols flow into/out of any network.
Lets imagine that your public address allocation is 240.55.0.0/16. Yes, I know this is considered to be IANA Class E reserved right now, but lets use it for our example. Lets also imagine that you want to perform anti-spoof filtering, and pass IPSEC related protocols, GRE, as well as ICMP, TCP, and UDP across your border routers.
In this example, Cisco IOS based ACL’s can be created as follows, and naturally on your border interface you would have “no ip unreachables” to prevent ACL mapping:
ip access-list extended Border-Inbound
10 permit gre any 240.55.0.0 0.0.255.255
20 permit ahp any 240.55.0.0 0.0.255.255
30 permit esp any 240.55.0.0 0.0.255.255
40 permit icmp any 240.55.0.0 0.0.255.255
50 permit tcp any 240.55.0.0 0.0.255.255
60 permit udp any 240.55.0.0 0.0.255.255
99 deny ip any any log-input
ip access-list extended Border-Outbound
10 permit gre 240.55.0.0 0.0.255.255 any
20 permit ahp 240.55.0.0 0.0.255.255 any
30 permit esp 240.55.0.0 0.0.255.255 any
40 permit icmp 240.55.0.0 0.0.255.255 any
50 permit tcp 240.55.0.0 0.0.255.255 any
60 permit udp 240.55.0.0 0.0.255.255 any
99 deny ip any any log-input
In all likelihood, your site may well have more strict ICMP policies than allowing all ICMP to pass through the border router interface(s). A policy which allows ICMP type 11 (time exceeded), for “traceroute” purposes, might be appropriate. Or even a policy that completely denies ICMP at the network border in some cases. It is common knowledge in the security community that ICMP has been used to tunnel other protocols, or as a control channel mechanism. ICMP Echo Request/Reply are often targeted for tunneling or command/control channel activities.
2. Bogon address filtering
Although IPv4 address resources are dwindling, there are still IP address blocks which are unallocated or reserved by the Internet Assigned Numbers Authority (IANA).
Network security engineers should always filter/drop any datagram that arrives at their network edge with a reserved or unallocated source address. Within the interior of a network, any datagram that is destined for a reserved or unallocated address could either be null routed, or perhaps directed to a security device for analysis and/or detention. This is where we enter the realm of Tom Liston’s LaBrea Tarpit or perhaps a honeynet.org project.
Note that IP address allocations continue to happen and thus any security enforcement implementation that deals with unallocated address filtering / forwarding, needs to be updated on a regular basis.
Team Cymru continues to main a bogon address space reference with various filtering techniques:
3. Strategic Null Routing
Create a static route for your shortest network prefix. If we take the same 240.55.0.0/16 network example above, then create a static route to null0 for this prefix within your routing infrastructure as follows:
ip route 240.55.0.0 255.255.0.0 null0
All of your connected sub-networks will have longer prefixes that the /16 null route example above, and thus traffic for all advertised routes within your network will get to destinations just fine. Any sub-network that you do not have allocated (dark space) will get dropped into the sink. You might also need a route like this to advertise to your upstream BGP provider anyway.
You might want to null route some other address prefixes you don't want running around your public facing network, such as RFC-1918 space for example.
4. Basic BGP Security Tips
I don't claim to be an expert in BGP however some basic security principles can be applied as follows:
(a) Include an ACL on your border interfaces to allow TCP port 179 traffic exclusively from your upstream BGP peering neighbor.
(b) Use an MD5 hash/password with your BGP peers.
(c) Use ip-prefix lists either directly or within route-maps to ensure that you are only advertising the prefixes you intend. If you have created a static null route for your entire network allocation, you might want to only advertise this prefix to your upstream.
(d) Use ip-prefix lists to only accept the routes you desire from your upstream. You can filter unallocated IP space (bogons) using this prefix list. You might have reasons to accept only a subset of routes from a specific provider.
(e) Set a maximum Autonomous System (AS) Path limit to limit risks of accepting an unusually long AS Path.