Bogons, and how to leverage public IP feeds with NSX-T

Have you ever wondered what happened to all the privately-addressed traffic coming from any home network?

Well, if it isn’t explicitly blocked by the business, it’s routed, and this is not good. Imagine what data leakage can occur when a user mistypes a destination IP — the traffic goes out to the Service Provider, who will probably drop it somewhere, but it’s inviting wiretapping/hijacking to occur.

RFC 1918 over the internet is part of a larger family of addresses called “bogons”, an industry term to indicate a short list of prefixes that shouldn’t be publicly routed.

Many network attacks traversing the public internet flow from what the industry calls “fullbogons”, or addresses that, while publicly routable, aren’t legitimate. These addresses are obviously block-able, with no legitimate uses.

As it turns out, the industry calls these types of network traffic Internet background noise, and recent IPv4 shortages have pushed some providers (Cloudflare in particular) into implementing on previous fullbogon space and shouldering the noise from an internet-load of mis-configured network devices.

The solution for mitigating both problems is the same: filtering that network traffic. Team Cymru provides public services that list all bogon types for public ingestion, all that needs to be done here is implementation and automation.

Bogon strategies

Given that the bogon list is extremely short, bogons SHOULD be implemented as null routes on perimeter routing. Due care may be required when filtering RFC 1918 in enterprise deployments with this method — Longest Prefix Match (LPM) will ensure that any specifically routed prefix will stay reachable, as long as dynamic routing is present and not automatically summarizing to the RFC 1918 parent. If this is a concern, implement what’s possible today and build a plan for what isn’t later.

Here’s an example of how to implement with VyOS:

protocols { static { route 10.0.0.0/8 { blackhole { } } route 10.66.0.0/16 { blackhole { } } route 100.64.0.0/10 { blackhole { } } route 169.254.0.0/16 { blackhole { } } route 172.16.0.0/12 { blackhole { } } route 192.0.2.0/24 { blackhole { } } route 192.88.99.0/24 { blackhole { } } route 192.168.0.0/16 { blackhole { } } route 198.18.0.0/15 { blackhole { } } route 198.51.100.0/24 { blackhole { } } route 203.0.113.0/24 { blackhole { } } } }

This approach is extremely straightforward and provides almost instant value.

Fullbogon strategies

For smaller enterprises and below (in this case, “smaller enterprise” means unable to support 250k+ prefixes via BGP, so nearly everybody) the most effective path to mitigate fullbogons isn’t routing. Modern policy based firewalls typically have features that can subscribe to a list and perform policy-level packet filtering. The following are examples of firewall platform built-ins that let you just subscribe to a service:

In all of these cases, policies must be configured to enforce on traffic in addition to ingesting the threat feeds.

We can build this on our own, though. Since NSX-T has a policy API, let’s apply it to a manager:

The method I provided here can be applied to any IP list with some minimal customization. There is only really one key drawback to this population method — the 4,000 object limit.

Originally published at https://blog.engyak.co.

--

--

--

I am a network engineer based out of Alaska, pursuing various methods of achieving SRE/NRE

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

AWS CloudTrail Logging Logic Flaw

The 100 Billion Dollar Infosec Question

How to Reduce the Risk of Online Transaction for Small Scale E-Businesses

How to expose a local development server to the Internet

Raze Network Partners With Memeunity

The Journey of a Transaction

옵저버 토큰 (OBSR) 재락업 설정 공지

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nick Schmidt

Nick Schmidt

I am a network engineer based out of Alaska, pursuing various methods of achieving SRE/NRE

More from Medium

My very interesting ten-day vacation

2022 — In Review

HYPOTHETICAL CONTINGENCY CONTRACT ( Schunk, D. H. ,2012, p 113)

vRO SecureString vs EncryptedString