1 / 26

Understanding DNS Security Problems and Solutions

Explore DNS security, zone management, distributed databases, query protocols, troubleshooting tools, and more in this informative lecture. Learn about resolving name queries, caching records, distributed database storage, and DNS protocol messages. Troubleshoot DNS using tools like nslookup and dig.

dillardg
Download Presentation

Understanding DNS Security Problems and Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture A.3: DNS Security • Domain Name Service • Security Problems in DNS

  2. Domain: a subtree of a domain name space Zone: some part of the domain name space Name servers generally have complete information about a zone Distributed management thru delegation DNS name service

  3. Distributed database: no server has all name-to-IP address mappings local name servers: each ISP, company has local (default) name server host DNS query first goes to local name server authoritative name server: for a host: stores that host’s IP address, name can perform name/address translation for that host’s name DNS name servers root name server: • contacted by local name server that can not resolve name • contacts authoritative name server if name mapping not known • gets mapping • returns mapping to local name server •  dozen root name servers worldwide

  4. Resolver: queries the name server interpret the responses return result to user recursive query: puts burden of name resolution on contacted name server heavy load? iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu

  5. once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time update/notify mechanisms under design by IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html DNS: caching and updating records

  6. DNS: distributed db storing resource records (RR) 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) DNS records • Type=CNAME • name is an alias name for some “cannonical” (the real) name • value is cannonical name • Type=A • name is hostname • value is IP address • Type=MX • value is hostname of mailserver associated with name

  7. DNS protocol :queryand reply messages, both with same message format DNS protocol, messages msg header • identification: 16 bit # for query, reply to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative

  8. DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional info that supplements other sections

  9. Troubleshooting tools for DNS nslookup dig (domain information gopher) dig cic.ulsan.ac.kr ; looks up A records for ; cic.ulsan.ac.kr dig mail.ulsan.ac.kr mx ; looks up MX records for ; mail.ulsan.ac.kr dig @a.root-servers.net ns . ; queries a.root-servers.net ; for NS records for . domain DNS query

  10. First query: authoritative gslacks[pts/3]:~> dig www.cse.ucsc.edu ; <<>> DiG 8.2 <<>> www.cse.ucsc.edu ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.cse.ucsc.edu, type = A, class = IN ;; ANSWER SECTION: www.cse.ucsc.edu. 1D IN CNAME ftp.cse.ucsc.edu. ftp.cse.ucsc.edu. 1D IN A 128.114.48.173 ;; AUTHORITY SECTION: cse.ucsc.edu. 1D IN NS services.cse.ucsc.edu. cse.ucsc.edu. 1D IN NS fs1.cse.ucsc.edu. ;; ADDITIONAL SECTION: services.cse.ucsc.edu. 1D IN A 128.114.48.10 fs1.cse.ucsc.edu. 1D IN A 128.114.48.11 ;; Total query time: 89 msec ;; FROM: gslacks.cs.umass.edu to SERVER: default -- 128.119.240.1 ;; WHEN: Thu Apr 12 08:25:04 2001 ;; MSG SIZE sent: 34 rcvd: 153 qr: query packet aa: authoritative answer rd: recursion desired ra: recursion available

  11. Second query: cached gslacks[pts/3]:~> dig www.cse.ucsc.edu ; <<>> DiG 8.2 <<>> www.cse.ucsc.edu ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.cse.ucsc.edu, type = A, class = IN ;; ANSWER SECTION: www.cse.ucsc.edu. 23h59m57s IN CNAME ftp.cse.ucsc.edu. ftp.cse.ucsc.edu. 23h59m57s IN A 128.114.48.173 ;; AUTHORITY SECTION: cse.ucsc.edu. 15h54m19s IN NS services.cse.ucsc.edu. cse.ucsc.edu. 15h54m19s IN NS fs1.cse.ucsc.edu. ;; ADDITIONAL SECTION: services.cse.ucsc.edu. 15h54m19s IN A 128.114.48.10 fs1.cse.ucsc.edu. 15h54m19s IN A 128.114.48.11 ;; Total query time: 1 msec ;; FROM: gslacks.cs.umass.edu to SERVER: default -- 128.119.240.1 ;; WHEN: Thu Apr 12 08:25:07 2001

  12. Name servers for a zone Primary master name server: reads zone data from a file on its host Secondary master (slave) name server: gets zone data from another name server that is authoritative for the zone Zone transfer: When a slave name server starts up, it contacts its master server and pulls the zone data over Zone transfer

  13. Zone transfer to get a list of all machines in a domain > dig @192.168.1.85 dumb.target.jay axfr ; transfer zone dumb.target.jay from 192.168.1.85 ; <<>> DiG 8.2 <<>> @192.168.1.85 dumb.target.jay axfr ; (1 server found) $ORIGIN dumb.target.jay. @ 20H IN SOA ns1 hostmaster.dumb.target.jay ( 2000111001 ; serial 5H ; refresh 1H ; retry 4d4h ; expire 1D ) ; minimum 1H IN NS dumb.target.jay. 20H IN NS ns.dumb.target.jay. 20H IN NS ns.dumbs.isp. 20H IN A 192.168.1.85 1D IN HINFO "Pentium 133" "Red Hat 6.1" 1D IN MX 10 mail mail 1D IN A 192.168.1.2 really 1D IN A 192.168.1.20 1D IN TXT "Admin's Trusted Workstation" 1D IN HINFO "Athlon 850" "Red Hat 6.1" rather 1D IN A 192.168.1.15 1D IN HINFO "Pentium 266" "Mandrake 7.1" serious 1D IN CNAME extra extra 1D IN A 192.168.1.80 ns 1D IN A 192.168.1.30 r_g 1D IN A 192.168.1.68 roblimo 1D IN MX 10 r_g 1D IN A 192.168.1.44 tahara 1D IN A 192.168.1.27

  14. BIND • Be careful not announce what version of bind you are running when answering queries <- security by obscurity. • In unix, DNS is handled by the BIND package, and a program called “named” • Configuration of the daemon is kept in /etc/named.conf

  15. /etc/named.conf // Config file for caching only name server options { directory "/var/named"; version “hackerz must die” allow-transfer {192.154.1.30}; Your secondary server }; zone "." in { type hint; file "root.hints"; root name server hints }; zone “foobar.brian.edu” in { For converting from name to address type master file “pz/db.foobar.brian.edu” zone ”1.154.192.in-addr.arpa" in { For converting from address to name type master; file "pz/db.192.154.1"; }; More on this in a minute...

  16. dns.victim.com Result cached 2 3 4 1 user.victim.com 5 www.bank.com Normal Operation dns.hacker.com • Normally, DNS is resolved with an authoritative server. • (Not shown is lookup to .com root server) resolving www.bank.com

  17. DNS Cache Poisoning • URL spoofing attack: • register a similar name of someone you are attacking • e.g., www.ibn.com, … • Cache poisoning is a more sophisticated version of the same idea. • The two key ideas we will take advantage of are: • The query number (and reply id) are often predictable if you can learn earlier IDs. • DNS caches previous results

  18. foo.hacker.com dns.victim.com user.victim.com www.bank.com Old Version of the Attack dns.hacker.com • On older versions of BIND, replies that came in could include additional lookup information. • This additional lookup information would be stored for future use. • The next time a user from victim.com looks for the bank, it will be redirected to the hacker’s site. • All the hacker has to do is create a mock-up of the banks site to get passwords, etc. dns query: hacker.com? hacker.com=x.x.x.x www.bank.com=x.x.x.x result cached dns query: hacker.com?

  19. www.hacker.com dns.victim.com user.victim.com www.bank.com Old Version of the Attack dns.hacker.com • On older versions of BIND, replies that came in could include additional lookup information. • This additional lookup information would be stored for future use. • The next time a user from victim.com looks for the bank, it will be redirected to the hacker’s site. • All the hacker has to do is create a mock-up of the banks site to get passwords, etc. result cached

  20. More attacks • The old attack no longer work since BIND was patched to ignore additional information provided in the reply. • However, a more complex version of the attack still works.

  21. dns query: hacker.com? dns.hacker.com foo.hacker.com dns query: hacker.com? www.bank.com The Attack query id stored • The first step of the attack is to learn victim.com’s current query id number. • The simplest way to do that is to get the victim to query the attacker’s DNS machine. • A simple method is to query the victim’s (shown left) • Or, if victim.com sends its queries recursively through a 3rd dns machine, attack the 3rd machine. dns.victim.com user.victim.com

  22. dns query: hacker.com? dns.hacker.com foo.hacker.com dns query: hacker.com? www.bank.com The Attack query id stored • If the attack has queries sent to it’s own domain, that leaves a trace. • Smarter attackers will compromise some remote authoritative name server. • This querying can be repeated many times to get an idea of how the query ids change over time. dns.victim.com user.victim.com

  23. dns.hacker.com foo.hacker.com www.bank.com=x.x.x.x(correct query ID) dns query: bank.com? dns query: bank.com? www.bank.com The Attack query id stored • If the attack has queries sent to it’s own domain, that leaves a trace. • Smarter attackers will compromise some remote authoritative name server. • This querying can be repeated many times to get an idea of how the query ids change over time. result cached dns.victim.com user.victim.com

  24. www.hacker.com dns.victim.com user.victim.com www.bank.com The Attack dns.hacker.com • Just as before, the cached result is used to avoid performing an expensive DNS lookup. • The victim is directed towards hacker.com • Can do this to banks, newspapers, etc. result cached

  25. Defenses • New versions of BIND have harder to predict query IDs. • DNSSEC (RFC 2535) is a secure version of DNS with RSA signed DNS records. • You could use a secure connection to your bank. • Split-split defense: • One DNS server for resolving names for users inside your domain; this server doesn’t respond to outside queries at all. • Another separate DNS server is setup for responding to queries from outsiders. • The two never exchange information. Your users never are subject to poisoned information.

  26. Defenses in /etc/named.conf // Config file for caching only name server options { directory "/var/named"; version “hackerz must die” allow-transfer {192.154.1.30}; allow-query { any; }; allow-recursion { 192.154.1.0/24; }; }; zone “foobar.brian.edu” in { type master file “pz/db.foobar.brian.edu” allow-query { 192.154.1.0/24; } }; zone ”1.154.192.in-addr.arpa" in { type master; file "pz/db.192.154.1"; allow-query { 192.154.1.0/24; } }; Global access control list (ACL): Only this subnet can query us Zone specific ACL: take precedence over a global ACL

More Related