Come scoraggiare un hacker con l'accesso root dall'eliminazione dei backup remoti?

Attualmente sto cercando la migliore soluzione di backup per il mio server CentOS, e sto pensando di andare con Tarsnap o straight-up Amazon S3.

Sto cercando di capire come scoraggiare un hacker da eliminare sia il mio contenuto di server che i miei backup remoti nel peggiore dei casi in cui guadagna l'accesso principale al mio server e quindi ha accesso alle credenziali di authentication remota di backup. (Capisco appieno l'importnza di avere una password forte e / o imporre solo l'authorization SSH basata su chiavi, come pure un'altra sicurezza generale di best practice. Ma roba a volte succede, potrebbe essere una vulnerabilità Linux o una vulnerabilità al livello VPS del mio ospite o qualcos'altro più o less dal mio controllo.)

So che sia Tarsnap che Amazon S3 dispongono di autorizzazioni utente di scrittura, ma il problema è che ho bisogno anche di potatura automatica / rotazione. Sarebbe ansible impostare uno di questi servizi (o forse un altro servizio) per impedire l'eliminazione delle generazioni di backup più recenti di, ad esempio, 2 giorni? Questo mi darebbe un buffer di due giorni per notare che sono stato hacked e impedire all'hacker di eliminare le mie ultime generazioni di dati.

Oppure altre idee? Molte grazie!

  • Le password generate dal computer sono protette?
  • Stampante di networking sfruttata (leggi: hacked) per la printing di documenti antisemiti. Come risolvere?
  • Come controllare il certificato TLS remoto del server SMTP?
  • certificati SSL da Rivenditori SSL - quali sono i rivenditori?
  • Come posso interrogare per tutti i contesti di file / file di selinux / etc predefiniti che interessano un tipo
  • Il sito è in linea con i bots di posta
  • / dev / shm & / proc indurimento
  • Esposizione di informazioni
  • 2 Solutions collect form web for “Come scoraggiare un hacker con l'accesso root dall'eliminazione dei backup remoti?”

    a livello fondamentale, il tuo problema è in parte aggravato spingendo i tuoi backup dall'host, piuttosto che tirarli fuori.

    È ansible risolvere il problema e, inoltre, fisicamente (o logicamente se necessario) disconnettere i volumi di backup nell'host di backup centrale.

    Ho macchine che spingono i backup a S3, ma i bucket di S3 usano la versione in modo che un attaccante che spinge un backup non è un problema (e le chiavi api utilizzate non hanno diritti di eliminazione degli oggetti, basta aggiungerli). I prune backup vecchi con boto come versione e il ciclo di vita della benna allo stesso tempo non è consentito).

    Nessun 'incentivo' sta lavorando, queste persone non si preoccupano dei tuoi dati.

    Beh, ho finito per andare con Duplicity poiché ha la sua interface Amazon S3. Ho creato un utente Amazon S3 tramite IAM con autorizzazioni limitate solo per gli oggetti GETting e PUTting. Sto utilizzando l'opzione --full-if-older-than Duplicity per creare un nuovo backup completo each 7 giorni. Allora ho in uso un sistema di vita ciclo automatico S3 che sposta gli oggetti più vecchi di 10 giorni al Ghiacciaio. Poi una regola secondaria elimina gli oggetti che sono più vecchi di 102 giorni dal Ghiacciaio (ho aggiunto un po 'più in più per assicurarmi di non avere successo con le tasse di cancellazione anticipate del ghiacciaio prima di 90 giorni). Quindi questo mi darà 80+ giorni di backup in Glacier (una volta che il backup completo più vecchio viene eliminato, i suoi incrementali figlio continueranno ad esistere per qualche giorno, ma non saranno validi più) e altri 10 giorni dei backup più recenti in S3 . Con aggiornamenti e compressioni differenziali i miei backup quotidiani sono piuttosto piccoli, quindi dovrebbe essere estremamente economico.

    Grazie a tutti per il loro aiuto e suggerimenti.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.