What do you do if someone knocks at your door, you see him through the peephole, and you notice he has a black cowl, a crowbar and a big bag? I’m quite sure: you do not open that door! Why? Because, sometimes, the gown does make the friar! And, actually, he’s really not a friar!
Same thing should happen in a network! If you know a packet is a bad packet, why should you let it go through?
In this (stupid) example bad packets are those coming from or going toward bogon IP addresses, that is, addresses picked up from unallocated or private (so, not routable) address spaces. As you know, there are many subnets used only for private addressing (RFC 1918), other are reserved (RFC 3330), and few subnets are still not allocated by IANA… so, if your router is sending or receiving a packet to/from one of these addresses, there is something you should be concerned about (of course, some restrictions may apply!)
How to identify bogons
In order to identify and catch bogon packets we need to know which subnets have to be marked as bogon.
One way to achieve this goal is to deploy static ACLs or route filters on every router we want to secure… a quite boring job on its own! But, what happens when IANA allocate one of the previously unallocated (so, bogon) subnets? Well, we have to change those ACLs on every router! This is a very boring job! Someone at RIPE knows that well!
Do you really want this?
Fortunately, we can use a great utility by Team Cymru: Bogon Route Server Project.
What is Bogon Route Server Project?
For the sake of our sanity, Team Cymru deployed some route servers running BGP which announce bogon prefixes over eBGP peering sessions. Once we have a BGP-aware box, we can get those prefixes and do what we want of them.
Here, I’ll show how to automatically handle bogon prefixes using a Linux box running Quagga, a routing software suite providing implementation of BGP.
What can we do with bogon prefixes?
From our central Quagga box we can distribute those prefixes to our routers, or to customers CPEs, and here we can filter traffic on the basis of source or destination addresses.
For example, we can avoid to route packets with a bogon destination address, simply by adding a route toward bogon prefixes with a null-pointing next-hop; it’s a kind of blackhole filtering:
ip route 192.0.2.1 255.255.255.255 Null0 ip route 18.104.22.168 255.0.0.0 192.0.2.1
With Cymru Bogon Route Server Project we can do this job in a fully automatic and central way.
Of course, we can also drop incoming packets presenting bogon source IP addresses; we can accomplish this using uRPF in a kind of source-based black hole filtering:
interface Serial1/0 ip verify unicast source reachable-via any
Anyway, you, and only you know what’s better for your network!
Now, I would like to show you how to setup a Linux box running Quagga, with a peer session with Cymru routers, and how to use it to distribute bogon prefixes to our routers.
Peering with Cymru Bogon Route Server
At first, we have to ask Team Cymru to setup a BGP session with our Quagga box: to do so we have to contact them on the basis of what we can find on their website. We have to tell them our AS number, our peering IP addresses and optional MD5 passwords and GPG/PGP public key.
You don’t need to have a public AS number, you can also peer with them using a private AS number.
Quagga: bgpd configuration
Once we have installed Quagga and received Cymru details, we just have to edit the bgpd.conf file and add a few lines.
router bgp YOUR_AS_NUMBER bgp router-id YOUR_ROUTER_ID neighbor cymru-bogon peer-group neighbor cymru-bogon remote-as 65333 neighbor cymru-bogon ebgp-multihop neighbor cymru-bogon prefix-list cymru-out out neighbor cymru-bogon route-map CYMRUBOGONS in neighbor cymru-bogon maximum-prefix 100 neighbor CYMRU_PEER_1_IP peer-group cymru-bogon neighbor CYMRU_PEER_2_IP peer-group cymru-bogon ! ip community-list 10 permit 65333:888 ! route-map CYMRUBOGONS permit 10 match community 10 set ip next-hop 192.0.2.1 ! ip prefix-list cymru-out seq 5 deny 0.0.0.0/0 le 32
Prefix-list prevents any update to leave our box toward Cymru routers; route-map allows marked prefixes and set their next-hop to 192.0.2.1, null-pointing route.
Automagically our Quagga box gets bogon prefixes:
QuaggaBox#show ip bgp BGP table version is 0, local router ID is YOUR_ROUTER_ID Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 22.214.171.124 192.0.2.1 0 0 65333 i *> 192.0.2.1 0 0 65333 i * 126.96.36.199 192.0.2.1 0 0 65333 i *> 192.0.2.1 0 0 65333 i [cut] * 192.168.0.0/16 192.0.2.1 0 0 65333 i *> 192.0.2.1 0 0 65333 i * 198.18.0.0/15 192.0.2.1 0 0 65333 i *> 192.0.2.1 0 0 65333 i * 188.8.131.52/8 192.0.2.1 0 0 65333 i *> 192.0.2.1 0 0 65333 i Total number of prefixes 32
Now, setup our Quagga box to bring up peering with your routers; just add few config lines to bgpd.conf:
router bgp YOUR_AS_NUMBER neighbor Clients peer-group neighbor Clients prefix-list DoNotAcceptAnything in neighbor Clients route-map CYMRUBOGONS out neighbor Clients ebgp-multihop neighbor Clients send-community neighbor YOUR_ROUTER1_IP remote-as YOUR_AS_NUMBER neighbor YOUR_ROUTER1_IP peer-group Clients neighbor YOUR_ROUTER2_IP remote-as YOUR_AS_NUMBER neighbor YOUR_ROUTER2_IP peer-group Clients ! ip prefix-list DoNotAcceptAnything seq 5 deny 0.0.0.0/0 le 32
We can deploy iBGP or eBGP configuration on our routers and automatically get bogon prefixes.
This is a sample configuration:
ip route 192.0.2.1 255.255.255.255 Null0 ! ip bgp-community new-format ! router bgp YOUR_AS_NUMBER no synchronization bgp log-neighbor-changes neighbor YOUR_QUAGGA_BOX_IP remote-as YOUR_AS_NUMBER neighbor YOUR_QUAGGA_BOX_IP update-source Loopback0 neighbor YOUR_QUAGGA_BOX_IP prefix-list DoNotAnnounceAnything out neighbor YOUR_QUAGGA_BOX_IP route-map CymruBogons in no auto-summary ! ip community-list standard CymruBogons permit 65333:888 ! ip prefix-list DoNotAnnounceAnything seq 5 deny 0.0.0.0/0 le 32 ! route-map CymruBogons permit 10 match community CymruBogons set ip next-hop 192.0.2.1
And now, let’s verify our job…
Router#show ip bgp BGP table version is 163, local router ID is X.Y.Z.W Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i184.108.40.206 192.0.2.1 0 100 0 65333 i *>i220.127.116.11 192.0.2.1 0 100 0 65333 i [cut] *>i192.168.0.0/16 192.0.2.1 0 100 0 65333 i *>i198.18.0.0/15 192.0.2.1 0 100 0 65333 i *>i18.104.22.168/8 192.0.2.1 0 100 0 65333 i
BGP gets bogon prefixes from our Quagga box; let’s take a look at our routing table, with focus on 192.168.0.0:
Router#show ip route | i 192.168 O IA 192.168.4.0/24 [110/196] via 192.168.254.3, 5d05h, Tunnel1 O IA 192.168.5.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0 [cut] O IA 192.168.1.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0 B 192.168.0.0/16 [200/0] via 192.0.2.1, 1d01h
Here we have some private prefixes from OSPF, used for branch offices, and they have the right paths; in the last line, the whole 192.168.0.0/16 goes toward the null-pointing route.
Remember: more specific route wins; until we have our private prefixes from OSPF no packets will be filtered out.
Router#sh ip cef 192.168.222.1 192.168.0.0/16, version 411, epoch 0 0 packets, 0 bytes via 192.0.2.1, 0 dependencies, recursive next hop 192.0.2.1, Null0 via 192.0.2.1/32 valid null (drop) adjacency
Well done: it’s simple and it works fine! Anyway, remember to take precautions: do no send bogon prefixes to your BGP peers (no-export plus safeguard communities) and keep in mind every network is different from others!
Team Cymru: Bogon Route Server Project
Quagga: Quagga Software Routing Suite
Andree Toonk: Bong Traffic Analysis in 2006
Rob Thomas (on Team Cymru website): 60 Days of Basic Naughtiness, a study conducted in 2001.
Latest posts by Pier Carlo Chiodi (see all)
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
- RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes - 9 March 2016