Het is geen geheim dat de geautomatiseerde systeem 'Revisor' toezicht houdt op de blokkeringen van de verboden informatie in Rusland. Hoe dit werkt, is goed beschreven in dit , afbeelding daarvandaan:
Direct bij de provider wordt geïnstalleerd :
De module 'Agent Revisor' is een structureel element van het geautomatiseerde systeem 'Revisor' (AS 'Revisor'). Dit systeem is bedoeld om toezicht te houden op de naleving door de telecomoperators van de vereisten voor het beperken van de toegang in overeenstemming met de bepalingen van artikelen 15.1-15.4 van de Federale wet van 27 juli 2006 nr. 149-FZ "Over informatie, informatietechnologieën en bescherming van informatie".
Het belangrijkste doel van het creëren van AS 'Revisor' is om toezicht te houden op de naleving door telecomoperators van de eisen die zijn vastgesteld in de artikelen 15.1-15.4 van de Federale wet van 27 juli 2006 nr. 149-FZ "Over informatie, informatietechnologieën en bescherming van informatie" met betrekking tot het identificeren van feiten van toegang tot verboden informatie en het verkrijgen van bevestigingsmateriaal (gegevens) over schendingen met betrekking tot de beperking van de toegang tot verboden informatie.
Gezien het feit dat, als niet alle, dan toch veel providers dit apparaat bij zich hebben geïnstalleerd, zou er een groot netwerk van detectoren moeten zijn, vergelijkbaar met en zelfs meer, maar met beperkte toegang. Maar een detector is een detector om signalen in alle richtingen te verzenden, en wat als we ze opvangen en kijken wat we hebben opgevangen en hoeveel?
Voordat we gaan tellen, laten we kijken waarom dit überhaupt mogelijk zou kunnen zijn.
Een beetje theorie
Agents controleren de beschikbaarheid van bronnen, onder andere via HTTP(S) verzoeken, zoals deze bijvoorbeeld:
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"
Het verzoek bestaat, naast de nuttige belasting, ook uit een fase voor het opzetten van de verbinding: de uitwisseling SYN en SYN-ACK, en de fase van het beëindigen van de verbinding: FIN-ACK.
Het register voor verboden informatie bevat verschillende soorten blokkeringen. Het is duidelijk dat als een bron geblokkeerd wordt op IP-adres of domeinnaam, we geen verzoeken zullen zien. Dit zijn de meest destructieve soorten blokkeringen, die leiden tot onbereikbaarheid van alle bronnen op één IP-adres of alle informatie op een domein. Er is ook een type blokkering 'per URL'. In dat geval moet het filtersysteem de HTTP-header van het verzoek analyseren om precies te bepalen wat geblokkeerd moet worden. En daarvoor, zoals hierboven zichtbaar is, moet de verbindingsfase plaatsvinden die we kunnen proberen te volgen, aangezien het filter deze waarschijnlijk zal doorlaten.
Hiervoor moet een geschikte vrije domeinnaam worden gekozen met het type blokkering 'per URL' en HTTP, om het werk van het filtersysteem te vergemakkelijken. Bij voorkeur een lange tijd verlaten domein, om de kans op binnenkomend verkeer, behalve van de agents, te minimaliseren. Deze taak bleek helemaal niet moeilijk te zijn; er zijn genoeg vrije domeinen in het register voor verboden informatie en voor elke smaak. Daarom werd het domein aangeschaft, gekoppeld aan IP-adressen op VPS met een actieve tcpdump en de telling begon.
Inspectie van de 'Inspecteurs'
Ik verwachtte periodieke pieken in verzoeken te zien, wat in mijn ogen zou duiden op een gecontroleerde actie. Ik kan niet zeggen dat ik dit helemaal niet heb gezien, maar er was zeker geen duidelijk beeld:
Wat niet verwonderlijk is; zelfs op een domein dat niemand nodig heeft, zal ook op een nooit gebruikt IP gewoon een massa ongewenste informatie binnenkomen, zo is het moderne Internet. Maar gelukkig had ik alleen de verzoeken voor specifieke URL's nodig, dus alle scanners en wachtwoordkrakers werden snel gevonden. Het was ook vrij eenvoudig om te begrijpen waar de overlast van een massa identieke aanvragen vandaan kwam. Daarna maakte ik frequenties van IP-adressen en ging handmatig door de top, waarbij ik de personen afscheidde die in de eerdere fasen voorbij waren gekomen. Bovendien snouwde ik alle bronnen uit die maar één pakket hadden verzonden; dat waren er al niet veel meer. En dit kreeg ik:
Een kleine lyrische afleiding. Iets meer dan een dag later ontving mijn hostingprovider een vrij omvloerste brief waarin werd verklaard dat er op uw servers een bron uit de verboden lijst van de RKN staat, daarom wordt deze geblokkeerd. In eerste instantie dacht ik dat mijn account was geblokkeerd, maar dat was niet het geval. Toen dacht ik dat ik gewoon gewaarschuwd werd over iets waar ik al van op de hoogte was. Maar het bleek dat de hoster zijn filter vóór mijn domein had ingeschakeld en daardoor viel ik onder dubbele filtering: van zowel de providers als van de hoster. Het filter liet alleen het einde van de verzoeken door. FIN-ACK en RST door het hele HTTP voor de verboden URL te snijden. Zoals te zien is in de bovenstaande grafiek, kreeg ik na de eerste dag minder gegevens, maar ik ontving ze nog steeds, wat voldoende was voor de taak van het tellen van de verzoekbronnen.
Ter zake. Naar mijn mening zijn er duidelijk twee pieken elke dag zichtbaar, de eerste is kleiner, na middernacht in Moskou, de tweede dichter bij 6 uur 's ochtends met een staart tot 12 uur 's middags. De piek valt niet precies op hetzelfde tijdstip. In het begin wilde ik alleen de IP-adressen die in deze periodes vielen en elk in alle periodes выделить, uitgaande van de veronderstelling dat de controles door de Agents periodiek plaatsvinden. Maar bij nader inzien ontdekte ik vrij snel periodes die in andere intervallen vielen, met verschillende frequenties, tot wel één verzoek per uur. Daarna dacht ik na over tijdzones en dat het daar misschien aan ligt, en vervolgens over de mogelijkheid dat het systeem helemaal niet wereldwijd is gesynchroniseerd. Bovendien zal NAT zeker ook een rol spelen, en dezelfde Agent kan verzoeken doen vanuit verschillende publieke IP's.
Aangezien mijn oorspronkelijke doel niet in precisie lag, heb ik uiteindelijk alle adressen geteld die gedurende de week zijn verschenen en kwam ik op — 2791. Het aantal TCP-sessies die zijn opgezet vanuit één adres is gemiddeld 4, met een mediaan van 2. Top sessies op adres: 464, 231, 149, 83, 77. Het maximum uit 95% van de steekproef is 8 sessies per adres. De mediaan is niet erg hoog, ik herinner eraan dat er een duidelijke dagelijkse periodiciteit zichtbaar is in de grafiek, dus het was te verwachten dat het iets rond de 4 tot 8 zou zijn over 7 dagen. Als je alle sessies die één keer zijn voorgekomen, weglaat, krijg je precies een mediaan van 5. Maar ik kon ze niet uitsluiten op een duidelijke basis. Integendeel, steekproefcontroles toonden aan dat ze gerelateerd zijn aan verzoeken voor de verboden bron.
Adressen zijn belangrijk, maar in het internet zijn autonome systemen belangrijker — AS, waarvan er zijn ontstaan. 1510, gemiddeld 2 adressen per AS met een mediaan van 1. Topadressen op AS: 288, 77, 66, 39, 27. Het maximale uit 95% van de steekproef — 4 adressen per AS. De mediaan is ook te verwachten — één agent per provider. De top is ook te verwachten — het zijn grote spelers. In een groot netwerk moeten agents waarschijnlijk in elke regio aanwezig zijn waar de provider actief is, en we vergeten NAT niet. Als we naar landen kijken, zijn de maxima: 1409 — RU, 42 — UA, 23 — CZ, 36 uit andere regio's, niet RIPE NCC. Verzoeken van buiten Rusland trekken de aandacht. Dit kan waarschijnlijk worden verklaard door fouten in geolocatie of fouten van registrars bij het invullen van gegevens. Of doordat een Russisch bedrijf geen Russische wortels heeft, of een buitenlandse vertegenwoordiging heeft omdat dit gemakkelijker is, natuurlijk te maken met de buitenlandse organisatie RIPE NCC. Een deel is ongetwijfeld overbodig, maar het is moeilijk om dit betrouwbaar te scheiden, aangezien de bron onder blokkade staat, en na de tweede dag onder dubbele blokkade, en de meeste sessies slechts bestaan uit het uitwisselen van enkele beheerspakketten. Laten we het erover eens zijn dat dit een klein deel is.
Deze cijfers kunnen nu al worden vergeleken met het aantal providers in Rusland. zijn er 6387 licenties voor "Communicatiediensten voor gegevensoverdracht, met uitzondering van spraak" — maar dit is een overschatting, niet al deze licenties zijn specifiek voor internetproviders die een agent moeten installeren. In het RIPE NCC-gebied is een vergelijkbaar aantal AS geregistreerd in Rusland — 6230, waarvan niet alle providers zijn. en kreeg 3940 bedrijven in 2017, en dit is eerder een overschatting. In ieder geval hebben we een aantal zichtbare AS dat tweeënhalf keer lager is. Maar hier moet begrip zijn dat AS niet strikt gelijk is aan provider. Sommige providers hebben geen eigen AS, sommige hebben er meer dan één. Als we aannemen dat agents toch bij iedereen aanwezig zijn, betekent dit dat iemand strenger filtert dan anderen, zodat hun verzoeken niet te onderscheiden zijn van rommel als ze überhaupt aankomen. Maar voor een ruwe schatting is het tamelijk acceptabel, zelfs als er iets verloren is gegaan door mijn fout.
Over DPI
Hoewel mijn hostingprovider zijn filter vanaf de tweede dag heeft ingeschakeld, blijkt uit de gegevens van de eerste dag dat de blokkades succesvol zijn. Slechts 4 bronnen konden doorgelaten worden en hebben volledig afgeronde HTTP- en TCP-sessies (zoals hierboven in het voorbeeld). Nog eens 460 kunnen versturen GET, maar de sessie wordt onmiddellijk onderbroken door RST. Let op 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"
#Dit is wat het filter verzond
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#En dit is de poging van de oorsprongnode om het verlies te verkrijgen
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"
#De oorsprongnode begrijpt dat de sessie is verbroken
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Variaties hiervan kunnen verschillen: minder RST of meer retransmissies — dit hangt ook af van wat het filter naar de oorsprongnode stuurt. Hoe dan ook, dit is het meest betrouwbare patroon, waaruit blijkt dat specifiek het verboden bron werd aangevraagd. Bovendien is er altijd een antwoord dat verschijnt in de sessie met TTL meer dan in de voorafgaande en volgende pakketten.
Van de anderen zie je zelfs niet GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Dit is wat het filter verzond
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Of zo:
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"
#Dit is wat het filter verzond
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"
#Weer het filter, meerdere keren
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Er is altijd een verschil waarneembaar in TTL als er iets van het filter komt. Maar vaak kan er zelfs helemaal niets binnenkomen:
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"
...
Of zo:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Er zijn enkele seconden zonder verkeer verstreken
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
En dit herhaalt zich steeds maar weer, zoals duidelijk op de grafiek te zien is, en dat niet slechts één keer, elke dag.
Over IPv6
Goed nieuws — hij is er. Ik kan met zekerheid zeggen dat er periodieke verzoeken vanaf 5 verschillende IPv6-adressen naar de verboden bron plaatsvinden, precies het gedrag van de Agents dat ik verwachtte. Bovendien valt een van de IPv6-adressen niet onder de filtering en zie ik een volledige sessie. Van de andere twee zag ik telkens maar één onafgebroken sessie, waarvan één werd onderbroken door RST de filter, de andere door tijd. In totaal dus 7.
Aangezien er maar weinig adressen zijn, heb ik ze allemaal grondig onderzocht en het bleek dat er in feite maar 3 providers zijn, waarvoor je staande zou moeten applaudisseren! Een ander adres is cloudhosting in Rusland (filtert niet), de andere is een onderzoekscentrum in Duitsland (er is een filter, waar?). Maar waarom ze gepland controleren op de beschikbaarheid van verboden bronnen is een goede vraag. De overige twee deden elk één verzoek en bevinden zich niet binnen de grenzen van Rusland, bovendien wordt één van hen gefilterd (toch tijdens de transitie?).
Blokkades en Agents zijn een grote rem voor IPv6, waarvan de implementatie al niet erg snel verloopt. Dat is triest. Degenen die deze taak volledig hebben opgelost, kunnen trots op zichzelf zijn.
Ter conclusie
Ik heb niet gestreefd naar 100% nauwkeurigheid, ik vraag om verontschuldiging hiervoor, hopelijk wil iemand deze taak met meer zorgvuldigheid herhalen. Voor mij was het belangrijk te begrijpen of deze aanpak überhaupt zou werken. Het antwoord is — ja. De verkregen cijfers zijn in eerste aanleg, ik denk dat ze behoorlijk betrouwbaar zijn.
Wat zou je nog meer kunnen doen en wat ik lui was om te doen — het tellen van verzoeken naar DNS. Ze worden niet gefilterd, maar geven ook niet veel nauwkeurigheid omdat ze alleen voor het domein werken en niet voor de volledige URL. De periodiciteit moet zichtbaar zijn. Als je dit combineert met wat direct in de verzoeken zichtbaar is, kan dit helpen om het onnodige te scheiden en meer informatie te verkrijgen. Misschien zelfs de DNS-ontwikkelaars die door de providers worden gebruikt bepalen en nog veel meer.
Ik had absoluut niet verwacht dat mijn VPS-provider ook zijn eigen filter zou inschakelen. Misschien is dit gebruikelijk. Uiteindelijk stuurt de RKN een verzoek om de bron te verwijderen naar de hoster. Maar het verraste me niet en kwam zelfs ergens van pas. Het filter werkte zeer effectief door alle correcte HTTP-verzoeken naar de verboden URL te blokkeren, maar niet-correcte verzoeken, die hiervoor door de providerfilters kwamen, kwamen toch door, zij het alleen als eindpunten: FIN-ACK en RST — min van min en bijna een plus. Overigens werd IPv6 door de hoster niet gefilterd. Natuurlijk heeft dit invloed gehad op de kwaliteit van het verzamelde materiaal, maar het bood toch de mogelijkheid om de periodiciteit te observeren. Dit bleek een belangrijk punt te zijn bij het kiezen van een platform voor het hosten van middelen; laat het niet na om informatie in te winnen over hoe om te gaan met de lijst van verboden websites en verzoeken van de RKN.
Aan het begin vergeleek ik AS "Revizor" met . Deze vergelijking is volkomen gerechtvaardigd en een groot netwerk van Agenten kan nuttig zijn. Bijvoorbeeld, het bepalen van de kwaliteit van beschikbaarheid van een resource vanuit verschillende providers in verschillende delen van het land. Vertragingen kunnen worden berekend, grafieken kunnen worden getekend, en dit alles kan worden geanalyseerd om veranderingen zowel lokaal als globaal te zien. Dit is niet de meest directe weg, maar astronomen gebruiken toch 'standaard kaarsen', waarom niet de Agenten? Door hun standaardgedrag te kennen (of te vinden), kan men veranderingen rondom hen bepalen en hoe dit invloed heeft op de kwaliteit van de geleverde diensten. En daarbij is het niet nodig om zelf meetinstrumenten in het netwerk te plaatsen, die zijn al geïnstalleerd door de Roskomnadzor.
Een ander punt dat ik wil aanraken, is dat elk instrument een wapen kan zijn. AS "Revizor" is een gesloten netwerk, maar de Agenten onthullen alles door verzoeken naar alle middelen op de verboden lijst te sturen. Het verkrijgen van zo'n resource vormt totaal geen probleem. Kortom, providers vertellen via Agenten, zonder het te willen, veel meer over hun netwerk dan ze misschien zouden moeten: soorten DPI en DNS, locatie van de Agent (centraal knooppunt en dienstnetwerk?), netwerkm momenten van vertragingen en verliezen — en dit is slechts het meest voor de hand liggende. Net zoals iemand de acties van Agenten kan monitoren om de beschikbaarheid van zijn middelen te verbeteren, kan iemand dit ook voor andere doeleinden doen en daar zijn geen obstakels voor. Het is een dubbelzijdig en zeer complex instrument geworden, waar iedereen zelf van kan overtuigen.
Bron: habr.com
