Domande di Linux forensics (ssh config, attività dell'utente)

Benvenuti nel mondo selvaggio e meraviglioso della medicina legale! Quindi hai le tue immagini. Prima di fare qualsiasi altra cosa assicurati di ottenere un checksum delle immagini del disco e di crearne una copia. La copia significa che puoi lavorare su di essa anziché sull'originale, permettendoti di tornare allo stato originale se cambi accidentalmente qualcosa nel sistema. L'hash ti consentirà di convalidare la tua copia di lavoro rispetto all'originale. Per questo scopo, qualsiasi algoritmo di hashing dovrebbe essere sufficiente.

Per capire veramente che cosa sta succedendo o che è andato avanti, in un sistema devi prima capire di cosa si tratta. È ovvio che stai guardando qualche forma di derivato UNIX, probabilmente un Linux, ma dovresti cercare di determinare a quale famiglia appartiene. È un RedHat, un Debian, un BSD, un Solaris o anche qualcosa di completamente diverso come AIX o HP-UX?

Il tipo di sistema che stai ispezionando determinerà esattamente quali file di registro è necessario sfogliare e come determinare dove sono archiviate le configurazioni. Il consiglio di iniziare in /var/log è piuttosto buono, ovvero la posizione di registro predefinita per i sistemi Linux. A seconda del gusto specifico, è possibile trovare anche informazioni utili in /var/log/audit dai sottosistemi di controllo (se installati) o dai sistemi RBAC / MAC come SELinux o AppArmor.

Rispondendo alle tue specifiche domande di configurazione, le informazioni sull'account sono memorizzate in un numero di file: /etc/passwd , /etc/shadow , /etc/group , /etc/gshadow . La costruzione di ciascuno è ben compresa e facilmente ricercabile. Per altri servizi, i file di configurazione specifici e la loro costruzione richiederanno sia la ricerca sia la comprensione basata sull'esperienza da parte tua.

L'esecuzione di una corretta indagine post-incidente richiede che si abbia una profonda comprensione del sistema che si sta analizzando. Non dovrai solo capire quali file guardare, ma anche quali file implicano cosa, come diverse configurazioni possono interagire tra loro e (quando intagli) come viene effettivamente costruito un filesystem. Essere stati gettati nella parte più profonda, per così dire, sarà faticoso, ma può essere gratificante. Non è senza merito che il mantra del team Offensive Security sia Try Harder ™. Anche se questo non è esattamente un lavoro offensivo, i principi si applicano sicuramente qui.

Il file principale per gli account utente è /etc/passwd . Se gli hacker hanno cercato di nascondere le loro tracce, potrebbero non aver creato una voce in /etc/shadow . Potrebbero non aver nemmeno creato una voce in /etc/passwd , ma in un altro database. Ciò avrebbe richiesto loro di aggiungere una voce alla riga passwd in /etc/nsswitch.conf .

Le voci in /etc/passwd e /etc/shadow compaiono nell'ordine in cui sono state aggiunte, se gli hacker hanno utilizzato i soliti strumenti per aggiungere account. Naturalmente possono averli modificati manualmente.

/etc/ssh/ssh_config (che può essere localizzato direttamente in /etc , questo dipende dalla distribuzione) è il file di configurazione a livello di sistema per il client SSH. C'è un file corrispondente sshd_config per il server SSH. Confronta questi file con l'impostazione predefinita della distribuzione.

Se non lo sai già, dovresti capire quale sia la distribuzione. Dato che hai una VM che puoi eseguire (assicurati di isolarla dalla rete e di conservare le copie dell'immagine originale!), Probabilmente visualizza un messaggio al momento dell'avvio. Con un'immagine disco, cerca file come /etc/redhat_release , /etc/debian_version , ecc. Si noti che questi file potrebbero indicare una derivata (ad esempio /etc/debian_version è presente anche su Ubuntu). Se esiste un comando lsb_release o un file /etc/lsb-release , ha le informazioni precise. Tutto ciò presuppone che nessuno abbia cercato di confondere le cose.

/var/log probabilmente contiene informazioni utili, ma trovarlo potrebbe essere difficile. La maggior parte delle azioni intraprese dagli hacker sono state registrate, ma potrebbero aver tentato di nascondere le loro tracce. Tuttavia, potrebbero non essere stati accurati. È difficile eliminare tutti i log incriminanti pur conservando quelli legittimi sufficienti a non rendere i registri sospetti: se non ci sono registri per un lungo periodo, mancano registri da cron jobs, ecc., Questo tende a indicare che qualcuno ha cancellato in modo massiccio un periodo di tempo.

Se gli hacker hanno modificato i file di log, le tracce del vecchio contenuto potrebbero rimanere nei settori non utilizzati. Gli strumenti di intaglio possono aiutarti a trovare questi settori.

"Altri shenanigans" possono includere cose come l'inserimento di un rootkit nel kernel (nel qual caso non è possibile fidarsi dei resoconti del sistema live, ma l'immagine del disco non mentirà, almeno non direttamente), nascondendo una shell di root di setuid da qualche parte, cambiando la password sull'account root (o aggiungendo un account con uid 0 e un altro nome), ...