Saskaitīsim aģentus "Inspektors"

Nav noslēpums, ka aizliegtās informācijas sarakstā esoÅ”o bloÄ·Ä“Å”anas kontroli Krievijā uzrauga automatizētā sistēma ā€œInspektorsā€. Å eit ir labi uzrakstÄ«ts, kā tas darbojas raksts par Habr, bilde no tās paÅ”as vietas:

Saskaitīsim aģentus "Inspektors"

Instalēta tieÅ”i pie pakalpojumu sniedzēja modulis "AÄ£entu inspektors":

Modulis "AÄ£entu inspektors" ir automatizētās sistēmas "Inspektors" (AS "Inspektors") strukturāls elements. Å Ä« sistēma ir paredzēta, lai uzraudzÄ«tu telekomunikāciju operatoru atbilstÄ«bu piekļuves ierobežojumu prasÄ«bām saskaņā ar 15.1. gada 15.4. jÅ«lija federālā likuma Nr. 27-FZ ā€œPar informāciju, informācijas tehnoloÄ£ijām un informācijas aizsardzÄ«buā€ 2006.ā€“149. pantu. ā€

AS "Revizor" izveides galvenais mērÄ·is ir nodroÅ”ināt telekomunikāciju operatoru atbilstÄ«bu prasÄ«bām, kas noteiktas 15.1.gada 15.4.jÅ«lija Federālā likuma Nr.27-FZ "Par informāciju, informācijas tehnoloÄ£ijām un informācijas aizsardzÄ«bu" 2006.-149. " attiecÄ«bā uz faktu noskaidroÅ”anu par piekļuvi aizliegtai informācijai un par pamatojoÅ”o materiālu (datu) iegÅ«Å”anu par pārkāpumiem, lai ierobežotu piekļuvi aizliegtai informācijai.

Ņemot vērā to, ka, ja ne visi, tad daudzi pakalpojumu sniedzēji ir instalējuÅ”i Å”o ierÄ«ci, vajadzēja bÅ«t lielam bākas zondu tÄ«klam, piemēram, NOBRAUKUMS atlants un pat vairāk, bet ar slēgtu piekļuvi. Tomēr bāka ir bāka, lai raidÄ«tu signālus visos virzienos, bet kā bÅ«tu, ja mēs tos noÄ·ertu un redzētu, ko mēs noķērām un cik daudz?

Pirms skaitÄ«Å”anas redzēsim, kāpēc tas pat varētu bÅ«t iespējams.

Mazliet teorija

AÄ£enti pārbauda resursa pieejamÄ«bu, tostarp izmantojot HTTP(S) pieprasÄ«jumus, piemēram, Å”o:

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"

Papildus lietderÄ«gajai slodzei pieprasÄ«jums sastāv arÄ« no savienojuma izveides fāzes: apmaiņas SYN Šø SYN-ACK, un savienojuma pabeigÅ”anas fāzes: FIN-ACK.

Aizliegtās informācijas reÄ£istrā ir vairāki bloÄ·Ä“Å”anas veidi. AcÄ«mredzot, ja resurss ir bloķēts ar IP adresi vai domēna nosaukumu, mēs neredzēsim pieprasÄ«jumus. Å ie ir visdestruktÄ«vākie bloÄ·Ä“Å”anas veidi, kuru dēļ visi resursi vienā IP adresē vai visa informācija domēnā kļūst nepieejami. Ir arÄ« bloÄ·Ä“Å”anas veids ā€œpēc URLā€. Šādā gadÄ«jumā filtrÄ“Å”anas sistēmai ir jāparsē HTTP pieprasÄ«juma galvene, lai precÄ«zi noteiktu, ko bloķēt. Un pirms tā, kā redzams iepriekÅ”, vajadzētu bÅ«t savienojuma izveides fāzei, kuru varat mēģināt izsekot, jo, visticamāk, filtrs to palaidÄ«s garām.

