Arvutame «Revizor» agente

Pole saladus, et Venemaal jälgib automatiseeritud süsteem «Revizor» blokeeringute kontrolli keelatud teabe nimekirja järgi. Kuidas see töötab, on hästi kirjutatud siinses artiklis Habr, pilt sealt samast:

Otseselt teenusepakkuja juures paigaldatakse moodul «Agent Revizor»:

Moodul «Agent Revizor» on automatiseeritud süsteemi «Revizor» (AS «Revizor») struktuurne element. Antud süsteem on mõeldud sideoperaatorite poolt nõuete järgimise kontrollimiseks, mis on kehtestatud 27. juuli 2006. aasta föderaalse seaduse nr 149-ФЗ „Teabe, teabetehnoloogiate ja teabe kaitse kohta“ artiklite 15.1-15.4 raames.

AS «Revizor» loomise peamine eesmärk on tagada sideoperaatorite nõuete järgimise jälgimine, mis on kehtestatud 27. juuli 2006. aasta föderaalse seaduse nr 149-ФЗ „Teabe, teabetehnoloogiate ja teabe kaitse kohta“ artiklite 15.1-15.4 raames seoses keelatud teabe juurde pääsemise tõendite (andmete) tuvastamise ja kogumisega.

Arvestades, et vähemalt paljud teenusepakkujad on selle seadme endale paigaldanud, pidi saama suur võrk proovide-majakate, nagu RIPE Atlas , ja veelgi enam, kuid suletud juurdepääsuga. Siiski, majakas on majakas, et saata signaale igas suunas, aga mis siis, kui need kinni püüda ja vaadata, mida me püüdsime ja kui palju?

Enne kui hakkame arvestama, vaatame, miks see üldse võimalik olla võiks.

Veidi teooriat

Agendid kontrollivad ressursi kättesaadavust, sealhulgas HTTP(S) päringute kaudu, nagu see näiteks:

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äring koos lisaks koormusele ka ühenduse loomise faasiga: vahetus SYN ja SYN-ACK, ja ühenduse lõpetamise faasiga: FIN-ACK.

Keelatud teabe register sisaldab mitmeid blokeeringu tüüpe. Ilmselgelt, kui ressurssi blokeeritakse IP-aadressi või domeeninime järgi, ei näe me mingeid päringuid. Need on kõige hävitavamad blokeeringu tüübid, mis viivad kõikide ressursside kättesaamatusele ühel IP-aadressil või kogu info domeenis. Samuti on olemas blokeeringu tüüp „URL-i järgi“. Sel juhul peab filtreerimissüsteem analüüsima päringu HTTP-pealkirja, et täpselt määrata, mida blokeerida. Ja enne seda, nagu ülal näha, peab toimuma ühenduse loomise faas, mida on võimalik jälgida, kuna tõenäoliselt filtreerija laseb selle läbi.

Selleks tuleb valida sobiv vaba domeen, millel on URL-i järgi blokeering ja HTTP, et hõlbustada filtreerimissüsteemi tööd; soovitavalt juba ammu unustatud domeen, et minimeerida kõrvalise liikluse sattumist peale Agentide. See ülesanne osutus üldse mitte keeruliseks, keelatud teabe registris on piisavalt palju vabu domeene ja igasuguste maitse jaoks. Seetõttu osteti domeen, seoti see IP-aadressidega VPS-is, kus on käimas tcpdump ja hakati kokku lugema.

Revisjon „Revisorite“

Ootasin näha perioodilisi päringute piike, mis meie arvates viitaks juhitavale tegevusele. Ei saa öelda, et ma seda täielikult ei näinud, kuid selget pilti kindlasti ei olnud:

Mis ei ole üllatav, isegi täiesti kasutuseta domeenile, mille IP-d ei kasutata kunagi, tuleb lihtsalt tohutul hulgal mitte nõutud teavet, selline on tänapäeva Internet. Kuid õnneks vajasime ainult konkreetse URL-i päringute hulka, seega leiti kõik skannerid ja paroolide pealtnäha kiiresti üles. Samuti oli üsna lihtne mõista, kus on massiliselt sarnaste päringute ülekoormus. Edasi koostasin IP-aadresside esinemise sagedused ja läksin käsitsi läbi kogu tippude, eraldades need, kes eelnevatel etappidel mööda pääsesid. Täiendavalt lõikasin välja kõik allikad, mis saatsid ühe paketi, neid ei olnud enam palju. Ja selline see on:

