Det er ingen hemmelighet at kontrollen av blokkering på listen over forbudt informasjon i Russland overvåkes av det automatiserte systemet "Inspector". Hvordan det fungerer står godt skrevet her i denne , bilde fra samme sted:
Installeres direkte hos leverandøren :
"Agent Inspector"-modulen er et strukturelt element i det automatiserte systemet "Inspector" (AS "Inspector"). Dette systemet er utformet for å overvåke overholdelse av teleoperatører med krav til tilgangsbegrensninger innenfor rammen av bestemmelsene fastsatt av artikkel 15.1-15.4 i føderal lov av 27. juli 2006 nr. 149-FZ “On Information, Information Technologies and Information Protection. ”
Hovedformålet med å opprette AS "Revizor" er å sikre overvåking av teleoperatørers etterlevelse av kravene fastsatt av artikkel 15.1-15.4 i føderal lov av 27. juli 2006 nr. 149-FZ "On Information, Information Technologies and Information" Beskyttelse" i form av å identifisere fakta om tilgang til forbudt informasjon og innhenting av støttemateriale (data) om brudd for å begrense tilgangen til forbudt informasjon.
Tatt i betraktning det faktum at, om ikke alle, så mange leverandører har installert denne enheten, burde det ha vært et stort nettverk av beacon-prober som og enda mer, men med lukket tilgang. Imidlertid er et beacon et beacon for å sende signaler i alle retninger, men hva om vi fanger dem og ser hva vi fanget og hvor mange?
Før vi teller, la oss se hvorfor dette til og med er mulig.
Litt teori
Agenter sjekker tilgjengeligheten til en ressurs, inkludert gjennom HTTP(S)-forespørsler, 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"
I tillegg til nyttelasten består forespørselen også av en forbindelsesetableringsfase: utveksling SYN и SYN-ACK, og tilkoblingsfullføringsfaser: FIN-ACK.
Registeret over forbudte opplysninger inneholder flere typer sperring. Selvfølgelig, hvis en ressurs er blokkert av IP-adresse eller domenenavn, vil vi ikke se noen forespørsler. Dette er de mest destruktive typene blokkering, som fører til utilgjengelighet for alle ressurser på én IP-adresse eller all informasjon på et domene. Det er også en blokkeringstype "etter URL". I dette tilfellet må filtreringssystemet analysere HTTP-forespørselshodet for å bestemme nøyaktig hva som skal blokkeres. Og før det, som du kan se ovenfor, bør det være en tilkoblingsetableringsfase som du kan prøve å spore, siden mest sannsynlig vil filteret savne det.
For å gjøre dette, må du velge et passende gratis domene med "URL"- og HTTP-blokkeringstypen for å lette arbeidet med filtreringssystemet, fortrinnsvis lenge forlatt, for å minimere tilgangen til fremmed trafikk unntatt fra agenter. Denne oppgaven viste seg ikke å være vanskelig i det hele tatt; det er ganske mange gratis domener i registeret over forbudt informasjon og for enhver smak. Derfor ble domenet kjøpt og knyttet til IP-adresser på en VPS som kjører tcpdump og tellingen begynte.
Revisjon av "revisorer"
Jeg forventet å se periodiske utbrudd av forespørsler, som etter min mening ville indikere kontrollert handling. Det er umulig å si at jeg ikke så det i det hele tatt, men det var definitivt ikke noe klart bilde:
Noe som ikke er overraskende, selv på et domene som ingen trenger og på en aldri brukt IP, vil det ganske enkelt være massevis av uønsket informasjon, slik er det moderne Internett. Men heldigvis trengte jeg bare forespørsler om en bestemt URL, så alle skannere og passordknekkere ble raskt funnet. Dessuten var det ganske enkelt å forstå hvor flommen var basert på massen av lignende forespørsler. Deretter kompilerte jeg frekvensen av forekomst av IP-adresser og gikk gjennom hele toppen manuelt, og skilte de som gikk glipp av det i de forrige stadiene. I tillegg kuttet jeg ut alle kildene som ble sendt i én pakke, det var ikke mange av dem lenger. Og dette er hva som skjedde:
En liten lyrisk digresjon. Litt mer enn et døgn senere sendte hostingleverandøren min et brev med et ganske strømlinjeformet innhold, der de sa at fasilitetene dine inneholder en ressurs fra RKNs forbudsliste, så den er blokkert. Først trodde jeg at kontoen min var blokkert, dette var ikke tilfelle. Da tenkte jeg at de rett og slett advarte meg om noe jeg allerede visste om. Men det viste seg at hosteren slo på filteret sitt foran domenet mitt og som et resultat kom jeg under dobbel filtrering: fra leverandørene og fra hosteren. Filteret passerte bare slutten av forespørslene: FIN-ACK и RST kutte av all HTTP på en forbudt URL. Som du kan se fra grafen over, begynte jeg etter den første dagen å motta mindre data, men jeg mottok det fortsatt, noe som var nok for oppgaven med å telle forespørselskilder.
Kom til poenget. Etter min mening er to utbrudd tydelig synlige hver dag, den første mindre, etter midnatt i Moskva-tid, den andre nærmere 6 med en hale til kl. 12. Toppen inntreffer ikke akkurat samtidig. Til å begynne med ønsket jeg å velge IP-adresser som falt bare i disse periodene og hver i alle perioder, basert på antagelsen om at kontroller av agenter utføres med jevne mellomrom. Men etter nøye gjennomgang oppdaget jeg raskt perioder som falt i andre intervaller, med andre frekvenser, opptil én forespørsel hver time. Så tenkte jeg på tidssoner og at det kanskje hadde noe med dem å gjøre, så tenkte jeg at generelt sett var kanskje ikke systemet synkronisert globalt. I tillegg vil trolig NAT spille en rolle og samme Agent kan komme med forespørsler fra forskjellige offentlige IP-er.
Siden mitt opprinnelige mål ikke var akkurat, telte jeg alle adressene jeg kom over i løpet av en uke og fikk - 2791. Antall TCP-sesjoner etablert fra én adresse er i gjennomsnitt 4, med en median på 2. Toppsesjoner per adresse: 464, 231, 149, 83, 77. Maksimum fra 95 % av utvalget er 8 økter per adresse. Medianen er ikke særlig høy, la meg minne om at grafen viser en tydelig daglig periodisitet, så man kan forvente noe rundt 4 til 8 på 7 dager. Hvis vi kaster ut alle øktene som skjer én gang, vil vi få en median lik 5. Men jeg kunne ikke utelukke dem ut fra et klart kriterium. Tvert imot viste en stikkprøvekontroll at de var knyttet til forespørsler om en forbudt ressurs.
Adresser er adresser, men på Internett, autonome systemer - AS, som viste seg å være viktigere 1510, i gjennomsnitt 2 adresser per AS med en median på 1. Toppadresser per AS: 288, 77, 66, 39, 27. Maksimalt 95 % av utvalget er 4 adresser per AS. Her forventes medianen - én Agent per leverandør. Vi forventer også toppen – det er store aktører i det. I et stort nettverk bør agenter sannsynligvis være lokalisert i hver region av operatørens tilstedeværelse, og ikke glem NAT. Hvis vi tar det etter land, vil maksimumsverdiene være: 1409 - RU, 42 - UA, 23 - CZ, 36 fra andre regioner, ikke RIPE NCC. Forespørsler fra utenfor Russland vekker oppmerksomhet. Dette kan trolig forklares med geolokaliseringsfeil eller registrarfeil ved utfylling av data. Eller det faktum at et russisk selskap kanskje ikke har russiske røtter, eller har et utenlandsk representasjonskontor fordi det er enklere, noe som er naturlig når man har å gjøre med en utenlandsk organisasjon RIPE NCC. En del er utvilsomt overflødig, men det er pålitelig vanskelig å skille den, siden ressursen er under blokkering, og fra den andre dagen under dobbel blokkering, og de fleste økter er bare en utveksling av flere tjenestepakker. La oss bli enige om at dette er en liten del.
Disse tallene kan allerede sammenlignes med antall leverandører i Russland. lisenser for "Kommunikasjonstjenester for dataoverføring, unntatt tale" - 6387, men dette er et veldig høyt estimat ovenfra, ikke alle disse lisensene gjelder spesifikt for Internett-leverandører som trenger å installere en agent. I RIPE NCC-sonen er det et tilsvarende antall ASer registrert i Russland - 6230, hvorav ikke alle er leverandører. og mottok 3940 bedrifter i 2017, og dette er snarere et anslag ovenfra. Uansett har vi to og en halv ganger færre antall opplyste AS. Men her er det verdt å forstå at AS strengt tatt ikke er lik tilbyderen. Noen tilbydere har ikke eget AS, noen har mer enn ett. Hvis vi antar at alle fortsatt har agenter, filtrerer noen sterkere enn andre, slik at forespørslene deres ikke kan skilles fra søppel, hvis de i det hele tatt når dem. Men for en grov vurdering er det ganske tålelig, selv om noe gikk tapt på grunn av min forglemmelse.
Om DPI
Til tross for at vertsleverandøren min slo på filteret fra den andre dagen, kan vi basert på informasjonen fra den første dagen konkludere med at blokkeringen fungerer vellykket. Bare 4 kilder klarte å komme gjennom og har fullført HTTP- og TCP-økter (som i eksempelet ovenfor). En annen 460 kan sendes GET, men økten avsluttes umiddelbart av RST. Følg med 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"
Variasjoner av dette kan være forskjellige: mindre RST eller flere retransmitter - avhenger også av hva filteret sender til kildenoden. Uansett er dette den mest pålitelige malen, hvorfra det er klart at det var en forbudt ressurs som ble etterspurt. Pluss at det alltid er et svar som dukker opp i økten med TTL større enn i tidligere og påfø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"
...
Forskjellen er definitivt synlig TTL hvis det kommer noe fra filteret. Men ofte kan ingenting komme i det hele tatt:
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 gjentas og gjentas og gjentas, som man kan se på grafen, mer enn én gang, hver dag.
Om IPv6
Den gode nyheten er at den eksisterer. Jeg kan pålitelig si at periodiske forespørsler til en forbudt ressurs skjer fra 5 forskjellige IPv6-adresser, som er nøyaktig oppførselen til agentene jeg forventet. Dessuten faller ikke en av IPv6-adressene under filtrering, og jeg ser en full økt. Fra to til så jeg bare en uferdig økt, hvorav den ene ble avbrutt av RST fra filteret, nummer to i tid. Totale mengden 7.
Siden det er få adresser, studerte jeg dem alle i detalj, og det viste seg at det bare er 3 tilbydere der, de kan få stående applaus! En annen adresse er skyhosting i Russland (filtrerer ikke), en annen er et forskningssenter i Tyskland (det finnes et filter, hvor?). Men hvorfor sjekker de tilgjengeligheten av forbudte ressurser på en tidsplan er et godt spørsmål. De resterende to kom med én forespørsel og befinner seg utenfor Russland, og en av dem er filtrert (i transitt, tross alt?).
Blokkering og agenter er en stor hindring for IPv6, hvis implementering ikke går veldig raskt. Det er trist. De som løste dette problemet kan være fullt stolte av seg selv.
i konklusjonen
Jeg strevde ikke etter 100% nøyaktighet, vennligst tilgi meg for dette, jeg håper noen ønsker å gjenta dette arbeidet med større nøyaktighet. Det var viktig for meg å forstå om denne tilnærmingen ville fungere i prinsippet. Svaret er ja. De oppnådde tallene, som en første tilnærming, tror jeg, er ganske pålitelige.
Hva annet kunne vært gjort og det jeg var for lat til å gjøre var å telle DNS-forespørsler. De er ikke filtrert, men de gir heller ikke mye nøyaktighet siden de kun fungerer for domenet, og ikke for hele URL-en. Frekvensen skal være synlig. Hvis du kombinerer det med det som er synlig direkte i spørringene, vil dette tillate deg å skille ut det unødvendige og få mer informasjon. Det er til og med mulig å bestemme utviklerne av DNS som brukes av leverandører og mye mer.
Jeg hadde absolutt ikke forventet at hosteren også ville inkludere et eget filter for min VPS. Kanskje dette er vanlig praksis. Til slutt sender RKN en forespørsel om å slette ressursen til hosteren. Men dette overrasket meg ikke og fungerte på noen måter til og med til min fordel. Filteret fungerte veldig effektivt, og kuttet av alle korrekte HTTP-forespørsler til en forbudt URL, men ikke korrekte som tidligere hadde passert gjennom leverandørens filter nådde dem, om enn bare i form av endelser: FIN-ACK и RST - minus for minus og det viste seg nesten å være et pluss. Forresten, IPv6 ble ikke filtrert av hosteren. Dette påvirket selvfølgelig kvaliteten på det innsamlede materialet, men det gjorde det likevel mulig å se frekvensen. Det viste seg at dette er et viktig poeng når du velger et nettsted for å plassere ressurser; ikke glem å interessere deg for spørsmålet om organisering av arbeid med listen over forbudte nettsteder og forespørsler fra RKN.
I begynnelsen sammenlignet jeg AS «Inspektøren» med . Denne sammenligningen er ganske berettiget, og et stort nettverk av agenter kan være fordelaktig. For eksempel å bestemme kvaliteten på ressurstilgjengeligheten fra ulike leverandører i ulike deler av landet. Du kan beregne forsinkelser, du kan bygge grafer, du kan analysere alt og se endringene som skjer både lokalt og globalt. Dette er ikke den mest direkte måten, men astronomer bruker "standardlys", hvorfor ikke bruke Agenter? Når du kjenner (etter å ha funnet) standardatferden deres, kan du bestemme endringene som skjer rundt dem og hvordan dette påvirker kvaliteten på tjenestene som tilbys. Og samtidig trenger du ikke å plassere sonder uavhengig på nettverket; Roskomnadzor har allerede installert dem.
Et annet punkt jeg vil berøre er at hvert verktøy kan være et våpen. AS «Inspektør» er et lukket nettverk, men Agentene overleverer alle ved å sende forespørsler om alle ressurser fra forbudslisten. Å ha en slik ressurs byr på ingen problemer i det hele tatt. Totalt sett forteller tilbydere gjennom Agenter, uforvarende, mye mer om nettverket sitt enn det sannsynligvis er verdt det: DPI- og DNS-typer, plassering av Agenten (sentral node og tjenestenettverk?), nettverksmarkører for forsinkelser og tap - og dette er bare det mest åpenbare. Akkurat som noen kan overvåke handlingene til agenter for å forbedre tilgjengeligheten til ressursene deres, kan noen gjøre dette til andre formål, og det er ingen hindringer for dette. Resultatet er et tveegget og svært mangefasettert instrument, dette kan alle se.
Kilde: www.habr.com