Lai to izdarÄ«tu, jums ir jāizvēlas piemērots bezmaksas domēns ar ā€œURLā€ un HTTP bloÄ·Ä“Å”anas veidu, lai atvieglotu filtrÄ“Å”anas sistēmas darbu, vēlams, jau sen pamestu, lai samazinātu sveÅ”as trafika iekļūŔanu, izņemot no aÄ£entiem. Å is uzdevums izrādÄ«jās nepavisam grÅ«ts, aizliegtās informācijas reÄ£istrā ir diezgan daudz bezmaksas domēnu un katrai gaumei. Tāpēc domēns tika iegādāts un saistÄ«ts ar IP adresēm VPS, kas darbojas tcpdump un sākās skaitÄ«Å”ana.

"Revidentu" audits

Es gaidīju periodiskus pieprasījumu uzliesmojumus, kas, manuprāt, liecinātu par kontrolētu rīcību. Nevar teikt, ka es to nemaz neredzēju, bet skaidra attēla noteikti nebija:

Saskaitīsim aģentus "Inspektors"

Kas nav pārsteidzoÅ”i, pat domēnā, kas nevienam nav vajadzÄ«gs un nekad neizmantotā IP, vienkārÅ”i bÅ«s daudz nevēlamas informācijas, tāds ir mÅ«sdienu internets. Bet par laimi man vajadzēja tikai konkrēta URL pieprasÄ«jumus, tāpēc visi skeneri un paroļu uzlauzēji tika ātri atrasti. Tāpat, pamatojoties uz lÄ«dzÄ«gu pieprasÄ«jumu masu, bija diezgan viegli saprast, kur plÅ«di. Tālāk es apkopoju IP adreÅ”u raÅ”anās biežumu un manuāli izgāju cauri visam topam, atdalot tos, kuri to palaida garām iepriekŔējos posmos. Turklāt es izgriezu visus avotus, kas tika nosÅ«tÄ«ti vienā iepakojumā, to vairs nebija daudz. Un notika Ŕādi:

Saskaitīsim aģentus "Inspektors"

Neliela liriska atkāpe. Nedaudz vairāk kā dienu vēlāk mans hostinga pakalpojumu sniedzējs nosÅ«tÄ«ja vēstuli ar diezgan vienkārÅ”otu saturu, sakot, ka jÅ«su telpās ir resurss no RKN aizliegtā saraksta, tāpēc tas ir bloķēts. Sākumā domāju, ka mans konts ir bloķēts, tas tā nebija. Tad es domāju, ka viņi mani vienkārÅ”i brÄ«dina par kaut ko, par ko es jau zināju. Bet izrādÄ«jās, ka mitinātājs ieslēdza savu filtru mana domēna priekŔā, un rezultātā es nokļuvu dubultā filtrācijā: no pakalpojumu sniedzējiem un no mitinātāja. Filtrs izturēja tikai pieprasÄ«jumu beigas: FIN-ACK Šø RST nogriežot visu HTTP pie aizliegta URL. Kā redzat no iepriekÅ” redzamā grafika, pēc pirmās dienas es sāku saņemt mazāk datu, taču es joprojām tos saņēmu, kas bija pilnÄ«gi pietiekami, lai veiktu pieprasÄ«jumu avotu skaitÄ«Å”anu.

Nonāc pie lietas. Manuprāt, katru dienu ir skaidri redzami divi uzliesmojumi, pirmais mazāks, pēc pusnakts pēc Maskavas laika, otrs tuvāk 6 no rÄ«ta ar asti lÄ«dz plkst.12. Maksimums nenotiek tieÅ”i tajā paŔā laikā. Sākumā vēlējos atlasÄ«t IP adreses, kas izkrita tikai Å”ajos periodos un katru visos periodos, pamatojoties uz pieņēmumu, ka aÄ£entu pārbaudes tiek veiktas periodiski. Taču, rÅ«pÄ«gi pārskatot, es ātri atklāju periodus, kas ietilpst citos intervālos, ar citām frekvencēm, lÄ«dz vienam pieprasÄ«jumam katru stundu. Tad es domāju par laika joslām un to, ka varbÅ«t tam ir kāds sakars ar tām, tad domāju, ka kopumā sistēma varētu nebÅ«t globāli sinhronizēta. Turklāt NAT, iespējams, spēlēs savu lomu, un tas pats aÄ£ents var veikt pieprasÄ«jumus no dažādiem publiskajiem IP.

