1 / 26

Enhanced Secure DNS: A Defense Against DDOS Attacks

Enhanced Secure DNS: A Defense Against DDOS Attacks. by David B. Wilkinson University of Colorado at Colorado Springs November 26, 2003. DDOS - Distributed Denial of Service. DDOS attack - A flooding attack directed against one host by many computers across many networks

maureen-cashman
Download Presentation

Enhanced Secure DNS: A Defense Against DDOS Attacks

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. Enhanced Secure DNS:A Defense AgainstDDOS Attacks by David B. Wilkinson University of Colorado at Colorado Springs November 26, 2003

  2. DDOS - Distributed Denial of Service • DDOS attack - A flooding attack directed against one host by many computers across many networks • Attack consumes victim’s network bandwidth - site becomes very slow or is unavailable to users • Threat to Internet commerce: In early 2000, DDOS attacks shut down Yahoo, eBay, Amazon, CNN.com, E*Trade, Datek Online, Buy.com and the FBI website for up to a few hours, resulting in millions of dollars in lost revenue • October 2002: 13 root DNS servers attacked (unsuccessful, but ...)

  3. DDOS Attack Architecture Attacker ... Compromised systems Handler Handler Handler ... ... ... A A A A A A Packets sent to broadcast addresses of intermediate networks ... Replies to Victim A = Agent Victim

  4. Types of DDOS Attacks • SYN Flooding - The agents send out TCP SYN requests to the victim, but do not reply to the SYN-ACK. Large numbers of open connections quickly exhaust available memory [Skoudis 2002]. • Smurf Attack - Agents send to intermediate networks ICMP echo request (“ping”) packets that have source IP address of the victim; victim gets replies • Fraggle Attack - Flood of datagrams (again with source address of victim) sent to UDP echo port 7 of intermediate hosts; echoes all sent to victim • SYN-ACK Attack - TCP SYN packets sent to random servers on Internet; SYN-ACKs all go to victim

  5. One Possible Solution: “Safe Network Security Practices” • Egress Filtering - Check source addresses of all packets leaving a network; discard if illegitimate • Ingress Filtering - Check source addresses of all packets entering a network; discard packets with 127.0.0.1, 192.168.0.1, etc., as source address • Harden Computers - Close unnecessary ports (e.g., echo port #7); remove services vulnerable to overflow security exploit; install latest patches • Communicate risks of opening email attachments to employees

  6. Another Solution:Secure Collective Defense (SCOLD) • A network or consortium of participating entities that utilize new capabilities in the Domain Name System (DNS) software to keep an attacked member site available during the attack • New idea of “Intrusion Tolerance” - attacks will always happen so try to successfully work around them

  7. Detail of DDOS attack R DNS A R Net A A R DNS R A R Net B G Victim R A DNS R R A Net C A = Agent R = Router G = Gateway R R

  8. SCOLD System Foils DDOS Attack A = Agent AG = Alternate Gateway R = Router PS = Proxy Server G = Gateway 2 PS1 SCOLD Coordinator R A Net A R 1 A 3 R Blocked by IDS G Victim R A R Net B R A 14 Client DNS IP IP 5 6 PS2 AG 4 7 A 10 9 8 Net C R R 11 13 Victim DNS Server 12 PS3 R

  9. My task: Enhance DNS Software, BIND, to meet the needs of SCOLD Three important areas of change in DNS BIND version 9.2.2: • New program, nsreroute, that proxy server runs to send a DNS message to client DNS server • Enhancement of BIND server software for handling incoming nsreroute message. Includes using SSL for authentication between client DNS server and proxy server. • Enhancement of BIND server software for handling subsequent query for host in victim domain, including retrieval and caching of ALT data type

  10. New DNS Functionality 1) When victim detects attack, it issues alert to SCOLD coordinator, which tells proxy server to run nsreroute 2) nsreroute sends messages to all client DNS servers for each client in list of input 3) Client DNS server authenticates message sender 4) Upon successful authentication, client DNS server writes zone for victim’s domain to disk, adds new entry to server configuration file, and reloads zones 5) Client DNS server redirects next query for host in victim zone to victim DNS server through a SCOLD-aware proxy server via IP tunnel 6) Subsequent queries for same host use cached results from previous query

  11. How to implement this? • Use GNU GDB debugger, with DDD GUI, to trace BIND code • Use nsupdate client program written by the Internet Software Consortium (ISC) as a starting point for creating nsreroute • Use OpenSSL to implement SSL and public key cryptography for server/sender authentication • Add a new resource record, ALT (99), to refer to proxy server IP addresses

  12. New client program nsreroute From command line, run nsreroute input_file where input_file contains reroute client.clientnet1.com. victimDNSserver1.victimnet.com. victimDNSserver2.victimnet.com. <victim DNS1 address> <victim DNS2 address> <proxy server1 address> <proxy server2 address> … <proxy serverN address> reroute client.clientnet2.com. victimDNSserver1.victimnet.com. victimDNSserver2.victimnet.com. <victim DNS1 address> <victim DNS2 address> <proxy server1 address> <proxy server2 address> … <proxy serverN address> . . . reroute client.clientnetX.com. victimDNSserver1.victimnet.com. victimDNSserver2.victimnet.com. <victim DNS1 address> <victim DNS2 address> <proxy server1 address> <proxy server2 address> … <proxy serverN address>

  13. Step 1: nsreroute gets all authoritative DNS servers for client domain Example input: reroute client.clientnet.com. victimdns1.victimnet.com. victimdns2.victimnet.com. 128.198.60.190 128.198.60.191 202.40.60.81 144.85.20.14 162.112.11.72 DNS1 DNS2 (primary master name server) Authoritative DNS servers for clientnet.com Q: Want NS records for clientnet.com Proxy server A: DNS1, DNS2, DNS3 DNS3 Alert from victim

  14. Step 2: nsreroute sends message (“reroutemsg”) to each DNS server at DNS server’s port #53 DNS1 #53 TCP DNS2 (primary master name server) Authoritative DNS servers for clientnet.com #53 TCP Proxy server TCP #53 DNS3

  15. DNS Message Format Header Question Answers Authority Additional

  16. Basic reroutemsg structure reroutemsg opcode = 7 authority section = victim_dns victim_dns2 victimdns1.victimnet.com victimdns2.victimnet.com list = list = rdataset rdataset_proxy rdataset2 rdataset_proxy2 type = 1 type = 99 type = 1 type = 99 private1 = private1 = private1 = private1 = rdata_victim rdata_proxy[0] rdata_victim2 rdata_proxy2[0] 128.198.60.190 202.40.60.81 128.198.60.191 202.40.60.81 rdata_proxy[1] rdata_proxy2[1] 144.85.20.14 144.85.20.14 rdata_proxy[2] rdata_proxy2[2] 162.112.11.72 162.112.11.72

  17. Step 3: client DNS server authenticates proxy server via SSL over TCP using DNS server port #5300 • Exchange certificates • Proxy server verifies authenticity of DNS server cert. • DNS server verifies proxy server certificate AND checks if proxy cert. is on a list of approved senders #53 DNS1 TCP #5300 SSL DNS2 (primary master name server) #53 TCP Proxy server Authoritative DNS servers for clientnet.com #5300 SSL TCP #53 SSL DNS3 #5300

  18. Step 4: After successful authentication, DNS server creates new zone file (“db.victimnet.com”) for victimnet.com domain and loads it into memory: @ IN SOA clientdns.clientnet.com. root.clientnet.com. ( 1 ; Serial 3h ; Refresh after 3 hours 1h ; Retry after 1 hour 1w ; Expire after 1 week 1h ; Negative caching TTL of 1 hour ) IN NS victimdns1.victimnet.com. IN NS victimdns2.victimnet.com. victimdns1.victimnet.com. 86400 IN A 128.198.60.190 victimdns1.victimnet.com. 86400 IN ALT 202.40.60.81 86400 IN ALT 144.85.20.14 86400 IN ALT 162.112.11.72 victimdns2.victimnet.com. 86400 IN A 128.198.60.191 victimdns2.victimnet.com. 86400 IN ALT 202.40.60.81 86400 IN ALT 144.85.20.14 86400 IN ALT 162.112.11.72

  19. New behavior for client DNS server for handling query for victim domain Without rerouting zone, query goes to root Referral to closer DNS server Query eventually goes to victim’s flooded main gateway 1 2 . . . G 4 Victim DNS Server 3 Slow client.clientnet.com Q DNS Fast IP tunnel A c a IP tunnel PS AG With rerouting zone, query goes to an ALT address b (Set up IP tunnels) ALT = 202.40.60.81 G = Gateway AG = Alternate Gateway PS = Proxy Server SCOLD Coordinator

  20. Query also requires retrieval and caching of new ALT data type First query for victim after victim zone installed on client DNS server client.clientnet.com Q Q Q Victim DNS Server DNS . . . . . . A A A Answer contains ALT records included in victim DNS server message Cache ALT records Answer contains ALT records retrieved from zone database Subsequent queries for victim client.clientnet.com Q DNS Victim DNS Server A Answer contains ALT records retrieved from cache database Not needed

  21. Time (in seconds) for proxy server and client DNS server to process reroutemsg Trial Proxy Server Client DNS Server 1 2.97 2.55 2 2.36 2.22 3 2.33 2.17 4 2.30 2.16 5 2.38 2.15 6 2.33 2.15 7 2.29 2.17 8 2.35 2.15 9 2.31 2.19 10 2.29 2.19 Tproxy server = TNSlookup + Tsendingto client DNSTclientDNS = Tns_reroute_start() to reroutedone_action()

  22. Time (in seconds) for query for host in targetnet.csnet.uccs.edu zone. Client DNS server does not have victim’s zone. Trial Time root DNS server 1 0.62 “edu” DNS server 2 2.53 Q2 R2 3 2.41 Q1 R1 4 2.26 Q3 “uccs.edu”server 128.198.1.250 5 4.44 client DNS server 128.198.61.52 R3 6 14.50 Q4 “csnet.uccs.edu” server 128.198.60.194 7 0.28 Answer Q5 R4 8 0.45 9 4.40 “targetnet.csnet.uccs.edu” server 128.198.60.190 10 12.32 Q = Query R = Referral

  23. Time (in seconds) for query for host in victim zone. Client DNS server has victim’s reroute zone. Trial Time 1 0.33 Client DNS server 128.198.61.52 2 0.29 3 0.15 4 0.13 Answer Query 5 0.22 6 0.22 7 0.22 “targetnet.csnet.uccs.edu” server 128.198.60.190 8 0.22 9 0.14 10 0.22

  24. Lessons Learned • Understanding ISC’s BIND code • Tracing named daemon process • must attach to process, not run process • Default timeouts hamper tracing • “Clock skew” problems • made installation take much longer than necessary • interfered with authentication • corrected with ntpdate function in crontab file • Result of caching “NS 128.198.60.194” • subsequent queries to gandalf failed • Trying to fork in server • Problems with reliability of my authentication code • In the end, everything works correctly, every time

  25. Future Work • Perform more comprehensive tests involving other aspects of DNS (TSIG, DNSSEC, DNS dynamic update, using different views, using other kinds of data types, etc.) • Try to reduce connection time between reroutemsg sender and client DNS server • Fork in client DNS server • Implement incremental zone reloading • Send reroutemsg to only SOA server and then do zone transfer to other DNS servers; compare total elapsed times

  26. Conclusions New Enhanced BIND v. 9.2.2 has some great features: • nsreroute program that remotely installs victim zones on client DNS machines • New zones help clients communicate with another member of the SCOLD consortium that is under attack • Intrusion tolerance works • New ALT data type results in faster queries over multiple dynamic paths • Multiple-path routing capability results in larger aggregate bandwidth for the server

More Related