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:
- Palo Alto Networks https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/policy/use-an-external-dynamic-list-in-policy/built-in-edls.html
- Fortinet (Note: This isn't built in, but is supported): https://fusecommunity.fortinet.com/blogs/yuri1/2020/07/26/using-external-threat-feeds-in-fortigate
- Checkpoint (Note: This is mostly built-in, and the threat feeds are provided by checkpoint): https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk103154
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:
/* https://github.com/lonekorean/gist-syntax-themes */ @import url('https://cdn.rawgit.com/lonekorean/gist-syntax-themes/d49b91b3/stylesheets/idle-fingers.css'); @import url('https://fonts.googleapis.com/css?family=Open+Sans'); body { font: 16px 'Open Sans', sans-serif; } body .gist .gist-file { border-color: #555 #555 #444 } body .gist .gist-data { border-color: #555 } body .gist .gist-meta { color: #ffffff; background: #373737; } body .gist .gist-meta a { color: #ffffff }
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.
Top comments (0)