BGPWatch: A comprehensive platform for detecting/diagnosing hijacking incidents
BGPWatch — A comprehensive platform for detecting and diagnosing hijacking incidents | APNIC Blog

                            BGPWatch's interactive attacker and victim distribution map.                            
This post was co-authored by Changqing An.



This blog post will introduce BGPWatch, a comprehensive platform that provides a detailed overview of BGP routing and analysis. BGPWatch not only reveals the entire landscape of BGP routing but also showcases incidents associated with route hijacks, identifies both victims and attackers, and presents a range of statistics, including hijack data, routing paths, and various other features.



The primary objective of BGPWatch is to enhance the responsiveness of network operators by offering event severity assessment, automated event warnings, and event replay functionalities. In addition, the platform offers a suite of tools designed to assist network operators in monitoring their networks. This includes a dashboard that presents crucial Autonomous System (AS) information, displays forward, reverse, and bi-directional routing paths, and supports subscription services.



BGP hijack detection algorithm



BGP hijacks can take the form of prefix or path hijacks. In prefix hijacks, the attacker simply announces an IP prefix that belongs to another AS. This triggers a conflict known as Multiple Origin Autonomous System (MOAS). To circumvent MOAS, some attackers announce IP prefixes while tampering with the AS-PATH, known as a path hijack. One important indication of a path hijack is the appearance of unseen links, which are typically introduced by attackers who manipulate the AS-PATH.



The platform employs a hybrid approach, integrating rules and machine learning (ML) techniques, leveraging domain knowledge (such as Route Origin Authorizations (ROAs), Internet Routing Registry (IRR) objects, AS relationships, and so on), combined with real-time BGP route feeds, as shown in Figure 1.



Figure 1 — BGPWatch’s BGP hijack detection algorithm.



Initially, the algorithm extracts domain knowledge and features and obtains ground truth data, used to train the ML classifier. During operation, the platform fetches BGP UPDATE messages from the live BGP feed, extracting MOAS and unseen LINK data, which are subsequently filtered using rules integrated with domain knowledge.



In instances where no rule is available to filter the events, they undergo analysis by a well-trained classifier, producing a prediction value ranging from 0 to 1. This value represents the probability that the event is legitimate. Events surpassing the preset threshold in the prediction value are deemed valid, while those falling below are considered invalid. Legitimate events will be periodically integrated into the training process to enhance the platform’s accuracy.



Hijack event navigation



You can browse, view, and search for hijack events in real-time, as shown in Figure 2.



Figure 2 — Monitoring hijack events in real-time.



The table displays information including the hijack event type, level of harm, attacker and victim AS name, AS number (ASN), and economy, along with additional information including start time, end time, duration, and so on.



Events are categorized as ‘High’, ’Middle‘, or ’Low‘ level based on the number of websites in the hijacked prefix. When the number of websites contained in the hijacked prefix is greater than five, the event is marked as ’High‘ level. When the number of websites contained in the hijacked prefix is greater than one but less than five or the victim AS is a data centre, CDN or a top content provider, the event is marked as ’Middle‘ level. Otherwise, the event is marked as ’Low‘ level.



By clicking the ‘down arrow’ button in the top left corner, you can download the data as a .csv format file.



Comprehending events



For each event, detailed information is available, outlining the reasons why this MOAS is identified as a hijack event (Figure 3).



Figure 3 — Event detail.



In the ’Event Review’ tab, you will find information about the reverse routing path of the victim and attacker of the hijack event in a time-stamped manner. You can use the slider to move into different timestamps to get this information. You can also click on the play button to automatically slide from one time to another for the full event. This is shown in Figure 4.



Figure 4 — Event replay.



In the ‘Comments’ tab, you can write a comment or you can check whether the hijack event is intentional or by mistake, based on the site user comments and voting.



Dashboard



The ‘Dashboard’ displays information specific to the ASN, featuring organization name, economy, ASN, and information regarding IPv4 and IPv6 prefixes originating from the ASN, and its peers. You can search by the ASN, AS name, or the organization name you require information about. All prefixes originating from the AS are depicted in a table, as illustrated in Figure 5.



Figure 5 — All prefixes originating from the AS.



The prefixes are hyperlinked. If you click on them, you will be redirected to the reverse routing path page of that prefix.



