{"id":35550,"date":"2019-10-31T22:04:58","date_gmt":"2019-10-31T19:04:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pochemu-internet-do-sih-por-onlajn\/"},"modified":"2019-10-31T22:04:58","modified_gmt":"2019-10-31T19:04:58","slug":"pochemu-internet-do-sih-por-onlajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/pochemu-internet-do-sih-por-onlajn","title":{"rendered":"\u00bfPor qu\u00e9 Internet sigue estando en l\u00ednea?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Internet parece una estructura fuerte, independiente e inquebrantable. En teor\u00eda, la robustez de la red ser\u00eda suficiente para sobrevivir a una explosi\u00f3n nuclear. En la realidad, Internet puede caerse por un peque\u00f1o 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\u00f3n de problemas. Es sorprendente que a\u00fan est\u00e9 en funcionamiento. Adem\u00e1s de los errores en Internet, este es vulnerado por todos: grandes proveedores de Internet, corporaciones, gobiernos y ataques DDoS. \u00bfQu\u00e9 hacer con esto y c\u00f3mo vivir con ello?<\/p>\n

\"\u00bfPor
\n
\nLa respuesta la sabe Alexey Uchakin<\/b> (Night_Snake<\/a><\/noindex>) es el l\u00edder 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\u00f3n de la presentaci\u00f3n de Alexey en\u00a0Saint HighLoad++ 2019<\/a><\/noindex> , hablaremos sobre BGP, ataques DDoS, el interruptor de Internet, los errores de los proveedores, la descentralizaci\u00f3n y casos en los que un peque\u00f1o router hizo que Internet se fuera a dormir. Al final, habr\u00e1 algunos consejos sobre c\u00f3mo sobrellevar todo esto.
\n<\/a><\/noindex>
\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

El d\u00eda en que Internet se cay\u00f3<\/h2>\n

\nSolo mencionar\u00e9 algunos incidentes en los que se perdi\u00f3 la conectividad en Internet. Esto ser\u00e1 suficiente para tener una imagen completa.<\/p>\n

\u00abEl incidente de AS7007\u00bb<\/b>. La primera vez que Internet se cay\u00f3 fue en abril de 1997. En el software de un router de la aut\u00f3noma 7007 hab\u00eda un error. En alg\u00fan momento, el router anunci\u00f3 a sus vecinos su tabla de enrutamiento interna y envi\u00f3 la mitad de la red a un agujero negro.<\/p>\n

\u00abPakist\u00e1n contra YouTube\u00bb<\/b>. En 2008, unos valientes de Pakist\u00e1n decidieron bloquear YouTube en su pa\u00eds. Lo hicieron de tal manera que medio mundo se qued\u00f3 sin gatos.<\/p>\n

\u00abIntercepci\u00f3n de los prefijos de VISA, MasterCard y Symantec por Rostelecom\u00bb<\/b>. En 2017, Rostelecom, por error, comenz\u00f3 a anunciar los prefijos de VISA, MasterCard y Symantec. Como resultado, el tr\u00e1fico financiero fue desviado a trav\u00e9s de canales controlados por el proveedor. La fuga dur\u00f3 poco tiempo, pero las empresas financieras se sintieron inc\u00f3modas.<\/p>\n

\u00abGoogle contra Jap\u00f3n\u00bb<\/b>. En agosto de 2017, Google comenz\u00f3 a anunciar en parte de sus enlaces ascendentes los prefijos de los grandes proveedores japoneses NTT y KDDI. El tr\u00e1fico fue dirigido a Google como transitario, probablemente por error. Dado que Google no es un proveedor y no transmite tr\u00e1fico de paso, gran parte de Jap\u00f3n se qued\u00f3 sin Internet.<\/p>\n

\u00abDV LINK ha capturado los prefijos de Google, Apple, Facebook, Microsoft\u00bb<\/b>. En 2017, el proveedor ruso DV LINK comenz\u00f3 a anunciar las redes de Google, Apple, Facebook, Microsoft y algunos otros grandes jugadores.<\/p>\n

\u00abeNet de EE. UU. ha capturado los prefijos de AWS Route53 y MyEtherwallet\u00bb<\/b>. En 2018, un proveedor de Ohio o alguien de sus clientes anunci\u00f3 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.<\/p>\n

\u00a1Hubo m\u00e1s de 14,000 incidentes similares solo en 2017! La red todav\u00eda es descentralizada, por lo que no se rompe todo ni para todos. Pero los incidentes ocurren por miles, y todos est\u00e1n relacionados con el protocolo BGP, que es la base de Internet.<\/p>\n

BGP y sus problemas<\/h2>\n

\nProtocolo BGP \u2014 Protocolo de Gateway de Frontera<\/b>, fue descrito por primera vez en 1989 por dos ingenieros de IBM y Cisco Systems en tres \u00abservilletas\u00bb\u2014 hojas de papel A4. Estas \u00abservilletas\u00bb<\/a><\/noindex> todav\u00eda reposan en la oficina principal de Cisco Systems en San Francisco como una reliquia del mundo de las redes.<\/p>\n

En el coraz\u00f3n del protocolo est\u00e1n las interacciones de sistemas aut\u00f3nomos<\/b>\u00a0\u2014 Sistemas Aut\u00f3nomos o, en abreviatura, AS. Un sistema aut\u00f3nomo es simplemente un ID asignado a redes IP en un registro p\u00fablico. Un router con tal ID puede anunciar estas redes al mundo. As\u00ed, cualquier ruta en Internet se puede representar como un vector, conocido como AS Path<\/b>. El vector consiste en n\u00fameros de sistemas aut\u00f3nomos que hay que atravesar para llegar a la red de destino.<\/p>\n

Por ejemplo, hay una red compuesta por varios sistemas aut\u00f3nomos. Necesitamos llegar del sistema AS65001 al sistema AS65003. El camino de un sistema est\u00e1 representado por un AS Path en el esquema. Consiste en dos aut\u00f3nomos: 65002 y 65003. Para cada direcci\u00f3n de destino hay un vector AS Path que consiste en los n\u00fameros de los sistemas aut\u00f3nomos que debemos atravesar.<\/p>\n

\"\u00bfPor
\n
\nEntonces, \u00bfcu\u00e1les son los problemas de BGP?<\/p>\n

BGP es un protocolo de confianza<\/h3>\n

\nEl protocolo BGP es basado en confianza. Esto significa que, por defecto, confiamos en nuestro vecino. Esta es una caracter\u00edstica de muchos protocolos que fueron desarrollados en los comienzos de Internet. Profundicemos en lo que significa 'confiar'.<\/p>\n

No hay autenticaci\u00f3n del vecino<\/b>. Formalmente hay MD5, pero MD5 en 2019 es... vamos, no es lo mejor...<\/p>\n

No hay filtrado<\/b>. BGP tiene filtros y est\u00e1n descritos, pero no se utilizan o se utilizan incorrectamente. M\u00e1s tarde explicar\u00e9 por qu\u00e9.<\/p>\n

Es muy f\u00e1cil establecer una vecindad<\/b>. La configuraci\u00f3n de la vecindad en el protocolo BGP en casi cualquier enrutador es solo un par de l\u00edneas de configuraci\u00f3n.<\/p>\n

No se requieren permisos para gestionar BGP<\/b>. No necesitas presentar ex\u00e1menes que validen tu calificaci\u00f3n. Nadie te quitar\u00e1 los derechos por configurar BGP bajo la influencia del alcohol.<\/p>\n

Dos problemas principales<\/h3>\n

\nSecuestros de prefijos - prefix hijacks<\/b>. 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\u00e9s de \u00e9l anunciamos estas redes.<\/p>\n

Filtraciones de rutas - route leaks<\/b>. Las filtraciones son un poco m\u00e1s complicadas. Una filtraci\u00f3n es un cambio en el AS Path<\/b>. En el mejor de los casos, el cambio provocar\u00e1 una mayor latencia, porque hay que recorrer una ruta m\u00e1s larga o a trav\u00e9s de un enlace menos eficiente. En el peor de los casos, se repetir\u00e1 el caso de Google y Jap\u00f3n.<\/p>\n

Google mismo no es un operador ni un sistema aut\u00f3nomo de tr\u00e1nsito. Pero cuando anunci\u00f3 a su proveedor las redes de los operadores japoneses, el tr\u00e1fico a trav\u00e9s de Google se consideraba m\u00e1s prioritario en el AS Path. El tr\u00e1fico se desvi\u00f3 all\u00ed y se perdi\u00f3 simplemente porque la configuraci\u00f3n del enrutamiento dentro de Google es m\u00e1s compleja que solo los filtros en la frontera.<\/p>\n

\u00bfPor qu\u00e9 no funcionan los filtros?<\/h3>\n

\nA nadie le importa<\/b>. Esta es la raz\u00f3n principal: a todos les da lo mismo. Un administrador de un peque\u00f1o proveedor o empresa, que se ha conectado a un proveedor a trav\u00e9s de BGP, tom\u00f3 un MikroTik, configur\u00f3 BGP en \u00e9l y ni siquiera sabe que se pueden configurar filtros.<\/p>\n

Errores de configuraci\u00f3n<\/b>. Algo se depur\u00f3, se cometi\u00f3 un error en la m\u00e1scara, se configur\u00f3 una red incorrecta y, de nuevo, todo mal.<\/p>\n

No hay posibilidad t\u00e9cnica<\/b>. Por ejemplo, los proveedores de telecomunicaciones tienen muchos clientes. De manera inteligente, se deber\u00edan actualizar autom\u00e1ticamente 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\u00fan m\u00e1s dif\u00edcil. Por eso simplemente se ponen filtros permisivos o no se ponen filtros en absoluto.<\/p>\n

Excepciones<\/b>. Hay excepciones para clientes favoritos y grandes. Especialmente en el caso de los puntos de interconexi\u00f3n entre operadores. Por ejemplo, TransTelecom y Rostelecom tienen muchas redes y hay interconexiones entre ellas. Si falla la interconexi\u00f3n, a nadie le ir\u00e1 bien, por lo tanto, se relajan o eliminan los filtros por completo.<\/p>\n

Informaci\u00f3n obsoleta o no actual en IRR<\/b>. Los filtros se construyen sobre la base de la informaci\u00f3n que est\u00e1 registrada en\u00a0IRR \u2014 Registro de Enrutamiento de Internet<\/b>. Estos son registros de registradores regionales de internet. A menudo, en los registros hay informaci\u00f3n obsoleta o no actual, o ambas.<\/p>\n

\u00bfQui\u00e9nes son estos registradores?<\/h3>\n

\"\u00bfPor
\n
\nTodas las direcciones en internet pertenecen a la organizaci\u00f3n IANA \u2014 Autoridad de N\u00fameros Asignados de Internet<\/b>. 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.<\/p>\n

El sistema funciona as\u00ed. IANA delega la gesti\u00f3n de direcciones IP y n\u00fameros de sistemas aut\u00f3nomos a cinco registradores regionales. Ellos emiten sistemas aut\u00f3nomos LIR \u2014 registradores de internet locales<\/b>. Luego, los LIR asignan direcciones IP a los usuarios finales.<\/p>\n

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\u00e9 informaci\u00f3n debe incluirse en los registros, qui\u00e9n debe o no debe verificarla. Como resultado, se obtiene el desorden que existe actualmente.<\/p>\n

\u00bfC\u00f3mo m\u00e1s se puede combatir estos problemas?<\/h3>\n

\nIRR \u2014 calidad mediocre<\/b>. En IRR est\u00e1 claro: todo est\u00e1 mal.<\/p>\n

Comunidades BGP<\/b>. Este es un atributo que est\u00e1 descrito en el protocolo. Podemos adjuntar, por ejemplo, una comunidad especial a nuestro anuncio, para que el vecino no env\u00ede 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.<\/p>\n

Las comunidades no son transitivas<\/b>. 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, \u00e9l entender\u00e1 lo que deseas a trav\u00e9s de la comunidad. Pero su vecino puede no entenderlo, o el operador simplemente puede eliminar tu etiqueta, y no lograr\u00e1s lo que quer\u00edas.<\/p>\n

RPKI + ROA solo resuelve una peque\u00f1a parte de los problemas<\/b>. RPKI es Infraestructura de Clave P\u00fablica de Recursos\u00a0<\/b> \u2014 un marco especial para firmar informaci\u00f3n 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.<\/p>\n

RPKI es tambi\u00e9n un sistema jer\u00e1rquico de claves p\u00fablicas. 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 \u2014 Autorizaciones de Origen de Enrutamiento:<\/p>\n

\u2014 Certifico que este prefijo ser\u00e1 anunciado en nombre de esta autonom\u00eda.<\/i><\/p>\n

Adem\u00e1s de ROA, existen otros objetos, pero de ellos hablaremos en otra ocasi\u00f3n. Parece que es una herramienta buena y \u00fatil. 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\u00edas de grandes jugadores como AT&T y grandes IXs de que los prefijos con registros ROA inv\u00e1lidos ser\u00e1n descartados. <\/p>\n

Quiz\u00e1s lo har\u00e1n, pero por ahora tenemos una gran cantidad de prefijos que no est\u00e1n firmados de ninguna manera. Por un lado, no est\u00e1 claro si se anuncian de manera v\u00e1lida. Por otro lado, no podemos descartarlos por defecto porque no estamos seguros de si es correcto o no.<\/p>\n

\u00bfQu\u00e9 m\u00e1s hay?<\/h3>\n

\nBGPSec<\/b>. Es una buena cosa que fue ideada por acad\u00e9micos para la red de ponys rosas. Ellos dijeron:<\/p>\n

\u2014 Tenemos RPKI + ROA, un mecanismo de certificaci\u00f3n de la firma del espacio de direcciones. Creamos un atributo BGP separado y lo llamamos BGPSec Path. Cada enrutador firmar\u00e1 con su firma los anuncios que propaga a sus vecinos. As\u00ed obtendremos un camino de confianza de una cadena de anuncios firmados que podremos verificar.<\/i><\/p>\n

En teor\u00eda es bueno, pero en la pr\u00e1ctica hay muchos problemas. BGPSec rompe muchas mec\u00e1nicas existentes de BGP relacionadas con la selecci\u00f3n de next-hop y la gesti\u00f3n del tr\u00e1fico 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\u00f3pico.<\/p>\n

BGPSec tiene enormes problemas de rendimiento. En el hardware actual, la velocidad de verificaci\u00f3n de anuncios es de aproximadamente 50 prefijos por segundo. Para ponerlo en perspectiva: la tabla actual de internet, que contiene 700,000 prefijos, tardar\u00e1 5 horas en actualizarse, periodo durante el cual cambiar\u00e1n 10 veces m\u00e1s.<\/p>\n

BGP Open Policy (BGP basado en roles)<\/b>. Una propuesta reciente basada en el modelo Gao-Rexford<\/b>. Son dos acad\u00e9micos que se dedican a investigar el BGP.<\/p>\n

El modelo Gao-Rexford se basa en lo siguiente. Simplificando, en el caso de BGP hay un peque\u00f1o n\u00famero de tipos de interacciones:<\/p>\n