Väike lühiüksus. Üks päev pärast sain oma hosting-teenuselt üsna ebamugava sisu kirja, et minu ressursid sisaldavad RKN-i keelatud nimekirja ning seetõttu blokeeritakse need. Esiteks arvasin, et mu konto on blokeeritud, kuid see polnud nii. Siis arvasin, et mind lihtsalt hoiatatakse millegi eest, mis mulle juba teada. Kuid selgus, et hostija aktiveeris oma filtri minu domeeni ees ja lõpuks sattusin ma kahe paigutuse alla: nii teenusepakkuja kui ka hostija poolt. Filter väljastas ainult päringute lõpu: FIN-ACK ja RST lõigates kogu HTTP kaudu keelatud URL-i. Nagu ülalt näha, pärast esimest päeva hakkasin ma saama vähem andmeid, kuid sain neid ikka, mis olid piisavad päringute allikate arvu loendamiseks.

Asja juurde. Minu arvates on kaks tõusud päeva jooksul selgelt nähtavad, esimene on väiksem, pärast keskööd Moskvast, teine lähemal kuue hommikul ja jätkub kuni 12 päeval. Tippaeg ei lange täpselt samasse aega. Esiteks tahtsin välja tuua IP-aadressid, mis langesid ainult nendesse ajavahemikesse ja igas ajavahemikus, oletades, et kontrollid Agentide poolt toimuvad perioodiliselt. Kuid hoolika vaatamisega avastasin kiiresti perioode, mis langesid teistesse intervallidesse, erinevate sagedustega, sealhulgas ühe päringu iga tunni jooksul. Siis mõtlesin ajavöönditele ja sellele, et võib-olla on sellel osa, siis mõtlesin, et kogu süsteem ei pruugi olla globaalselt sünkroniseeritud. Lisaks mängib kindlasti rolli NAT ja sama Agent võib edastada päringuid erinevatelt avalikelt IP-elt.

Kuna minu algne eesmärk polnud täpsus, loendasin kõik nädalas esinevad aadressid ja sain - 2791. TCP sessioonide keskmine arv, mis on loodud ühe aadressiga, on 4, mediaan 2. Top sessioonid aadressidele: 464, 231, 149, 83, 77. Maksimum 95% valimist - 8 sessiooni aadressi kohta. Mediaan ei ole väga kõrge, meenutan, et graafikust on näha, et on ilmne päevane perioodne rütm, seetõttu võiks oodata midagi umbes 4 kuni 8 seitsme päeva jooksul. Kui eemaldada kõik korduvad sessioonid, saame täpselt mediaani, mis on 5. Kuid ma ei suutnud neid selge kriteeriumi järgi välja jätta. Vastupidi, valimite kontroll näitas, et nad on seotud keelatud ressursi päringutega.

Aadressidest olenemata on Internetis olulisemad autonoomsed süsteemid — AS, mida on kokku saanud 1510, keskmiselt 2 aadressi AS-i kohta, mediaan on 1. Topp aadresse AS-ides: 288, 77, 66, 39, 27. Maksimum 95% valimist on 4 aadressi AS-i kohta. Siin on mediaan oodatav — üks agent pakkuja kohta. Topp on samuti oodatav — selles on suured mängijad. Suures võrgus peaksid ilmselt agentide suhted olema igas operaatori kohaloleku regioonis, ärgem unustagem NAT-i. Riikide lõikes on maksimaalsed väärtused: 1409 — RU, 42 — UA, 23 — CZ, 36 teistest regioonidest, mis ei ole RIPE NCC. Venemaalt väljaspoolt pärit päringud tõmbavad tähelepanu. Tõenäoliselt on seda võimalik selgitada geolokatsiooni vigade või registrite viga andmete täitmisel. Või sellega, et Venemaa ettevõttel võivad olla mittevenelased juured või olla välisettevõtte esindatus, kuna see on lihtsam, kui tegeleda välisorganisatsiooniga RIPE NCC. Mõned osad on kahtlemata üleliigsed, kuid usaldusväärselt on neid keeruline eraldada, kuna ressurss on blokeeritud ja teisel päeval on see kahekordse blokeeringu all ning enamik sessioone koosnevad vaid paarist teeninduspaketist. Lepime kokku, et see on väike osa.

