seguridad en el dns y en el sistema de ruteo de...
TRANSCRIPT
SeguridadenelDNSyenelsistemaderuteodeInternet
Seguridad,estabilidadyresilienciaenlaregión
GuillermoCicileo
VisióndeLACNIC
LiderarelfortalecimientodeUnaInternet,Abierta,EstableySeguraalserviciodeldesarrollodeAméricaLaBnayelCaribe,impulsandoelmodelocolaboraBvo
deInternet.
EstrategiadeLACNIC
• ConsideramosqueunaInternetsegurayestableesunfactorclaveparaeldesarrollosocialyeconómicodelanuestraregión• EntendemosquelosaspectosdeseguridadyestabilidadBenenunafuerteinterrelación– Muchasmedidasquecontribuyenaunotambiénlohacenalotro.
EstrategiadeLACNIC
• Ennuestravisión,laseguridadyestabilidaddeInternetnopuedeserlogradaporunaúnicaorganización,esnecesariamenteunobjeBvocomparBdo– TrabajoconjuntoconotrasenBdadescomoLAC-IX,LACTLD,ICANN,ISOC,ITU,etc,queconvergenenestosobjeBvos
ProgramadeSeguridadyEstabilidad
• Seguridad:– Librederiesgoypeligro– Tomademedidasqueprevenganriesgosypeligros
• Estabilidad:– Permanencia,conBnuidadenelBempo– FuncionamientoconlasmismascaracterísBcasenausenciadeesRmulosextraordinaros
• Resiliencia:– Lacapacidaddeauto-repararse(selfrestora*on)
ProgramadeSeguridadyEstabilidad
Ejesprincipales:– Fortalecimientoyproteccióndeinfraestructura– Creacióndecapacidadeshumanas– Difusión,cooperacióneinvesBgación
FortalecimientodeInfraestructura
• SSRenenrutamiento– ProyectodeCerBficacióndeRecursos(RPKI)– Fomentoalacreacióndepuntosdeintercambiodetráfico(IXP)
• SeguridadenelDNS– DesplieguedeDNSSECaniveldelaresoluciónreversa– Programa+Raíces,desplieguedecopiasdeservidoresraízdelDNSennuestraregión
• DesplieguedeIPv6– UnaInternetestabledebepodercrecersinrestriccionestécnicas
Creacióndecapacidadeshumanas
• Cursosdecapacitaciónvirtualesypresenciales– DNSSEC– EnrutamientoconBGPyRPKI– DesplieguedeIPv6– TalleresparaIXPs
• Talleressobrecreacióndegruposderespuestaaincidentesdeseguridad(CSIRTs)– TalleresAMPARO
Difusión,cooperacióneinvesBgación
• ColaboraciónconotrasorganizacionesendiferentesacBvidades
• GeneracióndereportesyestadísBcas• LACNICWARP,h_p://warp.lacnic.net– Serviciodemediacióndeincidentes(incidentbrokering)– NosapoyamosenlafuerterelaciónquetenemosconnuestrosmiembrosparahacerlesllegarinformaciónsobrepotencialesincidentesdeseguridadqueLACNICrecibeporotrasvías
LaimportanciadelDNS
• EncadacomunicaciónentreaplicacionesTCP/IPesnecesarioobtenerladirecciónIPdelextremoremoto
• LossereshumanosnopodemosmemorizarmillonesdedireccionesIP(especialmentedireccionesIPv6)
• Agrandesrasgos:ElSistemadeNombresdeDominioproveealasaplicacionesdisBntosBposderecursos(domainnameservers,mailexchangers,reverselookups,…)
11
DNS
• PermiteasociardireccionesIPconnombresdedominio– 192.0.2.3awww.example.net
• Inversamente:– www.example.net--->192.0.2.3
• Trabajaatravesdeconsultasyrespuestasatravesde“Registros”
RegistrosdelServidordeDNS
• TiposdeResourceRecords–RR:– A:MapeanunnombreaunadirecciónIPv4– AAAA:MapeanunnombreaunadirecciónIPv6– NS:Indicanquéservidorrespondeporquédominio– PTR:MapeanunarepresentacióndedirecciónIPv4aunnombre(in-addr.arpa)
– Entreotros..
Tiposdenameserver• RFC7719:
– Resolver:Aprogram"thatextract[s]informaBonfromnameserversinresponsetoclientrequests."(Quotedfrom[RFC1034],SecBon2.4)"Theresolverislocatedonthesamemachineastheprogramthatrequeststheresolver'sservices,butitmayneedtoconsultnameserversonotherhosts."(Quotedfrom[RFC1034],SecBon5.1)Aresolverperformsqueriesforaname,type,andclass,andreceivesanswers.ThelogicalfuncBoniscalled"resoluBon".InpracBce,thetermisusuallyreferringtosomespecifictypeofresolver(someofwhicharedefinedbelow),andunderstandingtheuseofthetermdependsonunderstandingthecontext.
– Recursivemode:AresoluBonmodeofaserverthatreceivesDNSqueriesandeitherrespondstothosequeriesfromalocalcacheorsendsqueriestootherserversinordertogetthefinalanswerstotheoriginalqueries.SecBon2.3of[RFC1034]describesthisas"Thefirstserverpursuesthequeryfortheclientatanotherserver".AserveroperaBnginrecursivemodemaybethoughtofashavinganameserverside(whichiswhatanswersthequery)andaresolverside(whichperformstheresoluBonfuncBon).SystemsoperaBnginthismodearecommonlycalled"recursiveservers".SomeBmestheyarecalled"recursiveresolvers".Whilestrictlythedifferencebetweentheseisthatoneofthemsendsqueriestoanotherrecursiveserverandtheotherdoesnot,inpracBceitisnotpossibletoknowinadvancewhethertheserverthatoneisqueryingwillalsoperformrecursion;bothtermscanbeobservedinuseinterchangeably.
– Authorita:veserver:"AserverthatknowsthecontentofaDNSzonefromlocalknowledge,andthuscananswerqueriesaboutthatzonewithoutneedingtoqueryotherservers."(Quotedfrom[RFC2182],SecBon2.)ItisasystemthatrespondstoDNSquerieswithinformaBonaboutzonesforwhichithasbeenconfiguredtoanswerwiththeAAflagintheresponseheadersetto1.ItisaserverthathasauthorityoveroneormoreDNSzones.NotethatitispossibleforanauthoritaBveservertorespondtoaquerywithouttheparentzonedelegaBngauthoritytothatserver.AuthoritaBveserversalsoprovide"referrals",usuallytochildzonesdelegatedfromthem;thesereferralshavetheAAbitsetto0andcomewithreferraldataintheAuthorityand(ifneeded)theAddiBonalsecBons.
Resolver,recursivoyautoritaBvo
DNSRecursivo
DNSAutorita:vo
Resolver
DNSAutorita:vo
DNSAutorita:vo
”."
COM
EXAMPLE
Zonas
BúsquedaDNS
16
comname server
example.comname server
name server
resolver
Reply
com ar br
example
imap mail www
Refer to com NS + glue
Refer to example.com NS [+ glue]
RR for www.example.comQ
uery
‘www.example.com’R
R?
Query ‘www.example.com’RR?
Query ‘www.example.com’RR?
Query ‘www.example.com’RR?
“” name server
root
example2
VulnerabilidadesdelDNS
• LainformacióntransmiBdapuedeserfalsificada– Entremasteryslave(AXFR)– Entreelmasterylosresolversclientes
• ElprotocoloDNSnopermitevalidarlainformacióncontenidaenunarespuesta– Esporlotantovulnerableaataquesde”poisoning”y”spoofing”– Losdatos”envenenados”seguiráncausandoproblemasporunBempo(TTL)
• TampocolossecundariosBenenformadeautenBcaralprimarioconelqueestánhablando
¿QuéprotecciónbrindaDNSSEC?
• ProporcionaunmecanismoparapodervalidarlaautenBcidadylaintegridaddelosdatoscontenidosenunazonaDNS– DNSKEY/RRSIG/NSEC
• Proporcionaunmecanismoparaestablecercadenasdeconfianza– DS
• ProporcionaunmecanismoparaautenBcarlastransferenciasdezonaentreprimariosysecundarios– TSIG
DNSSEC
• EsunconjuntodeextensionesalprotocoloDNStalcomoloconocemos
• Cambiosenel“wireprotocol”(EDNS0)– ExtensióndeltamañomáximodeunarespuestaUDPde512a4096bytes
• Agregadodenuevosresourcerecords– RRSIG,DNSKEY,DS,NSEC(3)
• Agregadodenuevosflags– CheckingDisabled(CD)– AuthenBcatedData(AD)
DNSSEC
• NuevosRR– RRSIG:ResourceRecordSignature– DNSKEY:DNSPublicKey– DS:Delega;onSigner– NSEC/NSEC3:NextSecure
Recordemos• UnresourcerecordenDNSesunatupladecincovalores:– (nombre,clase,;po,TTL,valor)
• Ejemplo:– www.example.com.86400INA192.0.2.1
• Estarepresentadoporlatupla:– Nombre(www.example.com)– Clase(IN)– Tipo(A)– TTL(86400segundos)– Valor(192.0.2.1)
DNSSECyRRSets• ResourceRecordSets(RRSets)
– DNSSECoperafirmandoRRSets(noRRindividuales)– UnRRSetesunconjuntoderesourcerecordsquecompartenigual:
• Clase• Tipo• Nombre
• EjemplodeRRSet(TTLomiBdo):
– wwwINA192.0.2.1– wwwINA192.0.2.2
– mailINMX10mail.example.com– mailINMX20mail2.example.com
– ns1INA192.0.2.3
– ns1INAAAA2001:db8::3
RRSet
RRSet
DiferentesRRSet
Firmadezonas
• Segeneraunpardeclaves(publicaysucorrespondienteprivada)paracadazona– ElpardeclavesespropiodecadazonaynodelservidorautoritaBvo
• Laparteprivadasedebemantenerbajocustodia– LaprivadafirmalosRRSetsdelazona
• LapublicasedebepublicarenDNSmedianteunregistroDNSKEY– LapúblicapermiteverificarlasfirmasdelosRRSets
• UnRRSetpuedetenermulBplesfirmasgeneradascondiferentesclaves
Registrosfirmados• LafirmadigitaldeunRRSetsedevuelveenformadeunregistroRRSIGqueespartedelarespuesta• Ejemplo:dig+dnssecwww.lacnic.net;;ANSWERSECTION:www.LACNIC.NET. 7200 IN A 200.3.14.147www.LACNIC.NET. 7200 IN RRSIGA537200201605060516122016040604250848072lacnic.net.RIiO6s9b95wgLK4H8ORMbR9PXWp0Rpb6huaoNySASQiZr32TldnMkNaNbvK0Dwl/hdwtIoz7yLjirNeaWTIIoaokO6OHbooPBdfV/RF/T5KNeBYFSqQpKO34AXQ3nEVmw6OgHFVJT/EVvLlghxGR5VUY6qRRMAJ1K6TqpPPnknjmMsDQ/RWLtuhWQRiOshuygp0GpMqdRH8W3I3nE0HqL43WBoYHB032/01NB59SWgbHV0C5wclNkXIFIVV45sXKNz7cXX9oc+CQy/xLrTRgegR0HvlwGLVZeeVRq3qPzAX3/sGDErkZi3pBEepXqzcGN/T5IPdoLIbZq3gA68vSg==;;AUTHORITYSECTION:LACNIC.NET. 7200 IN NS SEC3.APNIC.NET.LACNIC.NET. 7200 IN NS NS.LACNIC.NET.LACNIC.NET. 7200 IN NS TINNIE.ARIN.NET.LACNIC.NET. 7200 IN NS dns.anycast.lacnic.net.LACNIC.NET. 7200 IN NS NS2.LACNIC.NET.LACNIC.NET. 7200 IN NS ns2.dns.br.LACNIC.NET. 7200 IN RRSIGNS527200201605060533202016040604394348072lacnic.net.b6Au9BEdOqHG8V4vBwbqfEMYNUtdivOJoyy6ER0KSN3xsbY7GOZHwkxFm5StPUgOV8PXhzV/i0faqjpoTBJmQxRZbkW6KH2KuMRG8wA8KF/kbYfKrL15lQzNsJmv69iUjP5JuXdCE2v8RPrtlhIDOoyCA4cmSLxrZNAhZETMYR5uz7yegcEXEHwMf1OZCzBQZdXglZ5zw�xCwEO4mjzMKGPnfHsnxmHS5eQu5I71xAa+D7xvV0nyREk+qt/h/FyZeehazy5tGiVTH+Goht4pUoaDhQTqRdx1CJiu3XYJINE6jatGtPEKO0tDvx9EW6R27jmULFOyanvEkfFiZHpvA==
Cadenadeconfianza
• ¿ComopuedeunclienteverificarunRRSetdeunaciertazona?– HaceunaconsultaporelDNSKEYcorrespondiente– RealizaloscalculoscorrespondientesyloscomparaconelRRSIG
• Sicoinciden,lafirmaverifica,delocontrario,no
• Pero¿comosepuedeconfiarenlaDNSKEYsisaledelamismazonaquequeremosverificar?– Necesitamosverificarlacadenadeconfianza
Cadenadeconfianza• RegistroDS“Delega;onSignature”– LosregistrosDS“firman”clavesdezonashijas– DeestaformaunopuedeverificarelDNSKEYdeunazonabuscandounregistroDSenlazonapadre
• ElregistroDSconBeneunhashdelaunaclavepública– Esdecir,delcontenidodeunregistroDNSKEY
• LosregistrosDSenlazonapadreestánfirmadosconla(s)clavesdeesazona
• ParecidosalosNS,perosonauthoritaBvosenelpadre,noelhijo• ParacompletarlacadenadeconfianzaBenequeestarfirmadalaraízdelDNS
Cadenadeconfianza
• Pero¿quepasaconlazonaraíz?– LazonaraíznoBene“padre”aquienirapedirleunregistroDS
• LaraízdelDNSestafirmadadesdejuliode2010– [hHp://www.root-dnssec.org]
• ElregistroDSpara“.”sepuedeobtenerfueradebanda– [h_p://data.iana.org/root-anchors/root-anchors.xml]– .INDS49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
Firmadelaraíz
• ¿CómoseverificalaautenBcidaddelroottrust-anchor?• ElTAdelazonaraízsepublicafueradebanda,porellolavalidacióndebeserdiferente– SepuedebajarporHTTP/HTTPS– Sepuedeverificarporotrosmecanismos(cerBficados,firmasPGP)– Similaraloquepasaconlazonaraízmisma,sedebecargarmanualmente
Negacióndeexistencia
• Respuestascon“NXDOMAIN”– Nieganlaexistenciadeunnombre– Sonrespuestas“cacheables”apesardesernegaBvas
• ¿Comofirmarlano-existencia?– NecesitotenerunRRSetparafirmar
• RecordarqueenDNSSECloquesefirmasiempresonRRSets– Técnicaspropuestas:
• NSEC• NSEC3
NSEC/NSEC3
• NSECproveeunpunteroalpróximoregistrosegurosegúnordenalfabéBco
• Ej:consultapormail.example.com?
• NSEC:www.example.com
a.example.coma.example.comwww.example.com
KSKvsZSK
• Usamos2paresdeclavespública-privada:– ZSK:usadaparafirmarlaszonas– KSK:usadaparafirmarlaZSK
• EslaapuntadaporelregistroDSdelazonapadre
• Ventaja:noesnecesarioactualizarelregistroDSenlazonapadrecuandosecambialaclavedeunazona
• EvitaunamayorcomplejidadadministraBva
DANE:DNS-BasedAuthenBcaBonofNamedEnBBes
• ProtocoloparapodercodificarcerBficadosX.509enDNS• DANEpermitepublicaryfirmarlasclaves/cerBficadosTLSdeundominiousandolaestructuradelDNS– Paraqueelmodelofuncione,esnecesariousarDNSSEC
• Deestaforma,sepuedenusarcerBficadosauto-firmados(noesnecesariaunaCAexterna)paralosdisBntosservicios
• SeagregaunnuevoRR:TLSA• EspecificadoenlasRFC6698yRFC7671
ProtocoloBGP
• LasorganizacionespublicansusprefijosderedmedianteelprotocoloBGP
• Anuncianlasredesalasquesepuedellegaryelpróximosalto(nexthop)atravésdelcualllegar
• Cadaorganizacióndeberíaanunciarsólosuspropiosrecursos(prefijosIP)olosdeorganizacionesalasqueproveatránsito
• PeroestecontrolenBGPnoestácontemplado• Sebasaenlabuenavoluntaddelosoperadores(ISPs)
EnrutamientoenInternet
ElASN6057anuncia
200.40.0.0/16
Elprefijo200.40.0.0/16sepropagaconBGPaInternetElASN8158
recibe200.40.0.0/16 Atributos:
200.40.0.0/16AS_PATHASN1ASN3ASN6057
Verificacióndeautorizacióndeuso
• Administradordelared– Controleslocalesensuinfraestructuraderutas
• Pediralgúnprocesoprevio(ej.RegistrarelobjetoenunIRR)– Protecciónderouters– Integridaddeoperaciónensusprotocolosderuteo
• AutenBcaciónentrepeers• Filtradoderutasquesesabeninválidas– Filtros1918(rfc1918)prefijosderedesprivadas– "BogonFilters"espaciosnoasignadosdeIANA
• Laintegridaddelsistemadependedelaconfianzaentrepeers
RuteoenInternet
• RecordemosdeBGP:– Losanunciosderutasquerecibimosafectanaltráficosaliente– Losanunciosderutasquerealizamosafectanaltráficoentrante
• Entonces:– Sirecibimosunanuncioderutaincorrecto,nuestrotráficopuedeirhaciasiBosdisBntosdeloesperado
– Esposibleatraerhacianosotrosdeterminadotráficohaciendoanunciosderutasespecíficos
Secuestroderutas
• CuandounparBcipanteenelrouBngenInternetanunciaunprefijoquenoestaautorizadoaanunciarseproduceun“secuestroderuta”(routehijacking)
• Maliciosoocausadoporerroroperacionales• Casosmásconocidos:– PakistanTelecomvs.YouTube(2008)– ChinaTelecom(2010)– GoogleenEuropadeleste(variosAS,2010)– Casosennuestraregión(enero/febrerode2011)
Secuestroderutas
AS15358anuncia200.40.235.0/24
ASN8158recibe200.40.0.0/16y200.40.235.0/24
200.40.0.0/16AS_PATHASN1ASN3ASN6057200.40.235.0/24AS_PATHASN1ASN15358
AS6057anuncia
200.40.0.0/16
ASN8158recibe200.40.0.0/16
RouteLeaks
ASN65511
ASN65536ASN65537
Transit
Peering2001:db8::/40 2001:db8:100:/40
2001:db8::/40655362001:db8:100::/4065537
Cómoestodeberíafuncionarsinleaks
2001:db8::/40
2001:db8::/40
2001:db8:100:/40Eltráficoatodoel
2001:db8::/40vaporestecamino
RouteLeaks
ASN65511
ASN65536ASN65537
Transit
Peering
2001:db8::/40 2001:db8:100:/40
2001:db8::/40655362001:db8::/4065537655362001:db8:100::/40655372001:db8:1::/486553765536
Ahoraunrouteleak
2001:db8::/402001:db8:1/48
2001:db8::/40
2001:db8:100:/402001:db8::/402001:db8:1::/48Eltráficohaciael
2001:db8:1::/48vaporestecamino
Ataquescontraelcamino
• InsercióndeAS:– UnrouterpuedeinsertarunoomásASNs,apartedesupropioASN,enunmensajedeactualización
• OrigenderutafalsoconunASNválido:– UnrouterpuedeoriginarunarutaparaunprefijousandounASNnoautorizadoaoriginarrutasparaeseprefijo.
Ataquescontraelcamino
ElAS6057falso
anuncia200.40.235.0/24
ElASN8158recibe
200.40.0.0/16y200.40.235.0/24 200.40.0.0/16AS_PATHASN1ASN3ASN6057
200.40.235.0/24AS_PATHASN1ASN15358
ElAS6057anuncia200.40/16
ElASN8158recibe
200.40.0.0/16
ASN6057
Secuestroderutas
• Lamayoríadelossecuestrosderutasocurridoshastaahorahansidoredireccionesdetráfico– ElproblemaesdetectadoporinaccesibilidaddelsiBooriginal(ej:casoYouTube)
• Eventualmentepublicacióntemporaldeprefijosparahacerspamming
• Sinembargo,enuntrabajode2008,presentadoenDEFCON16,Pilosov-Kapelademuestranlaposibilidaddere-enrutartráficosinprácBcamentedejarevidencias– Deesamanera,eltráficopuedeseranalizadoyprocesadosinsernotado
PakistanTelecomvs.YouTube• ElDomingo24deFebrerode2008PakistanTelecom(AS17557)anuncióelprefijo
208.65.153.0/24sinautorización
• ElupstreamproviderPCCWGlobal(AS3491)reenvióesteanuncioalrestodeInternet,resultandoenqueYouTubequedóinaccesible
• Análisisdetallado(porRIPENCC):h_p://www.ripe.net/internet-coordinaBon/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study
• VideoenYouTubesobreelevento:h_p://www.youtube.com/watch?v=IzLPKuAOe50
ChinaTelecom(2010)• Enabrilde2010,AS23724operadoporChinaTelecompropagórutaserróneasdurante15minutos:– Deunpromediode40prefijospasóa37.000anunciosdeprefijosnoasignadosaellos
– MuchossiBospopularesfueronafectados,comodell.com,cnn.com,www.amazon.de,www.rapidshare.comywww.geociBes.jp,ademásdemuchossiBoschinos
– TambiénsiBos.mily.govcomoelSenado,ejército,marina,fuerzaaéreayotrosdelosEEUU
• h_p://www.bgpmon.net/chinese-isp-hijacked-10-of-the-internet/• h_p://www.bgpmon.net/chinese-bgp-hijack-pu�ng-things-in-perspecBve/
RPKI
• QuesoluciónproponeRPKI?• ValidarelASqueoriginaunaruta– SóloquienBenedelegadoslosprefijospodráoriginarunarutaanunciándolos
• Deestaforma,losejemplosquevimosnopodríanocurrir• NoprevieneotroBpodeataquesnorelacionadosalASdeorigendeunaruta– Ej:ASsimulandodartránsitoaunASyrutasválidas
¿QuécomponelasoluciónRPKI?
• PublicKeyInfrastructurederecursos(IP+ASN+cerBficados)• Objetosfirmadosdigitalmenteparasoportarseguridaddelenrutamiento(ROAs)
• UnrepositoriodistribuidoquealmacenalosobjetosPKIylosobjetosdeenrutamientofirmados(ROAs+CRL+MNF)
ROAs
• UsandocerBficadospodemoscrearobjetosquedescribanelorigendeunprefijo
• ROAs:RouBngOriginAuthorizaBon– LosROAsconBeneninformaciónsobreelASdeorigenpermiBdoparaunconjuntodeprefijos
– LosROAssonfirmadosusandoloscerBficadosgeneradosporRPKI– LosROAsfirmadossoncopiadosalrepositorio
ValidaciónRPKI
• MetodologíaautomaBzadaquepermitavalidarlaautoridadasociadaaunanunciodeunaruta“origendeunaruta”
• Elemisordelainformaciónderuta"firma"lainformaciónde“ASdeorigen”
• ParavalidarcerBficadoseinformacióndeenrutamientoseuBlizan:– Laspropiedadesdelcifradodeclavepública(cerBficados)– LaspropiedadesdelosbloquesCIDR
• Seimpideentoncesquetercerosfalsifiquenlainformacióndeenrutamientoolasfirmas
ValidacióndeOrigen• Losroutersarmanunabasededatosconlainformaciónquerecibendeloscaches
• EstatablaconBene– Prefix,Minlength,Maxlength,Origin-AS
• Aplicandounconjuntodereglas,seasignaunestadodevalidezacadaUPDATEdeBGP
• Losoperadoresderedpuedenusarelatributo“validez”paraconstruirpolíBcasderuteo
• Elestadodevalidezpuedeser:– Válido:ElASdeorigenyelLargoMáximocoincidenconlainformacióndelROA– Inválido:LainformacióndelROAnocoincide– Noencontrado:NohayunROAparaelprefijodado
PolíBcasdeRuteoconValidacióndeOrigen
• UsandoelatributodevalidezdeBGPlosoperadoresderedpuedenconstruirpolíBcasderuteo
• Porejemplo:– Alasrutasconestado“valid”asignarlesmayorpreferenciaquealasrutasconestado“notfound”
– Descartarrutasconestado“invalid”• MUYIMPORTANTE:RPKIesunafuentedeinformación!Losoperadoressonlibresdeusarlacomolesparezcamejor