Let's count the "Revisor" agents

Nem titok, hogy Oroszországban a betiltott információk blokkolásának ellenőrzését az automatikus "Revizor" rendszer végzi. Hogy ez hogyan működik, azt jól leírják itt a Habr cikkében, a képet onnan vették:

Közvetlenül a szolgáltatónál telepítik a "Revizor Ügynök" modult:

A "Revizor Ügynök" modul az automatikus "Revizor" rendszer (AS "Revizor") struktúrájának eleme. Ez a rendszer a szolgáltatók által előírt hozzáféréskorlátozási követelmények betartásának ellenőrzésére készült, a 2006. július 27-i 149-FZ számú szövetségi törvény 15.1-15.4 cikkelyei szerint az információról, az információs technológiákról és az információvédelemről.

A "Revizor" rendszer létrehozásának fő célja az, hogy nyomon kövesse a szolgáltatók által a 2006. július 27-i 149-FZ számú szövetségi törvény 15.1-15.4 cikkelyei alapján előírt követelmények betartását, különös figyelmet fordítva a tiltott információkhoz való hozzáférés megállapítására és a megsértésről szóló megerősítő anyagok (adatok) megszerzésére.

Figyelembe véve, hogy ha nem is minden, de sok szolgáltató telepítette ezt az eszközt, akkor egy nagy hálózat kell, hogy kialakuljon, amelyben próbák és jelzők vannak, hasonlóan RIPE Atlas és még több, de zárt hozzáféréssel. Azonban a jelző az jelző, hogy jeleket küldjön minden irányba. Mi van, ha ezeket elkapjuk, és megnézzük, mit kaptunk és mennyit?

Mielőtt számolnánk, nézzük meg, miért lehet ez egyáltalán lehetséges.

Egy kis elmélet

Az ügynökök ellenőrzik az erőforrás elérhetőségét, beleértve a HTTP(S) kéréseken keresztül, például a következőt:

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"

A kérés, a hasznos teher mellett, a kapcsolat létrehozásának fázisából is áll: csere SYN és SYN-ACK, és a kapcsolat lezárásának fázisából: FIN-ACK.

A tiltott információk nyilvántartása többféle blokkolási típust tartalmaz. Nyilvánvaló, hogy ha egy erőforrást IP-cím vagy domainnév alapján blokkolnak, akkor nem fogunk látni semmilyen kérést. Ezek a legrombolóbb blokkolási típusok, amelyek az összes erőforrás elérhetetlenségéhez vezetnek egy IP-címen vagy egy domain összes információjának. Van egy másik blokkolási típus is, amely "URL alapú". Ebben az esetben a szűrőrendszernek elemeznie kell a HTTP kérés fejlécét, hogy pontosan meghatározza, mit kell blokkolni. Ahhoz, hogy ez megtörténjen, az első lépés a kapcsolat létrehozása, amelyet megpróbálhatunk követni, mivel valószínű, hogy a szűrő ezt átengedi.

Ehhez ki kell választani egy megfelelő szabad domaint, amely "URL alapú" blokkolási típussal és HTTP-val rendelkezik, hogy megkönnyítse a szűrőrendszer munkáját, lehetőleg régóta elhagyottat, hogy minimalizáljuk a külső forgalom áramlását az Ügynökökön kívül. Ez a feladat nem bizonyult túl bonyolultnak, a tiltott információk nyilvántartásában elegendő szabad domain van, bőven a különböző igényeknek. Így a domaint megvásárolták, és hozzá lett rendelve a VPS-en futó IP-címekhez. tcpdump és megkezdődött a számlálás.

A "Revizorok" áttekintése

Arra számítottam, hogy időszakos kérésnövekedéseket fogok látni, ami az én véleményem szerint egy irányított cselekvést jelezne. Nem mondhatom, hogy egyáltalán nem tapasztaltam ezt, de egyértelmű kép határozottan nem volt:

Ami nem meglepő, még egy senki által nem használt domain is, egy soha nem használt IP címen masszív nemkívánatos információt fog kapni, ilyen a modern Internet. De szerencsére csak a konkrét URL kérésére volt szükségem, így minden szkenner és jelszókereső gyorsan előkerült. Emellett meglehetősen egyszerű volt megérteni, hol van a flood a hasonló típusú kérések tömegében. Aztán összeállítottam az IP-címek megjelenésének gyakoriságát, és manuálisan átvizsgáltam az összes toplistát, elkülönítve azokat, akik a korábbi lépéseken átcsúsztak. Továbbá kivágtam az összes forrást, amely csak egy csomagot küldött, ezek már nem voltak sokan. És ez lett az eredmény:

