BGP Hijacking Prevention: A Layered Defense Guide

By Savvas Bout, Founder of Prefixx. Last updated 7 October 2026.

BGP hijacking happens in seconds and most network operations teams discover the damage that has happened in the mean time. BGP hijacking prevention is not a simple setting to switch on. Defending against BGP hijacks is a complex discipline requiring several validation methods, including route origin validation, accurate IRR data, and RPKI (Resource Public Key Infrastructure) validation.

Additionally, Active monitoring that can trigger alerts before a prefix is withdrawn from the router's routing table. A single misconfigured upstream network, a malicious announcement of a part of your IP space. Alternatively, A simple mistake by a peer can pull all your prefixes out of a router's forwarding table regardless of how good the original assignment of IP addresses to your organization was.

This article walks through the full prevention stack against route hijacking, detailing RPKI ROAs and origin validation in practice, and why IRR route objects remain relevant even after RPKI has been implemented.

Preventing hijacking begins with the controls a provider places on a block of address space before it is leased or sold to customers. We examine how a hijack occurs and then go through the full prevention stack, layer by layer.

What is IP hijacking and why it threatens your IP address space

BGP hijacking is the malicious announcement of IP space by intercepting Internet routing. The announcement of prefixes that are not owned by the announcing router can redirect traffic intended for another to an alternative destination, potentially intercepting it. Alternatively, Causing it to be unable to reach its destination at all.

How border gateway protocol BGP connects the internet

The Border Gateway protocol (BGP) connects autonomous systems, i.e. the networks operated independently by Internet Service Providers (ISPs), cloud providers and enterprises. Each network announces all the IP prefixes for which it is responsible. These advertisements are then stored by other networks in a forwarding database. On the basis of this database, a network decides where to send packets. For more context, see BGP hijacking.

The design is trust-based.

What happens during a hijack

BGP announcements of unowned prefixes cause neighboring networks to update their forwarding information bases based on the new information. Subsequent Internet traffic directed to the “owner” of the prefix is redirected by forwarding information bases that were updated based on the announcement. This type of attack has been referred to as prefix hijacking, route hijacking, or IP hijacking, depending on the intent and scope.

This actually happened in 2008 when a Pakistani ISP accidentally announced a more specific prefix for a large video sharing website, rerouting internet traffic so that the website became unavailable worldwide for a short time.

Prefix hijacking route versus route leak

These two incidents are related but distinct:

• BGP hijack: a network announces prefixes it has no right to hold, usually with malicious or fraudulent intent.
• Route leak: a network re-advertises routes it received from one peer to another peer, violating policy but not necessarily claiming ownership.

While stealing IP addresses corrupts the global route table, hijacking IP addresses corrupts the legitimacy of an IP block. Preventing these corruptions requires active monitoring and methods to ensure their authenticity using cryptography. The next section will explore in detail how an attacker’s actions cause these corruptions to occur.

How a BGP hijack actually happens: attack mechanics step by step

BGP hijacking attacks exploit a basic trust in the way Internet routing is managed today: people assume that an AS announcing a route to them actually owns that route. When they don’t, detecting and preventing such hijacking is critical.

How a BGP router propagates routes

Each router on the global internet share reachability information with their immediate neighbors. The network operator of a block of IP addresses announces their ownership to their neighboring BGP routers. These routers in turn advertise the newly announced information to their outlying neighbors, and before long the entire global IP forwarding table is advised of the new block of IP addresses recently announced by the network operator for that block.

No proof of ownership of the announced block is required. The propagation of BGP advertisements across the internet relies entirely on trust, with no cryptographic verification of the announcing party's right to the prefix.

More-specific prefixes win

BGP prefers the longest match. So a /25 is better than a /24 for any destination within the range of the /25. Therefore an attacker could execute BGP hijacks by announcing a more specific sub-prefix of a range he has no announcements for, pulling traffic intended for the legitimate holder off onto himself. This is the most effective form of prefix hijacking: the original /24 announcement is still valid, but half the IP addresses in the range are routing elsewhere.

Complete vs. Partial hijacks

A misconfigured BGP route can cause a BGP hijack, whether accidental or intentional, to be indistinguishable from the other in operation. A fat-finger route leak can spread globally within minutes and be fixed only after it has been discovered. Validation of RPKI ROA’s are the primary means to prevent such hijacks at their source. This is where the prevention stack starts.

RPKI: the strongest technical defense against prefix hijacking route attacks

RPKI is the primary security mechanism to mitigate BGP hijacks. It allows a resource holder to sign a statement about valid announcements of a prefix by specifying the allowed ASN(s). Enforcement of Route Origin Validation by routers discards announcements that do not verify against such signed statements. Each routing policy statement encoded in a ROA binds a prefix to one or more origin ASNs, establishing the foundation for automated validation.

Create your ROA