Nende numbreid saab juba võrrelda Venemaa pakkujate arvuga. RKNi andmetel on tunnustusi "Andmeside teenuste, välja arvatud hääl" — 6387, kuid see on tugevalt ülespoole hinnatud hinnang, mitte kõik need litsentsid ei seondu Interneti pakkujatega, kellele tuleb paigaldada agent. RIPE NCC piirkonnas on sarnane arv AS-e, mis on Venemaal registreeritud — 6230, millest mitte kõik pakkujad. UserSide tegi rangema arvestuse ja leidis 2017. aastal 3940 ettevõtet, ja see on pigem ülevaate hinnang. Igatahes on meil AS-ide arv, mis on kaks ja pool korda väiksem. Kuid siin tuleks mõista, et AS ei ole rangelt võrdne pakkujaga. Mõnedel pakkujatel ei ole oma AS-i, mõnel on neid rohkem kui üks. Kui eeldada, et agent on ikkagi Kõikjal, siis tähendab see, et keegi filtreerib tugevamini kui teised, nii et nende päringud on nähtamatut prügi, kui nad üldse kohale jõuavad. Kuid karedate hindamiste jaoks on see täiesti talutav, isegi kui midagi on minu hooletuse tõttu kaduma läinud.

DPI kohta

Kuigi mu hostitarnija aktiveeris oma filtrid teisel päeval, näitab esimese päeva teave, et blokeeringud töötavad tõhusalt. Ainult 4 allikat suudavad läbida ja neil on täielikult lõpetatud HTTP ja TCP sessioonid (nagu eespool näidatud). Veel 460 võivad saata GET, kuid sessioon katkeb kohe RST. Pange tähele 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"

#See on, mida filter saatis
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#Ja see on algse sõlme katse kaotuse saamiseks
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"

#Algne sõlm mõistab, et sessioon on purunenud
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"

Selle variatsioonid võivad olla erinevad: vähem RST või rohkem edastamisi — olenevalt sellest, mida filter algsele sõlmele saadab. Igatahes on see kõige usaldusväärsem mall, mis näitab, et nõuti just keelatud ressurssi. Lisaks on alati vastus, mis ilmneb sessioonis TTL suurem kui eelnevates ja järgnevates pakettides.

Ülejäänud ei ole isegi nähtavad GET:

TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"

#See on, mida filter saatis
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"

Või nii:

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"

#See on, mida filter saatis
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"

#Taaskord filter, mitu korda
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...

Erinevus on kindlasti nähtav, TTL kui filter saadab midagi. Kuid sageli ei pruugi üldse midagi saabuda:

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"
...

Või nii:

TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"

#Möödus mitu sekundit ilma liikluseta

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

Ja see kõik kordub ja kordub ja kordub, nagu graafikust näha, kindlasti mitte üks kord, iga päev.

IPv6 kohta

Hea uudis - see on olemas. Võin kindlalt öelda, et 5 erinevalt IPv6-aadressilt toimub perioodilisi päringuid keelatud ressursside juurde, just see käitumine, mida ma Agendilt ootasime. Üks IPv6-aadressidest ei ole filtrisse sattunud ning näen täieõiguslikku sessiooni. Kahelt teiselt nägin ainult ühte lõpetamata sessiooni, millest üks katkestati filtrist, teine ajast. RST Kokku on neid kokku 7.

Kuna aadresse on vähe, uurisin neid üksikasjalikult ning selgus, et seal on sisuliselt ainult 3 teenusepakkujat, kellele võiks aplodeerida! Veel üks aadress on Venemaa pilvehosting (ei filtreeri), teine on Saksamaa teaduskeskus (seal on filter, kus?). Küsimus, miks nad kontrollivad keelatud ressursside kättesaadavust plaanipäraselt, on hea. Ülejäänud kaks tegid ühe päringu ning asuvad väljaspool Venemaad, kuid üks neist filtreeritakse (ütleme, et vahekäigus?).

