Internet Infrastructure Protection

May 23, 2006Steve Crocker, steve@shinkuro.com

ICANN Security and Stability Committee

Shinkuro, Inc.

2

My Primary Message

Build security into the infrastructure Good architecture is cheaper and better than chasing the bad guys It’s less sexy but more effective

CERTs, Firewalls, Honeynets, etc. are all good

Networking the security community is good

Do all of this, but also invest in the architecture

3

Latin America has unique opportunity

Plenty of technical talent Networks are still in a growth stage

Not as much legacy as North America, Europe

Good communication, cooperation

Opportunity to leap ahead

4

Incidents Reported to CERT/CC

5

Vulnerabilities Reported to CERT/CC

6

Attack Sophistication vs. Intruder Knowledge

email propagation of malicious code

“stealth”/advanced scanning techniques

widespread attacks using NNTP to distribute attack

widespread attacks on DNS infrastructure

executable code attacks (against browsers)

automated widespread attacks

GUI intruder tools

hijacking sessions

Internet social engineering attacks

packet spoofingautomated probes/scans

widespread denial-of-service

attacks

techniques to analyze code for vulnerabilitieswithout source code

DDoS attacks

increase in worms

sophisticated command & control

anti-forensic techniques

home users targeted

distributed attack tools

increase in wide-scale Trojan horse distribution

Windows-based remote controllable

Trojans (Back Orifice)

Intruder Knowledge

Att

ack

So

ph

isti

cati

on

1990 2004

7

Internet Infrastructure Threats

1. Physical disruption of major lines and switching centers

2. Loss of DNS service continuity and/or fidelity

3. Loss of routing infrastructure continuity and/or fidelity

4. Flooding of network or specific sites, i.e. denial of service attack

8

Internet Infrastructure

Protection

DNSSEC Address Security DDoS suppression

DNSSEC Deployment

Segments

Demo DNS & DNSSEC basics Deployment Issues Opportunity!

Hijack Demo

Connect to BADNET network We will intercept your queries…

DNSSEC Basics

Slides from RIPE NCC

13

Why DNSSEC? DNS is not secure

Known vulnerabilities People depend more and more on DNS

DNSSEC protects against data spoofing and corruption

14

DNS: Known Concepts

Known DNS concepts: Delegation, Referral, Zone, RRs, label, RDATA, authoritative server, caching forwarder, stub and full resolver, SOA parameters, etc

Reminder: DNS Resolving

Resolver

Question:

www.ripe.net A

www.ripe.net A ?

Cachingforwarder(recursive)

root-serverwww.ripe.net A ?

“go ask net server @ X.gtld-servers.net” (+ glue)

gtld-serverwww.ripe.net A ?

“go ask ripe server @ ns.ripe.net” (+ glue)

ripe-server

www.ripe.net A ?

“193.0.0.203”

193.0.0.203

1 2

3

4

5

6

7

Add to cache9

8

10 TTL

DNS: Data Flow

master Caching forwarder

resolver

Zone administrator

Zone file

Dynamicupdates

1

2

slaves

3

4

5

DNS Vulnerabilities

master Caching forwarder

resolver

Zone administrator

Zone file

Dynamicupdates

1

2

slaves

3

Server protection

4

5

Corrupting data Impersonating master

Unauthorized updates

Cache impersonation

Cache pollution byData spoofing

Data protection

Altered zone data

18

DNSSEC protects..

DNSSEC protects against data spoofing and corruption

DNSKEY/RRSIG/NSEC: provides mechanisms to establish authenticity and integrity of data

DS: provides a mechanism to delegate trust to public keys of third parties

A secure DNS will be used as an infrastructure with public keys However it is NOT a PKI

19

DNSSEC Current State

RFC 4033 DNS Security Introduction and Requirements

RFC 4034 Resource Records for the DNS Security Extensions

RFC 4035 Protocol Modifications for the DNS Security Extensions

March 2005 Obsoletes RFC 2535

20

DNSSEC hypersummary

Data authenticity and integrity by signing the Resource Records Sets

Public DNSKEYs used to verify the RRSIGs

Children sign their zones with their private key Authenticity of that key established by signature/checksum by the parent (DS)

Ideal case: one public DNSKEY distributed

Deployment Issues

Getting the Root Signed Getting TLDs Signed Getting Enterprises Signed Resolvers Applications

Key Generation

Key Distribution

Root

Signing

Serving Signed Root

TLD Key Acquisition

Serving Signed

