the domain name system
play

The Domain Name System Database that primarily maps IP addresses - PDF document

The Domain Name System Database that primarily maps IP addresses (147.188.192.42) to names (www.cs.bham.ac.uk) and viceversa Nice properties: distributed, coherent, reliable, autonomous, and hierarchical DNS namespace has tree


  1. The Domain Name System • Database that primarily maps IP addresses (147.188.192.42) to names (www.cs.bham.ac.uk) and viceversa – Nice properties: distributed, coherent, reliable, autonomous, and hierarchical • DNS namespace has tree structure TCP/IP: DNS – Domain is a node in this tree – All nodes except the root have labels (e.g., www) – Fully qualified name: nodes labels, bottom up, each followed by a dot • Nodes are grouped (clique) into zones (administrative boundaries) – Apex is called the “start of authority” Network Security – Bottom edges with other zones below them are “delegation points” – Bottom nodes with no other zones below them are “leaf nodes” Lecture 8 – Each zone is served by authority servers • Nodes store actual content in resource records (RRs) – RR: name, class, type, TTL, and data – Data can map IP to host name and viceversa – Data can specify the mail server for domain • More: P. Vixie, “DNS Complexity”, ACM Queue, 2007 Eike Ritter Network Security - Lecture 8 2 Domain hierarchy Mapping names to IPs and viceversa • Can a host name be mapped to many IP addresses? . (root) – Yes. For example, load balancing $ nslookup www.google.com Name: www.l.google.com Address: 209.85.143.99 Name: www.l.google.com uk Address: 209.85.143.104 arpa com net • Can an IP address be mapped to many domain names? – Yes. For example web hosting in-addr google lloydstsb co ac (Some) domains seen at 74.125.53.132: amomsrantings.blogspot.com, bloxee.blogspot.com, 147 culturadohashi.blogspot.com, ocedeloguxuf.blogspot.com, google bham opensocial.googleusercontent.com, www-blogger-, 188 ads.gmodules.com,, www.gmodules.com, … 192 ph cs – Tool: Passive DNS replication @ BFK 42 Eike Ritter Network Security - Lecture 8 3 Eike Ritter Network Security - Lecture 8 4 Servers Clients • Primary authoritative server • Often called “resolvers” – Authoritative for a zone • Most often they do not cache (“stub – Loads mappings from local configuration (file on disk) resolver”) • Secondary authoritative server – Backup • Rely on recursive service of their designated – Their zone data comes to them from primary servers full resolver via a zone transfer procedure $ cat /etc/resolv.conf • Recursive and caching server search cs.bham.ac.uk – Caches query results until their TTL expires nameserver 147.188.192.4 nameserver 147.188.192.8 – Implements the recursive algorithm needed to locate a RR • Tools: nslookup, dig, host Eike Ritter Network Security - Lecture 8 5 Eike Ritter Network Security - Lecture 8 6

  2. Queries Example $ dig google.com • Recursive • Specify the information ;; Got answer: requested (type of query) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34072 – Client asks the server to respond ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0 with either the requested resource − A: address of host record or error message if none − NS: authoritative name server for exists ;; QUESTION SECTION: domain ;google.com. IN A – If DNS server does not have the − CNAME: canonical name queried information, it queries − MX: mailer for host ;; ANSWER SECTION: other servers until it gets the google.com. 300 IN A 209.85.143.99 information (or the query fails) − TXT google.com. 300 IN A 209.85.143.104 Are identified by ID field (16 bits) • Iterative • – Client asks the server to respond • Can be done over UDP or TCP ;; AUTHORITY SECTION: with the best answer it can google.com. 172800 IN NS ns4.google.com. − Typically UDP; TCP for larger provide, given its cache or zone google.com. 172800 IN NS ns1.google.com. responses data google.com. 172800 IN NS ns2.google.com. – If DNS server does not have the google.com. 172800 IN NS ns3.google.com. queried information, it may respond with a referral to server ;; Query time: 21 msec that may have it ;; SERVER: 147.188.192.4#53(147.188.192.4) ;; WHEN: Wed Feb 2 18:29:31 2011 ;; MSG SIZE rcvd: 132 Eike Ritter Network Security - Lecture 8 7 Eike Ritter Network Security - Lecture 8 8 Example DNS query % dig +norecurse google.com ;; Got answer: 13:30:08.018705 IP 10.4.130.214.51103 > 147.188.128.102.53: 1313+ A? ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52597 google.com. (28) ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 13:30:08.047483 IP 147.188.128.102.53 > 10.4.130.214.51103: 1313 5/13/0 A 74.125.230.114, A 74.125.230.115, A 74.125.230.116, A 74.125.230.112, ;; QUESTION SECTION: A 74.125.230.113 (319) ;google.com. IN A ;; AUTHORITY SECTION: com. 172794 IN NS i.gtld-servers.net. com. 172794 IN NS e.gtld-servers.net. com. 172794 IN NS l.gtld-servers.net. com. 172794 IN NS c.gtld-servers.net. com. 172794 IN NS h.gtld-servers.net. com. 172794 IN NS d.gtld-servers.net. com. 172794 IN NS b.gtld-servers.net. com. 172794 IN NS g.gtld-servers.net. com. 172794 IN NS f.gtld-servers.net. com. 172794 IN NS a.gtld-servers.net. com. 172794 IN NS k.gtld-servers.net. com. 172794 IN NS j.gtld-servers.net. com. 172794 IN NS m.gtld-servers.net. Eike Ritter Network Security - Lecture 8 9 Eike Ritter Network Security - Lecture 8 10 DNS spoofing Defense: double reverse lookup server2.example.com ns1.example.com 172.16.48.2 • Given IP address I 1 , obtains the name N ns1.evil.com – Mapping is provided by name server responsible 2.-3. for I 1 , which may well be completely 1. untrustworthy Assumption: server1 trusts • Given N, obtain its address I 2 connection from .example.com – Mapping is provided by name server responsible 1) attacker connects to server1 from 6.6.6.6 Attacker: server1.example.com for N. In the scenario before, this name server is 2) server1 looks up the name 6.6.6.6 172.16.48.1 associated with 6.6.6.6 trusted 3) ns1.evil.com replies “server2.example.com” • Check if I 1 =I 2 4) Server1 grants access to attacker Eike Ritter Network Security - Lecture 8 11 Eike Ritter Network Security - Lecture 8 12

  3. DNS hijacking DNS hijacking • DNS does not provide any means of authentication A 74.125.230.115 • Racing against the queried named server it is A? google.com possible to provide a fake IP address/domain A 172.16.48.1 name mapping – Attacker could mount attack against client ns1.example.com – Attacker could mount attack against name server Victim: Attacker: • The attacker needs to set correctly the request ID 172.16.48.2 172.16.48.1 – Easy if attack done on the same LAN (sniffing) – Need to guess if done blindly Eike Ritter Network Security - Lecture 8 13 Eike Ritter Network Security - Lecture 8 14 DNS amplification attack DNS poisoning • Certain queries can cause large responses • Certain DNS implementations used to cache – TXT, ANY query anything contained in a DNS reply – Queries for “.” (root) • Malicious DNS server would return a reply with • Most typically, queries done over UDP • Do you see a problem here? additional answers that would poison the (remember smurf attacks?) victim’s cache • DNS amplification attack: – The attacker spoofs the source IP address to be the address of the victim – Query for foo.com answered with additional section – Sends these “expensive” queries to a large number of servers containing the IP address of bank.com – Servers will send the response to the victim, overloading it – Can you use it to bypass the double reverse lookup? • Defenses: – Don’t allow open recursive servers, that is recursive servers that respond • Solution: only accept additional information that queries from external clients is relative to the domain being queried (bailiwick – Respond to expensive queries from untrusted parties with shorter error messages (REFUSED answer, instead of providing the list of root servers) check) Eike Ritter Network Security - Lecture 8 15 Eike Ritter Network Security - Lecture 8 16 DNS poisoning Kaminsky attack A? google.com • Attacker forces recursive resolver • Technique to “speed up” the poisoning attack ID = 1234 to initiate a DNS query • Attacker sends query for 000001.bank.com ns.victim.com ns.google.com • As the resolver is waiting for • Recursive server recursively attempts to answer the query contacting answer from authority resolver, authoritative server of bank.com (ID = 1234) attacker forges answers • Attacker sends a number of spoofed responses (trying to guess the correct • Attacker needs to guess all the ID) with 2 parts: transactional elements used in – Answer for 000001.bank.com is arbitrary the victim’s query – Authority section that claims a malicious IP is the NS for the bank.com zone – Query ID • If the attacker guesses the ID and port number, Bailiwick check passes – Port number IN A google.com • If the attacker is unsuccessful, the correct answer (likely, NXDOMAIN) • If success, victim will store wrong 172.16.48.1 arrives first and is accepted IP-domain mapping ID = 1234 • But now attacker can simply try again, querying for 000002.bank.com • If attacker looses the race, he will – Attacker does not need to wait for TTL to expire have to wait until the correct response expires (TTL field) – Order of several days, typically Attacker 172.16.48.1 Eike Ritter Network Security - Lecture 8 17 Eike Ritter Network Security - Lecture 8 18

Recommend


More recommend