HSB - Secure DNS en BGP ontwikkelingen - Benno Overeinder

http://www.nlnetlabs.nl/

Developments in DNS and BGP Security Benno Overeinder

NLnet Labs

http://www.nlnetlabs.nl/ NLnetLabs

The Nature of A<acks on the Internet Infrastructure

•  DNS spoofing –  redirect to websites that are “evil twins” –  stealing personal informa@on or money

•  Route hijacks –  knock-‐out compe@tor or inspec@ng traffic –  inten@on (malicious or mistake) difficult to assess

•  DDoS amplifica@on reflec@on aKacks –  knock-‐out compe@tor: business or in gaming –  blackmailing: receive money to stop DDoS


DNS SPOOFING AND DNSSEC


DNS Spoofing and DNSSEC •  DNS Spoofing by cache poisoning

–  aKacker flood a DNS resolver with phony informa@on with bogus DNS results

–  by the law of large numbers, these aKacks get a match and plant a bogus result into the cache

•  Man-‐in-‐the-‐middle aKacks –  redirect to wrong Internet sites –  email to non-‐authorized email server


What is DNSSEC? •  Digital signatures are added to responses by authorita@ve servers for a zone

•  Valida@ng resolver can use signature to verify that response is not tampered with

•  Trust anchor is the key used to sign the DNS root

•  Signature valida@on creates a chain of overlapping signatures from trust anchor to signature of response

credits Geoff Huston


DNSSEC and ValidaHon

.nlnetlabs.nl.

A record www.nlnetlabs.nl. + signature .nl.

.

valida@ng resolver

DNSKEY record .nlnetlabs.nl. + signature

DS record .nlnetlabs.nl. + signature DNSKEY record .nl. + signature

DS record .nl. + signature

local root key (preloaded)

1

2

3

4

5


DNSSEC ValMon by SIDN

4 ISPs SIDN

Coming up: 3 universi@es

UNBOUND resolver

Support Desk Support Desk Valida@ng resolvers

at ISP

Valida@on errors

Email (per registrar)

Phone call

Email (overview) ValMon server

.nl Registrar .nl Registry

Check


ValidaHon Errors


ROUTE HIJACKS AND RPKI


Recent News on Internet RouHng Security

•  April 2, 2014: “Indonesia Hijacks the World” –  Indosat leaked over 320,000 routes (out of 500,000) of the global rou@ng table mul@ple @mes over a two-‐hour period

–  claimed that it “owned” many of the world’s networks –  few hundred were widely accepted

•  0.2% low impact (5-‐25% of routes) •  0.06% medium impact (25-‐50% of routes) •  0.03% high impact (more than 50% of routes)

–  for details see hKp://www.renesys.com/2014/04/indonesia-‐hijacks-‐world/


Less Recent News on Internet RouHng Security

•  April 8, 2010: “China Hijacks 15% of the Internet” –  50,000 of 340,000 IP address blocks makes 15% –  for roughly 15 minutes

•  Hijacking 15% of the routes, does not imply 15% of Internet traffic

•  More realis@c guesses –  order of 1% to 2% traffic actually diverted

•  much less in Europe and US –  order of 0.015% based on 80 ATLAS ISP observa@ons

•  but s@ll an es@ma@on


Even Less Recent News on Internet RouHng Security

•  February 2008: Pakistan’s aKempt to block YouTube access within their country takes down YouTube globally – mistakenly the YouTube block was also sent to a network outside of Pakistan, and propagated

•  August 2008: Kapela & Pilosov showed effec@ve man-‐in-‐the-‐middle aKack –  already known to the community, but never tested in real


Old News on Internet RouHng Security

•  January 2006: Con-‐Edison hijacks a chunk of the Internet

•  December 24, 2004: TTNet in Turkey hijacks the Internet (aka Christmas Turkey hijack)

•  May 2004: Malaysian ISP blocks Yahoo Santa Clara data center

•  May 2003: Northrop Grumman hit by spammers

•  April 1997: The "AS 7007 incident”, maybe the earliest notable example?


Today’s RouHng Infrastructure is Insecure

•  The Border Gateway Protocol (BGP) is the sole inter-‐domain rou@ng protocol used

•  BGP is based on informal trust models –  rou@ng by rumor –  business agreements between networks

•  Rou@ng audi@ng is a low value ac@vity –  and not always done with sufficient thoroughness


IP Hijacking Explained

A 213.154/16: A

D

E

C

B

213.154/16: E213.154/16: C, A

213.154/16: A213.154/16: E

213.154/16: C, A


RPKI Resource CerHficate Hierarchy

The Internet Protocol Journal17

Figure 2: RPKI Resource Certificate Hierarchy

ISP2ISP1 ISP4ISP3 ISP ISPISP

NIR1 NIR2

RIPE NCCAFRINIC ARIN LACNICAPNIC

Issued CertificatesMatch Allocation

Actions

ResourceAllocationHierarchy

IANA

Self-Signed “Root”Certificate

The common constraint within this certificate structure is that an issued certificate must contain a resource extension that contains a subset of the resources that are described in the resource extension of the issuing authority’s certificate. This requirement corresponds to the allocation constraint than a registry cannot allocate resources that were not allocated to the registry in the first place. One implication of this constraint is that if any party holds resources allocated from two or more registries, then it will hold two or more Resource Certificates in order to describe the complete set of its resource holdings.

Validation of a certificate within this RPKI is similar to conven-tional certificate validation within any PKI, namely establishing a chain of valid certificates that are linked by issuer and subject from a nominated trust anchor CA to the certificate in question. The only additional constraints in the RPKI are that every certificate in this validation path must be a valid Resource Certificate, and the IP num-ber of resources described in each certificate must be a subset of the resources described in the issuing authority’s certificate.

