Saskaitīsim aģentus "Revizors"

Nav nedrÄ«kst aizmirst, ka automatizētā sistēma ā€žRevizorsā€ uzrauga bloķēŔanas izpildi, pamatojoties uz sarakstu ar aizliegto informāciju Krievijā. Par to, kā tas darbojas, labi rakstÄ«ts Å”ajā rakstā Habr, attēls no turienes:

Saskaitīsim aģentus "Revizors"

TieÅ”i pie pakalpojumu sniedzēja tiek uzstādÄ«ts modulis ā€žRevizorsā€:

Modulis ā€žRevizorsā€ ir automatizētās sistēmas ā€žRevizorsā€ (AS ā€žRevizorsā€) strukturāls elements. Å Ä« sistēma ir paredzēta, lai uzraudzÄ«tu sakaru operatoru izpildi attiecÄ«bā uz piekļuves ierobežoÅ”anas prasÄ«bu izpildi atbilstoÅ”i 2006. gada 27. jÅ«lija Federālā likuma Nr. 149-FZ ā€žPar informāciju, informācijas tehnoloÄ£ijām un informācijas aizsardzÄ«buā€ 15.1-15.4 panta noteikumiem.

Galvenais mērÄ·is, kāpēc izveidota AS ā€žRevizorsā€, ir nodroÅ”ināt uzraudzÄ«bu par to, vai sakaru operatori ievēro 2006. gada 27. jÅ«lija Federālā likuma Nr. 149-FZ ā€žPar informāciju, informācijas tehnoloÄ£ijām un informācijas aizsardzÄ«buā€ 15.1-15.4 pantā noteiktās prasÄ«bas, kas saistÄ«tas ar aizliegtās informācijas piekļuves konstatēŔanu un pierādÄ«jumu (datņu) iegūŔanu par pārkāpumiem piekļuves ierobežoÅ”anai saistÄ«bā ar aizliegto informāciju.

Ņemot vērā to, ka, ja ne visi, tad daudzi pakalpojumu sniedzēji ir uzstādÄ«juÅ”i Å”o ierÄ«ci pie sevis, tam bÅ«tu jāveido liela tÄ«kla jaudas mērÄ«tāju sistēma lÄ«dzÄ«gā veidā RIPE Atlas un pat vairāk, bet ar slēgtu piekļuvi. Tomēr, jo ā€žmākslÄ«gais cietinātājsā€ ir mākslÄ«gais cietinātājs, kas var sÅ«tÄ«t signālus visās pusēs, ko darÄ«t, ja tos noÄ·ert un noskaidrot, ko mēs noķērām un cik daudz?

Pirms saskaitīt, aplūkosim, kāpēc tas vispār var būt iespējams.

Nedaudz teorijas

Aģenti pārbauda resursa pieejamību, tostarp, izmantojot HTTP(S) pieprasījumus, piemēram:

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

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"

PieprasÄ«jums, papildus lietderÄ«gai slodzei, sastāv arÄ« no savienojuma izveides fāzes: apmaiņa SYN un SYN-ACK, un savienojuma pabeigÅ”anas fāzes: FIN-ACK.

Aizliegto informāciju reÄ£istrs satur vairākus bloķēŔanas veidus. AcÄ«mredzami, ja resurss tiek bloķēts pēc IP adreses vai domēna vārda, tad nekādas pieprasÄ«jumu mēs neredzēsim. Tie ir visiznÄ«cinoŔākie bloķēŔanas veidi, kas nov leads uz visu resursu nepieejamÄ«bu vienā IP adresē vai visai informācijai domēnā. Pastāv arÄ« bloķēŔanas veids "pēc URL". Å ajā gadÄ«jumā filtrēŔanas sistēmai ir jāizskata HTTP pieprasÄ«juma galvene, lai precÄ«zi noteiktu, ko bloķēt. Pirms tam, kā redzams iepriekÅ”, ir jānotiek savienojuma izveidoÅ”anas fāzei, ko var mēģināt izsekot, jo, visticamāk, filtrs to izlaidÄ«s.

