Non è un segreto che il controllo del blocco nell'elenco delle informazioni vietate in Russia sia monitorato dal sistema automatizzato “Inspector”. Come funziona è scritto bene qui in questo , immagine dallo stesso posto:
Installato direttamente presso il fornitore :
Il modulo "Agent Inspector" è un elemento strutturale del sistema automatizzato "Inspector" (AS "Inspector"). Questo sistema è progettato per monitorare il rispetto da parte degli operatori di telecomunicazioni dei requisiti di limitazione dell'accesso nel quadro delle disposizioni stabilite dagli articoli 15.1-15.4 della legge federale del 27 luglio 2006 n. 149-FZ “Sull'informazione, sulle tecnologie dell'informazione e sulla protezione dell'informazione. "
Lo scopo principale della creazione dell'AS "Revizor" è quello di garantire il monitoraggio del rispetto da parte degli operatori di telecomunicazioni dei requisiti stabiliti dagli articoli 15.1-15.4 della legge federale del 27 luglio 2006 n. 149-FZ "Sull'informazione, sulle tecnologie dell'informazione e sull'informazione Protezione” in termini di identificazione dei fatti di accesso a informazioni vietate e ottenimento di materiali di supporto (dati) sulle violazioni per limitare l'accesso a informazioni vietate.
Tenendo conto del fatto che, se non tutti, molti fornitori hanno installato questo dispositivo, dovrebbe esserci una vasta rete di sonde beacon come e anche di più, ma ad accesso chiuso. Tuttavia, un faro è un faro per inviare segnali in tutte le direzioni, ma cosa succederebbe se li catturassimo e vedessimo cosa abbiamo catturato e quanti?
Prima di contare, vediamo perché questo potrebbe essere possibile.
Un po 'di teoria
Gli agenti controllano la disponibilità di una risorsa, anche tramite richieste HTTP(S), come questa:
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"
La richiesta prevede oltre al payload anche una fase di realizzazione della connessione: lo scambio SYN и SYN-ACKe fasi di completamento della connessione: FIN-ACK.
Il registro delle informazioni vietate contiene diversi tipi di blocco. Ovviamente, se una risorsa viene bloccata dall'indirizzo IP o dal nome di dominio, allora non vedremo alcuna richiesta. Questi sono i tipi di blocco più distruttivi, che portano all'inaccessibilità di tutte le risorse su un indirizzo IP o di tutte le informazioni su un dominio. Esiste anche un tipo di blocco “per URL”. In questo caso, il sistema di filtraggio deve analizzare l'intestazione della richiesta HTTP per determinare esattamente cosa bloccare. E prima di ciò, come puoi vedere sopra, dovrebbe esserci una fase di creazione della connessione che puoi provare a monitorare, poiché molto probabilmente il filtro non la mancherà.
Per fare ciò, è necessario selezionare un dominio libero adatto con il tipo di blocco “URL” e HTTP per facilitare il lavoro del sistema di filtraggio, preferibilmente abbandonato da tempo, per ridurre al minimo l'ingresso di traffico estraneo tranne che dagli Agenti. Questo compito non si è rivelato affatto difficile: ci sono molti domini gratuiti nel registro delle informazioni vietate e per tutti i gusti. Pertanto, il dominio è stato acquistato e collegato agli indirizzi IP su un VPS funzionante tcpdump e cominciò il conteggio.
Audit dei "Revisori dei Conti"
Mi aspettavo di vedere periodiche ondate di richieste, che a mio parere indicherebbero un’azione controllata. È impossibile dire di non averlo visto affatto, ma sicuramente non c’era un quadro chiaro:
Ciò non sorprende, anche su un dominio di cui nessuno ha bisogno e su un IP mai utilizzato ci saranno semplicemente un sacco di informazioni non richieste, come è la moderna Internet. Ma fortunatamente avevo solo bisogno di richieste per un URL specifico, quindi tutti gli scanner e i cracker di password sono stati trovati rapidamente. Inoltre, è stato abbastanza facile capire da dove provenisse l'alluvione vista la massa di richieste simili. Successivamente, ho compilato la frequenza di occorrenza degli indirizzi IP e ho esaminato manualmente l'intera parte superiore, separando coloro che non l'hanno vista nelle fasi precedenti. Inoltre, ho eliminato tutti i sorgenti che erano stati inviati in un unico pacchetto, non ce n'erano più molti. E questo è quello che è successo:
Una piccola digressione lirica. Poco più di un giorno dopo, il mio fornitore di hosting ha inviato una lettera dal contenuto piuttosto snello, dicendo che le vostre strutture contengono una risorsa dell'elenco proibito RKN, quindi è bloccata. All'inizio pensavo che il mio account fosse bloccato, non era così. Poi ho pensato che mi stessero semplicemente avvertendo di qualcosa che già sapevo. Ma si è scoperto che l'hoster ha attivato il filtro davanti al mio dominio e di conseguenza sono finito sotto un doppio filtro: da parte dei provider e da parte dell'hoster. Il filtro ha superato solo le estremità delle richieste: FIN-ACK и RST interrompendo tutto l'HTTP in un URL proibito. Come puoi vedere dal grafico sopra, dopo il primo giorno ho iniziato a ricevere meno dati, ma li ho comunque ricevuti, il che è abbastanza per il compito di contare le fonti delle richieste.
Arriva al punto. Secondo me, ogni giorno sono chiaramente visibili due raffiche, la prima più piccola, dopo la mezzanotte, ora di Mosca, la seconda più vicina alle 6 del mattino con una coda fino a mezzogiorno. Il picco non si verifica esattamente nello stesso momento. Inizialmente ho voluto selezionare gli indirizzi IP che cadevano solo in questi periodi e ciascuno in tutti i periodi, partendo dal presupposto che i controlli da parte degli Agenti vengono eseguiti periodicamente. Ma dopo un attento esame, ho subito scoperto che i periodi rientravano in altri intervalli, con altre frequenze, fino ad una richiesta ogni ora. Poi ho pensato ai fusi orari e che forse aveva qualcosa a che fare con essi, poi ho pensato che in generale il sistema potrebbe non essere sincronizzato a livello globale. Inoltre, probabilmente il NAT giocherà un ruolo e lo stesso Agent potrà effettuare richieste da diversi IP pubblici.
Dato che il mio obiettivo iniziale non era esattamente quello, ho contato tutti gli indirizzi che ho trovato in una settimana e ho ottenuto: 2791. Il numero di sessioni TCP stabilite da un indirizzo è in media 4, con una media di 2. Sessioni principali per indirizzo: 464, 231, 149, 83, 77. Il massimo dal 95% del campione è di 8 sessioni per indirizzo. La mediana non è molto alta, vi ricordo che il grafico mostra una chiara periodicità giornaliera, quindi ci si potrebbe aspettare qualcosa dai 4 agli 8 in 7 giorni. Se scartassimo tutte le sedute che si verificano una volta otterremo una mediana pari a 5. Ma non potevo escluderle in base ad un criterio chiaro. Al contrario, da un controllo casuale è emerso che si trattava di richieste di una risorsa vietata.
Gli indirizzi sono indirizzi, ma su Internet sistemi autonomi - AS, che si è rivelato più importante 1510, in media 2 indirizzi per AS con una mediana di 1. Indirizzi principali per AS: 288, 77, 66, 39, 27. Il massimo del 95% del campione è di 4 indirizzi per AS. In questo caso è prevista la media: un agente per fornitore. Ci aspettiamo anche il massimo: ci sono grandi giocatori. In una rete di grandi dimensioni, gli agenti dovrebbero probabilmente trovarsi in ciascuna regione in cui è presente l'operatore e non dimenticare il NAT. Se lo prendiamo per paese, i massimi saranno: 1409 - RU, 42 - UA, 23 - CZ, 36 da altre regioni, non RIPE NCC. Le richieste provenienti dall'estero attirano l'attenzione. Ciò può probabilmente essere spiegato da errori di geolocalizzazione o da errori del registrar durante la compilazione dei dati. Oppure il fatto che un'azienda russa potrebbe non avere radici russe o avere un ufficio di rappresentanza all'estero perché è più facile, il che è naturale quando si ha a che fare con un'organizzazione straniera RIPE NCC. Alcune parti sono indubbiamente superflue, ma è difficile separarle in modo affidabile, poiché la risorsa è sotto blocco e dal secondo giorno sotto doppio blocco e la maggior parte delle sessioni è solo uno scambio di diversi pacchetti di servizi. Siamo d'accordo che questa è una piccola parte.
Questi numeri possono già essere confrontati con il numero di fornitori in Russia. licenze per "Servizi di comunicazione per la trasmissione di dati, esclusa la voce" - 6387, ma questa è una stima molto alta dall'alto, non tutte queste licenze si applicano specificamente ai provider Internet che necessitano di installare un agente. Nella zona RIPE NCC esiste un numero simile di AS registrati in Russia - 6230, di cui non tutti sono fornitori. e ha accolto 3940 aziende nel 2017, e questa è piuttosto una stima dall’alto. In ogni caso abbiamo un numero di AS illuminati due volte e mezzo inferiore. Ma qui vale la pena capire che AS non è strettamente uguale al fornitore. Alcuni fornitori non hanno un proprio AS, altri ne hanno più di uno. Se assumiamo che tutti abbiano ancora degli agenti, allora qualcuno filtra più fortemente di altri, in modo che le loro richieste siano indistinguibili dalla spazzatura, sempre che raggiungano. Ma per una valutazione approssimativa è abbastanza tollerabile, anche se qualcosa è andato perso a causa della mia svista.
A proposito di DPI
Nonostante il mio hosting provider abbia attivato il filtro a partire dal secondo giorno, in base alle informazioni del primo giorno possiamo concludere che il blocco funziona correttamente. Solo 4 origini sono riuscite a passare e hanno completato completamente le sessioni HTTP e TCP (come nell'esempio sopra). È possibile inviarne altri 460 GET, ma la sessione viene immediatamente terminata da RST. prestare attenzione 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"
Le variazioni di questo possono essere diverse: meno RST o più ritrasmissioni - dipende anche da cosa il filtro invia al nodo sorgente. In ogni caso questo è il template più attendibile, dal quale risulta chiaro che si trattava di una risorsa vietata. Inoltre c'è sempre una risposta che appare nella sessione con TTL maggiore rispetto ai pacchetti precedenti e successivi.
Non puoi nemmeno vederlo dal resto 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 così:
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 differenza è sicuramente visibile TTL se qualcosa esce dal filtro. Ma spesso non arriva proprio nulla:
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 così:
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"
...
E tutto questo si ripete e si ripete e si ripete, come si può vedere nel grafico, più di una volta, ogni giorno.
Informazioni su IPv6
La buona notizia è che esiste. Posso affermare con certezza che le richieste periodiche a una risorsa vietata avvengono da 5 diversi indirizzi IPv6, che è esattamente il comportamento degli agenti che mi aspettavo. Inoltre uno degli indirizzi IPv6 non rientra nel filtraggio e vedo una sessione completa. Delle altre due ho visto solo una sessione incompiuta, una delle quali è stata interrotta da RST dal filtro, secondo nel tempo. Importo totale 7.
Dato che gli indirizzi sono pochi, li ho studiati tutti in dettaglio e ho scoperto che ci sono solo 3 fornitori, a loro si può fare una standing ovation! Un altro indirizzo è un cloud hosting in Russia (non filtra), un altro è un centro di ricerca in Germania (esiste un filtro, dove?). Ma perché controllano la disponibilità delle risorse vietate secondo un programma è una buona domanda. I restanti due hanno fatto una richiesta e si trovano fuori dalla Russia, e uno di loro è filtrato (in transito, dopotutto?).
Il blocco e gli agenti rappresentano un grosso ostacolo per IPv6, la cui implementazione non procede molto rapidamente. È triste. Coloro che hanno risolto questo problema possono essere pienamente orgogliosi di se stessi.
insomma
Non ho cercato una precisione al 100%, per favore perdonami per questo, spero che qualcuno voglia ripetere questo lavoro con maggiore precisione. Per me era importante capire se questo approccio avrebbe funzionato in linea di principio. La risposta è si. I dati ottenuti, in prima approssimazione, credo siano abbastanza attendibili.
Cos'altro si sarebbe potuto fare e quello che ero troppo pigro per fare era contare le richieste DNS. Non vengono filtrati, ma non forniscono molta precisione poiché funzionano solo per il dominio e non per l'intero URL. La frequenza dovrebbe essere visibile. Se lo combini con ciò che è visibile direttamente nelle query, ciò ti consentirà di separare ciò che non è necessario e ottenere più informazioni. È anche possibile determinare gli sviluppatori dei DNS utilizzati dai provider e molto altro ancora.
Non mi aspettavo assolutamente che l'hoster includesse anche un proprio filtro per il mio VPS. Forse questa è una pratica comune. Alla fine, RKN invia una richiesta per eliminare la risorsa all'hoster. Ma questo non mi ha sorpreso e per certi versi ha addirittura giocato a mio vantaggio. Il filtro ha funzionato in modo molto efficace, tagliando tutte le richieste HTTP corrette a un URL proibito, ma non sono arrivate quelle corrette che erano precedentemente passate attraverso il filtro del provider, anche se solo sotto forma di desinenze: FIN-ACK и RST - meno per meno e si è quasi rivelato un vantaggio. A proposito, IPv6 non è stato filtrato dall'hoster. Naturalmente ciò ha influito sulla qualità del materiale raccolto, ma ha comunque permesso di vedere la frequenza. Si è scoperto che questo è un punto importante quando si sceglie un sito per l'immissione di risorse, non dimenticare di interessarsi alla questione dell'organizzazione del lavoro con l'elenco dei siti vietati e delle richieste dell'RKN.
All'inizio ho confrontato l'AS "Inspector" con . Questo confronto è abbastanza giustificato e una vasta rete di agenti può essere vantaggiosa. Ad esempio, determinare la qualità della disponibilità delle risorse da diversi fornitori in diverse parti del paese. Puoi calcolare i ritardi, puoi costruire grafici, puoi analizzare tutto e vedere i cambiamenti che si verificano sia a livello locale che globale. Questo non è il modo più diretto, ma gli astronomi usano “candele standard”, perché non usare gli Agenti? Conoscendo (avendo trovato) il loro comportamento standard, puoi determinare i cambiamenti che si verificano intorno a loro e come ciò influisce sulla qualità dei servizi forniti. E allo stesso tempo, non è necessario posizionare autonomamente le sonde sulla rete, Roskomnadzor le ha già installate.
Un altro punto che voglio toccare è che ogni strumento può essere un’arma. AS "Inspector" è una rete chiusa, ma gli agenti consegnano tutti inviando richieste per tutte le risorse dall'elenco proibito. Disporre di una tale risorsa non presenta alcun problema. In totale, i fornitori attraverso gli agenti, involontariamente, dicono sulla loro rete molto di più di quanto probabilmente valga la pena: tipi DPI e DNS, posizione dell'agente (nodo centrale e rete di servizio?), indicatori di rete di ritardi e perdite - e questo è solo il più ovvio. Proprio come qualcuno può monitorare le azioni degli Agenti per migliorare la disponibilità delle proprie risorse, qualcuno può farlo per altri scopi e non ci sono ostacoli a questo. Il risultato è uno strumento a doppio taglio e molto sfaccettato, questo lo può constatare chiunque.
Fonte: habr.com