1 / 11

DNS as a Gatekeeper: Creating Lightweight Capabilities for Server Defense

DNS as a Gatekeeper: Creating Lightweight Capabilities for Server Defense. Curtis Taylor taylorcr@ornl.gov Craig Shue cshue@ ornl.gov. Outline. Automated Attacking Costs to Organizations Some Observations Our Approach Lightweight Capabilities Fast Flux Defense Future Directions.

dunn
Download Presentation

DNS as a Gatekeeper: Creating Lightweight Capabilities for Server Defense

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. DNS as a Gatekeeper: Creating Lightweight Capabilities for Server Defense Curtis Taylor taylorcr@ornl.gov Craig Shue cshue@ornl.gov

  2. Outline • Automated Attacking • Costs to Organizations • Some Observations • Our Approach • Lightweight Capabilities • Fast Flux Defense • Future Directions

  3. Automated Attacking • Attackers use others in attacks • Compromised machines form botnets • “Attacks” vary in goal, methodology • Reconnaissance • Footholds • Exfiltration • Exploitation • But most attacks are automated • Success rates may be low, but they make up for it in volume

  4. Example Attacks • SQL Injection • Harvesting email addresses for spam • Phishing • The use of deception in electronic communication to obtain unauthorized access • A symptom of system and network security improvements

  5. Organization Costs • Decreased credibility • Information exposure • Financial consequences • Billions lost a year • Identity theft • Business failure • Example: HBGary Federal

  6. Some Observations • Automated clients do not need host names • Mnemonic names for human convenience • Automated clients can skip DNS queries • Directly scan IP address space • Cache records beyond what is allowed • Share with other machines in a botnet • Humans likely play by the rules • Their browsers are standards compliant • “Illegal” caching does not really help them

  7. Associating Clients and Resolvers is Non-Trivial ISP DNS Resolver ORNL DNS Server DNS Reply ISP Network End User System ORNL Web Server DNS Query Web Query

  8. What does this motivate? • Some attackers are clearly skipping DNS, but a few still use it • Good users are unlikely to skip DNS steps • Can we use this knowledge to protect servers? • Make DNS a gatekeeper to the network • Failures to use DNS prevents access • But it still looks successful • Allow network providers know there is something awry with malicious clients

  9. Fast Flux Defense ISP DNS Resolver DNS Server DNS Reply Honey Pot Web Server Honey Pot Web Server Honey Pot Web Server Honey Pot Web Server End User System DNS Query Web Query Real Web Server Honey Pot Web Server Honey Pot Web Server

  10. Fast Flux Defense ISP DNS Resolver DNS Server Honey Pot Web Server Honey Pot Web Server Honey Pot Web Server Real Web Server End User System Web Query Honey Pot Web Server Honey Pot Web Server Honey Pot Web Server

  11. Future Directions • We are ready to test • Works with BIND9, Linux’s iptables, and uses libpcap to intercept DNS requests • Limited deployment on ORNL’s network

More Related