Category Archives: BGP Security

BGP Hijack


BGP – From Route Hijacking to RPKI: How Vulnerable is the Internet? by Mike Benjamin

BGP announcement for equal or more specific prefixes.
1. Equal prefixes (1.0.0.0/8)
2. Specific prefix (1.2.3.0/24)
BGP_Hijack
AS3 announce more specific prefixes to AS1 only, AS1(Victim) will forward it’s packet to AS3 (Attacker). Attacker can do payload injection, sniff packet etc.

Why do hijack happen?
1. Poor Hygeine (People do run their networks properly/Doesn’t clean things up)
2. Redistribution Mistakes
3. Typo’s
4. Malice
5. DDoS mitigation

What to stop Hijacking?
1. Prefix filtering
2. AS path filtering
3. Max prefix limits

Origin Validation Option
Method
RPKI – Full cryptographic trust towards ownership.
IRR (Legacy) – People register their autonomous system in a registry and put the prefixes you own.
Squatting – Who announce it yesterday.

Creating a baseline for hijack detection
1. Read one rib per day at random and record all as path. routeviews
2. Summarize each RIB entry to just origin AS uplink.
– Removing private ASNs and AS prepend
3. Baseline owner and uplink for 10entries in last 15days.

Detecting Hijack
Check for hijacks and record first match from:
1. Route matched owner
Tools:
a. Verify baseline from Oregon BGP data (comparison)
b. Current owner ex. show ip bgp 1.1.1.0/24 bestpath on public routers.
(verify bgp up/down time)
c. ASN lookup
2. Route and new origin AS match IRR record
3. New origin was an uplink in baseline data
4. New origin is a downlink of baseline owner
5. Remainder are assumed to be a real hijack

Fixing the problem
1. Start with origin validation
Resource Public Key Infrastructure (RPKI) – RFC6480
– Provides cryptographic proof of
ownership.
– RIRs provide the root trust
– Uses X.509 certificates for sub-
allocation
– Final owner signs a Route Origin
Authorization (ROA)
– ROA contains the prefix length
permitted and origin AS
2. Moving Path validation
3. BOGONS

What should people do?
1. Block Bogons -team-cymru.com/bogon-reference.html
2. What your routes – routeviews.org/
3. Adopt RPKI – nist.gov/programs-projects/robust-inter-domain-routing
4. BGP Security – datatracker.ietf.org/wg/sidr/about/
5. Encrypt your traffic

BGP security: an overview of the RPKI framework
https://www.noction.com/blog/bgp_security_rpki_overview

https://blog.thousandeyes.com/amazon-route-53-dns-and-bgp-hijack/

Advertisements

BGP Black hole

BGP Black hole
– Blackhole based on destination
– Remote Trigger with BGP Peers

DNS Amplification
DNS amplification is a Distributed Denial of Service (DDoS) attack in which the attacker exploits vulnerabilities in domain name system (DNS) servers to turn initially small queries into much larger payloads, which are used to bring down the victim’s servers.
https://www.researchgate.net/figure/An-example-of-a-DNS-amplification-attack-4_fig2_50392275

DNS Amplification attack solution
1. Filtering ain’t gonna solve the problem, Because the traffic is already coming down to the link to yours (PE).
2. Drop from upstream? Waiting forever, escalation process issue.

Automated solution we can use is real time blocking (RTBH), Setting up to a BGP session with our upstream providers and if your upstream provider doesn’t support it then find another one.

What is Community tags?
Community tags are just a “Sticky not” we just put on the router that says “Here’s the sticky note and process based on the note”

R1 (CE) sends:
1. /32 address
2. Community tag (666:666)

Upstream (PE) receive and they process it, do a match based on that community tag and set next-hop to R1 (sender) /32 address. We just set next-hop to that and pushes toward to black hole or null route.

BGP Blackhole, how it works?
You and your BGP peers (transit, peers) agree.
Special community tag will signal routes to BH
Say Community 666:666
You send your BGP peer a route with 666:666
They then adjust next-hop for that route to be BLACKHOLE, or NULL, etc (vendor dependent)
Traffic won’t goto that prefix anymore.
You’ve pushed the problem upstream.
But your victim can’t get ANY traffic!! Lesser of two

Use BGP to tell others (peers, transit) to drop traffic towards a particular prefix.
So your customer is getting DDOS’d and its impacting the rest of your network.
You can use blackhole to tell peers to drop towards the victim.
POOF. Victim is now really a victim, but rest of network is now happier.

https://mum.mikrotik.com//presentations/US16/presentation_3386_1462512745.pdf

Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding (uRPF)
– Typically done in hardware
– Very low impact to CPU
– Has some interesting side benefits

uRPF Modes:
– Strict
– Loose

Options:
– Allow self ping
– Allow default route
– ACL

