Prebrojavanje agenata 'Revizor'

Ni je skrivnost, da nadzor nad blokadami prepovedanih informacij v Rusiji izvaja avtomatiziran sistem „Revizor“. Kako to deluje, je dobro opisano v tem članku na Habr, slika pa je prav tako od tam:

Pri ponudniku storitev se namesti modul „Agent Revizor“:

Modul „Agent Revizor“ je strukturni element avtomatiziranega sistema „Revizor“ (AS „Revizor“). Ta sistem je namenjen nadzoru izpolnjevanja zahtev, ki jih morajo izpolnjevati operaterji telekomunikacij v okviru določb, ki jih določa Zakon z dne 27. julija 2006 št. 149-FZ „O informacijah, informacijskih tehnologijah in o zaščiti informacij“.

Glavni namen vzpostavitve AS „Revizor“ je zagotavljanje nadzora nad spoštovanjem zahtev, določenih v členih 15.1-15.4 zakona z dne 27. julija 2006 št. 149-FZ „O informacijah, informacijskih tehnologijah in o zaščiti informacij“, v delu ugotavljanja dejstev dostopa do prepovedanih informacij in pridobivanja potrjevalnih materialov (podatkov) o kršitvah glede omejevanja dostopa do prepovedanih informacij.

Glede na to, da so mnogi ponudniki že namestili to napravo, bi morala nastati obsežna mreža posnemovalcev-signalov, ki spominjajo na RIPE Atlas in še več, vendar z omejenim dostopom. Vendar pa je signal in ostaja signal, da pošilja signale vse smeri; ampak kaj, če jih ujamemo in pogledamo, kaj smo ujeli in koliko?

Preden začnemo šteti, si oglejmo, zakaj je to sploh lahko mogoče.

Nekaj teorije

Agenti preverjajo dostopnost virov, tudi s pomočjo HTTP(S) zahtevkov, kot je ta, na primer:

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"

Zahteva poleg uporabne obremenitve zajema tudi fazo vzpostavitve povezave: izmenjava SYN in SYN-ACK, in fazo zaključka povezave: FIN-ACK.

Seznam prepovedanih informacij vsebuje več vrst blokad. Očitno je, da če bo vir blokiran po IP naslovu ali domeni, ne bomo videli nobenih zahtevkov. To so najpogostejše in najbolj uničujoče vrste blokad, ki povzročajo nedostopnost vseh virov na enem IP naslovu ali vseh informacij na domeni. Obstaja tudi vrsta blokade "po URL-ju". V tem primeru mora sistem filtriranja analizirati HTTP glavo zahteve, da natančno določi, kaj blokirati. Pred tem, kot je razvidno zgoraj, mora potekati faza vzpostavitve povezave, ki jo lahko poskusimo zaznati, saj bo najverjetneje filter to spustil.

Zato je treba izbrati primeren prost domen z vrsto blokade "po URL-ju" in HTTP, da se olajša delo sistemu filtriranja, najbolje bi bilo, da gre za dolgo zapuščen domen, da se zmanjša prehod nepovezanega prometa, razen Agentov. Ta naloga se je izkazala za povsem preprosto, prostih domen v registru prepovedanih informacij je dovolj in so na voljo v različnih okusih. Zato je bil domen kupljen, povezan z IP naslovi na VPS s tečeče tcpdump in začeli smo s štetjem.

Revizija "Revizorjev"

Pričakoval sem, da bom videl občasne izbruhe zahtevkov, kar bi po mojem mnenju kazalo na nadzorovano dejanje. Ne morem reči, da tega sploh nisem videl, toda jasne slike zagotovo ni bilo:

Kar ni presenetljivo, celo na nikogaršnje domene na nikoli uporabljeni IP naslov bo prihajalo ogromno nepovprašanih informacij, takšen je sodobni internet. A na srečo, potreboval sem le zahtevke za določen URL, zato so bili vsi skenerji in preverjevalci gesel hitro najdeni. Prav tako je bilo dovolj preprosto razumeti, kje je bil mrk zaradi množice enotnih zahtevkov. Nato sem sestavil frekvence pojavljanja IP naslovov in ročno šel skozi vse na vrhu, ločujem tiste, ki so ušli na prejšnjih stopnjah. Poleg tega sem odstranil vse vire, ki so poslali samo en paket, njih je bilo že malo. In rezultat je bil to:

Kratka lirična digresija. Više od jednog dana kasnije, moj hosting provajder poslao je pismo prilično obazrivog sadržaja, rekavši da na vašim resursima postoji sadržaj sa zabrinjavajuće liste, zbog čega se blokira. Prvo sam pomislio da su blokirali moj račun, što nije bio slučaj. Tada sam mislio da me samo upozoravaju na nešto što već znam. Ali se ispostavilo da je hoster uključio svoj filter pre mog domena i na kraju sam pao pod dvostruku filtraciju: sa strane provajdera i sa strane hostera. Filter je propuštao samo krajeve zahteva: FIN-ACK in RST sečuvajući ceo HTTP po zabranjenom URL-u. Kao što se može videti iz gornjeg grafikona, nakon prvog dana sam primetio manji protok podataka, ali sam ih i dalje dobijao, što je bilo dovoljno za zadatak prebrojavanja izvora zahteva.

