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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend