1. Polytechnic University Attacks 1 Attacks & Hacker Tools r Reconnaissance r Network mapping r Port scanning r Sniffing Before talking about defenses, need to look at network from attacker’s perspective r IP address spoofing r Session hijacking r DoS r DDoS

2. Polytechnic University Attacks 2 Reconnaissance r “casing the joint” Let’s take a close look at: r Reconnaissance with whois r Reconnaissance with DNS r A few words about a Registrar: m Organization where you register a domain name m Verifies uniqueness of name m Enters domain name into various databases: whois & DNS

3. Polytechnic University Attacks 3 List of registrars from internic.net:

4. Polytechnic University Attacks 4 Whois databases r Input: domain name or company name r Output: registrar, whois server, dns server Some useful whois sites: r www.internic.net m For com, net and org top-level domains r www.allwhois.com m For country-code top-level domains, e.g., jp, fr Two steps r First find target’s registrar r Then whois target at registrar

5. Polytechnic University Attacks 5 Internic Whois: Target “kazaa”

6. Polytechnic University Attacks 6 Whois: next step Do whois at registrar, eg, register.com r Input: domain name, IP address, net administrator name r Output: m Names of people (administrator, billing contact) m Telephone numbers m E-mail addresses m Name servers and IP addresses

7. Polytechnic University Attacks 7 Whois at kazaa’s registrar

8. Polytechnic University Attacks 8 Reconnaissance: IP Ranges r ARIN: American Registry for Internet Numbers m Maintains whois database that includes IP address ranges in US r RIPE: Europe r APNIC: Asia

9. Polytechnic University Attacks 9 Query at ARIN

10. Polytechnic University Attacks 10 Why whois databases needs to be publicly available r If you’re under attack, can analyze source address of packets. r Can use whois database to obtain info about the domain from where the attack is coming. r Can inform admin that their systems are source of an attack

11. Polytechnic University Attacks 11 Reconnaissance: DNS database Let’s quickly review DNS: r distributed database implemented in hierarchy of many DNS servers Authoritative name server: r for a given domain (e.g., poly.edu), provides server name to IP address mappings for servers (Web, email, ftp, etc) in domain r Primary and secondary name server for reliability

12. Polytechnic University Attacks 12 Root DNS Servers Figure 2.18 Portion of the hierarchy of DNS servers com DNS servers org DNS serversedu DNS servers poly.edu DNS servers umass.edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers

13. Polytechnic University Attacks 13 DNS: queries requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server

14. Polytechnic University Attacks 14 DNS records DNS: distributed db storing resource records (RR) r Type=NS  name is domain (e.g. foo.com)  value is IP address of authoritative name server for this domain RR format: (name, value, type, ttl) r Type=A  name is hostname  value is IP address r Type=MX  value is name of mailserver associated with name

15. Polytechnic University Attacks 15 DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used Query and reply messages sent Over UDP on port 53

16. Polytechnic University Attacks 16 DNS: caching and updating records r once (any) DNS server learns mapping, it caches mapping m cache entries timeout (disappear) after some time

17. Polytechnic University Attacks 17 Interrogating DNS servers r Attacker first gets primary or secondary authoritative server for target organization using whois. r Attacker can then query the DNS by sending DNS query messages. r Tools (often available in Unix and Windows machines; also available at web sites): m nslookup m host m dig

18. Polytechnic University Attacks 18 nslookup Avaiable in most unix & Windows machines Get dialpad DNS server IP address from whois set type=any “get all”

19. Polytechnic University Attacks 19 Reconnaissance summary r Obtaining information from public databases: m whois databases Tool: web sites m DNS database Tool: nslookup r Defense m Keep to a minimum what you put in the public database: only what is necessary

20. Polytechnic University Attacks 20 Attacks & Hacker Tools r Reconnaissance r Network mapping r Port scanning r Sniffing Before talking about defenses, need to look at network from attacker’s perspective r IP address spoofing r Session hijacking r DoS r DDoS

21. Polytechnic University Attacks 21 Network mapping r Goal: Learn about a remote network Internal network Internet firewall? 121.27.2.1 121.27.2.4 121.27.2.16 attacker

22. Polytechnic University Attacks 22 Network mapping r Attacker uses ping sweeps to determine live hosts r Attacker uses port scans to determine live services r Attacker often uses traceroute to determine path to each host discovered during ping sweep. m Overlay results from traceroute to create an approximate network diagram

