Es ist kein Geheimnis, dass die Ăberwachung der Blockierungen von Informationen, die auf der Liste verbotener Inhalte in Russland stehen, durch das automatisierte System «Revisor» erfolgt. Wie das funktioniert, ist in diesem , das Bild stammt 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 Kontrolle der Einhaltung von Anforderungen der Kommunikationsanbieter zur EinschrĂ€nkung des Zugangs gemÀà den Bestimmungen der Artikel 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006, Nr. 149-ЀР«Ăber Informationen, Informationstechnologien und den Schutz von Informationen».
Ein Hauptziel der Schaffung von AS «Revisor» ist es, die Ăberwachung der Einhaltung der Anforderungen, die in den Artikeln 15.1-15.4 des Bundesgesetzes vom 27. Juli 2006 Nr. 149-ЀР«Ăber Informationen, Informationstechnologien und den Schutz von Informationen» festgelegt sind, bezĂŒglich des Nachweises von Zugriffsverletzungen auf verbotene Informationen und der Erfassung von Nachweismaterialien (Daten) ĂŒber VerstöĂe gegen den Zugang zu verbotenen Informationen sicherzustellen.
In Anbetracht der Tatsache, dass, wenn nicht alle, dann doch viele Anbieter dieses GerĂ€t installiert haben, hĂ€tte sich ein groĂes Netzwerk von Sendern in Form von und sogar mehr, aber mit geschlossenem Zugang, ergeben sollen. Allerdings ist ein Sender auch ein Sender, um Signale in alle Richtungen zu senden. Was passiert, wenn wir sie abfangen und herausfinden, was wir abgefangen haben und wie viel?
Bevor wir zĂ€hlen, betrachten wir, warum das ĂŒberhaupt möglich sein könnte.
Ein wenig Theorie
Die Agenten ĂŒberprĂŒfen die VerfĂŒgbarkeit der Ressource, unter anderem durch HTTP(S)-Anfragen, wie diese beispielsweise:
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 Anfrage besteht neben der NĂŒtzlichkeit auch aus einer Verbindungsaufbauphase: Austausch SYN und SYN-ACK, und einer Verbindungsabschlussphase: FIN-ACK.
Das Register der verbotenen Informationen enthĂ€lt mehrere Arten von Sperren. Offensichtlich, wenn eine Ressource aufgrund der IP-Adresse oder des Domainnamens blockiert wird, werden wir keine Anfragen sehen. Dies sind die zerstörerischsten Arten von Sperren, die zur UnzugĂ€nglichkeit aller Ressourcen unter einer IP-Adresse oder aller Informationen auf der Domain fĂŒhren. Es gibt auch eine Sperrtage, die auf âURLâ basiert. In diesem Fall muss das Filtersystem den HTTP-Header der Anfrage analysieren, um genau zu bestimmen, was blockiert werden soll. Davor, wie oben ersichtlich, muss die Verbindungsphase stattfinden, die man zu verfolgen versuchen kann, da der Filter sie wahrscheinlich passieren wird.
DafĂŒr muss eine geeignete, frei verfĂŒgbare Domain mit einer Sperre vom Typ âURLâ und HTTP ausgewĂ€hlt werden, um die Arbeit des Filtersystems zu erleichtern. Es ist wĂŒnschenswert, dass die Domain schon lange aufgegeben wurde, um die Wahrscheinlichkeit eines externen Traffics auĂer von Agenten zu minimieren. Diese Aufgabe erwies sich als gar nicht schwierig, da es im Register der verbotenen Informationen viele freie Domains gibt, die fĂŒr jeden Geschmack geeignet sind. Deshalb wurde die Domain erworben und an IP-Adressen auf VPS verbunden, auf denen tcpdump und die ZĂ€hlung begann.
Revision der âRevisorenâ
Ich erwartete, sporadische Anfragen zu sehen, was meiner Meinung nach auf ein gesteuertes Handeln hindeuten wĂŒrde. Man kann nicht sagen, dass ich das ĂŒberhaupt nicht gesehen habe, aber ein klares Bild gab es definitiv nicht:
Was nicht ĂŒberraschend ist, selbst auf einer nutzlosen Domain auf einer nie benutzten IP-Adresse wird eine Menge unerwĂŒnschter Informationen eingehen, so ist das moderne Internet. Aber zum GlĂŒck benötigte ich nur die Anfragen zu einer bestimmten URL, also wurden alle Scanner und Passwortgeneratoren schnell gefunden. Es war auch ziemlich einfach zu verstehen, wo es eine Flut von gleichartigen Anfragen gab. Danach stellte ich die HĂ€ufigkeiten der IP-Adressen zusammen und ĂŒberprĂŒfte manuell die gesamte Liste, wobei ich die herausfilterte, die in den vorherigen Phasen durchgerutscht waren. ZusĂ€tzlich schnitt ich alle Quellen heraus, die nur ein Paket gesendet hatten; diese waren nicht mehr viele. Und es ergab sich Folgendes:
Eine kleine lyrische Abweichung. Etwas mehr als einen Tag spĂ€ter erhielt mein Hosting-Anbieter ein Schreiben mit recht zweideutigem Inhalt, dass auf meinen Ressourcen eine Ressource aus der verbotenen Liste des RKN vorhanden sei, weshalb sie blockiert wird. Zuerst dachte ich, dass mein Konto gesperrt wurde, was nicht der Fall war. Dann dachte ich, dass ich nur gewarnt werde ĂŒber etwas, das ich bereits weiĂ. Aber es stellte sich heraus, dass der Hoster seinen Filter vor meiner Domain aktiviert hatte und ich letztendlich in eine doppelte Filterung geraten bin: sowohl seitens der Anbieter als auch seitens des Hosts. Der Filter lieĂ nur die Enden der Anfragen durch: FIN-ACK und RST indem er das gesamte HTTP bei der verbotenen URL abbrach. 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 der Berechnung der Quellen der Anfragen ausreichte.
Kommen wir zur Sache. Meiner Meinung nach sind zwei Spitzen jeden Tag ganz klar zu erkennen, die erste, kleinere, nach Mitternacht nach Moskauer Zeit, die zweite nĂ€her an 6 Uhr morgens mit einem Nachlauf bis 12 Uhr mittags. Der Höhepunkt fĂ€llt nicht genau zur gleichen Zeit. Zuerst wollte ich nur die IP-Adressen hervorheben, die nur in diesen ZeitrĂ€umen vorkamen, und jede Adresse in allen ZeitrĂ€umen, basierend auf der Annahme, dass die ĂberprĂŒfungen durch die Agenten periodisch durchgefĂŒhrt werden. Aber bei genauerer Betrachtung stellte ich schnell fest, dass es ZeitrĂ€ume gibt, die in andere Intervalle fallen, mit anderen Frequenzen, bis hin zu einer Anfrage jede Stunde. Dann dachte ich an die Zeitzonen und dass möglicherweise hierin das Problem liegt, und spĂ€ter dachte ich, dass die gesamte System möglicherweise nicht global synchronisiert sein könnte. Zudem wird mit Sicherheit NAT eine Rolle spielen und derselbe Agent kann Anfragen von verschiedenen öffentlichen IP-Adressen aus machen.
Da mein ursprĂŒngliches Ziel nicht die Genauigkeit war, zĂ€hlte ich alle Adressen, die ich in einer Woche fand, und erhielt â 2791. Die Anzahl der TCP-Sitzungen, die von einer Adresse aus im Durchschnitt 4 hergestellt wurden, mit einer Medianzahl von 2. Die meisten Sitzungen pro Adresse: 464, 231, 149, 83, 77. Höchstzahl aus der 95%-Stichprobe â 8 Sitzungen pro Adresse. Die Medianzahl ist nicht sehr hoch; ich erinnere daran, dass im Diagramm eine deutliche tĂ€gliche PeriodizitĂ€t sichtbar ist, weshalb man etwas in der Range von 4 bis 8 in 7 Tagen erwarten konnte. Wenn man alle einmalig auftretenden Sitzungen herausnimmt, erhĂ€lt man genau eine Medianzahl von 5. Aber ich konnte sie nicht auf ein klares Kriterium hin ausschlieĂen. Im Gegenteil, die stichprobenartige ĂberprĂŒfung zeigte, dass sie mit den Anfragen der verbotenen Ressource in Zusammenhang stehen.
Adressen sind wichtig, aber im Internet zĂ€hlen vor allem autonome Systeme â AS, von denen es geworden ist 1510, im Durchschnitt 2 Adressen pro AS mit einem Median von 1. Die Top-Adressen auf AS: 288, 77, 66, 39, 27. Das Maximum aus 95 % der Stichprobe â 4 Adressen pro AS. Hier ist der Median erwartungsgemÀà â ein Agent pro Anbieter. Auch die Top-Anbieter sind erwartungsgemÀà â darunter groĂe Akteure. In einem groĂen Netzwerk sollten Agenten wahrscheinlich in jeder Region vorhanden sein, in der der Anbieter tĂ€tig ist, und wir dĂŒrfen auch NAT nicht vergessen. Wenn wir die LĂ€nder betrachten, ergeben sich die Maxima: 1409 â RU, 42 â UA, 23 â CZ, 36 aus anderen Regionen, die nicht RIPE NCC zugeordnet sind. Anfragen, die nicht aus Russland stammen, fallen auf. Wahrscheinlich lĂ€sst sich das durch Geolokalisierungsfehler oder durch Fehler der Registrare bei der Dateneingabe erklĂ€ren. Oder damit, dass ein russisches Unternehmen keine russischen Wurzeln haben kann oder eine auslĂ€ndische Niederlassung hat, weil es einfacher ist, mit einer auslĂ€ndischen Organisation wie RIPE NCC umzugehen. Ein Teil ist sicherlich ĂŒberflĂŒssig, aber es ist schwierig, dies zuverlĂ€ssig zu trennen, da die Ressource blockiert ist und ab dem zweiten Tag unter doppelter Blockierung steht, wodurch die meisten Sitzungen lediglich den Austausch mehrerer Steuerpakete darstellen. Lassen Sie uns darauf einigen, dass dies ein kleiner Teil ist.
Diese Zahlen lassen sich bereits mit der Anzahl der Anbieter in Russland vergleichen. gibt es 6387 Lizenzen fĂŒr âDatenĂŒbertragungsdienste, mit Ausnahme von Spracheâ â aber das ist eine stark ĂŒberhöhte SchĂ€tzung, nicht alle diese Lizenzen beziehen sich auf Internetanbieter, die einen Agenten einsetzen mĂŒssen. In der RIPE NCC Zone liegt die Ă€hnliche Anzahl der in Russland registrierten AS bei 6230, von denen nicht alle Anbieter sind. und kam 2017 auf 3940 Unternehmen, und das ist eher eine SchĂ€tzung von oben. In jedem Fall haben wir eine Zahl von erschienenen AS, die zweieinhalbmal niedriger ist. Aber hier muss man verstehen, dass AS nicht unbedingt gleich Anbieter ist. Einige Anbieter haben kein eigenes AS, andere haben mehr als eines. Wenn wir annehmen, dass Agenten tatsĂ€chlich bei allen aufgestellt sind, dann bedeutet das, dass einige stĂ€rker filtern als andere, sodass ihre Anfragen nicht von MĂŒll zu unterscheiden sind, wenn sie ĂŒberhaupt ankommen. Aber fĂŒr eine grobe SchĂ€tzung ist das durchaus akzeptabel, selbst wenn etwas durch mein Versagen verloren gegangen ist.
Ăber DPI
Obwohl mein Hosting-Anbieter seinen Filter ab dem zweiten Tag aktiviert hat, kann aus den Informationen des ersten Tages geschlossen werden, dass die Blockierungen erfolgreich sind. Nur 4 Quellen konnten durchdringen und haben vollstÀndige HTTP- und TCP-Sitzungen (wie im obigen Beispiel) abgeschlossen. Weitere 460 können senden GET, aber die Sitzung bricht sofort ab aufgrund von RST. Bitte 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"
#Und das ist der Versuch des Quellknotens, Verlust zu erhalten
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 Quellknoten erkennt, dass die Sitzung zerstört 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 Retransmissionen â es hĂ€ngt auch davon ab, was der Filter an den Quellknoten sendet. In jedem Fall ist dies das verlĂ€sslichste Muster, aus dem ersichtlich ist, dass tatsĂ€chlich eine verbotene Ressource angefordert wurde. AuĂerdem gibt es immer eine Antwort, die in der Sitzung mit TTL gröĂeren als in den vorherigen und nachfolgenden Paketen erscheint.
Von den anderen sieht man nicht einmal GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Das hat der Filter gesendet
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 gesendet
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, immer wieder
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Es ist unbedingt sichtbar, wenn etwas vom Filter eintrifft. Aber oft kann auch ĂŒberhaupt nichts eintreffen: TTL 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" ...
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Einige Sekunden ohne Traffic vergangen
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Oder so:
Und das wiederholt sich und wiederholt sich und wiederholt sich, wie auf dem Diagramm zu sehen ist, definitiv nicht nur einmal, jeden Tag.
Ăber IPv6
Ăber IPv6
Gute Nachrichten â es gibt ihn. Ich kann mit Sicherheit sagen, dass von 5 verschiedenen IPv6-Adressen regelmĂ€Ăig Anfragen an die verbotene Ressource gesendet 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. Von zwei weiteren habe ich nur eine unvollendete Sitzung gesehen, von denen eine abgebrochen wurde aufgrund RST des Filters, die andere aufgrund der Zeit. Insgesamt also 7.
Da es nicht viele Adressen gibt, habe ich sie grĂŒndlich untersucht und es stellte sich heraus, dass es tatsĂ€chlich nur 3 Anbieter gibt, denen man stehend applaudieren kann! Eine weitere Adresse ist ein Cloud-Hosting in Russland (filtert nicht), eine andere ein Forschungszentrum in Deutschland (es gibt einen Filter, wo?). Aber warum sie planmĂ€Ăig die VerfĂŒgbarkeit verbotener Ressourcen ĂŒberprĂŒfen, ist eine gute Frage. Die verbleibenden zwei haben jeweils eine Anfrage gestellt und befinden sich auĂerhalb Russlands, wobei eine von ihnen gefiltert wird (muss wohl beim Transit passieren?).
Blockierungen und Agenten sind ein groĂes Hindernis fĂŒr IPv6, dessen EinfĂŒhrung ohnehin nicht besonders schnell voranschreitet. Das ist bedauerlich. Diejenigen, die dieses Problem vollstĂ€ndig gelöst haben, können stolz auf sich sein.
AbschlieĂend
Ich habe nicht nach 100%iger Genauigkeit gestrebt, ich bitte um Entschuldigung dafĂŒr, ich hoffe, dass jemand diese Arbeit mit mehr Sorgfalt wiederholen möchte. FĂŒr mich war es wichtig zu verstehen, ob dieser Ansatz grundsĂ€tzlich funktionieren wird. Die Antwort â ja, er wird. Die erhaltenen Zahlen sind im ersten NĂ€herungswert, ich denke, ziemlich zuverlĂ€ssig.
Was man noch hĂ€tte tun können und was ich mir nicht angetan habe â die Anfragen an DNS 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 arbeiten. Die HĂ€ufigkeit sollte sichtbar sein. Wenn man dies mit dem kombiniert, was direkt in den Anfragen sichtbar ist, wĂŒrde es ermöglichen, das ĂberflĂŒssige zu separieren und mehr Informationen zu erhalten. Möglicherweise sogar die verwendeten DNS-Entwickler der Anbieter zu bestimmen und vieles mehr.
Ich hatte ĂŒberhaupt nicht erwartet, dass der Hoster fĂŒr mein VPS auch seinen eigenen Filter einschaltet. Vielleicht ist das ĂŒbliche Praxis. SchlieĂlich sendet die RKN die Anfrage zur Entfernung der Ressource direkt an den Hoster. Aber das hat mich nicht ĂŒberrascht und hat sogar irgendwo von Vorteil gespielt. Der Filter arbeitete sehr effektiv und schnitt alle korrekten HTTP-Anfragen an die verbotene URL ab, wĂ€hrend die inkorrekten, die zuvor den Anbieterfilter passiert hatten, durchkamen, wenn auch nur in Form von Enden: FIN-ACK und RST â Minus mal Minus ergibt fast Plus. Ăbrigens wurde von IPv6-Hostern nicht gefiltert. NatĂŒrlich hatte das Einfluss auf die QualitĂ€t des gesammelten Materials, aber es gab trotzdem die Möglichkeit, die PeriodizitĂ€t zu beobachten. Dabei 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 Zusammenarbeit mit Listen verbotener Websites und Anfragen vom RKN zu erkundigen.
Zu Beginn habe ich das AS âRevisorâ mit verglichen. Dieser Vergleich ist durchaus gerechtfertigt, und ein groĂes Netzwerk von Agenten kann von Nutzen sein. Zum Beispiel die Bestimmung der ZugĂ€nglichkeitsqualitĂ€t von Ressourcen verschiedener Provider aus verschiedenen Teilen des Landes. Man kann Verzögerungen berechnen, Grafiken erstellen, alles analysieren und die VerĂ€nderungen sowohl lokal als auch global sehen. Das ist nicht der direkteste Weg, aber Astronomen verwenden ja schlieĂlich âStandardkerzenâ. Warum sollten Agenten nicht verwendet werden? Wenn man ihr Standardverhalten kennt (oder findet), kann man VerĂ€nderungen um sie herum bestimmen und wie sich dies auf die QualitĂ€t der angebotenen Dienstleistungen auswirkt. Zudem muss man die MessgerĂ€te nicht selbst im Netzwerk platzieren, das hat bereits der Roskomnadzor gemacht.
Ein weiterer Punkt, den ich ansprechen möchte, ist, dass jedes Werkzeug eine Waffe sein kann. Das AS âRevisorâ ist ein geschlossenes Netzwerk, aber die Agenten verraten alles, indem sie Anfragen an alle Ressourcen aus der verbotenen Liste senden. Ein solcher Dienst zu erhalten, stellt absolut kein Problem dar. Somit erzĂ€hlen Provider durch die Agenten, ohne es zu wollen, viel mehr ĂŒber ihr Netzwerk, als es vielleicht angebracht wĂ€re: Arten von DPI und DNS, Standort des Agenten (Zentralnode und Dienstnetz?), Netzwerkmarker fĂŒr Verzögerungen und Verluste â und das ist nur das Offensichtliche. So wie jemand die Aktionen der Agenten ĂŒberwachen kann, um die ZugĂ€nglichkeit seiner Ressourcen zu verbessern, kann jemand das auch aus anderen GrĂŒnden tun, und dem gibt es keine Hindernisse. Ein zweischneidiges und sehr vielschichtiges Werkzeug, jeder kann sich davon ĂŒberzeugen.
Quelle: habr.com
