In 2000, a document called BCP38 was released by the Internet Engineering Task Force (IETF). In it was a potential solution for mitigating spoofed DDoS attacks (later solved, at least in part, by severely limiting the TCP/IP stack in Windows XP SP2), which were, at the time, a prevalent threat on the Internet. The initial adoption of BCP38 was slowed due to the constraints and expense of hardware at the time. However, fast forward 14 years, and we’ve learned that BCP38 not only solves spoofed DDoS, but many other problems. By utilizing BCP38 and a few other tricks, such as ingress and egress filtering, you can bring sanity to the data coming into, and out of, your network.
Ingress Filtering
Ingress filtering is the easiest concept to understand. When most network administrators hear the word “firewall”, their mind is first drawn to ingress filtering, or simply keeping the evil packets away from “delicate” servers. Ingress filtering should ideally be done at the edge of your network, and serves to prevent traffic from coming in from questionable sources. Of course, the first and easiest method of ingress filtering is a Bogon List, but we will discuss that later. First, we want to highlight how Zenoss can alert you to Martians -- Martian packets, that is!
Monitoring for Martian Packets
Among the most evil alien packets are Martians. These are often caused by a mis-configuration of one of your provider’s networks. Martian packets come from RFC-1918 addresses, auto-configuration addresses, and other sources, such as reserved blocks that should not be routed on the public Internet.
This list has been fairly static for a long period of time, and these blocks of IP addresses should be filtered at both the edge of your network as well as anywhere else on your network where these packets should not pass.
Generating events on your routers for Martian packets with Zenoss is a quick easy way to detect leakage, or mis-configuration on your network, and a potential security problem before it becomes an incident.
Using Bogon Lists
As suggested earlier, the easiest method of ingress filtering is a Bogon list.
Bogons are IP addresses that are not announced to the internet, and it is safe to assume that any packets coming in from a Bogon source is spoofed. If you use an internal Bogon List, make sure you subscribe to the North American Network Operators’ Group (NANOG) mailing list, or your regional network operations group to receive updates from the Regional Internet Registries (RIRs) on the current list of Bogon sources.
Otherwise, utilize a resource like Team Cymru’s Bogon Route Server Project, which provides a Border Gateway Protocol feed of both IPv4 and IPv6 Bogon Addresses. (You did deploy IPv6, right?! For more information, see IPv6 -- The Sky Really Is Falling!).
Egress Filtering
Egress filtering is the monitoring and potential restriction of the flow of information outbound from one network to another. Wait, you want to do what? Are we going off the rails here? No! A solid egress filtering strategy can protect your network, your budget, and the services you deliver.
Simple Multi-Homed Egress Filtering
If you are just multi-homed, egress filtering is easy. Only allow packets to egress from your edge from blocks of IP addresses you have been assigned from your Regional Internet Registry (Such as RIPE or ARIN). This will prevent a scenario where an uplink’s BGP failure would cause their traffic to route through your network, crushing your 95% on your backup link, and likely resulting in a DoS condition.
Zenoss makes this easy. Simply set thresholds for your interfaces that match the metering in your ISP contract. You can even use graph definitions and thresholds to have RRD generate a 95% graph and alert you if your 95% traffic rate gets too high.
Per-Peer Routing Policies
Networks larger than those that are simply multi-homed are a bit more complex, and require per-peer routing policies for each peer. Per-peer routing policies take into account your network geography, topography, and offloading packets to someone else as close to the source on your network as possible. (For example, you don’t want to route a packet from DC to New York internally to hand off to a provider if you are peered with them in Baltimore.)
Your per-peer routing policies should also take into account your billing and contractual agreements. For instance, primary (or equal peer) links need priority over backup links, and ASNs you peer with for whom you carry traffic need to be permitted to do so.
With complex situations like these, Zenoss can help by using Predictive Thresholds, which trigger if an interface or link suddenly has much more traffic on it than it should. (For more information about Predictive Thresholds and the Predictive Thresholding ZenPack, see “Is Your Performance “Normal”? How Do You Know?“.)
Furthermore, simple latency testing with the Fping ZenPack can also indicate trouble caused by route policy filters that break, or that saturate a link resulting in degraded performance.
Next Steps
Raising your shield and monitoring for possible cracks in that shield on the network edge should be part of protecting your network. After 14 years, it’s finally time to pay attention BCP38 and strengthen the network shield.