23. Polytechnic University Attacks 23 Traceroute 1 cs-gw (128.119.240.254) 1 ms 1 ms 2 ms 2 border1-rt-fa5-1-0.gw.umass.edu (128.119.3.145) 1 ms 1 ms 2 ms 3 cht-vbns.gw.umass.edu (128.119.3.130) 6 ms 5 ms 5 ms 4 jn1-at1-0-0-19.wor.vbns.net (204.147.132.129) 16 ms 11 ms 13 ms 5 jn1-so7-0-0-0.wae.vbns.net (204.147.136.136) 21 ms 18 ms 18 ms 6 abilene-vbns.abilene.ucaid.edu (198.32.11.9) 22 ms 18 ms 22 ms 7 nycm-wash.abilene.ucaid.edu (198.32.8.46) 22 ms 22 ms 22 ms 8 62.40.103.253 (62.40.103.253) 104 ms 109 ms 106 ms 9 de2-1.de1.de.geant.net (62.40.96.129) 109 ms 102 ms 104 ms 10 de.fr1.fr.geant.net (62.40.96.50) 113 ms 121 ms 114 ms 11 renater-gw.fr1.fr.geant.net (62.40.103.54) 112 ms 114 ms 112 ms 12 nio-n2.cssi.renater.fr (193.51.206.13) 111 ms 114 ms 116 ms 13 nice.cssi.renater.fr (195.220.98.102) 123 ms 125 ms 124 ms 14 r3t2-nice.cssi.renater.fr (195.220.98.110) 126 ms 126 ms 124 ms 15 eurecom-valbonne.r3t2.ft.net (193.48.50.54) 135 ms 128 ms 133 ms 16 194.214.211.25 (194.214.211.25) 126 ms 128 ms 126 ms 17 * * * 18 * * * 19 fantasia.eurecom.fr (193.55.113.142) 132 ms 128 ms 136 ms traceroute: gaia.cs.umass.edu to www.eurecom.fr Three delay measements from gaia.cs.umass.edu to cs-gw.cs.umass.edu * means no reponse (probe lost, router not replying) trans-oceanic link

24. Polytechnic University Attacks 24 Traceroute: How it works r Source sends UDP packets to target m Each to an unlikely port m 3 packets with the same TTL, then increments TTL r When router decrements TTL to 0, sends back to source ICMP packet m type 11, code 0, TTL expired r When target receives packet, sends back to source ICMP packet m type 3, code 0, destination port unreachable

25. Polytechnic University Attacks 25 Ping Sweep Ping r Recall ICMP messages are directly encapsulated in IP datagrams (protocol 1) r To ping a host: m send ICMP Echo Request (ICMP type 8) m Host responds with ICMP Echo Reply (type 0) r So let’s ping the entire IP address range m Use automated tool for this ping sweep r If firewall blocks ping packets: m Try sweeping with TCP SYN packets to port 80 m Or try sending UDP packets to possible ports

26. Polytechnic University Attacks 26 Port scanning r Now that we have a map with some hosts, let’s find out what ports are open on a target host r 65,535 TCP ports; 65,535 UDP ports m Web server: TCP port 80 m DNS server: UDP port 53 m Mail server: TCP port 25 r Port scanning tools can scan: m List of ports m Range of ports m All possible TCP and UDP ports r Attacker may scan a limited set of ports, to avoid detection

27. Polytechnic University Attacks 27 Interlude TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used Options (variable length) ACK: ACK # valid RST, SYN, FIN: connection estab (setup, teardown commands) counting by bytes of data (not segments!)

28. Polytechnic University Attacks 28 Interlude: TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ time simple telnet scenario

29. Polytechnic University Attacks 29 Interlude: TCP Connection Establishment Three way handshake: Step 1: client host sends TCP SYN segment to server m SYN=1, ACK=0 m specifies initial seq # m no data Step 2: server host receives SYN, replies with SYN-ACK segment m SYN=1, ACK=1 m server host allocates buffers m specifies server initial seq. # Step 3: client receives SYN-ACK, replies with ACK segment, which may contain data m SYN=0, ACK=1

30. Polytechnic University Attacks 30 TCP: Reset packet r If machine receives a TCP packet it is not expecting, it responds with TCP packet with RST bit set. m For example when no process is listening on destination port r For UDP, machine returns ICMP “port unreachable” instead

