Não é segredo que a supervisão do bloqueio de informações proibidas na Rússia é feita por um sistema automatizado chamado "Revisor". Como isso funciona é bem abordado neste , imagem do mesmo:
É instalado diretamente no provedor :
O módulo "Agente Revisor" é um elemento estrutural do sistema automatizado "Revisor" (AS "Revisor"). Este sistema é destinado a controlar o cumprimento das exigências dos operadores de telecomunicações em relação à restrição de acesso, conforme estabelecido nos artigos 15.1-15.4 da Lei Federal nº 149-FZ, de 27 de julho de 2006, "Sobre informações, tecnologias de informação e proteção de informações."
O principal objetivo da criação da AS "Revisor" é garantir a supervisão do cumprimento pelas operadoras de telecomunicações das exigências estabelecidas nos artigos 15.1-15.4 da Lei Federal nº 149-FZ, de 27 de julho de 2006, "Sobre informações, tecnologias de informação e proteção de informações" no que diz respeito à identificação de casos de acesso a informações proibidas e à obtenção de materiais (dados) comprobatórios sobre violações das restrições de acesso a informações proibidas.
Considerando que, se não todos, muitos provedores instalaram este dispositivo, deveria ter sido criada uma grande rede de amostras-marco semelhante a e até mais, mas com acesso restrito. No entanto, um marco é um marco para enviar sinais em todas as direções, e e se nós os capturarmos e olharmos o que pegamos e quantos?
Antes de contar, vamos ver por que isso pode ser possível.
Um pouco de teoria
Os agentes verificam a disponibilidade do recurso, incluindo por meio de solicitações HTTP(S), como esta, por 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 estabelecimento da conexão: troca de e muitos outros. Mas a questão é outra, e SYN-ACK, e da fase de finalização da conexão: FIN-ACK.
O registro de informações proibidas contém vários tipos de bloqueios. É evidente que, se um recurso for bloqueado por endereço IP ou nome de domínio, não veremos nenhuma solicitação. Estes são os tipos de bloqueios mais destrutivos, que levam à indisponibilidade de todos os recursos em um mesmo endereço IP ou de toda a informação em um domínio. Também existe o tipo de bloqueio "por URL". Neste caso, o sistema de filtragem precisa analisar o cabeçalho HTTP da solicitação para determinar exatamente o que bloquear. E antes disso, como visto acima, deve ocorrer a fase de estabelecimento de conexão, que pode ser monitorada, pois é provável que o filtro a permita passar.
Para isso, é necessário 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, preferencialmente um que esteja há muito abandonado, para minimizar a entrada de tráfego externo além dos Agentes. Essa tarefa não se mostrou muito complicada; há muitos domínios livres no registro de informações proibidas, variados e para todos os gostos. Assim, o domínio foi adquirido e vinculado aos endereços IP em um VPS com o tcpdump e a contagem começou.
Revisão dos "Revisores"
Eu esperava ver picos periódicos de solicitações, o que indicaria, na minha opinião, uma ação controlada. Não posso dizer que não vi nada disso, mas não havia uma imagem clara:
O que não é surpreendente, mesmo em um domínio inútil em um IP nunca utilizado, haverá um grande volume de informações não solicitadas, essa é a realidade da Internet moderna. Mas, felizmente, eu precisava apenas das solicitações de um URL específico, portanto, todos os scanners e tentativas de quebra de senha foram rapidamente identificados. Também foi bastante fácil perceber onde o fluxo era formado por um grande número de solicitações similares. Em seguida, compilei a frequência de aparição dos endereços IP e revisei todo o topo manualmente, separando aqueles que passaram pelas etapas anteriores. Além disso, cortei todas as fontes que enviaram apenas um pacote, que já eram poucas. E isso resultou no seguinte:
Uma pequena digressão lírica. Um pouco mais de um dia depois, meu provedor de hospedagem enviou uma carta de conteúdo bastante ambíguo, alegando que em seus servidores havia um recurso da lista proibida pelo RKN, portanto, estava sendo bloqueado. A princípio, pensei que meu conta tinha sido bloqueada, mas não foi o caso. Depois, pensei que estavam apenas me alertando sobre algo que eu já sabia. Porém, descobri que o provedor aplicou seu filtro antes do meu domínio e, no final, fiquei sob uma dupla filtragem: do lado dos provedores e do lado do provedor de hospedagem. O filtro permitia apenas os finais dos pedidos: FIN-ACK e RST cortando todo o HTTP por uma URL proibida. Como pode ser visto no gráfico acima, após as primeiras 24 horas, comecei a receber menos dados, mas ainda assim os recebia, o que foi suficiente para a tarefa de contagem das fontes de pedidos.
Aproximando-me do assunto. Na minha opinião, é visível de forma bem clara que há dois picos todos os dias, o primeiro menor, após a meia-noite em Moscovo, e o segundo mais próximo das 6 da manhã, com um rabo até ao meio-dia. O pico não ocorre exatamente ao mesmo tempo. A princípio, eu queria destacar os endereços IP que caíam apenas nesses períodos e todos os períodos, a partir da suposição de que as verificações pelos Agentes ocorrem periodicamente. Mas, ao olhar mais de perto, rapidamente percebi períodos que se encaixam em outros intervalos, com diferentes frequências, até um pedido a cada hora. Depois pensei sobre os fusos horários e que talvez fosse isso, e então considerei que todo o sistema pode não estar sincronizado globalmente. Além disso, certamente, o NAT desempenhará um papel e o mesmo Agente pode fazer solicitações de diferentes IPs públicos.
Como meu objetivo inicial não era a precisão, contei todos os endereços que apareceram na semana e obtive — 2791. O número de sessões TCP estabelecidas a partir de um endereço é em média 4, com a mediana de 2. Top de sessões por endereço: 464, 231, 149, 83, 77. O máximo da amostra de 95% foi de 8 sessões por endereço. A mediana não é muito alta, lembrando que o gráfico mostra uma clara periodicidade diária, então seria de se esperar algo em torno de 4 a 8 ao longo de 7 dias. Se eu excluir todas as sessões que apareceram apenas uma vez, obteremos uma mediana igual a 5. Mas não consegui excluí-las com um critério claro. Pelo contrário, a verificação da amostra mostrou que elas estão relacionadas aos pedidos do recurso proibido.
Endereços são importantes, mas na Internet, sistemas autônomos — AS são ainda mais relevantes. 1510, em média, 2 endereços por AS com uma mediana de 1. Principais endereços em AS: 288, 77, 66, 39, 27. O máximo de 95% da amostra — 4 endereços por AS. Aqui, a mediana é esperado — um Agente por provedor. O ranking também é previsível — inclui grandes players. Em uma rede grande, os Agentes provavelmente devem estar em cada região de presença do operador, sem esquecer do NAT. Se analisarmos por países, os máximos serão: 1409 — RU, 42 — UA, 23 — CZ, 36 de outras regiões, não RIPE NCC. As solicitações fora da Rússia chamam a atenção. Provavelmente, isso pode ser explicado por erros de geolocalização ou erros dos registradores ao preencher os dados. Ou porque uma empresa russa pode ter raízes não russas ou ter uma representação estrangeira, pois isso facilita ao lidar com a organização estrangeira RIPE NCC. Certamente, uma parte é desnecessária, mas separá-la de forma confiável é difícil, pois o recurso está bloqueado, e a partir do segundo dia sob bloqueio duplo, e a maioria das sessões consiste apenas em trocar alguns pacotes de serviço. Vamos considerar que isso é uma pequena parte.
Esses números já podem ser comparados com a quantidade de provedores na Rússia. licenças para "Serviços de comunicação para transmissão de dados, exceto voz" — 6387, mas essa é uma estimativa muito alta, nem todas essas licenças se referem exatamente aos provedores de Internet que precisam ter Agentes. Na zona RIPE NCC, um número semelhante de AS registrados na Rússia é 6230, dos quais nem todos são provedores. e obteve 3940 empresas em 2017, e isso é provavelmente uma estimativa alta. De qualquer forma, temos um número de AS visíveis que é duas vezes e meia menor. Mas aqui é importante entender que AS não é estritamente igual a provedor. Alguns provedores não têm seu próprio AS, e alguns têm mais de um. Se supusermos que os Agentes estão realmente em todos os lugares, significa que alguém filtra mais forte do que os outros, de modo que suas solicitações são indistinguíveis de lixo, se é que chegam. Mas para uma avaliação grosseira, é bastante aceitável, mesmo que algo tenha sido perdido devido à minha descuido.
Sobre DPI
Embora meu provedor de hospedagem tenha ativado seu filtro a partir do segundo dia, com base nas informações do primeiro dia, pode-se concluir que as bloqueios funcionam com eficácia. Apenas 4 fontes conseguiram se conectar e têm sessões HTTP e TCP completamente finalizadas (como no exemplo acima). Outras 460 podem enviar GET, mas a sessão é instantaneamente cortada por RST. Observe 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"
#Isso foi enviado pelo filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#E esta é a tentativa do nó de origem de detectar a perda
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"
#O nó de origem entende que a sessão foi destruída
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
As variações disso podem ser diferentes: menos RST ou mais retransmissões — isso também depende do que o filtro envia ao nó de origem. De qualquer forma, este é o padrão mais confiável, que mostra que o recurso proibido foi realmente solicitado. Além disso, sempre há uma resposta que aparece na sessão com TTL mais do que nos pacotes anteriores e posteriores.
Dos outros, não se vê nem mesmo GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Isso foi enviado pelo filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Ou assim:
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"
#Isso foi enviado pelo filtro
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"
#Novamente o filtro, várias vezes
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
É sempre visível a diferença em TTL se algo chega do filtro. Mas muitas vezes pode não 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 assim:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Se passaram alguns segundos sem tráfego
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
E tudo isso se repete, se repete e se repete, como mostrado no gráfico, com certeza não é uma vez, mas a cada dia.
Sobre IPv6
Boa notícia — ele existe. Posso afirmar com certeza que a partir de 5 endereços IPv6 diferentes ocorrem solicitações periódicas a um recurso proibido, exatamente o comportamento dos Agentes que eu esperava. Além disso, um dos endereços IPv6 não é filtrado e vejo uma sessão completa. Com outros dois, vi apenas uma sessão não concluída, uma das quais foi interrompida por RST filtro, a outra por tempo. No total, 7.
Como há poucos endereços, estudei todos eles detalhadamente e descobri que, na verdade, existem apenas 3 provedores, a quem merecem aplausos em pé! Um dos endereços é uma hospedagem em nuvem na Rússia (não filtra), outro é um centro de pesquisa na Alemanha (existe filtro, onde?). A questão é por que eles verificam periodicamente a acessibilidade de recursos proibidos. Os outros dois fizeram uma solicitação cada e estão fora dos limites da Rússia, sendo que um deles é filtrado (ainda está em trânsito?).
Bloqueios e Agentes são um grande obstáculo para o IPv6, cuja implementação já avança lentamente. Isso é lamentável. Aqueles que resolveram essa tarefa em sua totalidade podem se orgulhar.
Para concluir
Não busquei 100% de precisão, por favor, me perdoem por isso, espero que alguém queira repetir esse trabalho com maior precisão. Para mim, era importante entender se esse tipo de abordagem funcionaria em princípio. A resposta é que funcionará. Os números obtidos são, em uma primeira aproximação, acredito, bastante confiáveis.
O que mais poderia ter sido feito e que tive preguiça de fazer — contar as solicitações ao DNS. Elas não são filtradas, mas também não oferecem muita precisão, já que funcionam apenas para o domínio, e não para toda a URL. A periodicidade deve ser visível. Se combinarmos com o que é visível diretamente nas solicitações, isso permitirá separar o supérfluo e obter mais informações. Talvez até identificar os desenvolvedores do DNS usados pelos provedores e muito mais.
Eu realmente não esperava que o provedor do meu VPS implementasse também seu próprio filtro. Pode ser uma prática comum. Afinal, o RKN envia um pedido para a remoção do recurso diretamente ao provedor. Mas isso não me surpreendeu e até de certa forma foi benéfico. O filtro funcionou de maneira muito eficaz, cortando todas as solicitações HTTP corretas para a URL proibida, mas as incorretas, que passaram antes pelo filtro dos provedores, chegavam, ainda que apenas na forma de terminações: FIN-ACK e RST — menos com menos e quase se tornou mais. A propósito, o provedor de hospedagem IPv6 não foi filtrado. Claro, isso influenciou a qualidade do material coletado, mas ainda assim proporcionou a oportunidade de ver a periodicidade. Descobriu-se que este é um aspecto importante na escolha de uma plataforma para hospedar recursos; não se esqueçam de perguntar sobre a organização do trabalho com a lista de sites proibidos e as solicitações do РКН.
No início, comparai o AS "Revisor" com . Essa comparação é bastante apropriada e uma grande rede de Agentes pode ser benéfica. Por exemplo, a determinação da qualidade de acessibilidade de recursos de diferentes provedores em várias partes do país. É possível medir latências, construir gráficos, analisar tudo isso e observar as mudanças que ocorrem tanto localmente quanto globalmente. Este não é o caminho mais direto, mas os astrônomos usam "velas padrão"; por que não usar Agentes? Conhecendo (ou encontrando) seu comportamento padrão, é possível determinar as mudanças ao redor deles e como isso afeta a qualidade dos serviços prestados. E não é necessário posicionar amostras pela rede; o Roskomnadzor já as colocou.
Outro ponto que quero abordar é que cada ferramenta pode ser uma arma. O AS "Revisor" é uma rede fechada, mas os Agentes expõem tudo enviando solicitações a todos os recursos da lista proibida. Obter tal recurso não apresenta absolutamente nenhum problema. Assim, os provedores através dos Agentes, sem querer, revelam muito mais sobre suas redes do que talvez deveriam: tipos de DPI e DNS, localização do Agente (nó central e rede de serviços?), marcadores de rede de latências e perdas — e isso é apenas o mais óbvio. Assim como alguém pode monitorar as ações dos Agentes para melhorar a acessibilidade de seus recursos, outra pessoa pode fazer isso com outros objetivos, e não há obstáculos para isso. O resultado foi uma ferramenta de duas facetas e muito versátil, qualquer um pode verificar.
Fonte: habr.com
