Prevent BGP Hijacking: 3 Technical Controls That Actually Work
Route origin validation stops most hijacks by rejecting false announcements, while RPKI adds cryptographic proof of ownership to your network prefixes.
Register your prefixes in RIR databases and create RPKI ROAs to cryptographically sign your origin AS. Enable Route Origin Validation on your border routers to drop invalid announcements. Monitor your routing table with external tools to detect leaks before they cause outages.
Why BGP Security Fails by Default
Border Gateway Protocol (BGP) was designed for connectivity, not security. The protocol assumes that network operators will be honest and will not announce IP prefixes they do not own. This trust model works for routing packets but fails against malicious actors who want to intercept traffic. When a hijacker announces a prefix that belongs to you, routers around the world update their tables to send that traffic to the hijacker. You lose control of your traffic without any authentication step. The protocol itself has no built-in mechanism to verify who is allowed to announce a given block of addresses.
Register Prefixes in RIR Databases
The first step in preventing hijacking is ensuring your ownership of IP addresses is recorded correctly. You must register your prefixes with your Regional Internet Registry (RIR). This includes ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC. If your registration is incomplete or outdated, you cannot create the cryptographic proofs needed later. Accurate registration establishes the baseline truth about who owns which addresses. Without this record, no technical control can distinguish a legitimate announcement from a fraudulent one. This administrative step is the foundation for all subsequent technical measures.
Create RPKI ROAs for Your Prefixes
Resource Public Key Infrastructure (RPKI) allows you to sign your prefix announcements. You create a Route Origin Authorization (ROA) that specifies which Autonomous System (AS) is allowed to originate which prefixes. This digital signature acts as a certificate for your network identity. Other networks can verify this signature to ensure that an announcement comes from the authorized owner. Creating ROAs is free and takes minutes. It does not require changes to your routing hardware. This step shifts the security model from trust to verification. It is the most effective single action you can take.
Enable Route Origin Validation on Routers
Creating ROAs is useless if other networks do not check them. You must enable Route Origin Validation (ROV) on your border routers. ROV checks incoming BGP announcements against the RPKI database. If an announcement does not match a valid ROA, the router rejects it. This prevents your network from accepting and propagating hijacked routes. Most modern router operating systems support ROV. Configuration varies by vendor, but the concept is standard. You should enable ROV on all edge routers that peer with other networks. This stops invalid traffic from entering your infrastructure.
| Measure | Effort | What it stops |
|---|---|---|
| RIR Registration | Low | Administrative disputes and lack of proof of ownership |
| RPKI ROA Creation | Low | Unauthorized origin announcements from other ASes |
| ROV Enablement | Medium | Acceptance and propagation of invalid routes |
| Monitoring Setup | Medium | Late detection of route leaks and hijacks |
Monitor Your Routing Table Externally
Your own routers cannot see what the rest of the internet thinks. You need external monitoring to detect hijacks in real-time. Services like BGPStream, RIPE RIS, or private monitoring platforms aggregate data from thousands of looking glasses. They alert you when someone announces your prefixes from an unexpected AS. This detection happens before your customers report issues. Internal logs only show what your router sees. External monitoring shows the global view. This is critical for identifying route leaks that ROV cannot stop. It provides the situational awareness needed to respond quickly.
Respond to Detected Hijacks
When monitoring alerts you to a hijack, you must act fast. First, verify that the announcement is indeed unauthorized. Check the RPKI status and the originating AS. If it is a hijack, contact your upstream providers to filter the route. Ask them to drop announcements from the offending AS for your prefixes. This manual filtering is slower than ROV but necessary for leaks or unvalidated hijacks. Document the incident and the steps taken. Use this data to refine your monitoring rules. Rapid response minimizes the duration of traffic interception. It limits the damage to your reputation and service availability.
What Does Not Work for Prevention
Relying solely on bilateral filtering is insufficient. Bilateral filtering involves manually configuring your router to accept only the prefixes you agreed to with a specific neighbor. This works if you have perfect information about every neighbor. In practice, the internet is too complex and dynamic. New peers appear, and agreements change. Manual filters become outdated quickly. They do not scale. They also do not protect against route leaks from upstream providers. You cannot filter traffic you do not see coming from your direct peers. This method creates a false sense of security. It requires constant maintenance and still leaves gaps.
Checklist for Today
Use this checklist to prioritize your actions. Focus on the items that remove the most risk with the least effort.
- Verify your prefix registrations in your RIR database are current and accurate.
- Create RPKI ROAs for all your active prefixes with the correct AS number.
- Enable Route Origin Validation on your border routers to drop invalid announcements.
Key takeaways
- RPKI ROAs provide cryptographic proof that only you can announce specific IP prefixes from your autonomous system.
- Route Origin Validation filters drop announcements that do not match signed records, blocking most hijack attempts automatically.
- External monitoring tools detect route leaks and hijacks faster than internal logs, allowing you to react before customers notice.
BGP hijacking prevention relies on cryptographic verification through RPKI and ROV, not on trust or manual filtering. Start by creating ROAs for your prefixes and enabling validation on your routers today.
Frequently asked questions
Does RPKI protect against all types of BGP attacks?
No, RPKI only validates the origin of prefixes. It does not prevent route leaks, prefix hijacking via sub-prefixes, or AS path manipulation. You need additional monitoring and filtering for those threats.
How long does it take for RPKI to propagate?
RPKI data propagates quickly, usually within minutes. Most routers cache RPKI data for efficiency. Changes to ROAs are visible to validators almost immediately, allowing for rapid response to configuration errors or attacks.
Can I use RPKI if I have multiple upstream providers?
Yes, RPKI is independent of your upstream providers. You create ROAs in your RIR portal. Your providers enable ROV on their end. You do not need their permission to create ROAs, but you need them to enable validation.
What is the difference between a hijack and a leak?
A hijack is an intentional attempt to steal traffic by announcing prefixes you own. A leak is an accidental or misconfigured announcement of your prefixes by a neighbor. Hijacks are malicious; leaks are often errors. Both require different mitigation strategies.
How this guide was produced: written by the Sandbox Desk editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
