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 uz AS ar mediānu 1. Galvenās adreses uz AS: 288, 77, 66, 39, 27. Maksimums 95% izlasē ir 4 adreses uz AS. Å eit tiek sagaidÄ«ta mediāna – viens aÄ£ents uz katru pakalpojumu sniedzēju. Tiek sagaidÄ«ts arÄ« augstākais – tas ietver galvenos dalÄ«bniekus. Lielā tÄ«klā aÄ£entiem, iespējams, vajadzētu atrasties katrā reÄ£ionā, kurā atrodas operators, un nevajadzētu aizmirst par NAT. Ja aplÅ«kojam valstis, maksimumi ir: 1409 – RU, 42 – UA, 23 – CZ, 36 no citiem reÄ£ioniem, nevis RIPE NCCPieprasÄ«jumi no ārpus Krievijas piesaista uzmanÄ«bu. To, visticamāk, var izskaidrot ar Ä£eolokācijas kļūdām vai reÄ£istratÅ«ru datu ievades kļūdām. AlternatÄ«vi, Krievijas uzņēmumam var nebÅ«t krievu sakņu vai tam var bÅ«t ārvalstu pārstāvniecÄ«ba, jo tā ir vienkārŔāk, kas ir dabiski, sadarbojoties ar ārvalstu organizāciju. RIPE NCCDaļa neapÅ”aubāmi ir lieka, taču to ir grÅ«ti droÅ”i izolēt, jo resurss ir slēgts un, sākot ar otro dienu, dubultslēgtā stāvoklÄ«, un lielākā daļa sesiju sastāv tikai no dažu pakalpojumu pakeÅ”u apmaiņas. Pieņemsim, ka Ŕī ir neliela daļa.

Å os skaitļus jau var salÄ«dzināt ar pakalpojumu sniedzēju skaitu Krievijā. Saskaņā ar RKN Ir 6387 licences "Datu sakaru pakalpojumiem, izņemot balss sakarus", taču Å”is ir ievērojami pārspÄ«lēts aprēķins; ne visas Ŕīs licences attiecas tieÅ”i uz interneta pakalpojumu sniedzējiem, kuriem nepiecieÅ”ama aÄ£enta instalēŔana. Å ajā zonā RIPE NCC LÄ«dzÄ«gs Krievijā reÄ£istrēto AS skaits ir 6230, un ne visi no tiem 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

Iegādājieties uzticamu mitināŔanu vietnēm ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa vietņu mitināŔanu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster