It is gjin geheime dat de kontrôle fan blokkearjen op 'e list fan ferbeane ynformaasje yn Ruslân wurdt kontrolearre troch it automatisearre systeem "Inspector". Hoe't it wurket is hjir goed skreaun , foto fan itselde plak:
Ynstallearre direkt by de provider :
De module "Agent Inspector" is in struktureel elemint fan it automatisearre systeem "Inspector" (AS "Inspector"). Dit systeem is ûntwurpen om te kontrolearjen neilibjen troch telecom operators mei tagong beheining easken binnen it ramt fan de bepalingen fêststeld troch kêsten 15.1-15.4 fan de Federale Wet fan 27. Juli 2006 No.. 149-FZ "On Information, Information Technologies and Information Protection. ”
It haaddoel fan it meitsjen fan AS "Revizor" is om te garandearjen tafersjoch op it neilibjen fan telekomoperators oan 'e easken fêststeld troch kêsten 15.1-15.4 fan' e federale wet fan 27 july 2006 No. 149-FZ "On Information, Information Technologies and Information Protection". " yn termen fan it identifisearjen fan feiten fan tagong ta ferbeane ynformaasje en it krijen fan stypjende materialen (gegevens) oer oertredings om tagong te beheinen ta ferbeane ynformaasje.
Mei it rekkenjen fan it feit dat, as net allegear, dan in protte providers dit apparaat hawwe ynstalleare, soe d'r in grut netwurk wêze moatte fan beaconprobes lykas en noch mear, mar mei sletten tagong. In beaken is lykwols in beaken om sinjalen yn alle rjochtingen te stjoeren, mar wat as wy se fange en sjen wat wy fongen hawwe en hoefolle?
Foardat wy telle, litte wy sjen wêrom dit sels mooglik is.
In bytsje teory
Aginten kontrolearje de beskikberens fan in boarne, ynklusyf fia HTTP(S)-oanfragen, lykas dizze:
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"
Njonken de lading bestiet it fersyk ek út in faze fan ferbining oprjochting: útwikseling SYN и SYN-ACK, en fazen foar foltôging fan ferbining: FIN-ACK.
It register fan ferbeane ynformaasje befettet ferskate soarten blokkearjen. Fansels, as in boarne wurdt blokkearre troch IP-adres of domeinnamme, dan sille wy gjin oanfragen sjen. Dit binne de meast destruktive soarten blokkearjen, dy't liede ta de ûnberikberens fan alle boarnen op ien IP-adres of alle ynformaasje op in domein. D'r is ek in "troch URL" type blokkearjen. Yn dit gefal moat it filtersysteem de HTTP-fersykkoper parse om krekt te bepalen wat te blokkearjen. En dêrfoar, lykas hjirboppe te sjen is, moat d'r in faze foar it oprjochtsjen fan ferbining wêze dy't jo kinne besykje te folgjen, om't wierskynlik it filter it sil misse.
Om dit te dwaan, moatte jo in gaadlik fergese domein selektearje mei it type "URL" en HTTP-blokkearjen om it wurk fan it filtersysteem te fasilitearjen, leafst lang ferlitten, om de ynfier fan bûtenlânske ferkear te minimalisearjen, útsein fan Agents. Dizze taak bleek hielendal net dreech te wêzen, d'r binne nochal in protte fergese domeinen yn it register fan ferbeane ynformaasje en foar elke smaak. Dêrom waard it domein kocht en keppele oan IP-adressen op in VPS dy't draait tcpdump en it tellen begûn.
Audit fan "Auditors"
Ik ferwachte te sjen periodike bursts fan fersiken, dy't nei myn miening soe oanjaan kontrolearre aksje. It is ûnmooglik om te sizzen dat ik it hielendal net seach, mar d'r wie perfoarst gjin dúdlik byld:
Wat net ferrassend is, sels op in domein dat gjinien nedich hat en op in nea brûkte IP sil d'r gewoan in ton net frege ynformaasje wêze, sa is it moderne ynternet. Mar gelokkich hie ik allinich fersiken nedich foar in spesifike URL, sadat alle scanners en wachtwurdcrackers gau fûn waarden. Ek wie it frij maklik te begripen wêr't de oerstreaming basearre wie op 'e massa fan ferlykbere fersiken. Folgjende, ik kompilearre de frekwinsje fan foarkommen fan IP-adressen en gie troch de hiele top mei de hân, skieden dejingen dy't miste it yn 'e foarige stadia. Dêrnjonken ha ik alle boarnen útknipt dy't yn ien pakket ferstjoerd wiene, der wiene net folle mear. En dit is wat der bard:
In lytse lyryske digresje. In bytsje mear as in dei letter stjoerde myn hostingprovider in brief mei in frij streamlined ynhâld, sizzende dat jo foarsjenningen in boarne befetsje fan 'e RKN ferbeane list, dus it is blokkearre. Earst tocht ik dat myn akkount blokkearre wie, dit wie net it gefal. Doe tocht ik dat se my gewoan warskôgen foar eat dat ik al wist. Mar it die bliken dat de hoster syn filter foar myn domein oansette en dêrtroch kaam ik ûnder dûbele filtering: fan de providers en fan de hoster. It filter hat allinich de einen fan fersiken trochjûn: FIN-ACK и RST it ôfsnijen fan alle HTTP op in ferbeane URL. Sa't jo sjen kinne út de grafyk hjirboppe, nei de earste dei begon ik minder gegevens te ûntfangen, mar ik krige it noch, wat genôch wie foar de taak om fersykboarnen te tellen.
Kom ta de saak. Neffens my binne twa bursts alle dagen dúdlik te sjen, de earste lytser, nei middernacht Moskouske tiid, de twadde tichterby 6 oere mei in sturt oant 12 oere. De peak komt net krekt tagelyk foar. Earst woe ik IP-adressen selektearje dy't allinich yn dizze perioaden foelen en elk yn alle perioaden, basearre op de oanname dat kontrôles troch Agents periodyk wurde útfierd. Mar by soarchfâldige beoardieling ûntduts ik gau perioaden dy't yn oare yntervallen falle, mei oare frekwinsjes, oant ien fersyk elk oere. Doe tocht ik oer tiidsônes en dat it der miskien wat mei te krijen hie, doe tocht ik dat it systeem yn 't algemien net wrâldwiid syngronisearre wurde kin. Derneist sil NAT wierskynlik in rol spylje en kin deselde Agent oanfragen meitsje fan ferskate iepenbiere IP's.
Om't myn earste doel net krekt wie, telde ik alle adressen dy't ik yn in wike tsjinkaam en krige - 2791. It oantal TCP-sesjes fêststeld fan ien adres is gemiddeld 4, mei in mediaan fan 2. Topsesjes per adres: 464, 231, 149, 83, 77. It maksimum fan 95% fan 'e stekproef is 8 sesjes per adres. De mediaan is net hiel heech, lit my jo herinnerje dat de grafyk in dúdlike deistige periodiciteit toant, dus men koe wat om de 4 oant 8 ferwachtsje yn 7 dagen. As wy smite út alle sesjes dy't foarkomme ien kear, wy krije in mediaan gelyk oan 5. Mar ik koe net útslute se basearre op in dúdlik kritearium. Krektoarsom, in willekeurige kontrôle die bliken dat se wiene relatearre oan fersiken foar in ferbeane boarne.
Adressen binne adressen, mar op it ynternet, autonome systemen - AS, dy't bliken te wêzen wichtiger 1510, gemiddeld 2 adressen per AS mei in mediaan fan 1. Topadressen per AS: 288, 77, 66, 39, 27. It maksimum fan 95% fan 'e stekproef is 4 adressen per AS. Hjir wurdt de mediaan ferwachte - ien Agent per provider. Wy ferwachtsje ek de top - dêr sitte grutte spilers yn. Yn in grut netwurk, Aginten moatte nei alle gedachten wurde leit yn elke regio fan de operator syn oanwêzigens, en ferjit net oer NAT. As wy nimme it troch lân, de maksimums sille wêze: 1409 - RU, 42 - UA, 23 - CZ, 36 út oare regio, net RIPE NCC. Fersiken fan bûten Ruslân lûke oandacht. Dit kin wierskynlik ferklearre wurde troch geolokaasjeflaters of registrarflaters by it ynfoljen fan gegevens. Of it feit dat in Russyske bedriuw miskien gjin Russyske woartels hawwe, of in bûtenlânske represintatyf kantoar hawwe, om't it makliker is, wat natuerlik is by it omgean mei in bûtenlânske organisaasje RIPE NCC. Guon diel is sûnder mis oerstallich, mar it is betrouber lestich om it te skieden, om't de boarne ûnder blokkearjen is, en fan 'e twadde dei ûnder dûbele blokkearjen, en de measte sesjes binne gewoan in útwikseling fan ferskate tsjinstpakketten. Litte wy it iens wêze dat dit in lyts part is.
Dizze nûmers kinne al fergelike wurde mei it oantal oanbieders yn Ruslân. lisinsjes foar "Kommunikaasje tsjinsten foar gegevens oerdracht, útsein stim" - 6387, mar dit is in tige hege skatting fan boppen, net al dizze lisinsjes jilde spesifyk foar ynternet providers dy't moatte ynstallearje in Agent. Yn 'e RIPE NCC-sône is d'r in ferlykber oantal AS's registrearre yn Ruslân - 6230, wêrfan net allegear oanbieders binne. en krige 3940 bedriuwen yn 2017, en dit is earder in skatting fan boppen. Yn alle gefallen hawwe wy twa en in heal kear minder oantal ferljochte AS's. Mar hjir is it wurdich te begripen dat AS net strikt gelyk is oan de provider. Guon oanbieders hawwe gjin eigen AS, guon hawwe mear as ien. As wy oannimme dat elkenien noch Agenten hat, dan filtert immen sterker as oaren, sadat har oanfragen net te ûnderskieden binne fan jiskefet, as se har überhaupt berikke. Mar foar in rûge beoardieling is it frij te fernearen, sels as der wat ferlern gien is troch myn tafersjoch.
Oer DPI
Nettsjinsteande it feit dat myn hostingprovider syn filter fan 'e twadde dei ynskeakele hat, kinne wy op basis fan' e ynformaasje fan 'e earste dei konkludearje dat it blokkearjen mei sukses wurket. Allinich 4 boarnen koenen trochkomme en hawwe HTTP- en TCP-sesjes folslein foltôge (lykas yn it foarbyld hjirboppe). In oare 460 kin ferstjoerd wurde GET, mar de sesje wurdt fuortendaliks beëinige troch RST. Jou oandacht oan 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"
Fariaasjes fan dit kin wêze oars: minder RST of mear retransmits - hinget ek ôf fan wat it filter stjoert nei de boarne node. Yn alle gefallen is dit de meast betroubere sjabloan, wêrfan it dúdlik is dat it in ferbeane boarne wie dy't frege waard. Plus der is altyd in antwurd dat ferskynt yn 'e sesje mei TTL grutter as yn eardere en folgjende pakketten.
Jo kinne it net iens sjen fan 'e rest 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"
Of sa:
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"
...
It ferskil is perfoarst sichtber TTL as der wat út it filter komt. Mar faak komt der hielendal neat:
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"
...
Of sa:
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"
...
En dit alles wurdt werhelle en werhelle en werhelle, sa't op 'e grafyk te sjen is, mear as ien kear, elke dei.
Oer IPv6
It goede nijs is dat it bestiet. Ik kin betrouber sizze dat periodike oanfragen nei in ferbeane boarne komme fan 5 ferskillende IPv6-adressen, dat is krekt it gedrach fan 'e Aginten dy't ik ferwachte. Boppedat falt ien fan 'e IPv6-adressen net ûnder filterjen en sjoch ik in folsleine sesje. Fan twa mear seach ik mar ien ûnfoltôge sesje, wêrfan ien waard ûnderbrutsen troch RST út it filter, twadde yn 'e tiid. Totaalbedrach 7.
Om't d'r in pear adressen binne, haw ik se allegear yn detail bestudearre en it die bliken dat d'r mar 3 oanbieders binne, dy kinne in steande ovaasje jûn wurde! In oar adres is wolkhosting yn Ruslân (filteret net), in oar is in ûndersykssintrum yn Dútslân (d'r is in filter, wêr?). Mar wêrom kontrolearje se de beskikberens fan ferbeane boarnen op in skema is in goede fraach. De oerbleaune twa makke ien fersyk en lizze bûten Ruslân, en ien fan harren is filtere (yn transit, nei alle gedachten?).
Blokkearje en aginten binne in grut hinderjen foar IPv6, wêrfan de ymplemintaasje net heul fluch beweecht. It is tryst. Dejingen dy't dit probleem oplost hawwe kinne folslein grutsk wêze op harsels.
Yn ôfsluting
Ik stribje net nei 100% krektens, ferjou my asjebleaft dit, ik hoopje dat immen dit wurk mei gruttere krektens wol werhelje. It wie foar my wichtich om te begripen oft dizze oanpak yn prinsipe wurkje soe. It antwurd is ja. As earste approximation binne de krigen sifers, tink ik, frij betrouber.
Wat oars koe dien wurde en wat ik te lui wie om te dwaan wie DNS-fersiken te tellen. Se wurde net filtere, mar se jouwe ek net folle krektens, om't se allinich wurkje foar it domein, en net foar de heule URL. De frekwinsje moat sichtber wêze. As jo it kombinearje mei wat direkt yn 'e queries sichtber is, sil dit jo de ûnnedige skiede kinne en mear ynformaasje krije. It is sels mooglik om te bepalen de ûntwikkelders fan 'e DNS brûkt troch providers en folle mear.
Ik hie perfoarst net ferwachte dat de hoster ek in eigen filter foar myn VPS soe befetsje. Miskien is dit gewoane praktyk. Uteinlik stjoert RKN in fersyk om de boarne te wiskjen nei de hoster. Mar dit fernuvere my net en wurke op guon manieren sels yn myn foardiel. It filter wurke heul effektyf, en snijde alle juste HTTP-oanfragen ôf nei in ferbeane URL, mar net korrekten dy't earder troch it filter fan 'e providers trochjûn wiene, berikten it, hoewol allinich yn' e foarm fan eintsjes: FIN-ACK и RST - minus foar minus en it blykte hast in plus te wêzen. Trouwens, IPv6 waard net filtere troch de hoster. Fansels hie dit ynfloed op de kwaliteit fan it sammele materiaal, mar it makke it dochs mooglik om de frekwinsje te sjen. It die bliken dat dit in wichtich punt is by it kiezen fan in side foar it pleatsen fan boarnen, ferjit net om ynteresse te nimmen yn 'e kwestje fan it organisearjen fan wurk mei de list fan ferbeane siden en oanfragen fan' e RKN.
Oan it begjin, ik fergelike de AS "Inspekteur" mei . Dizze fergeliking is frij rjochtfeardige en in grut netwurk fan aginten kin foardielich wêze. Bygelyks, it bepalen fan de kwaliteit fan beskikberens fan boarnen fan ferskate providers yn ferskate dielen fan it lân. Jo kinne fertragingen berekkenje, jo kinne grafiken bouwe, jo kinne alles analysearje en de feroaringen sjen dy't plakfine sawol lokaal as wrâldwiid. Dit is net de meast direkte wize, mar astronomen brûke "standert kearsen", wêrom net brûke Agents? Troch har standertgedrach te witten (nei't se fûn hawwe), kinne jo de wizigingen bepale dy't om har hinne foarkomme en hoe't dit ynfloed hat op de kwaliteit fan 'e oanbeane tsjinsten. En tagelyk hoege jo net selsstannich sondes op it netwurk te pleatsen Roskomnadzor hat se al ynstalleare.
In oar punt dat ik wol oanreitsje is dat elk ark in wapen kin wêze. AS "Inspector" is in sletten netwurk, mar de Aginten jouwe elkenien troch fersiken te stjoeren foar alle boarnen fan 'e ferbeane list. It hawwen fan sa'n boarne jout gjin problemen. Yn totaal fertelle providers fia Agents, ûnbewust, folle mear oer har netwurk dan it wierskynlik wurdich is: DPI- en DNS-typen, lokaasje fan 'e Agent (sintraal knooppunt en tsjinstnetwurk?), netwurkmarkers fan fertragingen en ferliezen - en dit is allinne de meast foar de hân lizzende. Krekt sa't immen de aksjes fan Agents kin kontrolearje om de beskikberens fan har middels te ferbetterjen, kin immen dit dwaan foar oare doelen en d'r binne gjin obstakels foar dit. It resultaat is in twasnijden en tige mearsidige ynstrumint, elkenien kin dit sjen.
Boarne: www.habr.com