View source for 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 [http://www.team-cymru.org/ 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.

==Policies==
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.

<PRE>
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
</PRE>


==BGP==
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.

<PRE>
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
</PRE>


==uRPF==
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.

<PRE>
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
</PRE>


==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.

<PRE>
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
</PRE>