El Internet es un lugar peligroso
El Corazón del Internet
DNS Infraestructura de enrutamiento
... es frágil
Cache poisoning
DNSSEC
RPKI
Secuestro de rutas
DDoS / DoS
Man in the middle
Hoy en día
• Un ISP al obtener recursos de Internet (IPv6/IPv4) – Indica a su upstream/peers cuales son los prefijos que va a anunciar
– Vía e-‐mail, formas web, IRR (Internet Rou1ng Registry)
• Proveedores/peers verifican derecho de uso del recurso y configuran filtros – Whois RIRs: Información no firmada, no para ruteo
– Whois IRR: Información no firmada, pocos mecanismos para auten1ficación de derecho de uso
Protección Actual
• Administrador de la red – Controles locales en su infraestructura de rutas – Protección de routers – Integridad de operación en sus protocolos de ruteo
• Medidas posibles de protección – Filtros 1918 (rfc1918) prefijos de redes privadas – "Bogon Filters" espacios no asignados de IANA
Pero a pesar de todo …
• ¿ Es realmente fiable la información manejada por los protocolos de ruteo ? – Quien anuncia una ruta en Internet puede no ser el autorizado a hacerlo
– Secuestro de redes no asignadas para el envío de spam – Secuestro de redes para captura de tráfico – Secuestro de redes para ataques de DDoS
Secuestro de rutas
• El clásico ejemplo de la fragilidad del sistema de ruteo • Ocurre todo el 1empo en Internet, en especial de
direcciones no asignadas • Gran problema es cuando se secuestran prefijos en
operación sea por error operacional o por ac1vidad maliciosa
• Par1cularmente es dañino cuando el ataque se hace con prefijos más específicos
• Ejemplo: YouTube vs. Pakistan Telecom (Feb 2008) – hip://www.ripe.net/news/study-‐youtube-‐hijacking.html
RPKI
• Validación de derecho de uso de un recurso • Metodología automa1zada que permita validar la
autoridad asociada a un anuncio de una ruta “origen de la ruta”
• El emisor de la información de ruta "firma" la actualización
• No permite que terceros falsifiquen la información o la firma
• U1lizar las propiedades de encriptación con Clave Pública
• Resource Public Key Infrastructure
RPKI cont …
• Los objectos firmados son listados en directorios públicos
• Los objetos pueden ser usados para configurar filtros en routers
• Proceso de Validación – Los objetos firmados son referenciados al cer1ficado que los generó
– Cada cer1ficado 1ene una referencia al cer1ficado en la capa superior
– Sigue una cadena de confianza hasta el “trust anchor”
X.509 con extensiones de direcciones de IP y ASNs (RFC3779)
• Cer1ficados Digitales X.509 – Información del sujeto,
plazo de validez, llave publica, etc
• Con extensión: – RFC 3779 estándar IETF
define extensión para recursos internet.
• Listado de IPv4, IPv6, ASN asignados a organización
Signature Algorithm
Serial Number
Version
Issuer
Subject
Subject Public Key
Extensions
Addr: 10.10.10.0 Asid: 65535
¿Cómo funciona? Trust Anchor
ISP ISP
End User End En1ty (EE)
ROA (Route Origin Authoriza1on)
End En1ty (EE)
ROA (Route Origin Authoriza1on)
10.0.0.0/8
10.1.0.0/24 10.10.0.0/16
10.10.1.0/24
CA bit on CA bit on
CA bit on CA bit off
CA bit off
No puede firmar CA pero puede firmar otros objetos
ROA no es un cer1ficado, es un objeto firmado
X.509 RFC3779
ROA (Route Origin Authoriza1on)
• ROA es un objeto digitalmente firmado que provee un mecanismo par verificar que la en1dad con derecho de uso de bloque de direcciones IP ha autorizado a un sistema autónomos (AS) a originar rutas de uno o varios prefijos del bloque de direcciones.
Arquitectura RPKI
• Una infraestructura de llaves públicas (PKI) • Objetos de ruteo digitalmente firmados para soportar seguridad en ruteo
• Un repositorio distribuido para mantener los objetos de PKI y los objectos de ruteo firmados
Hosted vs. Delegated
• Hosted – El CA genera los cer1ficados con los recursos de la en1dad y guarda la llave privada de la en1dad
– Esquema con el que actualmente trabajan los sistemas de los RIRs (futuro híbrido)
• Delegated – En1dad genera su cer1ficado con sus recursos – CA verifica auten1cidad y firma cer1ficado vía up/down protocol
Servicios RPKI CA
• Emisión de cer1ficados hijos cuando existen cambios en la base de registro o a demanda de un usuario
• Revocación de cer1ficados hijos en forma centralizada o a demanda de un usuario
• Emisión periódica de CRL para cer1ficado del CA • Publicación de Cer1ficado del CA y de cer1ficados hijos en repositorio público (rsync)
RPKI rou1ng protocol
• Validar los ASs que originan anuncios de BGP • Routers requieren mecanismos simple pero confiable
Global RPKI
Local Cache
Routers Routers
Local Cache
Routers
drat-‐ieu-‐sidr-‐rpki-‐rtr
Autorita1vo
Verificable no-‐Autorita1vo
Routers recogen datos
Otras alterna1vas
• Collectores/configuradores recogen datos de caches RPKI y configuran filtros de bgp en enrutadore
• Uso de RADB con interfaz de RPKI
Formalización del Protocolo
• SIDR (Secure InterDomain Rou1ng) Working Group en IETF
• Architecture, cer1ficate structure and profile, cer1ficate policies, Trust Anchor, Repository structure, ROAs, CP
• Ningún documento ha alcanzado estatus de RFC • hip://tools.ieu.org/wg/sidr/
Ligas
• Piloto – hip://rpki.lacnic.net
• Repositorio – rsync://repository.lacnic.net/rpki/
• Para ver el repositorio – rsync -‐-‐list-‐only rsync://repository.lacnic.net/rpki/lacnic/
Top Related