Arvutame "Revizor" agente

Pole saladus, et Venemaal jälgib automatiseeritud süsteem "Revizor" blokeeringute kontrollimist keelatud informatsiooni loendite alusel. Kuidas see töötab, on hästi kirjutatud siin: artikkel Habris, pilt sealt:

Teenusepakkuja juures on paigaldatud "Revizor Agent" moodul:

"Revizor Agent" moodul on automatiseeritud süsteemi "Revizor" (AS "Revizor") struktuuriline element. See süsteem on ette nähtud sideoperatsioonide nõuete järgimise kontrollimiseks juurdepääsu piiramise osas, nagu on sätestatud 27. juuli 2006. aasta föderaalse seaduse nr 149-FZ "Informatsiooni, informatsioonitehnoloogia ja informatsiooni kaitse kohta" artiklites 15.1-15.4.

AS «Revisor» peamine eesmärk on tagada sideoperaatorite jaoks nõuete järgimise jälgimine, nagu on kehtestatud Venemaa Föderaalses seaduses 27. juulist 2006 nr 149-ФЗ „Teabe, infotehnoloogia ja teabe kaitse kohta“ paragrahvide 15.1-15.4 osas, mis puudutab keelatud teabe juurde pääsemise tuvastamist ja kinnitavate materjalide (andmete) saamist rikkumiste kohta, mis piiravad juurdepääsu keelatud teabele.

Arvestades, et paljud teenusepakkujad on selle seadme enda juures paigaldanud, peaks olema loodud suur proovide-majakate võrgustik, sarnane RIPE Atlas ja isegi rohkem, aga suletud juurdepääsuga. Kuid majakas on ikkagi majakas, et saata signaale kõikides suundades. Aga mis siis, kui neid püütakse ja vaadatakse, mida me püüdsime ja kui palju?

Enne lugemist vaatame, miks see üldse võimalik on.

Natuke teooriat

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

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äringu kõrval, mis sisaldab kasulikku koormust, koosneb lisaks ka ühenduse loomise faasist: vahetus SYN ja SYN-ACK, ja ühenduse lõpetamise faasist: FIN-ACK.

Keelatud teabe register sisaldab mitut tüüpi blokeeringuid. Ilmselgelt, kui ressurssi blokeeritakse IP-aadressi või domeeninime järgi, ei näe me ühtegi päringut. Need on kõige hävitavamad blokeeringud, mis toovad kaasa kõikide ressursside kättesaamatuse samal IP-aadressil või kogu teabe domeenis. Samuti on olemas blokkeerimise tüüp „URL-i järgi”. Sel juhul peab filtreerimissüsteem analüüsima HTTP-päringu päist, et täpselt määrata, mida blokeerida. Enne seda peab toimuma ühenduse loomise faas, mida saab tõenäoliselt jälgida, kuna filtril on tõenäoliselt võimalus see mööda lasta.

Selleks tuleb valida sobiv vaba domeen, millel on URL-tüüpi blokeering ja HTTP, et kergendada filtreerimissüsteemi tööd. Soovitav on valida pikka aega hüljatud domeen, et minimeerida lisaliiklust, välja arvatud Agendid. See ülesanne osutus üsna lihtsaks, vaba domeene keelatud teabe registris on küllaga ja igasuguste veebilehtede jaoks. Seetõttu osteti domeen, seoti see VPS-i IP-aadressidega, millel oli käivitada. tcpdump ja algas arvutamine.

Revisjon „Revisoreid“

Ootasin perioodiliste päringute tõusude nägemist, mis näitaksid minu arvates juhitud tegevust. Ei saa öelda, et ma seda üldse ei näinud, kuid selget pilti kindlasti ei olnud:

