Să numărăm agenții „Inspector”

Nu este un secret pentru nimeni faptul că controlul blocării pe lista informațiilor interzise în Rusia este monitorizat de sistemul automat „Inspector”. Cum funcționează este scris bine aici în acest articol articol despre Habr, poza din acelasi loc:

Să numărăm agenții „Inspector”

Instalat direct la furnizor modulul „Agent Inspector”:

Modulul „Agent Inspector” este un element structural al sistemului automatizat „Inspector” (AS „Inspector”). Acest sistem este conceput pentru a monitoriza respectarea de către operatorii de telecomunicații a cerințelor de restricție de acces în cadrul prevederilor stabilite de articolele 15.1-15.4 din Legea federală din 27 iulie 2006 nr. 149-FZ „Cu privire la informații, tehnologii informaționale și protecția informațiilor. ”

Scopul principal al creării AS „Revizor” este de a asigura monitorizarea conformității operatorilor de telecomunicații cu cerințele stabilite de articolele 15.1-15.4 din Legea federală din 27 iulie 2006 nr. 149-FZ „Cu privire la informații, tehnologii informaționale și protecția informațiilor”. „în ceea ce privește identificarea faptelor de acces la informații interzise și obținerea de materiale justificative (date) despre încălcări pentru a restricționa accesul la informații interzise.

Ținând cont de faptul că, dacă nu toți, atunci mulți furnizori au instalat acest dispozitiv, ar fi trebuit să existe o rețea mare de sonde de baliză precum Atlas COPT si chiar mai mult, dar cu acces inchis. Totuși, un far este un far pentru a trimite semnale în toate direcțiile, dar dacă le prindem și vedem ce am prins și câte?

Înainte de a număra, să vedem de ce ar putea fi chiar posibil acest lucru.

Un pic de teorie

Agenții verifică disponibilitatea unei resurse, inclusiv prin solicitări HTTP(S), cum ar fi aceasta:

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"

Pe lângă sarcina utilă, cererea constă și într-o fază de stabilire a conexiunii: schimb SYN и SYN-ACK, și fazele de finalizare a conexiunii: FIN-ACK.

Registrul informațiilor interzise conține mai multe tipuri de blocare. Evident, dacă o resursă este blocată de adresa IP sau numele de domeniu, atunci nu vom vedea nicio solicitare. Acestea sunt cele mai distructive tipuri de blocare, care duc la inaccesibilitatea tuturor resurselor de pe o adresă IP sau a tuturor informațiilor de pe un domeniu. Există, de asemenea, un tip de blocare „după URL”. În acest caz, sistemul de filtrare trebuie să analizeze antetul cererii HTTP pentru a determina exact ce să blocheze. Și înainte de aceasta, așa cum se poate vedea mai sus, ar trebui să existe o fază de stabilire a conexiunii pe care puteți încerca să o urmăriți, deoarece cel mai probabil filtrul o va rata.

Pentru a face acest lucru, trebuie să selectați un domeniu gratuit adecvat cu tipul de blocare „URL” și HTTP pentru a facilita munca sistemului de filtrare, de preferință abandonat de mult timp, pentru a minimiza intrarea traficului extern, cu excepția agenților. Această sarcină sa dovedit a fi deloc dificilă; există destul de multe domenii gratuite în registrul de informații interzise și pentru toate gusturile. Prin urmare, domeniul a fost achiziționat și legat de adrese IP pe un VPS care rulează tcpdump iar numărătoarea a început.

Auditul „auditorilor”

Mă așteptam să văd explozii periodice de solicitări, care, în opinia mea, ar indica o acțiune controlată. Este imposibil să spun că nu l-am văzut deloc, dar cu siguranță nu a existat o imagine clară:

Să numărăm agenții „Inspector”

