Nije tajna da kontrolu blokiranja na popisu zabranjenih informacija u Rusiji nadzire automatizirani sustav "Inspektor". Ovdje je dobro napisano kako to radi
Instalirano izravno kod dobavljača
Modul "Agent Inspektor" je strukturni element automatiziranog sustava "Inspektor" (AS "Inspektor"). Ovaj sustav je dizajniran za praćenje usklađenosti telekom operatera sa zahtjevima za ograničenje pristupa u okviru odredbi utvrđenih člancima 15.1-15.4 Saveznog zakona od 27. srpnja 2006. br. 149-FZ „O informacijama, informacijskim tehnologijama i zaštiti informacija“. ”
Glavna svrha stvaranja AS "Revizor" je osigurati praćenje usklađenosti telekom operatera sa zahtjevima utvrđenim člancima 15.1-15.4 Saveznog zakona od 27. srpnja 2006. br. 149-FZ "O informacijama, informacijskim tehnologijama i zaštiti informacija". “ u smislu utvrđivanja činjenica pristupa zabranjenim informacijama i dobivanja popratnih materijala (podataka) o kršenjima radi ograničenja pristupa zabranjenim informacijama.
Uzimajući u obzir činjenicu da su, ako ne svi, onda mnogi pružatelji usluga instalirali ovaj uređaj, trebala je postojati velika mreža beacon sondi poput
Prije nego što prebrojimo, da vidimo zašto je to uopće moguće.
Malo teorije
Agenti provjeravaju dostupnost resursa, uključujući putem HTTP(S) zahtjeva, kao što je ovaj:
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"
Uz korisni teret, zahtjev se sastoji i od faze uspostavljanja veze: razmjena SYN
и SYN-ACK
, te faze završetka veze: FIN-ACK
.
Registar zabranjenih informacija sadrži nekoliko vrsta blokada. Očito, ako je resurs blokiran IP adresom ili nazivom domene, tada nećemo vidjeti nikakve zahtjeve. Ovo su najdestruktivnije vrste blokiranja koje dovode do nedostupnosti svih resursa na jednoj IP adresi ili svih informacija na domeni. Postoji i tip blokiranja "prema URL-u". U ovom slučaju, sustav filtriranja mora analizirati zaglavlje HTTP zahtjeva kako bi točno odredio što blokirati. A prije toga, kao što se može vidjeti gore, trebala bi postojati faza uspostavljanja veze koju možete pokušati pratiti, jer će je filter najvjerojatnije propustiti.
Da biste to učinili, trebate odabrati odgovarajuću besplatnu domenu s "URL" i vrstom blokiranja HTTP-a kako biste olakšali rad sustava za filtriranje, po mogućnosti davno napuštenog, kako biste minimizirali ulazak vanjskog prometa osim od agenata. Pokazalo se da ovaj zadatak nije nimalo težak, besplatnih domena u registru zabranjenih informacija ima dosta i za svačiji ukus. Stoga je domena kupljena i povezana s IP adresama na pokrenutom VPS-u tcpdump
i odbrojavanje je počelo.
Revizija "Revizora"
Očekivao sam da ću vidjeti povremene nalete zahtjeva, što bi po mom mišljenju značilo kontroliranu akciju. Nemoguće je reći da to uopće nisam vidio, ali definitivno nije bilo jasne slike:
Što i ne čudi, čak i na domeni koja nikome ne treba i na nikad korištenom IP-u jednostavno će biti gomila neželjenih informacija, takav je moderni Internet. Ali srećom, trebao sam samo zahtjeve za određeni URL, tako da su svi skeneri i alati za probijanje lozinki brzo pronađeni. Također, bilo je prilično lako shvatiti gdje je poplava na temelju mase sličnih zahtjeva. Zatim sam sastavio učestalost pojavljivanja IP adresa i ručno prošao kroz cijeli vrh, odvajajući one koji su to propustili u prethodnim fazama. Osim toga, izrezao sam sve izvore koji su poslani u jednom paketu, nije ih više bilo puno. I evo što se dogodilo:
Mala lirska digresija. Nešto više od dan kasnije, moj hosting provider je poslao pismo prilično pojednostavljenog sadržaja, u kojem piše da se u vašim objektima nalazi resurs s liste zabranjenih RKN-a, pa je blokiran. Prvo sam mislio da mi je račun blokiran, ali to nije bio slučaj. Tada sam pomislio da me jednostavno upozoravaju na nešto što već znam. Ali pokazalo se da je hoster uključio svoj filter ispred moje domene i zbog toga sam došao pod dvostruko filtriranje: od provajdera i od hostera. Filter je prošao samo krajeve zahtjeva: FIN-ACK
и RST
odsijecanje svih HTTP-a na zabranjenim URL-ovima. Kao što možete vidjeti na gornjem grafikonu, nakon prvog dana počeo sam dobivati manje podataka, ali sam ih ipak dobio, što je bilo sasvim dovoljno za zadatak brojanja izvora zahtjeva.
Prijeđi na stvar. Po mom mišljenju, dva praska su jasno vidljiva svaki dan, prvi manji, nakon ponoći po moskovskom vremenu, drugi bliže 6 sati ujutro s repom do 12 sati. Vrhunac se ne događa točno u isto vrijeme. Isprva sam htio odabrati IP adrese koje su pale samo u tim razdobljima i svaka u svim razdobljima, na temelju pretpostavke da se provjere od strane agenata obavljaju periodički. Ali nakon pažljivog pregleda, brzo sam otkrio razdoblja koja spadaju u druge intervale, s drugim učestalostima, do jednog zahtjeva svakog sata. Zatim sam razmišljao o vremenskim zonama i da to možda ima neke veze s njima, zatim sam mislio da općenito sustav možda nije globalno sinkroniziran. Osim toga, NAT će vjerojatno igrati ulogu i isti Agent može postavljati zahtjeve s različitih javnih IP adresa.
Budući da moj početni cilj nije bio točno, prebrojao sam sve adrese na koje sam naišao u tjedan dana i dobio - 2791. Broj TCP sesija uspostavljenih s jedne adrese u prosjeku je 4, s medijanom od 2. Najviše sesija po adresi: 464, 231, 149, 83, 77. Maksimalno od 95% uzorka je 8 sesija po adresi. Medijan nije jako visok, podsjetit ću da je na grafu jasna dnevna periodičnost, pa se može očekivati nešto oko 4 do 8 u 7 dana. Ako izbacimo sve sesije koje se jednom pojave, dobit ćemo medijan jednak 5. Ali nisam ih mogao isključiti na temelju jasnog kriterija. Nasuprot tome, nasumična provjera pokazala je da su povezani sa zahtjevima za zabranjenim resursom.
Adrese su adrese, ali na internetu autonomni sustavi - AS, što se pokazalo važnijim 1510, u prosjeku 2 adrese po AS-u s medijanom od 1. Najviše adresa po AS-u: 288, 77, 66, 39, 27. Maksimalno 95% uzorka su 4 adrese po AS-u. Ovdje se očekuje medijan - jedan agent po pružatelju usluga. Očekujemo i vrh – u njemu su veliki igrači. U velikoj mreži, agenti bi vjerojatno trebali biti smješteni u svakoj regiji prisutnosti operatera i ne zaboravite na NAT. Ako uzmemo po zemlji, maksimumi će biti: 1409 - RU, 42 - UA, 23 - CZ, 36 iz drugih regija, ne RIPE NCC. Zahtjevi izvan Rusije privlače pažnju. To se vjerojatno može objasniti geolokacijskim pogreškama ili pogreškama matičara prilikom popunjavanja podataka. Ili činjenica da ruska tvrtka možda nema ruske korijene ili nema inozemno predstavništvo jer je to lakše, što je prirodno kada se radi o stranoj organizaciji RIPE NCC. Neki dio je nedvojbeno suvišan, ali ga je pouzdano teško izdvojiti, jer je resurs u blokadi, a od drugog dana u dvostrukoj blokadi, a većina sesija je samo razmjena nekoliko servisnih paketa. Složimo se da je to mali dio.
Ove se brojke već mogu usporediti s brojem pružatelja usluga u Rusiji.
O DPI
Unatoč tome što je moj hosting provider uključio svoj filter od drugog dana, na temelju informacija od prvog dana možemo zaključiti da blokada uspješno funkcionira. Samo su 4 izvora uspjela proći i potpuno su dovršila HTTP i TCP sesije (kao u gornjem primjeru). Može se poslati još 460 GET
, ali sesija se odmah prekida od strane RST
. Obrati pozornost 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"
Varijacije toga mogu biti različite: manje RST
ili više ponovnih prijenosa - također ovisi o tome što filtar šalje izvornom čvoru. U svakom slučaju, ovo je najpouzdaniji predložak, iz kojeg je jasno da je tražen zabranjeni resurs. Osim toga, uvijek postoji odgovor koji se pojavljuje u sesiji sa TTL
veći nego u prethodnim i sljedećim paketima.
Od ostatka se to ni ne vidi 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"
Ili:
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"
...
Razlika se svakako vidi TTL
ako nešto dolazi iz filtera. Ali često uopće ne stigne ništa:
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"
...
Ili:
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"
...
I sve se to ponavlja i ponavlja i ponavlja, kao što se može vidjeti na grafikonu, više puta, svaki dan.
O IPv6
Dobra vijest je da postoji. Pouzdano mogu reći da se periodični zahtjevi prema zabranjenom resursu javljaju s 5 različitih IPv6 adresa, što je upravo ponašanje agenata koje sam očekivao. Štoviše, jedna od IPv6 adresa ne potpada pod filtriranje i vidim punu sesiju. Od još dvije vidio sam samo jednu nedovršenu sesiju, od kojih je jednu prekinuo RST
iz filtera, drugi po vremenu. Ukupni iznos 7.
Pošto ima malo adresa, sve sam ih detaljno proučio i pokazalo se da su tamo samo 3 pružatelja, za njih svaka čast! Druga adresa je cloud hosting u Rusiji (ne filtrira), druga je istraživački centar u Njemačkoj (postoji filter, gdje?). Ali zašto provjeravaju dostupnost zabranjenih resursa prema rasporedu, dobro je pitanje. Preostala dva su podnijela jedan zahtjev i nalaze se izvan Rusije, a jedan od njih je filtriran (ipak u tranzitu?).
Blokiranje i agenti velika su prepreka IPv6, čija implementacija ne napreduje tako brzo. Tužno je. Oni koji su riješili ovaj problem mogu biti u potpunosti ponosni na sebe.
U zaključku
Nisam težio 100% točnosti, oprostite mi na ovome, nadam se da netko želi ponoviti ovaj rad s većom točnošću. Bilo mi je važno shvatiti hoće li ovaj pristup načelno funkcionirati. Odgovor je da. Kao prvu aproksimaciju, dobivene brojke, mislim, prilično su pouzdane.
Što se drugo moglo učiniti, a ono za što sam bio previše lijen je brojanje DNS zahtjeva. Nisu filtrirani, ali također ne pružaju veliku točnost budući da rade samo za domenu, a ne za cijeli URL. Frekvencija bi trebala biti vidljiva. Ako ga kombinirate s onim što je vidljivo izravno u upitima, to će vam omogućiti da odvojite nepotrebno i dobijete više informacija. Moguće je čak odrediti programere DNS-a koje koriste pružatelji i još mnogo toga.
Apsolutno nisam očekivao da će hoster uključiti i vlastiti filter za moj VPS. Možda je ovo uobičajena praksa. Na kraju, RKN hosteru šalje zahtjev za brisanje resursa. Ali to me nije iznenadilo i na neki način je čak išlo u moju korist. Filtar je radio vrlo učinkovito, odsijecajući sve ispravne HTTP zahtjeve prema zabranjenom URL-u, ali do njih nisu stigli ispravni oni koji su prethodno prošli kroz filtar pružatelja usluga, iako samo u obliku završetaka: FIN-ACK
и RST
- minus za minus i zamalo da ispadne plus. Usput, hoster nije filtrirao IPv6. Naravno, to je utjecalo na kvalitetu prikupljenog materijala, ali je ipak omogućilo uvid u frekvenciju. Pokazalo se da je ovo važna točka pri odabiru mjesta za postavljanje resursa; ne zaboravite se zainteresirati za pitanje organizacije rada s popisom zabranjenih mjesta i zahtjevima RKN-a.
Na početku sam usporedio AS "Inspektor" sa
Još jedna stvar koju želim dotaknuti je da svaki alat može biti oružje. AS "Inspektor" je zatvorena mreža, ali Agenti predaju sve šaljući zahtjeve za sve resurse sa liste zabranjenih. Posjedovanje takvog resursa ne predstavlja nikakav problem. Sveukupno, pružatelji putem agenata, nesvjesno, govore mnogo više o svojoj mreži nego što je vjerojatno vrijedno toga: DPI i DNS tipovi, lokacija agenta (centralni čvor i servisna mreža?), mrežni markeri kašnjenja i gubitaka - a ovo je samo ono najočitije. Kao što netko može nadzirati radnje agenata kako bi poboljšao dostupnost svojih resursa, netko to može činiti u druge svrhe i za to nema nikakvih prepreka. Rezultat je dvosjekli i vrlo višestruki instrument, svatko to može vidjeti.
Izvor: www.habr.com