urpf2252918bloo
Packet capture from wireshark show that reply being sent out to 10.1.0.26
urpfcapturesrcdst226
urpf2252918worconf
uRPF Strict
1. Host/Client send’s a packet with ip address on it.
2. Router gonna take the source IP and look on it’s FIB to check whether or not that sources address is reachable on the link that it came in from host and if it is, R1 going to process the rest of the packet and move on. If not drop/deny.

Configuration:
## Create a ACL
access-list 123 deny ip any any log-input

## Enable ACL log
ip access-list log-update threshold 1 (Not applicable on production)

## Any = Loose / RX = Strict
interface FastEthernet1/0
ip verify unicast source reachable-via rx allow-default 123

Verification:

## Attacker using spoof source address and its being blocked
R5#ping 10.1.0.25 source 10.1.0.26 repeat 6
Type escape sequence to abort.
Sending 6, 100-byte ICMP Echos to 10.1.0.25, timeout is 2 seconds:
Packet sent with a source address of 10.1.0.26
……
Success rate is 0 percent (0/6)

## Verify | Logs generated on R4 and Interface source address

Multiple Logs seen
R4#
*Feb 25 12:11:33.054: %SEC-6-IPACCESSLOGDP: list 123 denied icmp 10.1.0.26 (FastEthernet1/0 ca05.1cd4.0000) -> 10.1.0.25 (0/0), 1 packet
R4#
*Feb 25 12:11:35.082: %SEC-6-IPACCESSLOGDP: list 123 denied icmp 10.1.0.26 (FastEthernet1/0 ca05.1cd4.0000) -> 10.1.0.25 (0/0), 1 packet

R4#sh ip int f1/0
IP verify source reachable-via RX, allow default, ACL 123
14 verification drops
0 suppressed verification drops
0 verification drop-rate

## Verify the allowed host(Being allowed)
R6#ping 10.1.0.26
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.26, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/26/44 ms

Ep22 – Securing BGP

Ep22 – Securing BGP
by
Network Collective

Dictionary:
Collision of MD5 –

BGP Security
1. Main common feature used for authentication is MD5, Authentication Md5 for TCP to ensure authentication with the peer.

MD5 uses has that been show theoretically to be breakable.

Collision of MD5, Bypass the password depending on your complexity of your password or what we call “Rainbow table”

Random sending of password(hash) can break your your router.
– Fall pretty fast when sending wrong hashes.
– Process of validity the hash can result as DOS.
– 10 BGP hash and you need to compute and it will result to “Compute exhaustion”

Mitigation:
2. We can mitigate this by using GTSM ( Generic TTL Security Mechanism ), What it does is for every peer, I want to specify how many hops away that peer can be. So if I say that peer is 1 hop away, I going to say that the coming TTL that will received to that peer for all the BGP control plane traffic has to be 256 – (Number of hops) that you specify.

That Effectively forces that peer was going to use maximum TTL when it send the traffic.

Default TTL = 1, Increased to 255.

#### Configuration

History: Formerly known as BTSH or BGP TTL SECURITY HACK

3. Enhanced Authentication(EA) option – To have stronger hashes like Sha etc (ASR Platform) Ipsec, What you can do is with a regular IPSEC.

4. BGP over IPSec
5. BGP over quic?

Prefix Filtering – Major answer is depends where you are in the network.

RFC 2827 / BCP 38 Ingress Packet Filtering
Packets should be sourced from valid, allocated address space, consistent with the topology and space allocation.

Techniques for BCP 38 Filtering:
 Static ACLs on the edge of the network
 Dynamic ACLs with AAA profiles
 Unicast RPF strict mode
 IP source guard
 Cable source verify (DHCP)
http://www.bcp38.info/index.php/Main_Page
https://tools.ietf.org/html/rfc2827.html

Unicast RPF:

Useful:
https://archive.apnic.net/meetings/22/docs/tut-routing-pres-bgp-bcp.pdf
http://www.rfc-editor.org/rfc/rfc3330.txt

From a provider perspective you can do BCP38 on your edge on transit links.

RTBH (Remote triggered black hole) – Injecting black hole in the network.

URPF and RTBH to blocked source and destination(Implemented data center)

Route highjack – RPKI validate the route
– Whais a valid route.

BGP Multihop and TTL Securty

eBGP Multihop feature is used when there is a need of establishing a BGP peering with routers multiple hops away from each other. By default, eBGP peering has a TTL value of 1, if let’s say, two routers are not directly connected (or using any tunneling mechanism), the IP packet will be dropped by router(s) in the transit, since the TTL is too low in order to reach the destination eBGP peer. In order to solve this issue, we can set the multihop feature in order to increase the TTL value of the IP packet for eBGP sessions.

TTL Security, also known as GTSM, defined in this RFC: RFC 5082 – The Generalized TTL Security Mechanism (GTSM); is a security technique implemented to enhance the security of the TCP connection between the BGP peers. Here is a good article describing this feature, http://packetlife.net/blog/2009/nov/23/understanding-bgp-ttl-security/.