Lai to izdarÄ«tu, ir jāizvēlas piemērots brÄ«vs domēns ar bloķēŔanas veidu "pēc URL" un HTTP, lai atvieglotu filtrēŔanas sistēmas darbu, vēlams, sen pamests, lai samazinātu nevajadzÄ«gā satiksmes daudzumu, kas nāk no aÄ£entiem. Å is uzdevums izrādÄ«jās pavisam vienkārÅ”s, brÄ«vo domēnu reÄ£istrā aizliegtajā informācijā ir diezgan daudz un katram gaumei. Tāpēc domēns tika iegādāts, piesaistÄ«ts IP adresēm VPS, kurā darbojas tcpdump un sākās skaitīŔana.

Revīzija "Revizoru"

Es gaidīju redzēt periodiskus pieprasījumu uzplūdus, kas, manuprāt, norādītu uz organizētu darbību. Nevar teikt, ka es to vispār neredzēju, bet skaidra aina noteikti nebija:

Saskaitīsim aģentus "Revizors"

Kas nav pārsteidzoÅ”i, pat uz nevienam nevajadzÄ«gu domēnu uz nekad neizmantotu IP adresi tiks saņemta liela daudzuma nevēlamas informācijas, tāda ir mÅ«sdienu interneta realitāte. Bet, par laimi, man vajadzēja tikai pieprasÄ«jumus uz konkrētu URL, tāpēc visi skeneri un parole pārbaudÄ«tāji tika ātri atrasti. ArÄ« bija pietiekami viegli saprast, kur notiek masveida identisku pieprasÄ«jumu plÅ«di. Tālāk es sastādÄ«ju IP adresu parādīŔanās biežumu un manuāli izgāju cauri visam topam, atdalot tos, kas aizlēca iepriekŔējos posmos. Papildus es izgriezos visus avotus, kas nosÅ«tÄ«ja vienu pakotni, to bija jau maz. Un rezultāts izskatÄ«jās Ŕādi:

Saskaitīsim aģentus "Revizors"

Mazs liriskas atkāpe. Nedaudz vairāk nekā dienu pēc tam mans hostinga pakalpojumu sniedzējs nosÅ«tÄ«ja vēstuli diezgan izplÅ«duŔā saturā, sakot, ka jÅ«su resursos ir ierobežots elements pēc RKN saraksta, tāpēc tas tiek bloķēts. Vispirms domāju, ka ir bloķēts mans konts, bet tā nebija. Pēc tam domāju, ka mani vienkārÅ”i brÄ«dina par to, ko jau zinu. Bet izrādÄ«jās, ka hostings ir aktivizējis savu filtru pirms mana domēna, un beigās es nonācu dubultas filtrēŔanas situācijā: gan no piegādātājiem, gan no hostinga. Filtrs laida cauri tikai pieprasÄ«jumu beigas: FIN-ACK un RST nogriežot visu HTTP pa ierobežoto URL. Kā redzams no iepriekÅ” redzamā grafika, pēc pirmajām dienām es sāku saņemt mazāk datu, taču es tos joprojām saņēmu, kas bija pietiekami, lai veiktu pieprasÄ«jumu avotu skaitīŔanu.

Tuvu lietai. Manuprāt, ir diezgan skaidri redzami divi uzplaiksnÄ«jumi katru dienu, pirmais mazāks, pēc pusnakts pēc Maskavas laika, otrais tuvu plkst. 6 no rÄ«ta ar astÄ«ti lÄ«dz plkst. 12 dienā. Piks nenotiek precÄ«zi vienā un tajā paŔā laikā. Sākumā vēlējos izcelt IP adreses, kas nonāca tikai Å”ajos periodos, un katru visos periodos, pamatojoties uz pieņēmumu, ka aÄ£entu pārbaudes notiek periodiski. Bet, rÅ«pÄ«gi pārskatot, es ļoti ātri atklāju periodus, kas iekļaujas citos intervālos, ar citām frekvencēm, pat lÄ«dz vienam pieprasÄ«jumam katru stundu. Pēc tam domāju par laika joslām un to, vai tās varētu bÅ«t iemesls, pēc tam domāju, ka visa sistēma var nebÅ«t globāli sinhronizēta. Turklāt, noteikti, savu lomu spēlēs NAT, un viens un tas pats aÄ£ents var veikt pieprasÄ«jumus no dažādām publiskām IP adresēm.

