Discard Routing for RFC1918 Addresses

While working with firewalls for the last few years, I’ve seen many logs polluted with scanning traffic. Obviously this is the type of thing that I want to see when someone is legitimately scanning, or attempting to scan, through the firewall. However, there are a few cases that seeing this traffic is simply an indication of some other issue in the network.

An example I have seen on several occasions is someone configuring a network management station to discover 192.168.0.0/16, 172.16.0.0/12 or 10.0.0.0/8. If not properly handled in the routed network architecture, the associated traffic could make its way to the firewall or even to the ISP. An ASA might block the traffic due to policy, reroute it back toward the internal network, drop it due to the intra-interface hairpin configuration, or forward it onward. In most cases, this traffic will cause a lot of “noise” in the syslogs produced by the firewall.

To fully understand the problem, the diagram below can be used for discussion–

DiscardRouting

In this example, R1 has a static default route that points to the IP address of FW1. R1 advertises this via EIGRP to its internal neighbors. If a networked host attempts to reach a nonexistent subnet of 10.0.0.0/8, the traffic would follow the default route to FW1. This issue might also occur if something was communicating with a legitimate internal host and the destination network segment went down. One obvious example would be when a network management station is monitoring a portion of the network that goes offline. To get a baseline understanding, the output below shows the relevant configuration from R1.

R1 Base Configuration

R1(config)#interface FastEthernet0/0
R1(config-if)#ip address 10.255.255.2 255.255.255.0
R1(config-if)#interface FastEthernet0/1
R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#router eigrp 1
R1(config-router)# redistribute static metric 100000 1 255 1 65535
R1(config-router)# passive-interface FastEthernet0/0
R1(config-router)# network 10.0.0.0
R1(config-router)# no auto-summary
R1(config-router)#exit
R1(config)#ip route 0.0.0.0 0.0.0.0 10.255.255.1

This configuration is simple and accomplishes the goal of redistributing the default route into EIGRP. The challenge is, as previously described, packets destined to all unknown destinations make their way to FW1 via the default route.

This is a lab, do not debug ip packet on production devices!

To prove the issue, we can shut down 10.1.4.0/24 on R4. Then while doing a debug ip packet on FW1, we can ping 10.1.4.1 from one of the other routers. The traffic clearly makes it to FW1.

FW1#
*Mar  1 01:59:02.811: IP: tableid=0, s=10.1.1.2 (FastEthernet0/1), d=10.1.4.1 (FastEthernet0/1), routed via FIB

To stop this behavior, we can add the following discard route into R1.

Summary/Network Discard Route

R1(config)#ip route 10.0.0.0 255.0.0.0 Null0

The internal active subnet routes are still reachable. This is true because of the longest match rule.

If the existing route table contains routes that are equal to or are included in the discard route(s), the impact should be fully understood before making the addition. This can happen if classful routes or supernets are used statically, on interfaces, via redistribution or in summary routes.

On the other hand, more specific discard routes could be used. In that case, they will absorb traffic for that entire subnet (again because of the longest match rule). As an example, 10.1.4.0/24 may have been recently removed and the desire is to only blackhole traffic destined to that network.

Subnet Discard Route

R1(config)#ip route 10.1.4.0 255.255.255.0 Null0

A final option is to create a host route for discarding traffic. This is a subset of what we do with remote triggered blackhole routing (RTBH).

Host Discard Route

R1(config)#ip route 10.1.4.25 255.255.255.255 Null0

Adding blackhole, discard or null routes to R1 will prevent stray (or predetermined malicious) packets from moving outward toward FW1. Many environments may benefit from proactively adding discard routes for the full RFC1918 space.

R1(config)#ip route 10.0.0.0 255.0.0.0 Null0
R1(config)#ip route 172.16.0.0 255.240.0.0 Null0
R1(config)#ip route 192.168.0.0 255.255.0 Null0

DiscardRoutingNullIt is worth noting that these are static routes and will also be redistributed by EIGRP. This could be filtered using the technique of choice. One example is using a prefix list to only allow the default route to be redistributed.

ip prefix-list default permit 0.0.0.0/0

route-map default
 match ip address prefix-list default

//add the route-map to the redistribute statement
redistribute static metric 100000 1 255 1 65535 route-map default

Conclusion

Networks tend to produce a considerable amount of stray traffic. As network administrators, we should understand our traffic flow and optimize the use of our resources. RFC1918 addressed traffic should never make it to ISP’s. Moreover, blocking the traffic before it gets to the firewall may allow us to focus on real threats. A final option might be to substitute the null routing with a physical interface and attaching something to log or inspect the traffic.

As with any network change, the impact of these techniques should be fully assessed and understood. Any changes should be made and verified in a maintenance window.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.

2 Responses to Discard Routing for RFC1918 Addresses

  1. madim2013 says:

    Great and informative blog Paul. Keep them coming 🙂 best wishes markus

  2. Bernard says:

    Hi Paul,
    Great post.

    I have a question: is there a way to perform debugging on the cisco IOS router without harming the cpu other than using debug associated with ACL ?

    Thank you in advance

Comments are closed.