Malo bliže suštini. Po mom mišljenju, jasno se vide dva vrhunca svaki dan, prvi manji, posle ponoći po Moskvi, drugi bliže 6 ujutro sa repom do 12 popodne. Vrh ne dolazi tačno u isto vreme. Prvo sam hteo da izdvojim IP adrese koje se pojavljuju samo u tim periodima i svaku u svim periodima, polazeći od pretpostavke da Agenti rade provere periodično. Međutim, pregledom sam brzo otkrio periodičnosti koje pokrivaju druge intervale, sa različitim frekvencijama, čak i do jednog zahteva svaka sat. Potom sam razmišljao o vremenskim zonama i da je možda do njih, a zatim sam pomislio da cijeli sistem možda nije globalno sinhronizovan. Osim toga, sigurno, svoju ulogu igra NAT i jedan te isti Agent može slati zahteve sa različitih javnih IP.

Budući da moj izvorni cilj nije bio preciznost, prebrojao sam sve adrese koje su se pojavile tokom nedelje i dobio - 2791. Broj TCP sesija uspostavljenih sa jedne adrese u proseku je 4, sa medijanom 2. Top sesija na adresi: 464, 231, 149, 83, 77. Maksimum iz 95% uzorka — 8 sesija na adresu. Medijana nije baš visoka, podsećam da na grafiku postoji jasna dnevna periodicnost, pa se moglo očekivati nešto između 4 do 8 za 7 dana. Ako isključimo sve jedinstvene sesije, dobićemo medijanu koja je jednaka 5. Međutim, nisam mogao da ih isključim na osnovu jasnih kriterijuma. Naprotiv, uzorkovanje je pokazalo da one imaju veze sa zahtevima zabranjenog resursa.

Naslov je naslov, a na Internetu su važniji autonomni sustavi — AS, kojih je došlo 1510, u prosjeku 2 adrese po AS s medijanom 1. Top adresa po AS: 288, 77, 66, 39, 27. Maksimum iz 95% uzorka — 4 adrese po AS. Ovdje je medijana očekivana — jedan Agent po davatelju usluga. Top je također očekivan — tu su veliki igrači. U velikoj mreži, Agenti bi mogli stajati u svakoj regiji prisutnosti operatora, ne zaboravljajući ni na NAT. Ako pogledamo prema zemljama, maksimumi će biti: 1409 — RU, 42 — UA, 23 — CZ, 36 iz drugih regija, ne RIPE NCC. Upiti koji nisu iz Rusije privlače pažnju. Možda to možemo objasniti greškama u geolokaciji ili greškama registratora prilikom popunjavanja podataka. Ili tim da ruska tvrtka može imati neruske korijene, ili imati strano predstavništvo jer je tako lakše, što je prirodno kada se radi sa stranom organizacijom RIPE NCC. Neki dio je nesumnjivo suvišan, ali je teško to točno odvojiti jer je resurs pod blokadom, a od drugih dana pod dvostrukom blokadom i većina sesija predstavljaju samo razmjenu nekoliko kontrolnih paketa. Dogovorimo se da je to mali dio.

Te brojke se već mogu usporediti s brojem davatelja usluga u Rusiji. Prema podacima RKN licencija za "Usluge komunikacije za prijenos podataka, osim glasa" — 6387, ali to je jako pretjerana procjena, ne pripadaju sve te licence upravo davateljima internet usluga kojima je potreban Agenti. U zoni RIPE NCC slično je broj AS registriranih u Rusiji — 6230, od kojih nisu svi davatelji usluga. UserSide je napravio rigorozniji izračun i dobio 3940 tvrtki u 2017. godini, i to je zapravo vjerojatno pretjerana procjena. U svakom slučaju, imamo broj prikazanih AS koji je dva i pol puta manji. No ovdje treba razumjeti da AS nije strogo jednako davatelju. Neki davatelji nemaju svoj AS, neki imaju više od jednog. Ako pretpostavimo da Agenti ipak stoje kod svih, to znači da netko filtrira jače od ostalih, tako da su njihovi upiti neprepoznatljivi kao smeće, ako uopće stignu. No za grubu procjenu, potpuno je prihvatljivo, čak i ako je nešto izgubljeno zbog moje greške.

O DPI

Čeprav je moj ponudnik gostovanja vključil svoj filter od drugega dne, se iz informacij prvega dne lahko izvede, da blokade uspešno delujejo. Le 4 viri so uspeli preiti in imajo popolnoma zaključene HTTP in TCP seje (kot v zgornjem primeru). Še 460 jih lahko pošlje GET, vendar se seja takoj pretrga po RST. Pozorite na 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"

#To je poslalo filtr
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"

HTTP, "HTTP/1.1 302 Found"

#In to je poskus izvorne vozlišča, da pridobi izgubo
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"

#Izvorno vozlišče razume, da je seja uničena
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"

