Document 1359361

10/21/15 12. Internet Protocols and Denial of Service 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 –  Building blocks –  AuthenFcaFon and access control •  Where we’re going today –  Internet protocols (BGP, DNS) –  Denial of service •  Where we’re going next –  Checkpoint 1 (Monday) –  Malware distribuFon networks (Wednesday) 2 1 10/21/15 Project Checkpoint #1 •  Prepare short presentaFons about your progress on the group project –  10 minutes: teams w/ 3 members –  7 minutes: teams w/ 2 members –  5 minutes: individual projects –  2 minutes Q&A aWer each presentaFon •  Post your slides (Powerpoint only) on Piazza by Monday at 10 am –  We will use a single laptop to present –  Timing will be strictly enforced •  Discuss novelty and iniFal results –  Review related work and the gap addressed by your project –  IniFal results •  ParFcularly important for projects that did not demonstrate feasibility in the pilot stage •  Focus on the progress since the pilot project 3 We’ve Seen: Internet Is a Network of Networks backbone ISP Internet service provider (ISP) local network local network Autonomous system (AS) is a collecFon of IP networks under control of a single administrator (e.g., ISP) •  Threats in TCP/IP: Eavesdropping, DoS, Host ImpersonaFon •  Other network protocols can be a^acked as well –  Border Gateway Protocol (BGP), used for route discovery –  Domain Name System (DNS), used for IP address discovery 4 2 10/21/15 IP RouVng •  RouFng of IP packets is based on IP addresses –  32-­‐bit host idenFfiers (128-­‐bit in IPv6) •  Routers use a forwarding table –  Entry = desFnaFon, 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 rouFng protocols –  Host is idenFfied by IP address, network by IP prefix •  BGP (Border Gateway Protocol) is the core Internet protocol for establishing inter-­‐AS routes 5 Distance-­‐Vector RouVng •  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 informaFon –  Bellman-­‐Ford algorithm: for each desFnaFon, router picks the neighbor adverFsing the cheapest route, adds his entry into its own rouFng table and re-­‐adverFses –  Used in RIP (rouFng informaFon protocol) •  How can you aYack RIP? What are the aYacker’s capabiliVes? •  Split-­‐horizon update –  Do not adverFse a route on an interface from which you learned the route in the first place! 6 3 10/21/15 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 adverFses 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 rouFng tables 7 Bad News Travels Slowly Exchange rouFng 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 adverFsing a pre^y good route to G1 (cost=2) •  G1’s packets to A are forever looping between G2 and G1 •  G1 is now adverFsing 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 counFng to infinity –  Split-­‐horizon updates only prevent two-­‐node loops 8 4 10/21/15 Overview of BGP •  BGP is a path-­‐vector protocol between ASes •  Just like distance-­‐vector, but rouFng updates contain an actual path to desFnaFon 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 adverFses this path to its neighbors –  Can be the shortest path, but doesn’t have to be •  “Hot-­‐potato” vs. “cold-­‐potato” rouFng –  Always route to most specific prefix for a desFnaFon 9 BGP MisconfiguraVon •  Domain adverFses 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-­‐adverFsed all prefixes as if it originated paths to them •  In effect, AS7007 was adverFsing that it has the best route to every host on the Internet –  Huge network instability as incorrect rouFng data propagated and routers crashed under traffic 10 5 10/21/15 BGP (In)Security •  BGP update messages contain no authenFcaFon or integrity protecFon •  A^acker may falsify the adverFsed routes –  Modify the IP prefixes associated with a route •  Can blackhole traffic to certain IP prefixes –  Change the AS path •  Either a^ract traffic to a^acker’s AS, or divert traffic away •  InteresFng economic incenFve: an ISP wants to dump its traffic on other ISPs without rouFng their traffic in exchange –  Re-­‐adverFse/propagate AS path without permission •  For example, a mulF-­‐homed customer may end up adverFsing transit capability between two large ISPs •  Or a spammer may hijack an IP prefix 11 YouTube (Normally) •  AS36561 (YouTube) adverFses 208.65.152.0/22 12 6 10/21/15 YouTube (February 24, 2008) •  Pakistan government wants to block YouTube –  AS17557 (Pakistan Telecom) adverFses 208.65.153.0/24 –  All YouTube traffic worldwide directed to AS17557 •  Result: two-­‐hour YouTube outage 13 BGP Security •  Origin authenFcaFon –  Resource Public Key Infrastructure (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 misconfiguraFons –  But also provides protecFon against prefix hijacking a^acks •  Path validaFon –  S-­‐BGP, soBGP, BGPSEC, etc. –  Protects against AS-­‐level a^ackers who want to draw traffic from another AS •  Any soluFon must consider that it will be parVally deployed for a long Fme –  Some a^acks are possible against secure ASes [Lychev et al., “BGP Security in ParFal Deployment”, 2013] 14 7 10/21/15 DNS: Domain Name Service 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
w
w
du NS e
NS umd.edu ww
w=
IPa
ddr
root DNS server edu DNS server umd.edu DNS server 15 DNS Root Name Servers •  Root name servers for top-­‐level domains •  AuthoritaFve name servers for subdomains •  Local name resolvers contact authoritaFve servers when they do not know a name •  h^p://www.root-­‐
servers.org/ Feb 6, 2007: Botnet DoS a^ack on root DNS servers 8 10/21/15 DDoS Against Root DNS Servers •  Could potenFally cause Internet-­‐wide blackout –  Two known incidents, in 2002 and 2007 •  Defense: IP anycast –  Each root DNS server is replicated at mulFple sites, worldwide •  87 sites for D-­‐root –  The server’s IP address announced by several ASes (using BGP) –  A packets is routed to the nearest address –  Recently, root servers had to change IP addresses to support anycast •  D-­‐root: 3 January 2013 [Lentz et. al, ‘D-­‐mysFfying the D-­‐root Address Change’, IMC’13] •  H-­‐root: 1 December 2015 17 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 a^ack method known as SQL injecFon 18 9 10/21/15 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/21/15 DNS Resolvers •  Resolver accepts queries from clients and queries the the authoritaFve name servers •  Local resolvers –  Example: UMD DNS servers –  Should not accept queries from clients outside their local network •  Open resolvers –  Examples: Open DNS, Google DNS –  Privacy threats: •  Client’s IP address and domain queried travel in clear toward the open resolver •  With ECS extension: resolver sends first few bits of client IP to the name server 21 DNS AmplificaVon AYack x50 amplificaFon [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 a^ack on Spamhaus 22 11 10/21/15 Other DNS VulnerabiliVes •  Kaminski a^ack: poison DNS caches –  A^acker guesses transacFon ID used to match queries with replies –  SoluFon: randomize ports and transacFon IDs •  DNS implementaFons have vulnerabiliFes –  Reverse query buffer overrun in old releases of BIND –  MS DNS for NT 4.0 crashes on chargen stream •  Can use “zone transfer” requests to download DNS database and map out the network –  SoluFon: block port 53 on corporate name servers See h^p://cr.yp.to/djbdns/notes.html 23 Trust Management •  With BGP and DNS, you interact with systems potenFally under the a^acker’s control –  Is the remote server compromised? –  Could the remote server have been tricked into relaying poisoned informaFon? •  How many remote systems are in your TCB? 24 12 10/21/15 DNSSEC •  Each DNS record is digitally signed •  CerFficates are appended to responses for
aks
y(K ro
ke
).co
ot
root server m) e
) sp
com
.
K
o) (
ey
om.fo
d (k
K root).c
(
e
y
e
n
k
.com server ksfor
sig
) spea
K root
m
K
oo.co
(
.f
y
e
(k
igned
K .com s
K.foo.com signed .foo.www) (key(Kwww.foo.com) speaksfor key(Kroot).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 25 root).com.foo.www) 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 perspecFve •  OpFmist: DNS already requires a trusted root, at least DNSSEC does not require trusFng every other DNS server •  Pessimist: Could have done be^er –  But probably not without changing how DNS works –  So, let’s try changing how DNS works 26 13 10/21/15 EliminaVng 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 27 Review of Lecture •  What did we learn? –  BGP –  DNS •  Sources –  Vitaly ShmaFkov •  What’s next? –  Project checkpoint #1 –  Malware delivery networks 28 14