31. Polytechnic University Attacks 31 Nmap (1) r Extremely popular m usually run over linux m rich feature set, exploiting raw sockets m need root to use all features r Ping sweeping m over any range of IP addresses m with ICMP, SYN, ACK m OS determination r Port scanning m Over any range of ports m Almost any type of TCP, UDP packet r Source IP address spoofing m Decoy scanning r Packet fragmentation r Timing Options Excellent reference: Nmap man page

32. Polytechnic University Attacks 32 Nmap (2) Input: r nmap [Scan Type] [Options] r Default for port scanning: ports 1-1024 plus ports listed in nmap service file Output: r open ports: syn/ack returned; port is open r unfiltered ports: RST returned: port is closed but not blocked by firewall r filtered ports: nothing returned; port is blocked by firewall

33. Polytechnic University Attacks 33 Nmap (3): ping sweep Nmap –sP –v 116.27.38/24 r Sends ICMP echo request (ping) to 256 addresses r Can change options so that pings with SYNs, ACKs… r -sP = ping r -v = verbose

34. Polytechnic University Attacks 34 Nmap (4): polite port scan  nmap –sT -v target.com r Attempts to complete 3-way handshake with each target port r Sends SYN, waits for SYNACK, sends ACK, then sends FIN to close connection r If target port is closed, no SYNACK returned m Instead RST packet is typically returned r TCP connect scans are easy to detect m Target (e.g. Web server) may log completed connections m Gives away attacker’s IP address

35. Polytechnic University Attacks 35 Nmap (5) : TCP SYN port scan  nmap –sS -v target.com r Stealthier than polite scan r Send SYN, receive SYNACK, send RST m Send RST segment to avoid an accidental DoS attack r Stealthier: hosts do not record connection m But routers with logging enabled will record the SYN packet r Faster: don’t need to send FIN packet

36. Polytechnic University Attacks 36 Nmap (6): TCP ACK scans r Many filters (in firewalls and routers) only let internal systems hosts initiate TCP connections m Drop packets for which ACK=0 (ie SYN packet): no sessions initiated externally r To learn what ports are open through firewall, try an ACK scan (segments with ACK=1) ACK dest port 2031 ACK dest port 2032 RST I learned port 2032 is open through the firewall Internal Network firewall

37. Polytechnic University Attacks 37 Nmap (7): UDP port scans r UDP doesn’t have SYN, ACK, RST packets r nmap simply sends UDP packet to target port m ICMP Port Unreachable: interpret port closed m Nothing comes back: interpret port open False positives common

38. Polytechnic University Attacks 38 Nmap (8): Obscure source r Attacker can enter list of decoy source IP addresses into Nmap r For each packet it sends, Nmap also sends packets from decoy source IP addresses m For 4 decoy sources, send five packets r Attacker’s actual address must appear in at least one packet, to get a result r If there are 30 decoys, victim network will have to investigate 31 different sources!

39. Polytechnic University Attacks 39 Nmap (9): TCP stack fingerprinting r In addition to determining open ports, attacker wants to know OS on targeted machine: m exploit machine’s known vulnerabilities m sophisticated hacker may set up lab environment similar to target network r TCP implementations in different OSes respond differently to illegal combinations of TCP flag bits.

40. Polytechnic University Attacks 40 Nmap (10): Fingerprinting r Nmap sends m SYN to open port m NULL to open port (no flag bits set) m SYN/FIN/URG/PSH to open port m SYN to closed port m ACK to closed port m FIN/PSH/URG to closed port m UDP to closed port r Nmap includes a database of OS fingerprints for hundreds of platforms

41. Polytechnic University Attacks 41 Nmap (11): examples  nmap -v target.com m Scans all TCP default ports on target.com; verbose mode r nmap -sS -O target.com/24 m First pings addresses in target network to find hosts that are up. Then scans default ports at these hosts; stealth mode (doesn’t complete the connections); tries to determine OS running on each scanned host  nmap -sX -p 22,53,110,143 198.116.*.1-127 m Sends an Xmas tree scan to the first half of each of the 255 possible subnets in the 198.116/16. Testing whether the systems run ssh, DNS, pop3, or imap  nmap -v -p 80 *.*.2.3-5 m finds all web servers on machines with IP addresses ending in.2.3,.2.4, or.2.5

