On the 26th of April, 2017, a ‘prefix hijacking’ event occurred that affected a number of financial services companies around the world. The impact of the event was such that traffic was in part, diverted and directed to another network that claimed to be the owner of the IPv4 address space.
The nature of the event was such that, depending on ‘distance’ between your network and that of the impacted companies, the ‘newly’ announced network now appeared to be ‘closer’ (or ‘shorter’ in BGP terms) and therefore would be preferred.
In the diagram above, the network operator responsible for Autonomous System (AS) 10 advertises the IPv4 prefix X. From the position of AS20, the ‘distance’ is considered to be an AS Path length of 4, (AS13, AS12, AS11, AS10). In the case of prefix hijacking, the same IPv4 prefix, X, was announced as being located in AS15. Given the proximity of AS20 to AS15 with an AS Path length of 3, traffic that originally flowed from AS20 toward AS10 will now be directed to AS15. However, if you were located in AS11 or AS12, the AS Path length is still shorter towards AS10 than towards AS15 and as a result, traffic will continue to flow towards AS10.
An additional element of the 26th of April event was the announcement of ‘more-specific prefixes’ from the source of the attack, also known as ‘sub-prefix injection’. The BGP protocol’s path selection algorithm prefers ‘more-specific’ prefixes before considering the AS Path length.
In the diagram above both AS10 and AS15 announce the IPv4 prefix X. In addition, AS15 announced the ‘more-specific prefix’, X.1. Since routers in the Internet operate on the premise of ‘longest match’, in such a case, regardless of the AS path length, the path to the more-specific prefix (X.1) will be preferred and traffic from all AS’s other than AS10, destined to addresses in the X.1 address range, will be diverted towards the attacker’s network (AS15).
For the purposes of illustration, let us assume that AS10 announced the IPv4 prefix 18.104.22.168/18. During the attack, AS15 also announced the IPv4 prefix 22.214.171.124/18 and in addition, the IPv4 prefix 126.96.36.199/24. Given the use of ‘longest match’, any traffic destined to an IPv4 address in the range 188.8.131.52-255 would be sent towards AS15, rather than the legitimate origin AS.
While it is possible that the announcement was as a result of an error, the announcement of more-specific prefixes that ‘targeted’ the financial institutions, makes it less likely to have been a mistake.
If network operators follow BGP security best practices, in respect to filtering incoming advertisements and specifically blocking the receipt of their own prefixes, they are typically unaware of a prefix hijack incident taking place until an impacted user contacts them!
In order to be able to detect and mitigate a prefix hijack, network operators need to have an ability to ‘see’ outside of their network perimeter, in order to understand what other networks ‘see’ with respect to the prefixes relating to that AS.
With (at the time of writing), over 660,000 prefixes present in the Internet routing table, looking for erroneous BGP events such as the one described above, is akin to looking for a ‘needle in a haystack’.
In a world where real-time system, such as those used by the financial services industry, are impacted, real-time, or close to real-time detection and reporting system are also required.
In a paper submitted to the upcoming ACM Internet Measurement Conference, we describe how high-frequency Apache Spark batch jobs or Spark streaming applications can be applied to this problem, looking for violations in the IPv4 and v6 prefixes being advertised in BGP, as well as security events such as prefix and sub-prefix hijacking.
The paper shows how techniques and technologies from the Big-data realm can be applied to the Networking space, offering the ability to examine, identify and alert network operators to events that have the potential to be highly disruptive to their customers and services, in near real-time.
To download a copy of the paper, click here.
You can watch a video of the application in action here: