IP Hijacking, part 2

Introduction

In part onewe looked at some reasons for and effects of an IP hijack. In this part we’llfocus 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 iton a daily basis. If your internet connectivity stops working, you knowsomething is wrong. However, lacking specificity, this service failure could bea number of things besides a hijack.

Taking a look at your own BGP announcement locally only allows you to verifythe announcement to your provider is correct and that BGP is functioningcorrectly. In order to understand how the rest of the Internet sees yourannouncement you need a public route server orlooking glass. A looking glass will giveyou a better idea of how everyone else sees your IP blocks. The limitations ofa single looking glass include its visibility horizon (who it is peered with)and that it does not provide historical routing data unless you aggregate ityourself.

An aggregation tool like RIPEstat gives you a timelineof events for routing announcements regarding your IP block. These tools utilizemany sources of BGP data, as well as allow a more detailed look at various nooksand crannies of the Internet that may be more susceptible to split horizon IPhijack 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-timemonitoring 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 spammerand find its way on to a blacklist. Unless you actively poll BLs for your IPblock, upon putting it into production you won’t be able to effectively sourcemail from the whole block.

Protect

The best defense is a better defense. Tautological cliches aside, there isusually 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 andcreating an audit process for the future. The alternative is eschewing risk tothe possible detriment of your organization.

Internal

Do you have internal knowledge, processes and visibility to allow healthy levelsof protection, mitigation and recovery of hijacked IP blocks?

• Multiple people with knowledge of how your IP blocks are originated, used andprotected.
• An internal documentation store that is accessible to the above people, aswell as others on a need-to-know basis. Since we’re discussing possible networkreachability issues, keeping local and encrypted copies of this documentationfor each person is a good idea.
• Also important is ensuring these folks can respond to an IP hijack. VOIP linesmay be down and email unusable, so out-of-bandcommunication may be the only way to contact a provider’s support group.
• A live monitoring system capable of alerting staff to waylaid IP blocks orother resources. This is where Farsight can help out, we’ll cover theparticulars 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 aregional/national registry or an assignment from an LIR/upstream provider.The records-keeping for assigned blocks is done at your providers’ behest viaSWIP. In general, most ofthis information was well maintained while ipv4 resources were still beingallocated by the regional registries. Keeping decent records was the only way toget additional direct allocations. However, since v4 address space is noweffectively exhausted, not swipping a new IP block assignment carries less of apenalty that it did before. This is just as true of smaller providers who mayhandle the swip process by hand as it is of large providers that may use anautomated swip process that is prone to failure.

It is vitally important to make sure that your IP block assignments are swippedcorrectly by whoever provided them to you. This information is visible to therest of the Internet and is a great place to reduce hijack risk. It is likeleaving the lights on at home when you leave for the weekend: thieves wouldrather have a softer target. Furthermore, the record can be part of your org’smonitoring schema and may be used as part of ownership verification during anyhijack recovery attempts.

Internet Routing Registry

A growing number of providers require that you use an Internet Routing Registryto create a basic set of objects that they and the rest of the Internet can useto passively verify your routing announcement. The fact that this is not arequirement for anyone using public BGP on the Internet is one of the reasons wehave IP hijacks to worry about in the first place. All important and most largeorganizations use the IRR system in coordination with their own routingobservations to ensure greater integrity of the public BGP routing table. Theremay still be non-malicious route hijacks from farther down the routing foodchain, but these lapses are smaller in scope and less harmful because of theprecautions taken at the top. This system was put in place a couple decades agoas a direct result of multiple accidental routing blunders that rerouted largeportions of the Internet.

Taking the time to register a mntner, aut-num and requisite route objectswith ARIN’s IRR, even if your provider may not require it, allows other publicBGP speakers who do use the IRR system to squelch malicious IP hijack attemptsand routing errors alike.

Resource Public Key Infrastructure

This is the last best piece of the IP hijack mitigation puzzle. Much like DNSSECis for the DNS, RPKI is for the IRR. It creates a trust mesh from the root thatallows validation of resource use that is much more difficult to exploit thanprevious methods. Current deployment of RPKI is small but slowly growing.Participants in the RPKI provide a level of integrity for routingannouncements that is not available in the IRR.

There are downsides to RPKI though, such as lengthened convergence times, spottyvendor support, as well as the regular slate of PKI issues

Recover

So the unthinkable has happened, your IP block was hijacked, time to instituteyour disaster recovery plan. You had one, right? If not, the list may includea number of items such as the following:

1. Ensure it is actually a hijack, and determine if it is still ongoing.
2. Take measures to regain immediate control, like announcing least specificblocks.
3. Determine the upstream source of the hijack announcement and start bycontacting NOCs or network engineering groups at the closest point tothe hijack, working your way backward to your own AS.
4. If you get limited response from intermediary networks, engage with therouting community via a regional network operators group like NANOG).Nothing beats hearing a familiar voice on the other end of the line when thingshit the fan.
5. Monitor the hijacked IP space: determine if and how it is being abused. Someattackers just want to send spam, others might attempt to MITM and capturepasswords or sensitive data. Knowing what the attack attempted or accomplishedwill assist in subsequent analysis.
6. 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’ IPblocks 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 blockhijack mitigation, monitoring and how recovery may work. In the next articlewe’ll discuss specific methods for utilizing Farsight’s products to assist inthis effort.

Dave Hauser is a Senior Network Engineer and Ben April is the Director of Engineering for Farsight Security, Inc.