Kis lírai kitérő. Múlt csütörtökön a webtárhely-szolgáltatóm egy elég ködös tartalmú levelet küldött, amelyben azt írták, hogy az Ön erőforrásaik között van a RKN által tiltottnak számító tartalom, ezért az blokkolva van. Először azt hittem, hogy letiltották a fiókamat, de ez nem volt így. Aztán azt gondoltam, hogy csak figyelmeztetnek arra, amiről amúgy is tudok. De kiderült, hogy a szolgáltató aktiválta a szűrőjét a doménem előtt, így végül dupla szűrés alá kerültem: a szolgáltatók és a tárhelyszolgáltató részéről is. A szűrő csak a lekérdezések végződéseit engedte át: FIN-ACK és RST eltávolítva a teljes HTTP-t a tiltott URL alapján. Ahogy a fenti grafikonból látható, az első nap után kevesebb adatot kaptam, de még mindig érkeztek, ami éppen elegendő volt a lekérdezések forrásának számlálásához.

Közel a lényeghez. Véleményem szerint világosan látható, hogy minden nap két csúcs van, az első kisebb, éjfél után Moszkvában, a második 6 reggel körül, amely 12-ig folytatódik. A csúcs nem pontosan ugyanabban az időben történik. Eleinte ki akartam emelni azokat az IP címeket, amelyek csak ezekben az időszakokban fordultak elő, és mindegyiket minden időszakban, abból a feltételezésből kiindulva, hogy az ügynöki ellenőrzések időszakosan történnek. De alaposabb nézés után elég gyorsan felfedeztem olyan időszakokat, amelyek más intervallumokba esnek, más gyakoriságokkal, akár óránkénti egy lekérdezéssel is. Aztán az időzónákra gondoltam, és arra, hogy lehet, hogy ez a probléma, majd arra, hogy egyáltalán a rendszer nem lehet globálisan szinkronizálva. Ezen kívül biztos vagyok benne, hogy a NAT is szerepet játszik, és ugyanaz az ügynök különböző nyilvános IP címekről küldhet lekérdezéseket.

Mivel az eredeti célom nem a pontosság volt, számba vettem az összes címet, amely egy hét alatt előfordult, és azt kaptam - 2791. Az egy címről létrehozott TCP kapcsolatok száma átlagosan 4, mediánja 2. A csúcsok címére: 464, 231, 149, 83, 77. A 95%-os minta maximuma - 8 kapcsolat egy címen. A medián nem túl magas, emlékeztetem, hogy a grafikonon egyértelmű napi periódusosság látható, így elvárható volt, hogy 4 és 8 között legyen 7 nap alatt. Ha eltávolítjuk azokat a kapcsolatokat, amelyek egyszer találkoztak, akkor pontosan 5 medián értéket kapunk. De nem tudtam őket világos kritérium alapján kizárni. Ellenkezőleg, a mintavételi ellenőrzés azt mutatta, hogy azok a tiltott erőforrások lekérdezéseihez kapcsolódnak.

A címek címek, de az interneten az autonóm rendszerek — AS — a fontosabbak, amelyekből született 1510, átlagosan 2 cím AS-ra, medián 1. A legfontosabb címek AS-ra: 288, 77, 66, 39, 27. A 95%-os minta maximuma — 4 cím AS-ra. Itt a medián várható — egy ügynök a szolgáltatóra. A toplista is várható — a legnagyobb szereplőkkel rendelkezik. A nagy hálózatokban az ügynököknek valószínűleg minden szolgáltató jelenlétében állniuk kellene, ne feledkezzünk meg a NAT-ról sem. Ha országokra bontjuk, a maximális értékek a következőképpen alakulnak: 1409 — Oroszország, 42 — Ukrajna, 23 — Csehország, 36 más régiókból, nem RIPE NCC. Az Oroszországon kívüli kérések figyelemfelkeltőek. Valószínűleg ezt a földrajzi helymeghatározás hibáival vagy a nyilvántartók hibáival lehet magyarázni a megadott adatok kitöltésénél. Vagy mivel az orosz cégnek lehetnek nem orosz gyökerei, vagy rendelkezhet külföldi képviselettel, mert így egyszerűbb, természetesen a külföldi RIPE NCC szervezettel való kapcsolatban. Egy részük kétségtelenül felesleges, de a megbízható elkülönítése nehézkes, mivel az erőforrás blokkolás alatt áll, és a második naptól kezdve kettős blokkolás alatt, a többségi munkamenetek csupán néhány szervizcsomag cseréjét jelentik. Abban állapodjunk meg, hogy ez egy kis rész.

