Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy...

24
Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc [email protected], [email protected] Internet 2 Members Meeting, 21 September 2005

Transcript of Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy...

Page 1: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Deploying Security for the Domain Name System

Securing the Infrastructure PanelAllison Mankin, Amy Friedlander

Shinkuro, Inc

[email protected], [email protected]

Internet 2 Members Meeting, 21 September 2005

Page 2: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Overview• Attacks via and against the DNS infrastructure are

increasing– Attacks are becoming costly and difficult to remedy

• A live one detected in March may be out there in your servers and forwarders. See http://isc.sans.org/presentations/dnspoisoning.php

– Trust in the Internet could decrease

• The DNSSEC protocol provides a key ingredient in the defense against these attacks

• DNSSEC is ready to deploy – Early service provider adopters have just begun– Higher education and research service providers have

historically worked at the technological forefront

Page 3: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Recent Progress• The DNSSEC standard has been published

– RFCs 4033, 4034 and 4035– This is very well tested, implemented in BIND

9.3.1

• The Swedish Registry (.SE ccTLD) and the RIPE reverse DNS Registry have deployed DNSSEC in production– Others are close– The Dutch registry (.NL) has stated 2006

Page 4: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Root• DNS database maps:– Name to IP address

www.dnssec-deployment.org = 63.241.136.206

– And many other mappings (mail servers, IPv6, reverse…)

• Data organized as tree structure:– Each zone is authoritative

for its own data– Minimal coordination between

zone operators

edu gov cctld

agencyschool acanother

library office

The Domain Name System

Page 5: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

DNS Look Up

Root Server TLD Server

"End" system

Zone Server

Local DNS Server

Other Servers

Important “Other” servers include:• ISP• Campus/Enterprise• GigaPoP• Public WLAN/hotel

Page 6: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

What Does DNSSEC Do?

• Provides an approach so DNS administrators and users can:– Validate that data they receive came from the

correct originator, i.e., Source Authenticity– Validate that data they receive is the data the

originator put into the DNS, i.e., Data Integrity

• Approach integrates with existing server infrastructure and user clients

Page 7: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Secure DNS Query and Response (simple case)

Local Server

End-user

myhost.example.com

myhost.example.com = 192.0.2.1Plus signature for myhost.example.com

Attacker can not forge this answer without the associated private key.

Root Server

com Server

example.com Server

Page 8: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Example of Signed Responsea.ns.se. 172800 IN A 192.36.144.107 a.ns.se. 172800 IN AAAA 2001:698:9:301::53

a.ns.se. 172800 IN RRSIG A 5 3 172800 20050919180951 ( 20050913070542 10217 se. vtnUJT0yBQNa4G6GfiMmv0lty8p5dDcfnnt8nryRRilm 1OoVnOIk93B6+UgdDu1FkmBe7VIJlyXtIyPA77y4q3+Z 6QA8s4C/AubUg5mpxxOnjFoQUeEaNRSCEcrDex5K9GW4 7uJbNbHnC3jra4jcVRdUJJUeaw2e/CUvJBz6bVo= ) a.ns.se. 172800 IN RRSIG AAAA 5 3 172800 20050919174432 ( 20050913070542 10217 se. ZRzot/TQl7YwOxZyhnKaKRobMHM8F8Sm/EI+7XScs5xA 8fx3Smtdoad/BGOIkjO29+3w6FXFpkSTbKjg6d6BoiCS GaomhQeMrkvSac4DtzuvODaibKKqArMPbYMFlNPC27L+

XxDdy9RVBN2UPllsi5Ft0My23FOgJYURjZknPHM= )

Check out ‘drill’ from Nlnet Labs

Page 9: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Attack Example

Local DNS server

User Laptop

dept.xyzz.edu A?

dept.xyzz.edu A A 128.9.128.127

xyzz edu

Attacker

dept.xyzz.edu A 192.0.2.1

Attacker’s response wins. Second response is dropped

dept.xyzz.edu

Page 10: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Root• DNSSEC provides for– Incremental adoption

anywhere in the hierarchy– Production use at early stages– Out-of-band distribution of

zone public keys– Pictured: the blue zones can

do DNSSEC among themselves

• Detect attacks against their communications

edu gov cctld

agencyschool acanother

library office

i2

Islands of Trust in DNSSEC

Page 11: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

End Systems’ Perspective - Early DNSSEC Deployment

Root Server TLD Server

"End" system

Zone Server

Local DNS Server

Cache Servers

• End systems are harmed by infrastructure attacks outside their frame of reference• DNSSEC initial deployment in service providers (mostly not in end systems) is effective• Transition of end systems and applications can follow

