Es ist kein Geheimnis, dass die automatisierte «Revisor»-System die Blockierungen auf der Liste verbotener Informationen in Russland überwacht. Wie das funktioniert, ist recht gut in diesem , das Bild ebenfalls von dort:
Direkt beim Anbieter wird :
installiert. Das Modul «Agent Revisor» ist ein strukturelles Element des automatisierten Systems «Revisor» (AS «Revisor»). Dieses System dient der Überwachung der Einhaltung der Anforderungen durch die Kommunikationsanbieter zur Beschränkung des Zugangs gemäß den Bestimmungen der Artikel 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149-FZ «Über Informationen, Informationstechnologien und den Schutz von Informationen».
Das Hauptziel der Erstellung des Systems „Revisor“ besteht darin, die Einhaltung der Anforderungen, die in den Artikeln 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149-FZ „Über Informationen, Informationstechnologien und den Schutz von Informationen“ festgelegt sind, durch die Kommunikationsanbieter zu überwachen. Dabei geht es insbesondere um die Feststellung von Zugriffen auf verbotene Informationen und das Sammeln von Bestätigungsunterlagen (Daten) über Verstöße hinsichtlich des Zugriffs auf diese verbotenen Informationen.
In Anbetracht dessen, dass, wenn nicht alle, viele Anbieter dieses Gerät bei sich installiert haben, sollte sich ein großes Netzwerk aus Proben-Baken wie und sogar mehr, aber mit eingeschränktem Zugang, ergeben. Dennoch bleibt eine Bake eine Bake, um Signale in alle Richtungen zu senden. Was wäre, wenn wir diese Signale auffangen und herausfinden, was wir erhalten haben und wie viel?
Bevor wir zählen, schauen wir uns an, warum das überhaupt möglich sein könnte.
Ein wenig Theorie
Agenten überprüfen die Verfügbarkeit von Ressourcen, unter anderem durch HTTP(S) Anfragen, wie zum 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"
Neben der Nutzlast umfasst die Anfrage auch eine Phase für den Verbindungsaufbau: Austausch SYN und SYN-ACK, und die Phase für den Verbindungsabbau: FIN-ACK.
Das Register für gesperrte Informationen enthält mehrere Arten von Blockierungen. Offensichtlich, wenn eine Ressource nach IP-Adresse oder Domainname blockiert wird, sehen wir keine Anfragen. Dies sind die zerstörerischsten Arten von Blockierungen, die zur Unzugänglichkeit aller Ressourcen einer IP-Adresse oder gesamten Informationen einer Domain führen. Es gibt auch eine Art von Blockierung "nach URL". In diesem Fall muss das Filtersystem die HTTP-Header der Anfrage analysieren, um genau zu bestimmen, was zu blockieren ist. Und davor, wie oben zu sehen ist, muss die Phase des Verbindungsaufbaus stattfinden, die wahrscheinlich vom Filter nicht erkannt wird.
Dazu muss eine geeignete, verfügbare Domain mit der Blockierung „nach URL“ und HTTP ausgewählt werden, um das Filtern zu erleichtern. Es ist empfehlenswert, eine seit längerer Zeit verwaiste Domain zu nutzen, um den unerwünschten Traffic von außerhalb, außer von den Agenten, zu minimieren. Diese Aufgabe stellte sich als relativ einfach heraus, da es im Register für verbotene Informationen viele verfügbare Domains gibt, die für jeden Geschmack geeignet sind. Daher wurde die Domain erworben und mit IP-Adressen auf einem VPS verbunden, auf dem tcpdump ausgeführt wurde, und die Zählung begann.
Revision der „Revisionierer“
Ich erwartete, zeitweise Anstiege der Anfragen zu sehen, was meiner Meinung nach auf eine gesteuerte Aktion hindeuten würde. Man kann nicht sagen, dass ich das überhaupt nicht sah, aber ein klares Bild war definitiv nicht vorhanden:
Es wundert nicht, dass sogar auf einer völlig unwichtigen Domain mit einer niemals genutzten IP eine Flut an unerwünschten Informationen eintrifft – so ist nun einmal das moderne Internet. Glücklicherweise benötigte ich nur die Anfragen zu einer bestimmten URL, deshalb konnten alle Scanner und Passwortknacker schnell identifiziert werden. Es war auch relativ einfach zu erkennen, wo es ein Übermaß an identischen Anfragen gab. Anschließend erstellte ich eine Frequenzanalyse der IP-Adressen und durchging manuell die gesamte Rangliste, um diejenigen zu trennen, die in den vorherigen Phasen durchgerutscht waren. Zusätzlich schloss ich alle Quellen aus, die nur ein einzelnes Paket geschickt hatten – das waren nicht viele. Und das kam dabei heraus:
Eine kleine lyrische Abschweifung. Etwas mehr als ein Tag später erhielt ich eine E-Mail von meinem Hosting-Anbieter, in der es hieß, dass auf meinen Ressourcen ein Inhalt von der verbotenen Liste der RKN vorhanden sei und daher blockiert werde. Zuerst dachte ich, sie hätten mein Konto gesperrt, was jedoch nicht der Fall war. Dann dachte ich, sie würden mich lediglich warnen über etwas, dessen ich mir bereits bewusst war. Aber es stellte sich heraus, dass der Hoster seinen Filter vor meiner Domain aktiviert hatte, und ich somit einer doppelten Filterung ausgesetzt war: sowohl seitens der Provider als auch seitens des Hosters. Der Filter ließ nur die Enden der Anfragen durch: FIN-ACK und RST und schnitt den gesamten HTTP über die verbotene URL ab. Wie aus dem obigen Diagramm ersichtlich, erhielt ich nach den ersten 24 Stunden weniger Daten, aber ich erhielt sie dennoch, was für die Aufgabe zur Zählung der Anfragenquellen ausreichend war.
Kommen wir zur Sache. Meiner Meinung nach sind zwei Spitzen pro Tag klar erkennbar: die erste, kleiner, nach Mitternacht in Moskau, die zweite gegen 6 Uhr morgens mit einem Nachlauf bis 12 Uhr mittags. Der Höhepunkt fällt nicht immer genau auf die gleiche Zeit. Zunächst wollte ich die IP-Adressen hervorheben, die nur in diesen Zeitfenstern auftraten, und jede in allen Zeitfenstern, basierend auf der Annahme, dass die Überprüfungen durch die Agenten regelmäßig durchgeführt werden. Bei genauerer Betrachtung stellte ich jedoch schnell fest, dass es Zeiten gibt, die in andere Intervalle fallen, mit unterschiedlichen Frequenzen, bis hin zu einer Anfrage jede Stunde. Dann dachte ich an die Zeitzonen und dass möglicherweise dies der Grund sein könnte; später kam mir der Gedanke, dass das System möglicherweise nicht global synchronisiert sein könnte. Außerdem wird sicher auch NAT eine Rolle spielen, sodass derselbe Agent Anfragen von verschiedenen öffentlichen IPs ausstellen kann.
Da mein ursprüngliches Ziel nicht Genauigkeit war, habe ich einfach alle Adressen gezählt, die in der Woche aufgetaucht sind, und erhielt – 2791Die Anzahl der TCP-Sitzungen, die von einer Adresse aus hergestellt werden, liegt im Durchschnitt bei 4, mit einem Median von 2. Die häufigsten Sitzungen pro Adresse sind: 464, 231, 149, 83, 77. Das Maximum aus 95 % der Stichprobe beträgt 8 Sitzungen pro Adresse. Der Median ist nicht besonders hoch; ich erinnere daran, dass im Diagramm eine klare tägliche Periodizität zu erkennen ist, daher konnte man etwa 4 bis 8 über 7 Tage erwarten. Wenn wir alle einzeln auftretenden Sitzungen ausschließen, erhalten wir genau einen Median von 5. Ich konnte sie jedoch nicht eindeutig ausschließen. Im Gegenteil, die stichprobenartige Überprüfung hat gezeigt, dass sie mit Anfragen an eine verbotene Ressource in Zusammenhang stehen.
Adressen sind wichtig, aber im Internet sind autonome Systeme — AS — entscheidender. 1510, durchschnittlich 2 Adressen pro AS mit einem Median von 1. Die Top-Adressen auf AS: 288, 77, 66, 39, 27. Das Maximum aus einer 95%-Stichprobe — 4 Adressen pro AS. Hier ist der Median zu erwarten — ein Agent pro Anbieter. Die Top-Player sind ebenfalls erwartbar — es handelt sich um große Akteure. In einem großen Netzwerk sollten Agenten wahrscheinlich in jeder Region des Netzbetreibers stehen, und nicht zu vergessen ist NAT. Wenn wir die Länder betrachten, ergibt sich Folgendes: 1409 — RU, 42 — UA, 23 — CZ, 36 aus anderen Regionen, die nicht zur RIPE NCC gehören. Anfragen außerhalb Russlands fallen auf. Das lässt sich wahrscheinlich durch Geolokalisierungsfehler oder Fehler der Registrare bei der Dateneingabe erklären. Oder dadurch, dass ein russisches Unternehmen nicht unbedingt russische Wurzeln haben oder eine ausländische Vertretung besitzen kann, weil es einfacher ist, insbesondere im Umgang mit der ausländischen Organisation RIPE NCC. Ein Teil ist sicherlich überflüssig, aber es ist schwierig, ihn zuverlässig zu trennen, da die Ressource blockiert ist und ab dem zweiten Tag unter doppelter Blockierung steht und die meisten Sitzungen lediglich den Austausch einiger Statuspakete darstellen. Vereinbaren wir, dass dies ein kleiner Teil ist.
Diese Zahlen können bereits mit der Anzahl der Anbieter in Russland verglichen werden. gibt es 6387 Lizenzen für „Telekommunikationsdienste zur Datenübertragung, mit Ausnahme von Stimme“, was jedoch eine stark überhöhte Schätzung ist. Nicht alle diese Lizenzen gehören zu den Internetanbietern, die einen Agenten installieren müssen. In der RIPE NCC Zone gibt es eine ähnliche Anzahl an AS, die in Russland registriert sind – 6230, von denen nicht alle Anbieter sind. und kam im Jahr 2017 auf 3940 Unternehmen, was eher eine obere Schätzung ist. In jedem Fall haben wir die Anzahl der aufgetretenen AS, die zweieinhalb Mal geringer ist. Dabei sollte man verstehen, dass AS nicht strikt gleich einem Anbieter ist. Einige Anbieter haben keine eigene AS, während andere mehr als eine haben. Wenn man davon ausgeht, dass Agenten überall vorhanden sind, filtert jemand stärker als die anderen, sodass ihre Anfragen von dem, was als Müll angesehen wird, nicht zu unterscheiden sind, wenn sie überhaupt ankommen. Aber für eine grobe Schätzung ist das durchaus hinnehmbar, selbst wenn durch mein Versäumnis etwas verloren gegangen ist.
Über DPI
Obwohl mein Hosting-Anbieter seinen Filter ab dem zweiten Tag aktiviert hat, kann man aufgrund der Informationen vom ersten Tag feststellen, dass die Blockierungen erfolgreich funktionieren. Nur 4 Quellen konnten durchkommen und haben vollständig abgeschlossene HTTP- und TCP-Sitzungen (wie im obigen Beispiel). Weitere 460 können versuchen, zu senden GET, aber die Sitzung wird sofort abgebrochen wegen RST. Beachten Sie 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"
#Das hat der Filter gesendet
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#Das ist ein Versuch des ursprünglichen Knotens, den Verlust zu erkennen
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"
#Der ursprüngliche Knoten versteht, dass die Sitzung abgebrochen wurde
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Die Variationen davon können unterschiedlich sein: weniger RST oder mehr Retransmissions – hängt auch davon ab, was der Filter dem ursprünglichen Knoten sendet. In jedem Fall ist dies die zuverlässigste Vorlage, aus der hervorgeht, dass genau die gesperrte Ressource angefordert wurde. Zudem gibt es immer eine Antwort, die in der Sitzung mit erscheint TTL größer ist als in den vorherigen und nachfolgenden Paketen.
Von den anderen ist nicht einmal sichtbar GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Das hat der Filter geschickt
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"
#Das hat der Filter geschickt
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"
#Wieder Filter, viele Male
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Der Unterschied ist auf jeden Fall deutlich TTL wenn etwas vom Filter kommt. Es kann aber oft auch überhaupt nichts ankommen:
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"
#Es sind einige Sekunden ohne Traffic vergangen
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Und all das wiederholt sich und wiederholt sich und wiederholt sich, wie im Diagramm zu sehen ist, in der Tat nicht nur einmal, jeden Tag.
Über IPv6
Die gute Nachricht ist, dass es vorhanden ist. Ich kann mit Sicherheit sagen, dass von 5 verschiedenen IPv6-Adressen periodische Anfragen an eine gesperrte Ressource erfolgen, genau das Verhalten der Agenten, das ich erwartet habe. Dabei fällt eine der IPv6-Adressen nicht unter die Filterung und ich sehe eine vollständige Sitzung. Bei zwei anderen habe ich jeweils nur eine unvollständige Sitzung gesehen, von denen eine aufgrund RST der Filterung abgebrochen wurde, die andere wegen der Zeit. Insgesamt sind es 7.
Da es nur wenige Adressen gibt, habe ich sie alle genau untersucht und festgestellt, dass es tatsächlich nur 3 Anbieter gibt, denen man stehende Ovationen geben kann! Eine weitere Adresse ist ein Cloud-Hosting-Anbieter in Russland (filtert nicht), eine andere ist ein Forschungszentrum in Deutschland (hat einen Filter, wo?). Die Frage ist gut, warum sie zeitgesteuert die Verfügbarkeit gesperrter Ressourcen überprüfen. Die verbleibenden zwei haben jeweils eine Anfrage gestellt und befinden sich außerhalb Russlands, wobei eine von ihnen gefiltert wird (schließlich beim Transit?).
Blockaden und Agenten sind ein großes Hemmnis für IPv6, dessen Einführung ohnehin nicht sehr schnell vorankommt. Das ist bedauerlich. Diejenigen, die dieses Problem vollständig gelöst haben, können stolz auf sich sein.
Zusammenfassung
Ich habe nicht nach 100 %iger Genauigkeit gestrebt und bitte um Nachsicht dafür; ich hoffe, dass jemand eine solche Arbeit mit größerer Sorgfalt wiederholen möchte. Für mich war es wichtig zu verstehen, ob ein solcher Ansatz grundsätzlich funktionieren wird. Die Antwort ist – ja, es wird funktionieren. Die erhaltenen Zahlen sind im ersten Ansatz, denke ich, durchaus zuverlässig.
Was man noch hätte tun können, und was ich aus Bequemlichkeit nicht getan habe – die DNS-Anfragen zu zählen. Sie werden nicht gefiltert, bieten jedoch keine hohe Genauigkeit, da sie nur für die Domain und nicht für die gesamte URL funktionieren. Die Periodizität sollte sichtbar sein. Wenn man sie mit dem kombiniert, was direkt aus den Anfragen sichtbar ist, könnte man das Überflüssige herausfiltern und mehr Informationen erhalten. Möglicherweise sogar die DNS-Entwickler, die von den Anbietern verwendet werden, und vieles mehr.
Ich hatte absolut nicht damit gerechnet, dass mein VPS-Hoster auch noch seinen eigenen Filter aktivieren würde. Vielleicht ist das übliche Praxis. Schließlich sendet die RKN die Anfrage zur Entfernung einer Ressource direkt an den Hoster. Aber mich hat das nicht überrascht und hat sogar irgendwo einen positiven Effekt gehabt. Der Filter hat sehr effektiv alle korrekten HTTP-Anfragen an die verbotene URL blockiert, während die inkorrekten, die zuvor durch die Filter der Anbieter gelaufen sind, durchkamen, wenn auch nur in Form von Endstücken: FIN-ACK und RST — minus auf minus ergibt fast plus. Übrigens wurde IPv6 vom Hoster nicht gefiltert. Natürlich hatte das Einfluss auf die Qualität des gesammelten Materials, aber es bot dennoch die Möglichkeit, die Häufigkeit zu sehen. Es stellte sich heraus, dass dies ein wichtiger Punkt bei der Auswahl einer Plattform für die Platzierung von Ressourcen ist. Vergessen Sie nicht, sich nach der Organisation der Arbeit mit der Liste der verbotenen Websites und den Anfragen von der RKN zu erkundigen.
Zu Beginn habe ich das AS "Revizor" mit . Dieser Vergleich ist durchaus gerechtfertigt, und ein großes Netzwerk von Agenten kann von Vorteil sein. Zum Beispiel die Qualitätsbestimmung der Verfügbarkeit von Ressourcen verschiedener Anbieter aus unterschiedlichen Regionen des Landes. Man kann Latenzen messen, Grafiken erstellen und all dies analysieren, um sowohl lokale als auch globale Veränderungen zu beobachten. Dies ist nicht der direkteste Weg, aber Astronomen nutzen ja auch „Standardkerzen“. Warum sollten wir nicht Agenten verwenden? Wenn man ihr Standardverhalten kennt (oder gefunden hat), kann man Veränderungen um sie herum erkennen und wie sich das auf die Qualität der Dienstleistungen auswirkt. Dabei ist es nicht nötig, selbst Proben im Netzwerk zu platzieren; das hat bereits der Roskomnadsor erledigt.
Ein weiterer Punkt, den ich ansprechen möchte: Jedes Werkzeug kann zur Waffe werden. Das AS "Revizor" ist ein geschlossenes Netzwerk, aber die Agenten verraten alles, indem sie Anfragen an alle Ressourcen aus der verbotenen Liste senden. Solche Ressourcen zu beschaffen ist in der Tat kein Problem. Insgesamt erzählen die Anbieter über die Agenten, ob sie wollen oder nicht, viel mehr über ihr Netzwerk, als sie sollten: Arten von DPI und DNS, Standort des Agenten (Zentralstelle und Dienstnetzwerk?), Netzwerklatenz und -verluste – und das ist nur die offensichtlichste Information. Genau wie jemand die Aktivitäten der Agenten überwachen kann, um die Verfügbarkeit seiner Ressourcen zu verbessern, kann jemand dies auch aus anderen Gründen tun, und es gibt keine Hindernisse dafür. Ein zweischneidiges und sehr vielschichtiges Werkzeug, von dem jeder überzeugt sein kann.
Quelle: habr.com
