Ni skrivnost, da nadzor blokiranja na seznamu prepovedanih informacij v Rusiji spremlja avtomatizirani sistem "Inšpektor". Kako deluje, je dobro napisano tukaj , slika z istega mesta:
Montira se direktno pri ponudniku :
Modul "Agent Inspector" je strukturni element avtomatiziranega sistema "Inspector" (AS "Inspector"). Ta sistem je zasnovan za spremljanje skladnosti telekomunikacijskih operaterjev z zahtevami za omejitev dostopa v okviru določb iz členov 15.1-15.4 zveznega zakona z dne 27. julija 2006 št. 149-FZ »O informacijah, informacijskih tehnologijah in varstvu informacij«. ”
Glavni namen ustanovitve AS "Revizor" je zagotoviti spremljanje skladnosti telekomunikacijskih operaterjev z zahtevami, ki jih določajo členi 15.1-15.4 zveznega zakona z dne 27. julija 2006 št. 149-FZ "O informacijah, informacijskih tehnologijah in varstvu informacij". " v smislu ugotavljanja dejstev dostopa do prepovedanih informacij in pridobivanja dokazil (podatkov) o kršitvah za omejitev dostopa do prepovedanih informacij.
Upoštevajoč dejstvo, da so to napravo namestili, če ne vsi, pa številni ponudniki, bi morala obstajati velika mreža svetilnih sond, npr. in še več, vendar z zaprtim dostopom. Vendar je svetilnik svetilnik, ki pošilja signale v vse smeri, kaj pa, če jih ujamemo in vidimo, kaj smo ujeli in koliko?
Preden začnemo šteti, poglejmo, zakaj je to sploh mogoče.
Malo teorije
Agenti preverjajo razpoložljivost vira, vključno z zahtevami HTTP(S), kot je ta:
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"
Zahtevo poleg koristnega tovora sestavlja tudi faza vzpostavitve povezave: izmenjava SYN и SYN-ACK, in faze zaključka povezave: FIN-ACK.
Register prepovedanih informacij vsebuje več vrst blokad. Očitno je, da če je vir blokiran z naslovom IP ali imenom domene, potem ne bomo videli nobenih zahtev. To so najbolj destruktivne vrste blokad, ki vodijo do nedostopnosti vseh virov na enem naslovu IP ali vseh informacij na domeni. Obstaja tudi vrsta blokiranja »po URL-ju«. V tem primeru mora sistem za filtriranje razčleniti glavo zahteve HTTP, da natančno določi, kaj naj blokira. In pred njo, kot je razvidno zgoraj, bi morala obstajati faza vzpostavitve povezave, ki ji lahko poskusite slediti, saj jo bo najverjetneje filter zamudil.
Če želite to narediti, morate izbrati ustrezno brezplačno domeno z »URL« in vrsto blokiranja HTTP, da olajšate delo filtrirnega sistema, po možnosti že dolgo opuščenega, da čim bolj zmanjšate vstop tujega prometa, razen od agentov. Izkazalo se je, da ta naloga ni težka, prostih domen v registru prepovedanih informacij je kar nekaj in za vsak okus. Zato je bila domena kupljena in povezana z IP naslovi na delujočem VPS tcpdump in začelo se je štetje.
Revizija "revizorjev"
Pričakoval sem občasne izbruhe zahtev, kar bi po mojem mnenju pomenilo nadzorovano ukrepanje. Nemogoče je reči, da tega sploh nisem videl, vendar jasne slike zagotovo ni bilo:
Kar ni presenetljivo, tudi na domeni, ki je nihče ne potrebuje, in na nikoli uporabljenem IP-ju bo enostavno ogromno nezaželenih informacij, takšen je sodobni internet. Toda na srečo sem potreboval le zahteve za določen URL, tako da so bili vsi skenerji in krekerji gesel hitro najdeni. Prav tako je bilo na podlagi množice podobnih zahtev precej enostavno razumeti, kje je bila poplava. Nato sem sestavil pogostost pojavljanja naslovov IP in šel skozi celoten vrh ročno, pri čemer sem ločil tiste, ki so ga zamudili na prejšnjih stopnjah. Dodatno sem izrezal vse vire, ki so bili poslani v enem paketu, ni jih bilo več veliko. In to se je zgodilo:
Majhna lirična digresija. Nekaj več kot dan kasneje je moj ponudnik gostovanja poslal pismo precej poenostavljene vsebine, v katerem piše, da vaši objekti vsebujejo vir s seznama prepovedanih RKN, zato je blokiran. Najprej sem mislil, da je moj račun blokiran, vendar ni bilo tako. Potem sem mislil, da me preprosto opozarjajo na nekaj, kar že vem. Izkazalo pa se je, da je hoster vklopil svoj filter pred mojo domeno in posledično sem prišel pod dvojno filtriranje: od ponudnikov in od hosterja. Filter je prešel samo konce zahtev: FIN-ACK и RST prekinitev vsega HTTP-ja na prepovedanem URL-ju. Kot je razvidno iz zgornjega grafa, sem po prvem dnevu začel dobivati manj podatkov, a sem jih vseeno prejel, kar je bilo povsem dovolj za nalogo štetja virov zahtev.
Preidi k bistvu. Po mojem mnenju sta vsak dan jasno vidna dva izbruha, prvi manjši, po polnoči po moskovskem času, drugi bližje 6. uri zjutraj z repom do 12. ure. Vrh se ne pojavi ob istem času. Najprej sem želel izbrati IP naslove, ki so padli samo v teh obdobjih in vsak v vseh obdobjih, na podlagi predpostavke, da se pregledi agentov izvajajo periodično. Toda po natančnem pregledu sem hitro odkril obdobja, ki spadajo v druge intervale, z drugimi frekvencami, do ena zahteva vsako uro. Potem sem pomislil na časovne pasove in da je morda to povezano z njimi, potem pa sem pomislil, da na splošno sistem morda ni globalno sinhroniziran. Poleg tega bo NAT verjetno igral vlogo in isti agent lahko pošilja zahteve z različnih javnih IP-jev.
Ker moj začetni cilj ni bil točno določen, sem preštel vse naslove, ki sem jih naletel v enem tednu in dobil - 2791. Število sej TCP, vzpostavljenih z enega naslova, je v povprečju 4, z mediano vrednostjo 2. Najboljše seje na naslov: 464, 231, 149, 83, 77. Največ od 95 % vzorca je 8 sej na naslov. Mediana ni zelo visoka, naj vas spomnim, da graf kaže jasno dnevno periodičnost, tako da bi lahko pričakovali nekaj okoli 4 do 8 v 7 dneh. Če izločimo vse seje, ki se zgodijo enkrat, bomo dobili mediano enako 5. Vendar jih nisem mogel izključiti na podlagi jasnega kriterija. Nasprotno, naključno preverjanje je pokazalo, da so povezani z zahtevami po prepovedanem viru.
Naslovi so naslovi, na internetu pa avtonomni sistemi – AS, ki so se izkazali za pomembnejše 1510, v povprečju 2 naslova na AS z mediano 1. Najvišji naslovi na AS: 288, 77, 66, 39, 27. Največ 95 % vzorca so 4 naslovi na AS. Tukaj je pričakovana mediana - en agent na ponudnika. Pričakujemo tudi vrh - v njem so veliki igralci. V velikem omrežju bi morali biti agenti verjetno nameščeni v vsaki regiji prisotnosti operaterja in ne pozabite na NAT. Če vzamemo po državah, bodo maksimumi: 1409 - RU, 42 - UA, 23 - CZ, 36 iz drugih regij, ne RIPE NCC. Zahteve izven Rusije pritegnejo pozornost. To je verjetno mogoče pojasniti z geolokacijskimi napakami ali napakami registrarjev pri izpolnjevanju podatkov. Ali dejstvo, da rusko podjetje morda nima ruskih korenin ali ima tuje predstavništvo, ker je to lažje, kar je naravno, če imate opravka s tujo organizacijo RIPE NCC. Del je nedvomno odvečen, vendar ga je zanesljivo težko ločiti, saj je vir v blokadi, od drugega dne pa v dvojni blokadi, večina sej pa je le izmenjava več servisnih paketov. Strinjajmo se, da je to majhen del.
Te številke je že mogoče primerjati s številom ponudnikov v Rusiji. licence za “Komunikacijske storitve za prenos podatkov, razen govora” - 6387, vendar je to zelo visoka ocena od zgoraj, vse te licence ne veljajo posebej za internetne ponudnike, ki morajo namestiti agenta. V coni RIPE NCC je podobno število AS, registriranih v Rusiji - 6230, od katerih niso vsi ponudniki. in prejel 3940 podjetij v letu 2017, in to je bolj ocena od zgoraj. V vsakem primeru imamo dvainpolkrat manj osvetljenih AS. Toda tukaj je vredno razumeti, da AS ni strogo enak ponudniku. Nekateri ponudniki nimajo svojega AS, nekateri jih imajo več kot enega. Če predpostavimo, da imajo vsi še vedno agente, potem nekdo filtrira močneje kot drugi, tako da se njegove zahteve ne razlikujejo od smeti, če jih sploh dosežejo. Je pa za grobo oceno kar znosno, četudi se je zaradi moje spregledljivosti kaj izgubilo.
O DPI
Kljub temu, da je moj ponudnik gostovanja svoj filter vklopil že drugi dan, lahko na podlagi podatkov prvega dne sklepamo, da blokada uspešno deluje. Samo 4 viri so lahko prišli skozi in so popolnoma zaključili seje HTTP in TCP (kot v zgornjem primeru). Lahko jih pošljete še 460 GET, vendar se sejo takoj prekine RST. Bodi pozoren 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"
Različice tega so lahko različne: manj RST ali več ponovnih prenosov - odvisno tudi od tega, kaj filter pošlje izvornemu vozlišču. V vsakem primeru je to najbolj zanesljiv predlog, iz katerega je razvidno, da je bil zahtevan prepovedan vir. Poleg tega se v seji vedno pojavi odgovor z TTL večji kot v prejšnjih in naslednjih paketih.
Od ostalih se tega sploh 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"
Ali tako:
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 je vsekakor vidna TTL če pride kaj iz filtra. Toda pogosto sploh ne pride nič:
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"
...
Ali tako:
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"
...
In vse to se ponavlja in ponavlja in ponavlja, kot je razvidno iz grafa, več kot enkrat, vsak dan.
O IPv6
Dobra novica je, da obstaja. Zanesljivo lahko trdim, da se občasne zahteve za prepovedan vir pojavljajo s 5 različnih naslovov IPv6, kar je točno takšno obnašanje agentov, kot sem pričakoval. Poleg tega eden od naslovov IPv6 ne spada med filtriranje in vidim celotno sejo. Od dveh drugih sem videl samo eno nedokončano sejo, od katere je bila ena prekinjena z RST iz filtra, drugi po času. Skupni znesek 7.
Ker je naslovov malo, sem jih vse podrobno preučila in izkazalo se je, da so tam samo 3 ponudniki, ki jim lahko priredimo stoječe ovacije! Drugi naslov je gostovanje v oblaku v Rusiji (ne filtrira), drugi je raziskovalni center v Nemčiji (obstaja filter, kje?). Toda zakaj preverjajo razpoložljivost prepovedanih virov po urniku, je dobro vprašanje. Preostala dva sta podala eno zahtevo in se nahajata zunaj Rusije, eden od njiju pa je filtriran (navsezadnje v tranzitu?).
Blokiranje in agenti so velika ovira za IPv6, katerega implementacija se ne premika prav hitro. Žalostno je. Tisti, ki so rešili ta problem, so lahko popolnoma ponosni nase.
Na koncu
Nisem si prizadeval za 100-odstotno natančnost, oprostite mi za to, upam, da bo kdo želel to delo ponoviti z večjo natančnostjo. Zame je bilo pomembno razumeti, ali bo ta pristop načeloma deloval. Odgovor je pritrdilen. Dobljene številke se mi zdijo kot prvi približek precej zanesljive.
Kaj drugega bi lahko naredili in kar sem bil prelen, je bilo štetje zahtev DNS. Niso filtrirani, vendar tudi ne zagotavljajo veliko natančnosti, saj delujejo samo za domeno in ne za celoten URL. Frekvenca mora biti vidna. Če ga kombinirate s tistim, kar je vidno neposredno v poizvedbah, vam bo to omogočilo, da ločite nepotrebno in pridobite več informacij. Možno je celo določiti razvijalce DNS, ki jih uporabljajo ponudniki in še veliko več.
Absolutno nisem pričakoval, da bo hoster vključil tudi svoj filter za moj VPS. Mogoče je to običajna praksa. Na koncu RKN gostitelju pošlje zahtevo za izbris vira. A to me ni presenetilo in mi je na nek način celo koristilo. Filter je deloval zelo učinkovito, saj je prekinil vse pravilne zahteve HTTP na prepovedan URL, pravilne, ki so predhodno šle skozi filter ponudnika, pa jih niso dosegle, čeprav le v obliki končnic: FIN-ACK и RST - minus za minus in skoraj se je izkazalo za plus. Mimogrede, gostitelj IPv6 ni filtriral. To je seveda vplivalo na kakovost zbranega materiala, a je vseeno omogočilo vpogled v frekvenco. Izkazalo se je, da je to pomembna točka pri izbiri mesta za postavitev virov, ne pozabite se zanimati za vprašanje organizacije dela s seznamom prepovedanih mest in zahtevkov RKN.
Na začetku sem primerjal AS "Inšpektor" z . Ta primerjava je povsem upravičena in velika mreža zastopnikov je lahko koristna. Na primer ugotavljanje kakovosti razpoložljivosti virov pri različnih ponudnikih v različnih delih države. Lahko izračunate zamude, lahko zgradite grafe, vse to lahko analizirate in vidite spremembe, ki se dogajajo tako lokalno kot globalno. To ni najbolj neposreden način, vendar astronomi uporabljajo "standardne sveče", zakaj ne bi uporabili agentov? Če poznate (če ugotovite) njihovo standardno vedenje, lahko ugotovite spremembe, ki se dogajajo okoli njih, in kako to vpliva na kakovost ponujenih storitev. In hkrati vam ni treba samostojno postavljati sond v omrežje; Roskomnadzor jih je že namestil.
Druga točka, ki se je želim dotakniti, je, da je vsako orodje lahko orožje. AS "Inšpektor" je zaprto omrežje, vendar Agenti vse predajo s pošiljanjem zahtevkov za vse vire s seznama prepovedanih. Imeti takšen vir sploh ne predstavlja nobenih težav. Skupaj ponudniki prek agentov nehote povedo veliko več o svojem omrežju, kot je verjetno vredno: vrste DPI in DNS, lokacija agenta (centralno vozlišče in servisno omrežje?), omrežni označevalci zamud in izgub - in to je samo najbolj očitne. Tako kot lahko nekdo spremlja dejanja agentov za izboljšanje razpoložljivosti njihovih virov, lahko nekdo to počne za druge namene in za to ni nobenih ovir. Rezultat je dvorezen in zelo večplasten instrument, to lahko vidi vsak.
Vir: www.habr.com