Ceea ce nu este surprinzător, chiar și pe un domeniu de care nimeni nu are nevoie și pe un IP nefolosit, pur și simplu vor exista o mulțime de informații nesolicitate, cum ar fi internetul modern. Dar, din fericire, aveam nevoie doar de solicitări pentru o anumită adresă URL, așa că toate scanerele și crackerele de parole au fost găsite rapid. De asemenea, a fost destul de ușor de înțeles unde s-a bazat potopul pe masa de cereri similare. În continuare, am compilat frecvența de apariție a adreselor IP și am parcurs manual întregul top, separându-i pe cei care au ratat-o ​​în etapele anterioare. În plus, am tăiat toate sursele care au fost trimise într-un singur pachet, nu mai erau multe dintre ele. Și iată ce s-a întâmplat:

Să numărăm agenții „Inspector”

O mică digresiune lirică. Puțin mai mult de o zi mai târziu, furnizorul meu de găzduire a trimis o scrisoare cu un conținut destul de raționalizat, spunând că facilitățile tale conțin o resursă din lista interzisă RKN, deci este blocată. La început am crezut că mi-a fost blocat contul, nu a fost cazul. Apoi m-am gândit că pur și simplu mă avertizează despre ceva despre care știam deja. Dar s-a dovedit că hosterul și-a pornit filtrul în fața domeniului meu și ca urmare am intrat sub dublă filtrare: de la furnizori și de la hoster. Filtrul a trecut doar sfârșitul solicitărilor: FIN-ACK и RST întreruperea tuturor HTTP la o adresă URL interzisă. După cum puteți vedea din graficul de mai sus, după prima zi am început să primesc mai puține date, dar le-am primit în continuare, ceea ce a fost suficient pentru sarcina de a număra sursele de solicitare.

Treci la subiect. După părerea mea, două explozii sunt clar vizibile în fiecare zi, prima mai mică, după miezul nopții, ora Moscovei, a doua mai aproape de ora 6 dimineața cu coada până la 12 amiază. Vârful nu are loc exact în același timp. La început, am vrut să selectez adrese IP care au căzut doar în aceste perioade și fiecare în toate perioadele, pornind de la presupunerea că verificările de către Agenți sunt efectuate periodic. Dar la o revizuire atentă, am descoperit rapid perioade care se încadrează în alte intervale, cu alte frecvențe, până la o solicitare la fiecare oră. Apoi m-am gândit la fusurile orare și că poate avea ceva de-a face cu ele, apoi m-am gândit că în general sistemul s-ar putea să nu fie sincronizat global. În plus, NAT va juca probabil un rol și același agent poate face cereri de la diferite IP-uri publice.

Deoarece obiectivul meu inițial nu era exact, am numărat toate adresele pe care le-am întâlnit într-o săptămână și am primit - 2791. Numărul de sesiuni TCP stabilite de la o adresă este în medie de 4, cu o mediană de 2. Top sesiuni pe adresă: 464, 231, 149, 83, 77. Maximul de la 95% din eșantion este de 8 sesiuni pe adresă. Mediana nu este foarte mare, permiteți-mi să vă reamintesc că graficul arată o periodicitate zilnică clară, așa că ne-am putea aștepta la ceva în jur de 4 până la 8 în 7 zile. Dacă aruncăm toate ședințele care au loc o singură dată, vom obține o mediană egală cu 5. Dar nu le-aș putea exclude pe baza unui criteriu clar. Dimpotrivă, o verificare aleatorie a arătat că acestea erau legate de cereri pentru o resursă interzisă.

Adresele sunt adrese, dar pe Internet, sisteme autonome - AS, care s-au dovedit a fi mai importante 1510, în medie 2 adrese per AS cu mediana de 1. Adrese de top per AS: 288, 77, 66, 39, 27. Maximul de 95% din eșantion este de 4 adrese per AS. Aici se așteaptă mediana - un agent per furnizor. Ne așteptăm și la vârf - sunt jucători mari în el. Într-o rețea mare, agenții ar trebui probabil să fie localizați în fiecare regiune a prezenței operatorului și nu uitați de NAT. Daca o luam pe tara, maximele vor fi: 1409 - RU, 42 - UA, 23 - CZ, 36 din alte regiuni, nu RIPE NCC. Solicitările din afara Rusiei atrag atenția. Acest lucru poate fi explicat probabil prin erori de localizare geografică sau erori ale registratorului la completarea datelor. Sau faptul că o companie rusă poate să nu aibă rădăcini rusești, sau să aibă o reprezentanță în străinătate pentru că este mai ușor, ceea ce este firesc atunci când ai de-a face cu o organizație străină RIPE NCC. O parte este, fără îndoială, de prisos, dar este dificil să o separați, deoarece resursa este în blocare, iar din a doua zi sub blocare dublă, iar majoritatea sesiunilor sunt doar un schimb de mai multe pachete de servicii. Să fim de acord că aceasta este o mică parte.

