Nije tajna da kontrolu blokiranja na popisu zabranjenih informacija u Rusiji nadzire automatizirani sustav "Inspektor". Ovdje je dobro napisano kako to radi , slika sa istog mjesta:
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 pa čak i više, ali sa zatvorenim pristupom. No, beacon je beacon koji šalje signale na sve strane, ali što ako ih uhvatimo i vidimo što smo uhvatili i koliko?
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. licence za “Komunikacijske usluge za prijenos podataka, isključujući glas” - 6387, ali ovo je vrlo visoka procjena odozgo, ne odnose se sve ove licence posebno na internetske pružatelje koji trebaju instalirati agenta. U zoni RIPE NCC postoji sličan broj AS-ova registriranih u Rusiji - 6230, od kojih nisu svi pružatelji usluga. i dobio 3940 tvrtki u 2017., a to je prije procjena odozgo. U svakom slučaju imamo dva i pol puta manji broj osvijetljenih AS-ova. Ali ovdje vrijedi razumjeti da AS nije striktno jednak davatelju. Neki pružatelji usluga nemaju vlastiti AS, neki imaju više od jednog. Ako pretpostavimo da svi još uvijek imaju agente, onda netko filtrira jače od drugih, tako da se njihovi zahtjevi ne mogu razlikovati od smeća, ako do njih uopće dospiju. Ali za grubu procjenu sasvim je podnošljivo, čak i ako se nešto izgubilo mojim previdom.
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 . Ova usporedba je sasvim opravdana i velika mreža agenata može biti od koristi. Na primjer, određivanje kvalitete dostupnosti resursa od različitih pružatelja usluga u različitim dijelovima zemlje. Možete izračunati kašnjenja, možete izgraditi grafikone, možete sve analizirati i vidjeti promjene koje se događaju i lokalno i globalno. Ovo nije najizravniji način, ali astronomi koriste "standardne svijeće", zašto ne koristiti agente? Poznavajući (pronašavši) njihovo standardno ponašanje, možete odrediti promjene koje se događaju oko njih i kako to utječe na kvalitetu pruženih usluga. U isto vrijeme, ne morate samostalno postavljati sonde na mrežu; Roskomnadzor ih je već instalirao.
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