Não é segredo que o controle do bloqueio da lista de informações proibidas na Rússia é monitorado pelo sistema automatizado “Inspetor”. Como funciona está bem escrito aqui neste , foto do mesmo lugar:
Instalado diretamente no provedor :
O módulo “Agente Inspetor” é um elemento estrutural do sistema automatizado “Inspetor” (AS “Inspetor”). Este sistema foi concebido para monitorizar o cumprimento pelos operadores de telecomunicações dos requisitos de restrição de acesso no âmbito das disposições estabelecidas pelos artigos 15.1-15.4 da Lei Federal de 27 de julho de 2006 nº 149-FZ “Sobre Informação, Tecnologias de Informação e Proteção da Informação. ”
O principal objetivo da criação do AS “Revizor” é garantir o monitoramento do cumprimento, pelas operadoras de telecomunicações, dos requisitos estabelecidos pelos artigos 15.1-15.4 da Lei Federal de 27 de julho de 2006 nº 149-FZ “Sobre Informação, Tecnologias da Informação e Proteção da Informação " em termos de identificação de fatos de acesso a informações proibidas e obtenção de materiais de apoio (dados) sobre violações para restringir o acesso a informações proibidas.
Levando em conta o fato de que, se não todos, muitos provedores instalaram este dispositivo, deveria haver uma grande rede de sondas beacon como e ainda mais, mas com acesso fechado. No entanto, um farol é um farol para enviar sinais em todas as direções, mas e se os capturarmos e vermos o que capturamos e quantos?
Antes de contarmos, vamos ver por que isso pode ser possível.
Um pouco de teoria
Os agentes verificam a disponibilidade de um recurso, inclusive por meio de solicitações 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"
Além do payload, a solicitação também consiste em uma fase de estabelecimento de conexão: troca SYN и SYN-ACKe fases de conclusão da conexão: FIN-ACK.
O cadastro de informações proibidas contém diversos tipos de bloqueio. Obviamente, se um recurso for bloqueado por endereço IP ou nome de domínio, não veremos nenhuma solicitação. Esses são os tipos de bloqueio mais destrutivos, que levam à inacessibilidade de todos os recursos de um endereço IP ou de todas as informações de um domínio. Existe também um tipo de bloqueio “por URL”. Neste caso, o sistema de filtragem deve analisar o cabeçalho da solicitação HTTP para determinar exatamente o que bloquear. E antes disso, como pode ser visto acima, deve haver uma fase de estabelecimento de conexão que você pode tentar rastrear, pois muito provavelmente o filtro irá sentir falta dela.
Para fazer isso, você precisa selecionar um domínio gratuito adequado com o tipo de bloqueio “URL” e HTTP para facilitar o trabalho do sistema de filtragem, de preferência há muito abandonado, para minimizar a entrada de tráfego estranho, exceto de Agentes. Esta tarefa acabou por não ser nada difícil, existem muitos domínios gratuitos no registo de informações proibidas e para todos os gostos. Portanto, o domínio foi adquirido e vinculado a endereços IP em um VPS rodando tcpdump e a contagem começou.
Auditoria de "Auditores"
Eu esperava ver explosões periódicas de solicitações, o que, na minha opinião, indicaria uma ação controlada. É impossível dizer que não vi nada, mas definitivamente não havia uma imagem clara:
O que não é surpreendente, mesmo num domínio que ninguém precisa e num IP nunca utilizado, haverá simplesmente uma tonelada de informação não solicitada, como é a Internet moderna. Mas, felizmente, eu só precisava de solicitações de uma URL específica, então todos os scanners e crackers de senhas foram encontrados rapidamente. Além disso, foi muito fácil entender onde estava a inundação com base na massa de pedidos semelhantes. Em seguida, compilei a frequência de ocorrência dos endereços IP e percorri todo o topo manualmente, separando aqueles que perderam nas etapas anteriores. Além disso, cortei todas as fontes que foram enviadas em um pacote, não eram mais muitas. E isso é o que aconteceu:
Uma pequena digressão lírica. Pouco mais de um dia depois, meu provedor de hospedagem enviou uma carta com conteúdo bastante simplificado, informando que suas instalações contêm um recurso da lista de proibidos RKN, por isso está bloqueado. A princípio pensei que minha conta estava bloqueada, não foi o caso. Então pensei que eles estavam simplesmente me alertando sobre algo que eu já sabia. Mas aconteceu que o hoster ativou seu filtro na frente do meu domínio e, como resultado, fiquei sob dupla filtragem: dos provedores e do hoster. O filtro passou apenas nos finais das solicitações: FIN-ACK и RST cortando todo o HTTP em um URL proibido. Como você pode ver no gráfico acima, a partir do primeiro dia comecei a receber menos dados, mas ainda recebi, o que foi suficiente para a tarefa de contagem das fontes de solicitação.
Vá direto ao ponto. Na minha opinião, duas rajadas são claramente visíveis todos os dias, a primeira menor, depois da meia-noite, horário de Moscou, a segunda perto das 6h com cauda até as 12h. O pico não ocorre exatamente ao mesmo tempo. A princípio, queria selecionar endereços IP que caíssem apenas nesses períodos e cada um em todos os períodos, partindo do pressuposto de que as verificações dos Agentes são realizadas periodicamente. Mas, após uma análise cuidadosa, descobri rapidamente períodos que caíam em outros intervalos, com outras frequências, até uma solicitação a cada hora. Aí pensei em fusos horários e que talvez tivesse algo a ver com eles, depois pensei que em geral o sistema poderia não estar sincronizado globalmente. Além disso, o NAT provavelmente desempenhará um papel e o mesmo Agente poderá fazer solicitações de diferentes IPs públicos.
Como meu objetivo inicial não era exatamente, contei todos os endereços que encontrei em uma semana e consegui - 2791. O número de sessões TCP estabelecidas a partir de um endereço é em média 4, com mediana de 2. Principais sessões por endereço: 464, 231, 149, 83, 77. O máximo de 95% da amostra é de 8 sessões por endereço. A mediana não é muito alta, lembro que o gráfico mostra uma periodicidade diária clara, então pode-se esperar algo em torno de 4 a 8 em 7 dias. Se descartarmos todas as sessões que ocorrem uma vez, obteremos uma mediana igual a 5. Mas não poderia excluí-las com base em um critério claro. Pelo contrário, uma verificação aleatória mostrou que estavam relacionados com pedidos de um recurso proibido.
Endereços são endereços, mas na Internet existem sistemas autônomos - AS, que se revelaram mais importantes 1510, em média 2 endereços por AS com mediana de 1. Principais endereços por AS: 288, 77, 66, 39, 27. O máximo de 95% da amostra é de 4 endereços por AS. Aqui a mediana é esperada – um Agente por provedor. Também esperamos o topo – há grandes jogadores nisso. Em uma rede grande, os Agentes provavelmente deverão estar localizados em cada região de presença da operadora, e não se esqueça do NAT. Se considerarmos por país, os máximos serão: 1409 - RU, 42 - UA, 23 - CZ, 36 de outras regiões, não RIPE NCC. Pedidos de fora da Rússia chamam a atenção. Provavelmente isso pode ser explicado por erros de geolocalização ou erros do registrador no preenchimento dos dados. Ou o facto de uma empresa russa poder não ter raízes russas, ou ter um escritório de representação estrangeiro porque é mais fácil, o que é natural quando se trata de uma organização estrangeira RIPE NCC. Alguma parte é sem dúvida supérflua, mas é difícil separá-la com segurança, pois o recurso está em bloqueio, e a partir do segundo dia em bloqueio duplo, e a maioria das sessões é apenas uma troca de vários pacotes de serviço. Vamos combinar que esta é uma pequena parte.
Esses números já podem ser comparados com o número de fornecedores na Rússia. licenças para “Serviços de comunicação para transmissão de dados, excluindo voz” - 6387, mas esta é uma estimativa muito elevada vista de cima, nem todas estas licenças se aplicam especificamente a fornecedores de Internet que necessitam de instalar um Agente. Na zona RIPE NCC há um número semelhante de ASes registrados na Rússia - 6230, dos quais nem todos são fornecedores. e recebeu 3940 empresas em 2017, e esta é mais uma estimativa de cima. De qualquer forma, temos duas vezes e meia menos número de ASs iluminados. Mas aqui vale a pena entender que o AS não é estritamente igual ao provedor. Alguns provedores não possuem seu próprio AS, alguns possuem mais de um. Se assumirmos que todos ainda têm Agentes, então alguém filtra com mais força do que outros, de modo que suas solicitações sejam indistinguíveis do lixo, se é que chegam até eles. Mas, para uma avaliação aproximada, é bastante tolerável, mesmo que algo tenha sido perdido devido à minha supervisão.
Sobre DPI
Apesar de meu provedor de hospedagem ter ativado seu filtro a partir do segundo dia, com base nas informações do primeiro dia podemos concluir que o bloqueio está funcionando com sucesso. Apenas 4 fontes conseguiram passar e concluíram completamente as sessões HTTP e TCP (como no exemplo acima). Outros 460 podem ser enviados GET, mas a sessão é imediatamente encerrada por RST. Prestar atenção em 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"
Variações disso podem ser diferentes: menos RST ou mais retransmissões - também depende do que o filtro envia ao nó de origem. Em qualquer caso, este é o modelo mais confiável, do qual fica claro que se trata de um recurso proibido que foi solicitado. Além disso, sempre há uma resposta que aparece na sessão com TTL maior do que nos pacotes anteriores e subsequentes.
Você nem consegue ver isso do 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 então:
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 diferença é definitivamente visível TTL se algo vier do filtro. Mas muitas vezes nada pode acontecer:
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 então:
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 tudo isso se repete e se repete e se repete, como pode ser visto no gráfico, mais de uma vez, todos os dias.
Sobre IPv6
A boa notícia é que ela existe. Posso dizer com segurança que solicitações periódicas para um recurso proibido ocorrem a partir de 5 endereços IPv6 diferentes, que é exatamente o comportamento dos Agentes que eu esperava. Além disso, um dos endereços IPv6 não se enquadra na filtragem e vejo uma sessão completa. De mais duas vi apenas uma sessão inacabada, uma das quais foi interrompida por RST do filtro, o segundo no tempo. Montante total 7.
Como são poucos os endereços, estudei todos detalhadamente e descobri que só existem 3 provedores, eles podem ser aplaudidos de pé! Outro endereço é hospedagem em nuvem na Rússia (não filtra), outro é um centro de pesquisa na Alemanha (existe filtro, onde?). Mas por que eles verificam a disponibilidade de recursos proibidos dentro de um cronograma é uma boa pergunta. Os dois restantes fizeram uma solicitação e estão localizados fora da Rússia, e um deles está filtrado (afinal, em trânsito?).
Bloqueios e Agentes são um grande obstáculo para o IPv6, cuja implementação não está avançando muito rapidamente. É triste. Aqueles que resolveram este problema podem estar totalmente orgulhosos de si mesmos.
Em conclusão
Não busquei 100% de precisão, por favor me perdoe por isso, espero que alguém queira repetir este trabalho com maior precisão. Era importante para mim compreender se esta abordagem funcionaria em princípio. A resposta é sim. Os números obtidos, numa primeira aproximação, penso eu, são bastante confiáveis.
O que mais poderia ter sido feito e o que eu estava com preguiça de fazer era contar as solicitações de DNS. Eles não são filtrados, mas também não oferecem muita precisão, pois funcionam apenas para o domínio, e não para a URL inteira. A frequência deve ser visível. Se você combinar com o que está visível diretamente nas consultas, isso permitirá separar o desnecessário e obter mais informações. É ainda possível determinar os desenvolvedores do DNS utilizado pelos provedores e muito mais.
Eu absolutamente não esperava que o hoster também incluísse seu próprio filtro para meu VPS. Talvez esta seja uma prática comum. No final, RKN envia uma solicitação para excluir o recurso ao hoster. Mas isso não me surpreendeu e, de certa forma, até funcionou a meu favor. O filtro funcionou de forma muito eficaz, cortando todas as solicitações HTTP corretas para uma URL proibida, mas não as corretas que haviam passado anteriormente pelo filtro dos provedores as alcançaram, ainda que apenas na forma de finais: FIN-ACK и RST - menos por menos e quase acabou sendo um sinal de mais. A propósito, o IPv6 não foi filtrado pelo hoster. Claro que isso afetou a qualidade do material coletado, mas ainda assim permitiu ver a frequência. Descobriu-se que este é um ponto importante na hora de escolher um site para colocação de recursos, não se esqueça de se interessar pela questão da organização do trabalho com a lista de sites proibidos e solicitações do RKN.
No início comparei o AS "Inspector" com . Esta comparação é bastante justificada e uma grande rede de Agentes pode ser benéfica. Por exemplo, determinar a qualidade da disponibilidade de recursos de diferentes fornecedores em diferentes partes do país. Você pode calcular atrasos, construir gráficos, analisar tudo e ver as mudanças que ocorrem tanto local quanto globalmente. Esta não é a forma mais direta, mas os astrônomos usam “velas padrão”, por que não usar Agentes? Conhecendo (tendo encontrado) seu comportamento padrão, é possível determinar as mudanças que ocorrem ao seu redor e como isso afeta a qualidade dos serviços prestados. E, ao mesmo tempo, você não precisa colocar sondas na rede de forma independente; Roskomnadzor já as instalou.
Outro ponto que quero abordar é que toda ferramenta pode ser uma arma. AS “Inspetor” é uma rede fechada, mas os Agentes entregam todos enviando solicitações para todos os recursos da lista proibida. Ter tal recurso não apresenta nenhum problema. No total, os provedores por meio de Agentes, involuntariamente, contam muito mais sobre sua rede do que provavelmente vale a pena: tipos de DPI e DNS, localização do Agente (nó central e rede de serviço?), marcadores de rede de atrasos e perdas - e isso é apenas o mais óbvio. Assim como alguém pode monitorar as ações dos Agentes para melhorar a disponibilidade de seus recursos, alguém pode fazer isso para outros fins e não há obstáculos para isso. O resultado é um instrumento de dois gumes e muito multifacetado, qualquer um pode perceber isso.
Fonte: habr.com