Automatic Bogon Firewalling Using uRPF and Team Cymru
A "bogon" is a prefix (IP subnet) that shouldn't be on the internet. These include RFC1918 private IP addresses, as well as public IP blocks that haven't been assigned to companies by their local RIR. The folks over at Team Cymru have a great list of all the IPv4 and IPv6 bogons. It's updated frequently, and is available as static text files or a BGP feed.
Routers have an option called a uRPF check, short for Unicast Reverse Path Forwarding, which looks at an incoming packet and compares the source address against the routing table. If the packet was received on the same interface that the router would use for the return traffic, the packet is allowed though. Otherwise, it gets discarded. Combine this with the bogon routes you get from Team Cymru, and you've got automatic bogon filtering.
Why might you want it?
- DDoS attacks may have spoofed source IPs, which could include bogon IPs.
- Some nefarious people may be cyber squatting on some unassigned IPs, and using them for any number of less-than-good purposes.
- You've set up a dark net. Instead of dropping packets from bogons, you could redirect them to a collector.
- You want to be the Alpha Nerd.
It doesn't even need to be using Team Cymru's list. If you have a bunch of routers, and just want some centralized firewall control, you can use this method.
The example below is using IPv6 transport for the BGP session, and is only receiving the IPv4 bogons. You can mix and match any combination. Just update your config accordingly.
First, set up the policy for received routes. These can be identified by a BGP community, route tag, "any", or any other method that your route source provides. In this case, I'm matching on the BGP community 65000:888. Then I set up a null route. It all comes together in the route-map, which matches the community, then sets the next hop to the null route. Because the router will have a route for each bogon, uRPF will have a viable route to check against, even though it's a null route. If you're running a dark net, you can set the next-hop IP as your collector, instead of the null interface.
Lastly, we need an outbound policy. This one sends no routes to the BGP peer.
ip community-list expanded CYMRU-BOGONS-COMMUNITY permit 65000:888 ip route 192.0.2.1 255.255.255.255 Null0 name NULL_ROUTE_FOR_CYMRU_BOGONS route-map CYMRU-BOGONS-IN permit 10 description BOGONS LIST FOR URPF FILTERING match community CYMRU-BOGONS-COMMUNITY set ip next-hop 192.0.2.1 ip prefix-list CYMRU-BOGONS-OUT seq 10 deny 0.0.0.0/0 le 32
This is a pretty standard BGP config. Two things to note are the multihop setting and the address-family. The multihop is there because I am not directly connected to the BGP neighbor. The address-family is required as the Team Cymru BGP feed is multi-protocol (MP-BGP), and can carry both IPv4 and IPv6 routes. To receive the IPv6 bogon list, I would just have to add an identical address family, but under "address-family ipv6".
The first line in the config snippet below may be in by default on some systems. It just makes your router work with BGP communities in the "ASN.community" format.
ip bgp-community new-format router bgp 65535 bgp log-neighbor-changes neighbor CYMRU peer-group neighbor CYMRU remote-as 65000 neighbor CYMRU description CYMRU BOGONS LIST neighbor CYMRU ebgp-multihop 255 neighbor CYMRU password 7 1234567890 neighbor CYMRU update-source Loopback6 neighbor 2000:B00:B00:10::2 peer-group CYMRU neighbor 2000:C00:C00:10::2 peer-group CYMRU address-family ipv4 neighbor CYMRU soft-reconfiguration inbound neighbor CYMRU prefix-list CYMRU-BOGONS-OUT out neighbor CYMRU route-map CYMRU-BOGONS-IN in neighbor 2000:B00:B00:10::2 activate neighbor 2000:C00:C00:10::2 activate no auto-summary no synchronization exit-address-family
Enabling uRPF is very simple: just add ip verify unicast reverse-path to your WAN interface. If you're using DHCP, the DHCP communication may get dropped by uRPF, depending on which version of code you're running. If you can't get an IP, you will need to use the ACL below. Sadly, it doesn't seem to support named ACLs yet.
access-list 100 remark ---- ACL FOR URPF ---- access-list 100 permit udp any eq bootps any eq bootpc access-list 100 deny ip any any interface FastEthernet0 description EXTERNAL ip verify unicast reverse-path 100
Fix for DMVPN
If you're running DMVPN, you may run into some issues. This could actually be a bug. If you have client routers that are behind NAT, they are likely to have a private IP, and all the RFC1918 subnets are in the bogons list. DMVPN attempts to communicate with the client using NAT Traversal (NAT-T) on UDP port 4500. There appears to be a bug where the router will send packets addressed to the client's public IP out the next hop for the private IP (the null route). So instead of sending out the WAN interface, it will send them out the null interface. I verified this by replacing the null route with an interface route to a sniffer.
The solution is easy enough: deny the routes from the BGP feed, and manually place the RFC1918 IPs in your WAN interface ACL.
Note that the route-map statement below is sequence number 5, and the one in the first section is number 10. This will insert the fix before the "permit" policy.
ip prefix-list CYMRU_NAT-T_FIX seq 10 permit 192.168.0.0/16 route-map CYMRU-BOGONS-IN deny 5 description TO FIX NAT-T ISSUE match ip address prefix-list CYMRU_NAT-T_FIX match community CYMRU-BOGONS-COMMUNITY