Ce n'est un secret pour personne que le contrôle du blocage sur la liste des informations interdites en Russie est surveillé par le système automatisé « Inspecteur ». Comment ça marche est bien écrit ici dans ce , photo du même endroit :
Installé directement chez le fournisseur :
Le module « Agent Inspector » est un élément structurel du système automatisé « Inspector » (AS « Inspector »). Ce système est conçu pour contrôler le respect par les opérateurs de télécommunications des exigences de restriction d'accès dans le cadre des dispositions é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 « Revizor » est d'assurer le contrôle du respect par les opérateurs télécoms des exigences é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. " en termes d'identification des faits d'accès à des informations interdites et d'obtention de pièces justificatives (données) sur les violations visant à restreindre l'accès à des informations interdites.
Compte tenu du fait que, sinon tous, de nombreux fournisseurs ont installé cet appareil, il aurait dû y avoir un vaste réseau de sondes de balise comme et même plus, mais avec un accès fermé. Cependant, une balise est une balise qui envoie des signaux dans toutes les directions, mais que se passerait-il si nous les attrapions et voyions ce que nous avons capturé et combien ?
Avant de compter, voyons pourquoi cela pourrait même être possible.
Un peu de théorie
Les agents vérifient la disponibilité d'une ressource, notamment via des requêtes HTTP(S), comme celle-ci :
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"
Outre la charge utile, la requête comprend également une phase d'établissement de connexion : échange SYN и SYN-ACK, et phases de réalisation de connexion : FIN-ACK.
Le registre des informations interdites contient plusieurs types de blocage. Évidemment, si une ressource est bloquée par une adresse IP ou un nom de domaine, nous ne verrons aucune demande. Ce sont les types de blocage les plus destructeurs, qui conduisent à l'inaccessibilité de toutes les ressources sur une adresse IP ou de toutes les informations sur un domaine. Il existe également un blocage de type « par URL ». Dans ce cas, le système de filtrage doit analyser l'en-tête de la requête HTTP pour déterminer exactement ce qu'il faut bloquer. Et avant cela, comme on peut le voir ci-dessus, il devrait y avoir une phase d'établissement de connexion que vous pouvez essayer de suivre, car le filtre la manquera très probablement.
Pour ce faire, vous devez sélectionner un domaine gratuit approprié avec le type de blocage « URL » et HTTP pour faciliter le travail du système de filtrage, de préférence abandonné depuis longtemps, afin de minimiser l'entrée de trafic étranger, sauf celui des agents. Cette tâche s'est avérée pas du tout difficile : il existe pas mal de domaines gratuits dans le registre des informations interdites et pour tous les goûts. Par conséquent, le domaine a été acheté et lié à des adresses IP sur un VPS exécutant tcpdump et le décompte commença.
Audit des "Auditeurs"
Je m'attendais à voir des rafales périodiques de demandes, ce qui, à mon avis, indiquerait une action contrôlée. Il est impossible de dire que je ne l’ai pas vu du tout, mais il n’y avait certainement pas d’image claire :
Ce qui n'est pas surprenant, même sur un domaine dont personne n'a besoin et sur une IP jamais utilisée, il y aura tout simplement une tonne d'informations non sollicitées, tel est l'Internet moderne. Mais heureusement, je n'avais besoin que de requêtes pour une URL spécifique, donc tous les scanners et pirates de mots de passe ont été rapidement trouvés. De plus, il était assez facile de comprendre d'où venait l'inondation à partir de la masse de demandes similaires. Ensuite, j'ai compilé la fréquence d'apparition des adresses IP et parcouru tout le haut manuellement, en séparant ceux qui l'avaient manqué aux étapes précédentes. De plus, j'ai découpé toutes les sources qui étaient envoyées dans un seul colis, il n'y en avait plus beaucoup. Et c'est ce qui est arrivé:
Une petite digression lyrique. Un peu plus d'un jour plus tard, mon hébergeur a envoyé une lettre au contenu plutôt épuré, disant que vos installations contiennent une ressource de la liste interdite RKN, elle est donc bloquée. Au début je pensais que mon compte était bloqué, ce n'était pas le cas. Ensuite, j’ai pensé qu’ils me mettaient simplement en garde contre quelque chose que je savais déjà. Mais il s'est avéré que l'hébergeur a activé son filtre devant mon domaine et par conséquent j'ai été soumis à un double filtrage : de la part des fournisseurs et de l'hébergeur. Le filtre n'a transmis que les fins de requêtes : FIN-ACK и RST couper tout HTTP à une URL interdite. Comme vous pouvez le voir sur le graphique ci-dessus, après le premier jour, j'ai commencé à recevoir moins de données, mais j'en ai quand même reçu, ce qui était tout à fait suffisant pour compter les sources de requêtes.
Arriver au point. À mon avis, deux sursauts sont clairement visibles chaque jour, le premier plus petit, après minuit, heure de Moscou, le second plus proche de 6 heures du matin avec une queue jusqu'à midi. Le pic n’arrive pas exactement au même moment. Au début, je voulais sélectionner des adresses IP qui tombaient uniquement au cours de ces périodes et chacune dans toutes les périodes, en partant du principe que les contrôles par les agents sont effectués périodiquement. Mais après un examen attentif, j'ai rapidement découvert des périodes tombant dans d'autres intervalles, avec d'autres fréquences, jusqu'à une requête toutes les heures. Ensuite, j'ai pensé aux fuseaux horaires et peut-être que cela avait quelque chose à voir avec eux, puis j'ai pensé qu'en général, le système n'était peut-être pas synchronisé globalement. De plus, le NAT jouera probablement un rôle et le même agent pourra faire des requêtes depuis différentes IP publiques.
Comme mon objectif initial n'était pas exactement, j'ai compté toutes les adresses que j'ai rencontrées en une semaine et j'ai obtenu... 2791. Le nombre de sessions TCP établies à partir d'une adresse est en moyenne de 4, avec une médiane de 2. Principales sessions par adresse : 464, 231, 149, 83, 77. Le maximum sur 95 % de l'échantillon est de 8 sessions par adresse. La médiane n'est pas très élevée, je vous rappelle que le graphique montre une périodicité quotidienne claire, on pourrait donc s'attendre à quelque chose autour de 4 à 8 en 7 jours. Si nous excluons toutes les séances qui ont lieu une fois, nous obtiendrons une médiane égale à 5. Mais je ne pourrais pas les exclure sur la base d'un critère clair. Au contraire, un contrôle aléatoire a montré qu'elles étaient liées à des demandes de ressources interdites.
Les adresses sont des adresses, mais sur Internet, des systèmes autonomes - AS, qui se sont avérés plus importants 1510, en moyenne 2 adresses par AS avec une médiane de 1. Principales adresses par AS : 288, 77, 66, 39, 27. Le maximum de 95 % de l'échantillon est de 4 adresses par AS. Ici, la médiane est attendue : un agent par fournisseur. Nous attendons également le sommet - il y a de grands acteurs. Dans un grand réseau, les agents devraient probablement être localisés dans chaque région de présence de l’opérateur, et ne pas oublier le NAT. Si nous le prenons par pays, les maximums seront : 1409 - RU, 42 - UA, 23 - CZ, 36 d'autres régions, pas RIPE NCC. Les demandes provenant de l’extérieur de la Russie attirent l’attention. Cela peut probablement s'expliquer par des erreurs de géolocalisation ou des erreurs du registraire lors du remplissage des données. Ou le fait qu'une entreprise russe peut ne pas avoir de racines russes ou avoir de bureau de représentation à l'étranger parce que c'est plus facile, ce qui est naturel lorsqu'on traite avec une organisation étrangère RIPE NCC. Une partie est sans doute superflue, mais il est difficile de la séparer de manière fiable, car la ressource est sous blocage, et à partir du deuxième jour sous double blocage, et la plupart des sessions ne sont qu'un échange de plusieurs paquets de service. Admettons qu'il s'agit d'une petite partie.
Ces chiffres peuvent déjà être comparés au nombre de prestataires en Russie. licences pour les « Services de communication pour la transmission de données, à l'exclusion de la voix » - 6387, mais il s'agit d'une estimation très élevée d'en haut, toutes ces licences ne s'appliquent pas spécifiquement aux fournisseurs Internet qui doivent installer un Agent. Dans la zone RIPE NCC, il existe un nombre similaire d'AS enregistrés en Russie - 6230 XNUMX, dont tous ne sont pas des fournisseurs. et a reçu 3940 entreprises en 2017, et c'est plutôt une estimation d'en haut. Dans tous les cas, nous avons deux fois et demie moins d’AS lumineux. Mais ici, il convient de comprendre qu'AS n'est pas strictement égal au fournisseur. Certains fournisseurs ne disposent pas de leur propre AS, d’autres en ont plusieurs. Si nous supposons que tout le monde a encore des agents, alors quelqu'un filtre plus fortement que les autres, de sorte que ses demandes ne peuvent pas être distinguées des ordures, si elles leur parviennent. Mais pour une évaluation approximative, c'est tout à fait tolérable, même si quelque chose a été perdu à cause de mon oubli.
À propos du DPI
Bien que mon hébergeur ait activé son filtre dès le deuxième jour, sur la base des informations du premier jour, nous pouvons conclure que le blocage fonctionne avec succès. Seules 4 sources ont pu passer et ont complètement terminé les sessions HTTP et TCP (comme dans l'exemple ci-dessus). 460 autres peuvent être envoyés GET, mais la session est immédiatement terminée par RST. faire attention à 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"
Les variantes peuvent être différentes : moins RST ou plusieurs retransmissions - dépend également de ce que le filtre envoie au nœud source. Dans tous les cas, il s’agit du modèle le plus fiable, à partir duquel il ressort clairement qu’il s’agit d’une ressource interdite qui a été demandée. De plus, il y a toujours une réponse qui apparaît dans la session avec TTL supérieur à celui des packages précédents et suivants.
Tu ne peux même pas le voir du reste 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 alors:
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"
...
La différence est définitivement visible TTL si quelque chose vient du filtre. Mais souvent, rien n’arrive :
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 alors:
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"
...
Et tout cela se répète et se répète, comme le montre le graphique, plus d’une fois, chaque jour.
À propos d'IPv6
La bonne nouvelle, c'est que cela existe. Je peux affirmer de manière fiable que les requêtes périodiques vers une ressource interdite proviennent de 5 adresses IPv6 différentes, ce qui correspond exactement au comportement des agents auquel je m'attendais. De plus, une des adresses IPv6 ne tombe pas sous filtrage et je vois une session complète. Sur deux autres, je n'ai vu qu'une seule séance inachevée, dont l'une a été interrompue par RST du filtre, deuxième dans le temps. Montant total 7.
Comme il y a peu d'adresses, je les ai toutes étudiées en détail et il s'est avéré qu'il n'y a que 3 prestataires là-bas, on peut leur faire une standing ovation ! Une autre adresse est l'hébergement cloud en Russie (ne filtre pas), une autre est un centre de recherche en Allemagne (il y a un filtre, où ?). Mais pourquoi vérifient-ils la disponibilité des ressources interdites selon un calendrier est une bonne question. Les deux autres ont fait une seule demande et sont situés en dehors de la Russie, et l'un d'eux est filtré (en transit, après tout ?).
Les blocages et les agents constituent un frein majeur à IPv6, dont la mise en œuvre n'avance pas très rapidement. C'est triste. Ceux qui ont résolu ce problème peuvent être pleinement fiers d’eux-mêmes.
En conclusion
Je n'ai pas recherché une précision à 100 %, pardonnez-moi, j'espère que quelqu'un voudra répéter ce travail avec plus de précision. Il était important pour moi de comprendre si cette approche fonctionnerait en principe. La réponse est oui. Les chiffres obtenus, en première approximation, je pense, sont assez fiables.
Qu'aurait-on pu faire d'autre et ce que j'étais trop paresseux pour faire, c'était compter les requêtes DNS. Ils ne sont pas filtrés, mais ils n’apportent pas non plus beaucoup de précision puisqu’ils ne fonctionnent que pour le domaine, et non pour l’intégralité de l’URL. La fréquence doit être visible. Si vous le combinez avec ce qui est visible directement dans les requêtes, cela vous permettra de séparer le superflu et d'obtenir plus d'informations. Il est même possible de déterminer les développeurs des DNS utilisés par les fournisseurs et bien plus encore.
Je ne m'attendais absolument pas à ce que l'hébergeur inclue également son propre filtre pour mon VPS. C'est peut-être une pratique courante. Finalement, RKN envoie une demande de suppression de la ressource à l'hébergeur. Mais cela ne m’a pas surpris et, d’une certaine manière, a même joué à mon avantage. Le filtre a fonctionné très efficacement, coupant toutes les requêtes HTTP correctes vers une URL interdite, mais celles qui étaient auparavant passées par le filtre des fournisseurs ne leur sont pas parvenues, mais uniquement sous la forme de terminaisons : FIN-ACK и RST - moins pour moins et cela s'est presque avéré être un plus. D’ailleurs, IPv6 n’a pas été filtré par l’hébergeur. Bien sûr, cela affectait la qualité du matériel collecté, mais cela permettait quand même de voir la fréquence. Il s'est avéré que c'est un point important lors du choix d'un site de placement de ressources, n'oubliez pas de vous intéresser à la question de l'organisation du travail avec la liste des sites interdits et les demandes du RKN.
Au début, j'ai comparé l'AS "Inspector" avec . Cette comparaison est tout à fait justifiée et un large réseau d’Agents peut s’avérer bénéfique. Par exemple, déterminer la qualité de la disponibilité des ressources auprès de différents fournisseurs dans différentes régions du pays. Vous pouvez calculer les retards, créer des graphiques, tout analyser et voir les changements qui se produisent à la fois localement et globalement. Ce n’est pas la manière la plus directe, mais les astronomes utilisent des « bougies standards », pourquoi ne pas utiliser des Agents ? Connaissant (ayant trouvé) leur comportement standard, vous pouvez déterminer les changements qui se produisent autour d'eux et comment cela affecte la qualité des services fournis. Et en même temps, vous n'avez pas besoin de placer indépendamment des sondes sur le réseau : Roskomnadzor les a déjà installées.
Un autre point que je souhaite aborder est que chaque outil peut être une arme. AS "Inspecteur" est un réseau fermé, mais les Agents livrent tout le monde en envoyant des demandes pour toutes les ressources de la liste interdite. Avoir une telle ressource ne pose aucun problème. Au total, les fournisseurs via les agents, involontairement, en disent beaucoup plus sur leur réseau qu'il n'en vaut probablement la peine : types DPI et DNS, emplacement de l'agent (nœud central et réseau de service ?), marqueurs réseau des retards et des pertes - et c'est le cas. seulement les plus évidents. Tout comme quelqu'un peut surveiller les actions des agents pour améliorer la disponibilité de leurs ressources, quelqu'un peut le faire à d'autres fins et il n'y a aucun obstacle à cela. Le résultat est un instrument à double tranchant et aux multiples facettes, tout le monde peut le constater.
Source: habr.com