Non è un segreto che il controllo dei blocchi secondo l'elenco delle informazioni vietate in Russia sia gestito da un sistema automatizzato chiamato «Revisor». Come funziona è descritto bene in questo , immagine presa da lì:
Direttamente presso il fornitore viene installato :
Il modulo «Agente Revisor» è un elemento strutturale del sistema automatizzato «Revisor» (AS «Revisor»). Questo sistema è progettato per controllare il rispetto da parte degli operatori di telecomunicazione delle normative che limitano l'accesso secondo le disposizioni stabilite dagli articoli 15.1-15.4 della Legge Federale del 27 luglio 2006 n. 149-FZ «Sulle informazioni, le tecnologie dell'informazione e la protezione delle informazioni».
L'obiettivo principale della creazione del sistema "Revisore" è garantire il monitoraggio del rispetto da parte degli operatori di telecomunicazione dei requisiti stabiliti dagli articoli 15.1-15.4 della legge federale del 27 luglio 2006 n. 149-FZ "Sulle informazioni, le tecnologie dell'informazione e la protezione delle informazioni" in merito all'identificazione dei fatti di accesso a informazioni vietate e alla raccolta di materiali (dati) a conferma delle violazioni relative al divieto di accesso a tali informazioni.
Dato che se non tutti, molti fornitori hanno installato questo dispositivo, avrebbe dovuto crearsi una vasta rete di campioni-buoy simile a e anche di più, ma con accesso chiuso. Tuttavia, un buoy è sempre un buoy, per inviare segnali in tutte le direzioni; e se li prendessimo e vedessimo cosa abbiamo catturato e quanto?
Prima di contare, vediamo perché questo potrebbe essere possibile.
Un po' di teoria
Gli agenti verificano la disponibilità delle risorse, anche attraverso richieste HTTP(S), come questa ad esempio:
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"
Una richiesta, oltre al payload, include anche la fase di creazione della connessione: lo scambio SYN e SYN-ACK, e la fase di chiusura della connessione: FIN-ACK.
Il registro delle informazioni vietate contiene diversi tipi di blocchi. È evidente che se una risorsa viene bloccata per indirizzo IP o nome di dominio, non vedremo alcuna richiesta. Questi sono i tipi di blocco più distruttivi, che portano all'inaccessibilità di tutte le risorse su un singolo 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 HTTP della richiesta per determinare esattamente cosa bloccare. Prima di ciò, come mostrato sopra, deve avvenire la fase di creazione della connessione, che può essere tracciata, poiché è probabile che il filtro la lasci passare.
Per questo, è necessario scegliere un dominio libero adatto con un tipo di blocco «per URL» e HTTP, per facilitare il lavoro del sistema di filtraggio. È preferibile che sia un dominio abbandonato da tempo, per minimizzare il traffico indesiderato oltre a quello proveniente dagli Agenti. Questa operazione si è rivelata molto semplice, poiché ci sono molti domini disponibili nel registro delle informazioni vietate, adatti a ogni gusto. Pertanto, il dominio è stato acquistato e collegato agli indirizzi IP su un VPS attivo. tcpdump e è iniziato il conteggio.
Revisione «Revisori»
Mi aspettavo di vedere picchi periodici di richieste, il che indicava secondo me un'azione gestita. Non si può dire che non l'abbia affatto notato, ma non c'era sicuramente un quadro chiaro:
Non sorprende che anche su un dominio ignorato con un IP mai utilizzato arrivino semplicemente un sacco di informazioni non richieste; questo è l'Internet moderno. Fortuntamente, avevo bisogno solo delle richieste per un URL specifico, quindi tutti gli scanner e i tentativi di accesso sono stati rapidamente identificati. Inoltre, è stato abbastanza facile capire dove si trovasse il flood di richieste simili. Poi, ho creato un'analisi delle frequenze degli indirizzi IP e ho esaminato tutti i dati manualmente, separando quelli che erano passati nelle fasi precedenti. Ho anche rimosso tutte le fonti che avevano inviato solo un pacchetto; non erano molte. Ed ecco cosa è emerso:
Una piccola digressione. Poco più di un giorno dopo, il mio fornitore di hosting mi ha inviato una lettera piuttosto evasiva, dicendo che sui vostri server ci sono risorse da un elenco proibito dell'RKN, quindi vengono bloccate. All'inizio ho pensato che avessero bloccato il mio account, ma non era così. Poi ho pensato che mi stessero semplicemente avvisando di qualcosa che già conoscevo. Ma si è scoperto che l'hoster ha attivato il suo filtro prima del mio dominio e alla fine sono stato soggetto a una doppia filtrazione: da parte dei fornitori e da quella dell'hoster. Il filtro passava solo le estremità delle richieste: FIN-ACK e RST tagliando tutto l'HTTP per URL vietati. Come si può vedere dal grafico sopra, dopo le prime 24 ore ho iniziato a ricevere meno dati, ma continuavo a riceverli, il che era sufficiente per il compito di contare le sorgenti delle richieste.
Parlando chiaro, sono fermamente convinto che si notino due picchi ogni giorno: il primo, più basso, dopo la mezzanotte secondo l'orario di Mosca, e il secondo, più significativo, intorno alle 6 del mattino, con un prolungamento fino a mezzogiorno. Il picco non si verifica esattamente alla stessa ora. Inizialmente, avevo intenzione di evidenziare solo gli indirizzi IP che rientravano in questi intervalli, e quelli che si presentavano in tutti i periodi, sulla base dell'ipotesi che i controlli da parte degli agenti avvengano periodicamente. Tuttavia, esaminando con attenzione, ho rapidamente scoperto periodi che rientrano in altri intervalli, con frequenze diverse, arrivando fino a una richiesta ogni ora. Poi ho pensato ai fusi orari e che questo potesse influire, quindi ho considerato che il sistema potrebbe non essere sincronizzato a livello globale. Inoltre, sicuramente il NAT gioca un ruolo, e lo stesso agente potrebbe effettuare richieste da diversi IP pubblici.
Poiché il mio obiettivo iniziale non era l'accuratezza, ho considerato tutti gli indirizzi che si sono presentati nell'arco di una settimana e ho ottenuto — 2791. Il numero medio di sessioni TCP stabilite da un singolo indirizzo è di 4, con una mediana di 2. I principali indirizzi di sessione sono: 464, 231, 149, 83, 77. Il massimo dal campione del 95% è di 8 sessioni per indirizzo. La mediana non è molto alta; ricordo che dal grafico si nota una chiara periodicità giornaliera, quindi ci si potrebbe aspettare qualcosa tra 4 e 8 sessioni in 7 giorni. Se escludiamo tutte le sessioni che si sono verificate una sola volta, otteniamo esattamente una mediana pari a 5. Tuttavia, non sono riuscito a escluderle su una base chiara. Al contrario, il controllo campionario ha mostrato che sono collegate a richieste di risorse vietate.
Indirizzi a parte, ciò che conta su Internet sono i sistemi autonomi — AS, che sono emersi 1510, in media 2 indirizzi per AS con una mediana di 1. I principali indirizzi su AS: 288, 77, 66, 39, 27. Il massimo del campione del 95% è di 4 indirizzi su AS. Qui la mediana è prevista: un Agente per fornitore. Anche il top è previsto: contiene grandi attori. In una grande rete, gli Agenti dovrebbero probabilmente essere presenti in ogni regione in cui opera l'operatore, senza dimenticare il NAT. Se consideriamo i vari paesi, i massimi saranno: 1409 — RU, 42 — UA, 23 — CZ, 36 da altre regioni, non RIPE NCC. Le richieste non provenienti dalla Russia attirano l'attenzione. Probabilmente, questo può essere spiegato da errori di geolocalizzazione o errori dei registrar nel completamento dei dati. Oppure dal fatto che un'azienda russa può avere radici non russe o avere una rappresentanza straniera, poiché è più semplice trattando con l'organizzazione straniera RIPE NCC. Una certa parte è indubbiamente superflua, ma separarla con precisione è difficile, poiché la risorsa è bloccata, e dalla seconda giornata è sotto doppio blocco e la maggior parte delle sessioni consiste solo nello scambio di pochi pacchetti di servizio. Concordiamo sul fatto che si tratti di una piccola parte.
Questi numeri possono già essere confrontati con il numero di fornitori in Russia. le licenze per "Servizi di comunicazione per la trasmissione di dati, eccetto la voce" sono 6387, ma questa è una stima significativamente sovrastimata, non tutte queste licenze riguardano effettivamente i provider Internet che devono installare l'Agente. Nella zona del RIPE NCC è registrato un numero simile di AS in Russia, pari a 6230, di cui non tutti sono provider. e ha ottenuto 3940 aziende nel 2017, e questa è più un'adeguata stima. In ogni caso, abbiamo un numero di AS visibili che è due volte e mezzo inferiore. Tuttavia, è importante capire che AS non equivale strettamente a un provider. Alcuni provider non possiedono un AS proprio, mentre altri ne hanno più di uno. Se si presume che gli Agenti siano presenti ovunque, significa che qualcuno filtra più degli altri, al punto che le loro richieste diventano indistinguibili dalla spazzatura, se arrivano. Ma per una stima grossolana va bene, anche se qualcosa è andato perso a causa della mia negligenza.
Riguardo al DPI
Sebbene il mio provider di hosting abbia attivato il proprio filtro dal secondo giorno, le informazioni del primo giorno indicano che i blocchi funzionano con successo. Solo 4 fonti sono riuscite a passare e hanno sessioni HTTP e TCP completamente completate (come nell'esempio sopra). Altre 460 potrebbero inviare GET, ma la sessione si interrompe immediatamente per RST. Nota che 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"
#Questo è quanto ha inviato il filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#E questa è un tentativo del nodo sorgente di ottenere una perdita
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"
#Il nodo sorgente comprende che la sessione è stata distrutta
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Le varianti di questo possono essere diverse: meno RST o più retransmission — dipende anche da cosa il filtro invia al nodo sorgente. In ogni caso, questo è il modello più affidabile, da cui si vede che è stata richiesta proprio la risorsa vietata. Inoltre, c'è sempre una risposta che appare nella sessione con TTL più rispetto ai pacchetti precedenti e successivi.
Dagli altri non si vede nemmeno GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Questo è quello che ha inviato il filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Oppure 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"
#Questo è quello che ha inviato il filtro
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
TTL 50, TCP ACKed segmento invisibile, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed segmento invisibile, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
#Ancora il filtro, molte volte
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
È sicuramente visibile la differenza in TTL se qualcosa proviene dal filtro. Ma spesso non può arrivare 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"
...
Oppure così:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Sono passati alcuni secondi senza traffico
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 vede nel grafico, non proprio una volta, ma ogni giorno.
Riguardo a IPv6
La buona notizia è che esiste. Posso confermare che da 5 diversi indirizzi IPv6 ci sono richieste periodiche verso una risorsa vietata, esattamente il comportamento degli Agenti che mi aspettavo. Inoltre, uno degli indirizzi IPv6 non è soggetto a filtraggio e vedo una sessione completa. Da altri due ho visto solo una sessione incompleta, una delle quali si è interrotta per RST motivi di filtraggio, l'altra per il tempo. In totale, ci sono 7.
Poiché ci sono pochi indirizzi, ho esaminato tutti in dettaglio e ho scoperto che i fornitori sono solo 3, ai quali si può applaudire in piedi! Un altro indirizzo appartiene a un hosting cloud in Russia (non filtra), un altro a un centro di ricerca in Germania (c'è un filtro, dove?). Ma perché controllano regolarmente l'accessibilità delle risorse vietate è una buona domanda. Gli altri due hanno effettuato una richiesta ciascuno e non si trovano entro i confini della Russia, e uno di essi è filtrato (forse sul transito?).
Le blocchi e gli agenti rappresentano un grande ostacolo per IPv6, la cui implementazione, già di per sé lenta, sta subendo ulteriori ritardi. È davvero un peccato. Coloro che hanno risolto completamente questo problema possono esserne fieri.
In conclusione
Non ho cercato la perfezione al 100%, vi chiedo di scusarmi per questo; spero che qualcuno voglia ripetere questo lavoro con maggiore accuratezza. Per me era importante capire se questo approccio avrebbe potuto funzionare. La risposta è sì. I numeri ottenuti sono una prima approssimazione e, a mio avviso, sono abbastanza affidabili.
Cosa si potrebbe fare di più e cosa ho trascurato — calcolare le query DNS. Queste non vengono filtrate, ma non forniscono grande precisione poiché funzionano solo per il dominio e non per l'intero URL. La periodicità dovrebbe essere evidente. Combinando ciò che si osserva direttamente nelle query, si potrebbe separare il superfluo e ottenere ulteriori informazioni. Potrebbe addirittura essere possibile identificare i fornitori di DNS utilizzati dai provider e molto altro ancora.
Non mi aspettavo affatto che il mio host VPS includesse anche il proprio filtro. Forse è una pratica comune. Dopotutto, il RKN invia richieste di rimozione risorsa proprio all'host. Ma non mi ha sorpreso e, anzi, è stato anche utile in qualche modo. Il filtro ha funzionato molto efficacemente eliminando tutte le richieste HTTP corrette verso l'URL vietato, mentre quelle errate, passate prima attraverso il filtro dei provider, sono arrivate, sebbene solo in forma di conclusioni: FIN-ACK e RST — meno su meno è quasi un più. A proposito, l'host non ha filtrato l'IPv6. Certo, questo ha influito sulla qualità del materiale raccolto, ma ha comunque offerto l'opportunità di vedere la periodicità. Si è rivelato un punto importante nella scelta della piattaforma per la collocazione delle risorse; non dimenticate di informavi sulla questione dell'organizzazione del lavoro con l'elenco dei siti vietati e le richieste del RKN.
All'inizio ho confrontato l'AS "Revisore" con . Questo confronto è del tutto giustificato e una rete vasta di Agenti può portare benefici. Ad esempio, determinare la qualità della disponibilità delle risorse da diversi fornitori in varie parti del paese. Si possono calcolare i ritardi, si possono costruire grafici, si può analizzare tutto questo per osservare i cambiamenti in atto sia a livello locale che globale. Non è il percorso più diretto, ma gli astronomi usano le “candele standard”, perché non utilizzare gli Agenti? Conoscendo (trovando) il loro comportamento standard, è possibile determinare i cambiamenti che avvengono attorno a loro e come questo influisce sulla qualità dei servizi forniti. E in questo caso non è necessario posizionare autonomamente i campionatori nella rete, sono già stati installati dal Roskomnadzor.
Un altro aspetto che voglio menzionare è che ogni strumento può diventare un'arma. L'AS 'Revisore' è una rete chiusa, ma gli Agenti rivelano tutto, inviando richieste a tutte le risorse della lista nera. Ottenere tale risorsa non presenta alcun problema. Di conseguenza, i fornitori, tramite gli Agenti, raccontano molto più della loro rete di quanto avrebbero dovuto: tipi di DPI e DNS, posizione dell'Agente (nodo centrale e rete di servizio?), marcatori di rete per ritardi e perdite — e questo è solo il più ovvio. Così come qualcuno può monitorare le azioni degli Agenti per migliorare l'accessibilità delle proprie risorse, qualcun altro può farlo per altri scopi e non ci sono ostacoli a questo. Si tratta di uno strumento a doppio taglio e molto complesso, dal quale chiunque può trarre conclusioni.
Fonte: habr.com