Tā kā mans sākotnējais mērÄ·is nebija precÄ«zi, es saskaitÄ«ju visas adreses, kuras es sastapu nedēļas laikā, un saņēmu - 2791. No vienas adreses izveidoto TCP sesiju skaits vidēji ir 4, ar vidējo 2. Populārākās sesijas vienā adresē: 464, 231, 149, 83, 77. Maksimums no 95% izlases ir 8 sesijas uz vienu adresi. Mediāna nav Ä«paÅ”i augsta, atgādināŔu, ka grafikā redzama skaidra dienas periodiskums, tātad 4 dienās varētu gaidÄ«t kaut ko ap 8 lÄ«dz 7. Ja mēs izmetÄ«sim visas sesijas, kas notiek vienu reizi, mēs iegÅ«sim mediānu, kas vienāda ar 5. Bet es nevarēju tās izslēgt, pamatojoties uz skaidru kritēriju. Gluži pretēji, izlases veida pārbaude parādÄ«ja, ka tie ir saistÄ«ti ar aizliegta resursa pieprasÄ«jumiem.

Adreses ir adreses, bet internetā autonomās sistēmas - AS, kas izrādÄ«jās svarÄ«gākas 1510, vidēji 2 adreses katrai AS ar vidējo 1. Galvenās adreses katrā AS: 288, 77, 66, 39, 27. Maksimālais 95% no izlases ir 4 adreses vienai AS. Å eit ir sagaidāma mediāna - viens aÄ£ents katram pakalpojumu sniedzējam. Sagaidām arÄ« topu ā€“ tajā ir lieli spēlētāji. Lielā tÄ«klā aÄ£entiem, iespējams, jāatrodas katrā operatora klātbÅ«tnes reÄ£ionā, un neaizmirstiet par NAT. Ja ņemam pa valstÄ«m, tad maksimumi bÅ«s: 1409 - RU, 42 - UA, 23 - CZ, 36 no citiem reÄ£ioniem, nevis RIPE NCC. UzmanÄ«bu piesaista pieprasÄ«jumi no ārpus Krievijas. Iespējams, to var izskaidrot ar Ä£eolokācijas kļūdām vai reÄ£istratora kļūdām, aizpildot datus. Vai arÄ« tas, ka Krievijas uzņēmumam var nebÅ«t krievu saknes, vai ir ārzemju pārstāvniecÄ«ba, jo tā ir vieglāk, kas ir dabiski, ja ir darÄ«Å”ana ar ārzemju organizāciju RIPE NCC. Kāda daļa neapÅ”aubāmi ir lieka, taču to ir grÅ«ti atdalÄ«t, jo resurss tiek bloķēts, bet no otrās dienas - dubultā, un lielākā daļa sesiju ir tikai vairāku pakalpojumu pakeÅ”u apmaiņa. Vienosimies, ka tā ir maza daļa.

Å os skaitļus jau var salÄ«dzināt ar pakalpojumu sniedzēju skaitu Krievijā. Saskaņā ar RKN licences ā€œSakaru pakalpojumi datu pārraidei, izņemot balsiā€ - 6387, taču tas ir ļoti augsts novērtējums no augÅ”as, ne visas Ŕīs licences attiecas tieÅ”i uz interneta pakalpojumu sniedzējiem, kuriem jāinstalē aÄ£ents. RIPE NCC zonā Krievijā reÄ£istrēts lÄ«dzÄ«gs AS skaits - 6230, no kuriem ne visas ir pakalpojumu sniedzēji. UserSide veica stingrāku aprēķinu un 3940. gadā saņēma 2017 uzņēmumus, un tas drÄ«zāk ir aprēķins no augÅ”as. Jebkurā gadÄ«jumā mums ir divarpus reizes mazāks apgaismoto AS skaits. Bet Å”eit ir vērts saprast, ka AS nav stingri vienāds ar pakalpojumu sniedzēju. Dažiem pakalpojumu sniedzējiem nav sava AS, dažiem ir vairāk nekā viens. Ja pieņemam, ka visiem joprojām ir AÄ£enti, tad kāds filtrē spēcÄ«gāk par citiem, lai viņu pieprasÄ«jumi neatŔķirtos no atkritumiem, ja tie vispār sasniedz. Bet aptuvenam vērtējumam tas ir diezgan pieļaujami, pat ja kaut kas tika zaudēts manas neuzmanÄ«bas dēļ.

