Es ist kein Geheimnis, dass die Kontrolle der Sperrung der Liste verbotener Informationen in Russland durch das automatisierte System „Inspector“ überwacht wird. Wie es funktioniert, ist hier gut beschrieben , Bild vom selben Ort:
Direkt beim Anbieter installiert :
Das Modul „Agent Inspector“ ist ein Strukturelement des automatisierten Systems „Inspector“ (AS „Inspector“). Dieses System soll die Einhaltung der Zugangsbeschränkungsanforderungen durch Telekommunikationsbetreiber im Rahmen der Bestimmungen der Artikel 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149-FZ „Über Informationen, Informationstechnologien und Informationsschutz“ überwachen. ”
Der Hauptzweck der Schaffung von AS „Revizor“ besteht darin, die Überwachung der Einhaltung der Anforderungen der Artikel 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149-FZ „Über Information, Informationstechnologien und Informationsschutz“ durch Telekommunikationsbetreiber sicherzustellen „im Hinblick auf die Identifizierung von Tatsachen des Zugangs zu verbotenen Informationen und die Beschaffung von unterstützenden Materialien (Daten) über Verstöße, um den Zugang zu verbotenen Informationen einzuschränken.
Unter Berücksichtigung der Tatsache, dass, wenn nicht alle, so doch viele Anbieter dieses Gerät installiert haben, hätte es ein großes Netzwerk von Beacon-Sonden geben müssen und noch mehr, aber mit geschlossenem Zugang. Allerdings ist ein Leuchtfeuer ein Leuchtfeuer, das Signale in alle Richtungen sendet. Was aber, wenn wir sie einfangen und sehen, was wir gefangen haben und wie viele?
Bevor wir zählen, wollen wir sehen, warum dies überhaupt möglich sein könnte.
Ein bisschen Theorie
Agenten prüfen die Verfügbarkeit einer Ressource, auch über HTTP(S)-Anfragen wie diese:
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"
Neben der Nutzlast besteht die Anfrage auch aus einer Verbindungsaufbauphase: Austausch SYN и SYN-ACKund Verbindungsabschlussphasen: FIN-ACK.
Das Register der verbotenen Informationen enthält verschiedene Arten der Sperrung. Wenn eine Ressource aufgrund der IP-Adresse oder des Domänennamens blockiert ist, sehen wir natürlich keine Anfragen. Hierbei handelt es sich um die destruktivsten Blockierungsarten, die dazu führen, dass nicht mehr auf alle Ressourcen einer IP-Adresse oder alle Informationen einer Domain zugegriffen werden kann. Es gibt auch eine Blockierungsart „per URL“. In diesem Fall muss das Filtersystem den HTTP-Anforderungsheader analysieren, um genau zu bestimmen, was blockiert werden soll. Und davor sollte es, wie oben zu sehen ist, eine Phase des Verbindungsaufbaus geben, die Sie nachverfolgen können, da der Filter sie höchstwahrscheinlich übersehen wird.
Dazu müssen Sie eine geeignete kostenlose Domäne mit dem Typ „URL“ und HTTP-Blockierung auswählen, um die Arbeit des Filtersystems zu erleichtern, vorzugsweise eine längst aufgegebene, um den Eintritt von fremdem Datenverkehr außer von Agenten zu minimieren. Diese Aufgabe erwies sich als gar nicht so schwierig, denn im Register der verbotenen Informationen gibt es eine ganze Reihe kostenloser Domains und zwar für jeden Geschmack. Daher wurde die Domain erworben und mit IP-Adressen auf einem laufenden VPS verknüpft tcpdump und das Zählen begann.
Prüfung von „Wirtschaftsprüfern“
Ich erwartete, dass es in regelmäßigen Abständen zu Anfragen kommt, was meiner Meinung nach auf kontrolliertes Handeln hindeutet. Man kann nicht sagen, dass ich es überhaupt nicht gesehen habe, aber es gab definitiv kein klares Bild:
Das ist nicht verwunderlich, denn selbst auf einer Domain, die niemand braucht, und auf einer nie genutzten IP wird es einfach eine Menge unerwünschter Informationen geben, so wie es im modernen Internet der Fall ist. Aber zum Glück brauchte ich nur Anfragen für eine bestimmte URL, sodass alle Scanner und Passwort-Cracker schnell gefunden wurden. Auch war es aufgrund der Masse ähnlicher Anfragen recht einfach zu verstehen, woher die Flut kam. Als nächstes habe ich die Häufigkeit des Auftretens von IP-Adressen zusammengestellt und die gesamte Spitze manuell durchgegangen, wobei ich diejenigen ausgesondert habe, die sie in den vorherigen Phasen übersehen haben. Außerdem habe ich alle Quellen herausgeschnitten, die in einem Paket verschickt wurden, da es nicht mehr viele davon gab. Und das ist passiert:
Ein kleiner lyrischer Exkurs. Etwas mehr als einen Tag später schickte mein Hosting-Anbieter einen Brief mit einem eher vereinfachten Inhalt, in dem es hieß, dass Ihre Einrichtungen eine Ressource von der RKN-Verbotsliste enthalten und daher gesperrt sind. Zuerst dachte ich, dass mein Konto gesperrt sei, aber das war nicht der Fall. Dann dachte ich, dass sie mich lediglich vor etwas warnten, von dem ich bereits wusste. Es stellte sich jedoch heraus, dass der Hoster seinen Filter vor meiner Domain eingeschaltet hatte und ich dadurch doppelt gefiltert wurde: von den Providern und vom Hoster. Der Filter hat nur die Enden der Anfragen durchgelassen: FIN-ACK и RST Abschneiden aller HTTP-Verbindungen bei einer verbotenen URL. Wie Sie der obigen Grafik entnehmen können, begann ich nach dem ersten Tag, weniger Daten zu erhalten, aber ich erhielt sie immer noch, was für die Aufgabe, die Anfragequellen zu zählen, völlig ausreichte.
Komm zum Punkt. Meiner Meinung nach sind jeden Tag zwei Ausbrüche deutlich sichtbar, der erste kleiner, nach Mitternacht Moskauer Zeit, der zweite näher an 6 Uhr morgens mit einem Schweif bis 12 Uhr mittags. Der Höhepunkt tritt nicht genau zur gleichen Zeit auf. Zunächst wollte ich IP-Adressen auswählen, die nur in diesen Zeiträumen und in allen Zeiträumen fielen, basierend auf der Annahme, dass Überprüfungen durch Agenten regelmäßig durchgeführt werden. Aber bei sorgfältiger Betrachtung entdeckte ich schnell, dass Zeiträume in andere Intervalle und mit anderen Frequenzen fielen, bis zu einer Anfrage pro Stunde. Dann habe ich über Zeitzonen nachgedacht und dass es vielleicht etwas damit zu tun hat, dann dachte ich, dass das System im Allgemeinen möglicherweise nicht global synchronisiert ist. Darüber hinaus wird wahrscheinlich NAT eine Rolle spielen und derselbe Agent kann Anfragen von verschiedenen öffentlichen IPs stellen.
Da mein ursprüngliches Ziel nicht ganz genau war, zählte ich alle Adressen, die ich in einer Woche fand, und erhielt – 2791. Die Anzahl der von einer Adresse aus aufgebauten TCP-Sitzungen beträgt durchschnittlich 4, mit einem Median von 2. Top-Sitzungen pro Adresse: 464, 231, 149, 83, 77. Das Maximum von 95 % der Stichprobe beträgt 8 Sitzungen pro Adresse. Der Median ist nicht sehr hoch. Ich möchte Sie daran erinnern, dass die Grafik eine deutliche tägliche Periodizität zeigt, sodass man in 4 Tagen mit etwa 8 bis 7 rechnen kann. Wenn wir alle Sitzungen, die einmal stattfinden, ausschließen, erhalten wir einen Medianwert von 5. Ich konnte sie jedoch nicht anhand eines klaren Kriteriums ausschließen. Vielmehr ergab eine stichprobenartige Überprüfung, dass es sich dabei um Anfragen nach einer verbotenen Ressource handelte.
Adressen sind Adressen, aber im Internet erwiesen sich autonome Systeme – AS – als wichtiger 1510, durchschnittlich 2 Adressen pro AS mit einem Median von 1. Top-Adressen pro AS: 288, 77, 66, 39, 27. Das Maximum von 95 % der Stichprobe beträgt 4 Adressen pro AS. Hier wird der Median erwartet – ein Agent pro Anbieter. Wir erwarten auch die Spitze – da sind große Spieler drin. In einem großen Netzwerk sollten sich Agenten wahrscheinlich in jeder Region befinden, in der der Betreiber präsent ist, und NAT nicht vergessen. Wenn wir es nach Ländern betrachten, sind die Höchstwerte: 1409 – RU, 42 – UA, 23 – CZ, 36 aus anderen Regionen, nicht RIPE NCC. Aufsehen erregen Anfragen von außerhalb Russlands. Dies kann wahrscheinlich durch Geolokalisierungsfehler oder Registrarfehler beim Ausfüllen der Daten erklärt werden. Oder die Tatsache, dass ein russisches Unternehmen möglicherweise keine russischen Wurzeln hat oder eine ausländische Repräsentanz hat, weil es einfacher ist, was bei der Zusammenarbeit mit einer ausländischen Organisation RIPE NCC selbstverständlich ist. Ein Teil ist zweifellos überflüssig, aber es ist zuverlässig schwierig, ihn zu trennen, da die Ressource blockiert ist und ab dem zweiten Tag doppelt blockiert ist und die meisten Sitzungen nur ein Austausch mehrerer Servicepakete sind. Wir sind uns einig, dass dies ein kleiner Teil ist.
Diese Zahlen lassen sich bereits mit der Anzahl der Anbieter in Russland vergleichen. Lizenzen für „Kommunikationsdienste zur Datenübertragung, ausgenommen Sprache“ – 6387, aber das ist eine sehr hohe Schätzung von oben, nicht alle dieser Lizenzen gelten speziell für Internetanbieter, die einen Agenten installieren müssen. In der RIPE NCC-Zone gibt es eine ähnliche Anzahl in Russland registrierter ASes – 6230, von denen nicht alle Anbieter sind. und empfing im Jahr 3940 2017 Unternehmen, wobei es sich hierbei eher um eine Schätzung von oben handelt. Auf jeden Fall haben wir zweieinhalbmal weniger beleuchtete ASs. Aber hier ist es wichtig zu verstehen, dass AS nicht unbedingt gleichbedeutend mit dem Anbieter ist. Einige Anbieter verfügen über kein eigenes AS, andere über mehrere. Wenn wir davon ausgehen, dass jeder noch Agenten hat, dann filtert jemand stärker als andere, sodass seine Anfragen nicht vom Müll zu unterscheiden sind, wenn sie ihn überhaupt erreichen. Aber für eine grobe Einschätzung ist es durchaus erträglich, auch wenn durch mein Versehen etwas verloren gegangen ist.
Über DPI
Obwohl mein Hosting-Provider seinen Filter ab dem zweiten Tag aktiviert hat, können wir anhand der Informationen vom ersten Tag schließen, dass die Blockierung erfolgreich funktioniert. Nur 4 Quellen konnten durchkommen und haben HTTP- und TCP-Sitzungen vollständig abgeschlossen (wie im Beispiel oben). Weitere 460 können verschickt werden GET, aber die Sitzung wird sofort beendet RST. Beachten 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"
Variationen davon können unterschiedlich sein: weniger RST oder mehr Neuübertragungen – hängt auch davon ab, was der Filter an den Quellknoten sendet. Auf jeden Fall ist dies die zuverlässigste Vorlage, aus der klar hervorgeht, dass es sich um eine verbotene Ressource handelte, die angefordert wurde. Außerdem gibt es immer eine Antwort, die in der Sitzung mit angezeigt wird TTL größer als in vorherigen und nachfolgenden Paketen.
Man kann es vom Rest nicht einmal sehen 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"
Oder so:
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"
...
Der Unterschied ist definitiv sichtbar TTL wenn etwas aus dem Filter kommt. Aber oft kommt überhaupt nichts an:
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"
...
Oder so:
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"
...
Und das alles wiederholt sich und wiederholt und wiederholt sich, wie in der Grafik zu sehen ist, mehr als einmal, jeden Tag.
Über IPv6
Die gute Nachricht ist, dass es sie gibt. Ich kann zuverlässig sagen, dass periodische Anfragen an eine verbotene Ressource von 5 verschiedenen IPv6-Adressen erfolgen, was genau dem Verhalten der Agenten entspricht, das ich erwartet habe. Außerdem fällt eine der IPv6-Adressen nicht unter die Filterung und ich sehe eine vollständige Sitzung. Von zwei weiteren sah ich nur eine unvollendete Sitzung, von denen eine unterbrochen wurde RST aus dem Filter, Sekunde im Takt. Gesamtmenge 7.
Da es nur wenige Adressen gibt, habe ich alle im Detail studiert und es stellte sich heraus, dass es dort nur 3 Anbieter gibt, die können mit Standing Ovations bedacht werden! Eine andere Adresse ist Cloud-Hosting in Russland (filtert nicht), eine andere ist ein Forschungszentrum in Deutschland (es gibt einen Filter, wo?). Aber warum überprüfen sie die Verfügbarkeit verbotener Ressourcen nach einem Zeitplan? Das ist eine gute Frage. Die restlichen beiden haben eine Anfrage gestellt und befinden sich außerhalb Russlands, und einer von ihnen wird gefiltert (immerhin auf der Durchreise?).
Blockierungen und Agenten sind ein großes Hindernis für IPv6, dessen Implementierung nicht sehr schnell voranschreitet. Es ist traurig. Wer dieses Problem gelöst hat, kann voll und ganz stolz auf sich sein.
Abschließend
Ich habe keine hundertprozentige Genauigkeit angestrebt, bitte verzeihen Sie mir das, ich hoffe, jemand möchte diese Arbeit mit größerer Genauigkeit wiederholen. Für mich war es wichtig zu verstehen, ob dieser Ansatz grundsätzlich funktionieren würde. Die Antwort ist ja. Die erhaltenen Zahlen sind meiner Meinung nach in erster Näherung recht zuverlässig.
Was man sonst hätte tun können und wozu ich zu faul war, war, DNS-Anfragen zu zählen. Sie werden nicht gefiltert, bieten aber auch keine große Genauigkeit, da sie nur für die Domain und nicht für die gesamte URL funktionieren. Die Frequenz sollte sichtbar sein. Wenn Sie es mit dem kombinieren, was direkt in den Abfragen sichtbar ist, können Sie Unnötiges heraustrennen und mehr Informationen erhalten. Es ist sogar möglich, die Entwickler des von Providern verwendeten DNS zu ermitteln und vieles mehr.
Ich hätte absolut nicht erwartet, dass der Hoster auch einen eigenen Filter für meinen VPS bereitstellt. Vielleicht ist das gängige Praxis. Am Ende sendet RKN eine Anfrage zum Löschen der Ressource an den Hoster. Aber das überraschte mich nicht und war in gewisser Weise sogar zu meinem Vorteil. Der Filter funktionierte sehr effektiv und schnitt alle korrekten HTTP-Anfragen an eine verbotene URL ab, aber korrekte Anfragen, die zuvor den Filter des Anbieters passiert hatten, erreichten sie jedoch nicht, wenn auch nur in Form von Endungen: FIN-ACK и RST - Minus für Minus und es wäre fast ein Plus geworden. IPv6 wurde übrigens vom Hoster nicht gefiltert. Dies wirkte sich natürlich auf die Qualität des gesammelten Materials aus, machte es aber dennoch möglich, die Häufigkeit zu erkennen. Es stellte sich heraus, dass dies ein wichtiger Punkt bei der Auswahl eines Standorts für die Platzierung von Ressourcen ist; vergessen Sie nicht, sich für die Organisation der Arbeit mit der Liste der verbotenen Standorte und Anfragen des RKN zu interessieren.
Zu Beginn habe ich den AS „Inspector“ mit verglichen . Dieser Vergleich ist durchaus berechtigt und ein großes Agentennetzwerk kann von Vorteil sein. Bestimmen Sie beispielsweise die Qualität der Ressourcenverfügbarkeit verschiedener Anbieter in verschiedenen Teilen des Landes. Sie können Verzögerungen berechnen, Diagramme erstellen, alles analysieren und die Änderungen sehen, die sowohl lokal als auch global auftreten. Dies ist nicht der direkteste Weg, aber Astronomen verwenden „Standardkerzen“, warum nicht auch Agenten? Wenn Sie ihr Standardverhalten kennen (nachdem Sie es gefunden haben), können Sie die Veränderungen, die um sie herum auftreten, bestimmen und feststellen, wie sich dies auf die Qualität der bereitgestellten Dienste auswirkt. Gleichzeitig müssen Sie keine Sonden unabhängig im Netzwerk platzieren; Roskomnadzor hat sie bereits installiert.
Ein weiterer Punkt, den ich ansprechen möchte, ist, dass jedes Werkzeug eine Waffe sein kann. AS „Inspector“ ist ein geschlossenes Netzwerk, aber die Agenten übergeben alle, indem sie Anfragen für alle Ressourcen aus der Verbotsliste senden. Der Besitz einer solchen Ressource ist überhaupt kein Problem. Insgesamt erzählen Anbieter über Agenten unabsichtlich viel mehr über ihr Netzwerk, als es wahrscheinlich wert ist: DPI- und DNS-Typen, Standort des Agenten (zentraler Knoten und Servicenetzwerk?), Netzwerkmarkierungen für Verzögerungen und Verluste – und das ist es nur das Offensichtlichste. So wie jemand die Aktionen von Agenten überwachen kann, um die Verfügbarkeit seiner Ressourcen zu verbessern, kann dies auch jemand für andere Zwecke tun, und es gibt keine Hindernisse dafür. Das Ergebnis ist ein zweischneidiges und sehr facettenreiches Instrument, das kann sich jeder ansehen.
Source: habr.com