Root with TLD Keys

A B

C

FE

D

Root Signing Road Map

Getting TLDs Signed -- Issues

Current Status Zone Walking Zone Size

TLD Zone Status

.SE (Sweden) is signed and operational

RIPE’s portion of in-addr.arpa is signed

.ORG, .COM and .NET have test beds

More coming

Zone Walking NSEC (“Next Secure”) makes it possible to “walk the zone” to find all entries

Some (many?) TLD operators object NSEC3, using hashes, solves this problem

NSEC3 design is done(?) Shakedown workshop at DENIC in early May Good progress. Further testing and documentation needed

Zone Size Memory requirements expand three to five times for a fully signed zone

Significant impact on large zones -- COM, NET, ORG, DE, UK, …

Current design requires one NSEC record for every delegation, even if it’s not signed

“Opt-in” requires NSEC (or NSEC3) record only for signed zones (Some call this “opt-out”. Same thing.)

Slightly different but equivalent security Much lower initial impact Opt-in is coming with NSEC3

Getting Enterprises Signed

In house operation Outsourced operation

In House Operation

Software Possible hardware Operations Policies

Key lifetimes, management chain Procedures, Training Become a founding operator…

Outsourced Operation Many enterprises outsource DNS service Registrars, hosting services Managed DNS Service Providers

UltraDNS, VeriSign, Akamai, Netriplex, Infoblox, EasyDNS, DNS Made Easy

DNS Service Providers can add DNSSEC with zero imposition on domain name holder

Except perhaps for a charge DNS Service Providers will be the source of many signed zones

Opportunity! Meanwhile, in the short run, it’s up to us.

Be a DNSSEC founding operator Sign your zone Be the primary for others Be a secondary

Tuesday we will announce a small directory of primary and secondary signer/operators

http://www.dnssec-deployment.org/zones Sign up. Talk to us today. Send email.

31

DNSSEC Deployment is…

… the transition from specs to operation

… a multinational effort … a complex process … a project that needs your help

32

Organizational Matters

Pockets of expertise Sweden, Netherlands, U.S., Japan

Active test bed and deployment in a few places

Deployment Working Group active

33

What’s Needed

Local efforts in each country Regional cooperation for training, etc.

Awareness campaigns Testing Application development

34

Government Role(s)

Awareness, motivation Prioritization – protect critical infrastructure

Funding of key local activities

Participation in global forum Adoption and leadership internally

Contacts & Resources steve.shinkuro.com www.dnssec-deployment.org Slides and other DNSSEC material at: www.ripe.net/training/dnssec/

http://www.nlnetlabs.nl/dnssec/ http://www.dnssec.net/

=====================================Support provided by U.S. Dept. of Homeland Security, Science and Technology Directorate

Cooperative work with Sparta, NIST, MIT Lincoln Laboratory

36

Acknowledgements

Olaf Kolkman, RIPE Edward Lewis, NeuLevel

The Whole DNSSEC Deployment Working Group

Address Validation

38

Address Validation is Essential

Address spoofing is a key component of multiple attacks

Must check at ingress Every ISP must do this

39

What is Address Validation? Does the source address belong to this customer?

Requires knowing authorized source addresses Same as destination addresses

Requires checking Adds cost, hardware Do it anyway

Insist your peers do it too

40

Suppression of Distributed Denial of Service (DDoS) Attacks

41

The Denial of Service Problem

Denial of service attacks are increasing This will get worse – probably much worse

Law enforcement is important but necessarily at the wrong end of the problem

Technical changes in the Internet would help a lot

42

A modest(?) proposal for controlling DDoS Attacks

Identify sources of traffic Identify “well managed” computers on “well managed” networks

Traffic from well managed networks gets preference

43

“Well managed” “Well managed” computers aren’t zombies Details on the next slide

Well managed networks quarantine computers which appear to be infected or misbehaving

Well managed networks report misbehaviors and accept reports of misbehaviors

44

Weeding out Zombies

Regular configuration checking Either within the enterprise Or by an outside service

Tight configuration control (Eventually) certified appliances

45

Network Wide Cooperation Traffic among well managed networks gets preference Traffic from same sites is labeled with a “good” bit

Eerily similar to Bellovin’s “evil” bit(!)

When there is congestion, traffic from unmanaged hosts on unmanaged networks is dropped

How is traffic labeled? Diffserv? IP header bit? MPLS? Other?

46

