No és cap secret que el control del bloqueig a la llista d'informació prohibida a Rússia està supervisat pel sistema automatitzat "Inspector". Com funciona està ben escrit aquí en això , imatge del mateix lloc:
Instal·lat directament al proveïdor :
El mòdul "Agent Inspector" és un element estructural del sistema automatitzat "Inspector" (AS "Inspector"). Aquest sistema està dissenyat per supervisar el compliment per part dels operadors de telecomunicacions dels requisits de restricció d'accés en el marc de les disposicions establertes pels articles 15.1-15.4 de la Llei Federal de 27 de juliol de 2006 núm. 149-FZ “sobre la informació, les tecnologies de la informació i la protecció de la informació. ”
L'objectiu principal de la creació d'AS "Revizor" és garantir el seguiment del compliment dels operadors de telecomunicacions dels requisits establerts pels articles 15.1-15.4 de la Llei Federal de 27 de juliol de 2006 núm. 149-FZ "Sobre la informació, les tecnologies de la informació i la protecció de la informació". " pel que fa a la identificació de fets d'accés a la informació prohibida i l'obtenció de materials de suport (dades) sobre violacions per restringir l'accés a la informació prohibida.
Tenint en compte el fet que, si no tots, molts proveïdors han instal·lat aquest dispositiu, hauria d'haver-hi hagut una gran xarxa de sondes de balises com ara i encara més, però amb accés tancat. Tanmateix, una balisa és una balisa per enviar senyals en totes direccions, però què passa si els agafem i veiem què hem agafat i quants?
Abans de comptar, anem a veure per què això podria ser possible.
Una mica de teoria
Els agents comproven la disponibilitat d'un recurs, fins i tot mitjançant sol·licituds HTTP(S), com aquesta:
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"
A més de la càrrega útil, la sol·licitud també consta d'una fase d'establiment de la connexió: intercanvi SYN и SYN-ACK, i fases de finalització de la connexió: FIN-ACK.
El registre d'informació prohibida conté diversos tipus de bloqueig. Evidentment, si un recurs està bloquejat per adreça IP o nom de domini, no veurem cap sol·licitud. Aquests són els tipus de bloqueig més destructius, que porten a la inaccessibilitat de tots els recursos d'una adreça IP o de tota la informació d'un domini. També hi ha un tipus de bloqueig "per URL". En aquest cas, el sistema de filtrat ha d'analitzar la capçalera de la sol·licitud HTTP per determinar exactament què bloquejar. I abans, com es pot veure més amunt, hi hauria d'haver una fase d'establiment de la connexió de la qual podeu intentar fer un seguiment, ja que el més probable és que el filtre la perdi.
Per fer-ho, cal seleccionar un domini gratuït adequat amb el tipus de bloqueig “URL” i HTTP per facilitar el treball del sistema de filtratge, preferiblement abandonat durant molt de temps, per minimitzar l'entrada de trànsit ali excepte dels Agents. Aquesta tasca no va resultar gens difícil, hi ha molts dominis gratuïts al registre d'informació prohibida i per a tots els gustos. Per tant, el domini es va comprar i es va vincular a adreces IP en un VPS en funcionament tcpdump i va començar el recompte.
Auditoria d'"Auditors"
Esperava veure ràfegues periòdiques de peticions, que al meu entendre indicarien una acció controlada. És impossible dir que no ho vaig veure en absolut, però definitivament no hi havia una imatge clara:
La qual cosa no és d'estranyar, fins i tot en un domini que ningú necessita i en una IP mai utilitzada, simplement hi haurà un munt d'informació no sol·licitada, com és la Internet moderna. Però, afortunadament, només necessitava sol·licituds per a un URL específic, de manera que es van trobar ràpidament tots els escàners i els crackers de contrasenyes. A més, va ser bastant fàcil entendre on es va basar la riuada a partir de la massa de peticions similars. A continuació, vaig compilar la freqüència d'ocurrència de les adreces IP i vaig recórrer tota la part superior manualment, separant els que ho van perdre en les etapes anteriors. A més, vaig retallar totes les fonts que es van enviar en un paquet, ja no n'hi havia moltes. I això és el que va passar:
Una petita digressió lírica. Poc més d'un dia després, el meu proveïdor d'allotjament va enviar una carta amb un contingut força simplificat, dient que les vostres instal·lacions contenen un recurs de la llista prohibida de RKN, per la qual cosa està bloquejat. Al principi vaig pensar que el meu compte estava bloquejat, no va ser així. Aleshores vaig pensar que simplement m'estaven avisant d'una cosa que ja sabia. Però va resultar que l'hoster va activar el seu filtre davant del meu domini i, com a resultat, em vaig sotmetre a un doble filtrat: dels proveïdors i de l'hoster. El filtre només ha passat els finals de les sol·licituds: FIN-ACK и RST tallant tot HTTP en un URL prohibit. Com podeu veure al gràfic anterior, després del primer dia vaig començar a rebre menys dades, però encara les vaig rebre, cosa que va ser prou per a la tasca de comptar les fonts de sol·licitud.
Arriba al punt. Al meu entendre, cada dia es veuen clarament dues ràfegues, la primera més petita, després de la mitjanit, hora de Moscou, la segona més a prop de les 6 del matí amb una cua fins a les 12 del migdia. El pic no es produeix exactament al mateix temps. Al principi, volia seleccionar adreces IP que només caiguessin en aquests períodes i cadascuna en tots els períodes, basant-me en el supòsit que les comprovacions dels agents es realitzen periòdicament. Però després d'una revisió acurada, vaig descobrir ràpidament períodes que caiven en altres intervals, amb altres freqüències, fins a una sol·licitud cada hora. Llavors vaig pensar en les zones horàries i que potser hi havia alguna cosa a veure, després vaig pensar que, en general, el sistema podria no estar sincronitzat globalment. A més, probablement NAT jugarà un paper i el mateix agent pot fer sol·licituds des de diferents IPs públiques.
Com que el meu objectiu inicial no era exactament, vaig comptar totes les adreces que vaig trobar en una setmana i vaig aconseguir... 2791. El nombre de sessions TCP establertes des d'una adreça és de mitjana 4, amb una mediana de 2. Sessions principals per adreça: 464, 231, 149, 83, 77. El màxim a partir del 95% de la mostra és de 8 sessions per adreça. La mediana no és molt alta, permeteu-me recordar que el gràfic mostra una periodicitat diària clara, per la qual cosa es podria esperar alguna cosa al voltant de 4 a 8 en 7 dies. Si llencem totes les sessions que es produeixen una vegada, obtindrem una mediana igual a 5. Però no les podria excloure amb un criteri clar. Al contrari, una comprovació aleatòria va demostrar que estaven relacionades amb les sol·licituds d'un recurs prohibit.
Les adreces són adreces, però a Internet, sistemes autònoms - AS, que van resultar ser més importants 1510, de mitjana 2 adreces per AS amb una mediana d'1. Adreces principals per AS: 288, 77, 66, 39, 27. El màxim del 95% de la mostra és de 4 adreces per AS. Aquí s'espera la mitjana: un agent per proveïdor. També esperem el cim: hi ha grans jugadors. En una xarxa gran, probablement els agents haurien d'estar situats a cada regió de presència de l'operador i no us oblideu de NAT. Si ho prenem per països, els màxims seran: 1409 - RU, 42 - UA, 23 - CZ, 36 d'altres regions, no RIPE NCC. Les peticions de fora de Rússia criden l'atenció. Això probablement es pot explicar per errors de geolocalització o errors de registre en omplir les dades. O el fet que una empresa russa no tingui arrels russes, o que tingui una oficina de representació estrangera perquè és més fàcil, la qual cosa és natural quan es tracta d'una organització estrangera RIPE NCC. Sens dubte, alguna part és superflua, però és difícil separar-la de manera fiable, ja que el recurs està bloquejat i des del segon dia amb doble bloqueig, i la majoria de sessions són només un intercanvi de diversos paquets de servei. Estem d'acord que això és una petita part.
Aquests números ja es poden comparar amb el nombre de proveïdors a Rússia. llicències per a "Serveis de comunicació per a la transmissió de dades, sense incloure la veu" - 6387, però aquesta és una estimació molt alta des de dalt, no totes aquestes llicències s'apliquen específicament als proveïdors d'Internet que necessiten instal·lar un agent. A la zona RIPE NCC hi ha un nombre similar d'AS registrats a Rússia: 6230, dels quals no tots són proveïdors. i va rebre 3940 empreses el 2017, i això és més aviat una estimació des de dalt. En qualsevol cas, tenim dues vegades i mitja menys d'AS il·luminats. Però aquí val la pena entendre que AS no és estrictament igual al proveïdor. Alguns proveïdors no tenen el seu propi AS, alguns en tenen més d'un. Si suposem que tothom encara té Agents, llavors algú filtra amb més força que els altres, de manera que les seves peticions són indistinguibles de les escombraries, si els arriba. Però per a una avaluació aproximada és bastant tolerable, fins i tot si alguna cosa es va perdre a causa de la meva supervisió.
Sobre DPI
Malgrat que el meu proveïdor d'allotjament va activar el seu filtre a partir del segon dia, a partir de la informació del primer dia podem concloure que el bloqueig funciona correctament. Només 4 fonts han pogut passar i han completat completament les sessions HTTP i TCP (com a l'exemple anterior). Es poden enviar 460 més GET, però la sessió s'acaba immediatament per RST. Para atenció a 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"
Les variacions d'això poden ser diferents: menys RST o més retransmissions: també depèn del que envia el filtre al node font. En tot cas, aquesta és la plantilla més fiable, de la qual es desprèn que era un recurs prohibit el que es demanava. A més, sempre hi ha una resposta que apareix a la sessió amb TTL més gran que en paquets anteriors i posteriors.
No ho pots veure ni des de la resta 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"
O bé:
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 diferència és definitivament visible TTL si alguna cosa ve del filtre. Però sovint no pot arribar res:
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"
...
O bé:
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"
...
I tot això es repeteix i es repeteix i es repeteix, com es pot veure al gràfic, més d'una vegada, cada dia.
Sobre IPv6
La bona notícia és que existeix. Puc dir de manera fiable que les sol·licituds periòdiques a un recurs prohibit es produeixen des de 5 adreces IPv6 diferents, que és exactament el comportament dels agents que esperava. A més, una de les adreces IPv6 no entra en filtratge i veig una sessió completa. De dues més només vaig veure una sessió inacabada, una de les quals va ser interrompuda RST del filtre, segon en el temps. Quantitat total 7.
Com que hi ha poques adreces, les vaig estudiar totes amb detall i va resultar que només hi ha 3 proveïdors, se'ls pot ovacionar! Una altra adreça és l'allotjament en núvol a Rússia (no filtra), una altra és un centre de recerca a Alemanya (hi ha un filtre, on?). Però per què comproven la disponibilitat dels recursos prohibits en un calendari és una bona pregunta. Els dos restants van fer una sol·licitud i es troben fora de Rússia, i un d'ells es filtra (en trànsit, després de tot?).
El bloqueig i els agents són un gran obstacle per a IPv6, la implementació del qual no es mou molt ràpidament. És trist. Els que van resoldre aquest problema poden estar completament orgullosos de si mateixos.
en conclusió
No em vaig esforçar per aconseguir una precisió del 100%, si us plau, perdoneu-me per això, espero que algú vulgui repetir aquest treball amb més precisió. Era important per a mi entendre si aquest enfocament funcionaria en principi. La resposta és sí. Les xifres obtingudes, com a primera aproximació, crec, són força fiables.
Què més es podria haver fet i el que em feia massa mandra per fer era comptar les sol·licituds de DNS. No es filtren, però tampoc proporcionen molta precisió ja que només funcionen per al domini, i no per a l'URL sencer. La freqüència ha de ser visible. Si ho combines amb el que és visible directament a les consultes, això et permetrà separar allò innecessari i obtenir més informació. Fins i tot és possible determinar els desenvolupadors del DNS utilitzats pels proveïdors i molt més.
No esperava que l'hoster també inclogués el seu propi filtre per al meu VPS. Potser aquesta és una pràctica habitual. Al final, RKN envia una sol·licitud per eliminar el recurs a l'hoster. Però això no em va sorprendre i d'alguna manera fins i tot va funcionar al meu avantatge. El filtre va funcionar de manera molt eficaç, tallant totes les sol·licituds HTTP correctes a una URL prohibida, però les correctes que havien passat prèviament pel filtre dels proveïdors hi arribaven, encara que només en forma de terminacions: FIN-ACK и RST - menys per menys i gairebé va resultar ser un avantatge. Per cert, IPv6 no va ser filtrat per l'hoster. Per descomptat, això va afectar la qualitat del material recollit, però tot i així va permetre veure la freqüència. Va resultar que aquest és un punt important a l'hora d'escollir un lloc per col·locar recursos, no us oblideu d'interessar-vos pel tema de l'organització del treball amb la llista de llocs prohibits i les sol·licituds de la RKN.
Al principi, vaig comparar l'AS "Inspector" amb . Aquesta comparació està força justificada i una gran xarxa d'Agents pot ser beneficiosa. Per exemple, determinar la qualitat de la disponibilitat de recursos de diferents proveïdors a diferents parts del país. Podeu calcular retards, crear gràfics, analitzar-ho tot i veure els canvis que es produeixen tant a nivell local com global. Aquesta no és la manera més directa, però els astrònoms utilitzen "espelmes estàndard", per què no utilitzen Agents? Coneixent (havent trobat) el seu comportament estàndard, podeu determinar els canvis que es produeixen al seu voltant i com això afecta la qualitat dels serveis prestats. I al mateix temps, no cal que col·loqueu sondes de manera independent a la xarxa Roskomnadzor ja les ha instal·lat.
Un altre punt que vull tocar és que cada eina pot ser una arma. AS "Inspector" és una xarxa tancada, però els Agents ceden a tothom enviant sol·licituds per a tots els recursos de la llista prohibida. Tenir aquest recurs no presenta cap problema. En total, els proveïdors a través d'Agents, sense voler-ho, diuen molt més sobre la seva xarxa del que probablement val la pena: tipus de DPI i DNS, ubicació de l'agent (node central i xarxa de serveis?), marcadors de xarxa de retards i pèrdues, i això és només el més evident. De la mateixa manera que algú pot controlar les accions dels Agents per millorar la disponibilitat dels seus recursos, algú pot fer-ho amb altres finalitats i no hi ha obstacles per a això. El resultat és un instrument de doble tall i molt polièdric, això ho pot veure qualsevol.
Font: www.habr.com