Non è un segreto che il controllo delle restrizioni sulla lista delle informazioni vietate in Russia sia svolto da un sistema automatizzato chiamato «Revisor». Come funziona è descritto bene in questo , immagine da lì:
Il modulo «Agente Revisor» viene installato direttamente presso il fornitore :
Il modulo «Agente Revisor» è un elemento strutturale del sistema automatizzato «Revisor» (AS «Revisor»). Questo sistema è progettato per controllare il rispetto delle normative da parte degli operatori di telecomunicazione riguardo alla limitazione dell'accesso secondo le disposizioni stabilite dagli articoli 15.1-15.4 della legge federale del 27 luglio 2006 n. 149-FZ «Sulle informazioni, sulle tecnologie dell'informazione e sulla protezione delle informazioni».
L'obiettivo principale della creazione dell'AS «Revisor» è garantire il monitoraggio del rispetto da parte degli operatori di telecomunicazione degli obblighi previsti dagli articoli 15.1-15.4 della legge federale del 27 luglio 2006 n. 149-FZ «Sulle informazioni, sulle tecnologie dell'informazione e sulla protezione delle informazioni», in merito all'individuazione di casi di accesso a informazioni vietate e alla raccolta di materiali (dati) probatori sulle violazioni relative alla limitazione dell'accesso a informazioni vietate.
Tenendo conto del fatto che, se non tutti, molti fornitori hanno installato questo dispositivo, dovrebbe essere emersa una grande rete di campionatori-faro come e anche di più, ma con accesso riservato. Tuttavia, un faro è pur sempre un faro e deve inviare segnali in tutte le direzioni, e se captassimo questi segnali e controllassimo cosa abbiamo catturato e quanto?
Prima di fare una stima, vediamo perché questo possa essere possibile.
Un po' di teoria
Gli agenti controllano la disponibilità delle risorse, incluso tramite 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"
La richiesta, oltre al payload, è composta anche dalla fase di instaurazione della connessione: scambio SYN e SYN-ACK, e dalla 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 unico 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 con precisione cosa bloccare. E prima di ciò, come mostrato sopra, deve verificarsi la fase di connessione, che può essere tentata di seguire, poiché è probabile che il filtro la ignori.
Per questo è necessario scegliere un dominio libero adatto con il tipo di blocco "per URL" e HTTP, per facilitare il lavoro del sistema di filtraggio, preferibilmente un dominio abbandonato da tempo, per minimizzare il traffico di curiosi, se non quello degli Agenti. Questo compito si è rivelato piuttosto semplice, ci sono molti domini liberi nel registro delle informazioni vietate e per tutti i gusti. Pertanto, il dominio è stato acquisito, collegato agli indirizzi IP su VPS con avviato tcpdump e ha avuto inizio il conteggio.
Revisione dei 'Revisori'
Mi aspettavo di vedere picchi periodici di richieste, ciò che a mio avviso avrebbe indicato un'azione gestita. Non si può dire che non l'abbia visto affatto, ma non c'era sicuramente un quadro chiaro:
Cosa che non sorprende affatto, anche su un dominio inutile e su un indirizzo IP mai utilizzato arriverà una massa di informazioni non richieste, così è il moderno Internet. Ma per fortuna, avevo bisogno solo delle richieste per un URL specifico, quindi tutti gli scanner e i cracker di password sono stati rapidamente individuati. È stato anche piuttosto facile capire dove si verificava il flooding a causa di una massa di richieste simili. Successivamente, ho composto le frequenze di apparizione degli indirizzi IP e ho esaminato manualmente tutta la topologia separando quelli che erano passati nelle fasi precedenti. Inoltre, ho tagliato tutte le fonti che avevano inviato un solo pacchetto, che non erano molte. E il risultato è stato questo:
Una piccola digressione lirica. Poco più di un giorno dopo, il mio provider di hosting ha inviato un'e-mail piuttosto generica, dicendo che sulle vostre risorse c'è materiale di una lista vietata del Roskomnadzor e quindi viene bloccato. All'inizio pensavo che avessero bloccato il mio account, ma non era così. Poi ho pensato che mi stessero semplicemente avvisando di qualcosa che già sapevo. Ma si è scoperto che l'host ha attivato il suo filtro prima del mio dominio e alla fine sono finito sotto un doppio filtraggio: da parte dei provider e da parte dell'host. Il filtro consentiva solo le estremità delle richieste: FIN-ACK e RST interrompendo tutto l'HTTP su URL vietati. Come si può vedere dal grafico sopra, dopo il primo giorno ho iniziato a ricevere meno dati, ma li ricevevo comunque, il che è stato sufficiente per il compito di conteggio delle fonti delle richieste.
Venendo al punto. A mio avviso, sono chiaramente visibili due picchi ogni giorno: il primo è più piccolo, dopo la mezzanotte secondo il fuso orario di Mosca, il secondo è vicino alle 6 del mattino con un prosieguo fino alle 12 di giorno. Il picco non si verifica esattamente alla stessa ora. All'inizio volevo isolare gli indirizzi IP che si trovavano solo in questi periodi e ciascuno in tutti i periodi, partendo dall'ipotesi che i controlli da parte degli Agenti siano eseguiti periodicamente. Ma con un'attenta osservazione, ho scoperto piuttosto rapidamente periodi che rientrano in altri intervalli, con altre frequenze, fino a una richiesta ogni ora. Poi ho pensato ai fusi orari e che forse era questo il problema; in seguito ho pensato che il sistema potrebbe non essere sincronizzato a livello globale. Inoltre, sicuramente il NAT giocherà un suo ruolo e lo stesso Agente potrebbe fare richieste da diversi IP pubblici.
Poiché il mio obiettivo iniziale non era l'accuratezza, ho contato tutti gli indirizzi che sono stati registrati nel corso della settimana e ho ottenuto — 2791. Il numero di sessioni TCP stabilite da un singolo indirizzo è in media 4, con una mediana di 2. Le sessioni top per indirizzo: 464, 231, 149, 83, 77. Il massimo dal campione del 95% è stato di 8 sessioni per indirizzo. La mediana non è molto alta, ricordo che dal grafico è evidente una periodicità giornaliera, quindi ci si poteva aspettare qualcosa intorno a 4-8 in 7 giorni. Se si escludono tutte le sessioni che si sono presentate una sola volta, si ottiene esattamente una mediana pari a 5. Tuttavia, non sono riuscito a escluderle in base a un criterio chiaro. Al contrario, un controllo campionario ha mostrato che hanno attinenza con le richieste di risorse vietate.
Gli indirizzi sono importanti, ma in Internet le autonomie delle reti — AS — hanno la priorità, e ne sono emerse 1510, in media 2 indirizzi per AS con una mediana di 1. I principali indirizzi per AS: 288, 77, 66, 39, 27. Il massimo su un campione del 95% è di 4 indirizzi per AS. Qui la mediana è attesa: un Agente per provider. Anche i principali sono previsti — con grandi attori. Nella grande rete, gli Agenti devono probabilmente trovarsi in ogni regione in cui è presente il provider, senza dimenticare il NAT. Se guardiamo ai paesi, i massimi saranno: 1409 — RU, 42 — UA, 23 — CZ, 36 da altre regioni, non RIPE NCC. Le richieste fuori dalla Russia attirano l'attenzione. Probabilmente, ciò può essere spiegato dagli errori di geolocalizzazione o dagli errori dei registratori nel compilare i dati. Oppure dal fatto che un'azienda russa può avere radici non russe, o avere una rappresentanza estera perché è più semplice, specialmente quando si ha a che fare con un'organizzazione estera come RIPE NCC. Una parte è certamente superflua, ma separarla in modo affidabile è difficile, dato che la risorsa è bloccata, e da due giorni è sotto doppio blocco e la maggior parte delle sessioni consiste solo nello scambio di alcuni pacchetti di servizio. Concordiamo sul fatto che questa sia una piccola parte.
Questi numeri si possono già confrontare con il numero di provider in Russia. le licenze per «Servizi di comunicazione per la trasmissione di dati, ad eccezione della voce» — 6387, ma si tratta di una stima molto ottimistica, non tutte queste licenze riguardano propriamente i provider Internet che devono avere un Agente. Nella zona RIPE NCC, un numero simile di AS registrati in Russia è 6230, dei quali non tutti sono provider. e ha ottenuto 3940 aziende nel 2017, e probabilmente è una stima ottimistica. In ogni caso, abbiamo un numero di AS visibili che è due volte e mezzo inferiore. Ma qui bisogna capire che un AS non corrisponde necessariamente a un provider. Alcuni provider non hanno un proprio AS, mentre alcuni ne hanno più di uno. Se supponiamo che gli Agenti siano presenti ovunque, significa che qualcuno filtra più degli altri, così da rendere le loro richieste indistinguibili dai rifiuti, se mai arrivano. Ma per una stima grossolana, va abbastanza bene, anche se qualcosa è stato perso a causa della mia disattenzione.
Su DPI
Nonostante il mio fornitore di hosting abbia attivato il proprio filtro a partire dal secondo giorno, dalle informazioni del primo giorno si può concludere che i blocchi funzionano efficacemente. Solo 4 fonti sono riuscite a superare il blocco e hanno sessioni HTTP e TCP completamente concluse (come nell'esempio sopra). Altre 460 possono inviare e username/password: admin/admin., 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 inviato dal filtro
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#E questo è il tentativo del nodo sorgente di ricevere 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 interrotta
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 invia il filtro al nodo sorgente. In ogni caso, questo è il modello più affidabile, da cui si vede che è stato richiesto proprio il recurso vietato. Inoltre, c'è sempre una risposta che appare nella sessione con TTL un valore più alto rispetto ai pacchetti precedenti e successivi.
Degli altri non si vede nemmeno e username/password: admin/admin.:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Questo è quanto inviato dal 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 è quanto inviato dal filtro
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"
#Ancora il filtro, molte volte
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
È sempre visibile la differenza in TTL se qualcosa arriva dal filtro. Ma spesso potrebbe non 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, sicuramente non una sola volta, ogni giorno.
Su IPv6
Una buona notizia: è presente. Posso affermare con certezza che ci sono richieste periodiche da 5 diversi indirizzi IPv6 verso risorse bloccate, 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 ciascuna, una delle quali si è interrotta a RST causa del filtro, l'altra per tempo. In totale, sono 7.
Poiché gli indirizzi sono pochi, li ho studiati in dettaglio e si è scoperto che in realtà ci sono solo 3 provider, a cui si può applaudire in piedi! Un altro indirizzo è un hosting cloud in Russia (non filtra), un altro è un centro di ricerca in Germania (c'è un filtro, dove?). Ma perché controllano periodicamente la disponibilità delle risorse bloccate è una buona domanda. Gli altri due hanno fatto una richiesta ciascuno e si trovano al di fuori della Russia, e uno di essi è soggetto a filtraggio (è nell'ambito del transito?).
I blocchi e gli Agenti sono un grande freno per IPv6, la cui implementazione comunque sta procedendo non molto rapidamente. È triste. Chi ha risolto completamente questo problema può essere orgoglioso di sé.
In conclusione
Non puntavo al 100% di accuratezza, vi prego di scusarmi per questo, spero che qualcuno voglia ripetere questo lavoro con maggiore attenzione. Per me era importante capire se tale approccio funzionasse in linea di principio. La risposta è sì. I numeri ottenuti in prima approssimazione, penso, siano abbastanza affidabili.
Cosa si potrebbe ancora fare e che ho trascurato di fare – contare le richieste a DNS. Non vengono filtrate, ma nemmeno offrono grande precisione poiché funzionano solo per il dominio, non per l'intero URL. La periodicità dovrebbe essere visibile. Se si combinasse con ciò che è visibile direttamente nelle richieste, questo permetterebbe di separare l'inutile e ottenere maggiori informazioni. Potrebbe anche essere possibile identificare gli sviluppatori di DNS utilizzati dai provider e molte altre cose.
Non mi aspettavo affatto che il mio VPS fosse soggetto a un filtro del provider. Forse è una pratica comune. Dopotutto, il Roskomnadzor invia una richiesta di rimozione della risorsa proprio al provider. Ma non mi ha sorpreso e ha persino in parte giocato a mio favore. Il filtro ha funzionato molto efficacemente bloccando tutte le richieste HTTP corrette verso l'URL bloccato, mentre quelle non corrette, passate prima attraverso il filtro dei provider, arrivavano, sebbene solo sotto forma di corti: FIN-ACK e RST — meno per meno e quasi un più. A proposito, l'host IPv6 non è stato filtrato. Certamente questo ha influito sulla qualità del materiale raccolto, ma ha comunque fornito l'opportunità di vedere la periodicità. Si è rivelato un punto importante nella scelta della piattaforma per la pubblicazione delle risorse, non dimenticate di informarvi sull'organizzazione del lavoro con l'elenco dei siti vietati e le richieste da parte del Roskomnadzor.
All'inizio ho confrontato il sistema AS «Rivisore» con . Questo confronto è del tutto giustificato e una grande rete di Agenti può portare vantaggio. Ad esempio, la determinazione della qualità di accesso alle risorse da parte di diversi fornitori in diverse parti del paese. Si possono calcolare i ritardi, costruire grafici, analizzare tutto questo e osservare i cambiamenti che avvengono sia localmente che globalmente. Non è il modo più diretto, ma gli astronomi utilizzano “candele standard”, perché non usare 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 disporre autonomamente i campionatori in rete, li ha già posizionati il Roskomnadzor.
Un altro aspetto che voglio toccare è che ogni strumento può essere un'arma. Il sistema AS «Rivisore» è una rete chiusa, ma gli Agenti tradiscono tutti inviando richieste a tutte le risorse dell'elenco vietato. Ottenere una risorsa di questo tipo non presenta nessun problema. Di conseguenza, i fornitori tramite gli Agenti, senza volere, rivelano molto di più sulla loro rete di quanto sarebbe opportuno: tipi di DPI e DNS, posizione dell'Agente (nodo centrale e rete di servizio?), marcatori di ritardo e perdita — e questo è solo il più ovvio. Così come qualcuno può monitorare le azioni degli Agenti per migliorare l'accessibilità delle proprie risorse, qualcuno potrebbe farlo per altri scopi e non ci sono ostacoli a questo. Si è rivelato uno strumento a doppio taglio e molto complesso, chiunque può verificarlo.
Fonte: habr.com
