Nuk është sekret që për kontrollin e bllokimeve sipas listës së informacionit të ndaluar në Rusi, kujdeset një sistem automatizuar "Revizor". Si funksionon kjo është shkruar mirë në këtë , figura nga aty po ashtu:
Direkt te ofruesi i shërbimeve instalohet :
Moduli "Agjenti Revizor" është një element strukturor i sistemit automatizuar "Revizor" (AS "Revizor"). Ky sistem është i destinuar për të realizuar kontrollin mbi përmbushjen e kërkesave të operatorëve të komunikimit për kufizimin e aksesit sipas dispozitave të përcaktuara nga nenet 15.1-15.4 të Ligjit Federal nga 27 korriku 2006 nr. 149-FZ "Mbi informacionin, teknologjitë e informacionit dhe mbrojtjen e informacionit".
Qëllimi kryesor i krijimit të AS "Revizor" është sigurimi i monitorimit të respektimit të kërkesave të operatorëve të komunikimit të përcaktuara nga nenet 15.1-15.4 të Ligjit Federal nga 27 korriku 2006 nr. 149-FZ "Mbi informacionin, teknologjitë e informacionit dhe mbrojtjen e informacionit" në lidhje me zbulimin e rasteve të aksesit në informacion të ndaluar dhe marrjen e materialeve (të dhënave) mbështetëse për shkeljet e kufizimit të aksesit në informacionin e ndaluar.
Duke marrë parasysh se, nëse jo të gjitha, atëherë shumica e ofruesve kanë instaluar këtë pajisje te vetja, duhet të ishte krijuar një rrjet i madh i provuesve-sigla, ngjashëm me dhe edhe më shumë, por me akses të mbyllur. Megjithatë, një sigla është si një sigla për të dërguar sinjale në të gjitha drejtimet, por çfarë nëse i kapim dhe shohim se çfarë kemi kapur dhe sa?
Para se të numërojmë, le të shohim pse kjo mund të jetë e mundur.
Pak teori
Agjentët kontrollojnë disponueshmërinë e burimit, përfshirë përmes kërkesave HTTP(S), si kjo për shembull:
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"
Kërkesa përveç ngarkesës, përbëhet gjithashtu nga faza e vendosjes së lidhjes: shkëmbimi SYN dhe SYN-ACK, dhe faza e përfundimit të lidhjes: FIN-ACK.
Regjistri i informacionit të ndaluar përmban disa lloje bllokimesh. Është e qartë se nëse një burim do të bllokohet sipas adresës IP ose emrit të domainit, atëherë nuk do të shohim asnjë kërkesë. Këto janë llojet më shkatërruese të bllokimeve, të cilat çojnë në papërftueshmërinë e të gjithë burimeve në një adresë IP ose të gjithë informacionit në një domain. Ka gjithashtu një lloj bllokimi "sipër URL-së". Në këtë rast, sistemi i filtrimit duhet të analizojë HTTP header-in e kërkesës për të përcaktuar saktësisht se çfarë të bllokojë. Dhe para tij, siç shihet më lart, duhet të ndodhë faza e krijimit të lidhjes e cila mund të përpunohet, pasi ka shumë të ngjarë që filtrimi do ta kalojë atë.
Për këtë, duhet të zgjidhet një domain i përshtatshëm i lirë me llojin e bllokimit "sipër URL-së" dhe HTTP, për të lehtësuar punën e sistemit të filtrimit, e preferueshme të jetë e braktisur prej kohësh, për të minimizuar ardhjen e trafikut të huaj përveç atij nga Agjentët. Kjo detyrë rezultoi të ishte fare e thjeshtë, kishte mjaft domain-a të lirë në registrin e informacionit të ndaluar dhe për çdo shije. Prandaj, domain-i u ble, u lidh me adresat IP në VPS me funksionim tcpdump dhe filloi numërimi.
Revizioni i "Revizorëve"
Priste të shihja shpërthime periodike të kërkesave, që do të tregonte në mendimin tim për një veprim të kontrolluar. Nuk mund të thuhet se nuk e pashë fare këtë, por nuk kishte një pamje të qartë:
Ç'ka nuk është të habitshme, madje edhe në një domain që nuk ka interess për askënd mbi një IP që nuk përdoret kurrë, do të mbërrijë thjesht një masë informacioni të pa kërkuar, kjo është Interneti modern. Por fatmirësisht, më duheshin vetëm kërkesat e një URL-je specifike, prandaj të gjitha skanerët dhe shpërndarësit e fjalëkalimeve u gjetën shpejt. Gjithashtu, ishte mjaft e lehtë të kuptohej ku kishte përmbytje nga masat e kërkesave të njëjta. Më pas, përgatita frekuencat e shfaqjes së adresave IP dhe kalova përmes gjithë rendit manualisht duke ndarë ata që kaluan në etapet e mëparshme. Për më tepër, hoqa të gjitha burimet që dërguan një paketë, ato nuk ishin më shumë.
Një devijim i vogël liriko. Pak më shumë se një ditë më vonë, ofruesi im i hostimit më dërgoi një letër me një përmbajtje të pacaktuar, duke thënë se në kapacitetet tuaja ka një burim nga lista e ndaluar të RKN, prandaj po bllokohet. Fillimisht mendova se kishin bllokuar llogarinë time, por nuk ishte kështu. Më pas mendova se thjesht më paralajmëronin për diçka që e dija tashmë. Por rezultoi se hosti kishte aktivizuar filtrin e tij para domenit tim dhe në fund isha kapur nën një filtrimin e dyfishtë: nga ana e ofruesve dhe nga ana e hostit. Filtri kalonte vetëm skajet e kërkesave: FIN-ACK dhe RST duke prerë të gjithë HTTP në URL-në e ndaluar. Siç shihet nga grafiku më sipër, pas dy ditëve të para fillova të merrja më pak të dhëna, por ende po i merrja, gjë që ishte mjaft e mjaftueshme për qëllimin e numërimit të burimeve të kërkesave.
Tani në çështje. Sipas mendimit tim, qartë duken dy shpërthime çdo ditë, i pari më i vogël, pas mesnatës sipas Moskës, i dyti më afër orës 6 të mëngjesit me një bisht deri në orën 12 të ditës. Piku nuk përputhet saktësisht në të njëjtën kohë. Fillimisht doja të veçoja adresat IP që binin vetëm në këto periudha dhe çdo njëra në të gjitha periudhat, duke u bazuar në supozimin se kontrollimet nga Agjentët kryhen periodikisht. Por teksa hodha një vështrim të kujdesshëm, shpejt e kuptova se ka periudha që bien në intervale të tjera, me frekuenca të tjera, deri në një kërkesë çdo orë. Më pas mendova për zonat kohore dhe se ndoshta çështja qëndronte aty, më pas mendoj se në përgjithësi sistemi mund të mos jetë i sinkronizuar globalisht. Për më tepër, pa dyshim që do të luajë një rol NAT dhe e njëjta Agjent mund të bëjë kërkesat nga IP publike të ndryshme.
Duke qenë se qëllimi im fillestar nuk ishte saktësia, hesapova të gjitha adresat që u përballën gjatë javës dhe mora — 2791. Numri i sesioneve TCP të krijuara nga një adresë mesatarisht kishte 4, me median 2. Të dhënat më të mira të sesioneve mbi adresë: 464, 231, 149, 83, 77. Maksimumi nga 95% e mostrës — 8 sesione për adresë. Mediana nuk është shumë e lartë, kujtoj se nga grafiku dallohet një ciklikitet i dukshëm ditor, prandaj mund të pritej diçka rreth 4 deri në 8 për 7 ditë. Nëse heqim të gjitha sesionet që takohen një herë, atëherë pikërisht do të marrim median e barabartë me 5. Por nuk arrita t’i përjashtoj mbi një kriter të saktë. Përkundrazi, kontrolli i mostrave tregoi se ato kanë lidhje me kërkesat për burimin e ndaluar.
Adresat dhe sistemet autonome janë më të rëndësishme në internet — AS, të cilat arritën 1510, në mesatare 2 adresa për AS me median 1. Adresat kryesore në AS: 288, 77, 66, 39, 27. Maksimumi nga 95% e mostër — 4 adresa për AS. Këtu median është e pritshme — një Agjent për ofruesin. Të dhënat kryesore gjithashtu janë të pritshme — në të ka lojtarë të mëdhenj. Në një rrjet të madh, Agjentët, ndoshta, duhet të jenë në çdo rajon ku operatori është prezent, mos harrojmë edhe për NAT. Nëse e shohim sipas vendeve, maksimumet do të jenë: 1409 — RU, 42 — UA, 23 — CZ, 36 nga regione të tjera, jo RIPE NCC. Kërkesat jo nga Rusia tërheqin vëmendjen. Ndoshta, kjo mund të shpjegohet nga gabimet e gjeolokacionit ose gabimet e regjistruesve gjatë plotësimit të të dhënave. Ose nga fakti se një kompani ruse mund të ketë rrënjë jo ruse, ose të ketë një përfaqësi të huaj sepse është më e lehtë, natyrisht duke u marrë me një organizatë të huaj si RIPE NCC. Një pjesë e caktuar është padyshim e tepruar, por ndarjen e saj saktësisht është e vështirë, pasi burimi është nën bllokim, dhe nga dita e dytë nën bllokim të dyfishtë dhe shumica e sesioneve paraqesin thjesht shkëmbim me disa paketa shërbimi. Le të pajtohemi se kjo është një pjesë e vogël.
Këto numra mund të krahasohen tashmë me numrin e ofruesve në Rusi. licencat për "Shërbimet e komunikimit për transfertën e të dhënave, përveç zërit" — 6387, por kjo është një vlerësim shumë i lartë, nuk janë të gjitha këto licenca që lidhen me ofruesit e internetit që duhet të vendosin Agjentin. Në zonën RIPE NCC një numër i ngjashëm AS i regjistruar në Rusi — 6230, nga të cilët nuk janë të gjithë ofruesit. dhe mori 3940 kompani në vitin 2017, dhe kjo është ndoshta një vlerësim i lartë. Në çdo rast kemi numrin e AS të shfaqur që është dyfish më i vogël. Por këtu duhet të kuptohet se AS nuk është me të vërtetë e barabartë me ofruesin. Disa ofrues nuk kanë AS të tyre, disa kanë më shumë se një. Nëse supozojmë që Agjentët gjithsesi janë të pranishëm te të gjithë, atëherë dikush filtroi më fort se të tjerët, kështu që kërkesat e tyre nuk janë të dukshme nga plehrat nëse arrijnë të kalojnë. Por për një vlerësim të përgjithshëm është mjaft tolerante, edhe nëse diçka është humbur për shkak të neglizhencës sime.
Rreth DPI
Megjithë se ofruesi im i hostimit aktivizoi filtrin e tij që nga dita e dytë, nga informacioni i ditës së parë mund të përfundohet se bllokimet po funksionojnë me sukses. Vetëm 4 burime arritën të kalojnë dhe kanë seanca të plota HTTP dhe TCP (siç ilustrohet më sipër). 460 të tjera mund të dërgojnë GET, por seanca ndërpritet menjëherë në RST. Vini re se 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"
#Këto i dërgoi filtrin
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#Kjo është një përpjekje e nyjës origjinale për të marrë humbjen
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"
#Nyja origjinale kupton që seanca është shkatërruar
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Variacionet e kësaj mund të jenë të ndryshme: më pak RST ose më shumë retransmita—varet gjithashtu nga ajo që filtri dërgon në nyjën origjinale. Në çdo rast, ky është modeli më i besueshëm, nga i cili duket se është kërkuar pikërisht burimi i ndaluar. Për më tepër, gjithmonë ka një përgjigje që shfaqet në seancën me TTL më shumë se në paketat e mëparshme dhe të pasme.
Nga të tjerët nuk duken as GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Këto i dërgoi filtrin
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Ose ashtu:
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"
#Këto i dërgoi filtrin
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"
#Kthehet filtrin, shumë herë
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Evident është dallimi në TTL nëse ka ndonjë gjë që vjen nga filtri. Por shpesh mund të mos ketë asgjë fare:
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"
...
Ose ashtu:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Në kalimin e disa sekondave pa trafik
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Dhe e gjithë kjo përsëritet, siç duket në grafik, me siguri jo një herë, çdo ditë.
Për IPv6
Lajmi i mirë është se është aty. Mund të them me siguri se nga 5 adresa të ndryshme IPv6 po bëhen kërkesa periodike për burimin e ndaluar, pikërisht ajo sjellje e Agjentëve që prisja. Dhe një nga adresat IPv6 nuk është nën filtrimin dhe unë shoh një sesion të plotë. Nga dy të tjerat kam parë vetëm nga një sesion të papërfunduar, njëri nga të cilët u ndërpre për RST arsyen e filtrit, tjetri për kohën. Pra, në total, të gjitha 7.
Duke qenë se ka pak adresa, studova të gjitha ato në detaje dhe rezultoi se ka vetëm 3 siguruese, të cilëve u takon të duartrokasësh në kë foot! Një adresë tjetër është hosting në cloud në Rusi (nuk filtruoja), një tjetër është qendra kërkimore në Gjermani (ka filtër, ku?). Por, pse kontrollojnë për orar disponueshmërinë e burimeve të ndaluara, është një pyetje e mirë. Dy të mbetur bënë nga një kërkesë dhe ndodhen jashtë kufijve të Rusisë, dhe një prej tyre filtrohet (ndoshta në transit?).
Bllokimet dhe Agjentët janë një ngadalësim i madh për IPv6, përhapja e të cilës po ecën ngadalë. Kjo është e trishtë. Ata që e kanë zgjidhur këtë problem në mënyrë të plotë mund të jenë të kënaqur me veten.
Në përfundim
Nuk kam rendur pas 100% saktësie, më falni për këtë, shpresoj se dikush do të dëshirojë të përsërisë një punë të tillë më me precizitet. Mua më kishte rëndësi të kuptoja nëse një qasje e tillë do të funksiononte. Përgjigjja është, po. Numrat e marrë në një afrim të parë, mendoj se janë të besueshëm.
Çfarë mund të bëhej dhe çfarë u përpoq të bëja—të numëroja kërkesat ndaj DNS. Ato nuk filtrohen, por nuk japin saktësi të madhe pasi punojnë vetëm për domenin, e jo për të gjithë URL-në. Periudhësia duhet të shihet. Nëse kombinohet me atë që shihet drejtpërdrejt në kërkesat, kjo do të lejojë ndarjen e të tepërtave dhe do të ofrojë më shumë informacion. Ndoshta madje të përcaktojmë zhvilluesit e DNS që përdoren nga ofruesit dhe shumë gjëra të tjera.
Absolutisht nuk prisja që hosti im VPS të aktivizonte edhe filtrin e vet. Ndoshta kjo është një praktikë e zakonshme. Në fund të fundit, RKN dërgon kërkesë për heqjen e burimit pikërisht te hosti. Por nuk më befasoi dhe madje ndonjëherë, e ndihmoi. Filtri punoi shumë efektivisht duke ndalur të gjitha kërkesat e sakta HTTP për URL-në e ndaluar, por ato të pasakta, që kaluan më parë nëpër filtrin e ofruesve, arritën, edhe pse vetëm në formën e fundeve: FIN-ACK dhe RST — minus on minus and almost a plus. By the way, the IPv6 host was not filtered. Of course, this affected the quality of the collected material, but it still allowed us to see the periodicity. It turned out to be an important point when choosing a platform for resource placement; don't forget to inquire about the organization of work with the list of prohibited sites and requests from the RKN.
In the beginning, I compared the AS "Revisor" with . This comparison is quite justified, and a large network of Agents can be beneficial. For example, assessing the accessibility quality of a resource from various providers across different parts of the country. Latencies can be calculated, graphs can be built, and everything can be analyzed to observe changes both locally and globally. This is not the most direct path, but astronomers use "standard candles"; why not use Agents? By knowing (finding) their standard behavior, we can determine the changes taking place around them and how this affects the quality of the services provided. And at the same time, there's no need to independently place probes in the network; they have already been set up by Roskomnadzor.
Another point I want to touch on is that every tool can be a weapon. The AS "Revisor" is a closed network, but Agents expose everything by sending requests to all resources on the prohibited list. Acquiring such a resource poses no problems at all. Therefore, through the Agents, providers inadvertently reveal much more about their network than might be prudent: types of DPI and DNS, the location of the Agent (central node and service network?), network markers for delays and losses — and this is just the most obvious aspect. Just as someone can monitor the actions of Agents to improve the accessibility of their resources, others can do so for different purposes, and there are no barriers to that. It turned out to be a double-edged and very multifaceted tool, anyone can see this.
Burimi: habr.com