42. Polytechnic University Attacks 42 Defenses against network mapping r Filter using firewalls and packet-filtering capabilities of routers m Block incoming ICMP packets, except to the hosts that you want to be pingable m Filter Time Exceeded ICMP messages leaving your network r Close all unused ports r Scan your own systems to verify that unneeded ports are closed r Intrusion Detection Systems

43. Polytechnic University Attacks 43 Attacks & Hacker Tools r Reconnaissance r Network mapping r Port scanning r Sniffing Before talking about defenses, need to look at network from attacker’s perspective r IP address spoofing r Session hijacking r DoS r DDoS

44. Polytechnic University Attacks 44 Review of interconnection devices r Hubs r Switches r Routers

45. Polytechnic University Attacks 45 Hubs Hubs are essentially physical-layer repeaters: m bits coming from one link go out all other links m at the same rate m no frame buffering m no CSMA/CD at hub: adapters detect collisions m provides net management functionality twisted pair hub

46. Polytechnic University Attacks 46 Sniffing r Attacker is inside firewall r Requirements m Attacker’s host connected to shared medium m NIC should be in “promiscuous mode” processes all frames that come to NIC r Sniffer has two components m Capture m Packet analysis r Grab and file away: m userids and passwords m credit card numbers m secret e-mail conversations r Island hopping attack: m Take over single machine (eg virus) m Install sniffer, observe passwords, take over more machines, install sniffers

47. Polytechnic University Attacks 47 Passive sniffing r Easy to sniff: m 802.11 traffic m Ethernet traffic passing through a hub Any packets sent to hub is broadcast to all interfaces Not true for a switch m Cable modem traffic r Popular sniffers m Wireshark (saw this in CS 684) m tcpdump (for unix) m Snort (sniffing and intrusion detection)

48. Polytechnic University Attacks 48 Active Sniffing through a switch switch attacker victim How does attacker sniff packets sent to/from the victim? Have to get victim’s packets to attacker!

49. Polytechnic University Attacks 49 Sniffing through a switch: flooding switch memory approach Host sends flood of frames with random source MAC addresses m Switch’s forwarding table gets filled with bogus MAC addresses m When “good packet arrives,” dest MAC address not in switch memory m Switch broadcasts real packets to all links r Sniff all the broadcast packets

50. Polytechnic University Attacks 50 Defenses r Tie MAC addresses to switch ports m Available on high-end switches m Sophisticated configuration r Give priority to existing mappings m Only replace them when timeout expires

51. Polytechnic University Attacks 51 Sniffing through LAN: poison victim’s ARP table approach attacker outside world default router for LAN switch victim (1) Send fake ARP response, mapping router IP address to attacker’s MAC address (2) Victim sends traffic destined to outside world. Poisoned ARP table causes traffic to be sent to attacker (3) Packets are forwarded from attacker’s host to default router (0) Sniff all frames that arrive. Configure so that IP packets arriving from victim are forwarded to default router Idea: have client’s traffic diverted to attacker

52. Polytechnic University Attacks 52 Powerful sniffing tools r Dsniff and ettercap m Flooding switch memory m ARP poisoning m Poisoning DNS

53. Polytechnic University Attacks 53 Sniffing defenses r Encrypt data: IPsec, SSL, PGP, SSH r Get rid of hubs: complete migration to switched network r Use encryption for wireless and cable channels r Configure switches with MAC addresses m Turn off self learning m Eliminates flooding problem r Intrusion detection systems: m Lookout for large numbers of ARP replies r Honeypot m Create fake account and send password over network m Identify attacker when it uses the password

54. Polytechnic University Attacks 54 Attacks & Hacker Tools r Reconnaissance r Network mapping r Port scanning r Sniffing Before talking about defenses, need to look at network from attacker’s perspective r IP address spoofing r Session hijacking r DoS r DDoS

55. Polytechnic University Attacks 55 IP address spoofing (1) r Attacker doesn’t want actions traced back r Simply re-configure IP address in Windows or Unix. r Or enter spoofed address in an application m e.g., decoy packets with Nmap 212.68.212.7 145.13.145.67 SA: 36.220.9.59 DA: 212.68.212.7

56. Polytechnic University Attacks 56 IP address spoofing (2) r But attacker cannot interact with victim. m Unless attacker is on path between victim and spoofed address. 212.68.212.7 145.13.145.67 SA: 36.220.9.59 DA: 212.68.212.7 36.220.9.59 SA: 212.68.212.7 DA: 36.220.9.59 attacker victim

