Nuk është sekret që mbikëqyrja e bllokimeve sipas listes së informacionit të ndaluar në Rusi bëhet nga një sistem automatizuar "Revizor". Si funksionon, është shkruar mirë në këtë , imazhi nga aty:
Përveç kësaj, provajderi instalon :
Moduli "Agjenti Revizor" është një element strukturor i sistemit automatizuar "Revizor" (AS "Revizor"). Ky sistem është i destinuar për të mbikëqyrur përmbushjen e kërkesave nga operatorët e komunikimit për kufizimin e qasjes në përputhje me ato që parashikohen nga nenet 15.1-15.4 të Ligjit Federal të datës 27 korrik 2006 nr. 149-FZ "Për informacionin, teknologjitë informative dhe mbrojtjen e informacionit".
Qëllimi kryesor i krijimit të AS «Revizor» është sigurimi i monitorimit të përputhshmërisë nga operatorët e komunikimit me kërkesat e përcaktuara në nenet 15.1-15.4 të Ligjit Federal të datës 27 korrik 2006 № 149-FZ «Për informacionin, teknologjitë informative dhe mbrojtjen e informacionit» në lidhje me identifikimin e rasteve të aksesit në informacion të ndaluar dhe mbledhjen e materialeve (të dhënave) konfirmuese për shkeljet e kufizimit të aksesit në informacion të ndaluar.
Duke pasur parasysh se, nëse jo të gjitha, shumica e ofruesve kanë instaluar këtë pajisje, duhet të jetë krijuar një rrjet i madh i mostrave sinjalizues siç është dhe madje më shumë, por me akses të mbyllur. Megjithatë, sinjalizuesi është thjesht një sinjalizues për të dërguar sinjale në të gjitha drejtimet, dhe çfarë nëse i kapim ato dhe shohim se çfarë kemi kapur dhe sa?
Para se të llogarisim, le të shohim pse kjo mund të jetë e mundur.
Pak teori
Agjentët kontrollojnë disponueshmërinë e burimeve, përfshirë, përmes kërkesave HTTP(S), si ky 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 krijimit të 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 burimi do të bllokohet sipas adresës IP ose emrit të domain-it, atëherë nuk do të shohim asnjë kërkesë. Këto janë llojet më shkatërruese të bllokimeve, të cilat çojnë në paarritshmëri të të gjitha burimeve në një adresë IP ose të gjithë informacionit në një domain. Ekziston gjithashtu një tip bllokimi "sipër URL". Në këtë rast, sistemi i filtrimit duhet të interpretojë titullin HTTP të kërkesës, për të përcaktuar saktësisht se çfarë të bllokojë. Dhe para saj, siç duket më sipër, duhet të ndodhë faza e krijimit të lidhjes e cila mund të tentojë të ndjekë, sepse shumë mundësi është që filtri ta kalojë.
Për këtë, duhet të zgjidhni një domen të lirë të përshtatshëm me tipin e bllokimit "sipër URL" dhe HTTP, për të lehtësuar punën e sistemit të filtrimit, është e dëshirueshme që të jetë një domen që është shkëputur prej kohësh, për të minimizuar qasjen e trafik të huaj përveç atij nga Agjentët. Kjo detyrë doli të jetë mjaft e lehtë, pasi ka shumë domin të lirë në regjistrin e informacionit të ndaluar dhe për çdo shije. Prandaj domeni u ble, u lidh me adresat IP në VPS me të nisur tcpdump dhe filloi numërimi.
Revizioni "Revizorëve"
Pr ожида, чтобы увидеть периодические всплески запросов, что, на мой взгляд, говорило бы о контролируемом действии. Нельзя сказать, чтобы я совсем этого не увидел, но четкой картины определенно не было:
Siç është e pritshme, madje edhe në një domen që askujt nuk i nevojitet, në një IP që kurrë nuk përdoret, do të ketë thjesht një masë informacioni të padëshiruar, kjo është interneti modern. Por, fatmirësisht, më duhej vetëm kërkesa për një URL specifike, kështu që të gjitha skanuesit dhe fjalëkalimet u gjetën shpejt. Gjithashtu, ishte mjaft e lehtë të kuptohej se ku ishin spamet nga masa e kërkesave të njëjta. Më pas, krijova frekuencat e shfaqjes së adresave IP dhe kalova manualisht përmes gjithë listës duke ndarë ata që kishin kaluar në etapën e mëparshme. Për më tepër, prita të gjithë burimet që dërguan vetëm një paketë, ata ishin pak. Dhe kështu doli kjo:
Një shënim i vogël lirik. Pak më shumë se një ditë më vonë, ofruesi im i hosting të dërgoi një email të përmbajtjes mjaft të paqartë, duke thënë se në kapacitetet tuaja ka një burim nga lista e ndaluar të RKN, prandaj po bllokohet. Fillimisht mendova se më kishin bllokuar llogarinë, por nuk ishte kështu. Më pas, mendova se thjesht po më paralajmëronin për diçka që e dija. Por u zbulua se hosti aktivizoi filtrin e tij përpara domenit tim dhe në fund u kam përfshirë dy herë në filtrimin: nga ana e ofruesve dhe nga ana e hostit. Filtri kalonte vetëm fundet e kërkesave: FIN-ACK dhe RST duke prerë të gjithë HTTP për URL-në e ndaluar. Siç shihet në grafikun e mësipërm, pas ditëve të para fillova të merrja më pak të dhëna, por ende i merrja, gjë që ishte mëse e mjaftueshme për detyrën e numërimit të burimeve të kërkesave.
Në thelb, mendoj se është shumë e qartë se ndodhin dy shpërthime çdo ditë, i pari më i vogël, pas mesnatës sipas orës Moskë, i dyti afër orës 6 të mëngjesit me një bisht deri në 12 të drekës. Piku nuk ndodh në të njëjtën kohë çdo herë. Fillimisht doja të veçoja IP adresat që përputhen vetëm në këto periudha dhe secila në të gjitha periudhat, duke u bazuar në supozimin se kontrollimet nga Agjentët kryhen periodikisht. Por, duke e parë me kujdes, e pashë mjaft shpejt se periudhat kryqëzoheshin në intervale të tjera, me frekuenca të ndryshme, deri në një kërkesë çdo orë. Më pas mendoja për zona kohore dhe se ndoshta kjo është një arsye, pastaj mendova se sistemi mund të mos jetë i sinkronizuar globalisht. Për më tepër, natyrisht, NAT do të luajë një rol dhe i njëjti Agjent mund të bëjë kërkesa nga IP publike të ndryshme.
Duke qenë se qëllimi im fillestar nuk ishte saktësia, llogaritëm të gjitha adresat që u paraqitën gjatë javës dhe mora - 2791. Numri i sesioneve TCP të vendosura nga një adresë është mesatarisht 4, me median 2. Sesionet kryesore për adresën: 464, 231, 149, 83, 77. Maksimumi nga 95% e mostras është 8 seansa për adresë. Media nuk është shumë e lartë, duke ndjerë se nga grafiku është e dukshme një periodikë e qartë ditore, prandaj mund të pritej diçka rreth 4 deri në 8 gjatë 7 ditëve. Nëse eliminojmë të gjitha sesionet që ndodhin një herë, do të arrijmë pikërisht një median prej 5. Por nuk arrita t’i përjashtoj sipas një kriteri të qartë. Përkundrazi, kontrolli mostra tregoi se ato lidheshin me kërkesat për burimin e ndaluar.
Adresat janë një gjë, por në Internet, sistemi autonom është më i rëndësishëm — AS, të cilat janë krijuar 1510, në mesatarisht 2 adresa në AS me median 1. Adresat kryesore në AS: 288, 77, 66, 39, 27. Maksimumi nga një mostër prej 95% është 4 adresa në AS. Këtu, median është e pritur - një Agjent për ofruesin. Topi gjithashtu është i pritur - përfshin lojtarë të mëdhenj. Në një rrjet të madh, Agjentët ndoshta duhet të qëndrojnë në çdo rajon ku operon operatori, pa harruar dhe NAT-in. Nëse shqyrtojmë vendet, maksimumet do të jenë: 1409 — RU, 42 — UA, 23 — CZ, 36 nga rajone të tjera, jo RIPE NCC. Kërkesat jashtë Rusisë tërheqin vëmendjen. Ndoshta, kjo mund të shpjegohet me gabime në gjeolokacion ose gabime të regjistruesve gjatë plotësimit të të dhënave. Ose ndoshta një kompani ruse mund të ketë rrënjë jo ruse, ose të ketë përfaqësim të huaj, sepse është më e lehtë, sidomos duke u marrë me organizatën e huaj RIPE NCC. Një pjesë e caktuar, padyshim, është e panevojshme, por është e vështirë ta ndash me saktësi, pasi burimi është nën bllokim, dhe që nga ditët e dyta nën një bllokim të dyfishtë dhe shumica e seancave përbëjnë vetëm shkëmbimin e disa paketimeve shërbimi. Le të pajtohemi se kjo është një pjesë e vogël.
Këto numra mund të krahasohen tani me numrin e ofruesve në Rusi. licencave për "Shërbimet e komunikimit për transferin e të dhënave, përveç zërit" - 6387, por kjo është një vlerësim shumë i lartë nga ana e sipërme, jo të gjitha këto licenca i përkasin saktësisht ofruesve të internetit të cilët kanë nevojë për të vendosur Agentin. Në zonën e RIPE NCC ka një numër të ngjashëm ASN të regjistruar në Rusi - 6230, nga të cilat jo të gjithë ofruesit. dhe ka arritur në 3940 kompani në vitin 2017, dhe kjo është më shumë një vlerësim i lartë. Në çdo rast, ne kemi numrin e ASN-ve të dukshme që është dy herë e gjysmë më i vogël. Por këtu duhet kuptuar se ASN nuk është striktisht i barabartë me ofruesin. Disa ofrues nuk kanë ASN të tyre, disa kanë më shumë se një. Nëse supozojmë se Agjentët janë gjithsesi të pranishëm te të gjithë, atëherë dikush filtroi më fuqishëm se të tjerët, kështu që kërkesat e tyre janë të padallueshme nga mbeturinat, nëse me të vërtetë arrijnë. Por për një vlerësim të përafërt, kjo është mjaft e pranueshme, edhe nëse disa gjëra janë humbur për shkak të gabimeve të mia.
Për DPI
Megjithëse provajderi im i hostimit aktivizoi filtrin e tij që nga dita e dytë, informacioni për ditën e parë tregon se bllokimet funksionojnë me sukses. Vetëm 4 burime arritën të kalonin dhe kanë seanca HTTP dhe TCP të plota (saktësisht si në shembullin më sipër). Edhe 460 mund të dërgojnë GET, por seanca ndërpritet menjëherë për RST. Kushtojini vëmendje 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"
#Ky është mesazhi i dërguar nga filtri
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#Kjo është përpjekja e nyjës origjinale për të marrë humbjen
TTL 50, TCP ACKed segment të padukshëm, 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 se seanca është shkatërruar
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Variacione të këtij mund të jenë të ndryshme: më pak RST ose më shumë retransmetime — varet gjithashtu nga ajo që filtri i dërgon nyjës origjinale. Në çdo rast, ky është modeli më i saktë, nga i cili është e qartë se është kërkuar në të vërtetë burimi i ndaluar. Plus, gjithmonë ka një përgjigje që shfaqet në sesionin me TTL më shumë se në paketat e mëparshme dhe të ardhshme.
Nga të tjerët nuk duket asgjë GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Këto dërgoi filtri
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Ose kështu:
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 dërgoi filtri
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
TTL 50, TCP ACKed segment të padukshëm, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed segment të padukshëm, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
#Përsëri filtri, shumë herë
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Dallimi është patjetër i dukshëm në TTL nëse diçka vjen nga filtri. Por shpesh nuk mund të vijë asgjë:
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 kështu:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Kaluan disa sekonda pa trafik
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Dhe gjithçka përsëritet, përsëritet dhe përsëritet, siç shihet në grafik, me siguri jo një herë, çdo ditë.
Për IPv6
Lajmi i mirë - ai është. Mund të them me siguri se nga 5 adresa të ndryshme IPv6 bëhen kërkesa periodike për një burim të ndaluar, pikërisht ajo sjellje e Agjentëve që prisja. Madje një nga adresat IPv6 nuk është nën filtrimin dhe unë shoh një sesion të plotë. Nga dy të tjerë kam parë vetëm nga një sesion të papërfunduar, një nga të cilat u ndërpre për RST nën filtrin, tjetri për kohën. Në total gjithsej 7.
Duke qenë se ka pak adresa, kam studiuar të gjitha ato në detaje dhe doli se në të vërtetë ka vetëm 3 ofrues, të cilëve mund t'u duash duar për qëndrim! Një tjetër adresë është një hostim cloud në Rusi (nuk filtrohet), tjetri është një qendër kërkimore në Gjermani (ka filtrin, ku?). Por qëllimi i tyre për të kontrolluar rregullisht aksesin në burimet e ndaluara është një pyetje e mirë. Dy të mbetur bënë nga një kërkesë dhe ndodhen jashtë kufijve të Rusisë, dhe një nga to filtrohet (përfundimisht në transit?).
Bllokimet dhe Agjentët janë një pengesë e madhe për IPv6, implementimi i të cilit tashmë nuk po shkon shumë shpejt. Kjo është e trishtueshme. Ata që e kanë zgjidhur këtë problem në mënyrë të plotë mund të krenohen me veten.
Në përfundim
Nuk po kërkoja 100% saktësi, ju lutem më falni për këtë, shpresoj që dikush do të dëshirojë të përsërisë një punë të tillë me më shumë saktësi. Për mua ishte e rëndësishme të kuptoja nëse një qasje e tillë do të funksiononte në përgjithësi. Përgjigjja është — po. Të dhënat e marra në një afrim të parë, mendoj se janë mjaft të besueshme.
Çfarë mund të bëhej tjetër dhe çfarë ndieja lenë për të bërë — të llogariten kërkesat për DNS. Ato nuk filtrohen, por gjithashtu nuk ofrojnë një saktësi të madhe pasi punojnë vetëm për domenin, dhe jo për të gjithë URL-në. Periodiciteti duhet të jetë i dukshëm. Nëse e kombinojmë me atë që është e dukshme në kërkesat, do të lejojë ndarjen e informacionit të panevojshëm dhe do të marrë më shumë të dhëna. Mund të përfshihet edhe përcaktimi i zhvilluesve të DNS që përdoren nga ofruesit dhe shumë gjëra të tjera.
Nuk e prisja aspak që host-i im do të aktivizonte edhe filtrin e tij për VPS-in tim. Ndoshta kjo është një praktikë e zakonshme. Në fund të fundit, RKN dërgon kërkesë për heqjen e burimeve pikërisht te host-i. Por kjo nuk më befasoi dhe madje diku më ndihmoi. Filtri punonte shumë efektivisht duke bllokuar të gjitha kërkesat e sakta HTTP për URL-në e ndaluar, por ato të pasakta, që kishin kaluar para kësaj përmes filtrave të ofruesve, arrinin, ndonëse vetëm si skeda te fundit: FIN-ACK dhe RST — minus për minus dhe thuajse u bë plus. Për më tepër, IPv6 nuk u filtrua nga host-i. Sigurisht, kjo ndikoi në cilësinë e materialeve të grumbulluara, por ndihmoi për të parë periodicitetin. Doli të ishte një moment i rëndësishëm kur zgjidhni platformën për vendosjen e burimeve, mos harroni të pyesni për organizimin e punës me listën e faqeve të ndaluara dhe kërkesat nga RKN.
Në fillim, krahasova AS 'Revizor' me . Это сравнение вполне оправдано и большая сеть из Агентов может приносить пользу. Например, определение качества доступности ресурса из различных провайдеров различных частей страны. Можно посчитать задержки, можно строить графики, можно это всё анализировать и видеть изменения происходящие как локально так и глобально. Это не самый прямой путь, но используют же астрономы «стандартные свечи», почему не использовать Агенты? Зная (найдя) их стандартное поведение можно определять изменения которые происходят вокруг них и как это влияет на качество оказываемых услуг. И при этом не надо самостоятельно расставлять пробники по сети, их уже поставил Роскомнадзор.
Një tjetër çështje që dëshiroj të theksoj është se çdo mjet mund të jetë armë. AS «Revizor» është një rrjet i mbyllur, por Agjentët përfundojnë duke zbuluar gjithçka duke dërguar kërkesa për të gjitha burimet nga lista e ndaluar. Të mbash një burim të tillë nuk paraqet asnjë problem. Pra, ofruesit përmes Agjentëve, pa e dashur, flasin më shumë për rrjetin e tyre se sa mund të duhej: llojet e DPI dhe DNS, vendndodhja e Agjentit (në qendër dhe në rrjetin shërbyes?), shenjat rrjetore të vonesave dhe humbjeve - dhe këto janë vetëm të dukshme. Ashtu si dikush mund të monitorojë veprimet e Agjentëve për të përmirësuar aksesin në burimet e tij, dikush tjetër mund ta bëjë këtë për qëllime të tjera dhe nuk ka pengesa për këtë. Doli të jetë një mjet dytësor dhe shumë dimensional, secili mund ta vërtetojë këtë.
Burimi: habr.com