Within the ‘IPv4 Peers‘ and ’IPv6 Peers‘ tabs, a connectivity diagram illustrates the BGP neighbors of the selected AS, outlining the crucial neighbors associated with that specific AS, as shown in Figure 6.



Figure 6 — Key neighbors of a specific AS.



Along the line connecting the peers, the number of prefixes that are being received and advertised respectively from and to the providers, peers, and customers are displayed.



Below that, you will find a table that shows all the BGP neighbor ASNs, organization name, economy / region, AS customer cone, relationship with those neighbors, and number of prefixes that the selected AS is importing from or exporting to. The AS neighbors column shows the neighboring ASNs. These are hyperlinked and if you click on any of the ASNs, you will be redirected to the dashboard section of that ASN (Figure 7).



Figure 7 — All neighbors of a specific AS.



Routing



In BGP, the forward routing path is used to determine the optimal route a data packet must take from its source to its destination. The router evaluates various attributes of the different paths, such as the length of the path and the origin of the prefix, to determine the best route. The optimal route is then added to the BGP routing table and used to forward data packets.



The reverse path shows how a data packet is routed from a specific AS to a prefix within your AS.



The routing path page shows the forward routing path to a specific prefix or IP. The system will return paths of all sub-networks and super networks of the input prefixes (destination) from the selected AS (source). This illustrates the fine-grained routing features.



In the routing path, you must select the National Research and Education Network (NREN) as a source from the ‘buttoned list’ above and input an IP prefix or address as a destination; they can be either IPv4 or IPv6. Note, in theory, it is possible to query this information for any AS that has outputted the BGP routing table. This will be added in the future.



Figure 8 — Prefixes sharing the same prefix are grouped.



In the list of prefixes on the left, some networks sharing the same path are grouped together with the same colour, as shown in Figure 8. If you click on any of the same-coloured blocks of prefixes, the forward path for that group will be highlighted. The ‘Prefix Total’ at the top-right corner shows the total number of prefixes that your selected ASN shares with the platform.



The system highlights the path for the first coloured block. If you click on the next coloured prefix block, the routing path to the next coloured block will be highlighted.



Within the reverse routing path section, you can input either an IPv4 or IPv6 prefix and then initiate the search. The system will seek the most suitable match for the entered prefix and provide the optimal topology for reaching that prefix from the external network, as shown in Figure 9.



The legend in the bottom right corner shows the layer of the reverse path with a colour code. You can click on the legends to add or remove the layers to your routing tree.



Figure 9 — Reverse routing path.



If you want to see the reverse routing path of the prefix from a specific AS, you simply click on that AS or input an ASN in the search field. You will be able to see how traffic is coming to your searched prefix as a reverse path.



In the ‘Routing Path’ menu, the ‘Bi-Routing Path’ submenu identifies both forward and reverse routing paths connecting a source and destination IP address or prefix. The input fields for ‘Left IP’ and ‘Right IP’ addresses or prefixes accept entries in either IPv4 or IPv6 format.



Note that due to the huge volume of data, the system selectively retrieves a subset of the complete data available from all routing information-sharing platforms. If the system returns a ‘no data found’ message, it does not necessarily imply the absence of a routing path; it could indicate that the system has not yet processed the corresponding data.



Subscription



Operators can subscribe to ASNs and prefixes they are interested in. The system actively monitors the subscribed ASes and prefixes, promptly notifying operators via email if there are any changes such as prefix modifications, hijacks, AS peer adjustments, or alterations to the AS-PATH. Access to subscriptions requires logging in with authorized credentials.



What’s next?



Now that we have integrated prefix hijack detection capabilities into the platform and created tools to assist network operators in monitoring their networks, our next step is to integrate path hijack detection capabilities and expand detection at the data level.



Having tested the BGPWatch platform across 15 of our 19 partner networks, feedback from network operators has been overwhelmingly positive. However, the platform is being continually improved. We welcome and greatly value your feedback and suggestions. Reach out to us at sec@cgtf.net with any input you may have.



The platform is now accessible to the public. We are looking forward to your comments!



Jilong Wang is a Professor of Computer Science at Tsinghua University.



Changqing An is an Associate Professor at Tsinghua University’s Network Research Center.



This work has been jointly developed by researchers and engineers from 19 economies and funded by the APNIC Foundation and the Chinese government. View APNIC Foundation’s project page or access the technical report directly for more information.

                            
                            
                                                        

                            The views expressed by the authors of this blog are their own
                                and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
                            
                        