Blokeeringud ja Agendid on IPv6 jaoks suur takistus, mille rakendamine ei edene juba niigi kiiresti. See on kurb. Need, kes selle ülesande täielikult lahendasid, saavad end selle eest uhkelt tunda.

Kokkuvõtteks

Ma ei püüdnud saavutada 100% täpsust, palun mind selle eest andestada, loodan, et keegi soovib teha sellist tööd suurema täpsusega. Minu jaoks oli oluline mõista, kas selline lähenemine toimib üldse. Vastus - toimib. Saadud numbrid on esialgses plaanis, arvan, et üsna usaldusväärsed.

Mida veel oleks võinud teha ja mida ma laiskusest ei teinud - lugeda päringud DNS-ile. Need ei ole filtreeritud, kuid ei anna suurt täpsust, kuna need toimivad ainult domeeni jaoks, mitte kogu URL-i jaoks. Rikkalikkus peaks olema nähtav. Kui seda kombineerida sellega, mida otse päringutes nähakse, võimaldab see eraldada liigset ning saada rohkem teavet. Võib-olla isegi tuvastada teenusepakkujate kasutatavad DNS-i arendajad ja veel palju muud.

Ma ei oodanud absoluutselt, et minu VPS-i hostija lisab ka oma filtri. Võib-olla on see tavaline praktika. Lõppude lõpuks saadab RKN päringu ressursi eemaldamiseks just hostijale. Kuid see ei üllata mind ja isegi, kuskil, mängis see kasuks. Filter töötas väga tõhusalt, lõigates ära kõik õiged HTTP päringud keelatud URL-ile, kuid vale, mis olid enne selle kaudu filtrist, jõudsid kohale, kuigi ainult lõpu näol: FIN-ACK ja RST — miinus miinusega ja peaaegu saime plussi. Muide, IPv6 hostiser ei filtreeritud. Loomulikult mõjutas see kogutud materjali kvaliteeti, kuid see andis siiski võimaluse näha perioodilisust. Selgus, et see on oluline aspekt ressursside paigutuse valimisel, ärge unustage huvituda küsimusest, kuidas korraldatakse tööd keelatud saitide nimekirjaga ja RKN-i päringutega.

Alguses võrdlesin AS-i „Revizor” RIPE Atlas. See võrdlus on täiesti põhjendatud ja suur agentide võrgustik võib tuua kasu. Näiteks ressursi kättesaadavuse kvaliteedi määramine erinevate teenusepakkujate poolt eri piirkondades. Saame arvestada viivitusi, saame koostada graafikuid, saame seda kõike analüüsida ja näha muudatusi nii kohalikul kui ka globaalset tasandil. See ei ole kõige otsem tee, kuid astronoomid kasutavad ju „standardseid küünlaid”, miks siis mitte kasutada agente? Teades (leidnud) nende standardset käitumist, saab määrata muudatused, mis nende ümber toimuvad ja kuidas see mõjutab osutatavate teenuste kvaliteeti. Ja selleks ei pea ise proove võrgus paigutama, need on juba paigutanud Roskomnadzor.

Veel üks aspekt, mida soovin käsitleda, on see, et iga tööriist võib olla relv. AS „Revizor” on suletud võrgustik, kuid agendid reetavad kõiki, saates päringud keelatud nimekirjas olevatele ressurssidele. Sellise ressursi omandamine ei valmista absoluutselt mingeid probleeme. Seega räägivad teenusepakkujad agentide kaudu, seda ise tahtmata, oma võrgust palju rohkem, kui ilmselt peaks: DPI ja DNS tüübid, agendi paiknemine (keskne sõlm ja teenusevõrk?), võrgu hilinemise ja kadumise markerid — ja see on vaid kõige ilmekam. Nii nagu keegi võib jälgida agentide tegevust, et parandada oma ressursside kättesaadavust, võib keegi seda teha ka muudel eesmärkidel, ja sellele pole takistusi. Tõeliselt kahe teraga ja väga mitmekesine tööriist on välja kujunenud, igaüks võib sellel veenduda.

Allikas: habr.com