Není žádným tajemstvím, že kontrolu blokací na základě seznamu zakázaných informací v Rusku sleduje automatizovaný systém „Revisor“. Jak to funguje je dobře popsáno v tomto , obrázek také odtud:
Přímo u poskytovatele je nainstalován :
Modul „Agent Revisor“ je strukturálním prvkem automatizovaného systému „Revisor“ (AS „Revisor“). Tento systém je určen pro kontrolu dodržování požadavků poskytovatelů komunikací na omezení přístupu v rámci ustanovení dle článků 15.1-15.4 Federálního zákona ze dne 27. července 2006 č. 149-FZ „O informacích, informačních technologiích a ochraně informací“.
Hlavním cílem vytvoření AS „Revisor“ je zajistit monitorování dodržování požadavků, které stanoví články 15.1-15.4 Federálního zákona ze dne 27. července 2006 č. 149-FZ „O informacích, informačních technologiích a ochraně informací“ ve vztahu k odhalování případů přístupu k zakázaným informacím a získání potvrzujících materiálů (údajů) o porušení omezení přístupu k zakázaným informacím.
S přihlédnutím k tomu, že, i když ne všichni, tak mnozí poskytovatelé nainstalovali toto zařízení u sebe, měla vzniknout velká síť testerů-majáků podobně jako a dokonce více, ale s uzavřeným přístupem. Nicméně, maják je maják, aby posílal signály všemi směry, a co když je zachytíme a podíváme se, co jsme zachytili a kolik?
Než začneme počítat, podívejme se, proč to vůbec může být možné.
Trochu teorie
Agenti kontrolují dostupnost zdroje, včetně prostřednictvím HTTP(S) požadavků, jako je tento například:
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"
Žádost kromě užitečné zátěže, obsahuje také fázi ustanovení spojení: výměnu SYN a SYN-ACK, a fázi ukončení spojení: FIN-ACK.
Rejstřík zakázaných informací obsahuje několik typů blokací. Je zřejmé, že pokud bude zdroj blokován podle IP adresy nebo doménového jména, žádné dotazy neuvidíme. To jsou nejničivější typy blokací, které vedou k nedostupnosti všech zdrojů na jedné IP adrese nebo všech informací na doméně. Existuje také typ blokace „podle URL“. V tomto případě musí systém filtrování analyzovat HTTP hlavičku požadavku, aby přesně určil, co blokovat. A předtím musí proběhnout fáze navazování spojení, kterou lze sledovat, protože filtr ji pravděpodobně propustí.
K tomu je třeba vybrat vhodnou volnou doménu s typem blokace „podle URL“ a HTTP, aby se usnadnila práce systému filtrování; ideálně dlouho opuštěnou, aby se minimalizovalo přicházení cizího provozu kromě Agenti. Tato úloha se ukázala jako vůbec nekomplikovaná, volných domén v rejstříku zakázaných informací je dostatek a pro každou chuť. Proto byla doména zakoupena, připojena k IP adresám na VPS s běžícím tcpdump a začalo se s počítáním.
Revize „Revizorů“
Očekával jsem, že uvidím periodické výkyvy požadavků, což by podle mého názoru naznačovalo řízenou akci. Není možné říci, že jsem to zcela neviděl, ale jasný obraz rozhodně chyběl:
Což není překvapující, i na nikým nepotřebovanou doménu na nikdy nepoužívané IP bude proudit spousta nevyžádaných informací, takový je moderní Internet. Ale naštěstí jsem potřeboval pouze dotazy konkrétního URL, takže všechny skenery a prolézače hesel byly rychle nalezeny. Také bylo poměrně snadné pochopit, kde je příval spousty stejného typu dotazů. Pak jsem sestavil frekvence výskytu IP adres a prošel jsem celé top ručně oddělující ty, kteří prošli na předchozích etapách. Dodatkově jsem vyřadil všechny zdroje, které poslaly jeden balíček, těch už bylo málo. A vzniklo toto:
Malé lyrické odbočení. O něco více než den poté mi poskytovatel hostingu poslal e-mail docela obsažného znění, že na vašich serverech je zdroj z zakázaného seznamu RKN, proto je blokován. Nejdříve jsem si myslel, že mi zablokovali účet, což se ukázalo jako nepravda. Poté jsem si myslel, že mě pouze varují o tom, co již dávno vím. Ale ukázalo se, že hosting přešel na svůj filtr před mým doménou a nakonec jsem se dostal pod dvojitou filtraci: ze strany poskytovatelů a ze strany hostingu. Filtr propouštěl pouze konce dotazů: FIN-ACK a RST ořezávající celý HTTP podle zakázaného URL. Jak je vidět z výše uvedeného grafu, po prvních 24 hodinách jsem začal dostávat méně dat, ale přesto jsem je dostával, čehož bylo dost na úkol spočítat zdroje dotazů.
K věci. Podle mého názoru je naprosto jasně vidět dva výkyvy každý den, první menší, po půlnoci podle Moskvy, druhý blíže k 6 hodině ráno s ocasem až do 12 hodin odpoledne. Špička se přesně neshoduje s stejným časem. Původně jsem chtěl vymezit IP adresy, které spadly jen do těchto období a každou do všech období, vycházeje z předpokladu, že kontroly agentů se provádějí pravidelně. Ale při podrobném pohledu jsem dost rychle zjistil, že existují období spadající do jiných intervalů s jinými frekvencemi, až po jeden dotaz každou hodinu. Poté jsem přemýšlel o časových pásmech a co když je to v tom, pak mě napadlo, že systém nemusí být vůbec globálně synchronizován. Kromě toho určitě sehrálo svou roli NAT a stejný agent může provádět dotazy z různých veřejných IP.
Jelikož mým původním cílem nebyla přesnost, spočítal jsem všechny adresy, které se objevily během týdne, a dostal jsem — 2791. Počet TCP relací vytvořených z jedné adresy je v průměru 4, s mediánou 2. Nejvíce relací na adresu: 464, 231, 149, 83, 77. Maximálně z 95% vzorku — 8 relací na adresu. Mediána není příliš vysoká, připomínám, že podle grafu je vidět jasná denní periodicita, takže bylo možné očekávat něco kolem 4 až 8 za 7 dní. Pokud vyřadíme všechny jednoznačně se vyskytující relace, dostaneme mediánu rovnající se 5. Ale nebyl jsem schopen je vyloučit podle jasného kritéria. Naopak, výběrová kontrola ukázala, že mají souvislost s dotazy zakázaného zdroje.
Adresa je adresa, ale v internetu jsou důležitější autonomní systémy — AS, jejichž počet vyšel 1510, v průměru 2 adresy na AS s mediánou 1. Top adresy na AS: 288, 77, 66, 39, 27. Maximum z 95% vzorku — 4 adresy na AS. Zde se očekává medián — jeden agent na poskytovatele. Top také očekávaný — zahrnuje velké hráče. V rozsáhlé síti by měli agenti být pravděpodobně v každém regionu přítomnosti operátora, nezapomínejme ani na NAT. Pokud bereme dle zemí, maximální počty budou: 1409 — RU, 42 — UA, 23 — CZ, 36 z jiných regionů, ne RIPE NCC. Dotazy ne z Ruska upoutávají pozornost. Pravděpodobně to lze vysvětlit chybami geolokace nebo chybami registrátorů při vyplňování údajů. Nebo tím, že ruská společnost může mít neruské kořeny, nebo mít zahraniční zastoupení, protože je to jednodušší, pokud se jedná o zahraniční organizaci RIPE NCC. Určitá část je bezpochyby nadbytečná, ale oddělit ji spolehlivě je složité, protože je zdroj pod blokací, a od druhého dne pod dvojitou blokací a většina sezení představuje pouze výměnu několika servisních paketů. Domluvme se, že to je malá část.
Tato čísla už lze porovnávat s počtem poskytovatelů v Rusku. licencí na „Služby komunikace pro přenos dat, s výjimkou hlasu“ — 6387, ale to je značně nadhodnocený údaj, ne všechny tyto licence se týkají právě poskytovatelů internetu, kteří musí mít agenta. V zóně RIPE NCC je podobný počet AS registrovaných v Rusku — 6230, z nichž ne všichni jsou poskytovatelé. a získalo 3940 společností v roce 2017, a to je spíše nadhodnocení. V každém případě máme číslo osvědčených AS o dvě a půl méně. Ale zde je třeba chápat, že AS není striktně rovno poskytovateli. Někteří poskytovatelé nemají svou AS, někteří jich mají více než jednu. Pokud předpokládáme, že agenti skutečně jsou u všech, znamená to, že někdo filtruje silněji než ostatní, takže jejich dotazy jsou nerozeznatelné od odpadu, pokud vůbec dojdou. Ale pro hrubé odhady je to docela přijatelná, i když něco bylo ztraceno kvůli mé chybě.
O DPI
I když můj hostingový provider aktivoval svůj filtr už od druhého dne, z údajů za první den lze usoudit, že blokace fungují úspěšně. Jen 4 zdroje se dokázaly dostat skrze a mají kompletně ukončené HTTP a TCP relace (jak je uvedeno ve výše uvedeném příkladu). Dalších 460 může posílat GET, ale relace se okamžitě přeruší podle RST. Všimněte si prosím 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"
#Toto poslal filtr
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#A toto je pokus výchozího uzlu získat ztrátu
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"
#Výchozí uzel chápe, že relace byla zničena
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Variace toho mohou být různé: méně RST nebo více retransmisí — záleží také na tom, co filtr posílá výchozímu uzlu. V každém případě je to nejspolehlivější vzor, ze kterého je jasné, že byl požadován přesně zakázaný zdroj. Kromě toho existuje vždy odezva, která se objevuje v relaci s TTL větší než v předchozích a následujících paketech.
Z ostatních není vidět ani GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Toto poslal filtr
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Nebo takto:
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"
#Toto poslal filtr
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"
#Znovu filtr, mnohokrát
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Rozdíl je vždy vidět v TTL pokud něco přiletí od filtru. Ale často se může stát, že vůbec nic nepřijde:
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"
...
Nebo takto:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Uběhlo několik sekund bez provozu
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
A to vše se opakuje a opakuje, jak je vidět na grafu, rozhodně ne jednou, každé 24 hodin.
O IPv6
Dobrá zpráva – je tady. Mohu s jistotou říci, že z 5 různých IPv6 adres občas dochází k žádostem o zakázaný zdroj, přesně takové chování agentů, jaké jsem očekával. Navíc jedna z IPv6 adres neprochází filtrováním a vidím plnohodnotnou relaci. Z dalších dvou jsem zaznamenal pouze jednu nedokončenou relaci, z nichž jedna byla přerušena podle RST filtru, druhá podle času. Celkem tedy 7.
Jelikož adres není mnoho, podrobně jsem je všechny prostudoval a ukázalo se, že tam jsou vlastně pouze 3 poskytovatelé, jimž lze tleskat vestoje! Další adresa je cloudové hostování v Rusku (nefiltruje), další je výzkumné centrum v Německu (existuje filtr, kde?). Otázka, proč kontrolují podle plánu dostupnost zakázaných zdrojů, je dobrá. Zbývající dvě udělaly po jedné žádosti a nacházejí se mimo Rusko, přičemž jedna z nich je filtrovaná (zejména na tranzitu?).
Blokace a agenti jsou velkou překážkou pro IPv6, jehož zavádění už i tak probíhá pomalu. To je smutné. Ti, kteří tuto úlohu vyřešili v plném rozsahu, si mohou být hrdí.
Na závěr
Nehnal jsem se za 100% přesností, prosím, odpusťte mi to, doufám, že někdo bude chtít opakovat tuto práci s větší precizností. Pro mě bylo důležité pochopit, zda tento přístup bude vůbec fungovat. Odpověď – bude. Získaná čísla v prvním přiblížení, myslím, že jsou celkem spolehlivá.
Co by se ještě dalo udělat a co jsem byl příliš lenivý udělat – spočítat požadavky na DNS. Ty nejsou filtrované, ale také nenabízejí velkou přesnost, protože fungují pouze pro doménu, nikoli pro celé URL. Periodičnost by měla být vidět. Pokud by se spojilo to, co je přímo vidět v žádostech, to by umožnilo oddělit nadbytečné a získat více informací. Možná dokonce určit vývojáře DNS používané poskytovateli a mnoho dalšího.
Úplně jsem nečekal, že mi poskytovatel VPS přidá i vlastní filtr. Možná je to běžná praxe. Koneckonců, RKN posílá žádost o odstranění zdroje právě poskytovateli. Ale to mě ani nepřekvapilo a dokonce se to někde vyplatilo. Filtr fungoval velmi efektivně a odřízl všechny správné HTTP požadavky na zakázané URL, ale nesprávné, které předtím prošly filtrem poskytovatelů, dorazily, ačkoli pouze ve formě koncovek: FIN-ACK a RST — minus na minus a téměř vznikl plus. Mimochodem, IPv6 poskytovatel nebyl filtrován. To samozřejmě ovlivnilo kvalitu shromážděného materiálu, ale přesto poskytlo možnost vidět periodičnost. Ukázalo se, že je to důležitý faktor při výběru platformy pro umístění zdrojů, nezapomeňte se zajímat o otázku organizace práce se seznamem zakázaných stránek a žádostmi od RKN.
Na začátku jsem porovnal AS „Revizor“ s . Toto srovnání je zcela oprávněné a velká síť agentů může být prospěšná. Například určení kvality dostupnosti zdroje z různých poskytovatelů v různých částech země. Můžete spočítat zpoždění, můžete vytvářet grafy, můžete to všechno analyzovat a vidět změny, které se odehrávají jak lokálně, tak globálně. Není to nejpřímější cesta, ale astronomové přece používají „standardní svíčky“, proč by neměli používat agenty? Znáte (našli) jejich standardní chování, můžete určovat změny, které se kolem nich dějí, a jak to ovlivňuje kvalitu poskytovaných služeb. A přitom není nutné si sami rozmisťovat měřidla po síti, ta už byla nastavena Roskomnadzorem.
Další téma, které chci zmínit, je, že každý nástroj může být zbraní. AS „Revizor“ je uzavřená síť, ale agenti odhalují všechny s důvody posíláním požadavků na všechny zdroje ze zakázaného seznamu. Získat takový zdroj není vůbec žádným problémem. Takže, poskytovatelé skrze agenty, aniž by to chtěli, sdělují o své síti mnohem více, než by bylo vhodné: typy DPI a DNS, umístění agenta (centrálního uzlu a pomocné sítě?), síťové markery pro zpoždění a ztráty — a to je jen to nejvíce očividné. Stejně jako někdo může sledovat činnost agentů ke zlepšení dostupnosti svých zdrojů, někdo může dělat to samé k jiným účelům, a tomu žádné překážky nejsou. Vznikl oboustranně ostře vyprofilovaný a velmi mnohostranný nástroj, každý se o tom může přesvědčit.
Zdroj: habr.com
