Nie je žiadnym tajomstvom, že kontrolu blokovania na zozname zakázaných informácií v Rusku monitoruje automatizovaný systém „Inšpektor“. Ako to funguje je tu dobre napísané , obrázok z toho istého miesta:
Inštalované priamo u poskytovateľa :
Modul "Agent Inspector" je konštrukčným prvkom automatizovaného systému "Inspector" (AS "Inspector"). Tento systém je určený na monitorovanie dodržiavania požiadaviek na obmedzenie prístupu zo strany telekomunikačných operátorov v rámci ustanovení ustanovených článkami 15.1-15.4 federálneho zákona č. 27-FZ z 2006. júla 149 o informáciách, informačných technológiách a ochrane informácií. “
Hlavným účelom vytvorenia AS „Revizor“ je zabezpečiť monitorovanie dodržiavania požiadaviek telekomunikačných operátorov podľa článkov 15.1-15.4 federálneho zákona z 27. júla 2006 č. 149-FZ „o informáciách, informačných technológiách a informáciách Ochrana“ v zmysle identifikácie faktov o prístupe k zakázaným informáciám a získavania podporných materiálov (údajov) o porušeniach na obmedzenie prístupu k zakázaným informáciám.
Ak vezmeme do úvahy skutočnosť, že ak nie všetci, tak mnohí poskytovatelia nainštalovali toto zariadenie, mala existovať veľká sieť majákov ako napr. a ešte viac, ale s uzavretým prístupom. Maják je však maják na vysielanie signálov všetkými smermi, ale čo keď ich chytíme a uvidíme, čo sme chytili a koľko?
Skôr než budeme počítať, pozrime sa, prečo by to mohlo byť vôbec možné.
Niektoré teórie
Agenti kontrolujú dostupnosť zdroja, a to aj prostredníctvom HTTP(S) požiadaviek, ako je tento:
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"
Okrem užitočného zaťaženia pozostáva požiadavka aj z fázy nadviazania spojenia: výmena SYN и SYN-ACK, a fázy dokončenia pripojenia: FIN-ACK.
Register zakázaných informácií obsahuje niekoľko typov blokovania. Je zrejmé, že ak je zdroj blokovaný IP adresou alebo názvom domény, neuvidíme žiadne požiadavky. Ide o najničivejšie typy blokovania, ktoré vedú k nedostupnosti všetkých zdrojov na jednej IP adrese alebo všetkých informácií na doméne. Existuje aj typ blokovania „podľa adresy URL“. V tomto prípade musí filtrovací systém analyzovať hlavičku požiadavky HTTP, aby presne určil, čo sa má blokovať. A pred ňou, ako je vidieť vyššie, by mala byť fáza nadviazania spojenia, ktorú môžete skúsiť sledovať, pretože ju filter s najväčšou pravdepodobnosťou vynechá.
Ak to chcete urobiť, musíte vybrať vhodnú voľnú doménu s typom blokovania „URL“ a HTTP, aby ste uľahčili prácu systému filtrovania, pokiaľ možno dlho opustenú, aby sa minimalizoval vstup cudzieho prenosu okrem agentov. Ukázalo sa, že táto úloha nie je vôbec náročná, v registri zakázaných informácií je pomerne veľa voľných domén pre každý vkus. Preto bola doména zakúpená a prepojená s IP adresami na spustenom VPS tcpdump a začalo sa počítanie.
Audit "audítorov"
Očakával som, že budem vidieť pravidelné návaly žiadostí, ktoré by podľa môjho názoru naznačovali kontrolovanú akciu. Nedá sa povedať, že by som to vôbec nevidel, ale určite tam nebol jasný obraz:
Čo nie je prekvapujúce, dokonca aj na doméne, ktorú nikto nepotrebuje a na nikdy nepoužívanej IP bude jednoducho kopa nevyžiadaných informácií, taký je moderný internet. Ale našťastie som potreboval iba požiadavky na konkrétnu adresu URL, takže všetky skenery a nástroje na prelomenie hesiel sa rýchlo našli. Na základe množstva podobných žiadostí bolo tiež celkom ľahké pochopiť, kde bola potopa. Ďalej som zostavil frekvenciu výskytu IP adries a ručne som prešiel celý vrchol, pričom som oddelil tých, ktorým to v predchádzajúcich fázach chýbalo. Okrem toho som vystrihol všetky zdroje, ktoré boli odoslané v jednom balíku, už ich nebolo veľa. A toto sa stalo:
Malá lyrická odbočka. O niečo viac ako deň neskôr môj poskytovateľ hostingu poslal list s pomerne zjednodušeným obsahom, v ktorom uviedol, že vaše zariadenia obsahujú zdroj zo zoznamu zakázaných RKN, takže je zablokovaný. Najprv som si myslel, že môj účet je zablokovaný, nebolo to tak. Potom som si myslel, že ma jednoducho varovali pred niečím, o čom som už vedel. Ukázalo sa však, že hostiteľ zapol svoj filter pred mojou doménou a v dôsledku toho som sa dostal pod dvojité filtrovanie: od poskytovateľov a od hostiteľa. Filter prešiel iba koncami požiadaviek: FIN-ACK и RST odrezanie všetkého HTTP na zakázanej adrese URL. Ako môžete vidieť z grafu vyššie, po prvom dni som začal dostávať menej údajov, ale stále som ich dostával, čo bolo celkom dosť na počítanie zdrojov požiadaviek.
Choďte k veci. Podľa môjho názoru sú každý deň jasne viditeľné dva výbuchy, prvý menší, po polnoci moskovského času, druhý bližšie k 6. hodine ráno s chvostom do 12. hodiny. Vrchol nenastáva presne v rovnakom čase. Najprv som chcel vybrať IP adresy, ktoré spadli iba v týchto obdobiach a každú vo všetkých obdobiach, na základe predpokladu, že kontroly agentmi sa vykonávajú pravidelne. Ale po starostlivom preskúmaní som rýchlo objavil obdobia spadajúce do iných intervalov s inými frekvenciami, až do jednej požiadavky každú hodinu. Potom som premýšľal o časových pásmach a že to s nimi možno má niečo spoločné, potom som si myslel, že vo všeobecnosti systém nemusí byť synchronizovaný globálne. Okrem toho bude pravdepodobne hrať úlohu NAT a ten istý Agent môže zadávať požiadavky z rôznych verejných IP adries.
Keďže môj pôvodný cieľ nebol úplne presný, spočítal som všetky adresy, na ktoré som za týždeň narazil a dostal som - 2791. Počet relácií TCP vytvorených z jednej adresy je v priemere 4, s mediánom 2. Najlepšie relácie na adresu: 464, 231, 149, 83, 77. Maximum z 95 % vzorky je 8 relácií na adresu. Medián nie je veľmi vysoký, pripomínam, že graf ukazuje jasnú dennú periodicitu, takže sa dalo očakávať niečo okolo 4 až 8 za 7 dní. Ak vyhodíme všetky relácie, ktoré sa raz vyskytnú, dostaneme medián rovný 5. Ale nemohol som ich vylúčiť na základe jasného kritéria. Naopak, náhodná kontrola ukázala, že súviseli so žiadosťami o zakázaný zdroj.
Adresy sú adresy, ale na internete autonómne systémy - AS, ktoré sa ukázali ako dôležitejšie 1510, v priemere 2 adresy na AS s mediánom 1. Top adresy na AS: 288, 77, 66, 39, 27. Maximum 95 % vzorky sú 4 adresy na AS. Tu sa očakáva medián – jeden agent na poskytovateľa. Očakávame aj vrchol – sú v ňom veľkí hráči. Vo veľkej sieti by sa agenti mali pravdepodobne nachádzať v každom regióne prítomnosti operátora a nezabudnite na NAT. Ak to vezmeme podľa krajín, maximá budú: 1409 - RU, 42 - UA, 23 - CZ, 36 z iných regiónov, nie RIPE NCC. Žiadosti z krajín mimo Ruska priťahujú pozornosť. Pravdepodobne sa to dá vysvetliť chybami geolokácie alebo chybami registrátora pri vypĺňaní údajov. Alebo skutočnosť, že ruská spoločnosť nemusí mať ruské korene, alebo mať zahraničné zastúpenie, pretože je to jednoduchšie, čo je prirodzené pri jednaní so zahraničnou organizáciou RIPE NCC. Niektorá časť je nepochybne zbytočná, ale je spoľahlivo ťažké ju oddeliť, pretože zdroj je blokovaný a od druhého dňa je blokovaný dvakrát a väčšina relácií je len výmena niekoľkých balíkov služieb. Zhodnime sa, že ide o malú časť.
Tieto čísla sa už dajú porovnať s počtom poskytovateľov v Rusku. licencie na „Komunikačné služby na prenos dát, okrem hlasu“ - 6387, ale to je veľmi vysoký odhad zhora, nie všetky tieto licencie sa vzťahujú konkrétne na poskytovateľov internetu, ktorí potrebujú nainštalovať Agenta. V zóne RIPE NCC je v Rusku zaregistrovaný podobný počet AS – 6230, z ktorých nie všetci sú poskytovateľmi. a v roku 3940 získalo 2017 firiem, a to je skôr odhad zhora. V každom prípade máme dvaapolkrát menší počet osvetlených AS. Tu však stojí za to pochopiť, že AS sa striktne nerovná poskytovateľovi. Niektorí poskytovatelia nemajú vlastný AS, niektorí ich majú viac. Ak predpokladáme, že každý má ešte agentov, tak niekto filtruje silnejšie ako ostatní, takže jeho požiadavky sú na nerozoznanie od odpadu, ak sa k nim vôbec dostane. Ale na približné posúdenie je to celkom znesiteľné, aj keď sa mojim prehliadnutím niečo stratilo.
O DPI
Napriek tomu, že môj poskytovateľ hostingu zapol filter už od druhého dňa, na základe informácií z prvého dňa môžeme konštatovať, že blokovanie funguje úspešne. Iba 4 zdroje dokázali prejsť a úplne dokončili relácie HTTP a TCP (ako v príklade vyššie). Ďalších 460 je možné poslať GET, ale relácia je okamžite ukončená RST. dávaj pozor na 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"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#А это попытка исходного узла получить потерю
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"
#Исходный узел понимает что сессия разрушена
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 opakovaných prenosov - závisí aj od toho, čo filter posiela do zdrojového uzla. V každom prípade ide o najspoľahlivejšiu šablónu, z ktorej je zrejmé, že išlo o zakázaný zdroj, ktorý bol vyžiadaný. Navyše vždy existuje odpoveď, ktorá sa objaví v relácii s TTL väčšie ako v predchádzajúcich a nasledujúcich balíkoch.
Zo zvyšku to ani nevidno GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Вот это прислал фильтр
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"
#Вот это прислал фильтр
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"
#Опять фильтр, много раз
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Rozdiel je určite viditeľný TTL ak niečo ide z filtra. Často však 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"
#Прошло несколько секунд без трафика
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
A toto všetko sa opakuje a opakuje a opakuje, ako vidno na grafe, každý deň viackrát.
O IPv6
Dobrou správou je, že existuje. Môžem spoľahlivo povedať, že periodické požiadavky na zakázaný zdroj prichádzajú z 5 rôznych IPv6 adries, čo je presne správanie agentov, ktoré som očakával. Jedna z adries IPv6 navyše nespadá pod filtrovanie a vidím plnú reláciu. Z dvoch ďalších som videl iba jednu nedokončenú reláciu, z ktorej jedna bola prerušená RST z filtra, druhý v poradí. Celková suma 7.
Keďže adries je málo, všetky som si podrobne preštudoval a vyšlo mi, že sú tam len 3 poskytovatelia, možno im zožal veľký potlesk! Iná adresa je cloud hosting v Rusku (nefiltruje), iná je výskumné centrum v Nemecku (je tam filter, kde?). Ale prečo kontrolujú dostupnosť zakázaných zdrojov podľa plánu, je dobrá otázka. Zvyšné dve podali jednu žiadosť a nachádzajú sa mimo Ruska a jedna z nich je filtrovaná (napokon?).
Blokovanie a agenti sú veľkou prekážkou IPv6, ktorej implementácia nenapreduje veľmi rýchlo. Je to smutné. Tí, ktorí tento problém vyriešili, môžu byť na seba plne hrdí.
na záver
Nesnažil som sa o 100% presnosť, prosím, prepáčte mi to, dúfam, že niekto chce túto prácu zopakovať s väčšou presnosťou. Bolo pre mňa dôležité pochopiť, či tento prístup bude v zásade fungovať. Odpoveď je áno. Myslím si, že získané čísla ako prvé priblíženie sú celkom spoľahlivé.
Čo sa ešte dalo urobiť a na čo som bol lenivý, bolo počítať DNS požiadavky. Nie sú filtrované, ale tiež neposkytujú veľkú presnosť, pretože fungujú iba pre doménu a nie pre celú adresu URL. Frekvencia by mala byť viditeľná. Ak to skombinujete s tým, čo je viditeľné priamo v dopytoch, umožní vám to oddeliť nepotrebné a získať viac informácií. Dokonca je možné určiť vývojárov DNS používaných poskytovateľmi a oveľa viac.
Absolútne som nepredpokladal, že by hoster obsahoval aj vlastný filter pre moje VPS. Možno je to bežná prax. Nakoniec RKN pošle hostiteľovi požiadavku na odstránenie zdroja. To ma však neprekvapilo a v niektorých smeroch to dokonca fungovalo v môj prospech. Filter fungoval veľmi efektívne, odrezal všetky správne HTTP požiadavky na zakázanú URL, ale nedostali sa k nim tie správne, ktoré predtým prešli cez filter poskytovateľov, aj keď len vo forme koncoviek: FIN-ACK и RST - mínus za mínus a takmer sa ukázalo, že je to plus. Mimochodom, IPv6 nebol filtrovaný hostiteľom. Samozrejme, že to ovplyvnilo kvalitu zozbieraného materiálu, ale stále to umožňovalo vidieť frekvenciu. Ukázalo sa, že toto je dôležitý bod pri výbere miesta na umiestnenie zdrojov, nezabudnite sa zaujímať o otázku organizácie práce so zoznamom zakázaných stránok a žiadostí od RKN.
Na začiatku som porovnával AS „Inšpektor“ s . Toto porovnanie je celkom opodstatnené a veľká sieť Agentov môže byť prospešná. Napríklad určenie kvality dostupnosti zdrojov od rôznych poskytovateľov v rôznych častiach krajiny. Môžete vypočítať oneskorenia, môžete vytvárať grafy, môžete to všetko analyzovať a vidieť zmeny, ktoré sa vyskytujú lokálne aj globálne. Toto nie je najpriamejší spôsob, ale astronómovia používajú „štandardné sviečky“, prečo nepoužiť agentov? Keď poznáte (po zistení) ich štandardné správanie, môžete určiť zmeny, ktoré sa okolo nich vyskytujú a ako to ovplyvňuje kvalitu poskytovaných služieb. A zároveň nemusíte samostatne umiestňovať sondy do siete, Roskomnadzor ich už nainštaloval.
Ďalším bodom, ktorého sa chcem dotknúť, je, že každý nástroj môže byť zbraňou. AS "Inšpektor" je uzavretá sieť, ale Agenti odovzdajú každého posielaním žiadostí o všetky zdroje zo zoznamu zakázaných. Mať takýto zdroj nepredstavuje vôbec žiadne problémy. Celkovo poskytovatelia prostredníctvom agentov nevedomky povedia o svojej sieti oveľa viac, ako sa pravdepodobne oplatí: typy DPI a DNS, umiestnenie agenta (centrálny uzol a sieť služieb?), sieťové ukazovatele oneskorení a strát – a to je len to najzjavnejšie. Tak ako niekto môže monitorovať činnosť agentov na zlepšenie dostupnosti svojich zdrojov, niekto to môže robiť na iné účely a neexistujú v tom žiadne prekážky. Výsledkom je dvojsečný a veľmi mnohostranný nástroj, ktorý môže vidieť každý.
Zdroj: hab.com