Pole saladus, et Venemaal keelatud teabe nimekirjas oleva blokeerimise kontrollimist jälgib automatiseeritud süsteem “Inspektor”. Kuidas see töötab, on siin hästi kirjutatud , pilt samast kohast:
Installitud otse teenusepakkuja juures :
Moodul "Agent Inspector" on automatiseeritud süsteemi "Inspektor" (AS "Inspektor") struktuurielement. See süsteem on loodud selleks, et jälgida, kas telekommunikatsioonioperaatorid järgivad juurdepääsupiirangu nõudeid 15.1. juuli 15.4. aasta föderaalseaduse nr 27-FZ “Teabe, infotehnoloogia ja teabekaitse” artiklites 2006–149 kehtestatud sätete raames. ”
AS "Revizor" loomise põhieesmärk on tagada telekommunikatsioonioperaatorite 15.1. juuli 15.4. aasta föderaalseaduse nr 27-FZ "Info, infotehnoloogia ja teabekaitse" artiklitega 2006-149 kehtestatud nõuete järgimise jälgimine. " keelatud teabele juurdepääsu faktide tuvastamise ja rikkumiste kohta tõendavate materjalide (andmete) hankimise osas, et piirata juurdepääsu keelatud teabele.
Võttes arvesse asjaolu, et kui mitte kõik, siis paljud pakkujad on selle seadme installinud, oleks pidanud olema suur majakassondide võrk, nagu ja isegi rohkem, kuid suletud juurdepääsuga. Majakas on siiski majakas, et saata signaale igas suunas, aga mis siis, kui me need kinni püüame ja vaatame, mida ja kui palju?
Enne loendamist vaatame, miks see võib isegi võimalik olla.
Natuke teooriat
Agendid kontrollivad ressursi saadavust, sealhulgas HTTP(S) päringute kaudu, nagu 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"
Lisaks kasulikule koormusele koosneb päring ka ühenduse loomise etapist: vahetus SYN и SYN-ACKja ühenduse valmimise etapid: FIN-ACK.
Keelatud teabe register sisaldab mitut tüüpi blokeerimist. Ilmselgelt ei näe me taotlusi, kui ressurss on IP-aadressi või domeeninime tõttu blokeeritud. Need on kõige hävitavamad blokeerimise tüübid, mis põhjustavad ligipääsmatust kõigile ühe IP-aadressi ressurssidele või kogu domeeni teabele. Samuti on olemas URL-i järgi blokeerimine. Sel juhul peab filtreerimissüsteem analüüsima HTTP päringu päist, et täpselt määrata, mida blokeerida. Ja enne seda, nagu ülalt näha, peaks olema ühenduse loomise faas, mida saate proovida jälgida, kuna tõenäoliselt jätab filter sellest ilma.
Selleks tuleb filtreerimissüsteemi töö hõlbustamiseks valida sobiv vaba domeen URL-i ja HTTP blokeerimistüübiga, soovitavalt ammu maha jäetud, et minimeerida kõrvaliste liikluste sisenemist v.a agentide poolt. See ülesanne ei osutunud sugugi keeruliseks, tasuta domeene on keelatud teabe registris päris palju ja igale maitsele. Seetõttu osteti domeen ja lingiti töötava VPS-i IP-aadressidega tcpdump ja lugemine algas.
Audiitorite audit
Ootasin näha perioodilisi taotluste puhanguid, mis minu arvates viitavad kontrollitud tegevusele. Ei saa öelda, et ma seda üldse ei näinud, aga selget pilti kindlasti polnud:
Mis pole üllatav, isegi domeenil, mida keegi ei vaja, ja kunagi kasutamata IP-l on lihtsalt palju soovimatut teavet, selline on kaasaegne Internet. Aga õnneks oli mul vaja ainult konkreetse URL-i päringuid, nii et kõik skannerid ja paroolimurdjad leiti kiiresti üles. Samuti oli sarnaste taotluste hulga põhjal üsna lihtne aru saada, kus üleujutus oli. Järgmisena koostasin IP-aadresside esinemissageduse ja läbisin kogu ülaosa käsitsi, eraldades need, kes eelmistes etappides sellest ilma jäid. Lisaks lõikasin välja kõik ühes pakis saadetud allikad, neid polnud enam palju. Ja see juhtus:
Väike lüüriline kõrvalepõige. Veidi rohkem kui päev hiljem saatis minu hostiteenuse pakkuja üsna sujuva sisuga kirja, milles ütles, et teie rajatised sisaldavad RKN-i keelatud nimekirja ressurssi, seega on see blokeeritud. Alguses arvasin, et mu konto on blokeeritud, see polnud nii. Siis mõtlesin, et nad lihtsalt hoiatasid mind millegi eest, millest ma juba teadsin. Kuid selgus, et hoster lülitas minu domeeni ees oma filtri sisse ja selle tulemusena sattusin topeltfiltreerimise alla: pakkujate ja hosti poolt. Filter läbis ainult päringute lõpud: FIN-ACK и RST katkestades kogu HTTP keelatud URL-il. Nagu ülaltoodud graafikult näete, hakkasin pärast esimest päeva saama vähem andmeid, kuid sain need siiski kätte, mis oli päringuallikate loendamiseks täiesti piisav.
Tulge asja juurde. Minu meelest on iga päev selgelt näha kaks purset, esimene väiksem, pärast keskööd Moskva aja järgi, teine lähemal kella 6-le hommikul koos sabaga kuni kella 12ni. Tipp ei toimu täpselt samal ajal. Alguses tahtsin valida IP-aadressid, mis langesid ainult nendel perioodidel ja kõik kõikidel perioodidel, lähtudes eeldusest, et agentide poolt kontrollitakse perioodiliselt. Kuid hoolikal ülevaatamisel avastasin kiiresti perioodid, mis langevad teistesse intervallidesse, teiste sagedustega, kuni üks taotlus igas tunnis. Siis mõtlesin ajavöönditele ja sellele, et äkki on see nendega seotud, siis mõtlesin, et üldiselt ei pruugi süsteem globaalselt sünkroniseerida. Lisaks mängib tõenäoliselt rolli ka NAT ja sama agent saab teha päringuid erinevatelt avalikelt IP-delt.
Kuna mu esialgne eesmärk ei olnud täpselt, lugesin nädala jooksul kõik aadressid kokku ja sain - 2791. Ühelt aadressilt loodud TCP-seansside arv on keskmiselt 4, mediaaniga 2. Populaarseimad seansid aadressi kohta: 464, 231, 149, 83, 77. Maksimaalne alates 95% valimist on 8 seanssi aadressi kohta. Mediaan ei ole väga kõrge, tuletan meelde, et graafik näitab selget päevaperioodi, nii et 4 päeva jooksul võiks oodata midagi 8–7. Kui kõik seansid, mis kord esinevad, välja visata, saame mediaani, mis on võrdne 5-ga. Aga ma ei saanud neid selge kriteeriumi alusel välistada. Vastupidi, pisteline kontroll näitas, et need olid seotud keelatud ressursi taotlustega.
Aadressid on aadressid, kuid Internetis autonoomsed süsteemid - AS, mis osutus olulisemaks 1510, keskmiselt 2 aadressi AS-i kohta mediaaniga 1. Kõige populaarsemad aadressid AS-i kohta: 288, 77, 66, 39, 27. Maksimaalselt 95% valimist on 4 aadressi AS-i kohta. Siin on oodata mediaani – üks agent pakkuja kohta. Ootame ka tippu – selles on suured tegijad. Suures võrgus peaksid agendid tõenäoliselt asuma igas operaatori kohaloleku piirkonnas ja ärge unustage NAT-i. Kui võtame selle riigiti, on maksimumid: 1409 - RU, 42 - UA, 23 - CZ, 36 teistest piirkondadest, mitte RIPE NCC. Taotlused väljastpoolt Venemaad äratavad tähelepanu. Tõenäoliselt on see seletatav geograafilise asukoha või registripidaja vigadega andmete täitmisel. Või see, et Vene ettevõttel ei pruugi olla vene juured või on välisesindus, sest nii on lihtsam, mis on loomulik, kui tegemist on välismaise organisatsiooniga RIPE NCC. Mõni osa on kahtlemata üleliigne, kuid seda on usaldusväärselt raske eraldada, kuna ressurss on blokeeritud ja alates teisest päevast topeltblokeeringu all ning enamik seansse on vaid mitme teenusepaketi vahetus. Lepime kokku, et see on väike osa.
Neid numbreid saab juba võrrelda Venemaa pakkujate arvuga. litsentsid "Andmeedastuse sideteenused, välja arvatud kõne" - 6387, kuid see on ülaltpoolt väga kõrge hinnang, mitte kõik need litsentsid ei kehti spetsiaalselt Interneti-teenuse pakkujatele, kes peavad installima agendi. RIPE NCC tsoonis on Venemaal registreeritud sarnane arv AS-e - 6230, millest kõik ei ole pakkujad. ja sai 3940. aastal 2017 ettevõtet ja see on pigem ülaltpoolt lähtuv hinnang. Igal juhul on meil valgustatud AS-e kaks ja pool korda vähem. Kuid siin tasub mõista, et AS ei ole pakkujaga rangelt võrdne. Mõnel pakkujal pole oma AS-i, mõnel on rohkem kui üks. Kui eeldada, et kõigil on endiselt Agendid, siis keegi filtreerib teistest tugevamini, nii et tema taotlused ei eristata prügist, kui need üldse nendeni jõuavad. Aga umbkaudsel hinnangul on see täiesti talutav, isegi kui minu möödalaskmise tõttu midagi kaduma läks.
DPI kohta
Vaatamata sellele, et minu hostiteenuse pakkuja lülitas oma filtri sisse alates teisest päevast, võime esimese päeva info põhjal järeldada, et blokeerimine toimib edukalt. Ainult 4 allikat suutsid HTTP- ja TCP-seansid läbida ja on täielikult lõpetanud (nagu ülaltoodud näites). Veel 460 saab saata GET, kuid seansi lõpetab kohe RST. pööra tähelepanu 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"
Selle variatsioonid võivad olla erinevad: vähem RST või rohkem kordusedastusi – oleneb ka sellest, mida filter lähtesõlme saadab. Igal juhul on see kõige usaldusväärsem mall, millest on selge, et see oli keelatud ressurss, mida taotleti. Lisaks on alati vastus, mis kuvatakse seansil koos TTL suurem kui eelmistes ja järgnevates pakettides.
Ülejäänutest pole seda isegi näha 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"
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"
#Вот это прислал фильтр
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"
...
Erinevus on kindlasti nähtav TTL kui filtrist midagi tuleb. Kuid sageli ei pruugi midagi jõuda:
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"
#Прошло несколько секунд без трафика
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Ja seda kõike korratakse ja korratakse ja korratakse, nagu graafikult näha, rohkem kui üks kord iga päev.
IPv6 kohta
Hea uudis on see, et see on olemas. Võin kindlalt väita, et perioodilised päringud keelatud ressursile tulevad 5 erinevalt IPv6-aadressilt, mis on täpselt selline käitumine agentidelt, mida ma ootasin. Pealegi ei kuulu üks IPv6-aadressidest filtreerimise alla ja ma näen täielikku seanssi. Veel kahest nägin ainult ühte lõpetamata seanssi, millest üks katkestas RST filtrist, ajaliselt teine. Kogu summa 7.
Kuna aadresse on vähe, siis uurisin neid kõiki põhjalikult ja selgus, et seal on ainult 3 pakkujat, neile võib lausa aplausi teha! Teine aadress on pilvemajutus Venemaal (ei filtreeri), teine on uurimiskeskus Saksamaal (filter on olemas, kus?). Aga miks nad kontrollivad graafiku alusel keelatud ressursside saadavust, on hea küsimus. Ülejäänud kaks esitasid ühe päringu ja asuvad väljaspool Venemaad ning üks neist on filtreeritud (läbi transiidis?).
Blokeerimine ja agendid on IPv6-le suureks takistuseks, mille juurutamine ei liigu eriti kiiresti. See on kurb. Need, kes selle probleemi lahendasid, võivad enda üle täiesti uhked olla.
Kokkuvõttes
Ma ei püüdnud 100% täpsuse poole, palun andke mulle see andeks, ma loodan, et keegi soovib seda tööd suurema täpsusega korrata. Minu jaoks oli oluline mõista, kas see lähenemine põhimõtteliselt toimib. Vastus on jah. Saadud arvud on esimese ligikaudsusena minu arvates üsna usaldusväärsed.
Mida muud oleks saanud teha ja milleks ma olin liiga laisk, oli DNS-i päringute loendamine. Neid ei filtreerita, kuid need ei anna ka suurt täpsust, kuna need töötavad ainult domeeni, mitte kogu URL-i jaoks. Sagedus peaks olema nähtav. Kui kombineerite selle päringutes otse nähtavaga, saate ebavajaliku eraldada ja saada rohkem teavet. Võimalik on isegi määrata pakkujate kasutatava DNS-i arendajad ja palju muud.
Ma ei oodanud absoluutselt, et hoster lisab minu VPS-i jaoks ka oma filtri. Võib-olla on see tavaline praktika. Lõpuks saadab RKN hostile ressursi kustutamise taotluse. Kuid see ei üllatanud mind ja töötas mõnes mõttes isegi minu kasuks. Filter töötas väga tõhusalt, katkestades kõik õiged HTTP-päringud keelatud URL-idele, kuid õiged, mis olid varem pakkujate filtrist läbinud, ei jõudnud nendeni, ehkki ainult lõppude kujul: FIN-ACK и RST - miinus miinus ja see osutus peaaegu plussiks. Muide, hoster ei filtreerinud IPv6. See muidugi mõjutas kogutava materjali kvaliteeti, kuid võimaldas siiski näha sagedust. Selgus, et see on ressursside paigutamise saidi valimisel oluline punkt; ärge unustage huvi tundma õppida keelatud saitide loendi ja RKN-i taotlustega töö korraldamise küsimuses.
Alguses võrdlesin AS "Inspektor" omaga . See võrdlus on üsna õigustatud ja suur agentide võrgustik võib olla kasulik. Näiteks erinevate pakkujate ressursside kättesaadavuse kvaliteedi määramine riigi eri piirkondades. Saate arvutada viivitusi, koostada graafikuid, saate seda kõike analüüsida ja näha nii lokaalselt kui globaalselt toimuvaid muutusi. See pole kõige otsesem viis, kuid astronoomid kasutavad "standardküünlaid", miks mitte kasutada agente? Teades (olles leidnud) nende tavakäitumist, saate kindlaks teha nende ümber toimuvad muutused ja kuidas see mõjutab pakutavate teenuste kvaliteeti. Ja samal ajal ei pea te sonde iseseisvalt võrku paigutama, Roskomnadzor on need juba installinud.
Veel üks punkt, mida tahan puudutada, on see, et iga tööriist võib olla relv. AS "Inspektor" on suletud võrgustik, kuid Agendid annavad kõik üle, saates päringud kõigi keelatud nimekirja ressursside kohta. Sellise ressursi omamine ei tekita probleeme. Kokku räägivad pakkujad agentide kaudu tahtmatult oma võrgust palju rohkem, kui see ilmselt seda väärt on: DPI ja DNS tüübid, agendi asukoht (kesksõlm ja teenindusvõrk?), viivituste ja kadude võrgumarkerid – ja see on ainult kõige ilmsemad. Nii nagu keegi saab jälgida agentide tegevust oma ressursside kättesaadavuse parandamiseks, saab keegi seda teha ka muudel eesmärkidel ja selleks pole takistusi. Tulemuseks on kahe teraga ja väga mitmetahuline instrument, seda näeb igaüks.
Allikas: www.habr.com