Par DPI

Neskatoties uz to, ka mans hostinga pakalpojumu sniedzējs ieslēdza savu filtru, sākot ar otro dienu, pēc pirmās dienas informācijas varam secināt, ka bloÄ·Ä“Å”ana darbojas veiksmÄ«gi. Tikai 4 avoti varēja tikt cauri un ir pilnÄ«bā pabeiguÅ”i HTTP un TCP sesijas (kā iepriekÅ” minētajā piemērā). Vēl 460 var nosÅ«tÄ«t GET, bet sesija nekavējoties tiek pārtraukta lÄ«dz RST. pievērs uzmanÄ«bu 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"

Variācijas var bÅ«t dažādas: mazāk RST vai vairāk retranslāciju ā€” arÄ« atkarÄ«gs no tā, ko filtrs nosÅ«ta uz avota mezglu. Jebkurā gadÄ«jumā Ŕī ir visuzticamākā veidne, no kuras ir skaidrs, ka tas bija aizliegts resurss, kas tika pieprasÄ«ts. Turklāt vienmēr ir atbilde, kas parādās sesijā ar TTL lielāks nekā iepriekŔējās un turpmākajās paketēs.

To pat nevar redzēt no pārējiem 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"

Vai arī:

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

AtŔķirība noteikti ir redzama TTL ja kaut kas nāk no filtra. Bet bieži vien nekas var nesanākt:

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

Vai arī:

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

Un tas viss atkārtojas un atkārtojas un atkārtojas, kā redzams grafikā, ne reizi vien, katru dienu.

Par IPv6

Labā ziņa ir tā, ka tā pastāv. Varu droÅ”i teikt, ka periodiski pieprasÄ«jumi aizliegtam resursam tiek saņemti no 5 dažādām IPv6 adresēm, kas ir tieÅ”i tāda AÄ£entu uzvedÄ«ba, kādu es gaidÄ«ju. Turklāt viena no IPv6 adresēm neietilpst filtrÄ“Å”anā, un es redzu pilnu sesiju. No vēl divām es redzēju tikai vienu nepabeigtu sesiju, no kurām vienu pārtrauca RST no filtra, otrais pēc laika. Kopējā summa 7.

Tā kā adreÅ”u ir maz, tad izpētÄ«ju visas sÄ«ki un izrādÄ«jās, ka tur ir tikai 3 provaideri, viņiem var dot ovācijas! Cita adrese ir mākoņa hostings Krievijā (nefiltrē), cita ir pētniecÄ«bas centrs Vācijā (ir filtrs, kur?). Bet kāpēc viņi pēc grafika pārbauda aizliegto resursu pieejamÄ«bu, ir labs jautājums. Pārējie divi iesniedza vienu pieprasÄ«jumu un atrodas ārpus Krievijas, un viens no tiem ir filtrēts (galu galā?).

BloÄ·Ä“Å”ana un aÄ£enti ir liels Ŕķērslis IPv6, kura ievieÅ”ana nevirzās ļoti ātri. Tas ir skumji. Tie, kas atrisināja Å”o problēmu, var pilnÄ«bā lepoties ar sevi.

Noslēgumā

Es netiecos uz 100% precizitāti, lÅ«dzu, piedodiet man par to, ceru, ka kāds vēlas atkārtot Å”o darbu ar lielāku precizitāti. Man bija svarÄ«gi saprast, vai Ŕī pieeja principā darbosies. Atbilde ir jā. IegÅ«tie skaitļi, kā pirmais tuvinājums, manuprāt, ir diezgan ticami.

