Gnome Meeting

How Route Analytics Help Detect BGP Route Hijacking

Previously, I have talked about BGP route hijacking as a security threat and various techniques being developed to secure it. In this blog entry, I will talk about how route analytics technology can help detect BGP route hijacking in the meantime.

There are two instances of route hijacking that need detecting. The first is when one of your prefixes is being hijacked; that is, someone is redirecting your traffic elsewhere and you are the victim. The second is when someone passes you a hijacked route; that is, you are being used as an instrument to hijack someone else. Route Analytics can help with both of these cases. However, the data sources that are needed for the analysis are different.

When your routes are being hijacked, you cannot look at the data that is in your BGP routers in the majority of the cases. Because of the way BGP AS_path attribute works, these routes will contain your AS number and therefore, BGP will not pass them back to your routers in order to avoid loops. However, if you have access to external BGP sessions or to the BGP data typically found in the Route Views or RIPE/RIS projects, it is possible to monitor your own routes and be alerted when suspicious deviations are found.

You can, however, detect when you are being passed hijacked routes using the data from your routers. Here are some techniques you can use to detect BGP anomalies using Route Analytics.

The first technique that helps detect malicious announcements is BGP route baselining. BGP route baselining tracks what routes are typically received and detects when these routes are missing, or new non-baselined routes pop up. It is possible to baseline BGP routes with respect to their origin AS, the neighbor AS, the BGP next hop router, the border router as well as various BGP route targets (Route Explorer baselines BGP routes with respect to the border routers and BGP route targets).

For example, for prefix P, if the baselined neighbor AS is X but now it is being announced by neighbor Y, P is potentially being hijacked. This can be easily detected (and alerted on) as shown in the picture below. However, determining if P is being hijacked still requires human intervention, as it is also possible that the AS that originated P has changed service providers and hence the new route is legitimate. That is why the ISOC study that I mentioned in an earlier post has gone to the source and confirmed whether the incidents they detected were malicious or not.

The second technique is BGP route visualization. For a given BGP prefix, or a set of prefixes specified using a filter, BGP route visualization can draw a picture of the route’s traversal across the Internet. This includes the border router in your AS, the next hop router in the next AS, neighbor, transit and origin ASs. It can draw a comparative picture to contrast the picture between two different times; it can animate the changes over this time period.

The picture below shows an incident as observed from AS 11423 (CalREN) where AS 2152 (CSUNet) has leaked full Internet routes to its neighbors. The path in gray/blue is the typical path, and the path in green is when the incident happened. Though this was not a malicious incident, it was very damaging, as the green path did not have sufficient capacity to carry the traffic.

One can also combine these two techniques for an even more powerful technique by visualizing just the “non-baselined” routes. If a non-baselined route is going over an AS that is not a service provider, but rather an enterprise, it is very likely it is being hijacked.

Ultimately, we need a permanent solution and need to secure BGP. Until then, we need to monitor the Internet’s BGP routing and look for anomalies. Route Analytics provides the means for monitoring BGP.

Editorial Staff

Add comment

Follow us

Don't be shy, get in touch. We love meeting interesting people and making new friends.

Most popular

Most discussed