No es ningún secreto que el control del bloqueo en la lista de información prohibida en Rusia es supervisado por el sistema automatizado "Inspector". Cómo funciona está bien escrito aquí en este , foto del mismo lugar:
Instalado directamente en el proveedor. :
El módulo "Agente Inspector" es un elemento estructural del sistema automatizado "Inspector" (AS "Inspector"). Este sistema está diseñado para monitorear el cumplimiento por parte de los operadores de telecomunicaciones de los requisitos de restricción de acceso en el marco de las disposiciones establecidas por los artículos 15.1 a 15.4 de la Ley Federal de 27 de julio de 2006 No. 149-FZ “Sobre Información, Tecnologías de la Información y Protección de la Información. "
El objetivo principal de la creación de AS "Revizor" es garantizar el seguimiento del cumplimiento por parte de los operadores de telecomunicaciones de los requisitos establecidos en los artículos 15.1 a 15.4 de la Ley Federal de 27 de julio de 2006 No. 149-FZ "Sobre Información, Tecnologías de la Información y Protección de la Información". " en términos de identificar hechos de acceso a información prohibida y obtener materiales de respaldo (datos) sobre violaciones para restringir el acceso a información prohibida.
Teniendo en cuenta que, si no todos, muchos proveedores han instalado este dispositivo, debería haber una gran red de sondas de baliza como y aún más, pero con acceso cerrado. Sin embargo, una baliza es una baliza para enviar señales en todas direcciones, pero ¿y si las captamos y vemos qué captamos y cuántas?
Antes de contar, veamos por qué esto podría ser posible.
Un poco de teoría
Los agentes verifican la disponibilidad de un recurso, incluso a través de solicitudes HTTP(S), como esta:
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"
Además de la carga útil, la solicitud también consta de una fase de establecimiento de conexión: intercambio SYN и SYN-ACKy fases de finalización de la conexión: FIN-ACK.
El registro de información prohibida contiene varios tipos de bloqueo. Obviamente, si un recurso está bloqueado por dirección IP o nombre de dominio, no veremos ninguna solicitud. Estos son los tipos de bloqueo más destructivos, que provocan la inaccesibilidad de todos los recursos en una 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 de la solicitud HTTP para determinar exactamente qué bloquear. Y antes, como se puede ver arriba, debería haber una fase de establecimiento de conexión que puedes intentar rastrear, ya que lo más probable es que el filtro la pase por alto.
Para hacer esto, debe seleccionar un dominio gratuito adecuado con el tipo de bloqueo “URL” y HTTP para facilitar el trabajo del sistema de filtrado, preferiblemente abandonado hace mucho tiempo, para minimizar la entrada de tráfico extraño excepto el de los Agentes. Esta tarea no resultó nada difícil, hay bastantes dominios gratuitos en el registro de información prohibida y para todos los gustos. Por lo tanto, el dominio fue comprado y vinculado a direcciones IP en un VPS que ejecuta tcpdump y empezó el conteo.
Auditoría de "Auditores"
Esperaba ver ráfagas periódicas de solicitudes, lo que en mi opinión indicaría una acción controlada. Es imposible decir que no lo vi en absoluto, pero definitivamente no había una imagen clara:
Lo cual no es sorprendente, incluso en un dominio que nadie necesita y en una IP nunca utilizada, simplemente habrá un montón de información no solicitada, como es la Internet moderna. Pero, afortunadamente, solo necesitaba solicitudes para una URL específica, por lo que todos los escáneres y descifradores de contraseñas se encontraron rápidamente. Además, fue bastante fácil entender dónde se produjo la inundación a partir de la gran cantidad de solicitudes similares. A continuación, recopilé la frecuencia de aparición de las direcciones IP y revisé todo el top manualmente, separando aquellos que se perdieron en las etapas anteriores. Además, corté todas las fuentes que se enviaron en un solo paquete, ya no había muchas. Y esto es lo que sucedió:
Una pequeña digresión lírica. Poco más de un día después, mi proveedor de alojamiento envió una carta con un contenido bastante simplificado, diciendo que sus instalaciones contienen un recurso de la lista prohibida de RKN, por lo que está bloqueado. Al principio pensé que mi cuenta estaba bloqueada, pero no fue así. Entonces pensé que simplemente me estaban advirtiendo sobre algo que ya sabía. Pero resultó que el proveedor de alojamiento activó su filtro delante de mi dominio y como resultado me encontré bajo un doble filtrado: del proveedor y del proveedor de alojamiento. El filtro solo pasó los finales de las solicitudes: FIN-ACK и RST cortando todo HTTP en una URL prohibida. Como puede ver en el gráfico anterior, después del primer día comencé a recibir menos datos, pero aún así los recibí, lo cual fue suficiente para la tarea de contar las fuentes de solicitudes.
Llegar al punto. En mi opinión, dos ráfagas son claramente visibles todos los días, la primera más pequeña, después de la medianoche, hora de Moscú, la segunda más cerca de las 6 am con una cola hasta las 12 del mediodía. El pico no ocurre exactamente al mismo tiempo. Al principio, quería seleccionar direcciones IP que cayeran solo en estos períodos y cada una en todos los períodos, basándose en el supuesto de que los controles por parte de los Agentes se realizan periódicamente. Pero tras una revisión cuidadosa, descubrí rápidamente períodos que caían en otros intervalos, con otras frecuencias, hasta una solicitud cada hora. Luego pensé en las zonas horarias y que tal vez tenía algo que ver con ellas, luego pensé que en general el sistema podría no estar sincronizado globalmente. Además, NAT probablemente desempeñará un papel y el mismo Agente puede realizar solicitudes desde diferentes IP públicas.
Como mi objetivo inicial no era exactamente, conté todas las direcciones que encontré 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. Principales sesiones por dirección: 464, 231, 149, 83, 77. El máximo del 95% de la muestra es 8 sesiones por dirección. La mediana no es muy alta, permítanme recordarles que el gráfico muestra una periodicidad diaria clara, por lo que se podría esperar algo entre 4 y 8 en 7 días. Si descartamos todas las sesiones que ocurren una vez, obtendremos una mediana igual a 5. Pero no podría excluirlas según un criterio claro. Por el contrario, una verificación aleatoria mostró que estaban relacionados con solicitudes de un recurso prohibido.
Las direcciones son direcciones, pero en Internet, los sistemas autónomos, AS, que resultaron ser más importantes 1510, en promedio 2 direcciones por AS con una mediana de 1. Direcciones principales por AS: 288, 77, 66, 39, 27. El máximo del 95% de la muestra es 4 direcciones por AS. Aquí se espera la mediana: un Agente por proveedor. También esperamos la cima: hay grandes jugadores en ella. En una red grande, los agentes probablemente deberían estar ubicados en cada región de presencia del operador, y no se olvide de NAT. Si lo tomamos por país, los máximos serán: 1409 - RU, 42 - UA, 23 - CZ, 36 de otras regiones, no RIPE NCC. Llaman la atención las solicitudes procedentes del exterior de Rusia. Probablemente esto se pueda explicar por errores de geolocalización o errores del registrador al completar los datos. O el hecho de que una empresa rusa puede no tener raíces rusas o tener una oficina de representación en el extranjero porque es más fácil, lo cual es natural cuando se trata de una organización extranjera RIPE NCC. Sin duda, una parte es superflua, pero es realmente difícil separarla, ya que el recurso está bloqueado y, a partir del segundo día, bajo doble bloqueo, y la mayoría de las sesiones son solo un intercambio de varios paquetes de servicios. Acordemos que esto es una pequeña parte.
Estas cifras ya se pueden comparar con el número de proveedores en Rusia. licencias para "Servicios de comunicación para transmisión de datos, excluida voz" - 6387, pero esta es una estimación muy alta de lo anterior, no todas estas licencias se aplican específicamente a proveedores de Internet que necesitan instalar 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 en 3940 recibió 2017 empresas, y esta es más bien una estimación anterior. En cualquier caso, tenemos dos veces y media menos AS iluminados. Pero aquí vale la pena entender que AS no es estrictamente igual al proveedor. Algunos proveedores no tienen su propio AS, otros tienen más de uno. Si asumimos que todos todavía tienen Agentes, entonces alguien filtra con más fuerza que otros, de modo que sus solicitudes no se pueden distinguir de la basura, si es que llegan a ellos. Pero para una evaluación aproximada es bastante tolerable, incluso si algo se perdió debido a mi descuido.
Acerca del PPP
A pesar de que mi proveedor de hosting activó su filtro a partir del segundo día, basándonos en la información del primer día podemos concluir que el bloqueo está funcionando correctamente. Solo 4 fuentes pudieron comunicarse y completaron completamente las sesiones HTTP y TCP (como en el ejemplo anterior). Se pueden enviar otros 460 GET, pero la sesión es inmediatamente terminada por RST. presta atención a 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"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#А это попытка исходного узла получить потерю
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"
#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Las variaciones de esto pueden ser diferentes: menos RST o más retransmisiones: también depende de lo que envíe el filtro al nodo de origen. En cualquier caso, esta es la plantilla más fiable, de la que se desprende que lo que se solicitó era un recurso prohibido. Además siempre hay una respuesta que aparece en la sesión con TTL mayor que en los paquetes anteriores y posteriores.
Ni siquiera puedes verlo desde el resto. GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Вот это прислал фильтр
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"
#Вот это прислал фильтр
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"
#Опять фильтр, много раз
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
La diferencia es definitivamente visible. TTL si algo sale del filtro. Pero a menudo es posible que no llegue nada:
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"
#Прошло несколько секунд без трафика
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 se repite y se repite, como se puede observar en el gráfico, más de una vez, cada día.
Acerca de IPv6
La buena noticia es que existe. Puedo decir con seguridad que las solicitudes periódicas a un recurso prohibido se producen desde 5 direcciones IPv6 diferentes, que es exactamente el comportamiento de los Agentes que esperaba. Además, una de las direcciones IPv6 no entra en el filtrado y veo una sesión completa. De dos más solo vi una sesión inacabada, una de las cuales fue interrumpida por RST del filtro, el segundo en el tiempo. Cantidad total 7.
Como hay pocas direcciones, las estudié todas en detalle y resultó que solo hay 3 proveedores allí, ¡se les puede dar una gran ovación! Otra dirección es alojamiento en la nube en Rusia (no filtra), otra es un centro de investigación en Alemania (hay un filtro, ¿dónde?). Pero, ¿por qué verifican la disponibilidad de recursos prohibidos en un horario? Es una buena pregunta. Los dos restantes hicieron una solicitud y están ubicados fuera de Rusia, y uno de ellos está filtrado (¿en tránsito, después de todo?).
Los bloqueos y los agentes son un gran obstáculo para IPv6, cuya implementación no avanza muy rápidamente. Es triste. Quienes resolvieron este problema pueden estar plenamente orgullosos de sí mismos.
en conclusión
No me esforcé por lograr una precisión del 100%, perdóneme por esto, espero que alguien quiera repetir este trabajo con mayor precisión. Para mí era importante comprender si este enfoque funcionaría en principio. La respuesta es sí. Las cifras obtenidas, como primera aproximación, creo que son bastante fiables.
Lo que más se podría haber hecho y lo que me daba pereza era contar las solicitudes de DNS. No están filtrados, pero tampoco aportan mucha precisión ya que sólo funcionan para el dominio, y no para la URL completa. La frecuencia debe ser visible. Si lo combinas con lo que se ve directamente en las consultas, esto te permitirá separar lo innecesario y obtener más información. Incluso es posible determinar los desarrolladores de los DNS utilizados por los proveedores y mucho más.
No esperaba en absoluto que el proveedor de alojamiento también incluyera su propio filtro para mi VPS. Quizás esta sea una práctica común. Al final, RKN envía una solicitud para eliminar el recurso al proveedor de alojamiento. Pero esto no me sorprendió y, en cierto modo, incluso me benefició. El filtro funcionó de manera muy efectiva, cortando todas las solicitudes HTTP correctas a una URL prohibida, pero no llegaron a ellas las correctas que habían pasado previamente por el filtro de los proveedores, aunque solo en forma de terminaciones: FIN-ACK и RST - menos por menos y casi resultó ser un plus. Por cierto, el proveedor de alojamiento no filtró IPv6. Por supuesto, esto afectó la calidad del material recopilado, pero aun así permitió ver la frecuencia. Resultó que este es un punto importante a la hora de elegir un sitio para colocar recursos, no olvide interesarse por el tema de la organización del trabajo con la lista de sitios prohibidos y las solicitudes del RKN.
Al principio comparé el AS "Inspector" con . Esta comparación está bastante justificada y una gran red de Agentes puede resultar beneficiosa. Por ejemplo, determinar la calidad de la disponibilidad de recursos de diferentes proveedores en diferentes partes del país. Puede calcular retrasos, crear gráficos, analizarlo todo y ver los cambios que se producen tanto a nivel local como global. Esta no es la forma más directa, pero los astrónomos usan “velas estándar”, ¿por qué no usar Agentes? Conociendo (habiendo encontrado) su comportamiento estándar, se pueden determinar los cambios que se producen a su alrededor y cómo esto afecta la calidad de los servicios prestados. Y al mismo tiempo, no es necesario colocar sondas en la red usted mismo, Roskomnadzor ya las ha instalado.
Otro punto que quiero tocar es que toda herramienta puede ser un arma. AS "Inspector" es una red cerrada, pero los Agentes entregan a todos enviando solicitudes de todos los recursos de la lista prohibida. Disponer de un recurso de este tipo no supone ningún problema. En total, los proveedores a través de Agentes, sin saberlo, dicen mucho más sobre su red de lo que probablemente valga la pena: tipos de DPI y DNS, ubicación del Agente (¿nodo central y red de servicio?), marcadores de red de retrasos y pérdidas, y esto es sólo lo más obvio. Así como alguien puede monitorear las acciones de los Agentes para mejorar la disponibilidad de sus recursos, alguien puede hacerlo para otros fines y no hay obstáculos para ello. El resultado es un instrumento de doble filo y muy polifacético, cualquiera puede verlo.
Fuente: habr.com