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–
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
It 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
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.