Nu este un secret că monitorizarea blocajelor pe lista informațiilor interzise în Rusia este realizată de un sistem automatizat numit „Revisor”. Cum funcționează acest sistem este explicat suficient de bine în acest , imaginea de acolo:
Direct la furnizor se instalează :
Modulul „Agent Revisor” este un element structural al sistemului automatizat „Revisor” (AS „Revisor”). Acest sistem este destinat monitorizării respectării cerințelor de către operatorii de telecomunicații în ceea ce privește restricționarea accesului conform prevederilor stabilite de articolele 15.1-15.4 din Legea federală din 27 iulie 2006 nr. 149-FZ „Despre informații, tehnologiile informației și protecția informației”.
Principalul scop al creării AS „Revisor” este asigurarea monitorizării respectării cerințelor stabilite de articolele 15.1-15.4 din Legea federală din 27 iulie 2006 nr. 149-FZ „Despre informații, tehnologiile informației și protecția informației” în ceea ce privește identificarea cazurilor de acces la informații interzise și obținerea de materiale (date) probante despre abaterile de la restricționarea accesului la informațiile interzise.
Având în vedere că, dacă nu toate, atunci mulți furnizori au instalat acest dispozitiv la ei, ar fi trebuit să rezulte o rețea mare de dispozitive de tip probe-far, asemănătoare cu și chiar mai mult, dar cu acces restricționat. Totuși, un far este un far care trimite semnale în toate direcțiile, iar ce se întâmplă dacă le captăm și vedem ce am prins și cât de mult?
Înainte de a număra, să vedem de ce ar putea fi acest lucru posibil.
Puțină teorie
Agenții verifică accesibilitatea resursului, inclusiv prin trimiterea de solicitări HTTP(S), cum ar fi aceasta, de exemplu:
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"
Solicitarea, pe lângă încărcătura utilă, constă și dintr-o fază de inițiere a conexiunii: schimb SYN și SYN-ACK, și faza de finalizare a conexiunii: FIN-ACK.
Registrul informațiilor interzise conține mai multe tipuri de blocaje. Evident, dacă resursa este blocată după adresa IP sau numele de domeniu, nu vom vedea nicio solicitare. Acestea sunt cele mai devastatoare tipuri de blocaje, care conduc la inaccesibilitatea tuturor resurselor pe o singură adresă IP sau a tuturor informațiilor de pe un domeniu. Există, de asemenea, tipul de blocare "după URL". În acest caz, sistemul de filtrare trebuie să analizeze antetul HTTP al solicitării pentru a determina exact ce trebuie blocat. Iar înainte de aceasta, așa cum se vede mai sus, trebuie să aibă loc faza de stabilire a conexiunii, pe care putem încerca să o monitorizăm, deoarece probabil filtru o va lăsa să treacă.
Pentru aceasta, trebuie să alegem un domeniu liber potrivit cu tipul de blocare "după URL" și HTTP, pentru a facilita munca sistemului de filtrare, de preferință unul abandonat de mult timp, pentru a minimiza traficul străin, în afară de cel provenit de la Agenți. Această sarcină s-a dovedit a fi deloc complicată; există suficiente domenii libere în registrul informațiilor interzise și pentru toate gusturile. Prin urmare, domeniul a fost achiziționat, legat de adresele IP pe VPS cu instalat tcpdump și a început numărarea.
Revizuirea "Revizorului"
M-am așteptat să văd vârfuri periodice de solicitări, ceea ce mi-ar fi sugerat o acțiune controlată. Nu pot spune că nu am observat deloc acest lucru, dar nu existau rezultate clare:
Ce nu este surprinzător, chiar și pe un domeniu inutil și pe o adresă IP care nu este utilizată niciodată, va sosi pur și simplu o masă imensă de informații necerute, așa este Internetul modern. Dar, din fericire, aveam nevoie doar de solicitări specificate pentru URL, așa că toate scanerele și brute forcer-urile au fost rapid identificate. De asemenea, a fost destul de simplu să înțeleg unde se află fluxul de solicitări similare. Apoi, am realizat frecvențele apariției adreselor IP și am făcut un tur manual prin tot topul, separându-i pe cei care au trecut prin etapele anterioare. În plus, am eliminat toate sursele care au trimis câte un pachet, acestea nu mai erau multe. Și a rezultat aceasta:
O mic răgaz liric. Cu puțin mai mult de 24 de ore mai târziu, providerul meu de hosting mi-a trimis un e-mail cu un conținut destul de vag, spunând că pe serverele dumneavoastră există resurse dintr-o listă interzisă de către RKN, așa că acestea sunt blocate. La început am crezut că mi-au blocat contul, dar nu a fost așa. Apoi am crezut că mă avertizează despre ceva ce știam deja. Dar s-a dovedit că gazda a activat filtrul său înainte de domeniul meu și, în consecință, am fost sub o dublă filtrare: din partea providerilor și din partea gazdei. Filtrul permitea doar capetele cererilor: FIN-ACK și RST tăind tot HTTP pe URL-ul interzis. Așa cum se vede în graficul de mai sus, după primele 24 de ore am început să primesc mai puține date, dar tot le-am obținut, ceea ce a fost suficient pentru a contabiliza sursele cererilor.
Pe scurt. Din punctul meu de vedere, se văd destul de clar două vârfuri în fiecare zi, primul mai mic, după miezul nopții în Moscova, al doilea aproape de 6 dimineața cu un coadă până la 12. Vârful nu coincide exact cu același moment. La început am vrut să identific adresele IP care apăreau doar în aceste perioade și fiecare în toate perioadele, pe baza presupunerii că verificările de către Agenți se fac periodic. Dar, după o examinare atentă, am descoperit destul de repede perioade care se încadrează în alte intervale, cu alte frecvențe, până la o cerere la fiecare oră. Apoi m-am gândit la fusurile orare și că poate este vorba despre asta, apoi m-am gândit că întregul sistem poate să nu fie sincronizat global. În plus, desigur, NAT-ul va avea un rol de jucat și același Agent poate face cereri din IP-uri publice diferite.
Având în vedere că scopul meu inițial nu a fost exactitatea, am numărat în general toate adresele întâlnite în decurs de o săptămână și am obținut - 2791. Numărul de sesiuni TCP stabilite dintr-o adresă este, în medie, 4, cu o mediană de 2. Cele mai multe sesiuni pe adresă: 464, 231, 149, 83, 77. Maximum dintr-o eșantionare de 95% - 8 sesiuni pe adresă. Mediana nu este foarte ridicată, reamintesc că în grafic se vede o periodicitate zilnică clară, așa că teoretic ar fi putut fi așteptat ceva între 4 și 8 în 7 zile. Dacă excluz toate sesiunile întâlnite o singură dată, tocmai obținem o medie de 5. Dar nu am putut să le exclud pe baza unui criteriu clar. Dimpotrivă, o verificare aleatoare a arătat că au legătură cu cererile resurselor interzise.
Adresele sunt importante, dar în internet sistemele autonome — AS, de care s-au obținut 1510, în medie 2 adrese pe AS cu o mediană de 1. Topul adreselor pe AS: 288, 77, 66, 39, 27. Maximul din 95% din eșantion — 4 adrese pe AS. Aici, mediana este așteptată — un Agent per furnizor. Topul este, de asemenea, așteptat — include jucători mari. Într-o rețea mare, Agenții ar trebui probabil să fie prezenți în fiecare regiune în care activează operatorul, nici nu uităm de NAT. Dacă ne uităm pe țări, maximele vor fi: 1409 — RU, 42 — UA, 23 — CZ, 36 din alte regiuni, nu RIPE NCC. Cererile din afara Rusiei atrag atenția. Probabil, acest lucru poate fi explicat prin erori de geolocație sau prin greșelile registratorilor la completarea datelor. Sau că o companie rusă poate avea rădăcini ne-rusești sau poate avea un reprezentant străin, deoarece este mai simplu, având de-a face cu organizația străină RIPE NCC. O anumită parte este, fără îndoială, redundantă, dar este dificil să o separăm cu acuratețe, deoarece resursa este blocată, iar după două zile este sub o dublă blocare și majoritatea sesiunilor constau doar în schimbul câtorva pachete de servicii. Să presupunem că aceasta este o parte mică.
Aceste numere pot fi deja comparate cu numărul furnizorilor din Rusia. licențe pentru „Servicii de comunicație pentru transferul de date, cu excepția vocii” — 6387, dar aceasta este o estimare exagerată, nu toate aceste licențe se referă în mod special la furnizorii de internet care trebuie să instaleze un Agent. În zona RIPE NCC, un număr similar de AS este înregistrat în Rusia — 6230, dintre care nu toți sunt furnizori. și a obținut 3940 de companii în 2017, iar aceasta este mai mult o estimare superioară. În orice caz, avem un număr de AS detectate de două ori și jumătate mai mic. Dar aici trebuie înțeles că AS nu este strict egal cu furnizorul. Unii furnizori nu au propriul AS, alții au mai mult de unul. Dacă presupunem că Agenții sunt totuși prezenți la toți, atunci cineva filtrează mai sever decât ceilalți, astfel că cererile lor sunt indistinguibile de gunoi dacă ajung cu adevărat. Dar pentru o estimare brută este destul de tolerabil, chiar dacă s-a pierdut ceva din cauza neglijenței mele.
Despre DPI
Deși furnizorul meu de găzduire a activat filtrul său începând cu a doua zi, din informațiile din prima zi se poate concluziona că blocările funcționează eficient. Doar 4 surse au reușit să treacă și au sesiuni HTTP și TCP complet finalizate (așa cum este exemplul de mai sus). În plus, 460 pot trimite metoda GET., dar sesiunea se întrerupe instantaneu prin RST. Vă rugăm să observați 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"
#Acesta a fost trimis de filtrul
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#Iar aceasta este încercarea nodului sursă de a obține pierderea
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"
#Nodul sursă înțelege că sesiunea a fost distrusă
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Varianta acestuia poate fi diferită: mai puține RST sau mai multe retransmisiuni — depinde de ceea ce filtrele trimit nodului sursă. În orice caz, acesta este modelul cel mai de încredere, din care se vede că a fost solicitat de fapt resursa interzisă. În plus, există întotdeauna un răspuns care apare în sesiunea cu TTL mai mult decât în pachetele anterioare și ulterioare.
La celelalte nu se vede nici măcar metoda GET.:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Acesta a fost trimis de filtrul
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Sau așa:
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"
#Acesta a fost trimis de filtrul
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"
#Din nou filtrul, de multe ori
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Este întotdeauna evidentă diferența în TTL dacă ceva vine de la filtrul. Dar adesea poate să nu vină nimic:
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"
...
Sau așa:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Au trecut câteva secunde fără trafic
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Și totul se repetă și se repetă și se repetă, după cum se vede în grafic, cu siguranță nu o dată, în fiecare zi.
Despre IPv6
Veste bună — există. Pot spune cu certitudine că din 5 adrese IPv6 diferite se fac cereri periodice către o resursă interzisă, exact comportamentul Agenților pe care l-am așteptat. În plus, una dintre adresele IPv6 nu este supusă filtrării și văd o sesiune completă. De la alte două, am observat doar câte o sesiune nefinalizată, dintre care una s-a întrerupt din cauza RST filtrului, iar cealaltă din cauza timpului. În total 7.
Așa cum adresele sunt puține, le-am studiat în detaliu și s-a dovedit că, de fapt, există doar 3 furnizori, merită aplauze! O altă adresă este un serviciu de cloud hosting în Rusia (nu filtrează), iar o alta este un centru de cercetare în Germania (există filtrare, unde?). Întrebarea este însă de ce verifică periodic disponibilitatea resurselor interzise. Celelalte două au făcut câte o cerere și se află în afara Rusiei, iar una dintre ele este filtrată (totuși în tranzit?).
Blocările și Agenții reprezintă un mare impediment pentru IPv6, al cărui implementare oricum progresează lent. Este trist. Cei care au rezolvat această problemă pe deplin se pot mândri cu realizările lor.
În concluzie
Nu am căutat 100% precizie, vă rog să mă iertați pentru asta; sper că cineva va dori să repete o astfel de lucrare cu mai multă atenție. A fost important pentru mine să înțeleg dacă o astfel de abordare va funcționa, iar răspunsul este — va funcționa. Datele obținute sunt, în prima aproximare, cred eu, destul de fiabile.
Ce s-ar mai putea face și de ce am fost prea leneș să fac — să număr cererile DNS. Ele nu sunt filtrate, dar nici nu oferă o mare precizie, deoarece funcționează doar pentru domeniu și nu pentru întreaga adresă URL. Ar trebui să se observe periodicitatea. Dacă combinăm cu ceea ce se vede direct în cereri, aceasta ar permite eliminarea informațiilor în plus și obținerea de mai multe detalii. Poate chiar să identificăm dezvoltatorii DNS utilizați de furnizori și multe altele.
Nu m-am așteptat deloc ca pentru VPS-ul meu, furnizorul să activeze și propriul filtru. Poate că aceasta este o practică obișnuită. În final, RKN trimite cereri de ștergere a resurselor tocmai către furnizor. Dar nu m-a uimit și chiar a fost, în anumite privințe, benefic. Filtrul a funcționat foarte eficient și a oprit toate cererile HTTP corecte către URL-ul interzis, însă cele incorecte, care au trecut anterior prin filtrul furnizorilor, au ajuns, chiar dacă doar sub formă de finaluri: FIN-ACK și RST — minus la minus și aproape a rezultat plus. Apropo, gazda IPv6 nu a fost filtrată. Desigur, acest lucru a afectat calitatea materialului colectat, dar totuși a oferit oportunitatea de a observa periodicitatea. S-a dovedit a fi un aspect important în alegerea platformei pentru găzduirea resurselor, nu uitați să vă interesați de organizarea lucrului cu lista site-urilor interzise și cererile din partea RKN.
La început, am comparat AS „Revizor” cu . Această comparație este pe deplin justificată, iar o rețea mare de Agenți poate aduce beneficii. De exemplu, determinarea calității accesibilității resursei din diverse furnizori din diferite părți ale țării. Se pot calcula întârzierile, se pot construi grafice, se poate analiza totul și se pot observa modificările care au loc atât local, cât și global. Aceasta nu este cea mai directă cale, dar astronomii folosesc „lumânări standard”, de ce să nu folosim Agenții? Cunoașterea (găsirea) comportamentului lor standard poate ajuta la determinarea modificărilor care au loc în jurul lor și cum acestea influențează calitatea serviciilor oferite. Și, în plus, nu trebuie să plasați probe în rețea, acestea au fost deja plasate de Roskomnadzor.
Încă un aspect pe care vreau să-l abordez este că fiecare instrument poate fi o armă. AS „Revizor” este o rețea închisă, dar Agenții dezvăluie totul trimisând cereri către toate resursele din lista interzisă. Obținerea unei astfel de resurse nu prezintă vreo problemă. Prin urmare, furnizorii prin intermediul Agenților, fără să vrea, povestesc despre rețeaua lor mult mai mult decât ar merita: tipuri DPI și DNS, locația Agentului (nucleului central și rețelei de serviciu?), markeri de întârzieri și pierderi — și aceasta este doar cea mai evidentă parte. La fel cum cineva poate monitoriza acțiunile Agenților pentru a îmbunătăți accesibilitatea resurselor lor, altcineva poate face acest lucru în alte scopuri și nu există obstacole în acest sens. S-a dovedit a fi un instrument cu două tăișuri și foarte complex, oricine poate verifica acest lucru.
Sursa: habr.com
