26
SECURING BGP Matthew Nickasch [email protected] University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

SECURING BGP Matthew Nickasch [email protected] University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Embed Size (px)

Citation preview

Page 1: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

SECURING BGPMatthew [email protected]

University of Wisconsin-PlattevilleDept. of Computer Science & Software Engineering

Page 2: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

BGP – Quick Overview

•External Routing Protocol▫Interior vs. Exterior Gateway Protocols▫The Autonomous System (AS)▫Routing between ISPs

•BGP - Only EGP in use

Page 3: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Functions of BGP

•Shortest path not priority•Routing policy•Removal of routing loops•Broken link removal•Determine which IPs “go where”

▫Responsibility of address blocks

Page 4: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Basic Operation of BGP

•Connections between border routers peer with neighboring ASes

•TCP port 179•Manual session creation

▫Complete copies of routing table sent to neighbors

▫Evaluate received routes▫Better route through neighbor? UPDATE▫Only update when routes change

Page 5: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Intra/Inter AS Routing

AS 100

AS 200

AS 500

AS 400

AS 300

(PEERING RULES)

AS 500

LAN_CORBOR_1

BOR_2

Page 6: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Routing Policy•When to send routes? •Where to send routes?•Peering Responsibility

▫Accept routes from known peers▫Don’t accept routes from non-peers▫Route efficiency hampered by political

boundaries▫Route preference configuration

•ACL (Access Control Lists)•Error Checking

Page 7: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

An ISP’s Use of BGP

•Importance of filtering•Address block size

▫Prefix “overload” (small networks/subnets)▫Delegate BGP handling to ISP

•Utilization of peering paths

Page 8: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

BGP Looking Glass Demo•Looking Glass

▫route-views.ab.bb.telus.com•ARIN AS Whois Lookup•Prefix / AS Query

Page 9: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Security Considerations

•BGP – Single Point of Failure?▫Only EGP in use▫Comparison with IGPs

OSPF, RIP, IS-IS, etc.

▫EGP standardization difficult “Big” router vendors

Early Cisco stronghold Now Juniper, Nortel, etc. Different vendors want different

implementations

Page 10: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Security Considerations•A “trusting protocol”

▫Very little error checking Route verification requires route lookups 30,000 + ASes! * 120,000 unique routes! =

TIME Garbage in, garbage out

•Physical Infrastructure▫9/11 “Meet Me Facilities”▫Peering Points▫Physical Router Compromisation

Page 11: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Security Considerations• Human error

▫Human error to human intent (exploit errors)

• Remote router compromisation▫IOS vulnerabilities, etc.

• Social Engineering vulnerabilities

• BGP traffic sniffing▫Message injection / modification▫Man-in-the-middle

Page 12: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Security – Assembling the Risk

•SPOF•Trusting protocol + lack of error checking•Physical Infrastructure•Human Error•Router security flaws•Social Engineering•Unencrypted message transport•DoS / MIM / TCP-style attacks•Supporting entire Internet routing

structure

Page 13: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

YouTube Route Hijacking

•Prime example of human ‘error’ ▫Illustrates violation of route trust▫Easily replicated by attacker▫Proves that attack vectors are in-place

Compromised router could cause similar results

Relatively simple attack, “invalid route announcement”

Potential large worldwide attack against many ASes

Page 14: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

YouTube Route Hijacking•YT always announces 208.65.152.0/22•Pakistani Telecom announces

208.65.153.0/24•Routes propagate to bordering ASes

▫Traffic destined for network directed to PT•YT announces 208.65.153.0/24

• Duplicate announcement entry (shortest path)•YT announces 208.65.153.128/25

▫Longest-prefix-match-rule Most specific route

Page 15: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

YouTube (AS 36561) Pre-Hijack

Page 16: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Pakistani Tel (AS 17557) Hijack

Page 17: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Detecting Invalid/False Routes

•Response▫“Firefighter” mentality to BGP problems▫Symptom-based response too late▫Cooperation between ASes?▫Governing ‘body’ for BGP disputes

Page 18: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

YouTube – What We’ve Learned

•ISP Routing Policy•“Routing Registry” – RIPE •Certificate-based approvals•BGP not substitute for ACLs!•Exploitation of protocol “trust”•Rapid replication•Extreme vulnerability

Page 19: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Protocol Security

•MD5 & other encryption▫Hard to standardize between all ASes▫Vendor agreement issues

•“Reinventing” the protocol▫Secure BGP▫PGBGP▫Revisions to existing BGP

Page 20: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Secure BGP (SBGP)

•Public key infrastructure (PKI)▫Authentication/ownership of IP address

space▫AS identity verification▫Encrypting BGP Update messages

•Implementation▫Vendor support must be unanimous▫All ASes must agree to adopt SBGP, or any

other protocol-level change

Page 21: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Secure BGP (SBGP)

•Doesn’t prevent human error▫“Encrypting garbage”

•Origins▫NSA/DoD initial support (1997)▫DARPA

•Next Steps▫PKI infrastructure, CA▫Oversight organization for PKI? Hosting?

Page 22: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Pretty Good BGP (PGBGP)•Cautiously accepting/updating routes

▫Suspicious updaters▫Quarantine routes▫Time-delay updates

•Implementation – Adapt PGBGP logic?▫Vendor support could vary – depends on

route-accepting algorithms▫Introduce PGBGP logic into existing BGP

environment.

Page 23: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Layered Security Analysis

PHYSICAL SECURITY

SOCIAL ENGINEERING

HUMAN ERROR

INADEQUATE CORP /ORG / ISP POLICY

AVAILABLE “TCP-STYLE” VECTORS

SOURCE / SENDER AUTHENTICATION

BGP PROTOCOL WEAKNESSES

SINGLE POINT OF FAILURE (INTERNET)

Page 24: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Layered Solution

•Protocol level ▫SBGP (PKI) + PGBGP (update logic) = a

more secure solution▫Limits peer trust, introduces authentication

and encryption▫AS identity verification▫Slower route change replication

throughout the Internet▫Not the end-all solution!

Page 25: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Layered Solution

•Implement stringent ISP routing policy•Implement SBGP + PGBGP logic into

existing protocol▫Attain vendor agreement on

implementation•Reduce human error•Enforce proper-use of BGP (ACL example)•Router security / minimize vectors•Physical security, etc.

Page 26: SECURING BGP Matthew Nickasch nickaschm@uwplatt.edu University of Wisconsin-Platteville Dept. of Computer Science & Software Engineering

Q/A ?Matthew [email protected]