Los usuarios de servicios de telecomunicaciones a menudo asumimos que el entorno que nos ofrecen los proveedores está protegido. Seamos realistas, no nos hemos ocupado de corroborarlo o nos importa poco; reflexionemos acerca de cómo estas redes son estructuradas e instaladas.
En repetidas ocasiones hemos escuchado de acontecimientos noticiosos donde se vulnera la confidencialidad de las llamadas, donde alguien recibe un mensaje escrito con supuestas ofertas, promociones, premios y dádivas en tono de regalo, que se aprovechan de la nobleza de la gente que termina siendo presa de fraudes. Evidentemente muchos sucesos de este estilo son culminados y fructifican tras una ingeniería social efectiva (no sé si llamarle el “eslabón más débil” pero la actuación de ese actor en el proceso de comunicación ha sido indispensable para conformar las alarmantes estadísticas en fraudes exitosos).
Quienes ya han tomado mayores previsiones y quienes a través del tiempo han realizado esfuerzos serios y constantes son los clientes empresariales, dado que sus activos son más críticos en términos del negocio y el ser “indiferente” resulta muy costoso. Algunos se preguntarán: ¿Si mi proveedor me da el acceso y servicios de Internet – por ejemplo – no podría entregármelos con más controles de seguridad?, ¿acaso no están ellos y su negocio demasiado expuestos a estas amenazas? La respuesta es que sí lo están y habrán de hacer esfuerzos para mantenerse fuera de las listas negras como país generador de spam o con el mayor número de direcciones IP marcadas con actividad sospechosa, etcétera.
Hoy en día la oferta de los proveedores de servicios (carriers) es tan poderosa que los ámbitos a proteger se multiplican ampliamente. Los proveedores de servicios tendrán la particularidad de ofertar servicios masivos pero -aún más antagónico a esta concepción- tendrán la necesitad de ofrecer una seguridad específica o con la granularidad necesaria para servir como recursos fidedignos en una persecución legal por ejemplo, y sin transgredir la confidencialidad de la información de los afiliados.
Indudablemente la velocidad de las tecnologías y la forma en la que se están esparciendo alrededor del mundo, y los entornos de aprovechamiento de las mismas nos amplían las ofertas a través de la convergencia… lo que antes solo se ofrecía para empresas ahora es de interés para los usuarios finales; lo que solo se concebía como servicios en entornos fijos ahora se ven fortalecidos con plataformas que brindan movilidad y características de ubicuidad de gran alcance.
.
Seguridad en el ruteo IP de los proveedores de servicios
BGP (border gateway protocol) forma parte del ADN de cualquier proveedor de servicios y proteger este protocolo de ruteo es primordial.
El protocolo BGP envía mensajes, hace decisiones de ruteo o comparte atributos. Los mensajes pueden ser anuncios acerca del origen del paquete, avisos de ruteo o retiro de ruteo y, con base en estos, realiza las decisiones del mejor camino para llevar la información entre sistemas autónomos. Sin entrar en gran detalle acerca del funcionamiento de BGP, centrémonos en las principales causas de fallas, amenazas y problemáticas de este protocolo de ruteo.
Es bien sabido que Internet está dividido en sistemas autónomos (AS) y que todos los hosts en un AS tienen un solo control administrativo. El ruteo interdominios es solamente completado vía BGP. De esta manera los AS se informan de manera cooperativa uno a otro, para cada dirección IP acerca de dónde o en cuál AS se encuentra y cómo llegar a ella. Dado que BGP es un protocolo basado en políticas, cada AS elige entre múltiples rutas que se reciben para el mismo prefijo de acuerdo a su propio criterio. Asimismo un AS puede aplicar una política cuando exporta una ruta de forma que se envía al vecino solo si este está dispuesto a aceptar y reenviar tráfico al prefijo desde su vecino. Los ruteadores de frontera entonces colaboran en esta comunicación.
Quizá el mayor problema sigue siendo la configuración errónea del protocolo y esta no solo puede ser a causa de la poca experiencia o errores humanos, sino también puede ser provocada por un atacante. De acuerdo a un estudio realizado por la Universidad de Washington[i] las configuraciones erróneas se presentan sobre todo en:
- Errores (bugs) de inicialización del ruteador: son sometidos a investigación con fabricantes.
- Confianza en filtrado hacia proveedor superior: algunos AS confían o asumen que el proveedor superior los conoce, pero pudiera no ser visible de manera global.
- Configuraciones antiguas sin actualizar.
- Redistribución de rutas.
- Errores en la comunidad BGP.
- Hijack: ocasionalmente un AS no relacionado anuncia espacio de direcciones perteneciente a otro sistema autónomo. A pesar de que el potencial de hacer esto es una falla mayor de seguridad, la causa más común de esto es un problema de escritura (“error de dedo”) cuando el AS con error en configuración se hace dueño de prefijos que son similares a los prefijos “secuestrados”.
- Filtro olvidado en la configuración: cuando un ISP responde aceptando una configuración errónea olvidando filtrar estas rutas.
.
Ataques a la plataforma con BGP
Los errores arriba mencionados pueden derivar en afectaciones importantes, entre ellas las siguientes:
- Sobrecarga en el ruteo: incrementan la carga en el ruteo, generando actualizaciones innecesarias de BGP. Con el tamaño actual de Internet cualquier cambio afecta a toda la comunidad.
- Interrupción de la conectividad, tanto local como global.
- Violación de la política: anuncios erróneos de ruteo pueden ser elegidos como validos y transitar inadvertidamente a otros sistemas autónomos.
- Hoyos negros en Internet: lugares dentro de la red donde los paquetes son descartados sin informar a la fuente de la causa. Tal vez el caso canónico más representativo es el conocido como Incidente AS7007[ii].
A pesar de los años que han transcurrido desde la realización del mencionado estudio, le sorprendería al lector lo mucho que se siguen observando estas fallas. Por ejemplo, el 20 de agosto pasado la empresa rusa de telecomunicaciones Link Telecom envió un comunicado informando que su red había sido presa de un ataque y por ello el sistema autónomo AS-31733 había sido secuestrado en cinco prefijos. Lo que es más sorprendente es que dicho secuestro había comenzado en abril de 2011[iii].
.
Entonces, ¿cuáles son los ataques más comunes a BGP?:
- Ataques de origen: pueden derivarse de errores humanos y desestabilizan la operación desde el anuncio de los prefijos.
- Prefix Hijaking.
- Prefix destabilization (principal causante de hoyos negros junto con el siguiente ataque).
- Self-deaggregation.
- Unauthorized use.
- Ataques de ruta: son usados para trastornar el ruteo y sesgar la forma en que los paquetes viajan a través del sistema autónomo.
- Path modification.
- Path forgery.
- Policy modification.
- AS forgery.
- Ataques de timing.
- Mensaje “OPEN spoofed” durante la fase de negociación.
- Ataque TCP SYN.
- Alteración de timers BGP.
- Mensajes KEEPALIVE falsos mientras los ruteadores peer se estén conectando.
- Ataques de disponibilidad.
- En protocolo.
- Mensajes NOTIFICATION falsos.
- Errores de sintaxis en mensajes BGP.
- Forzar que una inundación de ruteo ocurra.
- Paquetes TCP RST falsos.
- Enlaces físicos.
- Provocar la reinicialización del ruteador para ganar control de él. Por ejemplo, ejecutando un desbordamiento de buffer a través de un ataque SNMP.
- Afectar directamente el enlace.
- En protocolo.
Finalmente proveeré algunas de las sugerencias más comunes para evitar los ataques en la infraestructura BGP:
- Considerar la arquitectura y tecnología de ruteo como parte del portafolio de seguridad.
- Realizar el endurecimiento de configuraciones (hardening) a la infraestructura.
- Para un ataque contra DDoS BGP: cuidar el control de políticas, ya sea a través de CoPP (Control Plane Policing) o LTPS (local packet transport protocol).
- Asegurar la correcta asociación de ruteadores peer: autenticación de ruteadores vecinos a través de MD5 o keychain/TCP-OA (object autentication) y protección con IPSec a las sesiones TCP de BGP.
- Centralizar el modelo de seguridad a través de BGP Flow-Spec.
- Contra tráfico DDoS enviado hacia la red atacando la infraestructura: emplear recursos como RTBH (remote triggered black holes), Blacklist VRF, Sinkhole Routing y FlowSpec
- Para evitar la conexión de falsos BGP peers: habilitar la protección a través del máximo valor de TTL (time to live) – GTSM (generalized TTL security mechanism) -, LPTS (local packet transport protocol), MD5 o keychain/TCP-OA (object autentication) para la validación de anuncios.
- Contra inyección de información de ruteo falso por un partner: instrumentar autorización de orígenes y SIDR para autenticar rutas.
- Ataques con políticas de ruteo y atributos de ruteo BGP: Flexible RPL, BGP attribute filtering y BGP error handling.
- Para evitar que el secuestro de direcciones dirija a clientes a falsos sitios Web: instrumentar autenticación de AS origen y emplear SIDR (secure interdomain routing).
- Instrumentar RPKI (resource public key infrastructure) para verificar criptográficamente las asociaciones de sistemas autónomos y sus direcciones IP.
- Optimizar el filtrado de lo conocido como BOGONS: un BOGON es una dirección IP falsa, y un nombre informal para un paquete IP sobre el Internet público que “reclama” ser de un área de direcciones IP reservadas, pero no son delegadas o asignadas por IANA o por un delegado regional (RIR–regional Internet registry), las áreas de espacios de direcciones sin asignar son llamadas bogon spaces. La mayoría de los ISP y firewalls de usuarios finales filtran estos espacios de direcciones dado que no tienen un uso legítimo.
.
Conclusión
Aunque el entorno analizado en este artículo suele estar fuera del alcance del análisis de ambientes empresariales comunes, quise llamar la atención sobre el hecho de que las aplicaciones empresariales suelen descansar, al menos en parte, en la infraestructura del proveedor de servicios. Por ello no debe dejarse de lado el análisis de seguridad en el carrier y, como usuarios finales, debemos pedir a nuestros proveedores que se preocupen y nos informen de la parte que a ellos compete.
[i] Proceeding. SIGCOMM ’02 Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications Pages 3-16
ACM New York, NY, USA ©2002
Deja tu comentario