Ezek a számok már hasonlíthatók az orosz szolgáltatók számához. A RKN adatai szerint a "Távközlési szolgáltatások adatátvitele, kivéve a hangot" engedélyek — 6387, de ez egy túlárazott becslés, nem minden engedély vonatkozik az internetes szolgáltatókra, akiknek ügynököt kell beállítaniuk. A RIPE NCC zónában hasonló számú AS van regisztrálva Oroszországban — 6230, amelyek közül nem minden szolgáltató. A UserSide szigorúbb számítást végzett és 3940 céget kapott 2017-ben, és ez inkább egy felső becslés. Mindenesetre az ügynököket megjelenített AS-ok száma körülbelül két és fél alkalommal kevesebb. De itt érdemes megérteni, hogy az AS nem feltétlenül egyenlő a szolgáltatóval. Néhány szolgáltatónak nincs saját AS-e, másoknak több mint egy van. Ha feltételezzük, hogy az ügynökök tényleg mindenhol állnak, akkor valaki szigorúbban szűr, így a kérdéseik nem különböznek a szemétből, ha egyáltalán eljutnak. De a durva becsléshez ez teljesen elfogadható, még ha valami elveszett is a figyelmetlenségem miatt.

A DPI-ről

Bár a tárhelyszolgáltatóm a második naptól aktiválta a szűrőjét, az első nap adatai alapján arra lehet következtetni, hogy a blokkolások sikeresen működnek. Csak 4 forrást tudtak áttörni, és ezeknek teljes, befejezett HTTP és TCP szekvenciáik vannak (ahogy a fentiekben látható). Még 460 képes csatlakozni GET, de a kapcsolat azonnal megszakad a RST. Figyeljen arra, hogy 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"

#Ezt kapta a szűrő
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#Ez pedig az eredeti csomópont elvesztési kísérlete
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"

#Az eredeti csomópont rájön, hogy a kapcsolat megszakadt
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

Ezeknek a variációi eltérőek lehetnek: kevesebb RST vagy több retranszmitálás — attól függően, hogy mit küld a szűrő az eredeti csomópontnak. Mindenesetre ez a legmegbízhatóbb minta, amelyből látszik, hogy kifejezetten a tiltott erőforrást kérték. Ráadásul mindig van egy válasz, amely a TTL nagyobb, mint az előző és a következő csomagok.

A többi részével nem látható semmi, GET:

TTL 50, TCP, 14678  >  80, "[SYN] Seq=0"
TTL 64, TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"

#Ezt kapta a szűrő
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

Vagy így:

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"

#Ezt kapta a szűrő
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"

#Ismét a szűrő, többször is
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

Kötelezően látható a különbség a TTL ha valami beérkezik a szűrőtől. De gyakran semmi sem érkezik:

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"
...

Vagy így:

TCP, 14678  >  80, "[SYN] Seq=0"
TCP, 80  >  14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678  >  80, "[ACK] Seq=1 Ack=1"

#Eltelt néhány másodperc forgalom nélkül

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

És mindez folytatódik és folytatódik, ahogy a grafikonon is látható, nem egyszer, hanem minden nap.

IPv6-ról

Jó hír — van. Biztosan tudom mondani, hogy 5 különböző IPv6 címről időszakos lekérések érkeznek a tilalmas forráshoz, ez a viselkedés pontosan az, amit vártam az Ügynököktől. Ráadásul az egyik IPv6 cím nem tartozik a szűrés alá, és egy teljes munkamenetet látok. Két másik címről csak egy-egy befejezetlen munkamenetet észleltem, melyek közül az egyik megakadt a szűrőn. RST az egyik a szűrő miatt, a másik az időkorlát miatt. Összesen tehát 7.

Mivel kevés cím van, alaposan megvizsgáltam mindet, és kiderült, hogy valójában csak 3 szolgáltató van, akiknek állva kell tapsolni! Egy másik cím — egy felhőalapú tárhely Oroszországban (nem szűr), a másik — egy kutatóközpont Németországban (ott van szűrő, hol?). De miért ellenőrzik rendszeresen a tilalmas források elérhetőségét, az jó kérdés. A maradék két cím egy-egy lekérést végzett, és nem Oroszország területén található, ráadásul az egyik szűrve van (végül is a tranzitten?).