Aceste numere pot fi deja comparate cu numărul de furnizori din Rusia. Potrivit RKN licențe pentru „Servicii de comunicații pentru transmisia de date, excluzând vocea” - 6387, dar aceasta este o estimare foarte mare de mai sus, nu toate aceste licențe se aplică în mod specific furnizorilor de internet care trebuie să instaleze un Agent. În zona RIPE NCC există un număr similar de AS înregistrate în Rusia - 6230, dintre care nu toți sunt furnizori. UserSide a făcut un calcul mai strict și a primit 3940 de companii în 2017, iar aceasta este mai degrabă o estimare de sus. În orice caz, avem de două ori și jumătate mai puțin număr de AS-uri iluminate. Dar aici merită să înțelegem că AS nu este strict egal cu furnizorul. Unii furnizori nu au propriul AS, alții au mai mult de unul. Dacă presupunem că toată lumea are în continuare Agenți, atunci cineva filtrează mai puternic decât alții, astfel încât solicitările lor să nu se distingă de gunoi, dacă ajung la ei. Dar pentru o evaluare grosieră este destul de tolerabil, chiar dacă s-a pierdut ceva din cauza supravegherii mele.

Despre DPI

În ciuda faptului că furnizorul meu de găzduire și-a activat filtrul începând din a doua zi, pe baza informațiilor din prima zi putem concluziona că blocarea funcționează cu succes. Doar 4 surse au reușit să treacă și au finalizat complet sesiunile HTTP și TCP (ca în exemplul de mai sus). Alte 460 pot fi trimise GET, dar sesiunea se încheie imediat de RST. fi atent la 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"

Variațiile acestuia pot fi diferite: mai puțin RST sau mai multe retransmite - depinde și de ceea ce trimite filtrul către nodul sursă. În orice caz, acesta este cel mai de încredere șablon, din care reiese clar că a fost o resursă interzisă care a fost solicitată. Plus că întotdeauna există un răspuns care apare în sesiunea cu TTL mai mare decât în ​​pachetele anterioare și ulterioare.

Nici nu se poate vedea din restul 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"

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"

#Вот это прислал фильтр
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"
...

Diferența este cu siguranță vizibilă TTL daca iese ceva din filtru. Dar de multe ori nu ajunge 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"

#Прошло несколько секунд без трафика

TCP, 80  >  14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

Și toate acestea se repetă și se repetă și se repetă, așa cum se vede pe grafic, de mai multe ori, în fiecare zi.

Despre IPv6

Vestea bună este că există. Pot spune cu încredere că solicitările periodice către o resursă interzisă apar de la 5 adrese IPv6 diferite, care este exact comportamentul agenților la care mă așteptam. Mai mult, una dintre adresele IPv6 nu intră sub filtrare și văd o sesiune completă. Din încă două am văzut o singură ședință neterminată, dintre care una a fost întreruptă de RST de la filtru, al doilea ca timp. Valoare totală 7.

Întrucât adresele sunt puține, le-am studiat pe toate în detaliu și s-a dovedit că acolo sunt doar 3 furnizori, pot fi ovaționați! O altă adresă este găzduirea în cloud în Rusia (nu filtrează), alta este un centru de cercetare în Germania (există un filtru, unde?). Dar de ce verifică disponibilitatea resurselor interzise într-un program este o întrebare bună. Cei doi rămași au făcut o singură cerere și se află în afara Rusiei, iar unul dintre ei este filtrat (în tranzit, până la urmă?).

