Poiché il sistema è compromesso, non ci si deve fidare di nulla tramite gli strumenti. A meno che tu non abbia gli strumenti convalidati (ad es. Tripwire FIM), la soluzione migliore è prendere un sistema simile, copiare ciò che è necessario, che dovrebbe funzionare se i sistemi sono simili nell'architettura, ecc. Tuttavia, questo non è il metodo ottimale. Poiché la macchina è compromessa, a seconda dei tuoi prossimi passi (legali, autorità, ecc.), creerai un'immagine forense, quindi gestirai ciò che è accaduto mentre hai la tua copia. Una volta che hai la tua copia, devi determinare il rischio associato alla rimessa in linea del sistema, ecc.
Se hai determinato in che modo un utente malintenzionato è entrato nel sistema, dovresti ripulire quel "buco" (vulnerabilità, configurazione errata) per essere sicuro che non ritorni. A volte questo può richiedere più tempo rispetto all'installazione di un sistema pulito. Ma diciamo che hai bisogno di "quel" sistema. Puoi reinstallare ps con qualcosa come:apt-get install --reinstall procps lo stesso vale per lsof. Ti consigliamo di assicurarti che i tuoi repository non siano stati modificati e che il tuo DNS non punti a un repository non attendibile.
Per la maggior parte per rispondere alla tua domanda:Possiamo fidarci delle informazioni visualizzate dai comandi dell'utilità linux la risposta è che non dovresti assolutamente. 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 niente .
Penso che di solito le utilità standard funzionino per lo più correttamente, ma tralasciano le cose relative ai processi dell'attaccante. I rootkit sono progettati in questo modo, quindi è meno probabile che tu noti che la macchina è compromessa. Quindi penso che in genere ci si possa fidare di loro per esaminare i propri processi, ma non per assicurarsi che un rootkit sia stato eliminato.
Se l'attaccante può caricare i moduli del kernel, o modificare in altro modo il kernel, anche il sistema chiama e /proc L'API può mentire. Quindi 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 propri processi.
Ogni file sull'intero sistema è come scorie radioattive , che può potenzialmente contaminare altre cose se non stai attento. per esempio. un utente malintenzionato potrebbe aver aggiunto qualcosa a /home/*/.bashrc per reinfettare il tuo sistema nel caso in cui reinstalli il sistema operativo ma non selezioni /home .
Allo stesso modo, possono esserci cose sgradevoli nella configurazione del tuo server web, o nei tuoi script CGI, ecc. Confronta con i backup e non dare per scontato che nulla sia sicuro se l'attaccante potrebbe averlo toccato.
Sicuramente esegui qualsiasi controllo di dati non attendibili su una macchina nota e pulita. Finché non esegui nulla dal sistema compromesso, dovresti essere a posto. (ovvero supponendo cmp e diff non avere alcuna vulnerabilità. Ma nota che strings non lo è sicuro su file non attendibili, a seconda della versione di libbfd . Usa strings -a .
Probabilmente, ma non necessariamente. L'attaccante potrebbe sempre sostituire i programmi con le proprie versioni modificate se disponeva dell'accesso root.