Pole ime, isegi täiesti kasutu domeen ja kunagi mitte kasutatav IP kogub kohutavalt palju soovimatut teavet, see on tänapäeva Internet. Õnneks vajasin aga ainult konkreetse URL-i päringute andmeid, seetõttu leidsin kiiresti kõik skannerid ja paroolide järjekid. Samuti oli lihtne aru saada, kus toimus massiline sama tüüpi päringute ülekoormus. Edasi koostasin IP-aadresside esinemise sagedused ja läbisin kogu tabeli käsitsi, eraldades need, kes eelmistest etappidest läbi libisesid. Lisaks eemaldasin kõik allikad, kes saatsid ainult ühe paketi, neid polnud palju. Ja tulemus oli järgmine:

Veidi poeetiline kõrvalepõige. Veidi rohkem kui päev hiljem saatis mu hosting-teenuse pakkuja üsna ümarate väljenditega kirja, et teie ressurssidelt leiti RKN-i musta nimekirja kuuluv sisu, mistõttu see blokeeritakse. Algul mõtlesin, et mu konto on blokeeritud, kuid see polnud nii. Siis mõtlesin, et mind lihtsalt hoiatatakse millegi eest, millest ma juba teadsin. Kuid osutus, et hostija aktiveeris oma filtri minu domeeni ees ja lõpuks sattusin kahefiltermise alla: teenusepakkujate ja hostija poolt. Filter vahelesegasid ainult päringute lõppe. FIN-ACK ja RST kärpides kogu HTTP keelatud URL-i alusel. Nagu ülaltoodud graafikust näha, hakkasin esimestest päevadest alates saama vähem andmeid, kuid ma siiski sain neid, mis piisavalt katab päringute allikate arvutamise ülesande.

As for the matter at hand, it is quite clear to me that there are two spikes each day; the first, smaller one occurs after midnight Moscow time, and the second around 6 AM, extending into noon. The peak doesn't happen at exactly the same time. Initially, I wanted to highlight the IP addresses that fell within these periods and those that appeared across all periods, based on the assumption that checks by Agents are done periodically. However, upon closer inspection, I quickly discovered periods that fell into other intervals with different frequencies, even down to one request every hour. Then I thought about time zones and considered that this could be a factor; I also wondered if the system might not be globally synchronized. Furthermore, NAT would surely play a role, as the same Agent could make requests from different public IPs.

Since my initial goal was not accuracy, I counted all the addresses that came up over the week and got — 2791. Üksikute aadresside puhul on keskmine TCP sessioonide arv neljalt aadressilt 4, medianna 2. Suurim sessioonide arv aadressil: 464, 231, 149, 83, 77. 95% valimist maksimum — 8 sessiooni aadressi kohta. Medianna ei ole eriti kõrge, meenutan, et graafikust on selgelt näha päevane perioodsus, seega võis oodata midagi vahemikus 4 kuni 8 seitsme päeva jooksul. Kui välja arvata kõik ühekordselt esinevad seansid, saame tõepoolest medianna 5. Kuid ei suutnud neid selgest kriteeriumist kõrvaldada. Vastupidi, valimipõhine kontroll näitas, et need on seotud keelatud ressursi päringutega.

Aadressid on tähtsad, kuid internetis on olulisemad autonoomsed süsteemid — AS, mida on tekkinud 1510, keskmiselt 2 aadressi AS-is, mediaan 1. Topp aadressid AS-is: 288, 77, 66, 39, 27. Maksimum 95% valimist on 4 aadressi AS-is. Siin on mediaan ootuspärane — üks agenti pakkuja kohta. Topp on samuti ootuspärane — seal on suured mängijad. Suures võrgus peaksid agentuurid olema kohal igas operaatori piirkonnas, ärgem unustagem ka NAT-i. Riikide kaupa vaadates on maksimumid: 1409 — RU, 42 — UA, 23 — CZ, 36 teistest piirkondadest, mitte RIPE NCC-st. Venemaalt saabuvad päringud tõmbavad tähelepanu. Seda võib ilmselt selgitada geolokatsiooni vigade või registripidajate eksimustega andmete täitmisel. Või võib juhtuda, et Venemaa ettevõttel on mitte-venelased juured või omab väl representatsiooni, sest nii on lihtsam, tegeledes välisorganisatsiooniga RIPE NCC. Osa on kindlasti üleliigne, kuid usaldusväärselt eristada seda on keeruline, kuna ressurss on blokeeritud, ja teisel päeval on see kahekordse blokeeringu all ning enamik seansse koosneb vaid paarist teeninduspaketist. Leppime kokku, et see on väike osa.