A szűrések és az Ügynökök nagy késleltetést okoznak az IPv6 számára, amelynek bevezetése így is lassan halad. Ez szomorú. Azok, akik teljes mértékben megoldották ezt a feladatot, büszkék lehetnek magukra.

Végül

Nem kerestem a 100% -os pontosságot, ezért elnézést kérek, remélem, valaki szeretne egy ilyen munkát nagyobb precizitással megismételni. Számomra fontos volt megérteni, hogy egy ilyen megközelítés egyáltalán működni fog-e. A válasz — működni fog. Az első közelítésben kapott számok véleményem szerint meglehetősen megbízhatóak.

Mit lehetne még tenni, és mit lustáltam megtenni — megszámolni a DNS-lekéréseket. Ezek nem szűrve, de nem is adnak nagy pontosságot, mivel csak a domainra vonatkoznak, nem az egész URL-re. A periódikusságnak észlelhetőnek kell lennie. Ha ezt összevonjuk azzal, amit közvetlenül a lekérésekben láthatunk, az lehetővé teszi a felesleges adatok elválasztását és több információ nyerését. Lehet, hogy még a szolgáltatók által használt DNS fejlesztőit is meg lehet határozni, és sok mást is.

Teljesen nem vártam, hogy a VPS-emhez a szolgáltató még saját szűrőt is bekapcsol. Lehet, hogy ez szokásos gyakorlat. Végül is a RKN éppen a szolgáltatóhoz küldi a forrás törlésére vonatkozó kérelmet. De ez nem lepett meg, és valahol még hasznomra is vált. A szűrő nagyon hatékonyan működött, levágva minden helyes HTTP lekérést a tilalmas URL-re, de a nem megfelelő, a szolgáltatók szűrőjén átment lekérések eljutottak, ha csak a végkimenet formájában is: FIN-ACK és RST — mínusz mínuszra és majdnem plusz lett. Egyébként az IPv6 hosztert nem szűrték. Természetesen ez befolyásolta az összegyűjtött anyag minőségét, de így is lehetőséget adott arra, hogy láthassuk a periódikusságot. Kiderült, hogy ez fontos tényező a források elhelyezésének helyének kiválasztásakor, ne felejtsenek el érdeklődni a tiltottnak nyilvánított webhelyek listájával és a Roszkomnadzor által küldött kérelmek kezelésével kapcsolatban.

Elején a Revizor ASE-t hasonlítottam össze a RIPE Atlas. Ez a hasonlítás teljesen indokolt, és egy nagy hálózat az ügynökökkel hasznot hozhat. Például a forrás rendelkezésre állásának minősége különböző szolgáltatókból az ország különböző részein. Meg lehet számolni a késéseket, grafikonokat lehet építeni, mindezt elemezni és látni a helyi és globális változásokat. Ez nem a legközvetlenebb út, de az astronomák is használják a "standard gyertyákat", miért ne használhatnánk az ügynököket? Ismerve (megkeresve) a standard viselkedésüket, meghatározhatjuk a körülöttük történő változásokat, és hogyan befolyásolják a nyújtott szolgáltatások minőségét. És közben nem szükséges önállóan probe-okat elhelyezni a hálózatban, azokat már a Roszkomnadzor elhelyezte.

Még egy téma, amelyet szeretnék érinteni: minden eszköz lehet fegyver. A Revizor ASE zárt hálózat, de az ügynökök mindent elmondanak, küldve kérelmeket a tiltott források minden egyes webhelyére. Ilyen forrást szerezni egyáltalán nem jelent problémát. Összességében a szolgáltatók az ügynökökön keresztül, akaratlanul is, sokkal többet árulnak el a hálózatukról, mint amit valószínűleg megérne: DPI és DNS típusok, az ügynök helyzete (központi csomópont és szolgáltatói hálózat?), hálózati késleltetési és veszteségi jelzők — és ez csak a legnyilvánvalóbb. Ahogy valaki monitorozhatja az ügynökök tevékenységét a forrásai elérhetőségének javítása érdekében, mások ezt más célokra is megtehetik, és ennek nincs akadálya. Ez egy kétségbevonható és nagyon sokoldalú eszköz lett, bárki megbizonyosodhat róla.

Forrás: habr.com