No es un secreto que el control de bloqueos según la lista de información prohibida en Rusia es supervisado por un sistema automatizado llamado "Revisor". Está bien descrito cómo funciona en este , con imagen de allí también:
Directamente en el proveedor se instala :
El módulo "Agente Revisor" es un elemento estructural del sistema automatizado "Revisor" (AS "Revisor"). Este sistema está destinado a controlar que los operadores de telecomunicaciones cumplan con los requisitos de restricción de acceso establecidos por los artículos 15.1-15.4 de la Ley Federal del 27 de julio de 2006, No. 149-FZ "Sobre la información, las tecnologías de información y la protección de la información".
El objetivo principal de la creación de AS "Revisor" es asegurar el monitoreo del cumplimiento por parte de los operadores de telecomunicaciones de los requisitos establecidos en los artículos 15.1-15.4 de la Ley Federal del 27 de julio de 2006, No. 149-FZ "Sobre la información, las tecnologías de información y la protección de la información" en términos de detectar hechos de acceso a información prohibida y obtener material (datos) que confirme las violaciones sobre la restricción de acceso a esta información.
Teniendo en cuenta que, si no todos, muchos proveedores ya han instalado este dispositivo, debería haber surgido una gran red de sondas-balizas similar a y aún más, pero con acceso cerrado. Sin embargo, una baliza es una baliza para enviar señales en todas direcciones, ¿y si las atrapamos y vemos qué hemos captado y cuántas?
Antes de contar, veamos por qué esto podría ser posible.
Un poco de teoría
Los agentes verifican la disponibilidad del recurso, incluyendo a través de solicitudes HTTP(S), como este, por ejemplo:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /somepage HTTP/1.1"
TCP, 80 > 14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"
TCP, 14678 > 80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80 > 14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678 > 80, "[ACK] Seq=72 Ack=480"
La solicitud, además de la carga útil, consta de una fase de establecimiento de conexión: intercambio SYN y SYN-ACK, y una fase de finalización de conexión: FIN-ACK.
El registro de información prohibida contiene varios tipos de bloqueos. Es evidente que si un recurso se bloquea por dirección IP o nombre de dominio, no veremos ninguna solicitud. Estos son los tipos de bloqueo más destructivos, que llevan a la inaccesibilidad de todos los recursos en una misma dirección IP o de toda la información en un dominio. También existe un tipo de bloqueo 'por URL'. En este caso, el sistema de filtrado debe analizar el encabezado HTTP de la solicitud para determinar exactamente qué bloquear. Y antes de eso, como se ve arriba, debe ocurrir la fase de conexión que se puede intentar rastrear, ya que probablemente el filtro la pasará por alto.
Para ello, es necesario elegir un dominio libre adecuado con un tipo de bloqueo 'por URL' y HTTP, para facilitar el trabajo del sistema de filtrado; sería deseable que fuera un dominio abandonado desde hace tiempo, para minimizar la llegada de tráfico no deseado, excepto de los Agentes. Esta tarea resultó ser bastante sencilla; hay suficientes dominios libres en el registro de información prohibida para todos los gustos. Por lo tanto, se adquirió el dominio, se vinculó a direcciones IP en una VPS con el tcpdump y se inició el conteo.
Revisión de 'Los Revisores'
Esperaba ver picos periódicos de solicitudes, lo que indicaría, en mi opinión, una acción controlada. No se puede decir que no vi esto en absoluto, pero definitivamente no había un panorama claro:
Lo que no es sorprendente, incluso en un dominio sin interés y en una dirección IP nunca utilizada, llegará simplemente una gran cantidad de información no solicitada, así es el Internet moderno. Pero, afortunadamente, solo necesitaba las solicitudes de una URL específica, por lo que todos los escáneres y probadores de contraseñas fueron rápidamente identificados. Además, fue bastante simple entender dónde había un flujo de una gran cantidad de solicitudes similares. Luego, elaboré las frecuencias de aparición de direcciones IP y analicé toda la lista manualmente, separando a aquellos que habían pasado por alto en las etapas anteriores. Además, eliminé todas las fuentes que enviaron un solo paquete, ya que ya no eran muchas. Y esto es lo que resultó:
Una breve digresión lírica. Un poco más de un día después, mi proveedor de alojamiento me envió un correo bastante ambiguo, mencionando que en sus servidores había recursos de una lista prohibida de la RKN, por lo que están siendo bloqueados. Al principio pensé que habían bloqueado mi cuenta, pero no fue así. Luego pensé que solo me estaban advirtiendo sobre algo que ya sabía. Pero resultó que el anfitrión activó su filtro antes de mi dominio y, al final, caí en una doble filtración: por parte de los proveedores y por parte del anfitrión. El filtro solo permitía el paso de las solicitudes finales: FIN-ACK y RST cortando todo el HTTP en la URL prohibida. Como se puede ver en el gráfico anterior, después de las primeras 24 horas, comencé a recibir menos datos, pero aún así los recibía, lo cual fue suficiente para la tarea de contar las fuentes de solicitudes.
Más al grano. En mi opinión, se pueden ver claramente dos picos cada día, el primero más pequeño, después de la medianoche en Moscú, el segundo más cerca de las 6 de la mañana, con un rastro hasta el mediodía. El pico no ocurre exactamente a la misma hora. Al principio quería identificar las direcciones IP que solo aparecían en estos períodos y cada una en todos los períodos, basándome en la suposición de que las verificaciones por parte de los Agentes se realizan periódicamente. Pero al mirar detenidamente, descubrí bastante rápido que había períodos que caían en otros intervalos, con otras frecuencias, hasta una solicitud cada hora. Luego pensé en las zonas horarias y que quizás eso estaba en juego, después consideré que el sistema podría no estar globalmente sincronizado. Además, seguramente jugará un papel el NAT y el mismo Agente podría hacer solicitudes desde diferentes IPs públicas.
Dado que mi objetivo original no era la precisión, conté todas las direcciones que aparecieron en una semana y obtuve — 2791. El número de sesiones TCP establecidas desde una dirección es, en promedio, 4, con una mediana de 2. Las direcciones principales de sesiones son: 464, 231, 149, 83, 77. El máximo de una muestra del 95% — 8 sesiones por dirección. La mediana no es muy alta; cabe recordar que en el gráfico se muestra una clara periodicidad diaria, por lo que podría esperarse algo entre 4 y 8 en 7 días. Si se eliminan todas las sesiones que aparecen solo una vez, justo obtendremos una mediana de 5. Pero no pude excluirlas por un criterio claro. Por el contrario, una revisión aleatoria mostró que estaban relacionadas con las solicitudes del recurso prohibido.
Las direcciones son importantes, pero en Internet lo que realmente importa son los sistemas autónomos — AS, de los cuales hay 1510, un promedio de 2 direcciones por AS con una mediana de 1. Las principales direcciones en AS: 288, 77, 66, 39, 27. El máximo del 95% de la muestra es de 4 direcciones por AS. Aquí la mediana es predecible: un Agente por proveedor. También se espera que en una gran red haya Agentes en cada región de presencia del operador, sin olvidar el NAT. Si consideramos por países, los máximos serán: 1409 — RU, 42 — UA, 23 — CZ, 36 de otras regiones, no RIPE NCC. Las solicitudes que no provienen de Rusia llaman la atención. Probablemente, esto puede explicarse por errores en la geolocalización o errores de los registradores al completar los datos. O porque una empresa rusa puede no tener raíces rusas, o tener una representación extranjera porque es más sencillo, especialmente al tratar con la organización extranjera RIPE NCC. Ciertamente, una parte de esto es innecesaria, pero separarla de forma precisa es complicado, ya que el recurso está bloqueado, y a partir del segundo día está bajo doble bloqueo y la mayoría de las sesiones consisten solo en el intercambio de algunos paquetes de servicio. Convengamos que esta es una parte pequeña.
Estos números ya se pueden comparar con la cantidad de proveedores en Rusia. las licencias para “Servicios de comunicación de transmisión de datos, excepto voz” — 6387, pero esta es una estimación muy inflada, no todas estas licencias se relacionan directamente con los proveedores de Internet que necesitan establecer un Agente. En la zona RIPE NCC hay un número similar de AS registrados en Rusia — 6230, de los cuales no todos son proveedores. y obtuvo 3940 empresas en 2017, y esto es más bien una estimación superior. En cualquier caso, tenemos un número de AS visibles que es dos veces y media menor. Pero aquí hay que entender que AS no es estrictamente equivalente a un proveedor. Algunos proveedores no tienen su propio AS, y otros tienen más de uno. Si suponemos que todos tienen Agentes, significa que algunos filtran más que los demás, de modo que sus solicitudes son indistinguibles de basura si es que llegan. Pero para una estimación aproximada es bastante aceptable, incluso si algo se perdió por mi torpeza.
Sobre DPI
A pesar de que mi proveedor de hosting activó su filtro a partir del segundo día, la información del primer día muestra que los bloqueos funcionan correctamente. Solo 4 fuentes lograron eludirlo y tienen sesiones HTTP y TCP completamente establecidas (como en el ejemplo anterior). Otras 460 pueden intentarlo GET, pero la sesión se interrumpe instantáneamente por RST. Tenga en cuenta TTL:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80 > 14678, "[ACK] Seq=1 Ack=294"
#Esto fue enviado por el filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Encontrado"
#Y esto es un intento del nodo de origen para obtener la pérdida
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"
TTL 50, TCP, 14678 > 80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80 > 14678, "[FIN, ACK] Seq=171 Ack=295"
TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"
#El nodo de origen entiende que la sesión ha sido destruida
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Las variaciones de esto pueden ser diversas: menos RST o más retransmisiones, dependiendo también de lo que el filtro envía al nodo de origen. En cualquier caso, este es el patrón más fiable, del cual se puede ver que se solicitó precisamente el recurso prohibido. Además, siempre hay una respuesta que aparece en la sesión con TTL mayor que en los paquetes anteriores y posteriores.
De los demás no se ve ni siquiera GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Esto fue enviado por el filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
O así:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Esto fue enviado por el filtro
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
#De nuevo el filtro, muchas veces
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
La diferencia se ve obligatoriamente en TTL si algo llega del filtro. Pero a menudo puede no llegar nada en absoluto:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...
O así:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Han pasado varios segundos sin tráfico
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Y todo esto se repite y repite y repite, como se ve en el gráfico, definitivamente no una vez, cada día.
Sobre IPv6
Buenas noticias: está disponible. Puedo afirmar con certeza que se están realizando solicitudes periódicas a un recurso prohibido desde 5 direcciones IPv6 diferentes, exactamente el comportamiento de los Agentes que esperaba. Además, una de las direcciones IPv6 no está siendo filtrada y veo una sesión completa. Desde otras dos, solo vi una sesión incompleta, una de las cuales se interrumpió por RST el filtro, la otra por tiempo. En total, hay 7.
Dado que hay pocas direcciones, las he estudiado en detalle y resulta que en realidad solo hay 3 proveedores, ¡merecen un aplauso de pie! Otra dirección corresponde a un hosting en la nube en Rusia (no filtra), y otra a un centro de investigación en Alemania (hay filtro, ¿dónde?). Pero la pregunta es buena: ¿por qué verifican periódicamente la disponibilidad de recursos prohibidos? Los otros dos realizaron una solicitud cada uno y están fuera de las fronteras de Rusia, y uno de ellos está siendo filtrado (¿tal vez en tránsito?).
Los bloqueos y los Agentes son un gran freno para IPv6, cuya implementación ya avanza lentamente. Es una pena. Aquellos que han resuelto este problema en su totalidad pueden estar orgullosos de ello.
En conclusión
No busqué 100% de precisión, les pido disculpas por ello, espero que alguien quiera repetir este trabajo con mayor cuidado. Para mí era importante entender si este enfoque funcionaría en principio. La respuesta es: sí. Las cifras obtenidas son, en primera aproximación, bastante fiables.
Lo que podría haberse hecho y lo que me dio pereza hacer es contar las solicitudes a DNS. No están filtradas, pero tampoco proporcionan gran precisión, ya que funcionan solo para el dominio, no para toda la URL. La periodicidad debería ser visible. Si se combina con lo que se puede ver directamente en las solicitudes, permitirá separar lo innecesario y obtener más información. Quizás incluso identificar a los desarrolladores de DNS utilizados por los proveedores y mucho más.
No esperaba en absoluto que mi proveedor de VPS también activara su propio filtro. Tal vez sea una práctica común. Al final, el RKN envía la solicitud de eliminación del recurso precisamente al proveedor de hosting. Pero no me sorprendió y, de hecho, en cierta medida, me benefició. El filtro funcionó de manera muy efectiva al eliminar todas las solicitudes HTTP correctas al URL prohibido, mientras que las incorrectas, que pasaron previamente por el filtro de los proveedores, llegaron, aunque solo en forma de finales: FIN-ACK y RST — menos por menos y casi se convierte en más. Por cierto, el host de IPv6 no fue filtrado. Esto, por supuesto, afectó la calidad del material recopilado, pero aun así permitió ver la periodicidad. Resultó ser un aspecto importante al elegir una plataforma para alojar recursos; no olvide preguntar sobre la organización del trabajo con la lista de sitios prohibidos y las solicitudes del Roskomnadzor.
Al principio comparé el AS "Revisor" con . Esta comparación es completamente válida, y una gran red de Agentes puede resultar beneficiosa. Por ejemplo, determinar la calidad del acceso a un recurso desde diferentes proveedores de diversas partes del país. Se pueden calcular las latencias, se pueden hacer gráficos, se puede analizar todo esto y ver los cambios que suceden tanto local como globalmente. No es el camino más directo, pero los astrónomos emplean "velas estándar", ¿por qué no usar Agentes? Conociendo (o encontrando) su comportamiento estándar, se pueden identificar los cambios que ocurren a su alrededor y cómo esto afecta la calidad de los servicios prestados. Además, no es necesario colocar probadores manualmente en la red; ya lo han hecho el Roskomnadzor.
Otro aspecto que quiero abordar es que cada herramienta puede convertirse en un arma. El AS "Revisor" es una red cerrada, pero los Agentes delatan a todos por completo al enviar solicitudes a todos los recursos de la lista prohibida. Obtener tal recurso no representa ningún problema en absoluto. En resumen, los proveedores a través de los Agentes, sin querer, revelan mucho más sobre su red de lo que sería conveniente: tipos de DPI y DNS, localización del Agente (nodo central y red de servicio?), marcadores de red de latencias y pérdidas, y esto es solo lo más obvio. Así como alguien puede monitorear las acciones de los Agentes para mejorar la accesibilidad de sus recursos, alguien más puede hacerlo con otros fines, y no hay obstáculos para esto. Se ha convertido en una herramienta de doble filo y muy multifacética, cualquiera puede darse cuenta de esto.
Fuente: habr.com