Blocarea și agenții reprezintă o piedică mare pentru IPv6, a cărui implementare nu se mișcă foarte repede. Este trist. Cei care au rezolvat această problemă pot fi pe deplin mândri de ei înșiși.

în concluzie

Nu m-am străduit pentru acuratețe 100%, vă rog să mă iertați pentru asta, sper că cineva dorește să repete această lucrare cu mai multă acuratețe. A fost important pentru mine să înțeleg dacă această abordare va funcționa în principiu. Raspunsul este da. Cifrele obținute, ca primă aproximare, cred că sunt destul de sigure.

Ce altceva s-ar fi putut face și ceea ce mi-a fost prea lene să fac a fost să număr cererile DNS. Nu sunt filtrate, dar nici nu oferă prea multă acuratețe, deoarece funcționează doar pentru domeniu și nu pentru întreaga adresă URL. Frecvența ar trebui să fie vizibilă. Dacă îl combinați cu ceea ce este vizibil direct în interogări, acest lucru vă va permite să separați ceea ce nu este necesar și să obțineți mai multe informații. Este chiar posibil să se determine dezvoltatorii DNS-ului utilizat de furnizori și multe altele.

Nu mă așteptam ca hosterul să includă și propriul filtru pentru VPS-ul meu. Poate că aceasta este o practică obișnuită. În cele din urmă, RKN trimite o cerere de ștergere a resursei către hoster. Dar acest lucru nu m-a surprins și, în anumite privințe, chiar a funcționat în avantajul meu. Filtrul a funcționat foarte eficient, întrerupând toate solicitările HTTP corecte către o adresă URL interzisă, dar nu cele corecte care trecuseră anterior prin filtrul furnizorilor le-au ajuns, deși numai sub formă de terminații: FIN-ACK и RST - minus pentru minus și aproape s-a dovedit a fi un plus. Apropo, IPv6 nu a fost filtrat de către hoster. Desigur, acest lucru a afectat calitatea materialului colectat, dar a permis totuși să se vadă frecvența. S-a dovedit că acesta este un punct important atunci când alegeți un site pentru plasarea resurselor; nu uitați să vă interesați de problema organizării muncii cu lista de site-uri interzise și solicitările de la RKN.

La început am comparat AS „Inspectorul” cu Atlas COPT. Această comparație este destul de justificată și o rețea mare de agenți poate fi benefică. De exemplu, determinarea calității disponibilității resurselor de la diferiți furnizori din diferite părți ale țării. Puteți calcula întârzierile, puteți construi grafice, puteți analiza totul și puteți vedea schimbările care apar atât la nivel local, cât și global. Acesta nu este cel mai direct mod, dar astronomii folosesc „lumânări standard”, de ce nu folosesc agenți? Cunoscând (fiind găsit) comportamentul lor standard, puteți determina schimbările care apar în jurul lor și modul în care aceasta afectează calitatea serviciilor oferite. Și, în același timp, nu trebuie să plasați independent sonde în rețea; Roskomnadzor le-a instalat deja.

Un alt punct pe care vreau să îl ating este că fiecare unealtă poate fi o armă. AS „Inspector” este o rețea închisă, dar Agenții predau pe toți trimițând cereri pentru toate resursele din lista interzise. A avea o astfel de resursă nu prezintă deloc probleme. În total, furnizorii prin agenți, fără să vrea, spun mult mai multe despre rețeaua lor decât merită probabil: tipurile DPI și DNS, locația agentului (nodul central și rețeaua de servicii?), markeri de rețea ai întârzierilor și pierderilor - și aceasta este doar cele mai evidente. Așa cum cineva poate monitoriza acțiunile agenților pentru a îmbunătăți disponibilitatea resurselor lor, cineva poate face acest lucru în alte scopuri și nu există obstacole în acest sens. Rezultatul este un instrument cu două tăișuri și foarte multe fațete, oricine poate vedea acest lucru.

Sursa: www.habr.com

Adauga un comentariu