Não é segredo que o sistema automatizado "Inspetor" monitora o controle de bloqueios na lista de informações proibidas na Rússia. Como funciona está bem escrito aqui neste
artigo sobre Habr , a imagem é de lá:
O
módulo "Agent Auditor" do provedor
é instalado diretamente no provedor:
O módulo "Agent Auditor" é um elemento estrutural do sistema automatizado "Auditor" (AS "Auditor"). Este sistema foi projetado para monitorar o cumprimento pelas operadoras de telecomunicações das restrições de acesso no âmbito das disposições estabelecidas nos artigos 15.1 a 15.4 da Lei Federal de 27 de julho de 2006, nº 149- “Informações, tecnologias da informação e proteção da informação”.
O principal objetivo da criação do Auditor AS é monitorar a conformidade das operadoras de telecomunicações com os requisitos estabelecidos nos Artigos 15.1 a 15.4 da Lei Federal de 27 de julho de 2006, nº 149- “Sobre Informação, Tecnologias da Informação e Proteção de Informações”, com relação à 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.
Dado que, se não todos, muitos provedores instalaram esse dispositivo em casa, eles deveriam ter uma grande rede de sondas beacon como o
RIPE Atlas e muito mais, mas com acesso fechado. No entanto, o farol é o farol para enviar sinais em todas as direções, mas e se os pegarmos e vermos o que pegamos e quantos?
Antes de contar, vamos ver por que isso pode ser possível.
Pouco de teoria
Os agentes verificam a disponibilidade de um recurso, inclusive por meio de solicitações HTTP (S), como este exemplo:
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"
A solicitação, além da carga útil, também consiste na fase de configuração da conexão: troca de
SYN e
SYN-ACK e na fase de conclusão da conexão:
FIN-ACK .
O registro de informações proibidas contém vários tipos de bloqueios. Obviamente, se o recurso for bloqueado pelo endereço IP ou nome de domínio, não veremos nenhuma solicitação. Esses são os tipos mais destrutivos de bloqueios que levam à inacessibilidade de todos os recursos no mesmo endereço IP ou de todas as informações no domínio. Há também um tipo de bloqueio de URL. Nesse caso, o sistema de filtragem deve analisar o cabeçalho da solicitação HTTP para determinar exatamente o que bloquear. Antes disso, como pode ser visto acima, a fase de configuração da conexão deve ocorrer, a qual você pode tentar rastrear, pois provavelmente o filtro irá ignorá-lo.
Para fazer isso, você precisa escolher um domínio livre adequado com o tipo de bloqueio "por URL" e HTTP, a fim de facilitar o trabalho do sistema de filtragem, de preferência abandonado há muito tempo, para minimizar a entrada de tráfego estranho, exceto por agentes. Esta tarefa não foi nada difícil, existem muitos domínios gratuitos no registro de informações proibidas para todos os gostos. Portanto, o domínio foi adquirido, vinculado aos endereços IP no VPS com o
tcpdump execução e a contagem começou.
Auditoria dos “Auditores”
Eu esperava ver explosões periódicas de solicitações, o que, na minha opinião, indicaria uma ação controlada. Isso não quer dizer que eu não tenha visto isso, mas definitivamente não havia uma imagem clara:
Não é de surpreender que mesmo um domínio desnecessário para um IP não utilizado receba simplesmente uma massa de informações não solicitadas, como a Internet moderna. Felizmente, porém, eu precisava apenas de solicitações para um URL específico, para que todos os rastreadores e senhas de senha fossem encontrados rapidamente. Além disso, era simples o suficiente para entender onde estava a inundação pela massa do mesmo tipo de solicitações. Em seguida, compilei a frequência de ocorrência de endereços IP e andei pelo topo separando manualmente aqueles que escorregaram nas etapas anteriores. Além disso, recortei todas as fontes que enviaram um pacote, não havia muitas. E aconteceu isso:
Uma ligeira digressão lírica. Pouco mais de um dia depois, meu provedor de hospedagem enviou uma mensagem bastante simplificada, eles dizem que em suas instalações existe um recurso da lista proibida de ILV, para que seja bloqueado. No começo, pensei que eles bloqueavam minha conta, não era assim. Então eu pensei que eles estavam apenas me alertando sobre o que eu já sabia. Porém, o hoster ativou o filtro na frente do meu domínio e, como resultado, fui submetido a uma filtragem dupla: dos provedores e do host. O filtro ignorou apenas o final das solicitações:
FIN-ACK e
RST cortando todo o HTTP no URL proibido. Como você pode ver no gráfico acima, após o primeiro dia comecei a receber menos dados, mas ainda os recebia, o que era suficiente para a tarefa de calcular fontes de consulta.
Vá direto ao ponto. Na minha opinião, duas explosões são claramente visíveis todos os dias, a primeira menos depois da meia-noite em Moscou, a segunda mais perto das 6 da manhã, com uma cauda de até 12 dias. O pico não ocorre exatamente ao mesmo tempo. Primeiro, eu queria destacar os endereços IP que caíram apenas nesses períodos e cada um em todos os períodos, com base no pressuposto de que os agentes verificam periodicamente. Mas, após uma visualização cuidadosa, descobri rapidamente períodos que caíam em outros intervalos, com frequências diferentes, até uma solicitação a cada hora. Depois pensei sobre os fusos horários e o que é possível neles, depois pensei que, em geral, o sistema pode não ser sincronizado globalmente. Além disso, com certeza, o NAT desempenhará seu papel, e o mesmo Agente pode fazer solicitações de diferentes IPs públicos.
Como meu objetivo original não era exatamente, contei todos os endereços que recebi em uma semana e recebi
2791 . O número de sessões TCP estabelecidas a partir de um endereço é em média 4, com uma 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-me de que o cronograma mostra uma frequência diária clara, então você pode esperar algo em torno de 4 a 8 em 7 dias. Se você jogar fora todas as sessões da reunião uma vez, obteremos a mediana igual a 5. Mas não pude excluí-las de forma clara. Pelo contrário, as verificações pontuais mostraram que estão relacionadas a solicitações de um recurso proibido.
Os endereços e, na Internet, os sistemas autônomos são mais importantes - o AS, dos quais
1510 foram
lançados , em média 2 endereços no AS com mediana 1. Endereços principais no AS: 288, 77, 66, 39, 27. O máximo de 95% da amostra é de 4 endereços no AS. Aqui a média é esperada - um agente por provedor. Também esperamos o topo - há grandes jogadores nele. Em uma rede grande, os agentes provavelmente devem estar em cada região da presença da operadora e não se esqueça do NAT. Se você escolher por país, o máximo será: 1409 - RU, 42 - UA, 23 - CZ, 36 de outras regiões, não o RIPE NCC. Pedidos não da Rússia atraem atenção. Talvez isso possa ser explicado por erros de localização geográfica ou erros de registrador ao preencher os dados. Ou o fato de que uma empresa russa pode ter raízes não russas ou ter um escritório de representação estrangeiro, porque é tão mais simples que é natural lidar com uma organização estrangeira RIPE NCC. Alguma parte é indubitavelmente supérflua, mas é confiável separá-la, pois o recurso está bloqueado e, a partir do segundo dia, sob bloqueio duplo, e a maioria das sessões é apenas uma troca de vários pacotes de serviços. Vamos concordar com o fato de que essa é uma pequena parte.
Esses números já podem ser comparados com o número de fornecedores na Rússia.
De acordo com o ILV, as licenças para "Serviços de comunicação para transmissão de dados, exceto voz" são 6387, mas esta é uma classificação altamente intimidada acima, nem todas essas licenças são especificamente para provedores de Internet que precisam instalar o Agente. Na zona RIPE NCC, um número semelhante de AS registrado na Rússia é 6230, dos quais nem todos os provedores.
O UserSide fez um cálculo mais rigoroso e recebeu 3940 empresas em 2017, e essa é provavelmente uma estimativa acima. De qualquer forma, temos o número de AS iluminado duas vezes e meia menos. Mas aqui vale a pena entender que o AS não é estritamente igual ao provedor. Alguns provedores não têm seu próprio AS, outros têm mais de um. Se assumirmos que os agentes ainda estão em todos, alguém filtra mais do que os outros, para que suas solicitações sejam indistinguíveis do lixo, se é que existem. Mas, para uma avaliação grosseira, é bastante tolerável, mesmo que algo tenha sido perdido devido à minha supervisão.
Sobre o DPI
Apesar de meu provedor de hospedagem ter ativado seu filtro desde o segundo dia, de acordo com as informações do primeiro dia, podemos concluir que os bloqueios funcionam com êxito. Somente 4 fontes conseguiram avançar e concluíram completamente as sessões HTTP e TCP (como no exemplo acima). Outros 460 podem enviar um
GET , mas a sessão termina instantaneamente no
RST . Preste atenção ao
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"
Variações disso podem ser diferentes: menos
RST ou mais retransmissões - isso também depende do que o filtro envia para o nó de origem. De qualquer forma, esse é o modelo mais confiável, do qual fica claro que o recurso proibido foi solicitado. Além disso, sempre há uma resposta que aparece em uma sessão com um
TTL maior que nos pacotes anteriores e subseqüentes.
Até o
GET não
GET visível do resto:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0" TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=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"
A diferença no
TTL é certamente visível se algo chegar do filtro. Mas muitas vezes pode não voar:
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"
E tudo isso se repete, se repete e se repete, como pode ser visto no gráfico, exatamente mais de uma vez, todos os dias.
Sobre o IPv6
A boa notícia é que ele é. Posso dizer com segurança que, em 5 endereços IPv6 diferentes, há solicitações periódicas para o recurso proibido, 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. Com mais duas, vi apenas uma sessão incompleta, uma das quais foi interrompida pelo
RST do filtro, a segunda no tempo. Um total de
7 .
Como existem poucos endereços, estudei todos eles detalhadamente, e constatamos que existem apenas três fornecedores, é possível aplaudi-los de pé! Outro endereço é hospedagem na nuvem na Rússia (não filtra), outro é um centro de pesquisa na Alemanha (existe um filtro, onde?). Mas por que eles verificam dentro do prazo a disponibilidade de recursos proibidos é uma boa pergunta. Os dois restantes fizeram um pedido e não estão nas fronteiras da Rússia, com um deles sendo filtrado (ainda está em trânsito?).
Bloqueios e agentes é um grande freio no IPv6, cuja implementação não está sendo muito rápida. Isso é triste Aqueles que resolveram essa tarefa estão totalmente orgulhosos de si mesmos.
Em conclusão
Não persegui 100% de precisão, peço que me perdoe por isso, espero que alguém queira repetir este trabalho com maior precisão. Era importante para mim entender se tal abordagem funcionaria em princípio. A resposta será. Os números resultantes de uma primeira aproximação, eu acho, são bastante confiáveis.
O que mais poderia ser feito e o que eu estava com preguiça de fazer era calcular as consultas 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 todo o URL. A frequência deve estar visível. Se você combinar com o que é diretamente visível nas solicitações, isso permitirá que você separe o excesso e obtenha mais informações. É até possível identificar os desenvolvedores de DNS usados pelos fornecedores e muito mais.
Eu absolutamente não esperava que, para o meu VPS, o hoster também incluísse seu próprio filtro. Talvez essa seja uma prática comum. No final, o ILV envia uma solicitação para excluir o recurso ao hoster. Mas não me surpreendeu e até jogou com alguma vantagem. O filtro funcionou muito eficientemente cortando todas as solicitações HTTP corretas para a URL proibida, mas não as corretas que passavam pelo filtro dos provedores antes, mesmo que apenas na forma de finais:
FIN-ACK e
RST - menos menos e quase obtinham um plus. A propósito, o hoster IPv6 não foi filtrado. Obviamente, isso afetou a qualidade do material coletado, mas ainda possibilitou ver a frequência. Isso acabou sendo um ponto importante ao escolher um site para a 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 consultas do ILV.
No começo, comparei o “Auditor” do AC com o
RIPE Atlas . Essa comparação é justificada e uma grande rede de agentes pode ser benéfica. Por exemplo, determinar a qualidade da disponibilidade de recursos de vários fornecedores em diferentes partes do país. Você pode calcular os atrasos, criar gráficos, analisar tudo e ver as mudanças que ocorrem local e globalmente. Esta não é a maneira mais direta, mas os astrônomos usam "velas padrão", por que não usar agentes? Conhecendo (encontrando) seu comportamento padrão, você pode determinar as alterações que ocorrem ao seu redor e como isso afeta a qualidade dos serviços prestados. E, ao mesmo tempo, você não precisa instalar pontas de prova independentemente na rede, pois elas já foram fornecidas pela Roskomnadzor.
Outro ponto que quero abordar é que toda ferramenta pode ser uma arma. AS “Inspector” é uma rede fechada, mas os Agentes entregam a todos com crianças enviando solicitações de todos os recursos da lista proibida. Para se apossar de tal recurso não representa absolutamente nenhum problema. No total, os provedores por meio de Agentes informaram involuntariamente sobre sua rede muito mais do que valeria 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. Um instrumento de dois gumes e muito multifacetado acabou, qualquer um pode se convencer disso.