🥇Cosa fare se il tuo provider viene visitato dai siloviki

kdpv — Reuters

Se hai affittato un server, non hai il controllo completo su di esso. Ciò significa che in qualsiasi momento al fornitore di hosting possono arrivare persone specialmente addestrate e chiedere di fornire i tuoi dati. E il fornitore li consegnerà se la richiesta è formalizzata secondo la legge.

Non vuoi assolutamente che i log del tuo server web o i dati degli utenti finiscano in mani sbagliate. Costruire una protezione ideale non è possibile. Difendersi da un fornitore di hosting che possiede l'iperchiavistore e ti fornisce una macchina virtuale è quasi impossibile. Ma, forse, è possibile ridurre un po' i rischi. La crittografia delle macchine affittate non è così inutile come sembra a prima vista. Diamo anche un'occhiata alle minacce derivanti dall'estrazione di dati dai server fisici.

Modello di minacce

Di norma, il fornitore di hosting cercherà di proteggere al massimo gli interessi del cliente, nel limite del possibile secondo la legge. Se nella lettera delle autorità ufficiali viene richiesta solo la log di accesso, il fornitore non fornirà dump di tutte le tue macchine virtuali con i database. Non dovrebbe, almeno. Se viene richiesta la totalità dei dati, il fornitore copierà i dischi virtuali con tutti i file e tu non lo saprai.

Indipendentemente dallo scenario degli eventi, il tuo obiettivo principale è rendere l'attacco troppo complesso e costoso. Di solito ci sono tre opzioni principali per la minaccia.

Ufficiale

Più spesso, all'ufficio ufficiale del fornitore di hosting viene inviato un documento cartaceo con la richiesta di fornire i dati necessari secondo il relativo decreto. Se tutto è formalizzato correttamente, il fornitore fornisce i log di accesso e altri dati alle autorità ufficiali. Di solito si chiede semplicemente di inviare i dati richiesti.

Occasionalmente, se necessario, i rappresentanti delle forze dell'ordine si recano personalmente nel Data Center. Ad esempio, quando hai un server dedicato e i dati possono essere prelevati solo fisicamente.

In tutti i paesi, per ottenere l'accesso a un'area privata, eseguire perquisizioni e altre operazioni è necessaria l'esistenza di prove che possano contenere informazioni rilevanti per un'indagine su un crimine. Inoltre, è richiesto un mandato di perquisizione redatto secondo tutti i regolamenti. Qui possono esserci particolarità legate alle normative locali. La cosa principale da capire è che, seguendo il giusto iter ufficiale, i rappresentanti della sicurezza non lasceranno passare nessuno oltre il punto di controllo.

Inoltre, nella maggior parte dei paesi non è possibile semplicemente strappare via attrezzature in funzione. Ad esempio, in Russia, fino alla fine del 2018, secondo l'articolo 183 del codice di procedura penale russo, parte 3.1, era garantito che durante le operazioni di sequestro, il prelievo di supporti elettronici di informazione veniva effettuato con la presenza di un esperto. Su richiesta del legittimo proprietario dei supporti elettronici di informazione o di chi detiene le informazioni contenute in essi, un esperto partecipante al sequestro, alla presenza di testimoni, copia le informazioni dai supporti elettronici su altri supporti elettronici.

Poi, sfortunatamente, questo punto è stato rimosso dall'articolo.

Segreto e non ufficiale

Questa è già un'area di operazione di agenti appositamente formati dell'NSA, FBI, MI5 e di altre organizzazioni con acronimi di tre lettere. Spesso, la legislazione dei paesi prevede poteri estremamente ampi per tali strutture. Inoltre, quasi sempre esiste un divieto legislativo su qualsiasi divulgazione diretta o indiretta del semplice fatto di cooperare con tali agenzie di sicurezza. In Russia esistono norme giuridiche analoghe. norme giuridiche.