57. Polytechnic University IP spoofing with TCP? r Can an attacker make a TCP connection to server with a spoofed IP address? r Not easy: SYNACK and any subsequent packets sent to spoofed address. r If attacker can guess initial sequence number, can attempt to send commands m Send ACK with spoofed IP and correct seq #, say, one second after SYN r But TCP uses random initial sequence numbers. Attacks 57

58. Polytechnic University Attacks 58 Defense: Ingress filtering: access ISP 127.32.1.1 x Internet privately administered 222.22/16 127.32.1.1 x

59. Polytechnic University Attacks 59 Ingress Filtering: Upstream ISP (1) 12.12/24 34.34/24 56.56/24 78.78/24 BGP update: 12.12/24, 34.35/24 BGP update: 56.56/24, 78.78/24 regional ISP regional ISP tier-1 ISP

60. Polytechnic University Attacks 60 Ingress Filtering: Upstream ISP (2) 12.12/24 34.34/24 56.56/24 78.78/24 BGP update: 12.12/24, 34.34/24 BGP update: 56.56/24, 78.78/24 Filter all but 12.12/24 and 34.34/24 Filter all but 56.56/24 and 78.78/24

61. Polytechnic University Attacks 61 Ingress Filtering: Upstream ISP (3) 12.12/24 34.34/24 56.56/24 78.78/24 Filter all but 12.12/24 and 34.34/24 Filter all but 56.56/24 and 78.78/24 56.56.1.1 regional ISP regional ISP tier-1 ISP x

62. Polytechnic University Attacks 62 Ingress Filtering: Upstream ISP (3) 12.12/24 34.34/24 56.56/24 78.78/24 Filter all but 12.12/24 and 34.34/24 Filter all but 56.56/24 and 78.78/24 34.34.1.1 regional ISP regional ISP tier-1 ISP spoofed packet gets through!

63. Polytechnic University Attacks 63 Ingress filtering: summary r Effectiveness depends on widespread deployment at access ISPs r Deployment in upstream ISPs helps, but does not eliminate IP spoofing m Filtering can impact router forwarding perf r Even if universally deployed at access, hacker can still spoof another address in its access network 12.12/24 r See RFC 2827 “Network Ingress Filtering: Defeating DDoS”

64. Polytechnic University Attacks 64 Attacks & Hacker Tools r Reconnaissance r Network mapping r Port scanning r Sniffing Before talking about defenses, need to look at network from attacker’s perspective r IP address spoofing r Session hijacking r DoS r DDoS

65. Polytechnic University Attacks 65 Session hijacking r Take control of one side of a TCP connection r Marriage of sniffing and spoofing Alice telnet “hi, I’m Alice” Alice Bob Attacker

66. Polytechnic University Attacks 66 Session hijacking: The details r Attacker is on segment where traffic passes from Alice to Bob m Attacker sniffs packets m Sees TCP packets between Bob and Alice and their sequence numbers r Attacker jumps in, sending TCP packets to Bob; source IP address = Alice’s IP address m Bob now obeys commands sent by attacker, thinking they were sent by Alice r Principal defense: encyrption m Attacker does not have keys to encrypt and insert meaningful traffic

67. Polytechnic University Attacks 67 Session hijacking: limitation 3. “thanks bob” Alice Bob Attacker 1. weird ACK # for data never sent 2. to resync, Alice sends segment with correct seq # Bob is getting segments from attacker and Alice. Source IP address same, but seq #’s different. Bob likely drops connection. Attacker’s solution: Send unsolicited ARP replies to Alice and Bob with non-existent MAC addresses Overwrite IP-to-MAC ARP tables Alice’s segments will not reach Bob and vice-versa But attacker continues to hear Bob’s segments, communicates with Bob

68. Polytechnic University Attacks 68 Session Hijacking Tools: r Hunt m http://lin.fsid.cvut.cz/~kra/index.html http://lin.fsid.cvut.cz/~kra/index.html m Provides ARP poisoning r Netcat m General purpose widget m Very popular