Ko vēl varēja darÄ«t un ko man bija par slinku darÄ«t, bija DNS pieprasÄ«jumu saskaitÄ«Å”ana. Tie netiek filtrēti, taču tie arÄ« nenodroÅ”ina lielu precizitāti, jo tie darbojas tikai domēnam, nevis visam URL. Biežumam jābÅ«t redzamam. Ja to apvienojat ar to, kas ir tieÅ”i redzams vaicājumos, tas ļaus jums atdalÄ«t nevajadzÄ«go un iegÅ«t vairāk informācijas. Ir pat iespējams noteikt pakalpojumu sniedzēju izmantotā DNS izstrādātājus un daudz ko citu.

Es absolÅ«ti negaidÄ«ju, ka hoster manam VPS iekļaus arÄ« savu filtru. VarbÅ«t tā ir ierasta prakse. Galu galā RKN nosÅ«ta resursdatoram pieprasÄ«jumu dzēst resursu. Bet tas mani nepārsteidza un savā ziņā pat darbojās man par labu. Filtrs darbojās ļoti efektÄ«vi, nogriežot visus pareizos HTTP pieprasÄ«jumus uz aizliegtu URL, bet ne pareizie, kas iepriekÅ” bija izgājuÅ”i caur pakalpojumu sniedzēju filtru, tos sasniedza, kaut arÄ« tikai galotņu veidā: FIN-ACK Šø RST - mÄ«nuss mÄ«nusam un gandrÄ«z izrādÄ«jās pluss. Starp citu, resursdators nefiltrēja IPv6. Protams, tas ietekmēja savāktā materiāla kvalitāti, taču tas tomēr ļāva redzēt biežumu. IzrādÄ«jās, ka tas ir svarÄ«gs punkts, izvēloties vietu resursu izvietoÅ”anai; neaizmirstiet painteresēties par jautājumu par darba organizÄ“Å”anu ar aizliegto vietņu sarakstu un RKN pieprasÄ«jumiem.

Sākumā salÄ«dzināju AS "Inspektors" ar NOBRAUKUMS atlants. Å is salÄ«dzinājums ir diezgan pamatots, un liels aÄ£entu tÄ«kls var bÅ«t izdevÄ«gs. Piemēram, dažādu pakalpojumu sniedzēju resursu pieejamÄ«bas kvalitātes noteikÅ”ana dažādās valsts daļās. JÅ«s varat aprēķināt aizkaves, jÅ«s varat izveidot grafikus, varat to visu analizēt un redzēt izmaiņas, kas notiek gan lokāli, gan globāli. Tas nav tieŔākais veids, bet astronomi izmanto ā€œstandarta svecesā€, kāpēc gan neizmantot aÄ£entus? Zinot (atrodot) viņu standarta uzvedÄ«bu, varat noteikt, kādas izmaiņas notiek ap tiem un kā tas ietekmē sniegto pakalpojumu kvalitāti. Un tajā paŔā laikā jums nav nepiecieÅ”ams neatkarÄ«gi ievietot zondes tÄ«klā; Roskomnadzor tās jau ir instalējis.

Vēl viens punkts, kam vēlos pieskarties, ir tas, ka katrs instruments var bÅ«t ierocis. AS "Inspektors" ir slēgts tÄ«kls, bet AÄ£enti nodod visus, sÅ«tot pieprasÄ«jumus par visiem resursiem no aizliegtā saraksta. Šāda resursa izmantoÅ”ana nerada nekādas problēmas. Kopumā pakalpojumu sniedzēji ar aÄ£entu starpniecÄ«bu neapzināti pastāsta par savu tÄ«klu daudz vairāk, nekā, iespējams, ir tā vērts: DPI un DNS veidi, aÄ£enta atraÅ”anās vieta (centrālais mezgls un pakalpojumu tÄ«kls?), kavējumu un zudumu tÄ«kla marÄ·ieri - un tas ir tikai pats acÄ«mredzamākais. Tāpat kā kāds var pārraudzÄ«t AÄ£entu darbÄ«bas, lai uzlabotu savu resursu pieejamÄ«bu, kāds to var darÄ«t citiem mērÄ·iem, un tam nav ŔķērŔļu. Rezultāts ir divpusÄ«gs un ļoti daudzpusÄ«gs instruments, to var redzēt ikviens.

Avots: www.habr.com

Pievieno komentāru