Mettere un intero server Linux sotto controllo del codice sorgente (git)

Sto pensando di mettere tutto il mio server Linux sotto controllo di versione usando git. Il motivo è che potrebbe essere il modo più semplice per rilevare modifiche / rootkit dannosi. Tutto ciò che penserei ingenuamente è necessario per verificare l'integrità del sistema: montare la partizione Linux ogni settimana o giù di lì usando un sistema di salvataggio, verificare se il repository git non è ancora temperato e quindi emettere uno stato git per rilevare eventuali modifiche apportate al sistema .

A parte l'evidente spreco di spazio su disco, ci sono altri effetti collaterali negativi?

È un'idea totalmente folle?

È anche un modo sicuro per verificare i rootkit poiché molto probabilmente dovrei escludere / dev e / proc?

Questa è una "cattiva idea" (tm). A parte tutto il resto, il tuo repository funzionerà lentamente, ma peggiorerà man mano che viene mantenuta ogni revisione.

Prova la gestione centralizzata, come burattino / cfengine / chef. Ciò manterrà le cose come previsto e annullerà i cambiamenti inattesi.

Combinalo con qualcosa come iwatch per ricevere e-mail di modifiche non autorizzate ai file.

Combinalo ulteriormente con i file rpm / deb, se necessario, per distribuire applicazioni personalizzate.

Inserisci qualcosa come rkhunter o chkrootkit di tanto in tanto per i calci e dovresti essere bravo ad andare.

Lavoro fatto.

Un'altra alternativa è quella di impostare tripwire , che è il software GPL che controlla tutti i file importanti sul tuo sistema e determina quali sono cambiati in modi che hai definito inaccettabili. Il cambiamento può essere definito semplicemente come mtime, attraverso il numero di inode, fino a checksum crittograficamente forti.

Ci vuole un po 'di impostazione e messa a punto se non si desidera ottenere un sacco di rapporti ogni notte su file modificati /var/run, modifiche ai file client DHCP /etce simili, ma se si va a quel problema, può essere davvero molto utile.

Il database delle proprietà del file è firmato con una chiave non nota alla macchina, il che aiuta ad avere la certezza che nessuno strumento ha modificato maliziosamente il database o i file binari di tripwire. Per una certezza completa, è possibile masterizzare una copia degli strumenti e dei database tripwire su un supporto di sola lettura, che può essere montato sul server e utilizzato per verificare tutte le modifiche da quando il disco è stato masterizzato, se è necessaria un'analisi forense completa.

Se hai intenzione di farlo, è abbastanza importante configurare e far funzionare il tripwire prima che la macchina venga distribuita in produzione, oppure non puoi mai essere completamente sicuro che qualche utente malintenzionato non abbia avuto la possibilità di infettare la macchina prima di essa era cablato.

Non credo che probabilmente funzionerà, ma come esperimento mi piacerebbe vedere cosa succede se lo fai solo con la cartella / etc. È qui che viene conservata la maggior parte delle informazioni di configurazione.

@Sirex ha già fornito un'ottima risposta, ma se vuoi fare un passo avanti con la sicurezza, il modo migliore per affrontarla è prima la prevenzione e poi il rilevamento.

Prova a configurare un sistema con / filesystem montato in sola lettura. Crea / tmp un ramfs separato montato con noexec, opzione nodev. Affinché il sistema funzioni, è sufficiente montare / var solo su / var. Quindi sotto / var monta un fs con rw, noexec, nodev e rimuovi i permessi di scrittura su / var / tmp (a parte, è raramente necessario per i demoni e dovrebbe essere configurabile). Usa anche una patch di sicurezza per il tuo kernel per limitare ulteriormente l'accesso alle risorse da parte degli utenti, prova ad esempio grsec. Utilizzare un firewall con le regole più restrittive possibili.

Alcune distribuzioni forniscono un'ampia documentazione sull'indurimento del sistema. Per esempio:

• Protezione del manuale Debian
• Indurimento del Debian Wiki

Penso che sia una buona idea analizzare le modifiche apportate da uno strumento nel tuo sistema:

1. installa un Linux nudo in una VM
2. inizializza il root git
3. installa lo strumento che desideri analizzare
4. vedere tutte le modifiche apportate al rotolo nel sistema

... Elimina la VM

Dovresti aggiungere molte cartelle al .gitignore file anche se come proc, ecc.

Per le situazioni in cui sei solo interessato a mantenere determinate cartelle nell'intero filesystem sotto il controllo della versione, il seguente approccio potrebbe funzionare:

Innanzitutto, crea un repository Git a /livello:

$ cd /
# git init

Quindi creare un /.gitignoreche autorizza solo determinate cartelle, ad esempio solo per autorizzare /path/to/versioned/config/folder/(basato su /programming//a/11018557/320594 ):

/*
!/path/
/path/*
!/path/to/
/path/to/*
!/path/to/versioned/
/path/to/versioned/*
!/path/to/versioned/config/
/path/to/versioned/config/*
!/path/to/versioned/config/folder/
!/.gitignore

Quindi crea un primo commit:

# git add -A
# git commit -m "Initial commit"

E quindi aggiungere le cartelle aggiuntive che si desidera sotto controllo versione su richiesta.

PS:

Oltre al metodo precedente, se hai bisogno di mantenere / etc / sotto il controllo della versione, potresti preferire utilizzare etckeeper( https://etckeeper.branchable.com/ ) per il controllo delle versioni di quella cartella specifica in quanto è più specializzato a tale scopo ( ad es. si impegna automaticamente dopo l'installazione dei pacchetti).