Nuk është sekret që kontrolli i bllokimit në listën e informacionit të ndaluar në Rusi monitorohet nga sistemi i automatizuar "Inspektori". Se si funksionon është shkruar mirë këtu në këtë , foto nga i njëjti vend:
Instaluar direkt tek ofruesi :
Moduli "Agjent Inspektor" është një element strukturor i sistemit të automatizuar "Inspektor" (AS "Inspektor"). Ky sistem është krijuar për të monitoruar përputhjen nga operatorët e telekomit me kërkesat e kufizimit të aksesit brenda kuadrit të dispozitave të përcaktuara nga nenet 15.1-15.4 të Ligjit Federal të 27 korrikut 2006 Nr. 149-FZ "Për informacionin, teknologjitë e informacionit dhe mbrojtjen e informacionit". ”
Qëllimi kryesor i krijimit të AS "Revizor" është të sigurojë monitorimin e pajtueshmërisë së operatorëve të telekomit me kërkesat e përcaktuara nga nenet 15.1-15.4 të Ligjit Federal të 27 korrikut 2006 Nr. 149-FZ "Për informacionin, teknologjitë e informacionit dhe mbrojtjen e informacionit". "për sa i përket identifikimit të fakteve të aksesit në informacionin e ndaluar dhe marrjes së materialeve (të dhënave) mbështetëse për shkeljet për të kufizuar aksesin në informacionin e ndaluar.
Duke marrë parasysh faktin se, nëse jo të gjithë, atëherë shumë ofrues e kanë instaluar këtë pajisje, duhet të kishte një rrjet të madh sondash beacon si dhe akoma më shumë, por me akses të mbyllur. Megjithatë, një fener është një fener për të dërguar sinjale në të gjitha drejtimet, por çka nëse i kapim dhe shohim se çfarë kapëm 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 një burimi, duke përfshirë kërkesat HTTP(S), si kjo:
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"
Përveç ngarkesës, kërkesa përbëhet edhe nga një fazë e vendosjes së lidhjes: shkëmbimi SYN и SYN-ACK, dhe fazat e përfundimit të lidhjes: FIN-ACK.
Regjistri i informacionit të ndaluar përmban disa lloje të bllokimit. Natyrisht, nëse një burim bllokohet nga adresa IP ose emri i domenit, atëherë nuk do të shohim asnjë kërkesë. Këto janë llojet më shkatërruese të bllokimit, të cilat çojnë në paarritshmërinë e të gjitha burimeve në një adresë IP ose të gjithë informacionit në një domen. Ekziston gjithashtu një lloj bllokimi "nga URL". Në këtë rast, sistemi i filtrimit duhet të analizojë kokën e kërkesës HTTP për të përcaktuar saktësisht se çfarë të bllokojë. Dhe para saj, siç mund të shihet më lart, duhet të ketë një fazë të krijimit të lidhjes që mund të përpiqeni ta gjurmoni, pasi ka shumë të ngjarë që filtri ta humbasë atë.
Për ta bërë këtë, ju duhet të zgjidhni një domen të përshtatshëm falas me llojin e bllokimit "URL" dhe HTTP për të lehtësuar punën e sistemit të filtrimit, mundësisht të braktisur prej kohësh, për të minimizuar hyrjen e trafikut të jashtëm, përveç nga agjentët. Kjo detyrë doli të mos ishte aspak e vështirë; ka mjaft domene falas në regjistrin e informacionit të ndaluar dhe për çdo shije. Prandaj, domeni u ble dhe u lidh me adresat IP në një VPS që funksionon tcpdump dhe filloi numërimi.
Auditimi i "Auditorëve"
Prisja të shihja breshëri kërkesash periodike, të cilat për mendimin tim do të tregonin veprim të kontrolluar. Është e pamundur të thuhet se nuk e pashë fare, por definitivisht nuk kishte një pamje të qartë:
Gjë që nuk është për t'u habitur, edhe në një domen që nuk i nevojitet askujt dhe në një IP të pa përdorur kurrë, thjesht do të ketë një ton informacioni të pakërkuar, i tillë është Interneti modern. Por për fat të mirë, më duheshin vetëm kërkesa për një URL specifike, kështu që të gjithë skanerët dhe thyerësit e fjalëkalimeve u gjetën shpejt. Gjithashtu, ishte mjaft e lehtë për të kuptuar se ku ishte përmbytja bazuar në masën e kërkesave të ngjashme. Më pas, përpilova frekuencën e shfaqjes së adresave IP dhe kalova manualisht në të gjithë pjesën e sipërme, duke ndarë ata që e humbën atë në fazat e mëparshme. Për më tepër, unë preva të gjitha burimet që u dërguan në një paketë, nuk kishte më shumë prej tyre. Dhe kjo është ajo që ndodhi:
Një digresion i vogël lirik. Pak më shumë se një ditë më vonë, ofruesi im i pritjes dërgoi një letër me një përmbajtje mjaft të thjeshtë, duke thënë se objektet tuaja përmbajnë një burim nga lista e ndaluar e RKN, kështu që është i bllokuar. Në fillim mendova se llogaria ime ishte bllokuar, nuk ishte kështu. Pastaj mendova se ata thjesht po më paralajmëronin për diçka që e dija tashmë. Por doli që hosteri ndezi filtrin e tij përpara domenit tim dhe si rezultat u futa nën filtrim të dyfishtë: nga ofruesit dhe nga hosti. Filtri kaloi vetëm skajet e kërkesave: FIN-ACK и RST ndërprerja e të gjithë HTTP-së në një URL të ndaluar. Siç mund ta shihni nga grafiku i mësipërm, pas ditës së parë fillova të merrja më pak të dhëna, por gjithsesi i mora, gjë që ishte mjaft e mjaftueshme për detyrën e numërimit të burimeve të kërkesave.
Shkoni te pika. Sipas mendimit tim, dy breshëri janë qartë të dukshme çdo ditë, e para më e vogël, pas mesnatës me orën e Moskës, e dyta më afër orës 6 të mëngjesit me një bisht deri në orën 12 të mesditës. Kulmi nuk ndodh saktësisht në të njëjtën kohë. Fillimisht doja të zgjidhja adresat IP që binin vetëm në këto periudha dhe secila në të gjitha periudhat, bazuar në supozimin se kontrollet nga agjentët kryhen periodikisht. Por pas shqyrtimit të kujdesshëm, zbulova shpejt periudhat që bien në intervale të tjera, me frekuenca të tjera, deri në një kërkesë çdo orë. Pastaj mendova për zonat kohore dhe se ndoshta kishte të bënte me to, pastaj mendova që në përgjithësi sistemi mund të mos sinkronizohej globalisht. Për më tepër, NAT ndoshta do të luajë një rol dhe i njëjti Agjent mund të bëjë kërkesa nga IP të ndryshme publike.
Meqenëse qëllimi im fillestar nuk ishte saktësisht, unë numërova të gjitha adresat që hasa në një javë dhe mora - 2791. Numri i seancave TCP të krijuara nga një adresë është mesatarisht 4, me një mesatare prej 2. Sesionet kryesore për adresë: 464, 231, 149, 83, 77. Maksimumi nga 95% e kampionit është 8 seanca për adresë. Mesatarja nuk është shumë e lartë, më lejoni t'ju kujtoj se grafiku tregon një periodicitet të qartë ditor, kështu që mund të pritet diçka rreth 4 deri në 8 në 7 ditë. Nëse i hedhim jashtë të gjitha seancat që ndodhin një herë, do të marrim një mesatare të barabartë me 5. Por nuk mund t'i përjashtoja ato bazuar në një kriter të qartë. Përkundrazi, një kontroll i rastësishëm tregoi se ato kishin të bënin me kërkesa për një burim të ndaluar.
Adresat janë adresa, por në internet, sisteme autonome - AS, të cilat doli të ishin më të rëndësishme 1510, mesatarisht 2 adresa për AS me një mesatare prej 1. Adresat kryesore për AS: 288, 77, 66, 39, 27. Maksimumi 95% e kampionit është 4 adresa për AS. Këtu pritet mesatarja - një agjent për ofrues. Ne gjithashtu presim majën - ka lojtarë të mëdhenj në të. Në një rrjet të madh, agjentët ndoshta duhet të vendosen në çdo rajon të pranisë së operatorit dhe mos harroni për NAT. Nëse e marrim sipas vendit, maksimalet do të jenë: 1409 - RU, 42 - UA, 23 - CZ, 36 nga rajone të tjera, jo RIPE NCC. Kërkesat nga jashtë Rusisë tërheqin vëmendjen. Kjo ndoshta mund të shpjegohet me gabimet e gjeolokimit ose gabimet e regjistruesit gjatë plotësimit të të dhënave. Ose fakti që një kompani ruse mund të mos ketë rrënjë ruse, ose të ketë një zyrë përfaqësuese të huaj sepse është më e lehtë, gjë që është e natyrshme kur kemi të bëjmë me një organizatë të huaj RIPE NCC. Një pjesë është padyshim e tepërt, por është mjaft e vështirë ta ndash atë, pasi burimi është nën bllokim, dhe nga dita e dytë nën bllokim të dyfishtë, dhe shumica e seancave janë vetëm një shkëmbim i disa paketave të shërbimit. Le të biem dakord që kjo është një pjesë e vogël.
Këto shifra tashmë mund të krahasohen me numrin e ofruesve në Rusi. licencat për "Shërbimet e komunikimit për transmetimin e të dhënave, me përjashtim të zërit" - 6387, por ky është një vlerësim shumë i lartë nga lart, jo të gjitha këto licenca zbatohen posaçërisht për ofruesit e internetit që duhet të instalojnë një Agjent. Në zonën RIPE NCC ka një numër të ngjashëm të AS-ve të regjistruara në Rusi - 6230, nga të cilat jo të gjithë janë ofrues. dhe ka marrë 3940 kompani në 2017, dhe ky është më tepër një vlerësim nga lart. Në çdo rast, kemi dy herë e gjysmë më pak numër të AS-ve të ndriçuar. Por këtu ia vlen të kuptohet se AS nuk është rreptësisht e barabartë me ofruesin. Disa ofrues nuk kanë AS-në e tyre, disa kanë më shumë se një. Nëse supozojmë se të gjithë kanë akoma Agjentë, atëherë dikush filtron më fort se të tjerët, në mënyrë që kërkesat e tyre të mos dallohen nga mbeturinat, nëse i arrijnë fare. Por për një vlerësim të përafërt është mjaft e tolerueshme, edhe nëse diçka ka humbur për shkak të mbikëqyrjes sime.
Rreth DPI
Përkundër faktit se ofruesi im i pritjes aktivizoi filtrin e tij duke filluar nga dita e dytë, në bazë të informacionit nga dita e parë mund të konkludojmë se bllokimi po funksionon me sukses. Vetëm 4 burime ishin në gjendje të kalonin dhe të kishin përfunduar plotësisht seancat HTTP dhe TCP (si në shembullin e mësipërm). Mund të dërgohen edhe 460 të tjera GET, por seanca ndërpritet menjëherë nga 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"
#Вот это прислал фильтр
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"
Variacionet e kësaj mund të jenë të ndryshme: më pak RST ose më shumë ritransmetime - varet gjithashtu nga ajo që filtri dërgon në nyjen burimore. Në çdo rast, ky është shablloni më i besueshëm, nga i cili duket qartë se ishte një burim i ndaluar që u kërkua. Plus ka gjithmonë një përgjigje që shfaqet në seancën me TTL më i madh se në paketat e mëparshme dhe të mëvonshme.
Nuk mund ta shihni as nga pjesa tjetër 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"
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"
#Вот это прислал фильтр
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"
...
Dallimi është padyshim i dukshëm TTL nëse diçka vjen nga filtri. Por shpesh asgjë nuk mund të arrijë 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 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"
#Прошло несколько секунд без трафика
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 dhe përsëritet dhe përsëritet, siç mund të shihet në grafik, më shumë se një herë, çdo ditë.
Rreth IPv6
Lajmi i mirë është se ekziston. Mund të them me siguri se kërkesat periodike për një burim të ndaluar ndodhin nga 5 adresa të ndryshme IPv6, që është pikërisht sjellja e agjentëve që prisja. Për më tepër, një nga adresat IPv6 nuk bie në filtrim dhe unë shoh një seancë të plotë. Nga dy të tjera pashë vetëm një seancë të papërfunduar, njëra prej të cilave u ndërpre RST nga filtri, i dyti në kohë. Shuma totale 7.
Meqenëse adresat janë të pakta, i studiova të gjitha në detaje dhe doli që atje janë vetëm 3 ofrues, mund t'i duartrokasin! Një adresë tjetër është hostimi i cloud në Rusi (nuk filtron), një tjetër është një qendër kërkimore në Gjermani (ka një filtër, ku?). Por pse ata kontrollojnë disponueshmërinë e burimeve të ndaluara në një orar është një pyetje e mirë. Dy të tjerët bënë një kërkesë dhe ndodhen jashtë Rusisë, dhe njëra prej tyre është e filtruar (në fund të fundit në tranzit?).
Bllokimi dhe agjentët janë një pengesë e madhe për IPv6, zbatimi i të cilit nuk po ecën shumë shpejt. Është e trishtueshme. Ata që e zgjidhën këtë problem mund të jenë plotësisht krenarë për veten e tyre.
Në përfundim
Unë nuk u përpoqa për saktësi 100%, ju lutem më falni për këtë, shpresoj që dikush të dëshirojë ta përsërisë këtë punë me saktësi më të madhe. Ishte e rëndësishme për mua të kuptoja nëse kjo qasje do të funksiononte në parim. Përgjigja është po. Shifrat e marra, si përafrim i parë, mendoj se janë mjaft të besueshme.
Çfarë tjetër mund të ishte bërë dhe ajo që isha shumë dembel për të bërë ishte numërimi i kërkesave DNS. Ata nuk janë të filtruar, por gjithashtu nuk ofrojnë shumë saktësi pasi funksionojnë vetëm për domenin, dhe jo për të gjithë URL-në. Frekuenca duhet të jetë e dukshme. Nëse e kombinoni atë me atë që është e dukshme drejtpërdrejt në pyetje, kjo do t'ju lejojë të veçoni të panevojshmet dhe të merrni më shumë informacion. Është madje e mundur të përcaktohen zhvilluesit e DNS të përdorur nga ofruesit dhe shumë më tepër.
Absolutisht nuk prisja që hosti të përfshinte gjithashtu filtrin e tij për VPS-në time. Ndoshta kjo është praktikë e zakonshme. Në fund, RKN dërgon një kërkesë për të fshirë burimin te hosti. Por kjo nuk më befasoi dhe në një farë mënyre funksionoi edhe në avantazhin tim. Filtri funksionoi në mënyrë shumë efektive, duke ndërprerë të gjitha kërkesat e sakta HTTP në një URL të ndaluar, por ato jo të sakta që kishin kaluar më parë përmes filtrit të ofruesve i arritën ato, megjithëse vetëm në formën e përfundimeve: FIN-ACK и RST - minus për minus dhe pothuajse doli të ishte një plus. Nga rruga, IPv6 nuk ishte filtruar nga hosti. Sigurisht, kjo ndikoi në cilësinë e materialit të mbledhur, por gjithsesi bëri të mundur shikimin e frekuencës. Doli se kjo është një pikë e rëndësishme kur zgjidhni një sit për vendosjen e burimeve; mos harroni të interesoheni për çështjen e organizimit të punës me listën e vendeve të ndaluara dhe kërkesave nga RKN.
Në fillim e krahasova AS “Inspektorin” me . Ky krahasim është mjaft i justifikuar dhe një rrjet i madh agjentësh mund të jetë i dobishëm. Për shembull, përcaktimi i cilësisë së disponueshmërisë së burimeve nga ofrues të ndryshëm në pjesë të ndryshme të vendit. Ju mund të llogaritni vonesat, mund të ndërtoni grafikë, mund t'i analizoni të gjitha dhe të shihni ndryshimet që ndodhin si në nivel lokal ashtu edhe në atë global. Kjo nuk është mënyra më e drejtpërdrejtë, por astronomët përdorin "qirinj standardë", pse të mos përdorin Agjentët? Duke ditur (pasi të keni gjetur) sjelljen e tyre standarde, ju mund të përcaktoni ndryshimet që ndodhin rreth tyre dhe se si kjo ndikon në cilësinë e shërbimeve të ofruara. Dhe në të njëjtën kohë, nuk keni nevojë të vendosni në mënyrë të pavarur sonda në rrjet; Roskomnadzor i ka instaluar tashmë ato.
Një pikë tjetër që dua të prek është se çdo mjet mund të jetë një armë. AS "Inspektori" është një rrjet i mbyllur, por Agjentët i dorëzojnë të gjithë duke dërguar kërkesa për të gjitha burimet nga lista e ndaluar. Të kesh një burim të tillë nuk paraqet asnjë problem. Në total, ofruesit përmes Agjentëve, pa dashje, tregojnë shumë më tepër për rrjetin e tyre sesa ia vlen: llojet DPI dhe DNS, vendndodhjen e Agjentit (nyja qendrore dhe rrjeti i shërbimit?), shënuesit e rrjetit të vonesave dhe humbjeve - dhe kjo është vetëm më e dukshme. Ashtu si dikush mund të monitorojë veprimet e agjentëve për të përmirësuar disponueshmërinë e burimeve të tyre, dikush mund ta bëjë këtë për qëllime të tjera dhe nuk ka pengesa për këtë. Rezultati është një instrument me dy tehe dhe shumë aspekte, çdokush mund ta shohë këtë.
Burimi: www.habr.com