Tā kā mana sākotnējā mērÄ·is nebija precizitāte, es saskaitÄ«ju visus adreses, kas nokļuvuÅ”as nedēļas laikā, un saņēmu — 2791. TCP sesiju skaits, kas izveidots no vienas adreses, vidēji ir 4, ar medianu 2. Augstākās sesijas adresē: 464, 231, 149, 83, 77. Maksimums no 95% izvēles — 8 sesijas uz adresi. Mēra medians nav ļoti augsts, atgādinu, ka pēc grafika ir skaidra diennakts periodiskums, tādēļ varēja gaidÄ«t kaut ko ap 4 lÄ«dz 8 7 dienu laikā. Ja izslēdz visas vienreiz sastopamās sesijas, tad tieÅ”i iegÅ«sim medianu 5. Tomēr es nevarēju tās izslēgt pēc skaidra kritērija. TieÅ”i pretēji, paraugu pārbaude rāda, ka tās ir saistÄ«tas ar ierobežotā resursa pieprasÄ«jumiem.

Adreses ir svarÄ«gas, taču internetā svarÄ«gākas ir autonomās sistēmas — AS, no kurām ir izveidotas 1510, vidēji 2 adresi uz AS ar mediānu 1. Top adreses uz AS: 288, 77, 66, 39, 27. Maksimālais rādÄ«tājs 95% parauga ir 4 adreses uz AS. Å eit mediāna ir gaidāma — viens aÄ£ents uz pakalpojumu sniedzēju. Top arÄ« ir gaidāms — tajā ir lielie spēlētāji. Lielā tÄ«klā aÄ£entiem, iespējams, bÅ«tu jāatrodas katrā operatora klātbÅ«tnes reÄ£ionā, neaizmirstot arÄ« par NAT. Ja aplÅ«kojam pa valstÄ«m, tad maksimālie rādÄ«tāji bÅ«s: 1409 — RU, 42 — UA, 23 — CZ, 36 no citiem reÄ£ioniem, ne RIPE NCC. PieprasÄ«jumi, kas nav no Krievijas, pievērÅ” uzmanÄ«bu. Iespējams, to var izskaidrot ar Ä£eolokācijas vai reÄ£istratoru datu aizpildīŔanas kļūdām. Vai ar to, ka Krievijas uzņēmumam var nebÅ«t Krievijas sakņu, vai tam var bÅ«t ārvalstu pārstāvniecÄ«ba, jo tas ir ērtāk, rÄ«kojoties ar ārvalstu organizāciju RIPE NCC. Daļa no tām noteikti ir lieka, bet precÄ«zi to atdalÄ«t ir grÅ«ti, jo resurss ir bloķēts, un no otrajām dienām zem divkārÅ”as bloķēŔanas, un lielākā daļa sesiju sastāv vienÄ«gi no apmaiņas ar dažiem pakalpojumu datiem. Vienojamies, ka tas ir mazs procents.

Å os skaitļus jau var salÄ«dzināt ar pakalpojumu sniedzēju skaitu Krievijā. Saskaņā ar RKN datiem licenču par "Datu pārsÅ«tīŔanas pakalpojumiem, izņemot balss" — 6387, taču tas ir ļoti augsts novērtējums, ne visas Ŕīs licences attiecas tieÅ”i uz internetā pakalpojumu sniedzējiem, kuriem nepiecieÅ”ams uzstādÄ«t aÄ£entu. RIPE NCC zonā lÄ«dzÄ«gs mÅ«su reÄ£istrēto AS skaitam Krievijā ir — 6230, no kuriem ne visi ir pakalpojumu sniedzēji. UserSide veica stingrāku skaitīŔanu un 2017. gadā guva 3940 uzņēmumus, un tas ir drÄ«zāk augsts novērtējums. Jebkurā gadÄ«jumā mēs redzam skaitu, kas parādÄ«jies AS, kas ir divas reizes mazāks. Bet Å”eit ir jāizprot, ka AS nav tieÅ”i vienāds ar pakalpojumu sniedzēju. Dažiem pakalpojumu sniedzējiem nav savas AS, daži no tiem ir vairāk nekā viens. Ja pieņemam, ka aÄ£enti patieŔām atrodas visiem, tas varētu nozÄ«mēt, ka kāds filtrē stiprāk nekā citi, tāpēc viņu pieprasÄ«jumi ir nesaskatāmi no atkritumiem, ja vispār sasniedz. Bet rupjai novērtēŔanai tas ir diezgan pieņemami, pat ja kaut kas ir zaudēts manas neuzmanÄ«bas dēļ.