DNSSEC-capable

Page 12: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

A Roadmap for DNSSEC in Internet2

• Recognition of security needs for the DNS • Organization of an ad hoc group under way

– Towards a pilot project– Setting a timeframe for white paper

• Lead: Charles Yun

• DNSSEC Workshop scheduled for next Joint Techs meeting (Feb 2006, Albuquerque)– Followup on our Vancouver BoF– Intensive two-day set-up, tools, training

• DNSSEC• Also TSIG, secure dynamic DNS

Page 13: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Operational Guidelines Online• A number of guides (though not yet turn-key) are

out there now. A living map of these is coming up soon on our site: http://www.dnssec-deployment.org– http://csrc.nist.gov/publications/drafts/DRAFT-SP800-

81.pdf– http://www.ripe.net/disi/dnssec_howto/– draft-ietf-dnsop-dnssec-operational-practices-04.txt

• More are in the pipeline, including a hw/sw environment guide from .SE. See also – http://www.dnssec.org– http://www.nlnetlabs.nl/dnssec/– http://www.dnssec-tools.org

Page 14: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Acknowledgements

• Our work is supported under contract with U.S. Department of Homeland Security Science and Technology

• Much is owed to the DNSSEC Deployment Working Group

Page 15: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Background Slides

Page 16: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

DNS Names as Targets

• Organizations increasingly are under threats to their DNS names such as:– Hijacking – Phishing– Pharming

• DNS attack abetting or connected to phishing

• The names are also affected in mismatches and browser tricks aimed at unprepared users:– Names with international characters, like

www.pаypal.com– Name mismatch in e-commerce certificate

Page 17: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

www.robecodirect.nl

www.robecoadvies.nl

User Easily Misses DNS Name Mismatch

Page 18: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

DNS Attack Severity• Forged DNS data breaks most web applications

– Genuine web sites can appear to be replaced with a false site without ever touching the original site

– E-mail, b2b, backend applications can be re-routed or mis-delivered

– Logins can be compromised through man in the middle attacks leading to identity theft

• DNS attack tools are readily available on the Internet (e.g., dsniff, dnshijack) and they are FREE!

• These are real attacks with “investors” commissioning them for profit.

Page 19: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

On the Other Hand

• There are many bugs in software and other issues underlying each specific attack

• A protocol/infrastructure approach to DNS security is best:– Because it is infrastructural, it detects and

addresses attacks independent of software holes– New bugs and holes will always arise, but with

the right upfront work, the system is catching the attacks (and the bugs) before the damage mounts

Page 20: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

Recent Attacks: ISP Cache Poisoning

• DNS cache poisoning is an old problem but seems to continue unabated– Symantec products found to be vulnerable in

March 2005– Microsoft and BIND cache poisoning attacks in

April 2005– DNS bots in May 2005

• http://isc.sans.org/presentations/dnspoisoning.php

Page 21: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

ISP Cache Poisoning - in Essence

End-user

Query “bait” address

Valid reply, but false .com server address installed by in ISP server by bug

Destinations

Cache poisoning

Destinations serving Spyware, Spam or Other Malware

ISP Server

Attackers

Query any .com address

Install malware as well as receive valid reply (likely man-in-the middle too)

Page 22: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

ISP Cache Poisoning - Impacts

• Documented: three waves of attack; lucrative spam, spyware and click-for-pay outcomes were motives

• In addition, in just one of the site samples, hundreds of DNS names were poisoned, including– americanexpress.com, citicards.com, dhl-usa.com,

fedex.com, walmart.com, sabre.com– Many more (see report)– Any of these may have had man-in-the-middle attacks

such as stolen passwords or intercepted traffic– There is no public data

Page 23: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

DNS Security Summary

• Each DNS zone signs their data with their private key– Signing should be done with zone data preparation

• User queries are answered with:– the requested information– DNSSEC data for the requested information

• Users authenticate responses with trusted key(s)– At least one trusted public key is pre-configured– Validation done with pre-configured key or keys

learned via a sequence of queries to the DNS hierarchy• Enables and supports other security technologies

Page 24: Deploying Security for the Domain Name System Securing the Infrastructure Panel Allison Mankin, Amy Friedlander Shinkuro, Inc mankin@psg.commankin@psg.com,

DNSSEC Risk-Cost Points

• Attackers use DNS vectors to make money– Both the loss from the attack and the cost to the

infrastructure can be significant– Cost to attacker is low or nothing, gain is high

• Security always has costs– What is the risk-benefit?– Costs will include software, training,

performance, and administrative relationships to zone operators