Nem titok, hogy az oroszországi tiltott információk listáján szereplő blokkolások ellenőrzését az „Inspector” automatizált rendszer felügyeli. Itt jól meg van írva, hogyan működik , kép ugyanonnan:
Közvetlenül a szolgáltatónál telepítve :
Az "Agent Inspector" modul az "Inspector" automatizált rendszer (AS "Inspector") szerkezeti eleme. Ezt a rendszert arra tervezték, hogy a 15.1. július 15.4-i 27-FZ „Az információs, információs technológiákról és információvédelemről” szóló szövetségi törvény 2006-149. cikkében megállapított rendelkezések keretein belül nyomon kövesse a távközlési szolgáltatók általi hozzáférés-korlátozási követelményeket. ”
Az AS "Revizor" létrehozásának fő célja annak ellenőrzése, hogy a távközlési szolgáltatók megfelelnek-e az információs, információs technológiákról és információvédelemről szóló, 15.1. július 15.4-i 27-FZ szövetségi törvény 2006-149. " a tiltott információkhoz való hozzáférés tényeinek azonosítása és a tiltott információkhoz való hozzáférés korlátozása érdekében a jogsértésekről szóló támogató anyagok (adatok) beszerzése tekintetében.
Figyelembe véve azt a tényt, hogy ha nem is az összes szolgáltató, de sok szolgáltató telepítette ezt az eszközt, akkor a jeladó szondák nagy hálózatának kellett volna lennie, mint pl. és még több is, de zárt hozzáféréssel. A jeladó azonban arra való, hogy minden irányba jeleket küldjön, de mi van, ha elkapjuk őket, és megnézzük, mit és mennyit fogtunk?
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 egy erőforrás elérhetőségét, beleértve a HTTP(S) kéréseket is, mint például ez:
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 egy kapcsolatlétesítési fázisból is áll: cseréből SYN и SYN-ACKés a csatlakozás befejezésének fázisai: FIN-ACK.
A tiltott információk nyilvántartása többféle zárolást tartalmaz. Nyilvánvaló, hogy ha egy erőforrást IP-cím vagy domain név blokkol, akkor nem fogunk látni kéréseket. Ezek a blokkolások legpusztítóbb típusai, amelyek egy IP-címen lévő összes erőforrás vagy egy tartomány összes információjának elérhetetlenségéhez vezetnek. Létezik „URL alapján” típusú blokkolás is. Ebben az esetben a szűrőrendszernek elemeznie kell a HTTP kérés fejlécét, hogy pontosan meghatározza, mit blokkoljon. És előtte, amint fentebb látható, el kell jönnie egy kapcsolatlétesítési fázisnak, amelyet megpróbálhat nyomon követni, mivel nagy valószínűséggel a szűrő kihagyja.
Ehhez ki kell választani egy megfelelő szabad domaint „URL” és HTTP blokkolási típussal, hogy megkönnyítse a szűrőrendszer munkáját, lehetőleg régóta felhagyott, hogy minimalizáljuk a külső forgalom bejutását, kivéve az ügynököktől. Ez a feladat egyáltalán nem bizonyult nehéznek, elég sok ingyenes domain található a tiltott információk nyilvántartásában, és minden ízléshez. Ezért a domaint megvásárolták, és egy futó VPS-en lévő IP-címekhez kapcsolták tcpdump és elkezdődött a számolás.
„A könyvvizsgálók” ellenőrzése
Arra számítottam, hogy rendszeres kéréseket fogok látni, amelyek véleményem szerint ellenőrzött cselekvésre utalnak. Lehetetlen azt mondani, hogy egyáltalán nem láttam, de határozottan nem volt tiszta kép:
Ami nem meglepő, még egy olyan domainen is, amelyre senkinek nincs szüksége, és egy soha nem használt IP-n is egyszerűen rengeteg kéretlen információ lesz, ilyen a modern internet. De szerencsére csak egy konkrét URL-re volt szükségem, így az összes szkennert és jelszótörőt gyorsan megtaláltam. Ezenkívül a hasonló kérések tömege alapján meglehetősen könnyen megérthető volt, hogy hol volt az árvíz. Ezután összeállítottam az IP-címek előfordulási gyakoriságát, és manuálisan végigmentem a teljes tetején, elkülönítve azokat, akik az előző szakaszokban hiányoltak. Ráadásul kivágtam az összes forrást, amit egy csomagban küldtek, már nem sok volt belőlük. És ez történt:
Egy kis lírai kitérő. Valamivel több, mint egy nappal később a tárhelyszolgáltatóm küldött egy meglehetősen letisztult tartalmú levelet, amelyben azt írta, hogy az Ön létesítményei az RKN tiltólistájáról tartalmaznak forrást, ezért az le van tiltva. Először azt hittem, hogy a fiókom le van tiltva, ez nem így volt. Aztán arra gondoltam, hogy csak figyelmeztetnek valamire, amiről már tudtam. De kiderült, hogy a hoster bekapcsolta a szűrőjét a domainem előtt, és ennek eredményeként kettős szűrés alá kerültem: a szolgáltatóktól és a tárhelytől. A szűrő csak a kérések végén ment át: FIN-ACK и RST letiltott URL-címen az összes HTTP leállítása. Amint a fenti grafikonon látható, az első nap után kezdtem kevesebb adatot kapni, de még mindig megkaptam, ami elég volt a kérésforrások számlálásához.
Térjen a tárgyra. Véleményem szerint minden nap két kitörés jól látható, az első kisebb, moszkvai idő szerint éjfél után, a második közelebb reggel 6-hoz déli 12-ig. A csúcs nem pontosan ugyanabban az időben következik be. Eleinte olyan IP-címeket szerettem volna kiválasztani, amelyek csak ezekben az időszakokban és minden időszakban estek, abból a feltételezésből kiindulva, hogy az Ügynökök általi ellenőrzéseket időszakosan hajtják végre. Ám alapos áttekintés után gyorsan felfedeztem, hogy más intervallumokba esnek, más gyakorisággal, óránként legfeljebb egy kéréssel. Aztán az időzónákra gondoltam, és arra, hogy lehet valami köze hozzájuk, aztán arra gondoltam, hogy általában nem lehet globálisan szinkronizálni a rendszert. Ezenkívül a NAT valószínűleg szerepet fog játszani, és ugyanaz az ügynök különböző nyilvános IP-címekről küldhet kéréseket.
Mivel a kezdeti célom nem volt pontosan, megszámoltam az összes címet, amivel egy hét alatt találkoztam, és megkaptam: 2791. Az egy címről létrehozott TCP-munkamenetek száma átlagosan 4, mediánja 2. Legnépszerűbb munkamenetek címenként: 464, 231, 149, 83, 77. A minta 95%-ától a maximum 8 munkamenet címenként. A medián nem túl magas, hadd emlékeztessem önöket, hogy a grafikon egyértelmű napi periodicitást mutat, tehát 4 nap alatt valami 8-7 körülire lehet számítani. Ha az összes egyszer előforduló munkamenetet kidobjuk, akkor 5-ös mediánt kapunk. De egyértelmű kritérium alapján nem tudtam kizárni őket. Éppen ellenkezőleg, egy véletlenszerű ellenőrzés kimutatta, hogy tiltott forrásra vonatkozó kérelmekkel kapcsolatosak.
A címek címek, de az interneten autonóm rendszerek - AS, ami fontosabbnak bizonyult 1510, átlagosan 2 cím AS-onként, 1-es mediánnal. Legnagyobb címek AS-enként: 288, 77, 66, 39, 27. A minta maximum 95%-a AS-onként 4 cím. Itt a medián várható – szolgáltatónként egy ügynök. Mi is a csúcsra számítunk – nagy játékosok vannak benne. Egy nagy hálózatban az ügynököknek valószínűleg az operátor jelenlétének minden régiójában kell elhelyezkedniük, és ne feledkezzünk meg a NAT-ról. Ha országonként vesszük, akkor a maximumok a következők lesznek: 1409 - RU, 42 - UA, 23 - CZ, 36 más régióból, nem RIPE NCC. Az Oroszországon kívülről érkező kérések felkeltik a figyelmet. Ez valószínűleg a földrajzi helymeghatározási hibákkal vagy az adatkitöltéskor az anyakönyvvezető hibáival magyarázható. Illetve az, hogy egy orosz cégnek nem biztos, hogy orosz gyökerei vannak, vagy külföldi képviselete van, mert az egyszerűbb, ami természetes, ha külföldi szervezettel van dolgunk a RIPE NCC-vel. Bizonyos részek kétségtelenül feleslegesek, de megbízhatóan nehéz szétválasztani, mivel az erőforrás blokkolt, a második naptól pedig kettős blokkolás alatt áll, és a legtöbb munkamenet csak több szolgáltatáscsomag cseréje. Egyetértünk abban, hogy ez egy kis rész.
Ezek a számok már összevethetők az oroszországi szolgáltatók számával. „Adatátviteli kommunikációs szolgáltatások, a hang kivételével” licencek - 6387, de ez egy nagyon magas becslés felülről, nem mindegyik licenc vonatkozik kifejezetten azokra az internetszolgáltatókra, akiknek ügynököt kell telepíteniük. A RIPE NCC zónában hasonló számú AS-t regisztráltak Oroszországban - 6230, amelyek közül nem mindegyik szolgáltató. és 3940-ben 2017 cég érkezett, és ez inkább egy felülről jövő becslés. Mindenesetre két és félszer kevesebb a világító AS-unk. De itt érdemes megérteni, hogy az AS nem szigorúan egyenlő a szolgáltatóval. Egyes szolgáltatók nem rendelkeznek saját AS-vel, másoknak több is van. Ha feltételezzük, hogy mindenkinek vannak még ügynökei, akkor valaki erősebben szűr, mint mások, így a kérései megkülönböztethetetlenek a szeméttől, ha eljutnak hozzájuk. De hozzávetőleges értékeléshez ez teljesen elviselhető, még akkor is, ha valami elveszett az én figyelmetlenségem miatt.
A DPI-ről
Annak ellenére, hogy a tárhelyszolgáltatóm a második naptól bekapcsolta a szűrőjét, az első napi információk alapján megállapíthatjuk, hogy a blokkolás sikeresen működik. Csak 4 forrás tudott átjutni, és teljesen befejezte a HTTP- és TCP-munkameneteket (mint a fenti példában). További 460 küldhető GET, de a munkamenetet azonnal megszakítja RST. Figyelni 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"
Ennek változatai különbözőek lehetnek: kevesebb RST vagy több újraküldés – attól is függ, hogy a szűrő mit küld a forráscsomópontnak. Mindenesetre ez a legmegbízhatóbb sablon, amiből egyértelműen látszik, hogy tiltott forrást kértek. Plusz mindig van egy válasz, amely megjelenik a munkamenetben TTL nagyobb, mint az előző és a következő csomagokban.
A többiből nem is látszik 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"
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"
#Вот это прислал фильтр
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"
...
A különbség határozottan látható TTL ha jön valami a szűrőből. De gyakran előfordulhat, hogy 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"
#Прошло несколько секунд без трафика
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
És mindez megismétlődik és ismétlődik és ismétlődik, ahogy a grafikonon is látszik, naponta többször.
Az IPv6-ról
A jó hír az, hogy létezik. Megbízhatóan állíthatom, hogy egy tiltott erőforráshoz intézett időszakos kérések 5 különböző IPv6-címről érkeznek, ami pontosan az Ügynökök viselkedése, amire számítottam. Ráadásul az egyik IPv6-cím nem tartozik a szűrés alá, és teljes munkamenetet látok. További kettőből csak egy befejezetlen munkamenetet láttam, az egyiket megszakította RST a szűrőből, időben második. Teljes összeg 7.
Mivel kevés a cím ezért mindegyiket részletesen áttanulmányoztam és kiderült, hogy ott csak 3 szolgáltató van, nekik lehet taps! Egy másik cím az oroszországi felhőtárhely (nem szűr), a másik egy németországi kutatóközpont (van szűrő, hol?). De hogy miért ellenőrzik ütemezetten a tiltott források elérhetőségét, az jó kérdés. A maradék kettő egy kérést nyújtott be, és Oroszországon kívül található, és az egyik szűrt (végül is szállítás közben?).
A blokkolás és ügynökök nagy akadályt jelentenek az IPv6-nak, amelynek megvalósítása nem halad túl gyorsan. Szomorú. Azok, akik megoldották ezt a problémát, teljesen büszkék lehetnek magukra.
Összefoglalva
Nem törekedtem a 100%-os pontosságra, ezt kérem bocsássák meg, remélem valaki nagyobb pontossággal meg akarja ismételni ezt a munkát. Fontos volt megértenem, hogy ez a megközelítés elvben működik-e. A válasz igen. Első közelítésként a kapott számadatok szerintem meglehetősen megbízhatóak.
Mit lehetett volna még tenni, és amire lusta voltam, az az, hogy megszámoltam a DNS-kéréseket. Nincsenek szűrve, de nem is nyújtanak nagy pontosságot, mivel csak a domainre vonatkoznak, és nem a teljes URL-re. A frekvenciának láthatónak kell lennie. Ha kombinálja azzal, ami közvetlenül a lekérdezésekben látható, ez lehetővé teszi, hogy elkülönítse a feleslegeseket, és több információhoz jusson. Még a szolgáltatók által használt DNS fejlesztői és még sok más meghatározása is lehetséges.
Abszolút nem számítottam arra, hogy a hoster saját szűrőt is tartalmaz a VPS-emhez. Talán ez az általános gyakorlat. Végül az RKN kérelmet küld az erőforrás törlésére a gazdagépnek. De ez nem lepett meg, sőt bizonyos szempontból az előnyömre vált. A szűrő nagyon hatékonyan működött, levágta az összes helyes HTTP-kérést egy tiltott URL-re, de a szolgáltatók szűrőjén korábban átmenő helyesek nem jutottak el hozzájuk, igaz, csak végződések formájában: FIN-ACK и RST - mínusz mínuszra és majdnem plusz lett belőle. Az IPv6-ot egyébként nem szűrte a hoster. Ez természetesen befolyásolta az összegyűjtött anyag minőségét, de így is láthatóvá vált a gyakoriság. Kiderült, hogy ez egy fontos pont az erőforrások elhelyezésének helyének kiválasztásakor; ne felejtse el érdeklődni a tiltott helyek listájával és az RKN kéréseivel kapcsolatos munka megszervezése iránt.
Az elején összehasonlítottam az AS "Inspector"-val . Ez az összehasonlítás meglehetősen indokolt, és az ügynökök széles hálózata előnyös lehet. Például az erőforrások elérhetőségének minőségének meghatározása a különböző szolgáltatóktól az ország különböző részein. Kiszámolhatja a késéseket, grafikonokat készíthet, mindezt elemzi, és láthatja a helyi és globális változásokat. Ez nem a legközvetlenebb út, de a csillagászok „szokásos gyertyákat” használnak, miért ne használnának ügynököket? A szokásos viselkedésük ismeretében (megtalálva) meghatározhatja a körülöttük végbemenő változásokat, és azt, hogy ez hogyan befolyásolja a nyújtott szolgáltatások minőségét. Ugyanakkor nem kell önállóan elhelyezni a szondákat a hálózaton, a Roskomnadzor már telepítette őket.
Egy másik pont, amit szeretnék érinteni, az az, hogy minden eszköz lehet fegyver. Az AS "Inspector" egy zárt hálózat, de az Ügynökök mindenkit átadnak úgy, hogy kéréseket küldenek az összes erőforrásra a tiltott listáról. Egy ilyen erőforrás megléte 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 hálózatukról, mint amennyit valószínűleg megér: DPI és DNS típusok, az ügynök elhelyezkedése (központi csomópont és szolgáltatási hálózat?), a késések és a veszteségek hálózati jelzői – ez pedig csak a legnyilvánvalóbb. Ahogyan valaki figyelemmel kísérheti az Ügynökök tevékenységét erőforrásai elérhetőségének javítása érdekében, valaki ezt más célokra is megteheti, és ennek nincs akadálya. Az eredmény egy kétélű és nagyon sokrétű hangszer, ezt bárki láthatja.
Forrás: will.com