1. Go to your RIR portal and look up the prefix you hold. In the RPKI section create a new Route Origin Authorization (ROA) for this prefix. A ROA consists of an IP prefix, an origin ASN and a maximum prefix length. The ROA is signed with a key that your RIR issues to you.
2. Remember to set the max-length carefully. If you’re announcing a /24 out of a /22, set max-length to /24. Otherwise you risk your ROA marking out more-specific announcements as ‘invalid’ when in fact they are totally legitimate.

Note: Creating a ROA does not protect you by itself. Protection only kicks in when the routers receiving your announcements actually perform Route Origin Validation and drop invalid routes.

Confirm upstream enforcement

1. Can your transit provider guarantee ROV enforcement? Most networks today do not announce RPKI-invalid routes, but many transit providers still announce them and do not drop them. Announcements of an hijacker’s invalid RPKI-announcement are usually propagated across the BGP-mesh border.
2. You can verify your ROA status by using a ROA validator like RIPEstat. Verify that your prefix is listed as RPKI-valid from multiple locations before you start relying on it for this sort of defense.

Where Prefixx fits in

When you lease IP range or bring your own block to Netrouting bare metal through our BYOIP service, our team prepares the RPKI ROA, IRR route objects, and LOA on your behalf. You get a correctly signed, immediately valid ROA without navigating each RIR's portal yourself.

Note: RPKI covers origin validation only. It does not prevent path manipulation or attacks from networks that ignore ROV. Treat it as a necessary layer, not a complete BGP security solution. IRR filtering adds the complementary controls that RPKI alone cannot provide.

BGP monitoring: detecting hijacks in real time before damage spreads

BGP lacks any form of intrinsic authentication. Hence any autonomous system can freely announce an IP prefix which it does not own. As a result, verification of announced IP prefixes through real-time monitoring of the routing information base (RIB) constitutes the main detection layer currently utilized by most network operators. The lack of built-in trust mechanisms between autonomous systems means that operators must rely on external validation frameworks and continuous observation to verify the legitimacy of prefix announcements.

What monitoring tools watch for

Global BGP table views are aggregated by the route collectors continuously. Monitoring systems compare newly announced routes against the expected states and report changes immediately.

• Unexpected origin ASN on a prefix you own.
• More-specific announcements covering a sub-range of your block.
• RPKI validity changed from Valid to Unknown or Invalid.
• This includes IRR inconsistencies between registered route objects and actual announcements.
• Upstream visibility changes (e.g. a prefix no longer visible to peers).

How ripestat and route collectors detect route hijacking

RIPEstat uses information from the Routing Information Service operated by the RIPE NCC, which receives full BGP feeds from hundreds of collector peers from all over the world. This global view of internet routing information is used by the monitoring system to detect a BGP hijack that only announces to a part of the world (i.e. is regional).

BGP router monitoring in the Prefixx portal

We monitor BGP via the client portal with RIPEstat and RIS data, checking origin ASN, RPKI validity, IRR consistency, and routing policy alignment across the upstream view for all leased or transferred IP address spaces. If a check fails, this will be presented on the portal and we can then take action. We do not tie SLA figures to these checks, but rather use the latest routing information (not cached snapshots).

After an anomaly has occurred, monitoring will catch it.

BGP hijacking prevention for BYOIP deployments on cloud and bare metal

BYOIP deployments of your routing space to cloud or bare metal move routing control for that space to the new platform. Absence of ROAs and IRR route objects announcing the space before the announcement of BYOIP creates an opportunity for BGP hijacking.

Preparation for your address space

1. Create your RPKI ROA before you start announcing any routes. The Route Origin Authorization (ROA) for a prefix ties that prefix to an authorized origin Autonomous System (AS). Subsequent announcements of that prefix from an unauthorized AS will be marked invalid by most service providers and dropped.
2. Create an IRR route object. IRR filters can catch hijacks not caught by RPKI. Create a route object in your RIR’s registry before advertising the BGP route.
3. Get signed LOA from your address holder. Cloud providers and bare-metal providers need proof of ownership of the IP address range you want to bring. Without valid LOA, your BYOIP request will get rejected at the platform level.

Execution

1. Submit LOA and prefix details to your platform. Each of the cloud providers listed (AWS, GCP, Azure, OCI, and Cloudflare) have their own workflow for verifying BYOIP. Each must verify ownership of the announced IP prefixes independently before allowing them to be announced.
2. Verify the Origin ASN for your bare metal BYOIP on your provider. Bare-metal BYOIP allows for a direct BGP session as opposed to cloud environments where BGP is managed for you by your provider. Confirm that only your authorized ASN is originating your prefix.

Note: Announcing a prefix before your ROA is published is one of the most common mistakes in BYOIP deployments. The window between announcement and ROA creation is exactly when a hijack can go undetected.

Verification

