Ei ole mikään salaisuus, että Venäjällä kiellettyjen tietojen luettelon eston valvontaa valvoo automaattinen "Tarkastaja" -järjestelmä. Kuinka se toimii, on täällä hyvin kirjoitettu , kuva samasta paikasta:
Asennettu suoraan toimittajalta :
"Agent Inspector" -moduuli on automatisoidun järjestelmän "Inspector" (AS "Inspector") rakenneosa. Tämä järjestelmä on suunniteltu valvomaan, että teleoperaattorit noudattavat pääsynrajoitusvaatimuksia 15.1. heinäkuuta 15.4 annetun liittovaltion lain nro 27-FZ "Tiedoista, tietoteknologioista ja tietosuojasta" artiklojen 2006-149 määräysten puitteissa. ”
AS "Revizor" luomisen päätarkoituksena on varmistaa, että teleoperaattorit noudattavat 15.1. heinäkuuta 15.4 annetun liittovaltion lain nro 27-FZ "Tiedosta, tietoteknologioista ja tietosuojasta" artikloissa 2006-149 asetettuja vaatimuksia. " kielletyn tiedon saamiseen liittyvien tosiseikkojen tunnistamisen ja rikkomuksia koskevien tukimateriaalien (datan) hankkimisen osalta, jotta rajoitetaan pääsyä kiellettyihin tietoihin.
Ottaen huomioon sen tosiasian, että jos eivät kaikki, niin monet palveluntarjoajat ovat asentaneet tämän laitteen, olisi pitänyt olla laaja verkosto majakkaanturia, kuten ja vielä enemmän, mutta suljetulla pääsyllä. Majakka on kuitenkin majakka, joka lähettää signaaleja kaikkiin suuntiin, mutta entä jos saamme ne kiinni ja katsomme mitä saimme ja kuinka monta?
Ennen kuin laskemme, katsotaanpa, miksi tämä voi olla mahdollista.
Hieman teoria
Agentit tarkistavat resurssin saatavuuden myös HTTP(S)-pyyntöjen kautta, kuten tämä:
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"
Pyyntö koostuu hyötykuorman lisäksi myös yhteydenmuodostusvaiheesta: vaihdosta SYN и SYN-ACKja yhteyden valmistumisvaiheet: FIN-ACK.
Kiellettyjen tietojen rekisteri sisältää useita estoja. On selvää, että jos IP-osoite tai verkkotunnus estää resurssin, emme näe pyyntöjä. Nämä ovat tuhoisimpia estotyyppejä, jotka johtavat siihen, että kaikki yhden IP-osoitteen resurssit tai kaikki verkkotunnuksen tiedot eivät ole käytettävissä. On olemassa myös "URL-osoitteen perusteella" -tyyppinen esto. Tässä tapauksessa suodatusjärjestelmän on jäsennettävä HTTP-pyynnön otsikko määrittääkseen tarkalleen, mitä estetään. Ja ennen sitä, kuten yllä näkyy, pitäisi olla yhteydenmuodostusvaihe, jota voit yrittää seurata, koska todennäköisesti suodatin jättää sen huomaamatta.
Tätä varten sinun on valittava sopiva vapaa verkkotunnus URL- ja HTTP-estotyypeillä suodatusjärjestelmän toiminnan helpottamiseksi, mieluiten kauan hylätty, minimoimaan ulkopuolisen liikenteen sisäänpääsy paitsi agenteilta. Tämä tehtävä ei osoittautunut ollenkaan vaikeaksi, kiellettyjen tietojen rekisterissä on melko paljon ilmaisia verkkotunnuksia ja jokaiseen makuun. Siksi verkkotunnus ostettiin ja linkitettiin käynnissä olevan VPS:n IP-osoitteisiin tcpdump ja laskenta alkoi.
"Tarkastajien" tarkastus
Odotin näkeväni säännöllisiä pyyntöpurskeita, jotka mielestäni osoittaisivat hallittua toimintaa. On mahdotonta sanoa, että en nähnyt sitä ollenkaan, mutta selkeää kuvaa ei todellakaan ollut:
Mikä ei ole yllättävää, vaikka verkkotunnuksessa, jota kukaan ei tarvitse, ja koskaan käyttämättömällä IP-osoitteella, tulee yksinkertaisesti paljon ei-toivottua tietoa, kuten nykyaikainen Internet. Mutta onneksi tarvitsin vain tietyn URL-osoitteen pyyntöjä, joten kaikki skannerit ja salasanojen murskaajat löytyivät nopeasti. Lisäksi samankaltaisten pyyntöjen massan perusteella oli melko helppo ymmärtää, missä tulva oli. Seuraavaksi kokosin IP-osoitteiden esiintymistiheyden ja kävin läpi koko yläosan manuaalisesti erottamalla ne, jotka jäivät sen huomaamatta edellisissä vaiheissa. Lisäksi leikkasin pois kaikki samassa paketissa lähetetyt lähteet, niitä ei ollut enää montaa. Ja näin tapahtui:
Pieni lyyrinen poikkeama. Hieman yli päivää myöhemmin isännöintipalveluntarjoajani lähetti melko virtaviivaistetun sisällön kirjeen, jossa kerrottiin, että tilat sisältävät resurssia RKN:n kiellettyjen luettelosta, joten se on estetty. Aluksi luulin, että tilini on estetty, mutta näin ei ollut. Sitten ajattelin, että he vain varoittivat minua jostakin, josta tiesin jo. Mutta kävi ilmi, että isännöitsijä laittoi suodattimen päälle verkkotunnukseni edessä ja sen seurauksena jouduin kaksoissuodatuksen alle: palveluntarjoajilta ja isännöitsijältä. Suodatin läpäisi vain pyyntöjen loput: FIN-ACK и RST katkaisee kaiken HTTP:n kielletystä URL-osoitteesta. Kuten yllä olevasta kaaviosta näet, ensimmäisen päivän jälkeen aloin vastaanottaa vähemmän dataa, mutta silti sain sen, mikä riitti pyyntölähteiden laskemiseen.
Mennä asiaan. Mielestäni kaksi purskahdusta näkyy selvästi joka päivä, ensimmäinen pienempi, puolenyön jälkeen Moskovan aikaa, toinen lähempänä kello 6:ta hännän kanssa klo 12 asti. Huippu ei tapahdu täsmälleen samaan aikaan. Aluksi halusin valita IP-osoitteet, jotka putosivat vain näillä jaksoilla ja jokainen kaikilla jaksoilla, sillä oletuksella, että Agentit suorittavat tarkastuksia säännöllisesti. Mutta huolellisen tarkastelun jälkeen huomasin nopeasti jaksoja, jotka putosivat muihin aikaväleihin, muilla taajuuksilla, jopa yhteen pyyntöön joka tunti. Sitten ajattelin aikavyöhykkeitä ja sitä, että ehkä sillä oli jotain tekemistä niiden kanssa, sitten ajattelin, että yleisesti ottaen järjestelmä ei ehkä ole synkronoitu globaalisti. Lisäksi NAT todennäköisesti näyttelee roolia ja sama agentti voi tehdä pyyntöjä eri julkisista IP-osoitteista.
Koska alkuperäinen tavoitteeni ei ollut tarkka, laskin kaikki osoitteet, jotka löysin viikossa ja sain - 2791. Yhdestä osoitteesta muodostettujen TCP-istuntojen määrä on keskimäärin 4, mediaanin ollessa 2. Suosituimmat istunnot osoitetta kohti: 464, 231, 149, 83, 77. Enimmäismäärä 95 %:sta otoksesta on 8 istuntoa osoitetta kohden. Mediaani ei ole kovin korkea, haluan muistuttaa, että kaavio näyttää selkeän päivittäisen jaksollisuuden, joten 4 päivän aikana voisi odottaa jotain 8-7. Jos heitetään pois kaikki kerran esiintyvät istunnot, saadaan mediaani, joka on 5. Mutta en voinut sulkea niitä pois selkeän kriteerin perusteella. Päinvastoin, satunnaistarkastus osoitti, että ne liittyivät kiellettyä resurssia koskeviin pyyntöihin.
Osoitteet ovat osoitteita, mutta Internetissä autonomiset järjestelmät - AS, jotka osoittautuivat tärkeämmiksi 1510, keskimäärin 2 osoitetta per AS mediaani 1. Suosituimmat osoitteet per AS: 288, 77, 66, 39, 27. Enimmäismäärä 95 % otoksesta on 4 osoitetta per AS. Tässä odotetaan mediaania - yksi agentti per tarjoaja. Odotamme myös huippua - siinä on suuria pelaajia. Suuressa verkossa agenttien tulisi luultavasti sijaita jokaisella operaattorin läsnäolon alueella, äläkä unohda NAT:ia. Jos otamme sen maittain, enimmäismäärät ovat: 1409 - RU, 42 - UA, 23 - CZ, 36 muilta alueilta, ei RIPE NCC. Venäjän ulkopuolelta tulevat pyynnöt herättävät huomiota. Tämä johtuu luultavasti paikkatietovirheistä tai rekisterinpitäjän virheistä tietojen täyttämisessä. Tai se, että venäläisellä yrityksellä ei ehkä ole venäläisiä juuria tai ulkomaista edustustoa, koska se on helpompaa, mikä on luonnollista ulkomaisen organisaation RIPE NCC:n kanssa. Osa on epäilemättä tarpeeton, mutta sen erottaminen on luotettavasti vaikeaa, koska resurssi on eston alla ja toisesta päivästä alkaen kaksoisestossa, ja useimmat istunnot ovat vain useiden palvelupakettien vaihtoa. Sovitaan, että tämä on pieni osa.
Näitä lukuja voidaan jo verrata Venäjän palveluntarjoajien määrään. lisenssit "Tiedonsiirtopalvelut, lukuun ottamatta ääntä" - 6387, mutta tämä on erittäin korkea arvio ylhäältä, kaikki nämä lisenssit eivät koske erityisesti Internet-palveluntarjoajia, joiden on asennettava agentti. RIPE NCC -vyöhykkeellä on samanlainen määrä Venäjällä rekisteröityjä AS:ita - 6230, joista kaikki eivät ole tarjoajia. ja sai 3940 yritystä vuonna 2017, ja tämä on pikemminkin arvio ylhäältä. Joka tapauksessa meillä on kaksi ja puoli kertaa vähemmän valaistuja AS:ita. Mutta tässä on syytä ymmärtää, että AS ei ole täysin sama kuin palveluntarjoaja. Joillakin palveluntarjoajilla ei ole omaa AS:ta, toisilla on useampia kuin yksi. Jos oletetaan, että jokaisella on edelleen agentteja, niin joku suodattaa muita vahvemmin, jotta hänen pyyntönsä eivät eroa roskista, jos ne ylipäätään tavoittavat heidät. Mutta karkealla arvioinnilla se on melko siedettävää, vaikka jotain olisi menetetty huolimattomuudestani.
Tietoja DPI:stä
Huolimatta siitä, että palveluntarjoajani laittoi suodattimen päälle toisesta päivästä alkaen, voimme ensimmäisen päivän tietojen perusteella päätellä, että esto toimii onnistuneesti. Vain 4 lähdettä pääsi läpi ja ovat suorittaneet HTTP- ja TCP-istunnot kokonaan (kuten yllä olevassa esimerkissä). Toinen 460 voidaan lähettää GET, mutta istunnon lopettaa välittömästi RST. kiinnitä huomiota 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"
Tämän muunnelmat voivat olla erilaisia: vähemmän RST tai useampi uudelleenlähetys - riippuu myös siitä, mitä suodatin lähettää lähdesolmuun. Joka tapauksessa tämä on luotettavin malli, josta on selvää, että se oli pyydetty kielletty resurssi. Lisäksi on aina vastaus, joka näkyy istunnossa kanssa TTL suurempi kuin edellisissä ja seuraavissa paketeissa.
Sitä ei edes näe muualta 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"
Tai niin:
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"
...
Eron on selvästi havaittavissa TTL jos suodattimesta tulee jotain. Mutta usein ei välttämättä tule yhtään mitään:
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"
...
Tai niin:
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"
...
Ja kaikki tämä toistetaan ja toistetaan ja toistetaan, kuten kaaviosta voidaan nähdä, useammin kuin kerran, joka päivä.
Tietoja IPv6:sta
Hyvä uutinen on, että se on olemassa. Voin luotettavasti sanoa, että säännölliset pyynnöt kielletylle resurssille tulevat viidestä eri IPv5-osoitteesta, mikä on juuri sitä agenttien käyttäytymistä, jota odotin. Lisäksi yksi IPv6-osoitteista ei kuulu suodatuksen piiriin ja näen koko istunnon. Kahdesta muusta näin vain yhden keskeneräisen istunnon, joista toinen keskeytettiin RST suodattimesta, toinen ajallaan. Kokonaismäärä 7.
Koska osoitteita on vähän, tutkin niitä kaikkia yksityiskohtaisesti ja kävi ilmi, että siellä on vain 3 palveluntarjoajaa, heille voidaan antaa seisovia suosionosoituksia! Toinen osoite on pilvipalvelu Venäjällä (ei suodata), toinen on tutkimuskeskus Saksassa (siellä on suodatin, missä?). Mutta miksi he tarkistavat kiellettyjen resurssien saatavuuden aikataulussa, on hyvä kysymys. Loput kaksi tekivät yhden pyynnön ja sijaitsevat Venäjän ulkopuolella, ja yksi niistä on suodatettu (jonka aikana?).
Blocking and Agents ovat suuri este IPv6:lle, jonka käyttöönotto ei etene kovin nopeasti. Se on surullista. Ne, jotka ratkaisivat tämän ongelman, voivat olla täysin ylpeitä itsestään.
lopuksi
En pyrkinyt 100% tarkkuuteen, suokaa anteeksi, toivottavasti joku haluaa toistaa tämän työn suuremmalla tarkkuudella. Minulle oli tärkeää ymmärtää, toimiiko tämä lähestymistapa periaatteessa. Vastaus on kyllä. Saadut luvut ovat mielestäni ensimmäisenä likiarvona melko luotettavia.
Mitä muuta olisi voitu tehdä ja mitä olin liian laiska tekemään, oli DNS-pyyntöjen laskeminen. Niitä ei suodateta, mutta ne eivät myöskään tarjoa paljon tarkkuutta, koska ne toimivat vain verkkotunnukselle, eivät koko URL-osoitteelle. Taajuuden tulee olla näkyvissä. Jos yhdistät sen suoraan kyselyissä näkyvään, voit erottaa tarpeettomat ja saada lisää tietoa. On jopa mahdollista määrittää palveluntarjoajien käyttämän DNS:n kehittäjät ja paljon muuta.
En todellakaan odottanut, että isännöitsijä sisällyttäisi myös oman suodattimen VPS:ääni. Ehkä tämä on yleinen käytäntö. Lopulta RKN lähettää isännöitsijälle pyynnön resurssin poistamisesta. Mutta tämä ei yllättänyt minua, ja se oli jollain tapaa jopa hyödyksi. Suodatin toimi erittäin tehokkaasti ja katkaisi kaikki oikeat HTTP-pyynnöt kiellettyyn URL-osoitteeseen, mutta oikeat, aiemmin palveluntarjoajien suodattimen läpi menneet pyynnöt eivät saavuttaneet niitä, vaikkakin vain päätteiden muodossa: FIN-ACK и RST - miinus miinukseksi ja siitä tuli melkein plussa. Isäntä ei muuten suodattanut IPv6:ta. Tämä tietysti vaikutti kerätyn materiaalin laatuun, mutta silti mahdollisti taajuuden näkemisen. Kävi ilmi, että tämä on tärkeä kohta valittaessa resurssien sijoittamispaikkaa; älä unohda olla kiinnostunut töiden järjestämisestä kiellettyjen sivustojen luettelon ja RKN:n pyyntöjen kanssa.
Alussa vertasin AS "Tarkastaja" kanssa . Tämä vertailu on varsin perusteltu ja laaja agenttiverkosto voi olla hyödyksi. Esimerkiksi eri palveluntarjoajien resurssien saatavuuden laadun määrittäminen eri puolilla maata. Voit laskea viiveitä, rakentaa kaavioita, analysoida kaiken ja nähdä tapahtuvat muutokset sekä paikallisesti että globaalisti. Tämä ei ole suorin tapa, mutta tähtitieteilijät käyttävät "tavallisia kynttilöitä", miksi eivät käyttäisi agentteja? Kun tiedät (löydettyään) heidän normaalikäyttäytymisensä, voit määrittää niiden ympärillä tapahtuvat muutokset ja kuinka tämä vaikuttaa tarjottujen palvelujen laatuun. Ja samaan aikaan sinun ei tarvitse itsenäisesti sijoittaa antureita verkkoon; Roskomnadzor on jo asentanut ne.
Toinen asia, johon haluan kiinnittää huomiota, on se, että jokainen työkalu voi olla ase. AS "Inspector" on suljettu verkko, mutta agentit luovuttavat kaikki lähettämällä pyynnöt kaikista kielletyn luettelon resursseista. Tällaisen resurssin omistaminen ei aiheuta ongelmia ollenkaan. Kaiken kaikkiaan palveluntarjoajat Agenttien kautta kertovat tietämättään paljon enemmän verkosta kuin luultavasti sen arvoista: DPI- ja DNS-tyypit, agentin sijainti (keskussolmu ja palveluverkko?), viiveiden ja häviöiden verkkomerkit - ja tämä on vain ilmeisin. Aivan kuten joku voi valvoa Agenttien toimia parantaakseen resurssien saatavuutta, joku voi tehdä tämän muihin tarkoituksiin, eikä tälle ole esteitä. Tuloksena on kaksiteräinen ja erittäin monipuolinen instrumentti, jonka voi nähdä kuka tahansa.
Lähde: will.com