Nie je tajomstvom, že automatizovaný systém „Revisor“ sleduje blokovanie na základe zoznamu zakázaných informácií v Rusku. Ako to funguje, je dobre popísané v tomto , obrázok odtiaľto:
Priamo u poskytovateľa sa inštaluje :
Modul „Agent Revisor“ je štrukturálnym prvkom automatizovaného systému „Revisor“ (AS „Revisor“). Tento systém je navrhnutý na kontrolu dodržiavania požiadaviek, ktoré sú stanovené zákonnými článkami 15.1-15.4 Zákona č. 149-FZ zo 27. júla 2006 „O informáciách, informačných technológiách a o ochrane informácií“ zo strany poskytovateľov služieb.
Hlavným cieľom vytvorenia AS „Revisor“ je zabezpečiť monitorovanie dodržiavania požiadaviek, ktoré sú stanovené článkami 15.1-15.4 Zákona č. 149-FZ zo 27. júla 2006 „O informáciách, informačných technológiách a o ochrane informácií“ v súvislosti s odhaľovaním prípadov prístupu k zakázaným informáciám a získavaním potvrdenia (údajov) o porušeniach obmedzenia prístupu k zakázaným informáciám.
S ohľadom na to, že ak nie všetci, tak mnohí poskytovatelia si toto zariadenie nainštalovali, mala by vzniknúť veľká sieť skúšobných majákov podobná a dokonca viac, ale s uzavretým prístupom. Avšak, maják je maják, aby odosielal signály všade, a čo ak ich chytíme a pozrieme sa, čo sme zachytili a koľko?
Predtým, ako začneme počítať, sa pozrime, prečo to vôbec môže byť možné.
Trochu teórie
Agenti kontrolujú dostupnosť zdroja, a to aj prostredníctvom HTTP(S) požiadaviek, ako je táto naprí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"
Požiadavka, okrem užitočných dát, pozostáva aj z fázy nadviazania spojenia: výmena SYN a SYN-ACK, a fázy ukončenia spojenia: FIN-ACK.
Registrácia zakázaných informácií obsahuje niekoľko typov blokovania. Je zrejmé, že ak bude zdroj blokovaný podľa IP adresy alebo doménového mena, žiadne požiadavky neuvidíme. Tieto typy blokovania sú najdestruktívnejšie a vedú k nedostupnosti všetkých zdrojov na jednej IP adrese alebo všetkých informácií na doméne. Existuje tiež typ blokovania „podľa URL“. V tomto prípade musí systém filtrovania analyzovať HTTP hlavičku požiadavky, aby presne určil, čo blokovať. A predtým, ako sa to stane, ako je vidieť vyššie, musí prebehnúť fáza nadviazania spojenia, ktorú sa pokúsime sledovať, pretože filter ju pravdepodobne nechá prejsť.
Na to je potrebné vybrať vhodnú voľnú doménu s typom blokovania „podľa URL“ a HTTP, aby sa práca systému filtrovania uľahčila, ideálne dávno opustenú, aby sa minimalizovalo pôsobenie cudzích prenosov okrem Agentov. Táto úloha sa ukázala ako úplne jednoduchá, voľných domén v registri zakázaných informácií je dostatok a na akúkoľvek chuť. Preto bola doména zakúpená a priradená k IP adresám na VPS s načítaným tcpdump a začal sa počítať.
Revizia „Revizorov“
Očakával som, že uvidím periodické výkyvy požiadaviek, čo by podľa môjho názoru naznačovalo riadenú činnosť. Nedá sa povedať, že by som to úplne nevidel, ale jasný obraz určite nebol:
Čo nie je prekvapujúce, aj na nikomu nepotrebnú doménu na nikdy nepoužívanej IP bude prichádzať len masívne množstvo nežiaducej informácie, taký je súčasný internet. Ale našťastie, potreboval som len požiadavky na konkrétnu URL, takže všetky skenery a prostriedky na prelomenie hesiel boli rýchlo nájdené. Takisto bolo celkom jednoduché pochopiť, kde dochádza k preťaženiu prostredníctvom hromadných rovnakých požiadaviek. Následne som zostavil frekvencie výskytu IP adries a prešiel som celým topom manuálne, oddelil tých, ktorí prešli na predchádzajúcich krokoch. Navyše som vystrihol všetky zdroje, ktoré poslali len jeden balík, tých bolo už nie veľa. A takto to vyzeralo:
Malé lirycké odbočení. O niečo viac ako deň po tom, čo mi môj poskytovateľ hostingu poslal e-mail dosť obšírneho obsahu, že na vašich výkonoch je zdroj zo zakázaného zoznamu RKN, preto je blokovaný. Najprv som si myslel, že môj účet bol zablokovaný, ale nebolo to tak. Potom som si myslel, že ma len varujú o tom, čo už aj tak viem. Ale ukázalo sa, že hostiteľ aktivoval svoj filter pred mojím doménou a nakoniec som sa dostal pod dvojitú filtráciu: z pohľadu poskytovateľov a zo strany hostiteľa. Filter prepúšťal len konce požiadaviek: FIN-ACK a RST prekrajujúce celý HTTP na zakázanom URL. Ako je vidieť z grafu vyššie, po prvých 24 hodinách som začal dostávať menej údajov, ale stále som ich získaval, čo bolo celkom dosť na úlohu počítania zdrojov požiadaviek.
K veci. Podľa môjho názoru je úplne jasne vidieť dva nárasty každý deň, prvý menší, po polnoci podľa Moskvy, druhý bližšie k 6 ráno s chvostom do 12 na obed. Vrchol nie je presne v rovnakom čase. Najprv som chcel vyčleniť IP adresy, ktoré sa dostali len v týchto periódach a každú v všetkých periódach, vychádzajúc z predpokladu, že kontroly agentmi sa vykonávajú periodicky. Ale pri podrobnom preskúmaní som dosť rýchlo objavil obdobia, ktoré sa dostávali do iných intervalov, s inými frekvenciami, až po jednu požiadavku každú hodinu. Potom som pomyslel na časové pásma a že možno v nich to spočíva, potom som si pomyslel, že systém môže byť celkovo nesynchronizovaný. Okrem toho určite zohrá úlohu NAT a ten istý agent môže robiť požiadavky z rôznych verejných IP.
Keďže môj pôvodný cieľ nebol v presnosti, spočítal som všeobecne všetky adresy, ktoré sa objavili za týždeň a dostal — 2791. Počet TCP relácií vytvorených z jednej adresy v priemere 4, s mediánou 2. Top relácií na adresu: 464, 231, 149, 83, 77. Maximum z 95% vzorky — 8 relácií na adresu. Mediána nie je veľmi vysoká, pripomínam, že z grafu je viditeľná jasná denná periodicita, preto sa dalo očakávať niečo okolo 4 až 8 za 7 dní. Ak vylúčime všetky jednorazovo sa vyskytujúce relácie, dostaneme mediánu rovnu 5. Ale nemohol som ich vylúčiť na základe jasného kritéria. Naopak, výberová kontrola ukázala, že majú vzťah k požiadavkám zakázaného zdroja.
Adresa adrese, ale v internete sú dôležitejšie autonómne systémy — AS, ktorých je stále viac. 1510, v priemere 2 adresy na AS s mediánou 1. Top adresy na AS: 288, 77, 66, 39, 27. Maximálne z 95% vzorky — 4 adresy na AS. Môžeme očakávať, že na jedného providera pripadá jeden agent. Top sú tiež očakávané — sú to veľkí hráči. V rozsiahlej sieti by mali byť agenti asi v každom regióne, kde operátor pôsobí, nezabúdajúc na NAT. Ak sa pozrieme na krajiny, maximá budú: 1409 — RU, 42 — UA, 23 — CZ, 36 z iných regiónov, ktoré nie sú RIPE NCC. Požiadavky mimo Ruska upútajú pozornosť. Možno to možno vysvetliť chybami v geolokácii alebo nesprávnymi údajmi, ktoré uvedli registrátori. Alebo tým, že ruská spoločnosť môže mať nepriamo zahraničné korene, alebo mať zahraničné zastúpenie, pretože to uľahčuje, ak sa jedná o zahraničnú organizáciu RIPE NCC. Určitá časť poškodenia je nepochybne nadbytočná, ale ťažko ju presne oddeliť, pretože je zdroj pod blokádou, a od druhého dňa pod dvojitou blokádou, pričom väčšina relácií predstavuje iba výmenu niekoľkých systémových paketov. Dohodneme sa na tom, že to je malá časť.
Tieto čísla môžeme už porovnávať s počtom providerov v Rusku. je licencií na „Služby prenosu dát, s výnimkou hlasu“ — 6387, ale toto je značne nafúknutá horná hodnota, nie všetky tieto licencie sa týkajú providerov Internetu, ktorým je potrebné nainštalovať agenta. V zóne RIPE NCC je podobný počet AS registrovaných v Rusku — 6230, z ktorých nie všetci sú provideri. a získal 3940 spoločností v roku 2017, a to je skôr horná odhad. V každom prípade máme počet AS, ktoré sa objavili, o 2,5 krát menej. Ale tu je dôležité pochopiť, že AS nie je striktne rovné provideru. Niektorí provideri nemajú svoj vlastný AS, niektorí ich majú viac ako jedno. Ak predpokladáme, že agenti sú predsa len u všetkých, znamená to, že niekto filtruje silnejšie ako ostatní, takže ich požiadavky sú neodlíšiteľné od odpadu, ak vôbec prichádzajú. Ale pre hrubé odhady je to celkom prijateľné, aj keď niečo mohlo byť stratene kvôli mojej nepozornosti.
O DPI
Aj keď môj poskytovateľ hostingu aktivoval svoj filter od druhého dňa, podľa údajov za prvý deň sa dá usúdiť, že blokácie fungujú úspešne. Len 4 zdroje sa dokázali pretlačiť a majú úplne dokončené HTTP a TCP relácie (ako v uvedenom príklade). Ešte 460 môže posielať GET, ale relácia sa okamžite preruší podľa RST. Všimnite si 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 filter
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 o stratu zo zdrojového uzla
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"
#Zdrojový uzol chápe, že relácia je zničená
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Variácie tohto môžu byť rôzne: menej RST alebo viac retransmitov — závisí to aj od toho, čo filter posiela zdrojovému uzlu. V každom prípade je to najdôveryhodnejšia šablóna, z ktorej je jasné, že bola požadovaná presne zakázaná zdroj. Navyše je tu vždy odpoveď, ktorá sa objavuje v relácii s TTL väčšou ako v predchádzajúcich a nasledujúcich paketoch.
Od ostatných nie je vidno ani GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Toto poslal filter
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Alebo 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 filter
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"
#Opäť filter, veľakrát
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Rozdiel je určite viditeľný v TTL keď čokoľvek príde od filtra. Ale často sa nemusí prísť vôbec nič:
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"
...
Alebo takto:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Prešlo niekoľko sekúnd bez prevádzky
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
A všetko sa opakuje a opakuje a opakuje, ako je vidieť na grafe, určite nie raz, každý deň.
O IPv6
Dobrá správa — je tu. Môžem s istotou povedať, že z 5 rôznych adries IPv6 pravidelne prichádzajú požiadavky na zakázaný zdroj, presne tak, ako som očakával od Agentov. Jeden z týchto adries IPv6 sa totiž nepodrobuje filtrácii a vidím plnohodnotnú reláciu. Z ďalších dvoch som videl iba po jednej nedokončenej relácii, z ktorých jedna sa prerušila kvôli RST filtru, druhá kvôli času. Celkovo teda 7.
Keďže adries je málo, podrobne som preskúmal všetky a ukázalo sa, že tam vlastne pôsobia len 3 poskytovatelia, ktorým môžete aplaudovať vstoje! Ďalšia adresa je cloudový hosting v Rusku (nefiltruje), ďalšia — výskumné centrum v Nemecku (existuje filter, kde?). Ale prečo kontrolujú dostupnosť zakázaných zdrojov podľa rozvrhu, to je dobrá otázka. Zvyšné dve urobili po jednej požiadavke a sú mimo hraníc Ruska, pričom jedna z nich je filtrovaná (predsa len na tranzite?).
Blokácie a Agenti sú veľkým brzdením pre IPv6, ktorého zavádzanie už aj tak napreduje pomaly. To je smutné. Tí, ktorí sa tomuto problému venovali v plnej miere, sa môžu právom hrdí.
Na záver
Nehnal som sa za 100% presnosťou, prosím, ospravedlňte ma za to; dúfam, že niekto bude chcieť zopakovať takúto prácu s väčšou presnosťou. Pre mňa bolo dôležité pochopiť, či vlastne bude taký prístup funkčný. Odpoveď — áno, bude. Získané čísla sú v prvom priblížení, myslím, celkom spoľahlivé.
Čo by sa dalo ešte urobiť a čo som lenivý urobiť — spočítať požiadavky na DNS. Tie nie sú filtrované, ale ani neposkytujú veľkú presnosť, pretože fungujú iba pre doménu a nie pre celé URL. Periodicita by mala byť viditeľná. Ak sa to spojí s tým, čo je priamo viditeľné v požiadavkách, mohlo by to oddeliť nadbytočné a získať viac informácií. Možno dokonca určiť vývojárov DNS, ktorých poskytovatelia používajú a mnoho ďalšieho.
Úplne som nečakal, že môj VPS poskytovateľ zapne aj svoj filter. Možno je to bežná prax. Napokon, RKN posiela žiadosť o odstránenie zdroja priamo poskytovateľom. Ale neprekvapilo ma to a v niečom to dokonca prospelo. Filter fungoval veľmi efektívne, odrezával všetky správne HTTP požiadavky na zakázané URL, ale nesprávne, prechádzajúce predtým cez filtre poskytovateľov, dorazili, aspoň iba vo forme koncov: FIN-ACK a RST — mínus na mínus a takmer vznikol plus. Mimochodom, IPv6 hostiteľ nebol filtrovaný. Samozrejme, že to ovplyvnilo kvalitu zozbieraného materiálu, ale aj tak to umožnilo vidieť pravidelnosť. Ukázalo sa, že to je dôležitý aspekt pri výbere platformy na umiestnenie zdrojov, nezabudnite sa pýtať na organizovanie práce so zoznamom zakázaných stránok a požiadavkami od RKN.
Na začiatku som porovnal AS „Revizor“ s . Toto porovnanie je celkom odôvodnené a veľká sieť agentov môže prinášať prospech. Napríklad určenie kvality dostupnosti zdroja z rôznych poskytovateľov z rôznych častí krajiny. Môžete vypočítať oneskorenia, môžete vytvárať grafy, môžete to všetko analyzovať a vidieť zmeny, ktoré sa dejú lokálne aj globálne. Nie je to najpriamšia cesta, ale predsa len používajú astronómovia „štandardné sviečky“, prečo nepoužiť agentov? Poznanie (nájdenie) ich štandardného správania vám môže pomôcť určiť zmeny, ktoré sa dejú okolo nich a ako to ovplyvňuje kvalitu poskytovaných služieb. A pritom nie je potrebné osobne umiestňovať meracie prístroje po sieti, už ich umiestnil Roskomnadzor.
Ešte jeden aspekt, ktorý chcem spomenúť, každý nástroj môže byť zbraňou. AS „Revizor“ je uzavretá sieť, ale agenti odovzdávajú všetkých s potrohmi, posielajúc požiadavky na všetky zdroje zo zakázaného zoznamu. Získať takýto zdroj nepredstavuje vôbec žiadne problémy. Takže poskytovatelia cez agentov, aniž by to chceli, rozprávajú o svojej sieti oveľa viac, než by možno bolo potrebné: typy DPI a DNS, umiestnenie agenta (centrálny uzol a servisná sieť?), sieťové markery oneskorení a strát — a to je len to najzjavnejšie. Rovnako ako niekto môže monitorovať činnosti agentov, aby zlepšil dostupnosť svojich zdrojov, niekto môže robiť to isté za inými účelmi a tomu nič nebráni. Vznikol dvojsečný a veľmi mnohovrstevný nástroj, každý sa o tom môže presvedčiť.
Zdroj: habr.com
