Introduction
In part one we looked at some reasons for and effects of an IP hijack. In this part we’ll focus on prevention, diagnosis, and recovery.
How best to mitigate the risk of a hijack?
“Si vis pacem fac pactum” – If you want peace, make peace.
Monitor
Technically you already have real-time monitoring of any IP block if you use it on a daily basis. If your internet connectivity stops working, you know something is wrong. However, lacking specificity, this service failure could be a number of things besides a hijack.
Taking a look at your own BGP announcement locally only allows you to verify the announcement to your provider is correct and that BGP is functioning correctly. In order to understand how the rest of the Internet sees your announcement you need a public route server or looking glass. A looking glass will give you a better idea of how everyone else sees your IP blocks. The limitations of a single looking glass include its visibility horizon (who it is peered with) and that it does not provide historical routing data unless you aggregate it yourself.
An aggregation tool like RIPEstat gives you a timeline of events for routing announcements regarding your IP block. These tools utilize many sources of BGP data, as well as allow a more detailed look at various nooks and crannies of the Internet that may be more susceptible to split horizon IP hijack attempts.
So a single looking glass is useful for checking your own routing announcement, but some sort of BGP view aggregation is required for useful real-time monitoring and analysis. Another possibility is bgpmon, which can alert you to potential IP hijack attempts quickly.
If you are not actively using an IP block, it may by used by a snowshoe spammer and find its way on to a blacklist. Unless you actively poll BLs for your IP block, upon putting it into production you won’t be able to effectively source mail from the whole block.
Protect
The best defense is a better defense. Tautological cliches aside, there is usually a way to make something better, especially if something is nothing. You can spend a few hours here and there right now shoring up defenses and creating an audit process for the future. The alternative is eschewing risk to the possible detriment of your organization.
Internal
Do you have internal knowledge, processes and visibility to allow healthy levels of protection, mitigation and recovery of hijacked IP blocks?
- Multiple people with knowledge of how your IP blocks are originated, used and protected.
- An internal documentation store that is accessible to the above people, as well as others on a need-to-know basis. Since we’re discussing possible network reachability issues, keeping local and encrypted copies of this documentation for each person is a good idea.
- Also important is ensuring these folks can respond to an IP hijack. VOIP lines may be down and email unusable, so out-of-band communication may be the only way to contact a provider’s support group.
- A live monitoring system capable of alerting staff to waylaid IP blocks or other resources. This is where Farsight can help out, we’ll cover the particulars in the next part of the series.
- Disaster recovery and continuity of operations plans that are up to date.
Provider
Your IP address blocks came from somewhere. Either a direct allocation from a regional/national registry or an assignment from an LIR/upstream provider. The records-keeping for assigned blocks is done at your providers’ behest via SWIP. In general, most of this information was well maintained while ipv4 resources were still being allocated by the regional registries. Keeping decent records was the only way to get additional direct allocations. However, since v4 address space is now effectively exhausted, not swipping a new IP block assignment carries less of a penalty that it did before. This is just as true of smaller providers who may handle the swip process by hand as it is of large providers that may use an automated swip process that is prone to failure.
It is vitally important to make sure that your IP block assignments are swipped correctly by whoever provided them to you. This information is visible to the rest of the Internet and is a great place to reduce hijack risk. It is like leaving the lights on at home when you leave for the weekend: thieves would rather have a softer target. Furthermore, the record can be part of your org’s monitoring schema and may be used as part of ownership verification during any hijack recovery attempts.
Internet Routing Registry
A growing number of providers require that you use an Internet Routing Registry to create a basic set of objects that they and the rest of the Internet can use to passively verify your routing announcement. The fact that this is not a requirement for anyone using public BGP on the Internet is one of the reasons we have IP hijacks to worry about in the first place. All important and most large organizations use the IRR system in coordination with their own routing observations to ensure greater integrity of the public BGP routing table. There may still be non-malicious route hijacks from farther down the routing food chain, but these lapses are smaller in scope and less harmful because of the precautions taken at the top. This system was put in place a couple decades ago as a direct result of multiple accidental routing blunders that rerouted large portions of the Internet.
Taking the time to register a mntner, aut-num and requisite route objects with ARIN’s IRR, even if your provider may not require it, allows other public BGP speakers who do use the IRR system to squelch malicious IP hijack attempts and routing errors alike.
Resource Public Key Infrastructure
This is the last best piece of the IP hijack mitigation puzzle. Much like DNSSEC is for the DNS, RPKI is for the IRR. It creates a trust mesh from the root that allows validation of resource use that is much more difficult to exploit than previous methods. Current deployment of RPKI is small but slowly growing. Participants in the RPKI provide a level of integrity for routing announcements that is not available in the IRR.
There are downsides to RPKI though, such as lengthened convergence times, spotty vendor support, as well as the regular slate of PKI issues
Recover
So the unthinkable has happened, your IP block was hijacked, time to institute your disaster recovery plan. You had one, right? If not, the list may include a number of items such as the following:
- Ensure it is actually a hijack, and determine if it is still ongoing.
- Take measures to regain immediate control, like announcing least specific blocks.
- Determine the upstream source of the hijack announcement and start by contacting NOCs or network engineering groups at the closest point to the hijack, working your way backward to your own AS.
- If you get limited response from intermediary networks, engage with the routing community via a regional network operators group like NANOG). Nothing beats hearing a familiar voice on the other end of the line when things hit the fan.
- Monitor the hijacked IP space: determine if and how it is being abused. Some attackers just want to send spam, others might attempt to MITM and capture passwords or sensitive data. Knowing what the attack attempted or accomplished will assist in subsequent analysis.
- Analyze what happened and what can be improved. Be honest.
What if you find others’ hijacked blocks?
In the course of your routing adventures, you may stumble across others’ IP blocks that have been waylaid, misused, or abused. Please contact them, or, failing that, the RIR that assigned the block.
Conclusion
In this second article of the series, we covered a general layout of IP block hijack mitigation, monitoring and how recovery may work. In the next article we’ll discuss specific methods for utilizing Farsight’s products to assist in this effort.
Dave Hauser is a Senior Network Engineer and Ben April is the Director of Engineering for Farsight Security, Inc.
