No es ningún secreto que el sistema automatizado "Inspector" monitorea el control de las cerraduras en la lista de información prohibida en Rusia. Cómo funciona está bien escrito aquí en este
artículo sobre Habr , la imagen es de allí:
El
módulo del proveedor
"Auditor del agente" se instala directamente en el proveedor:
El módulo "Auditor del agente" es un elemento estructural del sistema automatizado "Auditor" (AS "Auditor"). Este sistema está diseñado para monitorear el cumplimiento por parte de los operadores de telecomunicaciones de las restricciones de acceso en el marco de las disposiciones establecidas por los artículos 15.1 a 15.4 de la Ley Federal del 27 de julio de 2006 Nº 149- "Sobre información, tecnologías de la información y protección de la información".
El objetivo principal de crear el Auditor AS es monitorear el 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- "Sobre la información, las tecnologías de la información y la protección de la información" con respecto a la identificación de los hechos de acceso a la información prohibida. y obtener materiales de respaldo (datos) sobre violaciones para restringir el acceso a la información prohibida.
Dado que, si no todos, muchos proveedores instalaron este dispositivo en casa, deberían haber tenido una gran red de sondas de baliza como
RIPE Atlas e incluso más, pero con acceso cerrado. Sin embargo, el faro es el faro para enviar señales en todas las direcciones, pero ¿qué pasa si los atrapamos y vemos qué capturamos y cuántos?
Antes de contar, veamos por qué esto puede ser posible.
Poco de teoría
Los agentes verifican la disponibilidad de un recurso, incluso a través de solicitudes HTTP (S), como este 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, también consiste en la fase de configuración de la conexión: intercambio de
SYN y
SYN-ACK , y la fase de finalización de la conexión:
FIN-ACK .
El registro de información prohibida contiene varios tipos de bloqueos. Obviamente, si el recurso está bloqueado por la dirección IP o el nombre de dominio, no veremos ninguna solicitud. Estos son los tipos de bloqueos más destructivos que conducen a la inaccesibilidad de todos los recursos en la misma dirección IP o toda la información en el dominio. También hay un tipo de bloqueo de URL. En este caso, el sistema de filtrado debe analizar el encabezado de la solicitud HTTP para determinar exactamente qué bloquear. Y antes de eso, como se puede ver arriba, debe ocurrir la fase de configuración de la conexión, que puede intentar rastrear, ya que lo más probable es que el filtro lo omita.
Para hacer esto, debe elegir un dominio libre adecuado con el tipo de bloqueo "por URL" y HTTP, a fin de facilitar el trabajo del sistema de filtrado, preferiblemente abandonado durante mucho tiempo, para minimizar la entrada de tráfico extraño, excepto de los agentes. Esta tarea no fue en absoluto difícil, hay muchos dominios gratuitos en el registro de información prohibida para todos los gustos. Por lo tanto, el dominio fue adquirido, vinculado a las direcciones IP en el VPS con
tcpdump ejecutándose, y comenzó el conteo.
Auditoría de los "Auditores"
Esperaba ver ráfagas periódicas de solicitudes, lo que en mi opinión indicaría una acción controlada. Esto no quiere decir que no haya visto esto en absoluto, pero definitivamente no había una imagen clara:
Como era de esperar, incluso un dominio innecesario para una IP no utilizada simplemente recibirá una gran cantidad de información no solicitada, como es el Internet moderno. Pero afortunadamente, solo necesitaba solicitudes para una URL específica, por lo que todos los rastreadores y los brutos de contraseña se encontraron rápidamente. Además, era lo suficientemente simple como para entender dónde estaba la inundación por la masa del mismo tipo de solicitudes. Luego compilé la frecuencia de ocurrencia de direcciones IP y caminé por la parte superior separando manualmente a aquellos que se deslizaron en los pasos anteriores. Además, eliminé todas las fuentes que enviaron un paquete, no había muchas. Y resultó esto:
Una ligera digresión lírica. Un poco más de un día después, mi proveedor de hosting envió un mensaje bastante simplificado, dicen que en sus instalaciones hay un recurso de la lista prohibida de ILV, por lo que está bloqueado. Al principio pensé que habían bloqueado mi cuenta, no fue así. Entonces pensé que solo me estaban advirtiendo sobre lo que ya sabía. Pero resultó que el proveedor de alojamiento activó su filtro en frente de mi dominio y como resultado, me encontré con doble filtro: de los proveedores y el host. El filtro omitió solo los extremos de las solicitudes:
FIN-ACK y
RST cortaron todo HTTP en la URL prohibida. Como puede ver en el gráfico anterior, después del primer día comencé a recibir menos datos, pero aún los recibí, lo cual fue suficiente para la tarea de calcular las fuentes de consulta.
Ve al grano. En mi opinión, dos ráfagas son claramente visibles cada día, la primera menos después de la medianoche en Moscú, la segunda más cerca de las 6 de la mañana con una cola de hasta 12 días. El pico no ocurre exactamente al mismo tiempo. Primero, quería resaltar las direcciones IP que cayeron solo en estos períodos y cada uno en todos los períodos, en base al supuesto de que los Agentes verifican periódicamente. Pero después de una cuidadosa visualización, descubrí rápidamente períodos que caen en otros intervalos, con diferentes frecuencias, hasta una solicitud por hora. Luego pensé en las zonas horarias y en lo que es posible en ellas, luego pensé que, en general, el sistema puede no estar sincronizado globalmente. Además, seguro, NAT desempeñará su papel, y el mismo Agente puede realizar solicitudes desde diferentes IP públicas.
Como mi objetivo original no era exactamente, conté todas las direcciones que obtuve en una semana y obtuve
2791 . El número de sesiones TCP establecidas a partir de una dirección es en promedio 4, con una mediana de 2. Sesiones principales por dirección: 464, 231, 149, 83, 77. El máximo del 95% de la muestra es de 8 sesiones por dirección. La mediana no es muy alta, recuerdo que el horario muestra una frecuencia diaria clara, por lo que puede esperar algo de 4 a 8 en 7 días. Si descarta todas las sesiones de reunión una vez, entonces obtenemos la mediana igual a 5. Pero no podría excluirlas de manera clara. Por el contrario, las comprobaciones puntuales mostraron que están relacionadas con solicitudes de un recurso prohibido.
Las direcciones, y en Internet, los sistemas autónomos son más importantes: AS, de los cuales
1510 salieron, en promedio 2 direcciones en AS con mediana 1. Direcciones principales en AS: 288, 77, 66, 39, 27. El máximo del 95% de la muestra son 4 direcciones en 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 en cada región de la presencia del operador, y no se olviden de NAT. Si toma por país, 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. Quizás esto puede explicarse por errores de geolocalización o errores de registrador al completar los datos. O el hecho de que una compañía rusa puede tener raíces no rusas, o tener una oficina de representación extranjera porque es tan simple que es natural tratar con una organización extranjera RIPE NCC. Una parte es indudablemente superflua, pero es difícil separarla, ya que el recurso está bloqueado, y desde el segundo día bajo doble bloqueo, y la mayoría de las sesiones son solo un intercambio de varios paquetes de servicios. Acordemos en el hecho de que esta es una pequeña parte.
Estos números ya se pueden comparar con el número de proveedores en Rusia.
Según el ILV, las licencias para "Servicios de comunicación para la transmisión de datos, a excepción de la voz" son 6387, pero esta es una calificación muy acosada desde arriba, no todas estas licencias son específicamente para proveedores de Internet que necesitan instalar el Agente. En la zona RIPE NCC, un número similar de AS registrados en Rusia es 6230, de los cuales no todos los proveedores.
UserSide realizó un cálculo más riguroso y recibió 3940 empresas en 2017, y es más probable que sea una estimación de arriba. En cualquier caso, tenemos el número de AS iluminados dos veces y media menos. Pero aquí vale la pena entender que AS no es estrictamente igual al proveedor. Algunos proveedores no tienen su propio AS, algunos tienen más de uno. Si suponemos que los Agentes aún se oponen a todos, entonces alguien filtra más que los demás, por lo que sus solicitudes no se pueden distinguir de la basura, si es que lo hacen. Pero para una evaluación aproximada es bastante tolerable, incluso si algo se perdió debido a mi descuido.
Sobre DPI
A pesar de que mi proveedor de alojamiento ha habilitado su filtro desde el segundo día, según la información del primer día, podemos concluir que los bloqueos funcionan con éxito. Solo 4 fuentes pudieron abrirse paso y finalizaron completamente las sesiones HTTP y TCP (como en el ejemplo anterior). Otro 460 puede enviar un
GET , pero la sesión termina instantáneamente en
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"
Las variaciones de esto pueden ser diferentes: menos
RST o más retransmisión, también depende de lo que el filtro envíe al nodo de origen. En cualquier caso, esta es la plantilla más confiable, a partir de la cual está claro que se solicitó el recurso prohibido. Además, siempre hay una respuesta que aparece en una sesión con un
TTL mayor que en los paquetes anteriores y posteriores.
Incluso el
GET no
GET visible desde el resto:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0" TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
Más o menos:
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"
La diferencia en
TTL seguramente es visible si algo llega del filtro. Pero a menudo puede no volar 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" ...
Más o menos:
TCP, 14678 > 80, "[SYN] Seq=0" TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1" TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
Y todo esto se repite y se repite y se repite, como se puede ver en el gráfico, exactamente más de una vez, todos los días.
Sobre IPv6
La buena noticia es que él es. Puedo decir de manera confiable que desde 5 direcciones IPv6 diferentes hay solicitudes periódicas al recurso prohibido, exactamente el comportamiento de los Agentes que esperaba. Además, una de las direcciones IPv6 no se incluye en el filtrado y veo una sesión completa. Con dos más, solo vi una sesión incompleta, una de las cuales fue interrumpida por
RST desde el filtro, la segunda en el tiempo. Un total de
7 .
Como hay pocas direcciones, las estudié en detalle y resultó que solo hay 3 proveedores, ¡puede aplaudirlos de pie! Otra dirección es el alojamiento en la nube en Rusia (no se filtra), otra es un centro de investigación en Alemania (hay un filtro, ¿dónde?). Pero, ¿por qué verifican a tiempo la disponibilidad de recursos prohibidos? Es una buena pregunta. Los dos restantes hicieron una solicitud y no se encuentran en las fronteras de Rusia, con uno de ellos filtrado (¿todavía está en tránsito?).
Locks and Agents es un gran freno para IPv6, cuya implementación, por lo tanto, no se mueve muy rápido. Esto es triste Los que han resuelto esta tarea están completamente orgullosos de sí mismos.
En conclusión
No busqué el 100% de precisión, le pido que me perdone por esto, espero que alguien quiera repetir este trabajo con mayor precisión. Era importante para mí entender si ese enfoque funcionaría en principio. La respuesta será Las cifras resultantes en una primera aproximación, creo, son bastante confiables.
Lo que se podía hacer más y lo que era demasiado vago para hacer era calcular las consultas de DNS. No se filtran, pero tampoco dan mucha precisión, ya que funcionan solo para el dominio y no para la URL completa. La frecuencia debe ser visible. Si se combina con lo que está directamente visible en las solicitudes, esto le permitirá separar el exceso y obtener más información. Incluso es posible identificar los desarrolladores de DNS utilizados por los proveedores y mucho más.
No esperaba que para mi VPS el host también incluyera su propio filtro. Tal vez esta es una práctica común. Al final, el ILV envía una solicitud para eliminar el recurso al host. Pero no me sorprendió e incluso jugó con alguna ventaja. El filtro funcionó de manera muy eficiente al cortar todas las solicitudes HTTP correctas a la URL prohibida, pero no las correctas que pasaron por el filtro de los proveedores antes, incluso si solo en forma de terminaciones:
FIN-ACK y
RST - menos menos y casi obtuvo un plus. Por cierto, el host IPv6 no se filtró. Por supuesto, esto afectó la calidad del material recolectado, pero aun así permitió ver la frecuencia. Esto resultó ser un punto importante al elegir un sitio para colocar recursos, no se olvide de estar interesado en el tema de organizar el trabajo con la lista de sitios prohibidos y consultas del ILV.
Al principio, comparé el "Auditor" de CA con
RIPE Atlas . Esta comparación está justificada y una gran red de agentes puede ser beneficiosa. Por ejemplo, determinar la calidad de la disponibilidad de recursos de varios proveedores en diferentes partes del país. Puede calcular los retrasos, puede construir gráficos, puede analizar todo y ver los cambios que ocurren 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 usan Agentes? Al conocer (encontrar) su comportamiento estándar, puede determinar los cambios que ocurren a su alrededor y cómo esto afecta la calidad de los servicios prestados. Y al mismo tiempo, no necesita instalar sondas de forma independiente en la red, ya han sido suministradas por Roskomnadzor.
Otro punto que quiero mencionar es que cada herramienta puede ser un arma. AS "Inspector" es una red cerrada, pero los agentes entregan a todos con menudencias enviando solicitudes de todos los recursos de la lista de prohibidos. Obtener tal recurso no representa absolutamente ningún problema. En total, los proveedores a través de Agentes, involuntariamente hablan sobre su red mucho más de lo que valdría 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 solo lo más obvio. Así como alguien puede monitorear las acciones de los Agentes para mejorar la disponibilidad de sus recursos, alguien puede hacer esto para otros fines y no existen obstáculos. Un instrumento de doble filo y muy polifacético resultó, cualquiera puede estar convencido de esto.