69. Polytechnic University Attacks 69 Denial-of-Service r Vulnerability attack: m Send a few crafted messages to target app that has vulnerability m Malicious messages called the “exploit” m Remotely stopping or crashing services r Connection flooding m Overwhelming connection queue with SYN flood r Bandwidth flooding attack: m Overwhelming communications link with packets m Strength in flooding attack lies in volume rather than content Prevent access by legitimate users or stop critical system processes

70. Polytechnic University Attacks 70 DoS and DDoS r DoS: m source of attack small # of nodes m source IP typically spoofed r DDoS m From thousands of nodes m IP addresses often not spoofed r Good book: m Internet Denial of Service by J. Merkovic, D. Dittrich, P. Reiher, 2005

71. Polytechnic University Attacks 71 Interlude: IP datagram format ver length 32 bits data (variable length, typically a TCP or UDP segment) 16-bit identifier Internet checksum time to live 32 bit source IP address header length (bytes) max number remaining hops (decremented at each router) for fragmentation/ reassembly total datagram length (bytes) upper layer protocol to deliver payload to head. len type of service “type” of data flgs fragment offset upper layer 32 bit destination IP address Options (if any)

72. Polytechnic University Attacks 72 IP Fragmentation and Reassembly ID =x offset =0 fragflag =0 length =4000 ID =x offset =0 fragflag =1 length =1500 ID =x offset =185 fragflag =1 length =1500 ID =x offset =370 fragflag =0 length =1040 One large datagram becomes several smaller datagrams Example r 4000 byte datagram r MTU = 1500 bytes 1480 bytes in data field offset = 1480/8

73. Polytechnic University Attacks 73 DoS: examples of vulnerability attacks r Land: sends spoofed packet with source and dest address/port the same r Ping of death: sends oversized ping packet r Jolt2: sends a stream of fragments, none of which have offset of 0. Rebuilding consumes all processor capacity. r Teardrop, Newtear, Bonk, Syndrop: tools send overlapping segments, that is, fragment offsets incorrect. Patches fix the problem, but malformed packet attacks continue to be discovered.

74. Polytechnic University Attacks 74 Connection flooding: Overwhelming connection queue w/ SYN flood (1) r Recall client sends SYN packet with initial seq. number when initiating a connection. r TCP on server machine allocates memory on its connection queue, to track the status of the new half- open connection. r For each half-open connection, server waits for ACK segment, using a timeout that is often > 1 minute r Attack: Send many SYN packets, filling connection queue with half-open connections. m Can spoof source IP address! r When connection queue is exhausted, no new connections can be initiated by legit users. Need to know of open port on victim’s machine: Port scanning.

75. Polytechnic University Attacks 75 DoS: Overwhelming connection queue with SYN flood (2) victim attacker Alice SYNs with Source IP = Alice SYN-ACKs RST Connection queue freed up with RST segment amateur attack: Expert attack: Use multiple source IP addresses, each from unresponsive addresses.

76. Polytechnic University Attacks 76 SYN flood defense: SYN cookies (1) r When SYN segment arrives, host B calculates function (hash) based on: m Source and destination IP addresses and port numbers, and a secret number r Host B uses resulting “cookie” for its initial seq # (ISN) in SYNACK r Host B does not allocate anything to half-open connection: m Does not remember A’s ISN m Does not remember cookie Host A Host B SYN with ISN A SYN-ACK with ISN B = cookie

77. Polytechnic University Attacks 77 SYN flood defense: SYN cookies (2) If SYN is legitimate r Host A returns ACK r Host B computes same function, verifies function = ACK # in ACK segment r Host B creates socket for connection r Legit connection established without the need for half-open connections If SYN-flood attack with spoofed IP address r No ACK comes back to B for connection. r No problem: B is not waiting for an ACK What if Host A sends only ACK (no SYN)? r Will host B establish a connection?

78. Polytechnic University Attacks 78 Overwhelming link bandwidth with packets r Attack traffic can be made similar to legitimate traffic, hindering detection. r Flow of traffic must consume target’s bandwidth resources. m Attacker needs to engage more than one machine => DDoS r May be easier to get target to fill-up its upstream bandwidth: async access m Example: attacking BitTorrent seeds

79. Polytechnic University Attacks 79 Distributed DoS: DDos Internet attacker victim bot Attacker takes over many machines, called “bots”. Potential bots are machines with vulnerabilities. bot processes wait for command from attacker to flood a target

80. Polytechnic University Attacks 80 DDoS: Reflection attack attacker victim DNS server request reply Source IP = victim’s IP