Within this RPKI all Resource Certificates must have the IP addresses and AS resources present, and marked as critical extensions. The con-tents of these extensions correspond exactly to the current state of IP address and AS number allocations from the issuer to the subject.

Any holder of a resource who can make further allocations of re-sources to other parties must be able to issue Resource Certificates that correspond to these allocations. Similarly, any holder who wishes to use the RPKI to digitally sign an attestation needs to be able to issue an End Entity (EE) certificate to perform the digital signing operation.


RouHng with RPKI Explained

A 213.154/16: A

D

E

C

B

213.154/16: E213.154/16: C, A

213.154/16: A213.154/16: E

213.154/16: C, A

✔

✗

✗

✔

✔

✔


Summary

•  Internet a dangerous place? –  yes/no, not different from the real world

• We have a shared responsibility in securing our infrastructure (the Internet is you!) –  deploy DNSSEC –  route filtering and RPKI –  BCP 38 and BCP 84


AMPLIFICATION ATTACKS AND SOURCE ADDRESS FILTERING

Supplementary Fun in Breaking the Internet Infrastructure


DNS AmplificaHon A<ack


Recent DDoS A<acks with Spoofed Traffic

•  The new normal: 200-‐400 Gbps DDoS AKacks •  March 2013: 300 Gbps DDoS aKack

–  vic@m Spamhaus –  DNS amplica@on aKack –  [offender arrested by Spanish police and handed over to Dutch police]

•  Februari 2014: 400 Gbps DDoS aKack –  vic@m customers of CloudFlare –  NTP amplifica@on


MiHgaHon to AmplificaHon A<acks

•  DNS amplifica@on aKacks –  response rate limi@ng (RRL) –  RRL available in NSD, BIND 9, and Knot

•  NTP –  secure NTP template from Team Cymru hKp://www.team-‐cymru.org/ReadingRoom/Templates/secure-‐ntp-‐template.html


… or BCP38 and Filter Spoofed Traffic

•  BCP 38 (and related BCP 84) •  Filter your customers

–  strict filter traffic from your customers –  strict unicast reverse path forwarding (uRPF) –  don’t be part of the problem

•  Filter your transit –  difficult to strict filter your transit –  feasible or loose uRPF –  feasible not well supported by hardware vendors


REFERENCES AND POINTERS TO COMMUNITY ACTIVITIES

Addi@onal informa@on on DNSSEC, RPKI, and address spoofing


DNSSEC Deployment

•  Open source authorita@ve DNS name servers suppor@ng DNSSEC –  e.g., NSD, BIND 9, and Knot

•  Open source DNSSEC valida@ng resolvers –  e.g., Unbound, BIND 9

•  Google Public DNS – DNSSEC valida@on –  8.8.8.8 and 8.8.4.4 –  2001:4860:4860::8888 and 2001:4860:4860::8844


DNSSEC and Community

RIPE •  DNS Working Group at RIPE

mee@ngs

•  DNS Working Group mailing list dns-‐[email protected]

•  DNSSEC training course hKp://www.ripe.net/lir-‐services/training/courses

IETF •  DNSOP Working Group at

IETF mee@ngs

•  DNSOP Working Group mailing list [email protected]

•  RFC on opera@onal prac@ceshKp://tools.iew.org/html/rfc6781


Other References to DNSSEC •  ISOC Deploy360

–  hKp://www.internetsociety.org/deploy360/dnssec/ –  informa@on on basics, deployment, training, etc.

•  DNSSEC Deployment Ini@a@ve –  hKps://www.dnssec-‐deployment.org –  mailing list dnssec-‐deployment@dnssec-‐deployment.org

•  OpenDNSSEC –  open-‐source turn-‐key solu@on for DNSSEC –  www.opendnssec.org


Resource PKI: First Step to Improve Security

•  Regional Internet Registries (RIPE, APNIC, etc.) issue resource cer@ficates –  proof of ownership of resources (IP addresses) –  … and recursively repeated by NIR/LIR/…

•  owner of IP addresses publishes signed route origin aKesta@ons –  private key signed ROA states right of use of addresses by a network (the route origin)

•  ISPs can validate BGP rou@ng announcements –  validate ownership of route origin by checking signature in ROA with public key in resource cer@ficate


RouHng Security and Community

RIPE •  Enable RPKI in RIPE LIR

portal for your resources

•  RPKI origin valida@on in Cisco, Juniper, Alcatel-‐Lucent, … and open source soyware Quagga and BIRD

•  RIPE mee@ngs in plenary and Rou@ng WG rou@ng-‐[email protected]

IETF and others •  IETF SIDR WG for RPKI and

BGPSEC protocol standardiza@on

•  IETF GROW WG on opera@onal problems

•  ISOC Deploy360 Programme hKp://www.internetsociety.org/deploy360/securing-‐bgp/tools/


Address Spoofing and Community

RIPE •  RIPE mee@ngs in plenary and

working groups

•  RIPE document 431 and 432 –  hKp://www.ripe.net/ripe/

docs/ripe-‐431 –  hKp://www.ripe.net/ripe/

docs/ripe-‐432

•  RIPE training course hKp://www.ripe.net/lir-‐services/training/courses

IETF and others •  BCP 38 and BCP 84

•  IETF SAVI WG

•  Open Resolver Project openresolverproject.org

•  Open NTP Project openntpproject.org

HSB - Secure DNS en BGP ontwikkelingen - Benno Overeinder

Technology

Transcript of HSB - Secure DNS en BGP ontwikkelingen - Benno Overeinder