Nende numbritega saab juba võrrelda Venemaa pakkujate arvuga. RKNi andmete kohaselt on litsentse "Andmeside teenuste, välja arvatud häält" — 6387, kuid see on tugevalt üles hinnatud number, mitte kõik need litsentsid ei kuulu just nendele Interneti-teenuse pakkujatele, kellele on vaja Agent paigaldada. RIPE NCC piirkonnas on sarnane AS-de arv, mis on Venemaal registreeritud — 6230, millest mitte kõik teenusepakkujad. UserSide tegi rangema arvestuse ja sai 2017. aastal 3940 ettevõtet, ja see on pigem üles hinnatud number. Igatahes näeme, et avalike AS-de arv on kaks ja pool korda väiksem. Siiski tuleb mõista, et AS ei ole rangelt võrdne teenusepakkujaga. Mõnedel teenusepakkujatel ei ole oma AS-i, mõnel on rohkem kui üks. Kui eeldada, et Agendid on tõepoolest kõikjal, tähendab see, et mõned filtreerivad tugevamalt kui teised, nii et nende päringud ei ole prügist eristatavad, kui nad üldse kohale jõuavad. Kuid jämedaks hindamiseks on see täiesti vastuvõetav, isegi kui midagi on kaduma läinud minu eksimuse tõttu.

DPI kohta

Kuigi minu hostiteenuse pakkuja aktiveeris oma filtri alates teise päeva, võib esimese päeva andmetest järeldada, et blokeeringud toimivad tõhusalt. Ainult 4 allikat suudavad läbi pääseda ja omavad täielikult lõpetatud HTTP ja TCP sessioone (nagu ülaltoodud näites). Veel 460 saavad saata GET, kuid sessioon katkeb koheselt 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 saadud filtrist
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 lähtepunkti katse kaotust saada
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"

#Lähtepunkt mõistab, et sessioon on hävitatud
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 edastusi — see sõltub ka sellest, mida filter saadab algsesse sõlme. Igatahes on see kõige usaldusväärsem malli, millest on näha, et küsiti just keelatud ressurssi. Pluss on alati olemas vastus, mis ilmub seansiga koos TTL suurema kui eelnevatel ja järgnevatel paketidel.

Teistest ei ole isegi näha 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"

#Siin on veel üks sõnum filtrilt
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"

#Jälle filter, korduvalt
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...

Erinevus on kindlasti nähtav TTL kui filter midagi saadab. 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õned sekundid on möödunud ilma liikluseta

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

Ja see kordub ja kordub taas, nagu graafikult näha, mitte vähem kui üks kord iga päev.

IPv6 kohta

Hea uudis — see on olemas. Ma võin kindlalt öelda, et 5 erinevast IPv6-aadressist tulevad perioodilised päringud keelatud ressurssidele, just selline agentide käitumine, mida ma ootasin. Üks IPv6-aadressidest ei jää filtreerimise alla ning ma näen täielikku sessiooni. Kahest teisest nägin vaid ühte lõpetamata sessiooni, millest üks katkestati RST filtri tõttu, teine aja tõttu. Kokku 7.

Kuna aadresse on vähe, uurisin neid põhjalikult ning selgus, et tegelikult on teenusepakkujaid vaid kolm, neile võib seista aplodeerida! Üks teine aadress on Venemaal asuv pilvepõhine hostimine (ei filtreeri), teine on Saksamaal asuv teaduskeskkond (seal on filter, kus?). Kuidas nad kontrollivad keelatud ressursside kättesaadavust ajakava järgi, on hea küsimus. Ülejäänud kaks tegid ühe päringu ja ei asu Venemaa piires, samas kui üks neist filtreeritakse (kas siiski transiidis?).