DDoS Policy ApproachesPressure on the vendor to supply machines that are safe out of the boxEstablishment of an ethic that machines should be safe, i.e. it’s the vendor’s problem, not the user’s.

This all requires R&D, clarity of vision, and perseverance. Not an overnight process.

47

Arguments in Favor Similar to VPN over private lines, but potentially more efficient

Adds incentive to improve security in hosts and networks

Raises DDoS protection to a primary goal Incremental – works well with a small set of core ISPs and expands smoothly

Robust – does not require 100% correct operation

Failures can be detected; adjustments can be made

48

Critique Sharp shift in policy Requires strong cooperation among ISPs Who sets the rules?

Enforcement issues Who determines when an ISP or a customer isn’t complying?

What appeals process? Efficiency issue for large ISPs: Is it feasible to filter traffic at high speed?

Shinkuro Overview

50

Working Together? Why is so hard to work closely together over the net?

Email and Instant Messaging… Is that all there is?

Need flexible, easily configurable, user-controlled file-sharing, screen-sharing, etc.

Need very low cost

51

Shinkuro Collaboration Peer-to-peer, ad hoc group formation and data sharing

Secure Lightweight Operational across organizational boundaries Unimpeded by firewalls

Implicit communication – less drag, focus on apps Contributions and interactions across…

Network technology Collaboration technology Human-computer interactions Security models

52

Our Approach Replicate data between group members

Each member specifies a shared folder Data replicates between all members Access control Messages secured during transport Supports intermittent connection of members

Approach includes… Direct & relayed transport Presence & instant messaging Screen-sharing Generalized platform capabilities Other small features

53

Status Version 2 is being tested broadly

Direct and relay transport Instant messaging & presence Screen-sharing Other platform capabilities

Internal use of system; changing the way we work

54

Shinkuro Strengths Group formation protocol

Secure, decentralized mechanism for group formation Independent of file sharing and replication

Simplex replication model Overcomes human issues of file sharing Resolves difficulties in loosely coupled systems

Transport Multiple transports and opportunities to add others

Security Encrypted and signed communications without relying on

SSL or TLS Opaque message transfer through relays

Platform Extensible design for leveraging group formation

mechanisms into new applications

55

Group Formation Protocol

Amanda Steve

Jeff

(1) Amanda invites Steve to join group

(2) Steve accepts group membership

(3) Amanda welcomes Steve to group and tellsSteve who the other group members are

(4) Steve introduces himself to Jeff as a newgroup member who was invited by Amanda

(5) Jeff welcomes Steve to group since heknows that Amanda is a group member

Group

Group Invitation Protocol

Peer group formation using cross certification of

group members

56

Simplex Model Replication

amanda@shinkuro.com

jeff@shinkuro.com

steve@shinkuro.com

C:\my documents\papers

C:\Groups\Shared Papers

D:\Shinkuro\Amanda Papers

jeff@shinkuro.com

steve@shinkuro.com

amanda@shinkuro.com

Simplex Model FileSharing

Amanda’s Computer Steve’s Computer

Jeff’s Computer

57

Operational Concept

Organization A Organization B

UserDesktop

RelayUser

DesktopUserDesktopUserDesktop

UserDesktopUserDesktopUserDesktopUserDesktop

Relay

Organization C

UserDesktop

UserDesktop

58

Security Built into the system core

Fundamental to group formation Designed to minimize reliance on secured channels (SSL, TLS)

X509v3 certificate generated for each user Keys exchanged before other communications Each message is separately encrypted

(no session keys)

59

Platform Components designed as separately functional “managers”

Designed using a service model Some well known services exist (key ring, crypto, group management)

Other services implemented around the core File replication Group chat

Core code implemented as a library of services for the main application UI

Can be used within other applications Services can be added into as loadable modules (coming soon)

60

Supervisor (extensibility manager)

Communications Manager (transport)

Direct/Relay SMTP POP3 MAPI

Queue Manager (message handling)

Group Manager (group formation)

DirectoryManager(file

replication)

ChatManager(group

conversation)

InstantMessaging(one-to-one

chat)

PersonManager(keyring)

OtherGroup

Functions(extensions)

OtherManagers

(extensions)

Other

User Interface Command Server

DyCER API

API Implemented ExpansionKey Architecture

CryptoManager

AlertsManager

SettingsManager

Implemented Utilities

ScreenSharingManager

Other UI/ApplicationsWeb-Based UI

Direct FileTransfer

61

Try it!

www.shinkuro.com Windows, Mac, Linux, FreeBSD Free!

Tell us what you think