Internet parece una estructura fuerte, independiente e inquebrantable. En teoría, la robustez de la red sería suficiente para sobrevivir a una explosión nuclear. En la realidad, Internet puede caerse por un pequeño router. Todo esto se debe a que Internet es un conglomerado de contradicciones, vulnerabilidades, errores y videos de gatos. La base de Internet, el protocolo BGP, tiene un montón de problemas. Es sorprendente que aún esté en funcionamiento. Además de los errores en Internet, este es vulnerado por todos: grandes proveedores de Internet, corporaciones, gobiernos y ataques DDoS. ¿Qué hacer con esto y cómo vivir con ello?
La respuesta la sabe Alexey Uchakin () es el líder del equipo de ingenieros de redes en la empresa IQ Option. Su principal tarea es garantizar la disponibilidad de la plataforma para los usuarios. En la transcripción de la presentación de Alexey en , hablaremos sobre BGP, ataques DDoS, el interruptor de Internet, los errores de los proveedores, la descentralización y casos en los que un pequeño router hizo que Internet se fuera a dormir. Al final, habrá algunos consejos sobre cómo sobrellevar todo esto.
El día en que Internet se cayó
Solo mencionaré algunos incidentes en los que se perdió la conectividad en Internet. Esto será suficiente para tener una imagen completa.
«El incidente de AS7007». La primera vez que Internet se cayó fue en abril de 1997. En el software de un router de la autónoma 7007 había un error. En algún momento, el router anunció a sus vecinos su tabla de enrutamiento interna y envió la mitad de la red a un agujero negro.
«Pakistán contra YouTube». En 2008, unos valientes de Pakistán decidieron bloquear YouTube en su país. Lo hicieron de tal manera que medio mundo se quedó sin gatos.
«Intercepción de los prefijos de VISA, MasterCard y Symantec por Rostelecom». En 2017, Rostelecom, por error, comenzó a anunciar los prefijos de VISA, MasterCard y Symantec. Como resultado, el tráfico financiero fue desviado a través de canales controlados por el proveedor. La fuga duró poco tiempo, pero las empresas financieras se sintieron incómodas.
«Google contra Japón». En agosto de 2017, Google comenzó a anunciar en parte de sus enlaces ascendentes los prefijos de los grandes proveedores japoneses NTT y KDDI. El tráfico fue dirigido a Google como transitario, probablemente por error. Dado que Google no es un proveedor y no transmite tráfico de paso, gran parte de Japón se quedó sin Internet.
«DV LINK ha capturado los prefijos de Google, Apple, Facebook, Microsoft». En 2017, el proveedor ruso DV LINK comenzó a anunciar las redes de Google, Apple, Facebook, Microsoft y algunos otros grandes jugadores.
«eNet de EE. UU. ha capturado los prefijos de AWS Route53 y MyEtherwallet». En 2018, un proveedor de Ohio o alguien de sus clientes anunció las redes de Amazon Route53 y la cartera de criptomonedas MyEtherwallet. El ataque fue exitoso: a pesar de un certificado autofirmado, que mostraba una advertencia al usuario al acceder al sitio de MyEtherwallet, muchas carteras fueron hackeadas y parte de la criptomoneda robada.
¡Hubo más de 14,000 incidentes similares solo en 2017! La red todavía es descentralizada, por lo que no se rompe todo ni para todos. Pero los incidentes ocurren por miles, y todos están relacionados con el protocolo BGP, que es la base de Internet.
BGP y sus problemas
Protocolo BGP — Protocolo de Gateway de Frontera, fue descrito por primera vez en 1989 por dos ingenieros de IBM y Cisco Systems en tres «servilletas»— hojas de papel A4. Estas todavía reposan en la oficina principal de Cisco Systems en San Francisco como una reliquia del mundo de las redes.
En el corazón del protocolo están las interacciones de sistemas autónomos — Sistemas Autónomos o, en abreviatura, AS. Un sistema autónomo es simplemente un ID asignado a redes IP en un registro público. Un router con tal ID puede anunciar estas redes al mundo. Así, cualquier ruta en Internet se puede representar como un vector, conocido como AS Path. El vector consiste en números de sistemas autónomos que hay que atravesar para llegar a la red de destino.
Por ejemplo, hay una red compuesta por varios sistemas autónomos. Necesitamos llegar del sistema AS65001 al sistema AS65003. El camino de un sistema está representado por un AS Path en el esquema. Consiste en dos autónomos: 65002 y 65003. Para cada dirección de destino hay un vector AS Path que consiste en los números de los sistemas autónomos que debemos atravesar.
Entonces, ¿cuáles son los problemas de BGP?
BGP es un protocolo de confianza
El protocolo BGP es basado en confianza. Esto significa que, por defecto, confiamos en nuestro vecino. Esta es una característica de muchos protocolos que fueron desarrollados en los comienzos de Internet. Profundicemos en lo que significa 'confiar'.
No hay autenticación del vecino. Formalmente hay MD5, pero MD5 en 2019 es... vamos, no es lo mejor...
No hay filtrado. BGP tiene filtros y están descritos, pero no se utilizan o se utilizan incorrectamente. Más tarde explicaré por qué.
Es muy fácil establecer una vecindad. La configuración de la vecindad en el protocolo BGP en casi cualquier enrutador es solo un par de líneas de configuración.
No se requieren permisos para gestionar BGP. No necesitas presentar exámenes que validen tu calificación. Nadie te quitará los derechos por configurar BGP bajo la influencia del alcohol.
Dos problemas principales
Secuestros de prefijos - prefix hijacks. El secuestro de prefijos es anunciar una red que no te pertenece, como en el caso de MyEtherwallet. Tomamos algunos prefijos, acordamos con el proveedor o lo hackeamos, y a través de él anunciamos estas redes.
Filtraciones de rutas - route leaks. Las filtraciones son un poco más complicadas. Una filtración es un cambio en el AS Path. En el mejor de los casos, el cambio provocará una mayor latencia, porque hay que recorrer una ruta más larga o a través de un enlace menos eficiente. En el peor de los casos, se repetirá el caso de Google y Japón.
Google mismo no es un operador ni un sistema autónomo de tránsito. Pero cuando anunció a su proveedor las redes de los operadores japoneses, el tráfico a través de Google se consideraba más prioritario en el AS Path. El tráfico se desvió allí y se perdió simplemente porque la configuración del enrutamiento dentro de Google es más compleja que solo los filtros en la frontera.
¿Por qué no funcionan los filtros?
A nadie le importa. Esta es la razón principal: a todos les da lo mismo. Un administrador de un pequeño proveedor o empresa, que se ha conectado a un proveedor a través de BGP, tomó un MikroTik, configuró BGP en él y ni siquiera sabe que se pueden configurar filtros.
Errores de configuración. Algo se depuró, se cometió un error en la máscara, se configuró una red incorrecta y, de nuevo, todo mal.
No hay posibilidad técnica. Por ejemplo, los proveedores de telecomunicaciones tienen muchos clientes. De manera inteligente, se deberían actualizar automáticamente los filtros para cada cliente: seguir que tenga una nueva red, que alquile su red a alguien. Seguir esto es complicado, hacerlo manualmente es aún más difícil. Por eso simplemente se ponen filtros permisivos o no se ponen filtros en absoluto.
Excepciones. Hay excepciones para clientes favoritos y grandes. Especialmente en el caso de los puntos de interconexión entre operadores. Por ejemplo, TransTelecom y Rostelecom tienen muchas redes y hay interconexiones entre ellas. Si falla la interconexión, a nadie le irá bien, por lo tanto, se relajan o eliminan los filtros por completo.
Información obsoleta o no actual en IRR. Los filtros se construyen sobre la base de la información que está registrada en IRR — Registro de Enrutamiento de Internet. Estos son registros de registradores regionales de internet. A menudo, en los registros hay información obsoleta o no actual, o ambas.
¿Quiénes son estos registradores?
Todas las direcciones en internet pertenecen a la organización IANA — Autoridad de Números Asignados de Internet. Cuando compras una red IP a alguien, no compras las direcciones, sino el derecho a usarlas. Las direcciones son un recurso intangible y, por acuerdo general, todas pertenecen a la agencia IANA.
El sistema funciona así. IANA delega la gestión de direcciones IP y números de sistemas autónomos a cinco registradores regionales. Ellos emiten sistemas autónomos LIR — registradores de internet locales. Luego, los LIR asignan direcciones IP a los usuarios finales.
El inconveniente del sistema es que cada uno de los registradores regionales lleva sus registros a su manera. Cada uno tiene sus propias opiniones sobre qué información debe incluirse en los registros, quién debe o no debe verificarla. Como resultado, se obtiene el desorden que existe actualmente.
¿Cómo más se puede combatir estos problemas?
IRR — calidad mediocre. En IRR está claro: todo está mal.
Comunidades BGP. Este es un atributo que está descrito en el protocolo. Podemos adjuntar, por ejemplo, una comunidad especial a nuestro anuncio, para que el vecino no envíe nuestras redes a sus vecinos. Cuando tenemos un enlace P2P, intercambiamos solo nuestras redes. Para que accidentalmente una ruta no se dirija a otras redes, adjuntamos la comunidad.
Las comunidades no son transitivas. Siempre es un acuerdo entre dos, y esa es su debilidad. No podemos adjuntar cualquier comunidad, excepto una que sea aceptada por defecto por todos. No podemos estar seguros de que esta comunidad sea aceptada e interpretada correctamente. Por lo tanto, en el mejor de los casos, si llegas a un acuerdo con tu uplink, él entenderá lo que deseas a través de la comunidad. Pero su vecino puede no entenderlo, o el operador simplemente puede eliminar tu etiqueta, y no lograrás lo que querías.
RPKI + ROA solo resuelve una pequeña parte de los problemas. RPKI es Infraestructura de Clave Pública de Recursos — un marco especial para firmar información de enrutamiento. Es una buena idea para hacer que los LIR y sus clientes mantengan una base de datos actualizada del espacio de direcciones. Pero hay un problema con ello.
RPKI es también un sistema jerárquico de claves públicas. IANA tiene una clave, a partir de la cual se generan las claves RIR, y de ellas las claves LIR, con las que firman su espacio de direcciones mediante ROAs — Autorizaciones de Origen de Enrutamiento:
— Certifico que este prefijo será anunciado en nombre de esta autonomía.
Además de ROA, existen otros objetos, pero de ellos hablaremos en otra ocasión. Parece que es una herramienta buena y útil. Sin embargo, no nos protege de las filtraciones en absoluto y no resuelve todos los problemas de robo de prefijos. Por lo tanto, los actores no tienen mucha prisa por implementarlo. Aunque ya hay garantías de grandes jugadores como AT&T y grandes IXs de que los prefijos con registros ROA inválidos serán descartados.
Quizás lo harán, pero por ahora tenemos una gran cantidad de prefijos que no están firmados de ninguna manera. Por un lado, no está claro si se anuncian de manera válida. Por otro lado, no podemos descartarlos por defecto porque no estamos seguros de si es correcto o no.
¿Qué más hay?
BGPSec. Es una buena cosa que fue ideada por académicos para la red de ponys rosas. Ellos dijeron:
— Tenemos RPKI + ROA, un mecanismo de certificación de la firma del espacio de direcciones. Creamos un atributo BGP separado y lo llamamos BGPSec Path. Cada enrutador firmará con su firma los anuncios que propaga a sus vecinos. Así obtendremos un camino de confianza de una cadena de anuncios firmados que podremos verificar.
En teoría es bueno, pero en la práctica hay muchos problemas. BGPSec rompe muchas mecánicas existentes de BGP relacionadas con la selección de next-hop y la gestión del tráfico entrante/saliente directamente en el enrutador. BGPSec no funciona hasta que el 95% de los participantes en el mercado lo implementen, lo cual es utópico.
BGPSec tiene enormes problemas de rendimiento. En el hardware actual, la velocidad de verificación de anuncios es de aproximadamente 50 prefijos por segundo. Para ponerlo en perspectiva: la tabla actual de internet, que contiene 700,000 prefijos, tardará 5 horas en actualizarse, periodo durante el cual cambiarán 10 veces más.
BGP Open Policy (BGP basado en roles). Una propuesta reciente basada en el modelo Gao-Rexford. Son dos académicos que se dedican a investigar el BGP.
El modelo Gao-Rexford se basa en lo siguiente. Simplificando, en el caso de BGP hay un pequeño número de tipos de interacciones:
- Proveedor Cliente;
- P2P;
- interacción interna, digamos, iBGP.
Sobre la base del rol del enrutador, ya se pueden aplicar por defecto ciertas políticas de importación/exportación. El administrador no necesita configurar listas de prefijos. Con base en el rol que acuerden los enrutadores entre sí y que se puede establecer, ya obtenemos algunos filtros predeterminados. Actualmente es un borrador que se está discutiendo en la IETF. Espero que pronto lo veamos en forma de RFC y en implementación en hardware.
Grandes proveedores de Internet
Tomemos como ejemplo al proveedor CenturyLink.Es el tercer proveedor más grande de EE. UU., que atiende a 37 estados y tiene 15 centros de datos.
En diciembre de 2018, CenturyLink estuvo inactivo en el mercado estadounidense durante 50 horas. Durante el incidente, hubo problemas con el funcionamiento de los cajeros automáticos en dos estados, y el número 911 no funcionó durante varias horas en cinco estados. Además, se suspendió una lotería en Idaho. La Comisión Federal de Comunicaciones de EE. UU. está actualmente investigando este incidente.
La causa de la tragedia fue una tarjeta de red en un centro de datos. La tarjeta falló, enviaba paquetes incorrectos y todos los 15 centros de datos del proveedor se cayeron.
Para este proveedor, la idea de "demasiado grande para caer"no funcionó. Esta idea en realidad no es válida. Se puede tomar a cualquier jugador grande y provocar su caída con algo pequeño. En EE. UU. aún hay buena conectividad. Los clientes de CenturyLink que tenían respaldo abandonaron masivamente la red. Luego, los operadores alternativos se quejaron de la sobrecarga de sus enlaces.
Si cayera, por ejemplo, "Kazakhtelecom", todo el país se quedaría sin Internet.
Corporaciones
¿Quizás Google, Amazon, Facebook y otras corporaciones mantienen el Internet? No, ellos también lo rompen.
En 2017, en San Petersburgo, en la conferencia ENOG13 Jeff Houston de APNIC presentó En ella se menciona que nos hemos acostumbrado a pensar que la interacción, los flujos de dinero y tráfico en Internet son verticales. Tenemos pequeños proveedores que pagan por la conectividad a proveedores más grandes, y estos a su vez pagan por la conectividad al tránsito global.
Ahora tenemos una estructura verticalmente orientada. Todo estaría bien, pero el mundo está cambiando: los grandes actores están construyendo sus cables transoceánicos para establecer sus propios backbones.
Noticia sobre el cable CDN.
En 2018, TeleGeography publicó un estudio que indicaba que más de la mitad del tráfico en Internet ya no es Internet, sino backbones de CDN de grandes actores. Es tráfico relacionado con Internet, pero ya no es esa red de la que hablamos.
Internet se está fragmentando en un gran conjunto de redes débilesmente conectadas entre sí.
Microsoft tiene su propia red, Google tiene la suya, y entre sí se conectan débilmente. El tráfico que se origina en algún lugar de EE. UU. viaja por los canales de Microsoft a través del océano hacia Europa, donde en algún momento llega a un CDN, luego se conecta con su proveedor a través del CDN o IX y llega a su enrutador.
La descentralización está desapareciendo.
Esta fortaleza del Internet, que le ayuda a sobrevivir después de una explosión nuclear, se está perdiendo. Están surgiendo lugares de concentración de usuarios y tráfico. Si cae Google Cloud, habrá muchos afectados de inmediato. En parte lo sentimos cuando el Roskomnadzor bloqueó AWS. Y en el caso de CenturyLink, se puede ver que basta con un pequeño problema.
Antes no se caía todo y no a todos. En el futuro, podemos llegar a un punto donde, al afectar a un gran actor, se puede romper mucho, en muchos lugares y para muchos.
Estados
Los próximos en la lista son los estados, y con ellos sucede generalmente así.
Aquí nuestro Roskomnadzor ni siquiera es pionero. Prácticas similares de apagón de Internet existen en Irán, India, Pakistán. En Inglaterra hay un proyecto de ley sobre la posibilidad de desconectar Internet.
Cualquier gran estado desea tener un interruptor para desconectar Internet, ya sea por completo o en partes: Twitter, Telegram, Facebook. No es que no comprendan que esto nunca funcionará, pero realmente lo desean. Usan el interruptor, por lo general, con fines políticos: para eliminar competidores políticos, o cuando las elecciones están a la vista, o los hackers rusos nuevamente rompieron algo.
Ataques DDoS
No voy a quitarles el trabajo a mis compañeros de Qrator Labs, ellos lo hacen mucho mejor que yo. Tienen sobre la estabilidad de Internet. Y esto es lo que escribieron en el informe de 2018.
La duración media de los ataques DDoS se reduce a 2.5 horas.. Los atacantes también comienzan a contar dinero, y si el recurso no cae de inmediato, rápidamente lo dejan en paz.
Aumenta la intensidad de los ataques. En 2018, vimos 1.7 Tb/s en la red Akamai, y eso no es el límite.
Aparecen nuevos vectores de ataque y se intensifican los antiguos. Emergen nuevos protocolos susceptibles a la amplificación, y aparecen nuevos ataques sobre protocolos existentes, especialmente sobre TLS y similares.
La mayor parte del tráfico proviene de dispositivos móviles. En este sentido, el tráfico de Internet se traslada a los clientes móviles. Esto debe ser manejado tanto por quienes atacan como por quienes se defienden.
No hay invulnerables. Este es el mensaje principal: no existe ni existirá una protección universal que proteja de cualquier DDoS.
Un sistema no puede caerse, a menos que no esté conectado a Internet.
Espero haberlos asustado lo suficiente. Ahora pensemos en qué hacer al respecto.
¿Qué hacer?!
Si tienes tiempo libre, ganas y conocimiento de inglés, participa en grupos de trabajo: IETF, RIPE WG. Estas son listas de correo abiertas, suscríbete a los boletines, participa en discusiones, asiste a conferencias. Si tienes estatus LIR, puedes votar, por ejemplo, en RIPE sobre diversas iniciativas.
Para los mortales comunes, esto es monitoreo. Para saber qué se ha roto.
Monitoreo: ¿qué verificar?
Ping normal, y no solo una verificación binaria: funciona o no. Registra el RTT en la historia, para observar anomalías más tarde.
Traceroute. Es una herramienta para determinar las rutas de los datos en redes TCP/IP. Ayuda a identificar anomalías y bloqueos.
Checks de HTTP para URL personalizadas y certificados TLS ayudarán a detectar bloqueos o una suplantación de DNS para un ataque, que es prácticamente lo mismo. Los bloqueos a menudo se realizan mediante la suplantación de DNS y el redireccionamiento del tráfico a una página de aviso.
Si es posible, verifica a través de tus clientes la resolución de tu origen desde diferentes lugares, si tienes una aplicación. Así descubrirás anomalías de suplantación de DNS, algo que algunos proveedores cometen ocasionalmente.
Monitoreo: ¿desde dónde verificar?
No hay respuesta universal. Verifica desde donde proviene el usuario. Si los usuarios están en Rusia, verifica desde Rusia, pero no te limites a ella. Si tus usuarios viven en diferentes regiones, verifica desde esas regiones. Pero lo mejor es desde todo el mundo.
Monitoreo: ¿qué usar para verificar?
He pensado en tres métodos. Si conoces más, escríbelo en los comentarios.
- RIPE Atlas.
- Monitoreo comercial.
- Tu propia red de virtuales.
Hablemos de cada uno de ellos.
RIPE Atlas — es una pequeña caja. Para aquellos que conocen el 'Revisor' local, es la misma caja, pero con otra etiqueta.
RIPE Atlas es un programa gratuito. Te registras, recibes un router por correo y lo conectas a la red. Por el hecho de que alguien más está utilizando tu prueba, ganas algunos créditos. Con esos créditos puedes realizar algunas investigaciones. Puedes probar de varias maneras: ping, traceroute, verificar certificados. La cobertura es bastante amplia, hay muchas nodos. Pero hay matices.
El sistema de créditos no permite construir soluciones de producción. Los créditos no son suficientes para investigaciones continuas o monitoreo comercial. Son suficientes para una investigación corta o una verificación puntual. La norma diaria con una prueba se consume con 1-2 verificaciones.
La cobertura es desigual. Dado que el programa es gratuito en ambos sentidos, la cobertura es buena en Europa, en la parte europea de Rusia y en algunas regiones. Pero si necesitas Indonesia o Nueva Zelanda, la situación empeora mucho; puede que no se logren 50 pruebas por país.
No se puede verificar http desde la prueba. Esto se debe a matices técnicos. Prometen solucionar esto en la nueva versión, pero por ahora no se puede verificar http. Solo se puede verificar el certificado. Alguna verificación http se puede hacer solo hasta un dispositivo especial de RIPE Atlas llamado Anchor.
La segunda forma es el monitoreo comercial. Con eso todo está bien, ¿verdad? Pagas dinero. Te prometen varias decenas o cientos de puntos de monitoreo en todo el mundo, te proporcionan bonitos dashboards 'listos para usar'. Pero, de nuevo, hay problemas.
Es costoso, en algunos lugares muy. El monitoreo por ping, las verificaciones desde todo el mundo y numerosas verificaciones http pueden costar varios miles de dólares al año. Si las finanzas lo permiten y te gusta esta solución, adelante.
La cobertura puede no ser suficiente en la región de interés. Con el mismo ping solo se puede especificar una parte abstracta del mundo: Asia, Europa, América del Norte. Raros sistemas de monitoreo pueden detallar la prueba hasta un país o región específicos.
Débil apoyo para pruebas personalizadas. Si necesita algo personalizado y no solo un simple «kurlyk» en la URL, también hay problemas con eso.
El tercer método es su propia monitorización.. Es un clásico: «¡Vamos a crear la nuestra!»
Su propia monitorización se convierte en el desarrollo de un producto de software, y además distribuido. Usted busca un proveedor de infraestructura, observa cómo implementarlo y monitorearlo, porque la monitorización también necesita ser monitoreada, ¿verdad? Y también se requiere soporte. Piénselo bien diez veces antes de embarcarse en esto. Tal vez sea más fácil pagar a alguien que lo haga por usted.
Monitorización de anomalías BGP y ataques DDoS.
Aquí, en cuanto a los recursos disponibles, es aún más sencillo. Las anomalías BGP se detectan utilizando servicios especializados como QRadar, BGPmon.. Ellos aceptan la tabla de vista completa de múltiples operadores. Basándose en lo que ven de diferentes operadores, pueden detectar anomalías, buscar amplificadores, etc. Usualmente el registro es gratuito: ingresa el número de su autónomo, se suscribe a las notificaciones por correo electrónico, y el servicio alerta sobre sus problemas.
En la monitorización de ataques DDoS también es todo sencillo. Generalmente, esto es basado en NetFlow y registros.. Existen sistemas especializados como FastNetMon, módulos para Splunk. En caso extremo, está su proveedor de protección DDoS. También puede enviarle NetFlow y, con base en eso, le alertará sobre ataques dirigidos hacia usted.
Conclusiones
No se haga ilusiones: Internet seguramente se caerá.. No todo se caerá y no será para todos, pero 14 mil incidentes en 2017 sugieren que habrá incidentes.
Su tarea es detectar problemas lo antes posible.. Al menos, no más tarde que su usuario. No solo es necesario notar, siempre tenga un «plan B» en reserva. El plan es la estrategia sobre lo que hará cuando todo falle:operadores de reserva, centros de datos, CDN. El plan es una lista de verificación separada, a la que se refiere para comprobar el funcionamiento de todo. El plan debe funcionar sin involucrar a ingenieros de redes, porque suelen ser escasos y quieren dormir.
Eso es todo. Les deseo alta disponibilidad y monitorización en verde.
La próxima semana se espera sol en Novosibirsk, carga alta y alta concentración de desarrolladores en . Se prevé en Siberia un frente de presentaciones sobre monitoreo, disponibilidad y pruebas, seguridad y gestión. Se esperan precipitaciones en forma de apuntes, networking, fotografías y publicaciones en redes sociales. Recomendamos posponer todos los asuntos el 24 y 25 de junio y . ¡Te esperamos en Siberia!
Fuente: habr.com
