Bài giảng An ninh mạng - Chương 8: Attacks on TCP/IP, BGP, DNS Denial of Service - Trần Trung Dũng

Nội dung text: Bài giảng An ninh mạng - Chương 8: Attacks on TCP/IP, BGP, DNS Denial of Service - Trần Trung Dũng

1. Attacks on TCP/IP, BGP, DNS Denial of Service slide 1
2. Internet is a Network of Networks backbone ISP local network Internet service provider (ISP) Autonomous system (AS) is a local network collection of IP networks under control of a single administrator (e.g., ISP)  TCP/IP for packet routing and connections  Border Gateway Protocol (BGP) for route discovery  Domain Name System (DNS) for IP address discovery slide 2
3. OSI Protocol Stack email, Web, NFS application presentation RPC session TCP transport IP network Ethernet data link physical slide 3
4. Data Formats application Application data message layer transport TCP TCP TCP segment layer header data header data header data network IP TCP packet layer header header data data link Ethernet IP TCP Ethernet frame layer header header header data trailer slide 4
5. TCP (Transmission Control Protocol) Sender: break data into packets • Sequence number is attached to every packet Receiver: reassemble packets in correct order • Acknowledge receipt; lost packets are re-sent Connection state maintained on both sides remember received pages book mail each and reassemble page slide 5
6. IP (Internet Protocol) Connectionless • Unreliable, “best-effort” protocol Uses numeric addresses for routing • Typically several hops in the route Alice’s computer Bob’s ISP Packet Alice’s ISP Source 128.83.130.239 Dest 171.64.66.201 128.83.130.239 Seq 3 Bob’s computer 171.64.66.201 slide 6
7. ICMP (Control Message Protocol) Provides feedback about network operation • “Out-of-band” messages carried in IP packets • Error reporting, congestion control, reachability, etc. Example messages: • Destination unreachable • Time exceeded • Parameter problem • Redirect to better gateway • Reachability test (echo / echo reply) • Message transit delay (timestamp request / reply) slide 7
8. Security Issues in TCP/IP Network packets pass by untrusted hosts • Eavesdropping (packet sniffing) IP addresses are public • Smurf attacks TCP connection requires state • SYN flooding TCP state is easy to guess • TCP spoofing and connection hijacking slide 8
9. Packet Sniffing Many applications send data unencrypted • ftp, telnet send passwords in the clear Network interface card (NIC) in “promiscuous mode” reads all passing data network Solution: encryption (e.g., IPsec), improved routing slide 9
10. “Smurf” Attack Looks like a legitimate “Are you alive?” ping request from the victim Stream of ping replies 1 ICMP Echo Req overwhelms victim Src: victim’s address Dest: broadcast address victim Every host on the network gateway generates a ping (ICMP Echo Reply) to victim Solution: reject external packets to broadcast addresses slide 10
11. “Ping of Death” If an old Windows machine received an ICMP packet with a payload longer than 64K, machine would crash or reboot • Programming error in older versions of Windows • Packets of this length are illegal, so programmers of Windows code did not account for them Solution: patch OS, filter out ICMP packets slide 11
12. “Teardrop” and “Bonk” TCP fragments contain Offset field Attacker sets Offset field to overlapping values • Bad implementation of TCP/IP stack will crash when attempting to re-assemble the fragments  or to very large values • Target system will crash Solution: use up-to-date TCP/IP implementation slide 12
13. “LAND” Single-packet denial of service (DoS) attack IP packet with source address, port equal to destination address, port SYN flag set Triggers loopback in the Windows XP SP2 implementation of TCP/IP stack • Locks up CPU Solution: ingress filtering slide 13
14. TCP Handshake C S SYNC Listening Spawn thread, store data SYNS, ACKC (connection state, etc.) Wait ACKS Connected slide 14
15. SYN Flooding Attack S SYNC1 Listening SYN Spawn a new thread, C2 store connection data SYNC3 and more SYNC4 and more and more SYNC5 and more and more slide 15
16. SYN Flooding Explained Attacker sends many connection requests with spoofed source addresses Victim allocates resources for each request • New thread, connection state maintained until timeout • Fixed bound on half-open connections Once resources exhausted, requests from legitimate clients are denied This is a classic denial of service attack • Common pattern: it costs nothing to TCP initiator to send a connection request, but TCP responder must spawn a thread for each request - asymmetry! slide 16
17. Preventing Denial of Service DoS is caused by asymmetric state allocation • If responder opens new state for each connection attempt, attacker can initiate thousands of connections from bogus or forged IP addresses Cookies ensure that the responder is stateless until initiator produced at least two messages • Responder’s state (IP addresses and ports of the con- nection) is stored in a cookie and sent to initiator • After initiator responds, cookie is regenerated and compared with the cookie returned by the initiator slide 17
18. SYN Cookies [Bernstein and Schenk] C S SYN C Listening Compatible with standard TCP; Does not store state simply a “weird” sequence number scheme SYNS, ACKC sequence # = cookie F(source addr, source port, Cookie must be unforgeable dest addr, dest port, and tamper-proof (why?) F=Rijndael or crypto hash Client should not be able coarse time, server secret) to invert a cookie (why?) ACKS(cookie) Recompute cookie, compare with with the one received, only establish connection if they match More info: slide 18
19. Another Defense: Random Deletion half-open connections SYNC 121.17.182.45 231.202.1.16 121.100.20.14 5.17.95.155 If SYN queue is full, delete random entry • Legitimate connections have a chance to complete • Fake addresses will be eventually deleted Easy to implement slide 19
20. TCP Connection Spoofing Each TCP connection has associated state • Sequence number, port number TCP state is easy to guess • Port numbers standard, seq numbers predictable Can inject packets into existing connections • If attacker knows initial sequence number and amount of traffic, can guess likely current number • Guessing a 32-bit seq number is not practical, BUT • Most systems accept large windows of sequence numbers (to handle massive packet losses) • Send a flood of packets with likely sequence numbers slide 20
21. “Blind” IP Spoofing Attack Trusted connection between Alice and Bob uses predictable sequence numbers  SYN-flood Bob’s queue Alice Bob  Open connection to Alice to get initial sequence number  Send packets to Alice that resemble Bob’s packets  Can’t receive packets sent to Bob, but maybe can penetrate Alice’s computer if Alice uses IP address-based authentication • rlogin and other remote access tools use address-based authentication slide 21
22. DoS by Connection Reset If attacker can guess the current sequence number for an existing connection, can send Reset packet to close it Especially effective against long-lived connections • For example, BGP route updates slide 22
23. User Datagram Protocol (UDP) UDP is a connectionless protocol • Simply send datagram to application process at the specified port of the IP address • Source port number provides return address • Applications: media streaming, broadcast No acknowledgement, no flow control, no message continuation Denial of service by UDP data flood slide 23
24. Countermeasures Above transport layer: Kerberos • Provides authentication, protects against application- layer spoofing • Does not protect against connection hijacking Above network layer: SSL/TLS and SSH • Protects against connection hijacking and injected data • Does not protect against DoS by spoofed packets Network (IP) layer: IPsec • Protects against hijacking, injection, DoS using connection resets, IP address spoofing slide 24
25. IP Routing Routing of IP packets is based on IP addresses • 32-bit host identifiers (128-bit in IPv6) Routers use a forwarding table • Entry = destination, 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 routing protocols • Host is identified by IP address, network by IP prefix BGP (Border Gateway Protocol) is the core Internet protocol for establishing inter-AS routes slide 25
26. Distance-Vector Routing 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 information • Bellman-Ford algorithm: for each destination, router picks the neighbor advertising the cheapest route, adds his entry into its own routing table and re-advertises • Used in RIP (routing information protocol) Split-horizon update • Do not advertise a route on an interface from which you learned the route in the first place! slide 26
27. Good News Travels Fast A: 0 A: 1 A: 2 A: 3 A: 4 A: 5 1 1 1 1 1 G1 G2 G3 G4 G5  G1 advertises 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 routing tables slide 27
28. Bad News Travels Slowly Exchange routing tables A: 0 A: 1 A: 2 A: 3 A: 4 A: 5 1 1 1 1 G1 G2 G3 G4 G5  G1’s link to A goes down  G2 is advertising a pretty good route to G1 (cost=2)  G1’s packets to A are forever looping between G2 and G1  G1 is now advertising 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 counting to infinity • Split-horizon updates only prevent two-node loops slide 28
29. Overview of BGP BGP is a path-vector protocol between ASes Just like distance-vector, but routing updates contain an actual path to destination 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 advertises it to the neighbors • Can be shortest path, but doesn’t have to be – “Hot-potato” vs. “cold-potato” routing • AS doesn’t have to use the path it advertises! slide 29
30. BGP Example [Wetherall] 3 2 7 1 2 7 3 4 2 6 5 2 6 5 3 2 6 5 5 2 7 8 2 6 5 7 2 6 5 7 2 7 7 6 2 7 2 6 5 6 5 7 5  AS 2 provides transit for AS 7 • Traffic to and from AS 7 travels through AS 2 slide 30
31. Some BGP Statistics BGP routing tables contain about 125,000 address prefixes mapping to about 17-18,000 paths Approx. 10,000 BGP routers Approx. 2,000 organizations own AS Approx. 6,000 organizations 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 slide 31
32. BGP Misconfiguration Domain advertises 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-advertised all prefixes as if it originated paths to them • In effect, AS7007 was advertising that it has the best route to every host on the Internet • Huge network instability as incorrect routing data propagated and routers crashed under traffic slide 32
33. BGP Security BGP update messages contain no authentication or integrity protection Attacker may falsify the advertised routes • Modify the IP prefixes associated with the route – Can blackhole traffic to certain IP prefixes • Change the AS path – Either attract traffic to attacker’s AS, or divert traffic away – Interesting economic incentive: an ISP wants to dump its traffic on other ISPs without routing their traffic in exchange • Re-advertise/propagate AS path without permission – For example, multi-homed customer may end up advertising transit capability between two large ISPs slide 33
34. YouTube (Normally) AS36561 (YouTube) advertises 208.65.152.0/22 slide 34
35. YouTube (February 24, 2008) Pakistan government wants to block YouTube • AS17557 (Pakistan Telecom) advertises 208.65.153.0/24 • All YouTube traffic worldwide directed to AS17557 Result: two-hour YouTube outage slide 35
36. Other BGP Incidents May 2003: Spammers hijack unused block of IP addresses belonging to Northrop Grumman • Entire 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 advertises routes to the entire Internet, including Amazon, CNN, Yahoo slide 36
37. DNS: Domain Name Service DNS maps symbolic names to numeric IP addresses (for example, www.hcmus.edu.vn  172.29.1.16) root & vn DNS server www.hcmus.edu.vn edu.vn Local DNS server Client DNS recursive resolver hcmus.edu.vn DNS server slide 37
38. DNS Root Name Servers  Root name servers for top-level domains  Authoritative name servers for subdomains  Local name resolvers contact authoritative servers when they do not know a name Feb 6, 2007: DoS attack on root DNS servers slide 38
39. DNS Caching DNS responses are cached • Quick response for repeated translations • Other queries may reuse some parts of lookup – NS records for domains DNS negative queries are cached • Don’t have to repeat past mistakes – For example, misspellings Cached data periodically times out • Lifetime (TTL) of data controlled by owner of data • TTL passed with every record slide 39
40. Cached Lookup Example root & vn DNS server fit.hcmus.edu.vn edu.vn Local DNS server Client DNS recursive resolver hcmus.edu.vn DNS server slide 40
41. DNS “Authentication” Request contains random 16-bit TXID root & vn DNS server www.hcmus.edu.vn edu.vn Response accepted if TXID is the same Local DNS server Client DNS recursive Stays in cache for a long time (TTL) resolver hcmus.edu.vn DNS server slide 41
42. DNS Spoofing 6.6.6.6 Trick client into looking up host1.foo.com (how?) Guess TXID, host1.foo.com is at 6.6.6.6 Another guess, host1.foo.com is at 6.6.6.6 Another guess, host1.foo.com is at 6.6.6.6 host1.foo.com Local ns.foo.com Client resolver DNS server Several opportunities to win the race If attacker loses, has to wait until TTL expires but can try again with host2.foo.com, host3.foo.com, etc. slide 42
43. Exploiting Recursive Resolving [Kaminsky] 6.6.6.6 Trick client into looking up host1.foo.com Guessed TXID, very long TTL I don’t know where host1.foo.com is host2.foo.com Ask the authoritative server at ns2.foo.com It lives at 6.6.6.6 host1.foo.com Local ns.foo.com Client resolver DNS server If attacker wins, all future DNS requests will go to 6.6.6.6 The cache is now poisoned for a very long time! No need to win future races! slide 43
44. Kaminsky’s exploit 2008 Typical DNS query and response to unknown www.example.com slide 44
45. Bailiwick Checking, since 1997 This just means that any records that aren't in the same domain of the question are ignored. slide 45
46. Kaminsky’s exploit  asks for the IP address of doesnotexist.example.com  Attacker replies: slide 46
47. Pharming Many anti-phishing defenses rely on DNS Can bypass them by poisoning DNS cache and/or forging DNS responses • Browser: give me the address of www.paypal.com • Attacker: sure, it’s 6.6.6.6 (attacker-controlled site) Dynamic pharming • Provide bogus DNS mapping for a trusted server, trick user into downloading a malicious script • Force user to download content from the real server, temporarily provide correct DNS mapping • Malicious script and content have the same origin! slide 47
48. Solving the DNS Spoofing Problem Long TTL for legitimate responses • Does it really help? Randomize port in addition to TXID • 32 bits of randomness, makes it harder for attacker to guess TXID DNSSEC • Cryptographic authentication of host-address mappings slide 48
49. DNSSEC Goals: authentication 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) • Encryption 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) slide 49