Es ist kein Geheimnis, dass das automatisierte System „Inspector“ die Kontrolle von Sperren auf der Liste der verbotenen Informationen in Russland überwacht. Wie es funktioniert, ist hier in diesem
Artikel über Habr gut geschrieben, das Bild ist von dort:
Das Provider-
Modul „Agent Auditor“ wird direkt beim Provider installiert:
Das Modul „Agent Auditor“ ist ein Strukturelement des automatisierten Systems „Auditor“ (AS „Auditor“). Dieses System soll die Umsetzung von Zugangsbeschränkungen durch Telekommunikationsbetreiber im Rahmen der Bestimmungen der Artikel 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149- „Über Information, Informationstechnologien und Informationsschutz“ überwachen.
Das Hauptziel der Schaffung des Auditor AS besteht darin, die Einhaltung der Anforderungen durch Artikel 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149- „Über Information, Informationstechnologien und Informationsschutz“ in Bezug auf die Identifizierung von Tatsachen über den Zugang zu verbotenen Informationen durch Telekommunikationsbetreiber zu überwachen und Erhalt von unterstützendem Material (Daten) zu Verstößen, um den Zugang zu verbotenen Informationen einzuschränken.
Angesichts der Tatsache, dass viele Anbieter, wenn nicht alle, dieses Gerät zu Hause installiert haben, sollten sie über ein großes Netzwerk von Beacon-Sonden wie
RIPE Atlas und mehr verfügen, jedoch mit geschlossenem Zugriff. Der Leuchtturm ist jedoch der Leuchtturm, der Signale in alle Richtungen sendet. Aber was ist, wenn wir sie fangen und sehen, was wir gefangen haben und wie viele?
Lassen Sie uns vor dem Zählen sehen, warum dies überhaupt möglich ist.
Ein bisschen Theorie
Agenten überprüfen die Verfügbarkeit einer Ressource, auch über HTTP (S) -Anforderungen, wie in diesem Beispiel:
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"
Die Anforderung besteht neben der Nutzlast auch aus der Phase des Verbindungsaufbaus: Austausch von
SYN und
SYN-ACK und Phase des Verbindungsabschlusses:
FIN-ACK .
Die Registrierung für verbotene Informationen enthält verschiedene Arten von Sperren. Wenn die Ressource durch die IP-Adresse oder den Domänennamen blockiert ist, werden offensichtlich keine Anforderungen angezeigt. Dies sind die zerstörerischsten Arten von Sperren, die dazu führen, dass nicht alle Ressourcen auf derselben IP-Adresse oder alle Informationen in der Domäne zugänglich sind. Es gibt auch einen URL-Blockierungstyp. In diesem Fall sollte das Filtersystem den HTTP-Anforderungsheader analysieren, um genau zu bestimmen, was blockiert werden soll. Und davor sollte, wie oben zu sehen, die Verbindungsaufbauphase stattfinden, die Sie nachverfolgen können, da der Filter sie höchstwahrscheinlich überspringt.
Dazu müssen Sie eine geeignete freie Domain mit der Art der Blockierung "nach URL" und HTTP auswählen, um die Arbeit des Filtersystems zu erleichtern, das vorzugsweise für längere Zeit aufgegeben wird, um das Eindringen von fremdem Datenverkehr mit Ausnahme von Agenten zu minimieren. Diese Aufgabe war überhaupt nicht schwierig, es gibt viele freie Domains in der Registrierung verbotener Informationen für jeden Geschmack. Daher wurde die Domäne erworben, bei laufendem
tcpdump an die IP-Adressen auf dem VPS gebunden, und die Zählung begann.
Prüfung der „Wirtschaftsprüfer“
Ich erwartete periodische Anfragen, die meiner Meinung nach auf eine kontrollierte Aktion hindeuten würden. Das soll nicht heißen, dass ich das überhaupt nicht gesehen habe, aber es gab definitiv kein klares Bild:
Es überrascht nicht, dass selbst eine unnötige Domain für eine nicht verwendete IP einfach eine Menge unerwünschter Informationen erhält, wie das moderne Internet. Glücklicherweise brauchte ich nur Anfragen nach einer bestimmten URL, sodass alle Crawler und Passwort-Brutes schnell gefunden wurden. Es war auch einfach genug zu verstehen, wo sich die Flut durch die Masse der gleichen Art von Anfragen befand. Dann habe ich die Häufigkeit des Auftretens von IP-Adressen zusammengestellt und bin manuell umhergegangen, um diejenigen zu trennen, die in den vorherigen Schritten ausgerutscht sind. Außerdem habe ich alle Quellen ausgeschnitten, die ein Paket gesendet haben, es gab nicht viele. Und es stellte sich heraus:
Ein leichter lyrischer Exkurs. Etwas mehr als einen Tag später schickte mein Hosting-Anbieter eine ziemlich optimierte Nachricht, dass in Ihren Einrichtungen eine Ressource aus der verbotenen Liste von ILV vorhanden ist, sodass diese blockiert ist. Zuerst dachte ich, dass sie mein Konto gesperrt haben, es war nicht so. Dann dachte ich, dass sie mich nur vor dem warnen, was ich bereits wusste. Es stellte sich jedoch heraus, dass der Hoster seinen Filter vor meiner Domain aktiviert hatte und ich daher doppelt gefiltert wurde: von den Anbietern und dem Host. Der Filter hat nur die Enden von Anforderungen übersprungen:
FIN-ACK und
RST das gesamte HTTP unter der verbotenen URL abgeschnitten. Wie Sie der obigen Grafik entnehmen können, erhielt ich nach dem ersten Tag weniger Daten, aber ich erhielt sie immer noch, was für die Berechnung der Abfragequellen völlig ausreichte.
Komm auf den Punkt. Meiner Meinung nach sind jeden Tag zwei Ausbrüche deutlich sichtbar, der erste weniger nach Mitternacht in Moskau, der zweite näher an 6 Uhr morgens mit einem Schwanz von bis zu 12 Tagen. Der Peak tritt nicht genau zur gleichen Zeit auf. Zunächst wollte ich IP-Adressen hervorheben, die nur in diesen Zeiträumen und jeweils in allen Zeiträumen fielen, basierend auf der Annahme, dass die Agenten regelmäßig prüfen. Bei sorgfältiger Betrachtung entdeckte ich jedoch schnell Perioden, die in andere Intervalle mit unterschiedlichen Frequenzen fielen, bis zu einer Anfrage pro Stunde. Dann dachte ich über Zeitzonen nach und was in ihnen möglich ist, dann dachte ich, dass das System im Allgemeinen möglicherweise nicht global synchronisiert ist. Darüber hinaus wird NAT natürlich seine Rolle spielen, und derselbe Agent kann Anforderungen von verschiedenen öffentlichen IP-Adressen stellen.
Da mein ursprüngliches Ziel nicht genau war, zählte ich alle Adressen, die ich in einer Woche bekam, und bekam
2791 . Die Anzahl der von einer Adresse aus eingerichteten 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 erinnere mich, dass der Zeitplan eine klare tägliche Häufigkeit aufweist, sodass Sie in 7 Tagen mit 4 bis 8 rechnen können. Wenn Sie alle Besprechungssitzungen einmal wegwerfen, erhalten wir nur den Median von 5. Aber ich konnte sie nicht eindeutig ausschließen. Im Gegenteil, Stichproben ergaben, dass sie mit Anfragen einer verbotenen Ressource zusammenhängen.
Adressen und im Internet sind autonome Systeme wichtiger - AS, von denen
1510 herauskamen, durchschnittlich 2 Adressen auf AS mit Median 1. Top-Adressen auf AS: 288, 77, 66, 39, 27. Das Maximum von 95% der Stichprobe beträgt 4 Adressen AS. Hier wird der Median erwartet - ein Agent pro Anbieter. Wir erwarten auch die Spitze - es gibt große Spieler darin. In einem großen Netzwerk sollten sich Agenten wahrscheinlich in jeder Region der Präsenz des Betreibers befinden und NAT nicht vergessen. Wenn Sie nach Land nehmen, sind die Höchstwerte: 1409 - RU, 42 - UA, 23 - CZ, 36 aus anderen Regionen, nicht RIPE NCC. Anfragen nicht aus Russland ziehen die Aufmerksamkeit auf sich. Möglicherweise kann dies durch Geolokalisierungsfehler oder Registrierungsfehler beim Ausfüllen der Daten erklärt werden. Oder die Tatsache, dass ein russisches Unternehmen möglicherweise nicht russische Wurzeln hat oder eine ausländische Repräsentanz hat, weil es so einfach ist, dass es selbstverständlich ist, mit einer ausländischen Organisation RIPE NCC zusammenzuarbeiten. Ein Teil ist zweifellos überflüssig, aber es ist zuverlässig schwierig, ihn zu trennen, da die Ressource gesperrt ist und ab dem zweiten Tag doppelt gesperrt ist und die meisten Sitzungen nur ein Austausch mehrerer Servicepakete sind. Lassen Sie uns der Tatsache zustimmen, dass dies ein kleiner Teil ist.
Diese Zahlen können bereits mit der Anzahl der Anbieter in Russland verglichen werden.
Laut ILV sind die Lizenzen für „Kommunikationsdienste für die Datenübertragung, außer für Sprache“ 6387, aber dies ist eine hoch gemobbte Bewertung von oben. Nicht alle dieser Lizenzen gelten speziell für Internetanbieter, die den Agenten installieren müssen. In der RIPE NCC-Zone ist eine ähnliche Anzahl von in Russland registrierten AS 6230, von denen nicht alle Anbieter.
UserSide hat eine strengere Berechnung durchgeführt und im Jahr 2017 3940 Unternehmen erhalten. Dies ist eher eine Schätzung von oben. In jedem Fall haben wir die Anzahl der beleuchteten AS zweieinhalb Mal geringer. Hier lohnt es sich jedoch zu verstehen, dass AS dem Anbieter nicht unbedingt gleichgestellt ist. Einige Anbieter haben keine eigene AS, andere mehr als eine. Wenn wir davon ausgehen, dass die Agenten immer noch bei jedem stehen, filtert jemand mehr als die anderen, sodass ihre Anforderungen, wenn überhaupt, nicht vom Müll zu unterscheiden sind. Aber für eine grobe Einschätzung ist es ziemlich erträglich, selbst wenn etwas aufgrund meines Versehens verloren gegangen ist.
Über DPI
Trotz der Tatsache, dass mein Hosting-Anbieter seinen Filter seit dem zweiten Tag aktiviert hat, können wir gemäß den Informationen für den ersten Tag schließen, dass die Sperren erfolgreich funktionieren. Nur 4 Quellen konnten durchbrechen und haben HTTP- und TCP-Sitzungen vollständig beendet (wie im obigen Beispiel). Ein weiterer 460 kann ein
GET senden, aber die Sitzung endet sofort mit
RST . Achten Sie auf
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"
Variationen davon können unterschiedlich sein: weniger
RST oder mehr Neuübertragung - dies hängt auch davon ab, was der Filter an den Quellknoten sendet. In jedem Fall ist dies die zuverlässigste Vorlage, aus der hervorgeht, dass die verbotene Ressource angefordert wurde. Außerdem gibt es immer eine Antwort, die in einer Sitzung mit einer
TTL angezeigt wird, die größer ist als in vorherigen und nachfolgenden Paketen.
Auch das
GET vom Rest nicht sichtbar:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0" TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=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"
Der Unterschied in der
TTL ist sicherlich sichtbar, wenn etwas vom Filter kommt. Aber oft kann es überhaupt nicht fliegen:
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"
Und all dies wiederholt sich und wiederholt sich und wiederholt sich, wie in der Grafik zu sehen ist, jeden Tag genau mehr als einmal.
Über IPv6
Die gute Nachricht ist, dass er es ist. Ich kann zuverlässig sagen, dass von 5 verschiedenen IPv6-Adressen regelmäßig Anfragen an die verbotene Ressource gestellt werden, genau das Verhalten der Agenten, das ich erwartet habe. Außerdem fällt eine der IPv6-Adressen nicht unter die Filterung, und ich sehe eine vollständige Sitzung. Bei zwei weiteren sah ich nur eine unvollständige Sitzung, von denen eine durch
RST vom Filter unterbrochen wurde, die zweite in der Zeit. Insgesamt
7 .
Da es nur wenige Adressen gibt, habe ich sie alle im Detail studiert und es stellte sich heraus, dass es nur 3 Anbieter gibt. Sie können sie im Stehen begrüßen! Eine andere Adresse ist Cloud-Hosting in Russland (filtert nicht), eine andere ist ein Forschungszentrum in Deutschland (wo gibt es einen Filter?). Aber warum sie planmäßig die Verfügbarkeit verbotener Ressourcen überprüfen, ist eine gute Frage. Die verbleibenden zwei haben eine Anfrage gestellt und befinden sich nicht an den Grenzen Russlands, wobei eine von ihnen gefiltert wird (befindet sie sich noch auf der Durchreise?).
Locks and Agents ist eine große Bremse für IPv6, deren Implementierung daher nicht sehr schnell vonstatten geht. Es ist traurig. Diejenigen, die diese Aufgabe gelöst haben, sind voll und ganz stolz auf sich.
Abschließend
Ich habe keine 100% ige Genauigkeit angestrebt. Ich bitte Sie, mir dies zu verzeihen. Ich hoffe, jemand möchte diese Arbeit mit größerer Genauigkeit wiederholen. Für mich war es wichtig zu verstehen, ob ein solcher Ansatz grundsätzlich funktionieren würde. Die Antwort wird sein. Die resultierenden Zahlen in erster Näherung sind meiner Meinung nach ziemlich zuverlässig.
Was ich sonst noch tun konnte und zu faul war, war die Berechnung von DNS-Abfragen. 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 mit dem kombinieren, was in den Anforderungen direkt sichtbar ist, können Sie den Überschuss trennen und weitere Informationen erhalten. Es ist sogar möglich, die von Anbietern verwendeten DNS-Entwickler und vieles mehr zu identifizieren.
Ich habe absolut nicht erwartet, dass der Hoster für meinen VPS auch einen eigenen Filter enthält. Vielleicht ist dies eine gängige Praxis. Am Ende sendet der ILV eine Anfrage zum Löschen der Ressource an den Hoster. Aber es hat mich nicht überrascht und sogar zu einem Vorteil gespielt. Der Filter arbeitete sehr effizient, indem alle korrekten HTTP-Anforderungen an die verbotene URL abgeschnitten wurden, jedoch nicht die korrekten, die zuvor durch den Filter der Anbieter geleitet wurden, auch wenn dies nur in Form von Endungen erfolgte:
FIN-ACK und
RST - minus minus und fast ein Plus. Der IPv6-Hoster wurde übrigens nicht gefiltert. Dies wirkte sich natürlich auf die Qualität des gesammelten Materials aus, ermöglichte jedoch die Anzeige der Häufigkeit. Dies stellte sich als wichtiger Punkt bei der Auswahl eines Standorts für die Platzierung von Ressourcen heraus. Vergessen Sie nicht, sich für die Organisation der Arbeit mit der Liste der verbotenen Standorte und Anfragen des ILV zu interessieren.
Am Anfang habe ich den AC „Auditor“ mit
RIPE Atlas verglichen. Dieser Vergleich ist gerechtfertigt und ein großes Netzwerk von Agenten kann von Vorteil sein. Zum Beispiel die Qualität der Ressourcenverfügbarkeit von verschiedenen Anbietern in verschiedenen Teilen des Landes bestimmen. Sie können die Verzögerungen berechnen, Diagramme erstellen, alles analysieren und die lokal und global auftretenden Änderungen anzeigen. Dies ist nicht der direkteste Weg, aber Astronomen verwenden "Standardkerzen". Warum nicht Agenten verwenden? Wenn Sie ihr Standardverhalten kennen (finden), können Sie die Änderungen bestimmen, die um sie herum auftreten, und wie sich dies auf die Qualität der bereitgestellten Dienste auswirkt. Gleichzeitig müssen Sie die Sonden nicht unabhängig voneinander im Netzwerk installieren, sie wurden bereits von Roskomnadzor geliefert.
Ein weiterer Punkt, den ich ansprechen möchte, ist, dass jedes Werkzeug eine Waffe sein kann. AS "Inspector" ist ein geschlossenes Netzwerk, aber Agenten geben alle mit Innereien ab, indem sie Anforderungen für alle Ressourcen aus der verbotenen Liste senden. Eine solche Ressource zu beschaffen, ist absolut kein Problem. Insgesamt Anbieter über Agenten, die unfreiwillig viel mehr über ihr Netzwerk erzählen, als es wert wäre: Arten von DPI und DNS, Standort des Agenten (zentraler Knoten und Dienstnetzwerk?), Netzwerkmarkierungen für Verzögerungen und Verluste - und dies ist nur die offensichtlichste. So wie jemand die Aktionen von Agenten überwachen kann, um die Verfügbarkeit ihrer Ressourcen zu verbessern, kann jemand dies für andere Zwecke tun, und es gibt keine Hindernisse. Ein zweischneidiges und sehr facettenreiches Instrument, von dem sich jeder überzeugen kann.