The Battle Against BOGONs (& How You Should Treat Them)

A lot of engineers aren’t familiar with the term ‘BOGON’ in terms of networking. Honestly, that’s as much of a good thing as it is a bad thing – if you never have to see or touch a BOGON in your career, I’d say you’re in a pretty fortunate spot.

For the rest of us, BOGONs can often be a security nuisance. In some rare cases, they can turn into network engineering nightmares.

Let’s have a brief look at BOGONs from the ground up, and understand how to defend against them on a day-to-day basis.

What Is A BOGON?

BOGONs, or BOGON Martians (as they were historically called by some), are packets with either a globally-invalid routing IP address as the source, destination, or both.

What do I mean by globally-invalid routing IP address? That’s a bit of a technical mouthful, after all. I’m referring to IP addresses that, under normal circumstances, should never be seen coming into your network perimeter or going out of your network perimeter.

They can be a variety of different things. The most easily recognized culprits are the 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 private address blocks – they should never make it past your edge router without being NAT’d. Another common culprit is an APIPA address in the 169.254.0.0/16 space – sometimes witnessed on a LAN, but should never be coming inbound through your perimeter router’s WAN interface.

According to bgphelp.com, the list of instantly-recognizable BOGONs is as follows (although this isn’t a complete list, and we’ll go over why in a moment):

  • 0.0.0/8
  • 10.0.0.0/8
  • 100.64.0.0/10
  • 127.0.0.0/8
  • 169.254.0.0/16
  • 172.16.0.0/12
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.168.0.0/16
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/3

Some of these are private addresses, while others were reserved as “design or drafting” scopes as documented in various RFCs. The most debatable entry in this list, as some of you may have noted, is the 224.0.0.0/3 entry which would contain some legitimate multicast traffic – bear in mind that multicast is generally not considered Internet-routable traffic, which is why it’s classed as being BOGON in nature. You wouldn’t normally see legitimate multicast traffic on your router’s WAN interface.

However, this listing isn’t complete. There’s another factor to be measured for consideration, and it’s not immediately obvious to many…

What About Unallocated IP Address Blocks?

Remember how years ago in the mid-2000s, many news resources were crying on street corners that the “world was out of available IPv4 addresses”?

The truth, more correctly put, is that all available IPv4 address blocks were allocated at the time to various interested parties. The world wasn’t really “out” of IPv4 addresses.

Times have since changed. Progressively more providers have either transitioned over to IPv6 and have been selling off portions of their “old” IPv4 address spaces, or providers have been sub-dividing their address blocks into smaller segments to keep and then releasing the rest back to IANA. What this means for us common folk is that there are actually unused IPv4 address blocks floating around the routable Internet right now.

The same can be said for IPv6, although for a different reason. There are still vast chunks of IPv6 addressing space that aren’t yet used by anyone, so there’s a ton of IPv6 addresses that aren’t yet present in a MP-BGP routing table on an IPv6 Internet backbone router. There’s a much bigger pool to pull from for them.

These addresses, while constantly in a state of flux, also class as BOGONs because they technically have an invalid source.

If your router were to receive one, and you weren’t using BGP and were otherwise using static routing (0.0.0.0/0) or an IGRP to avoid running BGP, it would needlessly consume your bandwidth because your router would forward a response to it along the upstream chain until it hit a router that was running BGP, which would then likely drop it because a route doesn’t exist for it.

Countryipblocks.net keeps a pretty up-to-date listing of all current BOGONs. If you’re ever in doubt, check their listing to confirm whether or not an IP address you’re seeing is a BOGON or not.

The Story Of My Experience With BOGONs

Years ago, I had my personal server farm in a different collocated datacenter than they’re presently in. Much to my distaste, I was using a CenturyLink bandwidth reseller who had forced me to use 95th-percentile bandwidth. (if you’re not familiar with 95th-percentile, it’s where you’re paying for fixed rate bandwidth, such as 100Mbps, but you’re allowed to go over that and you have to pay extra each month for how much you do go over)

To get around the idea of ever having to pay for additional charges as part of the 95th-percentile package, I rate-throttled both my on-premise router as well as my offsite backup program at my house to be at 95Mbps so that I wouldn’t go over the fee threshold.

Much to my surprise, my second month’s bill from the datacenter showed that I’d actually gone over my bandwidth allowance and had dipped into the 95th-percentile area.

The first time this happened, I set my rate-throttling down to 90Mbps – I figured I’d either just miscalculated or there was enough transmission overhead to have pushed me over (I didn’t go over by much, just a few Mbps). My Internet-facing systems at the location were firewalled pretty darn good and I was sure it wasn’t something internal to me. It still cost me roughly $50/month extra.

The next month, the report showed that I’d somehow gone over the threshold again – still only by a few Mbps. By this point, I was starting to get suspicious of what was actually going on. I wasn’t sure if the provider was misreporting my usage, or if I’d misconfigured my throttling.

I spun up a virtual machine on my infrastructure in the datacenter for syslog, pointing my shiny new Cisco ASA 5505 (I was a simpler engineer at that time) to it for logging, and set some thresholds for logging traffic to get some hard evidence should the issue resurface.

Sure enough, I somehow went over my allocation on month four. Going through my logs, I found my reason why – the extra traffic I was supposedly getting WAS actually there, and it was almost entirely BOGONs due to an invalid source IP address. Up to this point, I’d never dealt firsthand with the BOGON threat before in my career.

