Ce n'est un secret pour personne que le système automatisé «Inspecteur» surveille le contrôle des serrures sur la liste des informations interdites en Russie. Comment cela fonctionne est bien écrit ici dans cet
article sur Habr , l'image est de là:
Le
module «Agent Auditor» du fournisseur est installé directement chez le fournisseur:
Le module «Agent Auditor» est un élément structurel du système automatisé «Auditor» (AS «Auditor»). Ce système est destiné à contrôler le respect par les opérateurs télécoms des restrictions 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- «Information, technologies de l'information et protection de l'information».
L'objectif principal de la création de l'Auditeur AS est de contrôler le respect par les opérateurs télécoms des exigences fixées par les articles 15.1 à 15.4 de la loi fédérale du 27 juillet 2006 n ° 149- «sur l'information, les technologies de l'information et la protection de l'information» concernant l'identification des faits d'accès aux informations interdites et l'obtention de documents justificatifs (données) sur les violations afin de restreindre l'accès aux informations interdites.
Étant donné que, sinon tous, de nombreux fournisseurs ont installé cet appareil à la maison, ils devraient avoir un grand réseau de sondes de balise comme
RIPE Atlas et plus encore, mais avec un accès fermé. Cependant, le phare est le phare pour envoyer des signaux dans toutes les directions, mais que se passe-t-il si nous les attrapons et voyons ce que nous avons capturé et combien?
Avant de compter, voyons pourquoi cela peut même être possible.
Un peu de théorie
Les agents vérifient la disponibilité d'une ressource, y compris via des requêtes HTTP (S), comme cet 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 demande, en plus de la charge utile, comprend également la phase d'établissement de connexion: échange de
SYN et
SYN-ACK , et la phase d'achèvement de connexion:
FIN-ACK .
Le registre d'informations interdites contient plusieurs types de verrous. Évidemment, si la ressource est bloquée par l'adresse IP ou le nom de domaine, nous ne verrons aucune demande. Ce sont les types de verrous les plus destructeurs qui conduisent à l'inaccessibilité de toutes les ressources sur une seule adresse IP ou de toutes les informations sur un domaine. Il existe également un type de blocage d'URL. Dans ce cas, le système de filtrage doit analyser l'en-tête de requête HTTP pour déterminer exactement ce qu'il faut bloquer. Et avant cela, comme on peut le voir ci-dessus, la phase de configuration de la connexion doit avoir lieu, que vous pouvez essayer de suivre, car le filtre l'ignorera très probablement.
Pour ce faire, vous devez sélectionner un domaine gratuit approprié avec le type de blocage "par URL" et HTTP, afin de 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 à partir d'agents. Cette tâche n'était pas du tout difficile, il existe de nombreux domaines gratuits dans le registre des informations interdites pour tous les goûts. Par conséquent, le domaine a été acquis, lié aux adresses IP sur le VPS avec
tcpdump cours d'exécution, et le comptage a commencé.
Audit des «Auditeurs»
Je m'attendais à voir des rafales périodiques de demandes, ce qui, à mon avis, indiquerait une action contrôlée. Cela ne veut pas dire que je ne l'ai pas vu du tout, mais il n'y avait certainement pas d'image claire:
Sans surprise, même un domaine inutile pour une adresse IP inutilisée recevra simplement une masse d'informations non sollicitées, tel est l'Internet moderne. Mais heureusement, je n'avais besoin que de demandes pour une URL spécifique, donc tous les robots et les brutes de mot de passe ont été rapidement trouvés. De plus, c'était assez simple pour comprendre où se trouvait l'inondation par la masse du même type de demandes. Ensuite, j'ai compilé la fréquence d'apparition des adresses IP et parcouru le sommet en séparant manuellement ceux qui ont glissé dans les étapes précédentes. De plus, j'ai supprimé toutes les sources qui ont envoyé un paquet, il n'y en avait pas beaucoup. Et il s'est avéré ceci:
Une légère digression lyrique. Un peu plus d'un jour plus tard, mon hébergeur a envoyé un message plutôt simplifié, ils disent que dans vos installations il y a une ressource de la liste interdite d'ILV donc elle est bloquée. Au début, je pensais qu'ils avaient bloqué mon compte, ce n'était pas le cas. Puis j'ai pensé qu'ils me mettaient simplement en garde contre ce 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: des fournisseurs et de l'hôte. Le filtre n'a ignoré que la fin des requêtes:
FIN-ACK et
RST coupant tout HTTP à l'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 je les ai quand même reçues, ce qui était assez suffisant pour la tâche de calcul des sources de requête.
Allez droit au but. À mon avis, deux rafales sont clairement visibles tous les jours, la première moins après minuit à Moscou, la seconde plus proche de 6 heures du matin avec une queue jusqu'à 12 jours. Le pic ne se produit pas exactement en même temps. Tout d'abord, je voulais mettre en évidence les adresses IP qui ne tombaient que dans ces périodes et chacune dans toutes les périodes, en supposant que les agents vérifient périodiquement. Mais en regardant attentivement, j'ai rapidement découvert des périodes tombant dans d'autres intervalles, avec des fréquences différentes, jusqu'à une demande toutes les heures. Ensuite, j'ai pensé aux fuseaux horaires et à ce qui est possible dans ceux-ci, puis j'ai pensé qu'en général le système peut ne pas être synchronisé globalement. De plus, à coup sûr, le NAT jouera son rôle, et le même agent peut faire des demandes à partir de différentes adresses IP publiques.
Étant donné que mon objectif initial n'était pas exactement, j'ai compté toutes les adresses que j'ai obtenues 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. Top sessions par adresse: 464, 231, 149, 83, 77. Le maximum de 95% de l'échantillon est de 8 sessions par adresse. La médiane n'est pas très élevée, je me souviens que le calendrier montre une fréquence quotidienne claire, vous pouvez donc vous attendre à quelque chose autour de 4 à 8 en 7 jours. Si vous jetez toutes les séances de réunion une fois, alors nous obtenons simplement la médiane égale à 5. Mais je ne pouvais pas les exclure sur une base claire. Au contraire, des contrôles ponctuels ont montré qu'ils étaient liés à des demandes d'une ressource interdite.
Les adresses, et sur Internet, les systèmes autonomes sont plus importants - AS, dont
1510 sont sortis, en moyenne 2 adresses sur AS avec médiane 1. Adresses supérieures sur AS: 288, 77, 66, 39, 27. Le maximum de 95% de l'échantillon est de 4 adresses sur AS. Ici, la médiane est attendue - un agent par fournisseur. Nous attendons également le sommet - il y a de grands joueurs. Dans un grand réseau, les agents devraient probablement être dans chaque région de la présence de l'opérateur, et ne pas oublier NAT. Si vous prenez par pays, les maximums seront: 1409 - RU, 42 - UA, 23 - CZ, 36 d'autres régions, pas RIPE NCC. Les demandes ne provenant pas de Russie attirent l'attention. Cela peut peut-être s'expliquer par des erreurs de géolocalisation ou des erreurs de bureau d'enregistrement lors du remplissage des données. Ou le fait qu'une entreprise russe peut avoir des racines non russes, ou avoir un bureau de représentation à l'étranger parce que c'est tellement plus simple qu'il est naturel de traiter avec une organisation étrangère RIPE NCC. Une partie est sans aucun doute superflue, mais il est difficile de la séparer de manière fiable, car la ressource est sous verrouillage, et à partir du deuxième jour sous double verrouillage, et la plupart des sessions ne sont qu'un échange de plusieurs packages de services. Soyons d'accord sur le fait qu'il s'agit d'une petite partie.
Ces chiffres peuvent déjà être comparés au nombre de fournisseurs en Russie.
Selon l'ILV, les licences pour les «services de communication pour la transmission de données, à l'exception de la voix» sont de 6387, mais il s'agit d'une note fortement intimidée par le dessus, toutes ces licences ne sont pas spécifiquement destinées aux fournisseurs Internet qui doivent installer l'agent. Dans la zone RIPE NCC, un nombre similaire d'AS enregistrés en Russie est 6230, dont tous les fournisseurs.
UserSide a effectué un calcul plus rigoureux et a reçu 3940 entreprises en 2017, et il s'agit probablement d'une estimation ci-dessus. Dans tous les cas, nous avons le nombre d'AS éclairé deux fois et demi moins. Mais ici, il vaut la peine de comprendre que AS n'est pas strictement égal au fournisseur. Certains fournisseurs n'ont pas leur propre AS, certains en ont plus d'un. Si nous supposons que les agents se tiennent toujours contre tout le monde, alors quelqu'un filtre plus que les autres, de sorte que leurs demandes ne se distinguent pas des ordures, le cas échéant. Mais pour une évaluation approximative, c'est tout à fait tolérable, même si quelque chose a été perdu à cause de ma surveillance.
À propos de DPI
Malgré le fait que mon hébergeur ait activé son filtre depuis le deuxième jour, selon les informations du premier jour, nous pouvons conclure que les verrous fonctionnent correctement. Seules 4 sources ont pu percer et ont complètement terminé les sessions HTTP et TCP (comme dans l'exemple ci-dessus). Un autre 460 peut envoyer un
GET , mais la session se termine instantanément sur
RST . Faites 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"
Les variations peuvent être différentes: moins de
RST ou plus de retransmission - cela dépend aussi 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 est clair que la ressource interdite a été demandée. De plus, il y a toujours une réponse qui apparaît dans une session avec un
TTL supérieur à celui des packages précédents et suivants.
Même le
GET pas visible du reste:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0" TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=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"
La différence de
TTL est sûrement visible si quelque chose arrive du filtre. Mais souvent, il peut ne pas voler 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 alors:
TCP, 14678 > 80, "[SYN] Seq=0" TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1" TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
Et tout cela se répète et se répète et se répète, comme on peut le voir sur le graphique, exactement pas une fois, tous les jours.
À propos d'IPv6
La bonne nouvelle, c'est qu'il l'est. Je peux dire de manière fiable qu'à partir de 5 adresses IPv6 différentes, il y a des demandes périodiques à la ressource interdite, exactement le comportement des agents que j'attendais. De plus, l'une des adresses IPv6 ne relève pas du filtrage et je vois une session complète. Avec deux autres, je n'ai vu qu'une seule session incomplète, dont une a été interrompue par
RST du filtre, la deuxième dans le temps. Un total de
7 .
Puisqu'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 fournisseurs là-dedans, vous pouvez les applaudir debout! 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 à temps la disponibilité des ressources interdites est une bonne question. Les deux autres ont fait une demande et ne se trouvent pas aux frontières de la Russie, l'un d'eux étant filtré (est-il toujours en transit?).
Locks and Agents est un gros frein sur IPv6, dont la mise en œuvre n'avance donc pas très vite. C'est triste. Ceux qui ont résolu cette tâche sont entièrement fiers d'eux-mêmes.
En conclusion
Je n'ai pas poursuivi la précision à 100%, je vous demande de me pardonner pour cela, j'espère que quelqu'un veut répéter ce travail avec plus de précision. Il était important pour moi de comprendre si une telle approche fonctionnerait en principe. La réponse sera. Les chiffres qui en résultent dans une première approximation, je pense, sont assez fiables.
Quoi d'autre pourrait être fait et ce que j'étais trop paresseux pour faire était de calculer les requêtes DNS. Ils ne sont pas filtrés, mais ne donnent pas non plus beaucoup de précision car ils ne fonctionnent que pour le domaine et non pour l'URL entière. La fréquence doit être visible. Si vous combinez avec ce qui est directement visible dans les demandes, cela vous permettra de séparer l'excédent et d'obtenir plus d'informations. Il est même possible d'identifier les développeurs 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. Au final, l'ILV envoie une demande de suppression de la ressource à l'hébergeur. Mais cela ne m'a pas surpris et a même joué avec un certain avantage. Le filtre a fonctionné très efficacement en supprimant toutes les requêtes HTTP correctes vers l'URL interdite, mais pas celles correctes qui ont traversé le filtre des fournisseurs auparavant, même si ce n'est que sous la forme de terminaisons:
FIN-ACK et
RST - moins moins et a presque obtenu un plus. Soit dit en passant, l'hébergeur IPv6 n'a pas été filtré. Bien sûr, cela a affecté la qualité du matériel collecté, mais a quand même permis de voir la fréquence. Cela s'est avéré être 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 aux demandes de renseignements de l'ILV.
Au début, j'ai comparé le "Auditor" AC avec
RIPE Atlas . Cette comparaison est justifiée et un large réseau d'agents peut être bénéfique. Par exemple, déterminer la qualité de la disponibilité des ressources de divers fournisseurs dans différentes parties du pays. Vous pouvez calculer les retards, vous pouvez créer des graphiques, vous pouvez tout analyser et voir les changements qui se produisent à la fois localement et globalement. Ce n'est pas le moyen le plus direct, mais les astronomes utilisent des "bougies standard", pourquoi ne pas utiliser des Agents? Connaissant (trouvant) 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 d'installer indépendamment des sondes sur le réseau, elles ont déjà été fournies par Roskomnadzor.
Un autre point que je veux aborder est que chaque outil peut être une arme. AS «Inspector» est un réseau fermé, mais les agents remettent tout le monde avec des abats en envoyant des demandes pour toutes les ressources de la liste interdite. Mettre la main sur une telle ressource ne pose absolument aucun problème. Au total, les fournisseurs par le biais d'agents, disent involontairement beaucoup plus que ce qui en vaut la peine: types de DPI et DNS, emplacement de l'agent (nœud central et réseau de service?), Marqueurs réseau des retards et des pertes - et ce n'est que le plus évident. 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. Un instrument à double tranchant et très multiforme s'est avéré, tout le monde peut en être convaincu.