Download document 8927318

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Lag wikipedia , lookup

Net bias wikipedia , lookup

Peering wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Transcript
10/15/14 12. Security of Internet Protocols (BGP, DNS) ENEE 757 | CMSC 818V Prof. Tudor Dumitraș Assistant Professor, ECE University of Maryland, College Park http://ter.ps/757 https://www.facebook.com/SDSAtUMD Today’s Lecture •  Where we’ve been –  AuthenDcaDon and access control –  TCP/IP security •  Where we’re going today –  BGP –  DNS •  Where we’re going next –  Web authenDcaDon 2 1 10/15/14 IP RouKng •  RouDng of IP packets is based on IP addresses –  32-­‐bit host idenDfiers (128-­‐bit in IPv6) •  Routers use a forwarding table –  Entry = desDnaDon, next hop, network interface, metric –  Table look-­‐up for each packet to decide how to route it •  Routers learn routes to hosts and networks via rouDng protocols –  Host is idenDfied by IP address, network by IP prefix •  BGP (Border Gateway Protocol) is the core Internet protocol for establishing inter-­‐AS routes 3 Distance-­‐Vector RouKng •  Each node keeps vector with distances to all nodes •  Periodically sends distance vector to all neighbors •  Neighbors send their distance vectors, too; node updates its vector based on received informaDon –  Bellman-­‐Ford algorithm: for each desDnaDon, router picks the neighbor adverDsing the cheapest route, adds his entry into its own rouDng table and re-­‐adverDses –  Used in RIP (rouDng informaDon protocol) •  Split-­‐horizon update –  Do not adverDse a route on an interface from which you learned the route in the first place! 4 2 10/15/14 Good News Travels Fast A: 0 1 A: 1 1 G1 A: 2 1 G2 A: 3 1 G3 A: 4 1 G4 A: 5 G5 •  G1 adverDses route to network A with distance 1 •  G2-­‐G5 quickly learn the good news and install the routes to A via G1 in their local rouDng tables 5 Bad News Travels Slowly Exchange rouDng tables A: 0 A: 1 G1 1 A: 2 G2 1 A: 3 1 G3 A: 4 1 G4 A: 5 G5 •  G1’s link to A goes down •  G2 is adverDsing a preay good route to G1 (cost=2) •  G1’s packets to A are forever looping between G2 and G1 •  G1 is now adverDsing a route to A with cost=3, so G2 updates its own route to A via G1 to have cost=4, and so on –  G1 and G2 are slowly counDng to infinity –  Split-­‐horizon updates only prevent two-­‐node loops 6 3 10/15/14 Overview of BGP •  BGP is a path-­‐vector protocol between ASes •  Just like distance-­‐vector, but rouDng updates contain an actual path to desDnaDon node –  List of traversed ASes and a set of network prefixes belonging to the first AS on the list •  Each BGP router receives update messages from neighbors, selects one “best” path for each prefix, and adverDses this path to its neighbors –  Can be the shortest path, but doesn’t have to be •  “Hot-­‐potato” vs. “cold-­‐potato” rouDng –  Always route to most specific prefix for a desDnaDon 7 Some (Old) BGP StaKsKcs •  BGP rouDng tables contain about 125,000 address prefixes mapping to about 17-­‐18,000 paths •  Approx. 10,000 BGP routers •  Approx. 2,000 organizaDons own AS •  Approx. 6,000 organizaDons own prefixes •  Average route length is about 3.7 •  50% of routes have length less than 4 ASes •  95% of routes have length less than 5 ASes 8 4 10/15/14 BGP MisconfiguraKon •  Domain adverDses good routes to addresses it does not know how to reach –  Result: packets go into a network “black hole” •  April 25, 1997: “The day the Internet died” –  AS7007 (Florida Internet Exchange) de-­‐aggregated the BGP route table and re-­‐adverDsed all prefixes as if it originated paths to them •  In effect, AS7007 was adverDsing that it has the best route to every host on the Internet –  Huge network instability as incorrect rouDng data propagated and routers crashed under traffic 9 BGP (In)Security •  BGP update messages contain no authenDcaDon or integrity protecDon •  Aaacker may falsify the adverDsed routes –  Modify the IP prefixes associated with a route •  Can blackhole traffic to certain IP prefixes –  Change the AS path •  Either aaract traffic to aaacker’s AS, or divert traffic away •  InteresDng economic incenDve: an ISP wants to dump its traffic on other ISPs without rouDng their traffic in exchange –  Re-­‐adverDse/propagate AS path without permission •  For example, a mulD-­‐homed customer may end up adverDsing transit capability between two large ISPs •  Or a spammer may hijack an IP prefix 10 5 10/15/14 YouTube (Normally) •  AS36561 (YouTube) adverDses 208.65.152.0/22 11 YouTube (February 24, 2008) •  Pakistan government wants to block YouTube –  AS17557 (Pakistan Telecom) adverDses 208.65.153.0/24 –  All YouTube traffic worldwide directed to AS17557 •  Result: two-­‐hour YouTube outage 12 6 10/15/14 Other BGP Incidents •  May 2003: Spammers hijack unused block of IP addresses belonging to Northrop Grumman –  EnDre Northrop Grumman ends up on spam blacklist –  Took two months to reclaim ownership of IP addresses •  May 2004: Malaysian ISP hijacks prefix of Yahoo’s California data center •  Dec 2004: Turkish ISP adverDses routes to the enDre Internet, including Amazon, CNN, Yahoo •  Apr 2010: Small Chinese ISP adverDses routes to 37,000 networks, incl. Dell, CNN, Apple 13 Resource Public Key Infrastructure (RPKI) •  RPKI: provide trusted mapping from an IP prefix to a set of autonomous systems (ASes) that are authorized to originate it –  Main goal: compensate BGP misconfiguraDons –  But also provides protecDon against prefix hijacking aaacks –  Standardized by the IETF and adopted by the Regional Internet Registries (RIRs) •  RPKI authoriDes (ISPs) –  Strict hierarchy that mirrors the IP address allocaDon hierarchy –  Each authority has a resource cerDficate (RC) containing its cryptographic public key and its set of allocated IP addresses –  AuthoriDes issue signed cryptographic objects •  RCs that allocate subsets of its addresses to other authoriDes (customers) •  Route origin authorizaDon (ROA), allowing an AS to originate an IP prefix in BGP •  RouDng –  Relying parDes access RPKI objects stored in public repositories •  ROAs are also cached locally –  Determine if a BGP route is valid, invalid or unknown 14 7 10/15/14 AllocaKons Can Span InternaKonal Borders C.3 The number of countries that hold ROAs that descend from each direct allocation.
[Cooper, Heilman,
Brogle, Reizin and Goldberg, 2013]
Number of countries that hold ROAs descending from each direct allocaDon 15 DNS: Domain Name Service 15
DNS maps symbolic names to numeric IP addresses (for example, www.umd.edu ↔ 54.83.56.209) www.umd.edu Client Local DNS recursive resolver ..edu
umd
.
w
ww
du NS e
NS umd.edu ww
w=
IPa
ddr
root DNS server edu DNS server umd.edu DNS server 16 8 10/15/14 DNS Root Name Servers •  Root name servers for top-­‐level domains •  AuthoritaDve name servers for subdomains •  Local name resolvers contact authoritaDve servers when they do not know a name •  hap://www.root-­‐
servers.org/ Feb 6, 2007: Botnet DoS aaack on root DNS servers The hacking group, called Turkguvenligi, targeted the net's Domain Name System (DNS) Turkguvenligi revealed that it got access to the files using a well-­‐
established aaack method known as SQL injecDon 18 9 10/15/14 March 16, 2014 It is suspected that hackers exploited a well-­‐known vulnerability in the so-­‐
called Border Gateway Protocol (BGP) 19 Turkey (2014) 20 10 10/15/14 DNS AmplificaKon A`ack x50 amplificaDon [Rossow’14] EDNS response (3000 bytes) DNS query SrcIP: DoS Target (60 bytes) DoS Source DNS Server DoS Target 2006: 0.58M open resolvers on Internet (Kaminsky-­‐Shiffman) 2013: 21.7M open resolvers (openresolverproject.org) March 2013: 300 Gbps DDoS aaack on Spamhaus 21 Other DNS VulnerabiliKes •  Kaminski aaack: poison DNS caches –  Aaacker guesses transacDon ID used to match queries with replies –  SoluDon: randomize ports and transacDon IDs •  DNS implementaDons have vulnerabiliDes –  Reverse query buffer overrun in old releases of BIND –  MS DNS for NT 4.0 crashes on chargen stream •  Denial of service –  Oct ’02: ICMP flood took out 9 root servers for 1 hour •  Can use “zone transfer” requests to download DNS database and map out the network –  SoluDon: block port 53 on corporate name servers See hap://cr.yp.to/djbdns/notes.html 22 11 10/15/14 DNSSEC •  Goals: authenDcaDon and integrity of DNS requests and responses •  PK-­‐DNSSEC (public key) –  DNS server signs its data (can be done in advance) –  How do other servers learn the public key? •  SK-­‐DNSSEC (symmetric key) –  EncrypDon and MAC: Ek(m, MAC(m)) –  Each message contains a nonce to avoid replay –  Each DNS node shares a symmetric key with its parent –  Zone root server has a public key (hybrid approach) 23 DNSSEC •  Each DNS record is digitally signed •  CerDficates are appended to responses sf
eak
) sp
K .com
ey(
k
(
ned
sig
K root
(K .foo.co
d (key
signe
).co
root server m) ot
y(K ro
e
or k
.foo) ).com
ot
K
(
ro
y
e
k
.com server ksfor ) spea
m
K .com
K.foo.com signed .foo.www) ).com
ey(K
k
for peaks
s
) root
(key(Kwww.foo.com
.foo.com server Globally trusted! What does the key(Kroot).com.foo says client conclude? (key(K
) speaksfor key(K
www.foo.com
www.foo.com 24 root).com.foo.www) 12 10/15/14 Reducing the TCB •  We didn’t reduce the trust on the root –  But that’s real life: DNSSEC root is in TCB for every DNS name •  Is this bad? … The answer depends on your perspecDve •  OpDmist: DNS already requires a trusted root, at least DNSSEC does not require trusDng every other DNS server •  Pessimist: Could have done beaer –  But probably not without changing how DNS works –  So, let’s try changing how DNS works 25 EliminaKng a Globally Trusted Authority [Lampson, Abadi, Burrows & Wobber, 1992]
This part not in TCB for deducing Kwww.cs.cornell.edu ⇒ www.cs.cornell.edu .edu (5) .umd.edu .cornell.edu (7) (3) .cs.umd.edu (9) (4) (6) (8) (1) (10) (2) (11) .cs.cornell.edu www.cs.cornell.edu 26 13 10/15/14 Sources •  Various slides from Vitaly ShmaDkov 27 Review of Lecture •  What did we learn? –  BGP –  DNS •  Paper presentaDon •  What’s next? –  Web authenDcaDon 28 14