Looking at Hurricane Electric’s listing of current Tier 1/2 ISPs and BGP AS numbers that are recognized as allowing BOGONs through their network, I noted that CenturyLink occupies a marvelous spot right at the top of this listing. My BOGONs could quite likely be coming from CenturyLink…  but there was also the suspicious possibility that my collocation vendor was sourcing them on their own equipment because with an illegitimate source IP address, they can’t be traced unless you’re granularly hunting for them upstream.

​Contacting my collocation datacenter, I briefly described the situation to them and asked if they’d be willing to (as a best practice) block BOGONs at their perimeter. If that wasn’t a possibility, I then asked if they’d be willing to put an ingress ACL on my uplink interface on their equipment to block BOGON ranges. They told me that this was do-able on my interface…    for an additional monthly price.

At this point, evidence was beginning to mount that my datacenter provider was using BOGONs to elicit extra monthly revenue off of me. If they couldn’t get the money through BOGONs, then they’d get it through the ACL I wanted. While I couldn’t prove this directly, I decided I wasn’t going to get anywhere with the issue if I continued to give them my business, and I gave notice to vacate after I found an alternate vendor. After learning about my experience with them, a friend of mine who had equipment there as well also starting packet capturing and found that he was seeing BOGONs as well. He left shortly after I did.

Since then, that datacenter has gone through an organizational rebrand and traded out a large portion of their staff. I’m hopeful that they aren’t still doing the same thing anymore, so I’ll hold off on mentioning who they are in the outlook that those days are behind them.

Fortunately, the days of being ignorant to BOGONs are also behind me, too.

How To Defend Against BOGONs

If you’re going with an Internet Service Provider for anything besides arguably a personal connection, BOGON protection should be an action item on your checklist of “Needs”. Should your ISP be a Tier 3 ISP, find out who they’re using for upstream bandwidth or if your ISP is Tier 1/2, check if they’re on the Hurricane Electric BOGON naughty list provided above.

If your provider or upstream providers aren’t on the list, then it’s likely that they’re adopting best practices and are blocking BOGONs at their perimeter. If they’re doing this, then the likelihood is much lower than you’ll outright have to put an ACL on your perimeter routers or firewalls to do this yourself. Their stance on BOGONs should be in their Terms of Service – always check this to ensure that you know what you’re signing off of.

If the provider you’re considering is on the naughty list, this can reveal a couple of things. First off, they may not be following a number of industry-standard best practices if they aren’t adhering to something as simple as blocking BOGONs at their border. Second, they may believe that they don’t have the budget or equipment performance to support something like blocking BOGONs.

Completely random side comment, but it aggravates the living hell out of me when I tour datacenters in the year 2020 and see providers still using Cisco Catalyst 6500-series switches for core production network functions, or running (God-forbid) Catalyst 2950 or 3550 switches for absolutely anything besides out-of-band support for dev environments. If you ever have the misfortune to witness these “in the wild” for yourself, politely end the tour and leave – companies showcasing dinosaur-old hardware like this are rife with other, more deep-seated problems that will bite you hard should you ignore them.

​Third, and most concerningly, they may not have a stance on BOGON because they either don’t believe they’re a problem or because they have sources of them inside their environment and don’t want to do anything about it.

BOGONs tend to sit right alongside ‘pricing’ and ‘availability’ as my core reasons for always giving my Internet bandwidth business to Cogent Communications and Hurricane Electric. Their stance on them, as well as their continued resolve on other ethical fronts (such as the Net Neutrality debate) has placed them in the forefront of my mind in terms of big bandwidth here in the U.S.

Alright. Sales pitch aside, let’s suppose you’re stuck in a crappy situation where you’re forced to deal with an ISP that’s on the naughty list for BOGONs. What do you do?

​Using the countryipblocks.net Cisco ACL list referenced earlier in the article, you can always get a readily-available current list of BOGONs to block at your perimeter. While this can’t prevent BOGONs from consuming your bandwidth, you can at least stop them from doing any additional harm. This list could also be presented to your ISP on a quarterly basis as a request to have it added to your uplink interface ACL on their equipment (if they’re willing to do it for free, that is – if there’s a cost tied to doing this, balance that cost versus the risk and real-world impact that you see).

Because BOGONs are ultimately a form of DDoS, it may be helpful to mask as much of your public-facing network behind cloud-based proxy services that protect against DDoS. Putting websites and DNS behind cloud proxies can be a useful way to spend a few dollars each month, while putting email servers behind spam and DLP-based filtering is practically a necessity in today’s world. While it can’t hide your IP addresses from being reached directly, it can cut down on the aspect of them that’s in the public limelight.

Summary

BOGONs occupy a strange little corner of the Internet due to the nature of what they are, what they can be used for, and how dependent you are on your connectivity partners implementing best practices and “fair play” rules to keep them out of your field of view.

When in doubt, block them at your perimeter. Set a quarterly (or even monthly, if your environment is pretty large) point to review updates to the master BOGON listing, and adjust ACLs as needed.

​When possible, prefer Internet providers that have a very clear-cut stance on BOGONs and preventing them from flooding their network.

And, feel free to drop the term ‘BOGONs’ in a few company meetings to elicit a minor scare out of senior management in thinking that there’s a new player in the threat landscape that they don’t know about yet. The term “BOGON” does sound kinda scary, after all.

Like a toxic virus, a buzzword for a set of negative conditions, or an inside nickname for that guy in accounting who’s always putting too much food in the company fridge. You know the one.

Caleb
Caleb Huggenberger is a 31 year-old systems engineer, old-school guitar and amplifier builder, and Eastern culture enthusiast. Outside of long work days, he enjoys electronics engineering, cast iron campfire cooking, and homesteading on his acreage in the Indiana countryside.

Leave A Comment (please keep things clean & civil)

Your email address will not be published. Required fields are marked *