Variacije tega so lahko različne: manj RST ali več ponovitev — odvisno je tudi od tega, kaj filter pošlje izvoru. V vsakem primeru je to najbolj zanesljiv vzorec, iz katerega je jasno, da je bil zahtevan prav prepovedan vir. Poleg tega je vedno prisoten odgovor, ki se pojavi v seji z TTL več kot v prejšnjih in naslednjih paketih.

Od ostalih ni videti niti GET:

TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"

#To je poslalo filtr
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"

Ali pa tako:

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"

#To je poslalo filtr
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"

#Spet filtr, večkrat
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...

Razlika je zagotovo vidna v TTL če kaj prispe od filtra. A redko morda ne prispe nič:

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"
...

Ali pa tako:

TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"

#Minilo se je nekaj sekund brez prometa

TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...

In vse to se ponavlja, kot je vidno na grafu, prav zagotovo ne enkrat, vsak dan.

O IPv6

Dobra novica - to je. Zanesljivo lahko povem, da iz 5 različnih IPv6 naslovov prihajajo občasni zahtevki do prepovedanega vira, prav to vedenje Agentov je bilo tisto, kar sem pričakoval. Poleg tega en od IPv6 naslovov ne pade pod filtriranje in vidim popolno sejo. Še z dveh sem videl le po eno nedokončano sejo, ena od teh je bila prekinjena zaradi RST filtra, druga zaradi časa. Skupaj torej 7.

Ker je naslovov malo, sem jih podrobno preučil in se izkazalo, da je tam dejansko le 3 ponudnike, ki si zaslužijo aplavz! Še en naslov - oblačno gostovanje v Rusiji (ne filtrira), še en - raziskovalni center v Nemčiji (je filter, kje?). A zakaj preverjajo razpoložljivost prepovedanih virov po urniku, je dobro vprašanje. Preostala dva sta naredila po en zahtevek in se nahajata zunaj meja Rusije, pri čemer se eden od njiju filtrira (konec koncev na tranzitu?).

Blokade in Agenti so velik zavor za IPv6, katerega uvajanje že tako napreduje počasi. To je žalostno. Tisti, ki so se odločili rešiti to nalogo v celoti, se lahko ponosno pohvalijo.

Na záver

Nisem stremel k 100% natančnosti, oprostite mi to, upam, da bo nekdo želel ponoviti to delo z večjo natančnostjo. Zame je bilo pomembno razumeti, ali bo tak pristop sploh deloval. Odgovor - bo. Pridobljene številke so na prvi pogled, mislim, povsem zanesljive.

Kaj bi še lahko naredil in kar sem se vzel za leno - prešteti zahtevke za DNS. Ti niso filtrirani, a tudi ne dajejo velike natančnosti, saj delujejo samo za domeno, ne pa za celoten URL. Periodičnost bi morala biti vidna. Če to združimo s tistim, kar je jasno iz zahtevkov, bo to omogočilo ločiti odveč in pridobiti več informacij. Mogoče celo določiti razvijalce DNS, ki jih uporabljajo ponudniki, in še marsikaj drugega.

Nisem si prav nič predstavljal, da bo moj VPS gostitelj vključil še svoj filter. Morda je to običajna praksa. Na koncu koncev RKN pošlje zahtevo za odstranitev vira prav gostitelju. A me to ni presenetilo in celo nekje koristilo. Filter je deloval zelo učinkovito, blokirajoč vse pravilne HTTP zahteve za prepovedani URL, vendar so nepravilne, ki so pred tem prišle skozi filtriranje ponudnikov, prišle do konca: FIN-ACK in RST — minus plus and almost resulted in a plus. By the way, the IPv6 host was not filtered. Of course, this affected the quality of the collected data, but it still allowed us to see the periodicity. This turned out to be an important factor when choosing a platform for placing resources; don't forget to inquire about the organization of work with the list of banned sites and requests from the Federal Service for Supervision of Communications, Information Technology and Mass Media.

At the beginning, I compared AS "Revizor" with RIPE Atlas. This comparison is quite justified, and a large network of Agents can be beneficial. For example, determining the availability quality of a resource from various providers across different parts of the country. You can calculate delays, build graphs, analyze everything, and observe changes happening both locally and globally. This is not the most direct path, but astronomers use “standard candles”; why not use Agents? Knowing (or finding) their standard behavior can help identify changes occurring around them and how this affects the quality of services provided. Moreover, there's no need to independently place probes in the network; Roskomnadzor has already done that.

Another point I want to touch upon is that every tool can be a weapon. AS "Revizor" is a closed network, but Agents expose everything by sending requests to all resources from the banned list. Acquiring such a resource poses absolutely no problems. In total, providers through Agents, without wanting to, disclose much more about their network than might be advisable: types of DPI and DNS, the location of the Agent (central node and service network?), network latency markers and losses — and that’s just the most obvious aspects. Just as someone may monitor the actions of Agents to improve the accessibility of their resources, someone could do so for other purposes, and there are no obstacles to that. It has become a double-edged and very multifaceted tool, and anyone can see this.

Izvor: habr.com