It’s a well known fact that eBGP peers need to be (by default) directly connected. That is, the BGP packets generated by a BGP speaker have a TTL of one. When a BGP peer receives the packet, it decrements the TTL on ingress and process the packet normally. If the BGP peer is more than one layer 3 hop away, the first router to receive the packet from the BGP speaker will decrement the TTL of the packet. So in the case of a BGP peer multiple hops away, the eBGP packet sent by the BGP speaker will have a TTL of one. The next router in the path to the peer will decrement the TTL to 0, realize it can’t forward the packet, drop it, and generate an ICMP TTL expired in transit back to router1.

In this scenario we can see that to reach and establish peering our hop count is 3 to reach the ebgp neighbor.
Bgpmulhop827
EBGP Peering Configuration:
R5#
bgp router 10
neighbor 192.168.2.1 remote-as 20
neighbor 192.168.2.1 update-source Loopback1
R3#
bgp router 10
neighbor 192.168.1.1 remote-as 10
neighbor 192.168.1.1 update-source Loopback1

So by default we have TTL value of 1 when it comes to eBGP.
#show ip bgp neighbor
External BGP neighbor not directly connected.
Router knows that the neighbor isn’t directly connected. Apparently this means that the router knows it’s hop count is 1 and that since it isn’t directly connected it doesn’t even try to establish a connection.

We can tell the router to still attempt the the connection by issuing this command under the BGP configuration.
R5#
neighbor 192.168.2.1 disable-connected-check

Changing eBGP multihop setting to 3 on router5.
R5#
bgp router 10
neighbor 192.168.2.1 ebgp-multihop 3

R3#
bgp router 10
neighbor 192.168.2.1 ebgp-multihop 3

Verify:
R5#sh ip bgp neighbors | i hop (Show the allowed hop count)
External BGP neighbor may be up to 3 hops away.

R5#sh ip bgp summary
BGP router identifier 192.168.1.1, local AS number 10
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.1 4 20 0 0 1 0 0 never Idle

Based on this output it’s still not forming as Ebgp neighbor. Let see the debug output.

R5#debug ip bgp all
*Nov 8 15:46:43.411: BGP: 192.168.2.1 Active open failed – no route to peer, open active delayed 8192ms (35000ms max, 60% jitter)

Issue: EBGP Peering Not Established over a Default Route
R5#sh ip cef 192.168.2.1
0.0.0.0/0
nexthop 1.1.1.2 FastEthernet0/0

Note: BGP speaker will not try to establish an EBGP session if/when its peer is reachable over a default route. Cisco Docs

Solution:
Configure a static route on R5.
R5# ip route 192.168.2.1 255.255.255.255 1.1.1.2

Verification after adding static route. Now ebgp peering has been established.
R5#sh ip bgp summary
BGP router identifier 192.168.1.1, local AS number 10
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.1 4 20 6 6 1 0 0 00:02:28 0

TTL Security
This feature protects the eBGP peering session by comparing the value in the TTL field of received IP packets against a hop count that is configured locally for each eBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, the IP packet is accepted and processed normally. If the TTL value in the IP packet is less than the locally configured value, the packet is silently discarded and no ICMP message is generated. This is designed behavior; a response to a forged packet is unnecessary.

eBGP multihop configures the maximum number of hops in which a eBGP speaker can use to reach a eBGP peer. TTL-Security assumes the default TTL of 255 is being used and ensures that the TTL of the received packet is greater than or equal to the minimum TLL (255 minus configured hop count).

Configuration:
R1#

R4#

Consider we have a rogue router that’s many hops away. The rogue router and router1 both appear to be within the correct distance for router4 to accept the session. Granted, router4’s reply to the rogue router won’t work since he likely has en eBGP multihop setting of 3 (like router1 in this example) but router4 will still accept the initial TCP SYN for the BGP session. If we change this to TTL-Security we get something that looks like this.

Considering we had TTL-Security configured for 3 hops on both router1 and router4, the rogue router wouldn’t be able to create a session to router4 because it’s arriving TTL is not in between the minimum(252) and maximum(255) range. However, the connection from router1 would work just fine since it’s arriving TTL at router4 is 253 (252 once router4 processes it). Once configured we’d see something like this on router4.

Verification:
R1#sh ip bgp neighbors 192.168.2.1 | i hop|TTL
External BGP neighbor may be up to 3 hops away.
Connection is ECN Disabled, Mininum incoming TTL 252, Outgoing TTL 255

Reference:
http://www.dasblinkenlichten.com/ebgp-multihop-vs-ttl-security/
https://learningnetwork.cisco.com/thread/107427
https://networklessons.com/bgp/ebgp-multihop/
http://packetlife.net/blog/2009/nov/23/understanding-bgp-ttl-security/
http://costiser.ro/2013/02/02/bgp-over-a-default-route/#.WgK30FuCyUk