Det er ingen hemmelighed, at kontrollen med blokering på listen over forbudte oplysninger i Rusland overvåges af det automatiske system "Inspector". Hvordan det fungerer er godt skrevet her i denne , billede fra samme sted:
Installeres direkte hos udbyderen :
"Agent Inspector"-modulet er et strukturelt element i det automatiserede system "Inspector" (AS "Inspector"). Dette system er designet til at overvåge teleoperatørers overholdelse af adgangsbegrænsningskrav inden for rammerne af bestemmelserne fastsat i artikel 15.1-15.4 i den føderale lov af 27. juli 2006 nr. 149-FZ "Om information, informationsteknologi og informationsbeskyttelse. ”
Hovedformålet med at oprette AS "Revizor" er at sikre overvågning af teleoperatørers overholdelse af kravene fastsat i artikel 15.1-15.4 i den føderale lov af 27. juli 2006 nr. 149-FZ "Om information, informationsteknologi og informationsbeskyttelse " med hensyn til at identificere fakta om adgang til forbudte oplysninger og indhente støttemateriale (data) om overtrædelser for at begrænse adgangen til forbudte oplysninger.
I betragtning af det faktum, at hvis ikke alle, så mange udbydere har installeret denne enhed, burde der have været et stort netværk af beacon-sonder som f.eks. og endnu mere, men med lukket adgang. Et beacon er dog et beacon til at sende signaler i alle retninger, men hvad nu hvis vi fanger dem og ser hvad vi fangede og hvor mange?
Før vi tæller, lad os se, hvorfor det overhovedet er muligt.
Lidt teori
Agenter kontrollerer tilgængeligheden af en ressource, herunder via HTTP(S)-anmodninger, såsom denne:
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"
Foruden nyttelasten består anmodningen også af en forbindelsesetableringsfase: udveksling SYN и SYN-ACK, og tilslutningsfuldførelsesfaser: FIN-ACK.
Registeret over forbudte oplysninger indeholder flere former for blokering. Hvis en ressource er blokeret af IP-adresse eller domænenavn, vil vi naturligvis ikke se nogen anmodninger. Disse er de mest ødelæggende typer af blokering, som fører til utilgængelighed for alle ressourcer på én IP-adresse eller alle oplysninger på et domæne. Der er også en "ved URL"-type blokering. I dette tilfælde skal filtreringssystemet parse HTTP-anmodningsheaderen for at bestemme nøjagtigt, hvad der skal blokeres. Og før det, som det kan ses ovenfor, skulle der være en forbindelsesetableringsfase, som du kan prøve at spore, da filteret højst sandsynligt savner det.
For at gøre dette skal du vælge et passende gratis domæne med "URL"- og HTTP-blokeringstypen for at lette arbejdet med filtreringssystemet, helst for længst forladt, for at minimere adgangen til fremmed trafik undtagen fra agenter. Denne opgave viste sig slet ikke at være svær; der er en hel del gratis domæner i registret over forbudte oplysninger og for enhver smag. Derfor blev domænet købt og knyttet til IP-adresser på en kørende VPS tcpdump og optællingen begyndte.
Revision af "revisorer"
Jeg forventede at se periodiske udbrud af anmodninger, hvilket efter min mening ville indikere kontrolleret handling. Det er umuligt at sige, at jeg slet ikke så det, men der var bestemt ikke noget klart billede:
Hvilket ikke er overraskende, selv på et domæne, som ingen har brug for, og på en aldrig brugt IP, vil der simpelthen være et væld af uopfordret information, sådan er det moderne internet. Men heldigvis havde jeg kun brug for anmodninger om en bestemt URL, så alle scannere og adgangskodeknækkere blev hurtigt fundet. Det var også ret let at forstå, hvor oversvømmelsen var baseret på massen af lignende anmodninger. Dernæst kompilerede jeg hyppigheden af forekomst af IP-adresser og gik igennem hele toppen manuelt, og adskilte dem, der gik glip af det i de foregående faser. Derudover klippede jeg alle de kilder ud, der blev sendt i én pakke, der var ikke mange af dem længere. Og dette er hvad der skete:
En lille lyrisk digression. Lidt mere end et døgn senere sendte min hostingudbyder et brev med et ret strømlinet indhold og sagde, at dine faciliteter indeholder en ressource fra RKN's forbudte liste, så den er blokeret. Først troede jeg, at min konto var blokeret, det var ikke tilfældet. Så tænkte jeg, at de simpelthen advarede mig om noget, jeg allerede vidste om. Men det viste sig, at hosteren tændte sit filter foran mit domæne, og som et resultat kom jeg under dobbeltfiltrering: fra udbyderne og fra hosteren. Filteret bestod kun slutningen af anmodninger: FIN-ACK и RST afskære al HTTP på en forbudt URL. Som du kan se på grafen ovenfor, begyndte jeg efter den første dag at modtage mindre data, men jeg modtog det stadig, hvilket var ganske nok til opgaven med at tælle anmodningskilder.
Kom til sagen. Efter min mening er to udbrud tydeligt synlige hver dag, den første mindre, efter midnat i Moskva-tid, den anden tættere på kl. 6 med en hale indtil kl. 12. Toppen indtræffer ikke på nøjagtig samme tidspunkt. Først ønskede jeg at vælge IP-adresser, der kun faldt i disse perioder og hver i alle perioder, baseret på den antagelse, at kontrol af agenter udføres med jævne mellemrum. Men efter omhyggelig gennemgang opdagede jeg hurtigt perioder, der faldt i andre intervaller, med andre frekvenser, op til en anmodning hver time. Så tænkte jeg på tidszoner, og at det måske havde noget med dem at gøre, så tænkte jeg, at systemet generelt ikke var synkroniseret globalt. Derudover vil NAT formentlig spille en rolle, og den samme Agent kan lave anmodninger fra forskellige offentlige IP'er.
Da mit oprindelige mål ikke var præcist, talte jeg alle de adresser, jeg stødte på i løbet af en uge og fik - 2791. Antallet af TCP-sessioner etableret fra én adresse er i gennemsnit 4, med en median på 2. Topsessioner pr. adresse: 464, 231, 149, 83, 77. Det maksimale fra 95 % af stikprøven er 8 sessioner pr. adresse. Medianen er ikke særlig høj, lad mig minde om, at grafen viser en tydelig daglig periodicitet, så man kunne forvente noget omkring 4 til 8 på 7 dage. Hvis vi smider alle de sessioner, der opstår én gang, får vi en median lig med 5. Men jeg kunne ikke udelukke dem ud fra et klart kriterium. Tværtimod viste en stikprøvekontrol, at de var relateret til anmodninger om en forbudt ressource.
Adresser er adresser, men på internettet, autonome systemer - AS, som viste sig at være vigtigere 1510, i gennemsnit 2 adresser pr. AS med en median på 1. Topadresser pr. AS: 288, 77, 66, 39, 27. Det maksimale på 95 % af stikprøven er 4 adresser pr. AS. Her forventes medianen - én agent pr. udbyder. Vi forventer også toppen – der er store spillere i den. I et stort netværk bør agenter sandsynligvis være placeret i hver region af operatørens tilstedeværelse, og glem ikke NAT. Hvis vi tager det efter land, vil maksimumerne være: 1409 - RU, 42 - UA, 23 - CZ, 36 fra andre regioner, ikke RIPE NCC. Forespørgsler uden for Rusland tiltrækker opmærksomhed. Dette kan sandsynligvis forklares med geolokationsfejl eller registratorfejl ved udfyldning af data. Eller det faktum, at en russisk virksomhed måske ikke har russiske rødder, eller har et udenlandsk repræsentationskontor, fordi det er nemmere, hvilket er naturligt, når man har at gøre med en udenlandsk organisation RIPE NCC. En del er utvivlsomt overflødig, men det er pålideligt svært at adskille det, da ressourcen er under blokering og fra anden dag under dobbeltblokering, og de fleste sessioner er blot en udveksling af flere servicepakker. Lad os blive enige om, at dette er en lille del.
Disse tal kan allerede sammenlignes med antallet af udbydere i Rusland. licenser til "Kommunikationstjenester til datatransmission, undtagen tale" - 6387, men dette er et meget højt estimat fra oven, ikke alle disse licenser gælder specifikt for internetudbydere, der skal installere en agent. I RIPE NCC-zonen er der et tilsvarende antal AS'er registreret i Rusland - 6230, hvoraf ikke alle er udbydere. og modtog 3940 virksomheder i 2017, og det er snarere et skøn fra oven. Under alle omstændigheder har vi to en halv gange færre oplyste AS'er. Men her er det værd at forstå, at AS strengt taget ikke er lig med udbyderen. Nogle udbydere har ikke deres eget AS, nogle har mere end et. Hvis vi antager, at alle stadig har agenter, så filtrerer nogen stærkere end andre, så deres anmodninger ikke kan skelnes fra skrald, hvis de overhovedet når dem. Men for en grov vurdering er det ganske tåleligt, selvom noget gik tabt på grund af min forglemmelse.
Om DPI
På trods af at min hostingudbyder tændte sit filter fra den anden dag, kan vi på baggrund af oplysningerne fra den første dag konkludere, at blokeringen fungerer med succes. Kun 4 kilder var i stand til at komme igennem og har fuldstændig gennemført HTTP- og TCP-sessioner (som i eksemplet ovenfor). Yderligere 460 kan sendes GET, men sessionen afsluttes øjeblikkeligt af RST. Vær opmærksom på 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"
Variationer af dette kan være forskellige: mindre RST eller flere retransmits - afhænger også af hvad filteret sender til kildenoden. Under alle omstændigheder er dette den mest pålidelige skabelon, hvoraf det tydeligt fremgår, at det var en forbudt ressource, der blev anmodet om. Plus der er altid et svar, der dukker op i sessionen med TTL større end i tidligere og efterfølgende pakker.
Du kan ikke engang se det fra resten 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"
Eller så:
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"
...
Forskellen er bestemt synlig TTL hvis der kommer noget fra filteret. Men ofte kommer der ikke noget overhovedet:
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"
...
Eller så:
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"
...
Og alt dette bliver gentaget og gentaget og gentaget, som det kan ses på grafen, mere end én gang, hver dag.
Om IPv6
Den gode nyhed er, at den eksisterer. Jeg kan med sikkerhed sige, at periodiske anmodninger til en forbudt ressource forekommer fra 5 forskellige IPv6-adresser, hvilket er nøjagtigt den opførsel af agenterne, som jeg forventede. Desuden falder en af IPv6-adresserne ikke under filtrering, og jeg ser en fuld session. Fra to mere så jeg kun én uafsluttet session, hvoraf den ene blev afbrudt af RST fra filteret, anden gang i tiden. Total beløb 7.
Da der er få adresser, studerede jeg dem alle i detaljer, og det viste sig, at der kun er 3 udbydere der, de kan få et stående bifald! En anden adresse er cloud-hosting i Rusland (filtrerer ikke), en anden er et forskningscenter i Tyskland (der er et filter, hvor?). Men hvorfor tjekker de tilgængeligheden af forbudte ressourcer på en tidsplan, er et godt spørgsmål. De resterende to fremsatte én anmodning og er placeret uden for Rusland, og en af dem er filtreret (i transit, trods alt?).
Blokering og agenter er en stor hindring for IPv6, hvis implementering ikke går særlig hurtigt. Det er trist. De, der har løst dette problem, kan være fuldt ud stolte af sig selv.
Afslutningsvis
Jeg stræbte ikke efter 100% nøjagtighed, tilgiv mig venligst for dette, jeg håber nogen vil gentage dette arbejde med større nøjagtighed. Det var vigtigt for mig at forstå, om denne tilgang ville fungere i princippet. Svaret er ja. Som en første tilnærmelse synes jeg, at de opnåede tal er ret pålidelige.
Hvad der ellers kunne have været gjort, og hvad jeg var for doven til at gøre, var at tælle DNS-anmodninger. De er ikke filtreret, men de giver heller ikke meget nøjagtighed, da de kun virker for domænet, og ikke for hele URL'en. Frekvensen skal være synlig. Hvis du kombinerer det med det, der er synligt direkte i forespørgslerne, vil det give dig mulighed for at adskille det unødvendige og få mere information. Det er endda muligt at bestemme udviklerne af den DNS, der bruges af udbydere og meget mere.
Jeg havde absolut ikke forventet, at hosteren også ville inkludere sit eget filter til min VPS. Måske er dette almindelig praksis. I sidste ende sender RKN en anmodning om at slette ressourcen til hosteren. Men dette overraskede mig ikke og virkede på nogle måder endda til min fordel. Filtret fungerede meget effektivt og afskærede alle korrekte HTTP-anmodninger til en forbudt URL, men ikke korrekte, der tidligere var gået gennem udbydernes filter nåede dem, omend kun i form af endelser: FIN-ACK и RST - minus for minus og det viste sig næsten at være et plus. I øvrigt blev IPv6 ikke filtreret af hosteren. Det påvirkede naturligvis kvaliteten af det indsamlede materiale, men det gjorde det alligevel muligt at se frekvensen. Det viste sig, at dette er et vigtigt punkt, når du vælger et websted til at placere ressourcer; glem ikke at interessere dig for spørgsmålet om at organisere arbejdet med listen over forbudte websteder og anmodninger fra RKN.
I starten sammenlignede jeg AS "Inspektøren" med . Denne sammenligning er ganske berettiget, og et stort netværk af agenter kan være gavnligt. For eksempel at bestemme kvaliteten af ressourcetilgængeligheden fra forskellige udbydere i forskellige dele af landet. Du kan beregne forsinkelser, du kan bygge grafer, du kan analysere det hele og se ændringerne, der sker både lokalt og globalt. Dette er ikke den mest direkte måde, men astronomer bruger "standardlys", hvorfor ikke bruge Agenter? Når du kender (efter at have fundet) deres standardadfærd, kan du bestemme de ændringer, der sker omkring dem, og hvordan dette påvirker kvaliteten af de leverede tjenester. Og på samme tid behøver du ikke uafhængigt at placere sonder på netværket; Roskomnadzor har allerede installeret dem.
Et andet punkt, jeg vil berøre, er, at ethvert værktøj kan være et våben. AS "Inspektør" er et lukket netværk, men agenterne udleverer alle ved at sende anmodninger om alle ressourcer fra den forbudte liste. At have en sådan ressource giver ingen problemer overhovedet. I alt fortæller udbydere gennem Agenter ubevidst meget mere om deres netværk, end det nok er det værd: DPI- og DNS-typer, Agentens placering (central node og servicenetværk?), netværksmarkører for forsinkelser og tab - og dette er kun det mest åbenlyse. Ligesom nogen kan overvåge agenters handlinger for at forbedre tilgængeligheden af deres ressourcer, kan nogen gøre dette til andre formål, og der er ingen hindringer for dette. Resultatet er et tveægget og meget mangefacetteret instrument, det kan enhver se.
Kilde: www.habr.com