Backup sicuro fuori sede, anche in caso di accesso root dell'hacker

Sto cercando un modo per implementare un modo più sicuro di eseguire un backup fuori sede che protegga anche i miei dati dalla situazione in cui un hacker malintenzionato ha ottenuto l'accesso root al mio server. Anche se la possibilità che ciò accada è inferiore rispetto ad altri tipi di rischi se SSH e la sicurezza della password sono impostate correttamente e il sistema è tenuto adeguatamente aggiornato, l'entità del danno che può essere fatto in modo permanente è davvero elevata e quindi io Vorrei trovare una soluzione per limitarlo.

Ho già provato due modi di backup fuori sede:

• un semplice mount webdav scrivibile da root (e configurato in fstab) in cui vengono copiati i dati di backup. Problema : non proprio un backup offsite perché la connessione - e inoltre l'accesso - alla posizione offsite viene costantemente lasciata aperta come una cartella nel filesystem. Questa è una protezione sufficiente contro molti tipi di attacchi se il mount ha privilegi di accesso limitati (accesso di sola lettura root), ma non protegge da una persona malintenzionata con accesso root.

• Backup Borg tramite SSH con autenticazione chiave. Problema : la connessione a quel server offsite può essere effettuata con la chiave memorizzata sull'host se l'utente malintenzionato ha accesso root all'host.

Come soluzione sto pensando a questi potenziali modi, ma non so come e con cosa:

• I backup possono essere solo scritti o aggiunti alla destinazione ma non eliminati.
• L'uso di software di backup che gestisce i backup offsite e non supporta l'eliminazione di massa dei backup offsite dal primo host.

Soluzioni che non sono davvero interessanti nella mia situazione:

• Un processo di backup aggiuntivo sull'host fuori sede che li trasferisce in una posizione non accessibile dal primo host (a causa di limitazioni tecniche).

Qualcuno può dare consigli su come implementare un backup offsite adeguato per il mio caso?

Tutti i tuoi suggerimenti attualmente hanno una cosa in comune: l'origine del backup esegue il backup e ha accesso alla destinazione del backup. Indipendentemente dal fatto che tu monti la posizione o usi strumenti come SSH o rsync, il sistema di origine in qualche modo ha accesso al backup. Pertanto, un compromesso sul server potrebbe compromettere anche i backup.

Cosa succede se invece la soluzione di backup ha accesso al server? Il sistema di backup può fare il suo lavoro con un accesso di sola lettura, quindi qualsiasi compromesso sul sistema di backup probabilmente non comprometterebbe il server. Inoltre, il sistema di backup potrebbe essere dedicato solo a tale scopo, rendendo il contenuto del backup l'unico vettore di attacco. Sarebbe molto improbabile e richiederebbe un attacco davvero sofisticato.

Per evitare di sovrascrivere i backup con contenuti manomessi o danneggiati, eseguire backup incrementali che consentono di ripristinare qualsiasi stato precedente entro il periodo di ripristino definito.

Archiviazione immutabile

Una buona opzione è rendere immutabile l'archiviazione di backup, o almeno fornire un controllo delle versioni affidabile che offra effettivamente l'immutabilità. Per essere chiari: immutabile significa incapace di essere cambiato o permanente.

Esistono più servizi che possono farlo per te. AWS S3, BackBlaze B2 e sospetto che Azure e Google offrano entrambi un servizio simile. Probabilmente potresti configurare un server per farlo, ma non sono sicuro di come.

Quando si dispone di un repository immutabile / controllato con la versione, è possibile ripristinare il backup in qualsiasi momento, quindi se l'host è compromesso è comunque possibile ripristinare come in qualsiasi momento.

* AWS S3 **

Conosco molto bene AWS S3. S3 offre storage crittografato e con versione, con un elevato livello di durabilità.

S3 supporta il controllo delle versioni, che offre un'immutabilità effettiva. Puoi scegliere di utilizzare le regole del ciclo di vita per eliminare la vecchia versione dei file dopo un periodo di tempo che puoi configurare. Puoi anche archiviare le versioni in celle frigorifere (glacier cold archive), che costano circa $ 1 / TB / mese.

È possibile utilizzare la classe di tiering dello storage intelligente per ridurre i costi. Ho scelto di utilizzare una regola del ciclo di vita per spostare tutti i dati statici nella classe di accesso non frequente, che è una prestazione durevole e moderata (a caldo) ma non ha la scalabilità o le prestazioni dello standard S3.

