Ne estas sekreto, ke la kontrolo de blokado en la listo de malpermesitaj informoj en Rusio estas kontrolata de la aŭtomata sistemo "Inspektisto". Kiel ĝi funkcias estas bone skribita ĉi tie en ĉi tio , bildo el la sama loko:
Instalita rekte ĉe la provizanto :
La modulo "Agent Inspector" estas struktura elemento de la aŭtomatigita sistemo "Inspektisto" (AS "Inspektisto"). Ĉi tiu sistemo estas desegnita por kontroli la plenumon de telekomunikaj telefonistoj kun alirlimigoj en la kadro de la dispozicioj establitaj de Artikoloj 15.1-15.4 de la Federacia Leĝo de la 27-a de julio 2006 n-ro 149-FZ "Pri Informoj, Informaj Teknologioj kaj Informa Protekto. ”
La ĉefa celo de kreado de AS "Revizor" estas certigi kontroladon de la plenumo de telekomunikaj telefonistoj kun la postuloj establitaj de Artikoloj 15.1-15.4 de la Federacia Leĝo de la 27-a de julio 2006 n-ro 149-FZ "Pri Informoj, Informaj Teknologioj kaj Informa Protekto. " rilate identigi faktojn de aliro al malpermesitaj informoj kaj akiri subtenajn materialojn (datenoj) pri malobservoj por limigi aliron al malpermesitaj informoj.
Konsiderante la fakton, ke, se ne ĉiuj, tiam multaj provizantoj instalis ĉi tiun aparaton, devus estinti granda reto de lumsondiloj kiel kaj eĉ pli, sed kun fermita aliro. Tamen, lumturo estas lumturo por sendi signalojn en ĉiuj direktoj, sed kio se ni kaptas ilin kaj vidos kion ni kaptis kaj kiom?
Antaŭ ol ni kalkulas, ni vidu kial tio eĉ povus esti ebla.
Iom teorio
Agentoj kontrolas la haveblecon de rimedo, inkluzive per HTTP(S) petoj, kiel ĉi tiu:
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"
Krom la utila ŝarĝo, la peto ankaŭ konsistas el konektestabla fazo: interŝanĝo SYN и SYN-ACK, kaj konektkompletigaj fazoj: FIN-ACK.
La registro de malpermesitaj informoj enhavas plurajn specojn de blokado. Evidente, se rimedo estas blokita de IP-adreso aŭ domajna nomo, tiam ni ne vidos petojn. Ĉi tiuj estas la plej detruaj tipoj de blokado, kiuj kondukas al la nealirebleco de ĉiuj rimedoj sur unu IP-adreso aŭ ĉiuj informoj pri domajno. Ankaŭ ekzistas "per URL" speco de blokado. En ĉi tiu kazo, la filtra sistemo devas analizi la HTTP-peton kaplinion por determini ĝuste kion bloki. Kaj antaŭ ĝi, kiel videblas supre, devus ekzisti fazo pri konekto, kiun vi povas provi spuri, ĉar plej verŝajne la filtrilo maltrafos ĝin.
Por fari tion, vi devas elekti taŭgan senpagan domajnon kun la "URL" kaj HTTP-bloka tipo por faciligi la laboron de la filtra sistemo, prefere longe forlasita, por minimumigi la eniron de ekstera trafiko krom de Agentoj. Ĉi tiu tasko montriĝis tute ne malfacila; estas sufiĉe multe da senpagaj domajnoj en la registro de malpermesitaj informoj kaj por ĉiuj gustoj. Tial, la domajno estis aĉetita kaj ligita al IP-adresoj sur VPS funkcianta tcpdump kaj la kalkulado komenciĝis.
Revizio de "Revizoroj"
Mi atendis vidi periodajn eksplodojn de petoj, kiuj laŭ mi indikus kontrolitan agadon. Ne eblas diri, ke mi tute ne vidis ĝin, sed certe ne estis klara bildo:
Kio ne estas surpriza, eĉ sur domajno, kiun neniu bezonas kaj sur neniam uzata IP, simple estos amaso da nepetitaj informoj, tia estas la moderna Interreto. Sed feliĉe, mi nur bezonis petojn por specifa URL, do ĉiuj skaniloj kaj pasvortrompiloj estis rapide trovitaj. Ankaŭ, estis sufiĉe facile kompreni kie la inundo baziĝis sur la amaso de similaj petoj. Poste, mi kompilis la oftecon de apero de IP-adresoj kaj ekzamenis la tutan supro permane, apartigante tiujn, kiuj maltrafis ĝin en la antaŭaj stadioj. Aldone, mi eltranĉis ĉiujn fontojn, kiuj estis senditaj en unu pako, ne plu estis multaj el ili. Kaj jen kio okazis:
Eta lirika digresio. Iom pli ol unu tagon poste, mia gastiganta provizanto sendis leteron kun sufiĉe simpligita enhavo, dirante, ke viaj instalaĵoj enhavas rimedon el la malpermesita listo de RKN, do ĝi estas blokita. Komence mi pensis, ke mia konto estas blokita, tio ne estis la kazo. Tiam mi pensis, ke ili simple avertas min pri io, pri kio mi jam sciis. Sed montriĝis, ke la gastiganto ŝaltis sian filtrilon antaŭ mia domajno kaj sekve mi venis sub duoblan filtradon: de la provizantoj kaj de la gastiganto. La filtrilo nur pasis la finojn de petoj: FIN-ACK и RST fortranĉante ĉian HTTP ĉe malpermesita URL. Kiel vi povas vidi el la supra grafikaĵo, post la unua tago mi komencis ricevi malpli da datumoj, sed mi tamen ricevis ĝin, kio sufiĉis por la tasko kalkuli petajn fontojn.
Iru al la punkto. Miaopinie, du eksplodoj estas klare videblaj ĉiutage, la unua pli malgranda, post noktomezo moskva tempo, la dua pli proksime al la 6-a matene kun vosto ĝis la 12-a tagmezo. La pinto ne okazas precize en la sama tempo. Komence, mi volis elekti IP-adresojn kiuj falis nur en ĉi tiuj periodoj kaj ĉiu en ĉiuj periodoj, surbaze de la supozo, ke kontroloj de Agentoj estas periode faritaj. Sed post zorgema revizio, mi rapide malkovris periodojn falantajn en aliajn intervalojn, kun aliaj frekvencoj, ĝis unu peto ĉiun horon. Tiam mi pensis pri horzonoj kaj ke eble ĝi havas ion rilaton kun ili, tiam mi pensis, ke ĝenerale la sistemo eble ne estas tutmonde sinkronigita. Krome, NAT verŝajne ludos rolon kaj la sama Agento povas fari petojn de malsamaj publikaj IP-oj.
Ĉar mia komenca celo ne estis ĝuste, mi nombris ĉiujn adresojn, kiujn mi trovis en semajno kaj ricevis - 2791. La nombro da TCP-sesioj establitaj de unu adreso estas averaĝe 4, kun mediano de 2. Supraj sesioj per adreso: 464, 231, 149, 83, 77. La maksimumo de 95% de la specimeno estas 8 sesioj per adreso. La mediano ne estas tre alta, mi memorigu vin, ke la grafikaĵo montras klaran ĉiutagan periodecon, do oni povus atendi ion ĉirkaŭ 4 ĝis 8 en 7 tagoj. Se ni forĵetas ĉiujn kunsidojn, kiuj okazas unufoje, ni ricevos medianon egalan al 5. Sed mi ne povus ekskludi ilin laŭ klara kriterio. Male, hazarda kontrolo montris, ke ili rilatas al petoj por malpermesita rimedo.
Adresoj estas adresoj, sed en la interreto, aŭtonomaj sistemoj - AS, kiuj montriĝis pli gravaj 1510, averaĝe 2 adresoj po AS kun mediano de 1. Ĉefaj adresoj po AS: 288, 77, 66, 39, 27. La maksimumo de 95% de la specimeno estas 4 adresoj po AS. Ĉi tie la mediano estas atendata - unu Agento per provizanto. Ni ankaŭ atendas la pinton - estas grandaj ludantoj en ĝi. En granda reto, Agentoj probable devus troviĝi en ĉiu regiono de la ĉeesto de la funkciigisto, kaj ne forgesu pri NAT. Se ni prenas ĝin laŭ landoj, la maksimumoj estos: 1409 - RU, 42 - UA, 23 - CZ, 36 el aliaj regionoj, ne RIPE NCC. Petoj el ekster Rusio altiras atenton. Ĉi tio verŝajne povas esti klarigita per geolokigaj eraroj aŭ registraj eraroj dum plenigado de datumoj. Aŭ la fakto, ke rusa firmao eble ne havas rusajn radikojn, aŭ havas eksterlandan reprezentan oficejon ĉar ĝi estas pli facila, kio estas nature kiam traktas eksterlandan organizon RIPE NCC. Iu parto estas sendube superflua, sed estas fidinde malfacile apartigi ĝin, ĉar la rimedo estas sub blokado, kaj de la dua tago sub duobla blokado, kaj la plej multaj sesioj estas nur interŝanĝo de pluraj servaj pakoj. Ni konsentu, ke ĉi tio estas malgranda parto.
Ĉi tiuj nombroj jam povas esti komparitaj kun la nombro da provizantoj en Rusio. permesiloj por "Komunikadaj servoj por transdono de datumoj, krom voĉo" - 6387, sed ĉi tio estas tre alta takso de supre, ne ĉiuj ĉi tiuj permesiloj validas specife por interretaj provizantoj, kiuj bezonas instali Agenton. En la RIPE NCC-zono ekzistas simila nombro da AS-oj registritaj en Rusio - 6230, el kiuj ne ĉiuj estas provizantoj. kaj ricevis 3940 kompaniojn en 2017, kaj ĉi tio estas prefere takso de supre. Ĉiukaze ni havas dufoje kaj duonon malpli da lumigitaj AS-oj. Sed ĉi tie indas kompreni, ke AS ne strikte egalas al la provizanto. Iuj provizantoj ne havas sian propran AS, iuj havas pli ol unu. Se ni supozas, ke ĉiuj ankoraŭ havas Agentojn, tiam iu filtras pli forte ol aliaj, tiel ke iliaj petoj estas nedistingeblaj de rubo, se ili entute atingas ilin. Sed por malglata takso ĝi estas sufiĉe tolerebla, eĉ se io perdiĝis pro mia superrigardo.
Pri DPI
Malgraŭ tio, ke mia gastiga provizanto ŝaltis sian filtrilon ekde la dua tago, surbaze de la informoj de la unua tago ni povas konkludi, ke la blokado funkcias sukcese. Nur 4 fontoj povis trapasi kaj plene plenumi HTTP- kaj TCP-sesiojn (kiel en la supra ekzemplo). Pliaj 460 povas esti senditaj GET, sed la kunsido tuj finiĝas per RST. atentu 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"
Varioj de ĉi tio povas esti malsamaj: malpli RST aŭ pli da retransmisioj - ankaŭ dependas de tio, kion la filtrilo sendas al la fontnodo. Ĉiukaze, ĉi tiu estas la plej fidinda ŝablono, el kiu estas klare, ke ĝi estis malpermesita rimedo, kiun oni petis. Plie ĉiam estas respondo, kiu aperas en la kunsido kun TTL pli granda ol en antaŭaj kaj postaj pakoj.
Vi eĉ ne povas vidi ĝin de la ceteraj 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"
Aŭ tiel:
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"
...
La diferenco estas certe videbla TTL se io venas el la filtrilo. Sed ofte nenio povas alveni entute:
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"
...
Aŭ tiel:
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"
...
Kaj ĉio ĉi ripetiĝas kaj ripetas kaj ripetas, kiel videblas sur la grafikaĵo, pli ol unufoje, ĉiutage.
Pri IPv6
La bona novaĵo estas, ke ĝi ekzistas. Mi povas fidinde diri, ke periodaj petoj al malpermesita rimedo okazas de 5 malsamaj IPv6-adresoj, kio estas ĝuste la konduto de la Agentoj, kiujn mi atendis. Krome, unu el la IPv6-adresoj ne falas sub filtrado kaj mi vidas plenan kunsidon. El du pliaj mi vidis nur unu nefinitan kunsidon, el kiu unu estis interrompita de RST de la filtrilo, dua en la tempo. Tuta kvanto 7.
Ĉar estas malmultaj adresoj, mi detale studis ĉiujn kaj montriĝis, ke tie estas nur 3 provizantoj, oni povas ovadi ilin! Alia adreso estas nuba gastigado en Rusio (ne filtras), alia estas esplorcentro en Germanio (estas filtrilo, kie?). Sed kial ili kontrolas la haveblecon de malpermesitaj rimedoj laŭ horaro estas bona demando. La ceteraj du faris unu peton kaj situas ekster Rusujo, kaj unu el ili estas filtrita (en trairo, ja?).
Blokado kaj Agentoj estas granda malhelpo al IPv6, kies efektivigo ne moviĝas tre rapide. Estas malgaja. Tiuj, kiuj solvis ĉi tiun problemon, povas esti plene fieraj pri si mem.
En konkludo
Mi ne strebis al 100% precizeco, bonvolu pardoni min pro tio, mi esperas, ke iu volas ripeti ĉi tiun laboron kun pli granda precizeco. Estis grave por mi kompreni ĉu ĉi tiu aliro principe funkcios. La respondo estas jes. Kiel unua aproksimado, la akiritaj ciferoj, mi opinias, estas sufiĉe fidindaj.
Kion alian oni povus fari kaj kion mi tro mallaboris fari estis kalkuli DNS-petojn. Ili ne estas filtritaj, sed ili ankaŭ ne donas multe da precizeco ĉar ili funkcias nur por la domajno, kaj ne por la tuta URL. La ofteco devus esti videbla. Se vi kombinas ĝin kun kio estas videbla rekte en la demandoj, ĉi tio permesos al vi apartigi la nenecesajn kaj akiri pli da informoj. Eblas eĉ determini la programistojn de la DNS uzataj de provizantoj kaj multe pli.
Mi absolute ne atendis, ke la gastiganto ankaŭ inkludus sian propran filtrilon por mia VPS. Eble ĉi tio estas ofta praktiko. En la fino, RKN sendas peton forigi la rimedon al la gastiganto. Sed ĉi tio ne surprizis min kaj iel eĉ funkciis je mia avantaĝo. La filtrilo funkciis tre efike, fortranĉante ĉiujn ĝustajn HTTP-petojn al malpermesita URL, sed ne ĝustaj, kiuj antaŭe trapasis la filtrilon de la provizantoj, atingis ilin, kvankam nur en formo de finaĵoj: FIN-ACK и RST - minus por minus kaj ĝi preskaŭ montriĝis pluso. Cetere, IPv6 ne estis filtrita de la gastiganto. Kompreneble, tio influis la kvaliton de la kolektita materialo, sed ĝi ankoraŭ ebligis vidi la frekvencon. Montriĝis, ke ĉi tio estas grava punkto kiam vi elektas retejon por meti rimedojn; ne forgesu interesiĝi pri la temo de organizado de laboro kun la listo de malpermesitaj lokoj kaj petoj de la RKN.
Komence mi komparis la AS "Inspektoro" kun . Ĉi tiu komparo estas sufiĉe pravigita kaj granda reto de Agentoj povas esti utila. Ekzemple, determini la kvaliton de resurshavebleco de malsamaj provizantoj en malsamaj partoj de la lando. Vi povas kalkuli malfruojn, vi povas konstrui grafikaĵojn, vi povas analizi ĉion kaj vidi la ŝanĝojn okazantajn kaj loke kaj tutmonde. Ĉi tio ne estas la plej rekta maniero, sed astronomoj uzas "normajn kandelojn", kial ne uzi Agentojn? Sciante (trovinte) ilian norman konduton, vi povas determini la ŝanĝojn kiuj okazas ĉirkaŭ ili kaj kiel ĉi tio influas la kvaliton de la servoj provizitaj. Kaj samtempe, vi ne bezonas sendepende meti sondilojn en la reto; Roskomnadzor jam instalis ilin.
Alia punkto, kiun mi volas tuŝi, estas, ke ĉiu ilo povas esti armilo. AS "Inspektisto" estas fermita reto, sed la Agentoj transdonas ĉiujn sendante petojn por ĉiuj rimedoj el la malpermesita listo. Havi tian rimedon tute ne prezentas problemojn. Entute, provizantoj per Agentoj, senintence, rakontas multe pli pri sia reto ol verŝajne valoras ĝin: DPI kaj DNS-tipoj, loko de la Agento (centra nodo kaj serva reto?), retaj signoj de prokrastoj kaj perdoj - kaj ĉi tio estas nur la plej evidenta. Same kiel iu povas monitori la agojn de Agentoj por plibonigi la haveblecon de siaj rimedoj, iu povas fari tion por aliaj celoj kaj ne estas obstakloj al tio. La rezulto estas duobla kaj tre multfaceta instrumento, ĉiu povas vidi ĉi tion.
fonto: www.habr.com