Ne paslaptis, kad blokavimo draudžiamos informacijos sąraše kontrolę Rusijoje stebi automatizuota sistema „Inspektorius“. Čia gerai parašyta, kaip tai veikia , nuotrauka iš tos pačios vietos:
Įdiegta tiesiai pas tiekėją :
Modulis „Agento inspektorius“ yra automatizuotos sistemos „Inspektorius“ (AS „Inspektorius“) struktūrinis elementas. Ši sistema skirta stebėti, kaip telekomunikacijų operatoriai laikosi prieigos apribojimo reikalavimų pagal 15.1 m. liepos 15.4 d. Federalinio įstatymo Nr. 27-FZ „Dėl informacijos, informacinių technologijų ir informacijos apsaugos“ 2006–149 straipsnių nuostatas. “
Pagrindinis AS „Revizor“ kūrimo tikslas – stebėti, ar telekomunikacijų operatoriai laikosi 15.1 m. liepos 15.4 d. Federalinio įstatymo Nr. 27-FZ „Dėl informacijos, informacinių technologijų ir informacijos apsaugos“ 2006–149 straipsnių reikalavimų. “ kalbant apie prieigos prie draudžiamos informacijos faktų nustatymą ir pagalbinės medžiagos (duomenų) gavimą apie pažeidimus, siekiant apriboti prieigą prie draudžiamos informacijos.
Atsižvelgiant į tai, kad jei ne visi, tai daugelis paslaugų teikėjų įdiegė šį įrenginį, turėjo būti didelis švyturių zondų tinklas, pvz. ir dar daugiau, bet su uždara prieiga. Tačiau švyturys yra švyturys, skirtas siųsti signalus į visas puses, bet kas būtų, jei juos gaudytume ir pamatytume, ką pagavome ir kiek?
Prieš skaičiuodami, pažiūrėkime, kodėl tai netgi įmanoma.
Teorijos tiek
Agentai tikrina išteklių prieinamumą, įskaitant HTTP(S) užklausas, tokias kaip ši:
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"
Be naudingosios apkrovos, prašymą taip pat sudaro ryšio užmezgimo fazė: mainai SYN и SYN-ACK, ir ryšio užbaigimo etapai: FIN-ACK.
Draudžiamos informacijos registre yra keletas blokavimo tipų. Akivaizdu, kad jei išteklius blokuoja IP adresas arba domeno pavadinimas, mes nematysime jokių užklausų. Tai yra žalingiausi blokavimo tipai, dėl kurių visi ištekliai viename IP adresu arba visa domeno informacija tampa neprieinami. Taip pat yra blokavimo „pagal URL“ tipas. Tokiu atveju filtravimo sistema turi išanalizuoti HTTP užklausos antraštę, kad tiksliai nustatytų, ką blokuoti. Ir prieš tai, kaip matyti aukščiau, turėtų būti ryšio užmezgimo etapas, kurį galite pabandyti stebėti, nes greičiausiai filtras jo praleis.
Norėdami tai padaryti, turite pasirinkti tinkamą nemokamą domeną su „URL“ ir HTTP blokavimo tipu, kad palengvintumėte filtravimo sistemos darbą, pageidautina, seniai apleistą, kad būtų sumažintas pašalinio srauto, išskyrus agentus, patekimas. Ši užduotis pasirodė visai nesunki, draudžiamos informacijos registre yra gana daug nemokamų domenų ir kiekvienam skoniui. Todėl domenas buvo nupirktas ir susietas su veikiančio VPS IP adresais tcpdump ir prasidėjo skaičiavimas.
„Auditorių“ auditas
Tikėjausi, kad periodiškai gausiu užklausų, kurios, mano nuomone, rodytų kontroliuojamus veiksmus. Neįmanoma sakyti, kad visai nemačiau, bet aiškaus vaizdo tikrai nebuvo:
Nenuostabu, kad net niekam nereikalingame domene ir niekada nenaudojamame IP tiesiog bus daugybė nepageidaujamos informacijos, toks yra šiuolaikinis internetas. Bet, laimei, man reikėjo tik konkretaus URL užklausų, todėl visi skaitytuvai ir slaptažodžių krekeriai buvo greitai rasti. Be to, pagal panašių prašymų masę buvo gana lengva suprasti, kur kilo potvynis. Tada aš suskaičiavau IP adresų atsiradimo dažnumą ir rankiniu būdu perėjau visą viršų, atskirdamas tuos, kurie to praleido ankstesniuose etapuose. Be to, iškirpau visus šaltinius, kurie buvo išsiųsti vienoje pakuotėje, jų nebebuvo daug. Ir štai kas atsitiko:
Mažas lyrinis nukrypimas. Po kiek daugiau nei dienos mano prieglobos paslaugų teikėjas atsiuntė gana supaprastinto turinio laišką, sakydamas, kad jūsų patalpose yra išteklius iš RKN draudžiamo sąrašo, todėl jis užblokuotas. Iš pradžių maniau, kad mano paskyra užblokuota, bet taip nebuvo. Tada pagalvojau, kad jie mane tiesiog įspėja apie tai, ką jau žinojau. Bet paaiškėjo, kad prieglobos serveris įjungė savo filtrą prieš mano domeną ir dėl to aš patekau į dvigubą filtravimą: tiekėjų ir prieglobos serverio. Filtras praėjo tik užklausų pabaigas: FIN-ACK и RST nutraukti visą HTTP uždraustame URL. Kaip matote iš aukščiau esančio grafiko, po pirmos dienos pradėjau gauti mažiau duomenų, bet vis tiek juos gavau, o to visiškai pakako užklausų šaltinių skaičiavimui.
Eikite į esmę. Mano nuomone, kiekvieną dieną aiškiai matomi du pliūpsniai, pirmasis mažesnis, po vidurnakčio Maskvos laiku, antrasis arčiau 6 ryto su uodega iki 12 val. Smailės neįvyksta tiksliai tuo pačiu metu. Iš pradžių norėjau pasirinkti IP adresus, kurie nukrito tik šiais laikotarpiais ir kiekvienu visais laikotarpiais, remdamasis prielaida, kad agentai tikrina periodiškai. Tačiau atidžiai peržiūrėjęs, greitai atradau periodus, patenkančius į kitus intervalus, su kitais dažniais, iki vieno prašymo kas valandą. Tada galvojau apie laiko juostas ir gal tai su jomis susiję, tada pagalvojau, kad apskritai sistema gali būti nesinchronizuota globaliai. Be to, NAT tikriausiai atliks tam tikrą vaidmenį ir tas pats agentas gali pateikti užklausas iš skirtingų viešųjų IP.
Kadangi mano pradinis tikslas nebuvo tikslus, suskaičiavau visus adresus, kuriuos radau per savaitę ir gavau - 2791. Iš vieno adreso nustatytas TCP seansų skaičius vidutiniškai yra 4, o mediana – 2. Daugiausia seansų vienam adresui: 464, 231, 149, 83, 77. Maksimalus nuo 95% imties yra 8 seansai vienam adresui. Mediana nėra labai aukšta, priminsiu, kad grafikas rodo aiškų dienos periodiškumą, todėl per 4 dienas galima būtų tikėtis kažko apie 8–7. Jei išmestume visus seansus, kurie įvyksta vieną kartą, gautume medianą, lygią 5. Bet negalėčiau jų atmesti pagal aiškų kriterijų. Priešingai, atsitiktinis patikrinimas parodė, kad jie buvo susiję su užklausomis dėl draudžiamų išteklių.
Adresai yra adresai, bet internete autonominės sistemos – AS, kuri pasirodė svarbesnė 1510, vidutiniškai 2 adresai vienai AS, kurių mediana yra 1. Populiariausi AS adresai: 288, 77, 66, 39, 27. Didžiausia 95 % imties yra 4 adresai vienai AS. Čia tikimasi medianos – vienas agentas vienam teikėjui. Taip pat tikimės viršūnės – joje yra didelių žaidėjų. Dideliame tinkle agentai tikriausiai turėtų būti kiekviename operatoriaus buvimo regione ir nepamirškite apie NAT. Jei imsime pagal šalį, maksimumai bus: 1409 - RU, 42 - UA, 23 - CZ, 36 iš kitų regionų, o ne RIPE NCC. Dėmesį patraukia užklausos iš už Rusijos ribų. Tai tikriausiai galima paaiškinti geografinės vietos nustatymo klaidomis arba registratoriaus klaidomis pildant duomenis. Arba tai, kad rusiška įmonė gali neturėti rusiškų šaknų, arba turėti atstovybę užsienyje, nes taip lengviau, o tai natūralu bendraujant su užsienio organizacija RIPE NCC. Kai kuri dalis neabejotinai yra perteklinė, tačiau ją patikimai sunku atskirti, nes išteklius blokuojamas, o nuo antros dienos - dvigubas, o dauguma seansų tėra keitimasis keliais paslaugų paketais. Sutikime, kad tai maža dalis.
Šiuos skaičius jau galima palyginti su tiekėjų skaičiumi Rusijoje. „Ryšių paslaugų, skirtų duomenų perdavimui, išskyrus balsą“ licencijos - 6387, tačiau tai labai didelis įvertinimas iš viršaus, ne visos šios licencijos taikomos konkrečiai interneto tiekėjams, kuriems reikia įdiegti agentą. RIPE NCC zonoje Rusijoje registruotas panašus AS skaičius – 6230, iš kurių ne visos yra tiekėjai. ir 3940 m. gavo 2017 įmonių, ir tai greičiau įvertinimas iš viršaus. Bet kokiu atveju turime du su puse karto mažiau apšviestų AS. Tačiau čia verta suprasti, kad AS nėra griežtai lygus teikėjui. Kai kurie tiekėjai neturi savo AS, kai kurie turi daugiau nei vieną. Jeigu darysime prielaidą, kad Agentų vis dar turi visi, tai kažkas filtruojasi stipriau nei kiti, kad jų prašymai nesiskirtų nuo šiukšlių, jei išvis juos pasiekia. Bet apytiksliai vertinant, tai visai pakenčiama, net jei kažkas buvo prarasta dėl mano neapsižiūrėjimo.
Apie DPI
Nepaisant to, kad mano prieglobos paslaugų teikėjas savo filtrą įjungė nuo antros dienos, remiantis pirmos dienos informacija galime daryti išvadą, kad blokavimas veikia sėkmingai. Tik 4 šaltiniai galėjo pasiekti ir visiškai užbaigti HTTP ir TCP seansus (kaip aukščiau pateiktame pavyzdyje). Galima atsiųsti dar 460 GET, bet sesija nedelsiant nutraukiama RST. Atkreipkite dėmesį į 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"
To variantai gali būti įvairūs: mažiau RST ar daugiau pakartotinių siuntimų – taip pat priklauso nuo to, ką filtras siunčia į šaltinio mazgą. Bet kokiu atveju tai yra patikimiausias šablonas, iš kurio aišku, kad buvo prašoma uždrausto šaltinio. Be to, visada yra atsakymas, kuris pasirodo seanso metu TTL didesnis nei ankstesnėse ir vėlesnėse pakuotėse.
Jūs to net nematote iš kitų 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"
Arba taip:
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"
...
Skirtumas tikrai matomas TTL jei kas nors ateina iš filtro. Tačiau dažnai nieko gali nepavykti:
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"
...
Arba taip:
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"
...
Ir visa tai kartojasi ir kartojasi, ir kartojasi, kaip matyti iš grafiko, ne kartą, kasdien.
Apie IPv6
Geros naujienos yra tai, kad ji egzistuoja. Galiu patikimai teigti, kad periodinės užklausos į draudžiamus išteklius gaunamos iš 5 skirtingų IPv6 adresų, o būtent tokio agentų elgesio ir tikėjausi. Be to, vienas iš IPv6 adresų nepatenka į filtravimą ir matau visą seansą. Iš dar dviejų mačiau tik vieną nebaigtą seansą, iš kurių vienas buvo nutrauktas RST iš filtro, antras pagal laiką. Visas kiekis 7.
Kadangi adresų nedaug, visus juos išsamiai išstudijavau ir paaiškėjo, kad ten yra tik 3 tiekėjai, jiems galima pagirti ovacijų! Kitas adresas – debesų priegloba Rusijoje (nefiltruoja), kitas – tyrimų centras Vokietijoje (yra filtras, kur?). Tačiau kodėl jie tikrina draudžiamų išteklių prieinamumą pagal tvarkaraštį, yra geras klausimas. Likę du pateikė vieną prašymą ir yra už Rusijos ribų, o vienas iš jų yra filtruojamas (juk tranzitu?).
Blokavimas ir agentai yra didelė kliūtis IPv6, kurio diegimas vyksta ne itin greitai. Liudna. Tie, kurie išsprendė šią problemą, gali visiškai savimi didžiuotis.
užbaigiant
Aš nesiekiau 100% tikslumo, atleiskite man už tai, tikiuosi, kad kas nors norės pakartoti šį darbą su didesniu tikslumu. Man buvo svarbu suprasti, ar toks požiūris pasiteisins iš esmės. Atsakymas yra taip. Gauti skaičiai, kaip pirmas apytikslis, manau, yra gana patikimi.
Ką dar buvo galima padaryti ir ką aš tingėjau daryti, tai skaičiuoti DNS užklausas. Jie nefiltruojami, bet taip pat nesuteikia didelio tikslumo, nes veikia tik domenui, o ne visam URL. Dažnis turėtų būti matomas. Jei jį derinsite su tuo, kas matoma tiesiogiai užklausose, tai leis atskirti nereikalingus dalykus ir gauti daugiau informacijos. Netgi galima nustatyti tiekėjų naudojamo DNS kūrėjus ir dar daugiau.
Visiškai nesitikėjau, kad priegloba taip pat įtrauks savo filtrą mano VPS. Galbūt tai yra įprasta praktika. Galų gale RKN siunčia prieglobos serveriui prašymą ištrinti išteklius. Bet tai manęs nenustebino ir kai kuriais atžvilgiais netgi išėjo į naudą. Filtras veikė labai efektyviai, pašalindamas visas teisingas HTTP užklausas į draudžiamą URL, bet ne teisingos, kurios anksčiau buvo perėjusios per teikėjo filtrą, jas pasiekė, nors ir tik galūnių pavidalu: FIN-ACK и RST - minusas už minusą ir vos nepasirodė pliusas. Beje, prieglobos serveris nefiltravo IPv6. Žinoma, tai turėjo įtakos surinktos medžiagos kokybei, bet vis tiek leido matyti periodiškumą. Paaiškėjo, kad tai yra svarbus momentas renkantis išteklių talpinimo vietą; nepamirškite pasidomėti darbo su draudžiamų vietų sąrašu ir RKN užklausomis organizavimo klausimu.
Pradžioje lyginau AS „Inspektorius“ su . Šis palyginimas yra gana pagrįstas ir didelis agentų tinklas gali būti naudingas. Pavyzdžiui, išteklių prieinamumo iš skirtingų tiekėjų įvairiose šalies dalyse kokybės nustatymas. Galite apskaičiuoti vėlavimus, kurti grafikus, visa tai analizuoti ir matyti pokyčius, vykstančius tiek lokaliai, tiek globaliai. Tai nėra pats tiesiausias būdas, bet astronomai naudoja „standartines žvakes“, kodėl gi nepasinaudojus agentais? Žinodami (radę) jų įprastą elgesį, galite nustatyti aplink juos vykstančius pokyčius ir kaip tai įtakoja teikiamų paslaugų kokybę. Ir tuo pačiu metu jums nereikia savarankiškai įdėti zondų į tinklą; „Roskomnadzor“ juos jau įdiegė.
Kitas dalykas, kurį noriu paliesti, yra tai, kad kiekvienas įrankis gali būti ginklas. AS "Inspektorius" yra uždaras tinklas, tačiau Agentai perduoda visus, siųsdami užklausas dėl visų resursų iš draudžiamo sąrašo. Turint tokį išteklį, jokių problemų nekyla. Iš viso paslaugų teikėjai per agentus, nesąmoningai, pasako apie savo tinklą daug daugiau, nei tikriausiai verta: DPI ir DNS tipai, agento vieta (centrinis mazgas ir paslaugų tinklas?), tinklo vėlavimų ir nuostolių žymekliai - ir tai yra tik akivaizdžiausias. Kaip kažkas gali stebėti agentų veiksmus, kad pagerintų savo išteklių prieinamumą, kažkas gali tai padaryti kitais tikslais ir tam nėra jokių kliūčių. Rezultatas yra dviašmenis ir labai daugialypis instrumentas, tai gali pamatyti bet kas.
Šaltinis: www.habr.com