Dit is geen geheim dat die outomatiese stelsel "Revizor" die beheer van blokkering op die lys van verbode inligting in Rusland monitor nie. Hoe dit werk is goed hierin geskryf , die foto is van daar:
Geïnstalleer direk by die verskaffer :
Die "Agent Ouditeur" module is 'n strukturele element van die outomatiese stelsel "Inspekteur" (AS "Inspekteur"). Hierdie stelsel is ontwerp om die nakoming deur telekommunikasie-operateurs te beheer van die vereistes om toegang te beperk binne die raamwerk van die bepalings ingestel deur Artikels 15.1-15.4 van die Federale Wet van 27 Julie 2006 No. 149-FZ "Op Inligting, Inligtingstegnologie en Inligtingsbeskerming".
Die hoofdoel van die skepping van die AS "Revizor" is om te verseker dat telekommunikasie-operateurs voldoen aan die vereistes wat deur artikels 15.1-15.4 van die Federale Wet van 27 Julie 2006 No. en inligtingbeskerming" in terme van die identifisering van feite van toegang tot verbode inligting en die verkryging van ondersteunende materiaal (data) oor oortredings van die beperking van toegang tot verbode inligting.
Met inagneming van die feit dat, indien nie almal nie, dan baie verskaffers hierdie toestel by die huis geïnstalleer het, moes dit geblyk het 'n groot netwerk van sondebakens te wees soos en selfs meer, maar met geslote toegang. ’n Vuurtoring is egter ’n vuurtoring om seine in alle rigtings te stuur, maar wat as ons hulle vang en sien wat ons gevang het en hoeveel?
Voordat ons tel, kom ons kyk hoekom dit selfs moontlik is.
'N bietjie teorie
Agente kontroleer die beskikbaarheid van 'n hulpbron, insluitend deur HTTP(S)-versoeke, soos hierdie een:
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"
Benewens die loonvrag, bestaan die versoek ook uit die verbindingsopstelfase: ruil SYN и SYN-ACK, en verbinding beëindig fases: FIN-ACK.
Die verbode inligtingregister bevat verskeie soorte slotte. Natuurlik, as die hulpbron deur IP-adres of domeinnaam geblokkeer word, sal ons geen versoeke sien nie. Dit is die mees vernietigende tipes blokkering wat lei tot die onbeskikbaarheid van alle hulpbronne op een IP-adres of alle inligting op 'n domein. Daar is ook 'n "URL" tipe blokkering. In hierdie geval moet die filterstelsel die HTTP-versoekopskrif ontleed om presies te bepaal wat om te blokkeer. En voor dit, soos hierbo gesien kan word, moet daar 'n verbindingsopstelfase wees wat u kan probeer opspoor, aangesien die filter dit waarskynlik sal mis.
Om dit te doen, moet u 'n geskikte gratis domein kies met die tipe blokkering "deur URL" en HTTP, om die werk van die filterstelsel te vergemaklik, verkieslik 'n lang verlate een, om die ingang van vreemde verkeer te verminder, behalwe van Agente. Hierdie taak blyk glad nie moeilik te wees nie, daar is nogal baie gratis domeine in die register van verbode inligting en vir elke smaak. Daarom is die domein gekoop, gekoppel aan IP-adresse op 'n VPS wat loop tcpdump en die tel het begin.
Hersiening van die "Ouditeure"
Ek het verwag om periodieke uitbarstings van versoeke te sien, wat na my mening op 'n beheerde optrede sou dui. Dit is onmoontlik om te sê dat ek dit glad nie gesien het nie, maar daar was beslis geen duidelike prentjie nie:
Wat nie verbasend is nie, selfs 'n onnodige domein op 'n nooit gebruikte IP sal net 'n massa ongevraagde inligting ontvang, soos die moderne internet. Maar gelukkig het ek net versoeke vir 'n spesifieke URL nodig gehad, so al die skandeerders en wagwoord brute force is vinnig gevind. Dit was ook redelik maklik om te verstaan waar die vloed was as gevolg van die massa versoeke van dieselfde tipe. Toe het ek die frekwensie van voorkoms van IP-adresse saamgestel en deur die hele top gestap om diegene wat in die vorige stadiums deurgeglip het, met die hand te skei. Daarbenewens het ek al die bronne uitgesny wat een pakkie op 'n slag gestuur het, daar was nie baie van hulle nie. En dit is wat gebeur het:
'n Klein liriese afwyking. ’n Bietjie meer as ’n dag later het my gasheerverskaffer ’n brief met taamlik vaartbelynde inhoud gestuur en gesê dat jou fasiliteite ’n hulpbron van die verbode lys van die ILV het, dus is dit geblokkeer. Ek het eers gedink dat my rekening geblokkeer is, dit was nie. Toe dink ek dat ek net gewaarsku word oor wat ek reeds weet. Maar dit het geblyk dat die gasheer sy filter voor my domein aangeskakel het, en gevolglik het ek onder dubbelfiltrering geval: van die verskaffers en van die gasheer. Die filter het slegs die punte van die versoeke geslaag: FIN-ACK и RST sny alle HTTP op die verbode URL af. Soos u uit die grafiek hierbo kan sien, het ek na die eerste dag minder data begin ontvang, maar ek het dit steeds ontvang, wat genoeg was vir die taak om navraagbronne te tel.
Kom by die punt uit. Na my mening is twee sarsies elke dag duidelik sigbaar, die eerste is kleiner, na middernag Moskou-tyd, die tweede is nader aan 6 in die oggend met 'n stert tot 12 in die middag. Die piek kom nie presies op dieselfde tyd voor nie. Aanvanklik wou ek die IP-adresse uitlig wat slegs in hierdie tydperke en elk in alle tydperke geval het, gebaseer op die aanname dat Agent-kontroles periodiek uitgevoer word. Maar by nadere ondersoek het ek vinnig periodes ontdek wat in ander intervalle val, met ander frekwensies, tot een versoek elke uur. Toe dink ek aan tydsones en dat dit dalk die geval is, toe dink ek dat die stelsel in die algemeen dalk nie wêreldwyd gesinchroniseer is nie. Daarbenewens sal NAT verseker sy rol speel en dieselfde Agent kan versoeke van verskillende openbare IP's rig.
Aangesien my aanvanklike doelwit nie presies was nie, het ek al die adresse wat ek in 'n week raakgeloop het getel en gekry - 2791. Die aantal TCP-sessies wat vanaf een adres vasgestel is, is gemiddeld 4, met 'n mediaan van 2. Topsessies per adres: 464, 231, 149, 83, 77. Maksimum uit 95% van die steekproef is 8 sessies per adres. Die mediaan is nie baie hoog nie, laat ek jou herinner dat die grafiek 'n duidelike daaglikse periodisiteit toon, so jy kan iets rondom 4 tot 8 in 7 dae verwag. As ons alle eenmalige sessies uitgooi, dan kry ons net 'n mediaan gelyk aan 5. Maar ek kon hulle nie op 'n duidelike basis uitsluit nie. Inteendeel, 'n ewekansige kontrole het getoon dat hulle verband hou met versoeke vir 'n verbode hulpbron.
Adresse is adresse, en op die internet is outonome stelsels belangriker - AS, wat blyk te wees 1510, gemiddeld 2 adresse per AS met 'n mediaan van 1. Topadresse per AS: 288, 77, 66, 39, 27. Die maksimum van 95% van die steekproef is 4 adresse per AS. Hier word die mediaan verwag - een Agent per verskaffer. Ons verwag ook die top – daar is groot spelers daarin. In 'n groot netwerk moet agente waarskynlik in elke streek van die operateur se teenwoordigheid geleë wees, en moenie van NAT vergeet nie. As ons dit volgens land neem, sal die maksimums wees: 1409 - RU, 42 - UA, 23 - CZ, 36 van ander streke, nie RYP NCC nie. Versoeke van buite Rusland trek aandag. Dit kan waarskynlik verklaar word deur geoliggingsfoute of registrateurfoute wanneer data ingevul word. Of die feit dat 'n Russiese maatskappy dalk nie Russiese wortels het nie, of 'n buitelandse verteenwoordigende kantoor het omdat dit makliker is, wat natuurlik is wanneer jy met 'n buitelandse organisasie RIPE NCC te doen het. Sommige deel is ongetwyfeld oorbodig, maar dit is betroubaar moeilik om dit te skei, aangesien die hulpbron onder blokkering is, en vanaf die tweede dag onder dubbelblokkering, en die meeste sessies is net 'n uitruil van verskeie dienspakkette. Kom ons stem saam dat dit 'n klein deel is.
Hierdie getalle kan reeds vergelyk word met die aantal verskaffers in Rusland. lisensies vir "Kommunikasiedienste vir data-oordrag, behalwe vir stem" - 6387, maar dit is 'n baie hoë skatting van bo, nie al hierdie lisensies is spesifiek van toepassing op internetverskaffers wat 'n Agent moet installeer nie. In die RIPE NCC-sone is 'n soortgelyke aantal AS wat in Rusland geregistreer is 6230, waarvan nie alle verskaffers nie. en het 3940 maatskappye in 2017 ontvang, en dit is eerder 'n boonste skatting. In elk geval, ons het twee en 'n half keer minder aantal verligte AS'e. Maar hier is dit die moeite werd om te verstaan dat AS nie streng gelyk is aan die verskaffer nie. Sommige verskaffers het nie hul eie AS nie, sommige het meer as een. As ons aanvaar dat almal steeds Agente het, dan filter iemand meer as die ander, so hul versoeke is nie te onderskei van vullis, as hulle enigsins bereik nie. Maar vir 'n rowwe skatting is dit nogal draaglik, al het iets verlore gegaan as gevolg van my toesig.
Oor DPI
Ten spyte van die feit dat my gasheerverskaffer sy filter vanaf die tweede dag aangeskakel het, kan ons volgens die inligting vir die eerste dag aflei dat die blokkering suksesvol werk. Slegs 4 bronne kon deurbreek en het HTTP- en TCP-sessies volledig voltooi (soos in die voorbeeld hierbo). Nog 460 kan gestuur word GET, maar die sessie word onmiddellik beëindig deur RST. gee aandag aan 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"
Variasies hiervan kan anders wees: minder RST of meer heruitsendings - hang ook af van wat die filter na die bronnodus stuur. Dit is in elk geval die mees betroubare sjabloon, waaruit dit duidelik is dat dit 'n verbode hulpbron was wat aangevra is. Plus daar is altyd 'n antwoord wat verskyn in die sessie met TTL groter as in vorige en daaropvolgende pakkette.
Jy kan nie eers van die res sien nie 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 so:
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"
...
Jy kan beslis die verskil sien in TTL as iets uit die filter kom. Maar dikwels kan niks vlieg nie:
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 so:
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 herhaal en herhaal en herhaal, soos jy op die grafiek kan sien, nie presies een keer nie, elke dag.
Oor IPv6
Die goeie nuus is hy is. Ek kan verseker sê dat daar periodieke versoeke na die verbode hulpbron is vanaf 5 verskillende IPv6-adresse, presies die gedrag van die Agente wat ek verwag het. Boonop val een van die IPv6-adresse nie onder filter nie en ek sien 'n volwaardige sessie. Van nog twee het ek net een onvolledige sessie elk gesien, waarvan een deur onderbreek is RST van die filter, die tweede in tyd. Totale bedrag 7.
Aangesien daar min adresse is, het ek almal in detail bestudeer en dit het geblyk dat daar eintlik net 3 verskaffers is, hulle kan 'n staande ovasie gegee word! 'n Ander adres is 'n wolkgasheer in Rusland (filtreer nie), 'n ander adres is 'n navorsingsentrum in Duitsland (is daar 'n filter, waar?). Maar hoekom hulle die beskikbaarheid van verbode hulpbronne op 'n skedule nagaan, is 'n goeie vraag. Die oorblywende twee het een versoek gerig en is buite Rusland geleë, en een van hulle is gefiltreer (na alles, in transito?).
Blokkering en agente is 'n groot hindernis vir IPv6, waarvan die implementering nie baie vinnig beweeg nie. Dit is hartseer. Diegene wat hierdie probleem opgelos het, kan ten volle trots wees op hulself.
Ten slotte
Ek het nie 100% akkuraatheid nagestreef nie, ek vra jou om my hiervoor te vergewe, ek hoop iemand wil sulke werk met groter akkuraatheid herhaal. Dit was vir my belangrik om te verstaan of so 'n benadering in beginsel sou werk. Die antwoord is dit sal. Die syfers wat in die eerste benadering verkry is, dink ek, is redelik betroubaar.
Wat anders gedoen kan word en wat ek te lui was om te doen - tel DNS-versoeke. Hulle word nie gefiltreer nie, maar hulle bied ook nie veel akkuraatheid nie, aangesien hulle net vir die domein werk, nie die hele URL nie. Periodisiteit moet sigbaar wees. As dit gekombineer word met wat direk in die navrae sigbaar is, sal dit jou toelaat om die oorskot te skei en meer inligting te kry. Dit is selfs moontlik om die ontwikkelaars van die DNS wat deur die ISP's gebruik word, te identifiseer en nog baie meer.
Ek het absoluut nie verwag dat die gasheer ook sy eie filter vir my VPS sou insluit nie. Miskien is dit algemene praktyk. Op die ou end stuur RKN 'n versoek om die hulpbron te skrap aan die gasheer. Maar dit het my nie verras nie en in sekere opsigte selfs tot my voordeel gewerk. Die filter het baie effektief gewerk, en het alle korrekte HTTP-versoeke na 'n verbode URL afgesny, maar nie die korrekte wat voorheen deur die verskaffer se filter gegaan het, het hulle bereik nie, alhoewel slegs in die vorm van eindes: FIN-ACK и RST - minus vir minus en dit blyk amper 'n pluspunt te wees. Terloops, IPv6 is nie deur die gasheer gefiltreer nie. Dit het natuurlik die kwaliteit van die versamelde materiaal beïnvloed, maar dit het dit steeds moontlik gemaak om die frekwensie te sien. Dit het geblyk dat dit 'n belangrike punt is by die keuse van 'n webwerf vir die plasing van hulpbronne; moenie vergeet om belang te stel in die kwessie van die organisering van werk met die lys van verbode werwe en versoeke van die RKN nie.
Aan die begin het ek AS "Revizor" vergelyk met . Hierdie vergelyking is redelik geregverdig en 'n groot netwerk van agente kan nuttig wees. Byvoorbeeld, die bepaling van die kwaliteit van beskikbaarheid van 'n hulpbron van verskillende verskaffers in verskillende dele van die land. Jy kan die vertragings bereken, jy kan grafieke bou, jy kan dit alles ontleed en sien hoe die veranderinge plaaslik en wêreldwyd plaasvind. Dit is nie die mees direkte manier nie, maar sterrekundiges gebruik "standaard kerse", waarom nie Agente gebruik nie? Deur hul standaardgedrag te ken (vind), is dit moontlik om die veranderinge wat rondom hulle plaasvind te bepaal en hoe dit die kwaliteit van dienste wat gelewer word, beïnvloed. En terselfdertyd hoef u nie sondes onafhanklik oor die netwerk te plaas nie, dit is reeds deur Roskomnadzor geïnstalleer.
Nog 'n punt wat ek wil aanraak, is dat elke werktuig 'n wapen kan wees. AS "Revizor" is 'n geslote netwerk, maar die Agente gee almal weg deur versoeke vir alle hulpbronne van die verbode lys te stuur. Om so 'n hulpbron te hê, bied glad nie probleme nie. In totaal vertel verskaffers deur Agente, onbewustelik, baie meer oor hul netwerk as wat dit dalk die moeite werd is: DPI- en DNS-tipes, Agentligging (sentrale nodus en diensnetwerk?), netwerkvertraging en verliesmerkers - en dit is net die meeste voor die hand liggend. Net soos iemand die optrede van Agente kan monitor om die beskikbaarheid van hul hulpbronne te verbeter, kan iemand dit vir ander doeleindes doen en daar is geen struikelblokke hiervoor nie. 'n Tweesnydende en baie veelvlakkige werktuig het uitgedraai, enigiemand kan hiervan oortuig word.
Bron: will.com