Par DPI

Neskatoties uz to, ka mans hostinga pakalpojumu sniedzējs ieslēdza savu filtrāciju jau no otrās dienas, pirmās dienas dati liecina, ka bloķēŔanas mehānismi darbojas veiksmÄ«gi. Tikai 4 avoti spēja iekļūt un tiem ir pilnÄ«bā pabeigtas HTTP un TCP sesijas (kā iepriekŔējā piemērā). Vēl 460 var nosÅ«tÄ«t GET, taču sesija nekavējoties pārtrÅ«kst caur RST. LÅ«dzu, pievērsiet uzmanÄ«bu uz 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"

#Šo nosūtīja filtrs
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678  >  80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#Un tas ir mēģinājums no avota mezgla saņemt zaudējumus
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"

#Avota mezgls saprot, ka sesija ir iznīcināta
TTL 50, TCP, 14678  >  80, "[RST] Seq=294"
TTL 50, TCP, 14678  >  80, "[RST] Seq=295"

Variantus var bÅ«t dažādi: mazāk RST vai vairāk retransmÄ«tu — tas atkarÄ«gs arÄ« no tā, ko filtrs nosÅ«ta avota mezglam. Katrā ziņā tas ir visprecÄ«zākais paraugs, no kura redzams, ka tika pieprasÄ«ts tieÅ”i aizliegtais resurss. Turklāt vienmēr ir atbilde, kas parādās sesijā ar TTL lielāku nekā iepriekŔējos un nākamajos paketros.

No pārējiem pat nav redzams neviens GET:

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

#Šo nosūtīja filtrs
TTL 53, TCP, 14678  >  80, "[RST] Seq=1"

Vai arī tā:

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"

#Šo nosūtīja filtrs
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"

#Atkal filtrs, daudzkārt
TTL 53, TCP, 14678  >  80, "[RST, PSH] Seq=1"
...

Noteikti ir redzama atŔķirība, ja TTL kaut kas ierodas no filtra. Bet bieži var vispār nekas nepienā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ī tā:

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

#PagājuŔas dažas sekundes bez trafika

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

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

Par IPv6

Laba ziņa — tas notiek. Es varu apstiprināt, ka no 5 dažādiem IPv6 adresēm regulāri tiek veikti pieprasÄ«jumi uz aizliegtu resursu, tieÅ”i tā uzvedÄ«ba, kuru es gaidÄ«ju no AÄ£entiem. Turklāt viena no IPv6 adresēm netiek filtrēta, un es redzu pilnÄ«gu sesiju. No divām citām es redzēju tikai pa vienai nepabeigtai sesijai, no kurām viena tika pārtraukta pēc RST filtra, otrā pēc laika. Kopā 7.

Tā kā adresu ir maz, es rÅ«pÄ«gi izpētÄ«ju visas tās, un izrādÄ«jās, ka tur ir tikai 3 pakalpojumu sniedzēji, kurus var applaudēt stāvot! Vēl viena adrese — mākoņu hostings Krievijā (nefiltrē), vēl viena — pētniecÄ«bas centrs Vācijā (ir filtra, kur?). Bet kāpēc viņi regulāri pārbauda aizliegto resursu pieejamÄ«bu, ir labs jautājums. AtlikuÅ”as divas veica pa vienam pieprasÄ«jumam un atrodas ārpus Krievijas, un viena no tām tiek filtrēta (galu galā tranzÄ«tā?).

BloķēŔana un AÄ£enti ir liels kavējums IPv6, kura ievieÅ”ana jau tā norit lēni. Tas ir žēl. Tie, kas ir atrisinājuÅ”i Å”o problēmu pilnÄ«bā, var lepoties ar sevi.

Noslēgumā

Es necentos panākt 100% precizitāti, lÅ«dzu piedodiet man par to, ceru, ka kāds vēlēsies atkārtot Ŕādu darbu ar lielāku precizitāti. Man bija svarÄ«gi saprast, vai Ŕāds pieeja vispār darbosies. Atbilde — darbosies. IegÅ«tie dati pirmajā tuvumā, es domāju, ir diezgan uzticami.