In caso di una minaccia simile ai vostri dati, è quasi certo che verranno estratti. In questo contesto, oltre al semplice sequestro, possono essere utilizzati tutti gli strumenti non ufficiali, backdoor, vulnerabilità zero-day, estrazione di dati dalla memoria operativa della vostra macchina virtuale e altre 'delizie'. Il fornitore di hosting sarà obbligato a cooperare il più possibile con gli specialisti delle forze dell'ordine.

Dipendente disonesto

Non tutte le persone sono uguali. Alcuni degli amministratori del CED possono decidere di guadagnare vendendo i tuoi dati. Lo sviluppo degli eventi dipenderà dai suoi poteri e accessi. La cosa più spiacevole è che un amministratore con accesso alla console di virtualizzazione ha il pieno controllo sulle tue macchine. È sempre possibile creare uno snapshot insieme a tutto il contenuto della memoria RAM e poi studiarlo con calma.

VDS

Quindi, hai una macchina virtuale che ti è stata fornita dal provider. Come puoi organizzare la crittografia per proteggerti? In realtà, praticamente non puoi. Inoltre, anche un server dedicato esterno può finire per essere una macchina virtuale, alla quale sono stati collegati i dispositivi necessari.

Se lo scopo del sistema remoto non è solo l'archiviazione dei dati, ma l'esecuzione di calcoli, l'unica opzione per lavorare con una macchina non fidata sarà la realizzazione di crittografia omomorfica. In questo modo, il sistema eseguirà calcoli senza la possibilità di capire cosa stia facendo. Sfortunatamente, le spese generali per implementare tale crittografia sono così elevate che la loro applicazione pratica è attualmente limitata a compiti molto specifici.

Inoltre, nel momento in cui la macchina virtuale è accesa e sta eseguendo delle azioni, tutti i volumi crittografati si trovano in uno stato accessibile, altrimenti il sistema operativo semplicemente non potrebbe interagirci. Ciò significa che, avendo accesso alla console di virtualizzazione, puoi sempre creare uno snapshot della macchina in funzione ed estrarre tutte le chiavi dalla memoria RAM.

Molti fornitori hanno tentato di implementare la crittografia hardware della RAM affinché neanche il fornitore avesse accesso a questi dati. Ad esempio, la tecnologia Intel Software Guard Extensions, che organizza aree nella memoria virtuale protette dalla lettura e scrittura da parte di altri processi, incluso il kernel del sistema operativo. Sfortunatamente, non potrai fidarti completamente di queste tecnologie, poiché sarai limitato dalla tua macchina virtuale. Inoltre, ci sono già esempi concreti di attacco riuscito a questa tecnologia. Eppure, la crittografia delle macchine virtuali non è così inutile come potrebbe sembrare.

Crittografiamo i dati su VDS

Iniziamo col dire che tutto ciò che faremo di seguito non costituisce una protezione completa. L'iper-vettore permetterà di creare le copie necessarie senza fermare il servizio e senza che voi ve ne accorgiate.

Se l'hosting dovesse fornire un'immagine "fredda" della vostra macchina virtuale su richiesta, sarete relativamente al sicuro. Questo è lo scenario più comune.
Se l'hosting fornisce uno snapshot completo della macchina in funzione, la situazione è piuttosto grave. Tutti i dati saranno montati nel sistema in chiaro. Inoltre, ci sarà possibilità di setacciare la RAM in cerca di chiavi private e dati simili.

Per impostazione predefinita, se avete distribuito un sistema operativo da un'immagine vanilla, l'hosting non ha accesso root. Si può sempre montare un'unità con l'immagine di rescue e cambiare la password di root, eseguendo un chroot nell'ambiente della macchina virtuale. Ma questo richiederà un riavvio, che sarà notato. Inoltre, tutte le partizioni crittografate montate saranno chiuse.

Comunque, se la distribuzione della macchina virtuale avviene da un'immagine preparata in anticipo, l'hosting può spesso aggiungere un'account privilegiata per fornire assistenza in caso di emergenza al cliente. Ad esempio, per modificare una password di root dimenticata.