IPv6 kasutuselevõttu takistavad blokeeringud ja agentuurid on suur pidurdus, mille areng ei edene juba niigi kiiresti. See on kahju. Need, kes selle probleemi täielikult lahendasid, võivad selle üle uhked olla.

Kokkuvõtteks

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

Mida veel saaks teha ja mida ma laiskusega ei teinud — lugeda DNS-i päringuid. Need ei filtreerita, kuid ei anna ka suurt täpsust, kuna need töötavad ainult domeeni tasandil, mitte kogu URL-i jaoks. Perioodilisus peaks olema nähtav. Kui seda koos sellele, mis on otse päringutes nähtav, kombineerida, siis see võimaldaks eristada liigset ja saada rohkem teavet. Võib-olla isegi tuvastada DNS-i arendajad, keda pakkujad kasutavad, ja palju muud.

Ma ei oodanud üldse, et mu VPS-i eest vastutav hostija aktiveerib ka oma filtri. Võib-olla on see tavaline praktika. Lõppude lõpuks saadab RKN taotluse ressursi eemaldamiseks just hostijale. Kuid see ei üllatanud mind ja isegi osaliselt mängis see mulle kasuks. Filter töötas väga tõhusalt, blokeerides kõik õiged HTTP-päringud keelatud URL-ile, kuid vale, mis läbi edastajate filtri pääses, jõudis kohale, kui mitte midagi muud, siis ainult lõppudena: FIN-ACK ja RST — miinus miinuse peale ja peaaegu sai pluss. Muide, hostija ei blokeerinud IPv6. Loomulikult mõjutas see kogutud materjali kvaliteeti, kuid see andis siiski võimaluse näha perioodilisust. Selgus, et see on oluline punkt ressursside paigutamise koha valimise juures; ärge unustage uurida, kuidas korraldada tööd keelatud saitide nimekirjade ja RKN-i taotluste osas.

Alguses võrdlesin AS-i "Revisori" RIPE Atlas. See võrdlus on täiesti põhjendatud ja suur agentide võrk võib tuua kasu. Näiteks erinevate teenusepakkujate ressursi kättesaadavuse kvaliteedi määramine eri regioonidest. Saab mõõta viivitusi, luua graafikuid, analüüsida andmeid ja näha muudatusi nii lokaalsetel kui ka globaalsel tasandil. See ei ole kõige otsem tee, kuid astronoomid kasutavad ju "standardeid", miks mitte kasutada agente? Teades (leidnud) nende tavalist käitumist, saab määrata ümberringi toimuvaid muudatusi ja kuidas see mõjutab teenuste kvaliteeti. Ja samal ajal ei pea ise proove sisse seadma, need on juba paigaldanud Roskomnadzor.

Veel on üks teema, mida ma tahan käsitleda: iga tööriist võib olla relv. AS "Revisor" on suletud võrk, kuid Agendid annavad kõik üles, saates päringuid kõigile keelatud loendisse kuuluvatele ressurssidele. Sellise ressursi hankimine ei ole mingitpidi keeruline. Lõppkokkuvõttes räägivad pakkujad Agente kaudu, seda tahes või tahtmata, oma võrgust oluliselt rohkem, kui võib-olla peaks: DPI ja DNS tüübid, Agendi asukoht (keskpood ja teenindusvõrk?), viivituse ja kadude võrgu markerid — ja see on vaid kõige ilmselgem. Nii nagu keegi võib jälgida Agentide tegevusi oma ressursside kättesaadavuse parandamiseks, võib keegi seda teha ka muudel eesmärkidel ja sellele ei ole takistusi. Tulemus on kahe teraga ja väga mitmekesine tööriist, milles võib igaüks veenduda.

Allikas: habr.com