81. Polytechnic University Attacks 81 DDoS: Reflection attack r Spoof source IP address = victim’s IP r Goal: generate lengthy or numerous replies for short requests: amplification m Without amplification: would it make sense? r January 2001 attack: m requests for large DNS record m generated 60-90 Mbps of traffic r Reflection attack can be also be done with Web and other services

82. Polytechnic University Attacks 82 DDoS Defenses r Don’t let your systems become bots m Keep systems patched up m Employ egress anti- spoof filtering on external router. r Filter dangerous packets m Vulnerability attacks m Intrusion prevention systems r Over-provisioning of resources m Abundant bandwidth m Large pool of servers m ISP needs abundant bandwidth too. m Multiple ISPs r Signature and anomaly detection and filtering m Upstream hopefully r Rate limiting m Limit # of packets sent from source to dest

83. Polytechnic University Attacks 83 DNS attacks r Reflector attack: already discussed m Leverage DNS for attacks on arbitrary targets r Denying DNS service m Stop DNS root servers m Stop top-level-domain servers (e.g..com domain) m Stop local (default name servers) r Use fake DNS replies to redirect user r Poisoning DNS: m Insert false resource records into various DNS caches m False records contain IP addresses operated by attackers

84. Polytechnic University Attacks 84 DDos DNS Attack Oct 21, 2002 r Ping packets sent from bots to the 13 DNS root servers. Goal: bandwidth flood servers r Minimal impact: m DNS caching m rate limiting at upstream routers: filter ping when they arrive at an excessive rate r During attack, some networks filtered pings; corresponding root servers remained up. r Root server attack is easy to defend: download root server database to local (default) name servers m Not much data in root server; changes infrequently r TLD servers are more volatile r Similar kind of attack in May 2004, Feb 2007

85. Polytechnic University Attacks 85 DNS attack: redirecting network attacker client local DNS server hub or WiFi 1 2 1.Client sends DNS query to its local DNS server; sniffed by attacker 2.Attacker responds with bogus DNS reply Issues: Must spoof IP address: set to local DNS server (easy) Must match reply ID with request ID (easy) May need to stop reply from the local DNS server (harder)

86. Polytechnic University Attacks 86 Poisoning DNS Cache (1) r Poisoning: Attempt to put bogus records into DNS name server caches m Bogus records could point to attacker nodes m Attacker nodes could phish r But unsolicited replies are not accepted at a name server. m Name servers use IDs in DNS messages to match replies to queries m So can’t just insert a record into a name server by sending a DNS reply message. r But can send a reply to a request.

87. Polytechnic University Attacks 87 Poisoning local DNS server (2) Local DNS Server (eg, Berkeley) Attacker in Australia: 17.32.8.9 1. DNS query poly.edu=? 3. DNS reply poly.edu= 17.32.8.9 2. iterative DNS queries authoritative DNS for poly.edu Goal: Put bogus IP address for poly.edu in local Berkeley DNS server 1) Attacker queries local DNS server 2) Local DNS makes iterative queries 3) Attacker waits for some time; sends a bogus reply, spoofing authoritative server for poly.edu.

88. Polytechnic University Attacks 88 Poisoning local DNS server (3) Poisoned local DNS server (eg, Berkeley) Attacker in Australia 17.32.8.9 1. DNS query ftp.poly.edu=? 2. DNS query ftp.poly.edu=? authoritative DNS for poly.edu DNS response can provide IP address of malicious server!

89. Polytechnic University Attacks 89 DNS Poisoning (4) r Issues: m Attacker needs to know sequence number in request message sent to upstream server Not easy! m Attacker may need to stop upstream name server from responding So that server under attack doesn’t get suspicious Ping of death, DoS, overflows, etc

90. Polytechnic University Attacks 90 DNS attacks: Summary r DNS is a critical component of the Internet infrastructure r But is surprisingly robust: m DDoS attacks against root servers have been largely unsuccessful m Poisoning and redirection attacks are difficult unless you can sniff DNS requests And even so, may need to stop DNS servers from replying r DNS can be leveraged for reflection attacks against non-DNS nodes

91. Polytechnic University Attacks 91 Attacks & Hacker Tools r Reconnaissance r Network mapping r Port scanning r Sniffing Before talking about defenses, need to look at network from attacker’s perspective r IP address spoofing r Session hijacking r DoS r DDoS