Anche nel caso di uno snapshot completo non è tutto così negativo. L'attaccante non riceverà file crittografati se li avete montati da un sistema di file remoto di un'altra macchina. Sì, teoricamente si può esaminare il dump della memoria e ricavare le chiavi di crittografia da lì. Ma in pratica è molto complicato e è altamente improbabile che il processo vada oltre una semplice trasmissione di file.

Richiediamo una macchina

Per i nostri scopi di test prendiamo una macchina semplice in sezione per la richiesta di server. Non abbiamo bisogno di molte risorse, quindi opteremo per l'opzione di pagamento per i megahertz e il traffico effettivamente consumati. Sarà sufficiente per fare delle prove.

Il classico dm-crypt dell'intera partizione non ha funzionato. Il disco per impostazione predefinita viene fornito in un blocco unico, con root su tutta la partizione. Ridurre la partizione ext4 montata con root è praticamente garantito che diventi un mattone al posto di un file system. Ho provato) Il tamburo non ha aiutato.

Creiamo un contenitore crittografico

Pertanto, non crittograferemo l'intera sezione, ma utilizzeremo contenitori crittografici, in particolare il sicuro VeraCrypt che ha superato un audit. Questo è sufficiente per i nostri scopi. Iniziamo scaricando e installando il pacchetto con la versione CLI dal sito ufficiale. Puoi anche controllare la firma.

wget https://launchpad.net/veracrypt/trunk/1.24-update4/+download/veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
dpkg -i veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb

Ora creeremo il contenitore da qualche parte nella nostra home, in modo da montarlo manualmente all'avvio. Nella versione interattiva, imposta le dimensioni del contenitore, la password e gli algoritmi di crittografia. Puoi scegliere il crittografo patriottico Grasshopper e la funzione hash Stribog.

veracrypt -t -c ~/my_super_secret

Ora installiamo nginx, montiamo il contenitore e carichiamo al suo interno informazioni segrete.

mkdir /var/www/html/images
veracrypt ~/my_super_secret /var/www/html/images/
wget https://upload.wikimedia.org/wikipedia/ru/2/24/Lenna.png

Modifichiamo leggermente /var/www/html/index.nginx-debian.html per ottenere la pagina desiderata e poter controllare.

Ci connettiamo e controlliamo

Il contenitore è montato, i dati sono accessibili e restituiti.

Ecco la macchina dopo il riavvio. I dati sono al sicuro in ~/my_super_secret.

Se è davvero necessario e si vuole un po' di hardcore, si può crittografare l'intero sistema operativo, in modo che al riavvio richieda una connessione ssh e l'immissione della password. Questo sarà sufficiente anche in uno scenario di semplice estrazione di "dati a freddo". Ecco le istruzioni per utilizzare dropbear e la crittografia remota dei dischi. Anche se nel caso di VDS è complicato e ridondante.

Bare metal

Non è semplice posizionare un proprio server in un centro dati. Un dedicato di terzi potrebbe essere una macchina virtuale, a cui sono connessi tutti i dispositivi. Ma in termini di sicurezza, qualcosa di interessante inizia quando hai la possibilità di collocare un tuo server fisico fidato in un centro dati. Qui puoi già utilizzare a pieno regime il tradizionale dm-crypt, VeraCrypt o qualsiasi altra crittografia a tua scelta.

Va compreso che nell'implementazione della crittografia totale, il server non potrà avviarsi autonomamente dopo un riavvio. Sarà necessario stabilire una connessione all'interfaccia locale IP-KVM, IPMI o un altro analogo simile. Dopodiché, inseriremo manualmente la chiave master. Lo schema appare piuttosto criticabile in termini di continuità e tolleranza ai guasti, ma non ci sono alternative significative qui, se i dati sono così preziosi.

NCipher nShield F3 Hardware Security Module

