tcp/ip: dns - cs.bham.ac.ukexr/lectures/networksecurity/11_12/slides/08_t… · the domain name...
TRANSCRIPT
TCP/IP: DNS
Network Security
Lecture 8
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– 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”
– Bottom edges with other zones below them are “delegation points”
– Bottom nodes with no other zones below them are “leaf nodes”
– 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, 2007Eike Ritter Network Security - Lecture 8 2
Domain hierarchy
Eike Ritter Network Security - Lecture 8 3
.
com net uk
google acco
google bham
csph
lloydstsb
arpa
in-addr
147
188
192
42
(root)
Mapping names to IPs and viceversa
• Can a host name be mapped to many IP addresses?– Yes. For example, load balancing
$ nslookup www.google.comName:www.l.google.comAddress: 209.85.143.99Name:www.l.google.comAddress: 209.85.143.104
• Can an IP address be mapped to many domain names?– Yes. For example web hosting
(Some) domains seen at 74.125.53.132:amomsrantings.blogspot.com, bloxee.blogspot.com, culturadohashi.blogspot.com, ocedeloguxuf.blogspot.com, opensocial.googleusercontent.com, www-blogger-, ads.gmodules.com,, www.gmodules.com, …
– Tool: Passive DNS replication @ BFK
Eike Ritter Network Security - Lecture 8 4
Servers
• Primary authoritative server– Authoritative for a zone
– Loads mappings from local configuration (file on disk)
• Secondary authoritative server– Backup
– Their zone data comes to them from primary servers via a zone transfer procedure
• Recursive and caching server– Caches query results until their TTL expires
– Implements the recursive algorithm needed to locate a RR
Eike Ritter Network Security - Lecture 8 5
Clients
• Often called “resolvers”
• Most often they do not cache (“stub
resolver”)
• Rely on recursive service of their designated
full resolver
• Tools: nslookup, dig, host
Eike Ritter Network Security - Lecture 8 6
$ cat /etc/resolv.conf
search cs.bham.ac.uk
nameserver 147.188.192.4
nameserver 147.188.192.8
Queries
• Recursive– Client asks the server to respond
with either the requested resource record or error message if none exists
– If DNS server does not have the queried information, it queries other servers until it gets the information (or the query fails)
• Iterative– Client asks the server to respond
with the best answer it can provide, given its cache or zone data
– If DNS server does not have the queried information, it may respond with a referral to server that may have it
• Specify the information requested (type of query)− A: address of host
− NS: authoritative name server for domain
− CNAME: canonical name
− MX: mailer for host
− TXT
• Are identified by ID field (16 bits)
• Can be done over UDP or TCP− Typically UDP; TCP for larger
responses
Eike Ritter Network Security - Lecture 8 7
Example
Eike Ritter Network Security - Lecture 8 8
$ dig google.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34072
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 209.85.143.99
google.com. 300 IN A 209.85.143.104
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns4.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns3.google.com.
;; Query time: 21 msec
;; SERVER: 147.188.192.4#53(147.188.192.4)
;; WHEN: Wed Feb 2 18:29:31 2011
;; MSG SIZE rcvd: 132
Example
Eike Ritter Network Security - Lecture 8 9
% dig +norecurse google.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52597
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;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.
DNS query
Eike Ritter Network Security - Lecture 8 10
13:30:08.018705 IP 10.4.130.214.51103 > 147.188.128.102.53: 1313+ A?
google.com. (28)
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,
A 74.125.230.113 (319)
DNS spoofing
Eike Ritter Network Security - Lecture 8 11
server1.example.com
172.16.48.1
Attacker:
6.6.6.6
server2.example.com
172.16.48.2
ns1.evil.com
ns1.example.com
Assumption: server1 trusts
connection from
.example.com
1) attacker connects to server1
from 6.6.6.6
2) server1 looks up the name
associated with 6.6.6.6
3) ns1.evil.com replies
“server2.example.com”
4) Server1 grants access to
attacker
1.
2.-3.
Defense: double reverse lookup
• Given IP address I1, obtains the name N
– Mapping is provided by name server responsible
for I1, which may well be completely
untrustworthy
• Given N, obtain its address I2
– Mapping is provided by name server responsible
for N. In the scenario before, this name server is
trusted
• Check if I1 = I2
Eike Ritter Network Security - Lecture 8 12
DNS hijacking
• DNS does not provide any means of authentication
• Racing against the queried named server it is possible to provide a fake IP address/domain name mapping
– Attacker could mount attack against client
– Attacker could mount attack against name server
• The attacker needs to set correctly the request ID
– Easy if attack done on the same LAN (sniffing)
– Need to guess if done blindly
Eike Ritter Network Security - Lecture 8 13
DNS hijacking
Eike Ritter Network Security - Lecture 8 14
ns1.example.com
Victim:
172.16.48.2
Attacker:
172.16.48.1
A? google.com
A 74.125.230.115
A 172.16.48.1
DNS amplification attack
• Certain queries can cause large responses– TXT, ANY query
– Queries for “.” (root)
• Most typically, queries done over UDP
• Do you see a problem here?(remember smurf attacks?)
• DNS amplification attack:– The attacker spoofs the source IP address to be the address of the victim
– Sends these “expensive” queries to a large number of servers
– Servers will send the response to the victim, overloading it
• Defenses:– Don’t allow open recursive servers, that is recursive servers that respond
queries from external clients
– Respond to expensive queries from untrusted parties with shorter error messages (REFUSED answer, instead of providing the list of root servers)
Eike Ritter Network Security - Lecture 8 15
DNS poisoning
• Certain DNS implementations used to cache anything contained in a DNS reply
• Malicious DNS server would return a reply with additional answers that would poison the victim’s cache– Query for foo.com answered with additional section
containing the IP address of bank.com
– Can you use it to bypass the double reverse lookup?
• Solution: only accept additional information that is relative to the domain being queried (bailiwick check)
Eike Ritter Network Security - Lecture 8 16
DNS poisoning
• Attacker forces recursive resolver to initiate a DNS query
• As the resolver is waiting for answer from authority resolver, attacker forges answers
• Attacker needs to guess all the transactional elements used in the victim’s query– Query ID
– Port number
• If success, victim will store wrong IP-domain mapping
• If attacker looses the race, he will have to wait until the correct response expires (TTL field)– Order of several days, typically
Eike Ritter Network Security - Lecture 8 17
A? google.comID = 1234
ns.victim.com ns.google.com
IN A google.com172.16.48.1ID = 1234
Attacker172.16.48.1
Kaminsky attack
• Technique to “speed up” the poisoning attack
• Attacker sends query for 000001.bank.com
• Recursive server recursively attempts to answer the query contacting authoritative server of bank.com (ID = 1234)
• Attacker sends a number of spoofed responses (trying to guess the correct ID) with 2 parts:– Answer for 000001.bank.com is arbitrary
– Authority section that claims a malicious IP is the NS for the bank.com zone
• If the attacker guesses the ID and port number, Bailiwick check passes
• If the attacker is unsuccessful, the correct answer (likely, NXDOMAIN) arrives first and is accepted
• But now attacker can simply try again, querying for 000002.bank.com – Attacker does not need to wait for TTL to expire
Eike Ritter Network Security - Lecture 8 18
TCP/IP RECAP
In form of a quiz
Eike Ritter Network Security - Lecture 8 19
PGP
• Alice signs a message as follows:$ gpg –s –a msg.txtand sends it to Bob via regular email
• What security properties are guaranteed?
– Integrity?
– Confidentiality?
– Authenticity?
• Would anything change if Alice signed the message in binary format, i.e., without using the –a flag?
Eike Ritter Network Security - Lecture 8 20
IP addresses
• Looking at logs of network traffic of the School web server (147.188.192.42), you notice a bunch of ICMP echo messages directed to it. They all have the source IP address set to 192.168.1.1.What do you do?
– Look up the IP to notify the admin of the corresponding network
– Drink another coffee: there’s nothing you can do
– Filter packets from reserved network addresses
Eike Ritter Network Security - Lecture 8 21
IP
Eike Ritter Network Security - Lecture 8 22
C:
172.16.48.3
00:11:22:33:44:03
A:
172.16.48.2
00:11:22:33:44:02
B:
172.16.48.1
00:11:22:33:44:01
Src IP: ?, Dst IP: ?
Src ether: ?; Dst ether: ?
You’re monitoring traffic between A and C. What are the values of IPdatagrams that you expect?
libpcap
• Our forensic team just recovered the
following snippet of code from the hard disk
of the old administrator. What was the
purpose of the code (port 23 is the telnet
port)?
#!/bin/bash
tcpdump –i eth0 –s0 port 23 –w dump.pcap
Eike Ritter Network Security - Lecture 8 23
IP options
• Briefly explain why most routers drop IP
packets with the IP source routing option
Eike Ritter Network Security - Lecture 8 24
Scanning
• Briefly explain the traffic found in the
following trace
Eike Ritter Network Security - Lecture 8 25
12:31:38.707533 ARP, Request who-has 172.16.48.130 tell 172.16.48.139, length 2812:31:38.708077 ARP, Reply 172.16.48.130 is-at 00:0c:29:27:25:40, length 4612:31:38.708083 IP 172.16.48.139.39844 > 172.16.48.130.80: tcp 012:31:38.708116 IP 172.16.48.139.60408 > 172.16.48.130.443: tcp 012:31:38.708567 IP 172.16.48.130.80 > 172.16.48.139.39844: tcp 012:31:38.708582 IP 172.16.48.139.39844 > 172.16.48.130.80: tcp 012:31:38.708615 IP 172.16.48.130.443 > 172.16.48.139.60408: tcp 012:31:38.708806 IP 172.16.48.139.39844 > 172.16.48.130.80: tcp 0
TCP
• You have been hired to implement the TCP/IP
stack in the new iPosh. You are tired of
reading RFCs and decide that for picking Initial
Sequence Numbers you will use the following
formula:ISN = # packets sent + src_port + src_ip + dst_port + dst_ip
• Is this a good idea?
Eike Ritter Network Security - Lecture 8 26
TCP
• You are studying the ISN generator of the iPosh2 and you derive the following graph. What is your onclusionon the security of the device?
Eike Ritter Network Security - Lecture 8 27
DNS
• You are monitoring queries to your DNS
server, when you notice the following series
of queries:
A? asdasdsa.example.com
A? gdfgfoger.example.com
A? p34339ds.example.com
A? p03jsdss.example.com
• What is your analysis?
Eike Ritter Network Security - Lecture 8 28