Není žádným tajemstvím, že kontrola blokování na seznamu zakázaných informací v Rusku je monitorována automatizovaným systémem „Inspektor“. Jak to funguje je zde dobře napsáno , obrázek ze stejného místa:
Instalováno přímo od poskytovatele :
Modul "Agent Inspector" je konstrukčním prvkem automatizovaného systému "Inspector" (AS "Inspector"). Tento systém je navržen tak, aby sledoval, jak telekomunikační operátoři dodržují požadavky na omezení přístupu v rámci ustanovení stanovených v článcích 15.1-15.4 federálního zákona č. 27-FZ ze dne 2006. července 149 „o informacích, informačních technologiích a ochraně informací. “
Hlavním účelem vytvoření AS „Revizor“ je zajistit sledování souladu telekomunikačních operátorů s požadavky stanovenými č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 informacích Ochrana“ ve smyslu zjišťování faktů o přístupu k zakázaným informacím a získávání podpůrných materiálů (údajů) o porušení za účelem omezení přístupu k zakázaným informacím.
Vezmeme-li v úvahu skutečnost, že pokud ne všichni, tak mnoho poskytovatelů nainstalovalo toto zařízení, měla existovat velká síť majákových sond, jako je a ještě více, ale s uzavřeným přístupem. Avšak maják je maják, který vysílá signály do všech směrů, ale co když je chytíme a uvidíme, co jsme chytili a kolik?
Než budeme počítat, podívejme se, proč je to vůbec možné.
Některé teorie
Agenti kontrolují dostupnost zdroje, a to i prostřednictvím požadavků HTTP(S), jako 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"
Kromě užitečného zatížení se požadavek skládá také z fáze navázání spojení: výměna SYN и SYN-ACKa fáze dokončení připojení: FIN-ACK.
Registr zakázaných informací obsahuje několik typů blokování. Je zřejmé, že pokud je zdroj blokován IP adresou nebo názvem domény, neuvidíme žádné požadavky. Jedná se o nejničivější typy blokování, které vedou k nedostupnosti všech zdrojů na jedné IP adrese nebo všech informací na doméně. Existuje také typ blokování „podle URL“. V tomto případě musí filtrovací systém analyzovat hlavičku požadavku HTTP, aby přesně určil, co má blokovat. A před tím, jak je vidět výše, by měla proběhnout fáze navázání spojení, kterou můžete zkusit sledovat, protože ji filtr s největší pravděpodobností vynechá.
Chcete-li to provést, musíte vybrat vhodnou volnou doménu s typem blokování „URL“ a HTTP, abyste usnadnili práci systému filtrování, nejlépe dlouho opuštěnou, aby se minimalizoval vstup cizího provozu s výjimkou agentů. Ukázalo se, že tento úkol není vůbec obtížný, v registru zakázaných informací je poměrně hodně volných domén pro každý vkus. Proto byla doména zakoupena a propojena s IP adresami na běžícím VPS tcpdump a začalo počítání.
Audit "Auditorů"
Očekával jsem, že uvidím pravidelné návaly žádostí, které by podle mého názoru naznačovaly řízenou akci. Nedá se říct, že bych to vůbec neviděl, ale jasný obrázek tam rozhodně nebyl:
Což není překvapivé, i na doméně, kterou nikdo nepotřebuje a na nikdy nepoužívané IP prostě bude tuna nevyžádaných informací, takový je moderní internet. Ale naštěstí jsem potřeboval pouze požadavky na konkrétní URL, takže všechny skenery a crackery byly rychle nalezeny. Na základě množství podobných žádostí bylo také docela snadné pochopit, kde se potopa vzala. Dále jsem sestavil četnost výskytu IP adres a prošel celý vrchol ručně, přičemž jsem oddělil ty, kteří to v předchozích fázích minuli. Navíc jsem vyškrtl všechny zdroje, které byly zaslány v jednom balíku, už jich nebylo mnoho. A stalo se toto:
Malá lyrická odbočka. O něco více než den později mi můj poskytovatel hostingu poslal dopis s poměrně zjednodušeným obsahem, že vaše zařízení obsahují zdroj ze seznamu zakázaných RKN, takže je blokován. Nejprve jsem si myslel, že můj účet je zablokován, nebylo tomu tak. Pak jsem si myslel, že mě prostě varují před něčím, o čem už vím. Ukázalo se ale, že hostitel zapnul svůj filtr před mou doménou a v důsledku toho jsem se dostal pod dvojí filtrování: od poskytovatelů a od hostitele. Filtr prošel pouze konci požadavků: FIN-ACK и RST odříznout veškerý HTTP na zakázané adrese URL. Jak můžete vidět z grafu výše, po prvním dni jsem začal dostávat méně dat, ale stále jsem je dostával, což bylo docela dost pro úkol počítat zdroje požadavků.
Dostat se k věci. Podle mého názoru jsou každý den jasně vidět dva výbuchy, první menší, po půlnoci moskevského času, druhý blíže k 6 hodině ranní s ocasem do 12 hodin. Vrchol nenastává přesně ve stejnou dobu. Nejprve jsem chtěl vybrat IP adresy, které padly pouze v těchto obdobích a každou ve všech obdobích, na základě předpokladu, že kontroly agenty jsou prováděny pravidelně. Ale po pečlivém přezkoumání jsem rychle objevil periody spadající do jiných intervalů s jinými frekvencemi, až jeden požadavek každou hodinu. Pak jsem přemýšlel o časových pásmech a že to s nimi možná má něco společného, pak jsem si řekl, že obecně systém nemusí být synchronizován globálně. Kromě toho bude pravděpodobně hrát roli NAT a stejný Agent může zadávat požadavky z různých veřejných IP.
Protože můj původní cíl nebyl přesně, spočítal jsem všechny adresy, na které jsem za týden narazil a dostal jsem - 2791. Počet relací TCP vytvořených z jedné adresy je v průměru 4, s mediánem 2. Nejlepší relace na adresu: 464, 231, 149, 83, 77. Maximum z 95 % vzorku je 8 relací na adresu. Medián není moc vysoký, připomínám, že graf ukazuje jasnou denní periodicitu, takže se dalo čekat něco kolem 4 až 8 za 7 dní. Pokud vyhodíme všechny sezení, které se vyskytují jednou, dostaneme medián rovný 5., ale nemohl jsem je vyloučit na základě jasného kritéria. Naopak náhodná kontrola ukázala, že se týkaly žádostí o zakázaný zdroj.
Adresy jsou adresy, ale na internetu autonomní systémy - AS, které se ukázaly být důležitější 1510, v průměru 2 adresy na AS s mediánem 1. Top adresy na AS: 288, 77, 66, 39, 27. Maximum 95 % vzorku jsou 4 adresy na AS. Zde se očekává medián - jeden agent na poskytovatele. Očekáváme také top - jsou v něm velcí hráči. Ve velké síti by agenti měli být pravděpodobně umístěni v každé oblasti přítomnosti operátora a nezapomeňte na NAT. Pokud to vezmeme podle země, maxima bude: 1409 - RU, 42 - UA, 23 - CZ, 36 z jiných regionů, nikoli zralé NCC. Žádosti zvenčí Rusko přitahují pozornost. To lze pravděpodobně vysvětlit chybami geolokace nebo chybami registrátora při vyplňování dat. Nebo skutečnost, že ruská společnost nemusí mít ruské kořeny nebo mít zahraniční zastoupení, protože je to jednodušší, což je přirozené při jednání se zahraniční organizací RIPE NCC. Některá část je nepochybně nadbytečná, ale je spolehlivě obtížné ji oddělit, protože zdroj je blokován a od druhého dne je blokován dvojitě a většina relací je jen výměna několika servisních paketů. Souhlasíme s tím, že se jedná o malou část.
Tato čísla lze již srovnat s počtem poskytovatelů v Rusku. licence pro „Komunikační služby pro přenos dat, kromě hlasu“ - 6387, ale to je velmi vysoký odhad shora, ne všechny tyto licence se vztahují konkrétně na poskytovatele internetu, kteří potřebují nainstalovat Agenta. V zóně RIPE NCC je v Rusku registrován podobný počet AS – 6230, z nichž ne všichni jsou poskytovatelé. a v roce 3940 obdrželo 2017 firem, a to je spíše odhad shora. V každém případě máme dvaapůlkrát menší počet osvětlených AS. Zde však stojí za to pochopit, že AS se striktně nerovná poskytovateli. Někteří poskytovatelé nemají vlastní AS, někteří jich mají více. Pokud předpokládáme, že všichni stále mají Agenty, pak někdo filtruje silněji než ostatní, takže jeho požadavky jsou k nerozeznání od smetí, pokud se k nim vůbec dostane. Ale pro hrubé posouzení je to celkem snesitelné, i když se mým nedopatřením něco ztratilo.
O DPI
I přesto, že můj poskytovatel hostingu zapnul svůj filtr již od druhého dne, na základě informací z prvního dne můžeme konstatovat, že blokování funguje úspěšně. Pouze 4 zdroje dokázaly projít a kompletně dokončily relace HTTP a TCP (jako v příkladu výše). Dalších 460 lze poslat GET, ale relace je okamžitě ukončena RST. Dávejte 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"
Variace tohoto mohou být různé: méně RST nebo více retransmitů - záleží také na tom, co filtr posílá do zdrojového uzlu. V každém případě se jedná o nejspolehlivější šablonu, ze které je zřejmé, že se jednalo o zakázaný zdroj, který byl požadován. Navíc vždy existuje odpověď, která se objeví v relaci s TTL větší než v předchozích a následujících balíčcích.
Ze zbytku to ani nejde vidět 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"
Nebo tak:
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"
...
Rozdíl je určitě vidět TTL jestli něco jde z filtru. Ale často nemusí přijít vůbec nic:
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 tak:
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 to vše se opakuje a opakuje a opakuje, jak je vidět na grafu, nejednou, každý den.
O IPv6
Dobrá zpráva je, že existuje. Spolehlivě mohu říci, že k periodickým požadavkům na zakázaný zdroj dochází z 5 různých IPv6 adres, což je přesně chování Agentů, které jsem očekával. Navíc jedna z IPv6 adres nespadá pod filtrování a vidím plnou relaci. Ze dvou dalších jsem viděl pouze jednu nedokončenou relaci, z nichž jedna byla přerušena RST z filtru, podruhé v pořadí. Celková částka 7.
Jelikož je adres málo, všechny jsem si je podrobně prostudoval a ukázalo se, že jsou tam jen 3 poskytovatelé, lze jim sklidit ovace! Jiná adresa je cloud hosting v Rusku (nefiltruje), jiná je výzkumné centrum v Německu (je tam filtr, kde?). Ale proč kontrolují dostupnost zakázaných zdrojů podle plánu, je dobrá otázka. Zbývající dva podali jeden požadavek a nacházejí se mimo Rusko a jeden z nich je filtrován (koneckonců v tranzitu?).
Blokování a agenti jsou velkou brzdou IPv6, jejíž implementace se neposouvá příliš rychle. Je to smutné. Ti, kteří tento problém vyřešili, na sebe mohou být plně hrdí.
Konečně,
Neusiloval jsem o 100% přesnost, to mi prosím odpusťte, doufám, že někdo chce tuto práci zopakovat s větší přesností. Bylo pro mě důležité pochopit, zda tento přístup bude v principu fungovat. Odpověď je ano. Získaná čísla, jako první přiblížení, jsou myslím docela spolehlivá.
Co jiného se dalo dělat a na co jsem byl líný, bylo počítat DNS požadavky. Nejsou filtrovány, ale také neposkytují velkou přesnost, protože fungují pouze pro doménu, nikoli pro celou adresu URL. Frekvence by měla být viditelná. Pokud to zkombinujete s tím, co je vidět přímo v dotazech, umožní vám to oddělit nepotřebné a získat více informací. Je dokonce možné určit vývojáře DNS používaných poskytovateli a mnoho dalšího.
Absolutně jsem nečekal, že hoster bude obsahovat i vlastní filtr pro moje VPS. Možná je to běžná praxe. Nakonec RKN odešle hostiteli požadavek na smazání zdroje. To mě ale nepřekvapilo a v některých ohledech dokonce fungovalo v můj prospěch. Filtr fungoval velmi efektivně, odřízl všechny správné HTTP požadavky na zakázanou URL, ale nedostaly se k nim ty správné, které dříve prošly filtrem poskytovatelů, i když pouze ve formě koncovek: FIN-ACK и RST - mínus za mínus a málem se ukázalo, že je to plus. Mimochodem, IPv6 nebyl filtrován hostitelem. To samozřejmě ovlivnilo kvalitu nasbíraného materiálu, ale stále to umožňovalo vidět frekvenci. Ukázalo se, že je to důležitý bod při výběru místa pro umístění zdrojů; nezapomeňte se zajímat o otázku organizace práce se seznamem zakázaných míst a požadavků RKN.
Na začátku jsem porovnával AS "Inspektor" s . Toto srovnání je zcela oprávněné a velká síť Agentů může být prospěšná. Například stanovení kvality dostupnosti zdrojů od různých poskytovatelů v různých částech země. Můžete vypočítat zpoždění, můžete vytvářet grafy, můžete to vše analyzovat a vidět změny, ke kterým dochází lokálně i globálně. Toto není nejpřímější způsob, ale astronomové používají „standardní svíčky“, proč nepoužít agenty? Znáte-li (po nalezení) jejich standardní chování, můžete určit změny, které se kolem nich vyskytují a jak to ovlivňuje kvalitu poskytovaných služeb. A zároveň nemusíte samostatně umisťovat sondy do sítě, Roskomnadzor je již nainstaloval.
Dalším bodem, kterého se chci dotknout, je, že každý nástroj může být zbraní. AS "Inspector" je uzavřená síť, ale Agenti předají každého zasláním požadavků na všechny zdroje ze seznamu zakázaných. Mít takový zdroj nepředstavuje vůbec žádné problémy. Celkově poskytovatelé prostřednictvím Agentů nevědomky řeknou o své síti mnohem více, než by pravděpodobně stálo za to: typy DPI a DNS, umístění Agenta (centrální uzel a servisní síť?), síťové značky zpoždění a ztrát – a to je jen to nejviditelnější. Stejně jako někdo může sledovat akce agentů za účelem zlepšení dostupnosti svých zdrojů, někdo to může dělat pro jiné účely a neexistují v tom žádné překážky. Výsledkem je dvousečný a velmi mnohostranný nástroj, to může vidět každý.
Zdroj: www.habr.com