Una versione più morbida prevede che i dati siano crittografati e che la chiave si trovi direttamente nel server stesso all'interno di un HSM (Hardware Security Module) speciale. In genere, si tratta di dispositivi molto funzionali, che non solo forniscono crittografia hardware, ma hanno anche meccanismi per rilevare tentativi di effrazione fisica. Se qualcuno inizia a scavare nel tuo server con un flessibile, l'HSM con una fonte di alimentazione indipendente resetterà le chiavi che conserva nella sua memoria. All'attaccante rimarrà solo un miscuglio crittografato. In questo caso, il riavvio potrebbe avvenire automaticamente.

L'eliminazione delle chiavi è un'opzione molto più rapida e umana rispetto all'attivazione di una bomba a termiti o di un detonatore elettromagnetico. Per tali dispositivi, i tuoi vicini in sala server ti picchieranno a lungo. Tanto più che nel caso di utilizzo TCG Opal 2 la crittografia sui supporti stessi non comporta praticamente alcun overhead. Tutto ciò avviene in modo trasparente per il sistema operativo. Tuttavia, è necessario fidarsi del condizionale Samsung e sperare che ci sia un AES256 onesto e non un banale XOR.

Inoltre, non bisogna dimenticare che tutte le porte superflue devono essere fisicamente disabilitate o semplicemente riempite di compound. Altrimenti, dai la possibilità agli attaccanti di effettuare attacchi DMA.Se hai un PCI Express o un Thunderbolt che sporge, comprese le porte USB con supporto — sei vulnerabile. L'attaccante potrà effettuare un attacco attraverso queste porte e ottenere accesso diretto alla memoria contenente le chiavi.

In una variante molto sofisticata, l'attaccante può effettuare un attacco di cold boot. In questo caso, egli versa semplicemente una buona quantità di azoto liquido nel tuo server, estrae brutalmente i moduli di memoria congelati e ne estrae il dump con tutte le chiavi. Spesso, per effettuare l'attacco, è sufficiente uno spray refrigerante normale e temperature attorno ai -50 gradi. Esiste anche un'opzione più accurata. Se non hai disabilitato l'avvio da dispositivi esterni, allora l'algoritmo dell'attaccante sarà ancora più semplice:

Congelare i moduli di memoria senza aprire il case.
Collegare la propria chiavetta USB avviabile.
Utilizzare apposite utility per estrarre i dati dalla memoria RAM, che sono sopravvissuti al riavvio, grazie al congelamento.

Dividi e conquista

Va bene, abbiamo solo macchine virtuali, ma vogliamo comunque ridurre i rischi di perdita di dati.
In linea di principio, si potrebbe provare a rivedere l'architettura e a separare l'archiviazione dei dati e l'elaborazione in diverse giurisdizioni. Ad esempio, il frontend con le chiavi di crittografia presso il provider in Repubblica Ceca, e il backend con dati crittografati da qualche parte in Russia. In caso di tentativo standard di sequestro, è estremamente improbabile che le forze dell'ordine possano effettuare questo simultaneamente in diverse giurisdizioni. Inoltre, questo ci protegge parzialmente da uno scenario di cattura di snapshot.

Oppure si potrebbe considerare un'opzione completamente pulita: la crittografia End-to-End. Certamente, questo va oltre le specifiche e non prevede l'esecuzione di calcoli sul lato della macchina remota. Tuttavia, è un'opzione del tutto accettabile, se si parla di archiviazione e sincronizzazione dei dati. Ad esempio, è molto ben implementato nello stesso Nextcloud. In questo modo, la sincronizzazione, il versioning e altre funzionalità del server non andranno da nessuna parte.

Totale

Non esistono sistemi perfettamente protetti. L'obiettivo è solo rendere l'attacco più costoso del potenziale guadagno.

Un certo abbattimento dei rischi di accesso ai dati su un server virtuale può essere ottenuto combinando la crittografia e l'archiviazione separata presso diversi provider.

Un'opzione relativamente affidabile è l'utilizzo di un proprio server fisico.

E il provider dovrà comunque essere in qualche modo fidato. Su questo si regge l'intera industria.