Il n'est pas secret que le contrôle des blocages sur la liste des informations interdites en Russie est surveillé par un système automatisé appelé « Réviseur ». Son fonctionnement est bien décrit dans cet , image tirée de là aussi :
Auprès du fournisseur, on installe :
Le module « Agent Réviseur » est un élément structural du système automatisé « Réviseur » (AS « Réviseur »). Ce système est destiné à contrôler la conformité des opérateurs de télécommunications aux exigences de restriction d'accès établies par les articles 15.1-15.4 de la loi fédérale du 27 juillet 2006 n° 149-FZ « Sur l'information, les technologies de l'information et la protection de l'information ».
L'objectif principal de la création de l'AS « Réviseur » est d'assurer le suivi de la conformité des opérateurs de télécommunications aux exigences stipulées dans les articles 15.1-15.4 de la loi fédérale du 27 juillet 2006 n° 149-FZ « Sur l'information, les technologies de l'information et la protection de l'information » concernant l'identification des accès à des informations interdites et l'obtention de preuves (données) sur les violations des restrictions d'accès à ces informations.
Étant donné que, si tous les, ou du moins la plupart des, fournisseurs ont installé cet appareil, il devrait exister un vaste réseau d'échantillons-bouées semblable à et même plus, mais avec un accès fermé. Cependant, une bouée est faite pour envoyer des signaux dans toutes les directions, et que se passerait-il si on les recevait et qu'on regardait ce que nous avons capté et combien ?
Avant de faire des calculs, voyons pourquoi cela peut même être possible.
Un peu de théorie
Les agents vérifient l'accessibilité des ressources, y compris via des requêtes HTTP(S), comme celle-ci par exemple :
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 requête, en plus de sa charge utile, se compose également d'une phase d'établissement de connexion : échange SYN et SYN-ACK, et d'une phase de terminaison de connexion : FIN-ACK.
Le registre des informations interdites contient plusieurs types de blocages. Il est évident que si une ressource est bloquée par adresse IP ou nom de domaine, nous ne verrons aucune requête. Ce sont les types de blocages les plus destructeurs, qui entraînent l'inaccessibilité de toutes les ressources sur une même adresse IP ou de toutes les informations sur un domaine. Il existe également un type de blocage « par URL ». Dans ce cas, le système de filtrage doit analyser l'en-tête HTTP de la requête pour déterminer exactement ce qu'il faut bloquer. Avant cela, comme mentionné ci-dessus, la phase d'établissement de connexion doit se produire, ce qui peut être suivi, car il est probable que le filtre la laisse passer.
Pour cela, il faut choisir un domaine libre approprié avec un type de blocage « par URL » et HTTP, afin de faciliter le travail du système de filtrage, de préférence un domaine abandonné depuis longtemps, pour minimiser le trafic indésirable en dehors des Agents. Cette tâche s'est révélée tout à fait simple, il y a beaucoup de domaines libres dans le registre des informations interdites, et pour tous les goûts. Ainsi, le domaine a été acquis, lié aux adresses IP sur un VPS avec tcpdump et le comptage a commencé.
Révision des « Vérificateurs »
Je m'attendais à voir des pics périodiques de requêtes, ce qui indiquerait, à mon avis, une action contrôlée. On ne peut pas dire que je ne l'ai pas vu du tout, mais il n'y avait clairement pas de tableau clair :
Ce qui n'est pas surprenant, même sur un domaine inutile sur une adresse IP jamais utilisée, il y aura simplement une multitude d'informations non demandées, tel est l'Internet moderne. Mais heureusement, j'avais seulement besoin de requêtes pour une URL spécifique, donc tous les scanners et les attaquants de mots de passe ont rapidement été trouvés. De plus, il était assez facile de comprendre où il y avait du spam dû à des requêtes similaires. Ensuite, j'ai compilé les fréquences d'apparition des adresses IP et j'ai parcouru tout le top manuellement, séparant ceux qui avaient échappé aux étapes précédentes. De plus, j'ai coupé toutes les sources qui avaient envoyé un seul paquet, elles n'étaient pas nombreuses. Et j'ai obtenu ceci :
Une petite digression lyrique. Un peu plus d'un jour plus tard, mon fournisseur d'hébergement a envoyé un courrier au contenu plutôt diplomatique, prétendant qu'il y avait une ressource dans la liste noire de la RKN sur vos serveurs, c'est pourquoi elle était bloquée. Au début, j'ai pensé qu'ils avaient bloqué mon compte, mais ce n'était pas le cas. Ensuite, j'ai pensé qu'ils m'avertissaient simplement de quelque chose que je savais déjà. Mais il s'est avéré que l'hébergeur avait activé son filtre devant mon domaine et, au final, j'ai été soumis à une double filtration : côté des fournisseurs et celui de l'hébergeur. Le filtre ne laissait passer que les fins de demandes : FIN-ACK et RST en coupant tout le HTTP par URL interdite. Comme on peut le voir sur le graphique ci-dessus, après les premières 24 heures, j'ai commencé à recevoir moins de données, mais je les recevais quand même, ce qui était suffisant pour le tâche de comptabiliser les sources de requêtes.
Pour en venir aux faits. À mon avis, il est évident qu'il y a deux pics chaque jour, le premier étant plus petit, juste après minuit à Moscou, le second plus proche de 6 heures du matin avec un prolongement jusqu'à midi. Le pic ne se produit pas exactement à la même heure. Au début, je voulais identifier les adresses IP qui tombaient uniquement dans ces périodes et celles dans toutes les périodes, partant du principe que les vérifications par les Agents sont effectuées périodiquement. Mais en regardant attentivement, j'ai rapidement découvert des périodes entrant dans d'autres intervalles, avec d'autres fréquences, jusqu'à une requête chaque heure. Puis j'ai pensé aux fuseaux horaires et à la possibilité que cela y soit lié, ensuite j'ai pensé que le système pourrait ne pas être synchronisé au niveau mondial. De plus, il est certain que le NAT joue également un rôle et qu'un même Agent peut faire des requêtes à partir de différentes adresses IP publiques.
Comme mon objectif initial n'était pas la précision, j'ai compté toutes les adresses qui apparaissaient au cours de la semaine et j'ai obtenu — 2791. Le nombre de sessions TCP établies à partir d'une seule adresse est en moyenne de 4, avec une médiane de 2. Les top sessions par adresse : 464, 231, 149, 83, 77. Maximum de l'échantillon à 95 % — 8 sessions par adresse. La médiane n'est pas très élevée, je me rappelle que le graphique montre une périodicité quotidienne évidente, donc on pouvait s'attendre à quelque chose entre 4 et 8 sur 7 jours. Si l'on exclut toutes les sessions qui apparaissent une seule fois, alors on obtient une médiane égale à 5. Mais je n'ai pas pu les exclure selon un critère clair. Au contraire, un contrôle par échantillonnage a montré qu'elles sont liées aux requêtes de la ressource interdite.
Les adresses sont importantes, mais sur Internet, les systèmes autonomes — AS — sont plus cruciaux, et il y en a beaucoup. 1510, en moyenne 2 adresses par AS avec une médiane de 1. Les principales adresses sur AS : 288, 77, 66, 39, 27. Le maximum des 95% de l'échantillon est de 4 adresses par AS. Ici, la médiane est attendue — un Agent par fournisseur. Les principaux acteurs sont également prévisibles. Dans un grand réseau, les Agents doivent probablement être présents dans chaque région où l'opérateur est actif, sans oublier le NAT. Si l'on regarde les pays, les maximums seront : 1409 — RU, 42 — UA, 23 — CZ, 36 d'autres régions, pas RIPE NCC. Les requêtes en dehors de la Russie attirent l'attention. Cela peut probablement s'expliquer par des erreurs de géolocalisation ou des erreurs de la part des registraires lors de la saisie des données. Ou parce qu'une entreprise russe peut avoir des racines non russes, ou avoir une représentation étrangère pour des raisons de simplicité, ce qui est compréhensible lorsqu'il s'agit d'organisations étrangères comme RIPE NCC. Une partie de ces données est sans aucun doute superflue, mais il est difficile de la distinguer de manière fiable, car la ressource est sous blocage, et depuis le deuxième jour, sous double blocage, et la plupart des sessions ne consistent qu'en l'échange de quelques paquets de service. Convenons que cela représente une petite portion.
Ces chiffres peuvent déjà être comparés au nombre de fournisseurs en Russie. il y a 6387 licences pour « Services de communication pour la transmission de données, sauf la voix », mais c'est une estimation considérablement exagérée ; toutes ces licences ne concernent pas spécifiquement les fournisseurs Internet, qui doivent installer un Agent. Dans la zone RIPE NCC, un nombre similaire d'AS est enregistré en Russie — 6230, parmi lesquels tous ne sont pas des fournisseurs. et a trouvé 3940 entreprises en 2017, et c'est plutôt une estimation supérieure. Quoi qu'il en soit, nous avons un nombre d'AS enregistrés qui est deux fois et demie moins élevé. Mais il est important de comprendre que AS n'égale pas strictement un fournisseur. Certains fournisseurs n'ont pas leur propre AS, tandis que d'autres en ont plus d'une. Si l'on suppose que des Agents sont effectivement présents chez tous, cela signifie que certains filtrent plus que d'autres, rendant leurs requêtes indiscernables des spams, si jamais elles parviennent à passer. Mais pour une évaluation grossière, c'est tout à fait acceptable, même si quelque chose a pu être perdu à cause de mes erreurs.
Concernant le DPI
Bien que mon fournisseur d'hébergement ait activé son filtre au bout de deux jours, les données du premier jour montrent que les blocages fonctionnent efficacement. Seules 4 sources ont réussi à passer et ont des sessions HTTP et TCP complètement terminées (comme dans l'exemple ci-dessus). En outre, 460 autres peuvent envoyer GET, mais la session se termine immédiatement par RST. Veuillez noter que 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"
#Ceci a été renvoyé par le filtre
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#Et ceci est la tentative du nœud source d'obtenir une perte
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"
#Le nœud source comprend que la session est interrompue
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Les variations à ce sujet peuvent être différentes : moins RST ou plus de retransmissions — cela dépend également de ce que le filtre envoie au nœud source. Dans tous les cas, c'est le modèle le plus fiable, montrant que la ressource interdite a été demandée. De plus, il y a toujours une réponse qui apparaît dans la session avec TTL plus grande que dans les paquets précédents et suivants.
Des autres, il n'y a même pas de visibilité GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Ceci a été renvoyé par le filtre
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Ou ainsi :
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"
#Ceci a été renvoyé par le filtre
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"
#Encore le filtre, de nombreuses fois
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Il est toujours visible qu'il y a une différence dans TTL si quelque chose arrive du filtre. Mais souvent, il n'y a rien du tout :
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 ainsi :
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Cela fait plusieurs secondes sans trafic
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Et tout cela se répète encore et encore, comme on le voit sur le graphique, pas moins d'une fois, tous les jours.
Concernant IPv6
Bonne nouvelle, il est là. Je peux affirmer avec certitude que des requêtes périodiques provenant de 5 adresses IPv6 différentes sont effectuées vers une ressource bloquée, exactement le comportement des Agents que j'attendais. De plus, l'une des adresses IPv6 ne passe pas sous filtrage et je vois une session complète. Encore deux m'ont montré seulement une session inachevée, dont l'une s'est interrompue à cause RST du filtre, l'autre à cause du temps. Au total, cela fait 7.
Étant donné qu'il y a peu d'adresses, j'ai étudié chacune d'elles en détail et il s'avère qu'il n'y a en réalité que 3 fournisseurs ; on peut vraiment les applaudir ! Une autre adresse provient d'un hébergement cloud en Russie (qui ne filtre pas), une autre d'un centre de recherche en Allemagne (il y a un filtre, où ?). La question est de savoir pourquoi ils vérifient périodiquement la disponibilité des ressources bloquées. Les deux autres ont effectué une requête chacune et se trouvent hors des frontières de la Russie, et l'une d'elles est filtrée (sûrement en transit ?).
Les blocages et les Agents sont un grand frein pour l'IPv6, dont l'implémentation avance déjà lentement. C'est regrettable. Ceux qui ont résolu ce problème à plein peuvent être fiers d'eux.
En conclusion
Je ne visais pas 100 % de précision, veuillez m'en excuser, j'espère que quelqu'un voudra répéter ce travail avec plus de rigueur. Pour moi, il était important de comprendre si cette approche fonctionnerait en principe. La réponse est oui. Les chiffres obtenus, en première approximation, sont à mon avis tout à fait fiables.
Que pourrait-on encore faire et ce que j'ai eu la paresse de ne pas faire — compter les requêtes DNS. Elles ne sont pas filtrées, mais ne donnent pas une grande précision car elles fonctionnent uniquement pour le domaine, et non pour l'URL complète. La périodicité devrait être visible. Si on combine cela avec ce qui est directement visible dans les requêtes, cela permettra d'éliminer le superflu et d'obtenir plus d'informations. On pourrait même déterminer les développeurs des DNS utilisés par les fournisseurs et bien plus encore.
Je ne m'attendais absolument pas à ce que mon hébergeur VPS active aussi son propre filtre. Peut-être est-ce une pratique courante. Après tout, le RKN envoie une demande de suppression de ressource justement à l'hébergeur. Mais cela ne m'a pas surpris et, d'une certaine manière, cela a même joué en ma faveur. Le filtre fonctionnait très efficacement, éliminant toutes les requêtes HTTP correctes vers l'URL bloquée, mais pas les incorrectes, qui étaient passées auparavant par le filtre des fournisseurs et parvenaient, bien que seulement sous forme de fragments : FIN-ACK et RST — une soustraction sur une soustraction et presque un plus. D'ailleurs, le fournisseur d'hébergement IPv6 n'a pas été filtré. Bien sûr, cela a eu un impact sur la qualité du matériel collecté, mais cela a tout de même permis de voir la périodicité. Cela s'est avéré être un élément important lors du choix d'une plateforme pour héberger des ressources, n'oubliez pas de vous renseigner sur l'organisation du travail avec la liste des sites interdits et les demandes de la RKN.
Au début, j'ai comparé le système AS "Revizor" avec . Cette comparaison est tout à fait justifiée et un grand réseau d'agents peut être bénéfique. Par exemple, évaluer la qualité de l'accessibilité des ressources auprès de divers fournisseurs à travers différentes régions du pays. On peut mesurer les latences, construire des graphiques, analyser tout cela et voir les changements qui se produisent à la fois localement et globalement. Ce n'est pas le chemin le plus direct, mais les astronomes utilisent des "bougies standard", pourquoi ne pas utiliser les agents ? En connaissant (ou en trouvant) leur comportement standard, on peut identifier les changements qui se produisent autour d'eux et comment cela affecte la qualité des services offerts. Parallèlement, il n'est pas nécessaire de placer des sondes dans le réseau, elles ont déjà été mises en place par le Roskomnadzor.
Un autre point que je veux aborder, c'est que chaque outil peut être une arme. Le système AS "Revizor" est un réseau fermé, mais les agents révèlent tout en envoyant des requêtes vers toutes les ressources de la liste interdite. Acquérir une telle ressource ne pose absolument aucun problème. En fin de compte, les fournisseurs, à travers les agents, dévoilent beaucoup plus sur leur réseau que cela ne le vaut peut-être : les types de DPI et DNS, la localisation de l'agent (nœud central et réseau de service ?), les marqueurs de latence et de perte — et ce n’est que la partie émergée de l'iceberg. De la même manière, si quelqu'un peut surveiller les actions des agents pour améliorer l'accessibilité de ses ressources, d'autres peuvent le faire à d'autres fins et il n'y a pas d'obstacle à cela. C'est un outil à double tranchant et très multifacette, tout le monde peut s'en rendre compte.
Source : habr.com
