Possiamo fidarci delle informazioni visualizzate dai comandi di utilità linux per una macchina vulnerabile?

Poiché il sistema è compromesso, non ci si può fidare di nulla tramite strumenti. A meno che tu non abbia gli strumenti convalidati (es. Tripwire FIM ), la tua migliore scommessa è quello di prendere un sistema simile, copiare su ciò che è necessario, che dovrebbe essere eseguito se i sistemi sono simili in architettura, ecc. Questo non è tuttavia il metodo ottimale. Poiché la macchina è compromessa, in base ai passaggi successivi (legale, autorità, ecc.), Crei un'immagine forense, quindi gestisci ciò che è avvenuto quando hai la tua copia. Una volta ottenuta la copia, è necessario determinare il rischio associato al ripristino del sistema online, ecc.

Se hai determinato come un utente malintenzionato è entrato nel sistema, dovrai pulire quel 'buco' (vulnerabilità, errata configurazione) per essere sicuro che non tornino. A volte questo può richiedere più tempo rispetto all'installazione di un sistema pulito. Ma diciamo che hai bisogno di quel "sistema". È possibile reinstallare ps con qualcosa del tipo: apt-get install --reinstall procps lo stesso vale per lsof. Dovresti assicurarti che i tuoi repository non siano stati modificati e il tuo DNS non punta a un repository non attendibile.

Per la maggior parte per rispondere alla tua domanda: Possiamo fidarci delle informazioni visualizzate dai comandi di utilità linux la risposta è assolutamente non dovrebbe. Poco su quel sistema dovrebbe essere attendibile fino a quando non viene eseguita un'analisi approfondita.

Se il tuo sistema è stato compromesso, non dovresti fidarti di nulla .

Penso che in genere le utilità standard funzionino principalmente correttamente, ma tralasciano le informazioni relative ai processi dell'attaccante. I rootkit sono progettati in questo modo, quindi è meno probabile notare che la macchina è compromessa. Quindi penso che puoi generalmente fidarti di loro per osservare i tuoi processi, ma non per assicurarti che un rootkit sia sparito.

Se l'attaccante può caricare i moduli del kernel, o altrimenti modificare il kernel, anche le chiamate di sistema e l'API /proc possono mentire. Pertanto, anche una copia pulita delle utilità dello spazio utente come ps o grep foo /proc/*/cmdline non ti dirà se è in esecuzione un processo dannoso. Qualsiasi rootkit degno di questo nome nasconderà i suoi processi.

Ogni file dell'intero sistema è come uno spreco radioattivo , che può potenzialmente contaminare altre cose se non si presta attenzione. per esempio. un utente malintenzionato potrebbe aver aggiunto qualcosa a /home/*/.bashrc per reinfettare il sistema in caso di reinstallazione del sistema operativo ma non controllare /home .

Allo stesso modo, ci possono essere cose sgradevoli nella tua configurazione del server web, o nei tuoi script CGI, ecc. Confrontati con i backup e non presumere che nulla sia sicuro se l'autore dell'attacco potrebbe averlo toccato.

Effettuate sicuramente qualsiasi controllo di dati non attendibili su una macchina pulita conosciuta. Finché non si esegue nulla dal sistema compromesso, si dovrebbe essere ok. (cioè supponendo che cmp e diff non abbiano alcuna vulnerabilità., nota che strings non è sicuro su file non attendibili, a seconda della versione di libbfd . Utilizza strings -a .

Ho tirato fuori la mia sfera di cristallo e, Buona Novella !, nessuno di ps , netstat , top e lsof sono stati modificati! Infatti, nessuno dei comandi sul tuo sistema sono stati modificati dal rootkit ... tranne per bash . Tuttavia, bash intercetta le chiamate a tutte le altre utilità al fine di nascondere la presenza continua del rootkit modificando qualsiasi output prima di vederlo; potresti voler sapere che anche le chiamate a cp , echo , sudo e apt-get vengono intercettate.

Va tutto bene, però! Il rootkit ha anche sostituito udev e il modulo usbcore , quindi qualsiasi dispositivo USB collegato al sistema verrà infettato da BadUSB. Quindi la tastiera che hai collegato al server per eseguire il debug dalla console e la chiavetta USB utilizzata per spostare il database critico sul server di failover ora sono vettori per il rootkit nel resto della rete. Dovrebbero essere necessarie solo circa 48 ore prima che tutti i tuoi sistemi siano One con il rootkit. Sarà un paio di giorni dolorosi ma puoi rinunciare entro il fine settimana e goderti il sole sapendo che non devi più preoccuparti di amministrare i tuoi sistemi da solo.

Sì, un po 'esagerato. Ma davvero, se non sai esattamente cosa ha fatto il rootkit, allora cosa ha fatto il rootkit?

Probabilmente, ma non necessariamente. L'autore dell'attacco potrebbe sempre sostituire i programmi con versioni modificate di loro se avessero accesso root.

Sorprendentemente, contro tutte le leggi dell'universo, un'analogia basata sull'auto è inutile qui.

Tuttavia, un Invasione degli ultracorpi funziona per analogia.

Qualunque dei comandi del tuo sistema (o delle librerie da cui dipendono) può essere sostituito (e probabilmente lo è stato) con una copia che sembra e agisce quasi esattamente come l'originale ma ha anche lo scopo segreto di nascondere il compromesso esistente e / o assistere qualsiasi tentativo di compromesso futuro.

In breve, la risposta è "No, non puoi fidarti di nessuno dei programmi sul tuo sistema compromesso".