S3 utilizza utenti e criteri IAM (gestione dell'accesso alle identità, ovvero gestione degli utenti). Questo ti dà un controllo molto granulare di ciò che il tuo software di backup può fare con la tua memoria. Puoi concedere all'utente di backup l'autorizzazione per i caricamenti ma negare l'aggiornamento e l'eliminazione. È inoltre possibile richiedere l'autenticazione a più fattori per eliminare i file o persino fornire un blocco degli oggetti in modo che i file non possano essere eliminati.

Software suggerito

Creo backup incrementali utilizzando Restic . Restic carica i nuovi file nella posizione di archiviazione. Credo (ma potrei essere errato) che crea nuovi file, ma in generale non aggiorna o elimina alcun file.

Borg è un'altra opzione. Usavo Borg, ma ho scoperto che con i miei backup di dimensioni moderate di centinaia di MB ha effettivamente caricato tutti i miei dati ogni giorno da EC2 a S3. Per me questo non è incrementale, quindi ho smesso di usarlo. Ho trovato documentazione su questo, ma non ho il link.

Esistono dozzine di software che possono essere caricati su cloud storage.

Archiviazione protetta

Con alcuni software di backup potresti provare a concedere all'utente IAM il permesso di scrivere nuovi file ma non di aggiornare i file esistenti. È facile applicare questa restrizione con AWS IAM, ma secondo il commento di seguito Restic non funzionerà con tali autorizzazioni. È inoltre possibile richiedere l'autenticazione a più fattori per l'eliminazione dei file da S3.

Potresti avere un altro utente IAM, eseguito da dire il tuo PC, che esegue la pulizia periodica dell'archivio, scartando le versioni secondo il criterio impostato.

Borg Backup supporta repository remoti solo append . Qualsiasi compromissione del backup del server può comportare solo la creazione di nuovi backup, non sovrascrivere solo quelli precedenti.

Soluzioni che non sono davvero interessanti nella mia situazione:

Un processo di backup aggiuntivo sull'host fuori sede che li trasferisce in una posizione non accessibile dal primo host.

Il problema fondamentale è che se riesci ad accedere in remoto ai tuoi backup, anche l'hacker può farlo .

(A causa di limitazioni tecniche)

Le limitazioni tecniche sono fatte per essere superate.

Qualcuno può dare consigli su come implementare un backup offsite adeguato per il mio caso?

Le unità a nastro offrono una protezione sicura e off-site da tutti i tipi di catastrofi, compresi gli hacker, da quasi 70 anni.

Puoi utilizzare servizi di archiviazione come AWS S3 (o probabilmente l'equivalente di Google o di Azure) in cui puoi assegnare le autorizzazioni PUT al tuo account di root al tuo bucket ma non le autorizzazioni DELETE. In questo modo, è possibile utilizzare un modello push e l'attaccante non sarà in grado di eliminare il backup.

Esistono ulteriori misure di sicurezza che è possibile adottare con AWS, come la richiesta di AMF per eseguire DELETE sul bucket, ma consentire PUT e GET senza AMF. In questo modo, è possibile sia eseguire il backup dei dati sia recuperarli per ripristinare i servizi senza utilizzare il dispositivo MFA, il che potrebbe essere utile in alcuni casi estremi (e probabilmente troppo oscuri per menzionarli) in cui l'accesso al dispositivo MFA potrebbe comprometterlo.

Inoltre, un commento fuori campo che potresti trovare interessante / utile, ci sono diversi modi per configurare S3 e servizi simili per il failover automatico nel caso in cui l'origine dati principale non sia in linea.

Backup Borg tramite SSH con autenticazione chiave. Problema: la connessione a quel server fuori sede può essere effettuata con la chiave archiviata sull'host se l'utente malintenzionato ha accesso root all'host.

È possibile utilizzare il comando opzione nei tasti di autorizzazione. Risolvi il comando consentito in remoto.

come aggiungere comandi in ssh authorized_keys

Anche se un utente malintenzionato recupera la radice di accesso, non sarà in grado di fare altro che il comando definito.

Una tecnica che è possibile impostare consiste nell'utilizzare la sincronizzazione tra il server e un server di backup remoto e consentire al server di backup remoto di eseguire istantanee o qualsiasi altra cosa alla sua estremità in modo che la cancellazione del lato server non comporti la cancellazione fuori sede.