Det er ingen hemmelighed, at en automatiseret system kaldet "Revisor" overvåger blokeringer af forbudte oplysninger i Rusland. Hvordan det fungerer, er ret godt beskrevet i denne , billede fra den samme kilde:
Det er direkte hos udbyderen, at :
Modulet "Agent Revisor" er et strukturelt element i det automatiserede system "Revisor" (AS "Revisor"). Dette system er designet til at overvåge, at telecom-operatører overholder kravene til begrænsning af adgangen i overensstemmelse med bestemmelserne i artiklerne 15.1-15.4 i den føderale lov fra 27. juli 2006 nr. 149-FZ "Om information, informationsteknologier og beskyttelse af information".
Hovedmålet med oprettelsen af AS "Revisor" er at sikre overvågning af overholdelse af kravene, der er fastsat i artiklerne 15.1-15.4 i den føderale lov fra 27. juli 2006 nr. 149-FZ "Om information, informationsteknologier og beskyttelse af information", når det gælder identificering af fakta omkring adgang til forbudte oplysninger og indsamling af bekræftende materiale (data) om overtrædelser af adgangen til forbudte oplysninger.
I betragtning af at, hvis ikke alle, så mange udbydere har installeret denne enhed hos sig, burde der være dannet et stort netværk af "prøve-bøjer" ligesom og endda mere, men med lukket adgang. Men en bøje er stadig en bøje, som sender signaler i alle retninger, og hvad nu hvis vi fanger dem og ser, hvad vi har fanget og hvor meget?
Inden vi tæller, lad os se på, hvorfor dette overhovedet kan være muligt.
Lidt teori
Agenterne tjekker tilgængeligheden af ressourcen, blandt andet gennem HTTP(S) forespørgsler, som denne for eksempel:
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 Fundet"
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"
Forespørgslen ud over nyttelasten, består også af en fase for etablering af forbindelse: bytte SYN og SYN-ACK, og en fase for afslutning af forbindelsen: FIN-ACK.
Register for prohibited information contains several types of blocking. Obviously, if a resource is blocked by IP address or domain name, we will not see any requests. These are the most destructive types of blocks that lead to the inaccessibility of all resources on one IP address or all information on the domain. There is also a type of blocking "by URL". In this case, the filtering system must analyze the HTTP header of the request to accurately determine what to block. Before that, as mentioned above, a connection setup phase must occur, which can be tracked since most likely the filter will miss it.
To do this, you need to choose a suitable free domain with a "by URL" blocking type and HTTP to make the filtering system's job easier, preferably a long-abandoned one to minimize the entry of unrelated traffic except from Agents. This task turned out to be quite simple; there are many free domains in the register for prohibited information available and to suit every taste. Therefore, the domain was purchased and linked to IP addresses on a VPS with running tcpdump and the counting began.
Revision of the "Inspectors"
I expected to see periodic spikes in requests, which in my opinion would indicate a controlled action. I can't say that I didn't see this at all, but there was definitely no clear picture:
Which is not surprising; even on a completely unnecessary domain on an never-used IP, there will be a massive amount of unsolicited information coming in, such is the modern Internet. But fortunately, I only needed requests for a specific URL, so all scanners and password brute-forcers were quickly identified. It was also quite easy to understand where the flood of similar requests was coming from. Then I compiled the frequencies of IP addresses and manually reviewed the entire top, separating those who slipped through in the previous stages. Additionally, I cut out all sources that sent only one packet, there weren't many of them. And here is the result:
En lille lyrisk afstikker. Lidt mere end et døgn senere sendte min hostingudbyder et brev med ret vag indhold, der sagde, at der var ressourcer på jeres system, der var på den forbudte liste fra RKN, og derfor blev de blokeret. Først troede jeg, at de havde blokeret min konto, men det var ikke tilfældet. Så tænkte jeg, at jeg bare blev advaret om noget, jeg allerede vidste. Men det viste sig, at hosteren havde aktiveret sin filter før mit domæne, og i sidste ende blev jeg ramt af dobbelt filtrering: fra udbyderne og fra hosteren. Filteret tillod kun enden af forespørgselerne: FIN-ACK og RST og skar hele HTTP af for den forbudte URL. Som det fremgår af grafen ovenfor, begyndte jeg at modtage færre data efter de første 24 timer, men jeg modtog stadig data, hvilket var tilstrækkeligt til at tælle kilderne til forespørgslerne.
Nærmere bestemt. Efter min mening er det helt klart, at der er to toppe hver dag, den første mindre, efter midnat i Moskva tid, den anden tættere på kl. 6 om morgenen med en hale til kl. 12. Toppen falder ikke på præcis samme tidspunkt. Først ønskede jeg at isolere IP-adresserne, der kun faldt inden for disse perioder og hver i alle perioder, baseret på antagelsen om, at kontrollerne fra agenterne udføres periodisk. Men ved nærmere eftersyn opdagede jeg hurtigt perioder, der falder ind under andre intervaller, med andre frekvenser, helt ned til én forespørgsel hver time. Så tænkte jeg på tidszoner og, at det muligvis var årsagen, derefter overvejede jeg, at systemet slet ikke kunne være globalt synkroniseret. Derudover vil NAT helt sikkert spille en rolle, og den samme agent kan lave forespørgsler fra forskellige offentlige IP-adresser.
Da mit oprindelige mål ikke var nøjagtighed, har jeg talt alle adresser, der blev fanget i løbet af ugen, og har fået - 2791. Antallet af TCP-sessioner etableret fra én adresse er i gennemsnit 4, med en median på 2. Top sessioner på adresserne: 464, 231, 149, 83, 77. Maksimum fra 95% stikprøven — 8 sessioner per adresse. Medianen er ikke særlig høj, og jeg vil minde om, at grafen viser en tydelig daglig periodicitet, så det kunne forventes at være omkring 4 til 8 over 7 dage. Hvis man udelader alle sessioner, der kun optræder én gang, vil vi netop få en median der er lig med 5. Men jeg kunne ikke ekskludere dem på et klart kriterium. Tværtimod, stikprøvekontrollen viste, at de havde relation til forespørgsler om den forbudte ressource.
Adresser er én ting, men på internettet er autonome systemer – AS – vigtigere, og der er blevet skabt 1510, i gennemsnit 2 adresser pr. AS med medianen 1. Topadresserne på AS: 288, 77, 66, 39, 27. Maksimum fra 95% af prøven – 4 adresser pr. AS. Her er medianen forventet – én Agent pr. udbyder. Toppen er også forventet – den indeholder store spillere. I et stort netværk bør Agenterne være til stede i hver region, hvor operatøren er til stede, og vi skal ikke glemme NAT. Hvis vi ser på lande, vil maksimum være: 1409 – RU, 42 – UA, 23 – CZ, 36 fra andre regioner, som ikke er RIPE NCC. Forespørgsler, der ikke kommer fra Rusland, tiltrækker opmærksomhed. Dette kan måske forklares med fejl i geolokaliseringen eller fejl fra registratorer ved udfyldelse af data. Eller at en russisk virksomhed måske har ikke-russiske rødder eller en udenlandsk repræsentation, fordi det er lettere, især når man har at gøre med den udenlandske organisation RIPE NCC. En del er uden tvivl overflødig, men det er svært at adskille den præcist, da ressourcen er under blokering, og fra den anden dag er der dobbelt blokering, og de fleste sessioner består kun af udveksling af et par administrative pakker. Lad os være enige om, at dette er en lille del.
Disse tal kan allerede sammenlignes med antallet af udbydere i Rusland. er der 6387 licenser til 'Tjenester til datatransmission, undtagen stemme' – men det er en stærkt overvurderet estimat, da ikke alle disse licenser gælder specifikt for internetudbydere, der skal have en Agent. I RIPE NCC-området er der et lignende antal AS registreret i Rusland – 6230, hvoraf ikke alle er udbydere. og fandt 3940 virksomheder i 2017, og dette er sandsynligvis et overvurderet tal. Under alle omstændigheder har vi et antal synlige AS, der er to og en halv gang mindre. Men her er det vigtigt at forstå, at AS ikke er strengt lig med udbyder. Nogle udbydere har ikke deres egne AS, mens andre har mere end én. Hvis vi antager, at Agenterne trods alt er til stede hos alle, betyder det, at nogle filtrerer strengere end andre, så deres forespørgsler er uadskillelige fra støj, hvis de overhovedet når frem. Men for et groft estimat er det ret acceptabelt, selv hvis der er gået noget tabt på grund af min fejl.
Om DPI
Selvom min hostingudbyder aktivere sin filter fra den anden dag, kan man på baggrund af informationerne fra den første dag konstatere, at blokeringerne fungerer effektivt. Kun 4 kilder formåede at trænge igennem og har fuldt afsluttede HTTP- og TCP-sessioner (som i eksemplet ovenfor). Endnu 460 kan sende GET, men sessionen brydes straks ved RST. Bemærk venligst 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"
#Dette blev sendt af filteret
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#Og dette er forsøget fra kilden for at få tab
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"
#Kilden forstår, at sessionen er brudt
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Variationerne kan være forskellige: færre RST eller flere retransmissioner — det afhænger også af, hvad filteret sender til kilden. Under alle omstændigheder er dette den mest pålidelige skabelon, som viser, at der blev anmodet om en forbudt ressource. Desuden er der altid et svar, der dukker op i sessionen med TTL mere end i de tidligere og efterfølgende pakker.
Fra de andre kan man ikke engang se GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Dette blev sendt af filteret
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Eller sådan her:
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"
#Dette blev sendt af filteret
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"
#Igen filteret, mange gange
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Forskellen er bestemt synlig i TTL hvis noget kommer fra filteret. Men ofte kan der slet ikke komme noget:
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ådan her:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Der er gået flere sekunder uden trafik
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Og alt dette gentages og gentages og gentages, som man kan se på grafen, bestemt ikke kun én gang, hver dag.
Om IPv6
Den gode nyhed er, at den findes. Jeg kan med sikkerhed sige, at der fra 5 forskellige IPv6-adresser sker periodiske forespørgsler til det forbudne resource, nøjagtig det adfærdsmønster jeg forventede fra agenterne. Desuden falder en af IPv6-adresserne ikke under filtreringen, og jeg kan se en fuld session. Derudover så jeg kun en enkelt ufuldstændig session fra to andre, hvoraf den ene blev afbrudt af RST filtreringen, den anden på grund af tidsbegrænsning. I alt er der 7.
Fordi der er få adresser, har jeg undersøgt dem alle i detaljer, og det viste sig, at der faktisk kun er 3 udbydere, som man kan applaudere stående! Den ene adresse tilhører en cloud-hosting i Rusland (som ikke filtrerer), og den anden tilhører et forskningscenter i Tyskland (hvor der er filtrering, hen?). Det er et interessant spørgsmål, hvorfor de tjekker tilgængeligheden af forbudne ressourcer efter en tidsplan. De to resterende lavede hver især en forespørgsel og befinder sig uden for Rusland, og en af dem filtreres (måske i transit?).
Filtrering og agenter er en stor hindring for IPv6, hvis implementering i forvejen ikke går særlig hurtigt. Det er trist. Dem, der har løst denne opgave fuldt ud, kan virkelig være stolte af sig selv.
Afslutningsvis
Jeg har ikke jagtet 100% nøjagtighed, og jeg beder om undskyldning for det; jeg håber, at nogen vil ønske at gentage dette arbejde med større grundighed. For mig var det vigtigt at forstå, om denne tilgang overhovedet vil fungere. Svaret er – ja. De tal, jeg har fået, er i første omgang, hvad jeg mener, ganske pålidelige.
Hvad kunne man ellers have gjort, og hvad jeg ikke gad gøre – tælle forespørgsler til DNS. De bliver ikke filtreret, men giver heller ikke særlig stor nøjagtighed, da de kun fungerer for domænet og ikke for hele URL'en. Det burde være muligt at se periodisiteten. Hvis man kombinerer det med det, der direkte kan ses i forespørgslerne, kan det hjælpe med at adskille det unødvendige og få mere information. Det kan endda muligvis afsløre udviklerne af de DNS-servere, der bruges af udbyderne, og meget mere.
Jeg havde slet ikke forventet, at min VPS-udbyder også ville aktivere sin egen filtrering. Måske er det en almindelig praksis. I sidste ende sender RKN en anmodning om at fjerne ressourcen direkte til udbyderen. Men det overraskede mig ikke og endda hjalp mig på en måde. Filtreringen fungerede meget effektivt ved at skære alle korrekte HTTP-forespørgsler til den forbudte URL, men de forkerte, som tidligere gik igennem udbyderens filtrering, nåede frem, omend kun i form af ender: FIN-ACK og RST — minus på minus og næsten plus. For øvrigt er IPv6-hosting ikke blevet filtreret. Dette har selvfølgelig påvirket kvaliteten af det indsamlede materiale, men det gav alligevel mulighed for at se periodiskheden. Det viste sig at være et vigtigt aspekt ved valget af platform til hosting af ressourcer, så glem ikke at spørge ind til arbejdet med lister over forbudte websteder og anmodninger fra RKN.
I starten sammenlignede jeg AS "Revisor" med . Denne sammenligning er fuldt berettiget, og et stort netværk af agenter kan være til gavn. For eksempel kan man bestemme kvaliteten af tilgængeligheden af ressourcen fra forskellige internetudbydere i forskellige dele af landet. Man kan beregne forsinkelser, man kan lave grafer, man kan analysere alt dette og se ændringer både lokalt og globalt. Det er ikke den mest direkte metode, men astronomer bruger jo "standardlys", hvorfor ikke bruge agenter? Ved at kende (finde) deres standardopførsel kan man bestemme ændringerne omkring dem og hvordan dette påvirker kvaliteten af de leverede ydelser. Og samtidig behøver man ikke selv at placere måleapparater i netværket, det har Roskomnadzor allerede gjort.
En anden ting, jeg ønsker at berøre, er, at hvert værktøj kan være et våben. AS "Revisor" er et lukket netværk, men agenterne afslører alt om sig selv ved at sende anmodninger til alle ressourcer fra den forbudte liste. At få fat i en sådan ressourcer i sig selv repræsenterer slet ikke nogen problemer. I alt fortæller udbyderne gennem agenterne, uden at de ønsker det, meget mere om deres netværk, end man måske skulle tro: typer af DPI og DNS, agentens placering (centralnode og tjenestenetværk?), netværkets markører for forsinkelser og tab - og det er kun det mest åbenlyse. Ligesom nogen kan overvåge agenternes handlinger for at forbedre tilgængeligheden af deres ressourcer, kan nogen gøre det af andre grunde, og der er ingen forhindringer for dette. Det er blevet et todelt og meget multifacetteret værktøj, som enhver kan overbevise sig om.
Kilde: habr.com