1. Verify the status of RPKI validation for your prefix using a routing looking glass. Validation status should be reported as RPKI-Valid from multiple locations. An entry of RPKI-Invalid or RPKI-Not-Found indicates that your ROA is missing or misconfigured.
2. Monitor unexpected origin changes after go-live with BGP route monitoring for announcements. BGP monitoring for BGP routes is included in the client portal of Prefixx. The data is based on RIPEstat. We check origin ASN, RPKI validity and IRR consistency.

Prefixx prepares the LOA, RPKI ROA, and IRR route objects as part of every BYOIP deployment. On Netrouting bare metal, BYOIP is natively included with no per-IP surcharge. Learn more at Prefixx.net/BYOIP.

Even with all necessary documents in place, BGP itself has inherent limitations.

BGP advertisements and the honest state of BGP security in 2025

BGP was designed under the assumption of trust rather than security verification.

Where RPKI stands today

The rate of RPKI adoption has increased significantly in recent times. Route Origin Authorizations (ROAs) allow the cryptic binding of prefixes to AS Numbers of the originating router. There is however a large gap in enforcement of this invalid configuration data. Most transit networks do not announce invalid Route Origin-Attributes (ROAs) to their customers, meaning that a single signed ROA only helps prevent BGP hijacks where upstream networks actually perform Route Origin Validation.

BGPsec, the path-signing extension for BGP for BGP security, as specified in RFC 8205, would address this problem.

What you can and cannot control

Remote operators can misconfigure their routers regardless. All you can do on your side of the network is to publish correct ROAs, keep your IRR route objects clean, perform prefix length filtering. Additionally, Monitor your routing information for changes of the origin that you did not intentionaly introduce.

BGP security is a multi-faceted approach, not just a single feature to turn on. RPKI ensures origin is valid. IRR filters check path is correct. Monitoring enables you to detect unusual activity in real time. No single one is enough.

Practical defense posture

A realistic approach to IP defense is a ‘defense in depth’ approach. Publish ROAs for all prefixes that you advertise. Keep your IRR objects up to date. Monitor BGP visibility and RPKI validity on a continuous basis. When using a broker like Prefixx, Tixx quality control checks the routing hygiene and the IP addresses on blacklists before any block is put into place, so you start from a clean position and don’t inherit any BGP related issues of the broker.

While it is not possible to prevent all hijacks initiated from outside the Internet, it is possible to make your own prefixes harder to hijack and to detect such anomalies very fast to be able to react in time.

The following questions get at some of the nuances and challenges that arise when practitioners try to implement this kind of defense posture.

Frequently asked questions

Does BGP routing policy remain relevant today despite autonomous system route hijacking risks?

Every autonomous system on the planet exchanges reachability information through it, and there is no credible replacement on the horizon.

How does routing policy affect BGP routers connecting autonomous systems in cybersecurity?

That makes BGP the vector for hijacking attacks, traffic interception, and large-scale outages.

How does BGP routing policy in advertisements help prevent loops?

In iBGP, the split-horizon rule prevents a route learned from one internal peer from being passed to another.

In eBGP, routers check the AS_PATH attribute and discard any update that already contains their own ASN.

Are BGP advertisements secure yet?

Not fully.

The honest answer is that BGP is more secure than it was five years ago, and still not secure enough.

What is the difference between a BGP hijack and a route leak?

A BGP hijack is when an AS announces a prefix it has no authority to originate, either to steal traffic or to cause an outage. A route leak is when a legitimate route is re-advertised beyond its intended scope, for example, a customer announcing a transit provider's routes to another transit provider. Hijacks are usually deliberate; route leaks are usually accidental. Both can cause widespread traffic disruption, but the remediation and legal implications differ significantly.

Does RPKI fully prevent BGP hijacking?

It does not protect against path manipulation, where an attacker inserts false AS hops into a valid-origin announcement.

How does BYOIP relate to BGP hijacking risk?

If the ROA, IRR route objects, and LOA are not set up correctly before the announcement goes live, your prefix can appear to autonomous systems across the global prefix table as an unauthorized origin, indistinguishable from a hijack.

Getting RPKI ROAs, IRR objects, and the LOA aligned before any advertisement is the critical step.

IRR filtering at your upstreams and monitoring BGP routes for unexpected origin changes make for a solid set of layers to detect both automated and manual route leaks before they cause any damage.

The weakest part of technology implementation for most organizations is paper work. Missing, stale or misconfigured ROAs, IRR objects that do not accurately reflect announced routes, these are typical weak points in organizations’ networks. In fact, if a given block of IP addresses was transferred or leased and the related border gateway protocol BGP routing objects were not updated properly, a weakness in your network configuration will be exposed regardless of the content of your router configuration files.

Prefixx prepares LOAs, RPKI ROAs and IRR route objects on your behalf as part of every transaction. If you want your prefix records audited and corrected, contact the Prefixx team and we will run a Tixx health check on your block first.