Internet parece ser unha estrutura forte, independente e indestructible. En teoría, a rede é o suficientemente forte como para sobrevivir a unha explosión nuclear. En realidade, Internet pode soltar un pequeno enrutador. Todo porque Internet é unha morea de contradicións, vulnerabilidades, erros e vídeos sobre gatos. A columna vertebral de Internet, BGP, está chea de problemas. É incrible que siga respirando. Ademais dos erros na propia Internet, tamén está roto por todos e todas: grandes provedores de Internet, corporacións, estados e ataques DDoS. Que facer e como vivir con el?
Coñece a resposta Alexey Uchakin () é o líder dun equipo de enxeñeiros de rede en IQ Option. A súa principal tarefa é a accesibilidade da plataforma para os usuarios. Na transcrición do informe de Alexey sobre Falemos de BGP, ataques DDOS, conmutadores de Internet, erros do provedor, descentralización e casos nos que un pequeno enrutador enviou Internet para durmir. Ao final, un par de suxestións sobre como sobrevivir a todo isto.
O día que se rompeu Internet
Vou citar só algúns incidentes nos que se rompeu a conectividade de Internet. Isto será suficiente para a imaxe completa.
"Incidente AS7007". A primeira vez que Internet rompeu foi en abril de 1997. Houbo un erro no software dun enrutador do sistema autónomo 7007. Nalgún momento, o enrutador anunciou a súa táboa de enrutamento interno aos seus veciños e enviou a metade da rede a un burato negro.
"Paquistán contra YouTube". En 2008, rapaces valentes de Paquistán decidiron bloquear YouTube. Fixérono tan ben que medio mundo quedou sen gatos.
"Captura de prefixos VISA, MasterCard e Symantec por parte de Rostelecom". En 2017, Rostelecom comezou a anunciar por erro os prefixos VISA, MasterCard e Symantec. Como resultado, o tráfico financeiro foi encamiñado a través de canles controladas polo provedor. A filtración durou pouco, pero foi desagradable para as empresas financeiras.
Google vs Xapón. En agosto de 2017, Google comezou a anunciar os prefixos dos principais provedores xaponeses NTT e KDDI nalgúns dos seus enlaces ascendentes. O tráfico enviouse a Google como tránsito, probablemente por erro. Dado que Google non é un provedor e non permite o tráfico de transporte público, unha parte importante de Xapón quedou sen Internet.
"DV LINK capturou os prefixos de Google, Apple, Facebook, Microsoft". Tamén en 2017, o provedor ruso DV LINK, por algún motivo, comezou a anunciar as redes de Google, Apple, Facebook, Microsoft e algúns outros principais xogadores.
"eNet dos EUA capturou os prefixos AWS Route53 e MyEtherwallet". En 2018, o provedor de Ohio ou un dos seus clientes anunciou as redes de carteira criptográfica Amazon Route53 e MyEtherwallet. O ataque foi exitoso: mesmo a pesar do certificado autoasinado, un aviso sobre o que apareceu ao usuario ao entrar no sitio web de MyEtherwallet, moitas carteiras foron secuestradas e parte da moeda criptográfica foi roubada.
Só en 2017 houbo máis de 14 incidentes deste tipo! A rede aínda está descentralizada, polo que non todo e non todos se rompen. Pero hai miles de incidencias, todas relacionadas co protocolo BGP que alimenta Internet.
BGP e os seus problemas
Protocolo BGP - Border Gateway Protocol, foi descrito por primeira vez en 1989 por dous enxeñeiros de IBM e Cisco Systems en tres "servilletas" - follas A4. Estes segue sentado na sede de Cisco Systems en San Francisco como unha reliquia do mundo das redes.
O protocolo baséase na interacción de sistemas autónomos - Sistemas autónomos ou AS para abreviar. Un sistema autónomo é simplemente un ID ao que se asignan redes IP no rexistro público. Un enrutador con este ID pode anunciar estas redes ao mundo. En consecuencia, calquera ruta en Internet pódese representar como un vector, que se chama Camiño AS. O vector está formado polo número de sistemas autónomos que se deben atravesar para chegar á rede de destino.
Por exemplo, existe unha rede de varios sistemas autónomos. Debe pasar do sistema AS65001 ao sistema AS65003. O camiño dun sistema está representado por AS Path no diagrama. Consta de dous sistemas autónomos: 65002 e 65003. Para cada enderezo de destino hai un vector AS Path, que consta dos números de sistemas autónomos polos que debemos pasar.
Entón, cales son os problemas con BGP?
BGP é un protocolo de confianza
O protocolo BGP está baseado na confianza. Isto significa que confiamos no noso veciño por defecto. Esta é unha característica de moitos protocolos que se desenvolveron nos albores mesmos de Internet. Imos descubrir o que significa "confianza".
Sen autenticación de veciño. Formalmente, hai MD5, pero MD5 en 2019 é só iso...
Sen filtrado. BGP ten filtros e descríbense, pero non se usan nin se usan incorrectamente. Explicarei por que máis tarde.
É moi sinxelo montar un barrio. Configurar un barrio no protocolo BGP en case calquera enrutador son un par de liñas da configuración.
Non se precisan dereitos de xestión de BGP. Non é necesario presentarse a exames para acreditar as súas cualificacións. Ninguén che quitará os dereitos para configurar BGP estando borracho.
Dous problemas principais
Secuestros de prefixos. O secuestro de prefixos é anunciar unha rede que non che pertence, como é o caso de MyEtherwallet. Collemos algúns prefixos, acordamos co provedor ou pirateámolos e a través del anunciamos estas redes.
Rutas de fugas. As filtracións son un pouco máis complicadas. A fuga é un cambio en AS Path. No mellor dos casos, o cambio provocará un maior atraso porque necesitas percorrer unha ruta máis longa ou nunha ligazón menos ampla. No peor dos casos, repetirase o caso de Google e Xapón.
Google en si non é un operador nin un sistema de tránsito autónomo. Pero cando anunciou as redes dos operadores xaponeses ao seu provedor, o tráfico a través de Google a través de AS Path foi visto como unha prioridade. O tráfico foi alí e caeu simplemente porque a configuración de enrutamento dentro de Google é máis complexa que os filtros na fronteira.
Por que non funcionan os filtros?
A ninguén lle importa. Esta é a razón principal: a ninguén lle importa. O administrador dun pequeno provedor ou empresa que se conectou co provedor a través de BGP tomou MikroTik, configurou BGP nel e nin sequera sabe que alí se poden configurar filtros.
Erros de configuración. Empuxaron algo, cometeron un erro na máscara, puxéronse a malla equivocada, e agora hai un erro de novo.
Sen posibilidade técnica. Por exemplo, os provedores de telecomunicacións teñen moitos clientes. O máis intelixente é actualizar automaticamente os filtros de cada cliente: controlar que ten unha rede nova, que alugou a súa rede a alguén. É difícil seguir isto, e aínda máis difícil coas mans. Polo tanto, simplemente instalan filtros relaxados ou non instalan filtros en absoluto.
Excepcións. Hai excepcións para clientes amados e grandes. Especialmente no caso das interfaces entre operadores. Por exemplo, TransTeleCom e Rostelecom teñen unha morea de redes e hai unha interface entre elas. Se a articulación cae, non será bo para ninguén, polo que os filtros están relaxados ou eliminados por completo.
Información desactualizada ou irrelevante no TIR. Os filtros constrúense en función da información que se rexistra IRR - Rexistro de enrutamento de Internet. Estes son rexistros dos rexistradores rexionais de Internet. Moitas veces, os rexistros conteñen información obsoleta ou irrelevante, ou ambas.
Quen son estes rexistradores?
Todos os enderezos de Internet pertencen á organización IANA - Internet Assigned Numbers Authority. Cando compras unha rede IP a alguén, non estás a mercar enderezos, senón o dereito a usalos. Os enderezos son un recurso inmaterial e de común acordo son todos propiedade da IANA.
O sistema funciona así. A IANA delega a xestión dos enderezos IP e dos números do sistema autónomo en cinco rexistradores rexionais. Emiten sistemas autónomos LIR - rexistradores locais de internet. A continuación, os LIR asignan enderezos IP aos usuarios finais.
O inconveniente do sistema é que cada un dos rexistradores autonómicos mantén os seus rexistros á súa maneira. Cada un ten o seu propio punto de vista sobre que información debe conter nos rexistros e quen debe ou non verificala. O resultado é a desorde que temos agora.
De que outra maneira podes combater estes problemas?
IRR - calidade mediocre. Está claro con IRR: todo está mal alí.
Comunidades BGP. Este é un dos atributos que se describen no protocolo. Podemos achegar, por exemplo, unha comunidade especial ao noso anuncio para que un veciño non envíe as nosas redes aos seus veciños. Cando temos unha ligazón P2P, só intercambiamos as nosas redes. Para evitar que a ruta vaia accidentalmente a outras redes, engadimos comunidade.
As comunidades non son transitivas. Sempre é un contrato para dous, e este é o seu inconveniente. Non podemos asignar ningunha comunidade, a excepción dunha, que é aceptada por defecto por todos. Non podemos estar seguros de que todos acepten esta comunidade e a interpretarán correctamente. Polo tanto, no mellor dos casos, se estás de acordo coa túa ligazón ascendente, entenderá o que queres del en termos de comunidade. Pero o teu veciño pode non entender, ou o operador simplemente restablecerá a túa etiqueta e non conseguirás o que querías.
RPKI + ROA resolve só unha pequena parte dos problemas. RPKI é Recursos Infraestrutura de chave pública — un marco especial para asinar información de enrutamento. É unha boa idea obrigar aos LIR e aos seus clientes a manter unha base de datos de espazos de enderezos actualizada. Pero hai un problema con iso.
RPKI tamén é un sistema de clave pública xerárquica. A IANA ten unha clave a partir da cal se xeran as claves RIR e a partir de que as claves LIR se xeran? co que asinan o seu espazo de enderezos mediante ROAs - Route Origin Authorisations:
— Asegúrolle que este prefixo será anunciado en nome desta comunidade autónoma.
Ademais do ROA, hai outros obxectos, pero máis sobre eles máis tarde. Parece unha cousa boa e útil. Pero non nos protexe das filtracións da palabra "en absoluto" e non resolve todos os problemas co secuestro de prefixos. Polo tanto, os xogadores non teñen présa en implementalo. Aínda que xa hai garantías de grandes xogadores como AT&T e grandes empresas IX de que se eliminarán os prefixos cun rexistro de ROA non válido.
Quizais o fagan, pero polo momento temos un gran número de prefixos que non están asinados de ningún xeito. Por unha banda, non está claro se están validamente anunciados. Por outra banda, non podemos eliminalos por defecto, porque non estamos seguros de se é correcto ou non.
Que máis hai?
BGPSec. Esta é unha cousa xenial que os académicos pensaron para unha rede de pôneis rosas. Eles dixeron:
- Temos RPKI + ROA - un mecanismo para verificar sinaturas de espazo de enderezos. Creemos un atributo BGP separado e chamémoslle Ruta BGPSec. Cada router asinará coa súa propia sinatura os anuncios que anuncie aos seus veciños. Deste xeito obteremos un camiño de confianza da cadea de anuncios asinados e poderemos comprobalo.
Bo en teoría, pero na práctica hai moitos problemas. BGPsec rompe moitas mecánicas BGP existentes para seleccionar os seguintes saltos e xestionar o tráfico entrante/saínte directamente no enrutador. BGPSec non funciona ata que o 95% de todo o mercado o implantou, o que en si é unha utopía.
BGPSec ten grandes problemas de rendemento. No hardware actual, a velocidade de comprobación dos anuncios é de aproximadamente 50 prefixos por segundo. A modo de comparación: a actual táboa de Internet de 700 prefixos cargarase en 000 horas, durante as cales cambiará 5 veces máis.
Política aberta de BGP (BGP baseado en roles). Proposta fresca baseada no modelo Gao-Rexford. Estes son dous científicos que están a investigar sobre BGP.
O modelo Gao-Rexford é o seguinte. Para simplificar, con BGP hai un pequeno número de tipos de interaccións:
- Cliente provedor;
- P2P;
- comunicación interna, digamos iBGP.
En función do rol do enrutador, xa é posible asignar determinadas políticas de importación/exportación por defecto. O administrador non precisa configurar listas de prefixos. En función do papel que acorden os enrutadores entre eles e que se pode configurar, xa recibimos algúns filtros predeterminados. Este é actualmente un borrador que está a ser discutido no IETF. Espero que pronto vexamos isto en forma de RFC e implementación en hardware.
Grandes provedores de Internet
Vexamos o exemplo dun provedor CenturyLink. É o terceiro provedor dos Estados Unidos, atendendo a 37 estados e contando con 15 centros de datos.
En decembro de 2018, CenturyLink estivo no mercado estadounidense durante 50 horas. Durante o incidente, houbo problemas co funcionamento dos caixeiros automáticos en dous estados e o número 911 non estivo funcionando durante varias horas en cinco estados. A lotería en Idaho quedou completamente arruinada. O incidente está actualmente baixo investigación da Comisión de Telecomunicacións dos Estados Unidos.
A causa da traxedia foi unha tarxeta de rede nun centro de datos. A tarxeta funcionou mal, enviou paquetes incorrectos e os 15 centros de datos do provedor caeron.
A idea non funcionou para este provedor "demasiado grande para caer". Esta idea non funciona en absoluto. Podes levar a calquera xogador importante e poñer algunhas pequenas cousas encima. A EE. UU. aínda lle vai ben coa conectividade. Os clientes de CenturyLink que tiñan unha reserva entraron nela en masa. Entón os operadores alternativos queixáronse de que as súas ligazóns estaban sobrecargadas.
Se cae o condicional Kazakhtelecom, todo o país quedará sen Internet.
Corporacións
Probablemente Google, Amazon, FaceBook e outras corporacións admiten Internet? Non, tamén o rompen.
En 2017 en San Petersburgo na conferencia ENOG13 Jeff Houston de APnic introducido . Di que estamos afeitos a que as interaccións, os fluxos de diñeiro e o tráfico en Internet sexan verticais. Temos pequenos provedores que pagan a conectividade a outros máis grandes e xa pagan a conectividade ao tránsito global.
Agora temos unha estrutura tan orientada verticalmente. Todo estaría ben, pero o mundo está cambiando: os principais actores están a construír os seus cables transoceánicos para construír as súas propias columnas.
Novidades sobre o cable CDN.
En 2018, TeleGeography publicou un estudo de que máis da metade do tráfico en Internet xa non é a Internet, senón a columna vertebral CDN dos grandes xogadores. Trátase de tráfico relacionado con Internet, pero esta xa non é a rede da que falabamos.
Internet estase dividindo nun gran conxunto de redes pouco conectadas.
Microsoft ten a súa propia rede, Google ten a súa propia e teñen pouca superposición entre si. O tráfico que se orixinou nalgún lugar dos EE. UU. pasa polas canles de Microsoft a través do océano ata Europa nalgún lugar nun CDN, despois a través da CDN ou IX conéctase co teu provedor e chega ao teu enrutador.
A descentralización está a desaparecer.
Esta fortaleza de Internet, que a axudará a sobrevivir a unha explosión nuclear, estase perdendo. Aparecen lugares de concentración de usuarios e tráfico. Se o Google Cloud condicional cae, haberá moitas vítimas á vez. Sentímolo en parte cando Roskomnadzor bloqueou AWS. E o exemplo de CenturyLink demostra que ata pequenas cousas son suficientes para iso.
Anteriormente, non todo e non todos romperon. No futuro, podemos chegar á conclusión de que influíndo nun xogador importante, podemos romper moitas cousas, en moitos lugares e en moitas persoas.
Estados
Os Estados son os seguintes, e isto é o que adoita ocorrer con eles.
Aquí o noso Roskomnadzor nin sequera é un pioneiro en absoluto. Unha práctica similar de peche de Internet existe en Irán, India e Paquistán. En Inglaterra existe un proxecto de lei sobre a posibilidade de pechar Internet.
Calquera gran estado quere conseguir un interruptor para apagar Internet, xa sexa por completo ou en partes: Twitter, Telegram, Facebook. Non é que non entendan que nunca terán éxito, pero realmente o queren. O interruptor úsase, por regra xeral, con fins políticos: para eliminar competidores políticos, ou se achegan eleccións ou os hackers rusos romperon algo de novo.
Ataques DDoS
Non lles quitarei pan aos meus compañeiros de Qrator Labs, fano moito mellor ca min. Teñen sobre a estabilidade de Internet. E isto é o que escribiron no informe de 2018.
A duración media dos ataques DDoS cae a 2.5 horas. Os atacantes tamén comezan a contar cartos e, se o recurso non está dispoñible de inmediato, axiña o deixan en paz.
A intensidade dos ataques é cada vez maior. En 2018, vimos 1.7 Tb/s na rede de Akamai, e este non é o límite.
Xorden novos vectores de ataque e intensifícanse os vellos. Están xurdindo novos protocolos susceptibles de amplificación, e están xurdindo novos ataques contra os protocolos existentes, especialmente TLS e similares.
A maior parte do tráfico procede de dispositivos móbiles. Ao mesmo tempo, o tráfico de Internet trasládase aos clientes móbiles. Tanto os que atacan como os que defenden teñen que poder traballar con isto.
Invulnerable - non. Esta é a idea principal: non hai protección universal que protexa definitivamente contra calquera DDoS.
O sistema non se pode instalar a non ser que estea conectado a Internet.
Espero terche asustado o suficiente. Pensemos agora que facer ao respecto.
Que facer?!
Se tes tempo libre, ganas e coñecementos de inglés, participa nos grupos de traballo: IETF, RIPE WG. Estas son listas de correo abertas, subscríbete a listas de correo, participa en discusións, ven a conferencias. Se tes o status de LIR, podes votar, por exemplo, en RIPE por varias iniciativas.
Para simples mortais isto é vixilancia. Para saber o que está roto.
Monitorización: que comprobar?
Ping normal, e non só unha verificación binaria - funciona ou non. Grava RTT no historial para que poidas ver as anomalías máis tarde.
Traceroute. Este é un programa de utilidade para determinar rutas de datos en redes TCP/IP. Axuda a identificar anomalías e bloqueos.
HTTP comproba URL personalizados e certificados TLS axudará a detectar o bloqueo ou a suplantación de DNS para un ataque, que é practicamente o mesmo. O bloqueo adoita realizarse mediante a suplantación de DNS e convertendo o tráfico a unha páxina stub.
Se é posible, comprobe a determinación dos seus clientes sobre a súa orixe desde diferentes lugares se ten unha solicitude. Isto axudarache a detectar anomalías de secuestro de DNS, algo que ás veces fan os provedores.
Monitorización: onde comprobar?
Non hai unha resposta universal. Comproba de onde vén o usuario. Se os usuarios están en Rusia, consulta desde Rusia, pero non te limites a iso. Se os teus usuarios viven en rexións diferentes, consulta desde estas rexións. Pero mellor de todo o mundo.
Monitorización: que comprobar?
Ocorréronme tres formas. Se sabes máis, escribe nos comentarios.
- Atlas MADURO.
- Seguimento comercial.
- A túa propia rede de máquinas virtuais.
Falemos de cada un deles.
Atlas MADURO - É unha caixa tan pequena. Para aqueles que coñecen o "Inspector" doméstico - esta é a mesma caixa, pero cun adhesivo diferente.
RIPE Atlas é un programa gratuíto. Rexístrate, recibes un enrutador por correo e conéctalo á rede. Polo feito de que outra persoa use a túa mostra, obtén algúns créditos. Con estes préstamos podes investigar ti mesmo. Podes probar de diferentes xeitos: ping, traceroute, verificar certificados. A cobertura é bastante grande, hai moitos nodos. Pero hai matices.
O sistema de crédito non permite construír solucións de produción. Non haberá créditos suficientes para a investigación continua ou o seguimento comercial. Os créditos son suficientes para un estudo breve ou unha verificación única. A norma diaria dunha mostra é consumida por 1-2 controis.
A cobertura é desigual. Dado que o programa é gratuíto en ambas direccións, a cobertura é boa en Europa, na parte europea de Rusia e nalgunhas rexións. Pero se necesitas Indonesia ou Nova Zelanda, todo é moito peor: quizais non teñas 50 mostras por país.
Non podes comprobar o http dunha mostra. Isto débese a matices técnicos. Prometen solucionalo na nova versión, pero polo momento non se pode comprobar http. Só se pode verificar o certificado. Algún tipo de comprobación http só se pode facer nun dispositivo especial RIPE Atlas chamado Anchor.
O segundo método é o seguimento comercial. Todo está ben con el, estás pagando cartos, non? Prométenche varias ducias ou centos de puntos de vixilancia en todo o mundo e debuxan fermosos paneis da caixa. Pero, de novo, hai problemas.
É de pago, nalgúns sitios é moi. O seguimento de ping, as comprobacións mundiais e moitas comprobacións http poden custar varios miles de dólares ao ano. Se as finanzas o permiten e che gusta esta solución, adiante.
A cobertura pode non ser suficiente na rexión de interese. Co mesmo ping, especifícase como máximo unha parte abstracta do mundo: Asia, Europa, América do Norte. Os sistemas de monitorización raros poden explorar un país ou rexión específicos.
Soporte débil para probas personalizadas. Se necesitas algo personalizado, e non só un "rizado" na URL, tamén hai problemas con iso.
A terceira forma é o teu seguimento. Este é un clásico: "Escribamos o noso!"
O seu seguimento convértese no desenvolvemento dun produto de software e outro distribuído. Estás a buscar un provedor de infraestruturas, mira como implementalo e supervisalo: hai que supervisar o seguimento, non? E tamén se require apoio. Pense dez veces antes de asumir isto. Pode ser máis doado pagar a alguén para que o faga por ti.
Monitorización de anomalías BGP e ataques DDoS
Aquí, en función dos recursos dispoñibles, todo é aínda máis sinxelo. As anomalías de BGP son detectadas mediante servizos especializados como QRadar, BGPmon. Aceptan unha táboa de vista completa de varios operadores. Segundo o que ven de diferentes operadores, poden detectar anomalías, buscar amplificadores, etc. O rexistro adoita ser gratuíto: introduces o teu número de teléfono, subscríbete ás notificacións por correo electrónico e o servizo avisará dos teus problemas.
O seguimento dos ataques DDoS tamén é sinxelo. Normalmente isto é Baseado en NetFlow e rexistros. Hai sistemas especializados como FastNetMon, módulos para Spunk. Como último recurso, está o teu provedor de protección DDoS. Tamén pode filtrar NetFlow e, en función del, notificarache os ataques na túa dirección.
Descubrimentos
Non te fagas ilusións: Internet definitivamente romperá. Non todo e non todos van romper, pero 14 mil incidentes en 2017 deixan entrever que haberá incidencias.
A súa tarefa é detectar os problemas o antes posible. Como mínimo, non máis tarde que o teu usuario. Non só é importante ter en conta, manter sempre un "Plan B" en reserva. Un plan é unha estratexia para o que vai facer cando todo se rompe.: operadores de reserva, DC, CDN. Un plan é unha lista de verificación separada coa que verifica o traballo de todo. O plan debería funcionar sen a implicación dos enxeñeiros de rede, porque normalmente hai poucos e queren durmir.
Iso é todo. Deséxoche alta dispoñibilidade e vixilancia verde.
A próxima semana en Novosibirsk espérase sol, alta carga e unha alta concentración de desenvolvedores . En Siberia, prevese unha fronte de informes sobre vixilancia, accesibilidade e probas, seguridade e xestión. Espéranse precipitacións en forma de notas garabateadas, redes, fotografías e publicacións nas redes sociais. Recomendamos aprazar todas as actividades os días 24 e 25 de xuño e . Agardámoste en Siberia!
Fonte: www.habr.com