Ko vēl varētu izdarÄ«t un ko es neizdarÄ«ju — saskaitÄ«t pieprasÄ«jumus uz DNS. Tie netiek filtrēti, bet arÄ« nedod augstu precizitāti, jo darbojas tikai domēnam, nevis visam URL. Periodiskums bÅ«tu redzams. Ja apvieno ar to, kas ir redzams tieÅ”i pieprasÄ«jumos, tas ļaus izdalÄ«t lieko un iegÅ«t vairāk informācijas. Iespējams pat noteikt DNS izstrādātājus, ko izmanto pakalpojumu sniedzēji, un vēl daudz ko citu.

Es pavisam negaidÄ«ju, ka manam VPS hostings ieslēgs arÄ« savu filtru. VarbÅ«t tas ir parasta prakse. Galu galā, RKN nosÅ«ta pieprasÄ«jumu uz resursa dzēŔanu tieÅ”i hostinga pakalpojumu sniedzējam. Bet tas mani ne pārsteidza un pat nedaudz spēlēja uz labu. Filtrs strādāja ļoti efektÄ«vi, izgriežot visus pareizos HTTP pieprasÄ«jumus uz aizliegtu URL, bet nepareizie, kas iepriekÅ” caur filtru tika veikti no pakalpojumu sniedzējiem, tika saņemti, lai arÄ« tikai noslēgumos: FIN-ACK un RST — mÄ«nus pie mÄ«nus un gandrÄ«z sanāca plus. Starp citu, IPv6 hosteris netika filtrēts. Protams, tas ietekmēja savākto materiālu kvalitāti, bet tomēr deva iespēju redzēt periodiskumu. IzrādÄ«jās, ka tas ir svarÄ«gs moments, izvēloties platformu resursu izvietoÅ”anai, neaizmirstiet interesēties par jautājumu, kā organizēt darbu ar aizliegto vietņu sarakstu un pieprasÄ«jumiem no RKN.

Sākumā salÄ«dzināju AS "Revizor" ar RIPE Atlas. Å is salÄ«dzinājums ir pilnÄ«gi pamatots, un liela aÄ£entu tÄ«kla klātbÅ«tne var nest labumu. Piemēram, noteikt resursa pieejamÄ«bas kvalitāti no dažādiem pakalpojumu sniedzējiem dažādās valsts daļās. Var aprēķināt aiztures, var bÅ«vēt grafikus, var to visu analizēt un redzēt notikumus, kas notiek gan lokāli, gan globāli. Tas nav vistieŔākais ceļŔ, bet taču astronomi izmanto "standarta sveces", kāpēc neizmantot aÄ£entus? Zinot (atrodot) to standarta uzvedÄ«bu, var noteikt izmaiņas, kas notiek apkārt tiem un kā tas ietekmē sniegto pakalpojumu kvalitāti. Un tajā paŔā laikā nav jāizvieto mērīŔanas ierÄ«ces pa tÄ«klu, tās jau ir novietojis Roskomnadzor.

Vēl viens moments, ko vēlos aplÅ«kot, ir, ka katrs instruments var bÅ«t ierocis. AS "Revizor" ir slēgta tÄ«kls, bet aÄ£enti nodod visus ar sirdi, nosÅ«tot pieprasÄ«jumus uz visām resursu no aizliegto saraksta. IegÅ«t Ŕādu resursu nav nevienas problēmas. LÄ«dz ar to pakalpojumu sniedzēji caur aÄ£entiem, paÅ”i to negribot, stāsta par savu tÄ«klu daudz vairāk, nekā varbÅ«t vajadzētu: DPI un DNS tipi, aÄ£enta atraÅ”anās vieta (centrālais mezgls un pakalpojumu tÄ«kls?), tÄ«kla aiztures un zaudējumu marÄ·ieri — un tas ir tikai acÄ«mredzamākais. Tāpat kā kāds var monitorēt aÄ£entu darbÄ«bas, lai uzlabotu savu resursu pieejamÄ«bu, kāds var to darÄ«t citos nolÅ«kos, un tam nav nekāda ŔķērŔļa. Rezultātā ir dubultas asmeņi un ļoti daudzveidÄ«gs instruments, ikviens var to pierādÄ«t.

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster