Non é ningún segredo que o control do bloqueo na lista de información prohibida en Rusia é supervisado polo sistema automatizado "Inspector". Como funciona está escrito ben aquí neste , imaxe do mesmo lugar:
Instalado directamente no provedor :
O módulo "Axente Inspector" é un elemento estrutural do sistema automatizado "Inspector" (AS "Inspector"). Este sistema está deseñado para supervisar o cumprimento por parte dos operadores de telecomunicacións dos requisitos de restrición de acceso no marco das disposicións establecidas nos artigos 15.1-15.4 da Lei Federal do 27 de xullo de 2006 n.o 149-FZ “sobre información, tecnoloxías da información e protección da información. ”
A finalidade principal da creación de AS "Revizor" é garantir o seguimento do cumprimento dos operadores de telecomunicacións cos requisitos establecidos polos artigos 15.1-15.4 da Lei Federal do 27 de xullo de 2006 núm. 149-FZ "sobre información, tecnoloxías da información e protección da información". " en termos de identificar feitos de acceso a información prohibida e obter materiais de apoio (datos) sobre violacións para restrinxir o acceso á información prohibida.
Tendo en conta o feito de que, se non todos, moitos provedores instalaron este dispositivo, debería haber unha gran rede de sondas de baliza como e aínda máis, pero con acceso pechado. Non obstante, unha baliza é unha baliza para enviar sinais en todas as direccións, pero que pasa se os captamos e vemos o que captamos e cantos?
Antes de contar, vexamos por que isto pode ser posible.
Un pouco de teoría
Os axentes comproban a dispoñibilidade dun recurso, incluso mediante 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"
Ademais da carga útil, a solicitude tamén consta dunha fase de establecemento da conexión: intercambio SYN и SYN-ACK, e fases de finalización da conexión: FIN-ACK.
O rexistro de información prohibida contén varios tipos de bloqueo. Obviamente, se un recurso está bloqueado por enderezo IP ou nome de dominio, non veremos ningunha solicitude. Estes son os tipos de bloqueo máis destrutivos, que conducen á inaccesibilidade de todos os recursos nun enderezo IP ou de toda a información dun dominio. Tamén hai un tipo de bloqueo "por URL". Neste caso, o sistema de filtrado debe analizar a cabeceira da solicitude HTTP para determinar exactamente que bloquear. E antes, como se pode ver anteriormente, debería haber unha fase de establecemento da conexión que podes tentar rastrexar, xa que o máis probable é que o filtro perda.
Para iso, cómpre seleccionar un dominio gratuíto axeitado co tipo de bloqueo "URL" e HTTP para facilitar o traballo do sistema de filtrado, preferiblemente abandonado por moito tempo, para minimizar a entrada de tráfico alleo agás dos axentes. Esta tarefa non resultou nada difícil; hai moitos dominios gratuítos no rexistro de información prohibida e para todos os gustos. Polo tanto, o dominio foi adquirido e ligado a enderezos IP nun VPS en execución tcpdump e comezou o reconto.
Auditoría de "Auditores"
Esperaba ver ráfagas periódicas de solicitudes, que na miña opinión indicarían unha acción controlada. É imposible dicir que non o vin en absoluto, pero definitivamente non había unha imaxe clara:
O que non é de estrañar, mesmo nun dominio que ninguén necesita e nunha IP nunca utilizada, simplemente haberá unha tonelada de información non solicitada, como é a Internet moderna. Pero, afortunadamente, só necesitaba solicitudes para un URL específico, polo que se atoparon rapidamente todos os escáneres e crackers de contrasinais. Ademais, foi bastante doado entender onde se baseou a inundación na masa de solicitudes similares. A continuación, compilei a frecuencia de aparición de enderezos IP e repasei manualmente toda a parte superior, separando os que o perderon nas etapas anteriores. Ademais, recortei todas as fontes que se enviaron nun paquete, xa non había moitas. E isto foi o que pasou:
Unha pequena digresión lírica. Pouco máis dun día despois, o meu provedor de hospedaxe enviou unha carta cun contido bastante simplificado, dicindo que as súas instalacións conteñen un recurso da lista de prohibidos de RKN, polo que está bloqueado. Ao principio pensei que a miña conta estaba bloqueada, non foi así. Entón pensei que simplemente me estaban avisando sobre algo que xa sabía. Pero resultou que o servidor activou o seu filtro fronte ao meu dominio e, como resultado, quedei baixo un dobre filtrado: dos provedores e do host. O filtro só pasou os extremos das solicitudes: FIN-ACK и RST cortando todo HTTP nun URL prohibido. Como podedes ver no gráfico anterior, despois do primeiro día comecei a recibir menos datos, pero aínda así os recibín, o que foi bastante para a tarefa de contar as fontes de solicitude.
Chegar ao grano. Na miña opinión, dúas ráfagas son claramente visibles todos os días, a primeira máis pequena, despois da medianoite, hora de Moscova, a segunda máis preto das 6 da mañá cunha cola ata as 12 do mediodía. O pico non ocorre exactamente ao mesmo tempo. Nun primeiro momento, quería seleccionar enderezos IP que caían só nestes períodos e cada un en todos os períodos, partindo da hipótese de que as comprobacións dos axentes se realizan periodicamente. Pero tras unha revisión coidadosa, descubrín axiña períodos que caían noutros intervalos, con outras frecuencias, ata unha solicitude cada hora. Despois pensei nos fusos horarios e que quizais tiña algo que ver con eles, entón pensei que en xeral o sistema podería non estar sincronizado globalmente. Ademais, NAT probablemente desempeñará un papel e o mesmo axente pode facer solicitudes desde diferentes IP públicas.
Como o meu obxectivo inicial non era exactamente, contei todos os enderezos que atopei nunha semana e conseguín: 2791. O número de sesións TCP establecidas a partir dun enderezo é de media de 4, cunha mediana de 2. Sesións principais por enderezo: 464, 231, 149, 83, 77. O máximo do 95% da mostra é de 8 sesións por enderezo. A mediana non é moi alta, permítanme lembrar que o gráfico mostra unha periodicidade diaria clara, polo que se podería esperar algo de 4 a 8 en 7 días. Se botamos todas as sesións que se producen unha vez, obteremos unha mediana igual a 5. Pero non podería excluílas a partir dun criterio claro. Pola contra, unha comprobación aleatoria mostrou que estaban relacionadas con solicitudes de recurso prohibido.
Os enderezos son enderezos, pero en Internet, sistemas autónomos - AS, que resultou ser máis importante 1510, de media 2 enderezos por AS cunha mediana de 1. Enderezos principais por AS: 288, 77, 66, 39, 27. O máximo do 95% da mostra é de 4 enderezos por AS. Aquí espérase a mediana: un axente por provedor. Tamén esperamos o cumio: hai grandes xogadores nel. Nunha rede grande, os axentes probablemente deberían estar situados en cada rexión da presenza do operador e non se esqueza de NAT. Se o tomamos por país, os máximos serán: 1409 - RU, 42 - UA, 23 - CZ, 36 doutras rexións, non RIPE NCC. As solicitudes de fóra de Rusia chaman a atención. Probablemente, isto pode explicarse por erros de xeolocalización ou erros de rexistro ao cubrir os datos. Ou o feito de que unha empresa rusa pode non ter raíces rusas, ou ter unha oficina de representación estranxeira porque é máis fácil, o que é natural cando se trata cunha organización estranxeira RIPE NCC. Algunha parte é sen dúbida superflua, pero é difícil separala de forma fiable, xa que o recurso está en bloqueo, e desde o segundo día en bloqueo dobre, e a maioría das sesións son só un intercambio de varios paquetes de servizo. Imos de acordo en que esta é unha pequena parte.
Estes números xa se poden comparar co número de provedores en Rusia. licenzas para "Servizos de comunicación para a transmisión de datos, excluída a voz" - 6387, pero esta é unha estimación moi alta de arriba, non todas estas licenzas se aplican especificamente aos provedores de Internet que precisan instalar un axente. Na zona RIPE NCC hai un número similar de AS rexistrados en Rusia: 6230, dos cales non todos son provedores. e recibiu 3940 empresas en 2017, e esta é máis ben unha estimación desde arriba. En calquera caso, temos dúas veces e media menos de AS iluminados. Pero aquí paga a pena entender que AS non é estrictamente igual ao provedor. Algúns provedores non teñen o seu propio AS, outros teñen máis dun. Se asumimos que todo o mundo aínda ten Axentes, entón alguén filtra con máis forza que outros, de xeito que as súas solicitudes non se poden distinguir do lixo, se chegan a eles. Pero para unha valoración aproximada é bastante tolerable, aínda que algo se perdese debido á miña supervisión.
Sobre DPI
A pesar de que o meu provedor de hospedaxe activou o seu filtro a partir do segundo día, baseándonos na información do primeiro día podemos concluír que o bloqueo funciona correctamente. Só 4 fontes puideron pasar e completar as sesións HTTP e TCP (como no exemplo anterior). Pódense enviar outros 460 GET, pero a sesión finaliza inmediatamente por RST. Preste atención 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"
As variacións deste poden ser diferentes: menos RST ou máis retransmisións - tamén depende do que o filtro envíe ao nodo fonte. En todo caso, este é o modelo máis fiable, do que se desprende que foi un recurso prohibido o que se solicitou. Ademais sempre hai unha resposta que aparece na sesión con TTL maior que nos paquetes anteriores e posteriores.
Nin sequera podes velo polo 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"
Ou 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"
...
A diferenza é definitivamente visible TTL se algo sae do filtro. Pero moitas veces non pode chegar 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"
...
Ou 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"
...
E todo isto repítese e repítese e repítese, como se pode ver na gráfica, máis dunha vez, todos os días.
Acerca de IPv6
A boa noticia é que existe. Podo dicir de forma fiable que as solicitudes periódicas a un recurso prohibido prodúcense desde 5 enderezos IPv6 diferentes, que é exactamente o comportamento dos axentes que esperaba. Ademais, un dos enderezos IPv6 non entra no filtrado e vexo unha sesión completa. De dúas máis só vin unha sesión sen rematar, unha das cales foi interrompida por RST do filtro, segundo no tempo. Cantidade total 7.
Como hai poucos enderezos, estudeinos todos en detalle e resultou que só hai 3 provedores alí, ¡pódeselles ovacionar! Outro enderezo é o hospedaxe na nube en Rusia (non filtra), outro é un centro de investigación en Alemaña (hai un filtro, onde?). Pero por que verifican a dispoñibilidade de recursos prohibidos nun horario é unha boa pregunta. Os dous restantes fixeron unha solicitude e están situados fóra de Rusia, e un deles está filtrado (en tránsito, despois de todo?).
O bloqueo e os axentes son un gran obstáculo para IPv6, cuxa implementación non se está movendo moi rápido. É triste. Os que resolveron este problema poden estar completamente orgullosos de si mesmos.
En conclusión
Non me esforcei por conseguir o 100% de precisión, perdóame por isto, espero que alguén queira repetir este traballo con maior precisión. Era importante para min entender se este enfoque funcionaría en principio. A resposta é si. As cifras obtidas, como primeira aproximación, creo, son bastante fiables.
O que máis se puido facer e o que me daba preguiza era contar as solicitudes de DNS. Non se filtran, pero tampouco proporcionan moita precisión xa que só funcionan para o dominio, e non para o URL completo. A frecuencia debe ser visible. Se o combinas co que está visible directamente nas consultas, isto permitirache separar o innecesario e obter máis información. Mesmo é posible determinar os desenvolvedores do DNS utilizados polos provedores e moito máis.
Absolutamente non esperaba que o host tamén incluíse o seu propio filtro para o meu VPS. Quizais esta sexa unha práctica común. Ao final, RKN envía unha solicitude para eliminar o recurso ao servidor. Pero isto non me sorprendeu e, nalgúns aspectos, mesmo funcionou para min. O filtro funcionou de forma moi eficaz, cortando todas as solicitudes HTTP correctas a un URL prohibido, pero non chegaron a elas as correctas que pasaran previamente polo filtro dos provedores, aínda que só en forma de finais: FIN-ACK и RST - menos por menos e case resultou ser un plus. Por certo, IPv6 non foi filtrado polo servidor. Por suposto, isto afectou á calidade do material recollido, pero aínda así permitiu ver a frecuencia. Resultou que este é un punto importante á hora de elixir un sitio para colocar recursos; non se esqueza de interesarse no tema da organización do traballo coa lista de sitios prohibidos e solicitudes do RKN.
Ao principio, comparei o AS "Inspector" con . Esta comparación está bastante xustificada e unha gran rede de axentes pode ser beneficiosa. Por exemplo, determinando a calidade da dispoñibilidade de recursos de diferentes provedores en diferentes partes do país. Podes calcular atrasos, podes construír gráficos, podes analizalo todo e ver os cambios que se producen tanto a nivel local como global. Esta non é a forma máis directa, pero os astrónomos usan "velas estándar", por que non usan axentes? Coñecendo (tendo atopado) o seu comportamento estándar, pode determinar os cambios que se producen ao seu redor e como isto afecta á calidade dos servizos prestados. E ao mesmo tempo, non precisa colocar sondas na rede de forma independente; Roskomnadzor xa as instalou.
Outro punto que quero tocar é que cada ferramenta pode ser un arma. AS "Inspector" é unha rede pechada, pero os Axentes entregan a todos enviando solicitudes para todos os recursos da lista prohibida. Ter tal recurso non presenta ningún problema. En total, os provedores a través de axentes, sen querelo, din moito máis sobre a súa rede do que probablemente paga a pena: tipos de DPI e DNS, localización do axente (nodo central e rede de servizos?), marcadores de atrasos e perdas de rede, e isto é. só o máis obvio. Do mesmo xeito que alguén pode supervisar as accións dos Axentes para mellorar a dispoñibilidade dos seus recursos, alguén pode facelo para outros fins e non hai obstáculos para iso. O resultado é un instrumento de dobre fío e moi polifacético, isto pode ver calquera.
Fonte: www.habr.com