Perché è possibile per l'utente root cancellare i log?

Why is it possible for the root user to delete the logs?

Perché devi essere in grado di gestire il server.

Whats stopping a hacker with root access from deleting the logs in order to cover their tracks?

Per quanto riguarda la registrazione locale, solo la loro stupidità. Per quanto riguarda la registrazione esterna, il loro set di abilità e il tuo.

Ci sono molti, molti modi diversi per "accedere". In effetti, si potrebbe fare in modo che il log della macchina di root si colleghi a un dispositivo nascosto separato che non può essere facilmente sovrascritto, come un logger raspberry pi / arduino, di cui ne ho alcuni.

In Linux, si suppone che root sia in grado di fare praticamente tutto. In Windows, si applica lo stesso concetto; se hai accesso root a una macchina, sarai in grado di fare quasi tutto ciò che vuoi su quella macchina, che include l'eliminazione dei log.

È inoltre possibile registrare tutte le connessioni su una determinata macchina, soprattutto se non si prevede che venga "acceduta" in primo luogo.

Come scopriresti cosa sta succedendo e come lo eludere?

Ecco un modo per trovare tutte le modifiche negli ultimi 120 minuti:

find / -mmin -120 -printf '%p\t%a\n'

Bello, eh? Gotcha, hacker! Mwahahaha ... ma puoi cambiare questi attributi se sai cosa stai facendo, in questo modo:

touch -d "24 hours ago" <file>

Peggio ancora, automatizzandolo:

find / -print | while read file; do
    touch -d "$(date -r "$file") - 24 hours" "$file"
done

Ma aspetta, Mark Hulkalo! Se tutti i file sono stati modificati l'ultima volta 24 ore fa, ciò dimostra chiaramente che abbiamo un haxor! È vero, ma puoi anche applicare $RANDOM dove 24 esiste. Ecco un esempio di un numero compreso tra 1 e 24: $((RANDOM % 10) + 1) . Ora non sembra così facile da scoprire, vero?

E se tutti i file fossero così, specialmente i file che non dovrebbero essere modificati? Limita l'ambito a una determinata directory, ad esempio /root . Esistono molti modi per mascherare la tua presenza localmente.

A meno che l'attaccante non dimentichi di pulire ~/.bash_history , starai volando alla cieca. In realtà, se l'unica "registrazione" che hai è ~/.bash_history , allora sei nei guai se il tuo aggressore è almeno moderatamente intelligente. Questo può essere cancellato su ogni account utente con estrema facilità, così da avere le autorizzazioni appropriate.

È molto più facile registrare le voci da qualche parte che non saranno facilmente rilevate o modificate, come un dispositivo esterno. Mentre è possibile usare la scientifica per recuperare le impronte degli attaccanti, è molto, molto facile da aggirare se sai cosa stai facendo. Questo è il motivo per cui il logging esterno è una soluzione molto migliore.

E questa è la ragione per cui il logging esterno è generalmente la risposta ... tieni presente che ci sono anche modi per aggirare il logging esterno. Nulla è mai sicuro al 100%; puoi rendere più difficile per il tuo aggressore, non impossibile.

Why is it possible for the root user to delete the logs?

Perché qualcuno deve essere in grado di apportare modifiche al sistema, ad esempio ruotare i file di registro, rimuovere i file di registro ecc. Nella root UNIX è tradizionalmente questo utente con privilegi completi. In realtà non c'è molta differenza tra la modifica di un log e la sostituzione di un binario per omettere la registrazione - e root può fare entrambe le cose per impostazione predefinita.

Whats stopping a hacker with root access from deleting the logs in order to cover their tracks?

La configurazione standard di solito non ferma affatto l'aggressore. Un modo ovvio per migliorare questo è l'accesso a un server di log remoto che è sufficientemente protetto in modo che l'utente malintenzionato non abbia accesso (nel caso più semplice: nessun accesso remoto possibile).

Oltre a FreeBSD, OpenBSD e probabilmente altri hanno l'idea di file immutabili o solo append. Con chflags puoi contrassegnare i file di registro in questo modo e quindi sono possibili solo accodamenti e il file non può essere cancellato. Combinando questa funzionalità con il dispositivo di sicurezza, è possibile ottenere file di registro che possono essere modificati (rimossi, ruotati) solo in modalità utente singolo.

E potresti usare meccanismi di sicurezza alternativi o estesi come SELinux per assicurarti che l'utente root "normale" non possa cambiare i file.

Se il server ha avuto l'utente root compromesso, quell'utente può certamente cancellare qualsiasi file (inclusi i log) sui sistemi. Tuttavia, nella maggior parte delle aziende, i registri non sono archiviati localmente.

Se i registri sono archiviati localmente e cancellati, al fine di determinare l'entità della violazione, è possibile condurre analisi forensi per recuperare i file.

Tuttavia, la maggior parte dei server Web aziendali e ambienti aziendali utilizzano un tipo di gestione dei registri, che può variare da strumenti standard come Syslog e SNMP e software di gestione dei registri proprietario come Splunk.

Quando tali sistemi vengono utilizzati, l'utente malintenzionato dovrebbe compromettere il sistema di gestione dei registri e qualsiasi suo backup al fine di eliminare i registri e coprire le loro tracce.

Così sicuro, si possono eliminare i file come root; ma questo non è un modo certo di coprire le proprie tracce.

Poiché i dispositivi WORM (scrivere una sola volta, leggi molti) sono ancora rari. Nei sistemi in cui la sicurezza e la medicina legale sono molto importanti questi dispositivi vengono utilizzati per registrare i registri in tempo reale, ma non può essere cancellato da, anche da root. Per essere in grado di implementarlo in modo sicuro deve essere una limitazione hardware. Meno sicuro potrebbe esporre un'API a un servizio software che ha solo operazioni per scrivere nuovi file e leggere quelli vecchi. Se il server ha anche un dispositivo hardware o un hypervisor che registra praticamente ogni modifica al sistema, sarebbe molto difficile nascondere le tracce.

Per il vero paranoico, qualcosa sulla falsariga di:

tail -f /var/log/auth.log > /dev/lp0

... probabilmente fermerebbe tutti tranne quelli che si abbasserebbero al fuoco doloso.

Batti i nastri di Oki!

Perché QUALCUNO deve essere in grado di gestire i file di registro, e se non è root, allora chi? Vorresti davvero un sistema in cui, se, ad esempio, un file di registro cresce fino a occupare il 90% dello spazio su disco, non è assolutamente possibile eliminarlo?

Certo, questo è un buco di sicurezza. Nello stesso senso in cui un sistema che consente a qualsiasi utente di fare qualsiasi cosa crea un buco di sicurezza. La maggior parte delle serrature delle porte sono progettate in modo che la serratura possa essere rimossa dalla porta solo da qualcuno che si trova all'interno della casa. Ma questo significa che chiunque possa entrare nella tua casa, come un ospite o un idraulico, potrebbe sostituire la serratura con una a cui solo lui ha la chiave. È un buco di sicurezza? Sicuro. Ma qual è l'alternativa? Fai in modo che nessuno possa sostituire il lucchetto? Cosa succede se il blocco si rompe?

Nella vita reale, non è nemmeno un semplice / o: "sistemi insicuri" in cui chiunque può entrare e fare qualsiasi cosa, contro "sistemi sicuri" dove siamo sicuri al 100% che solo gli utenti autorizzati possono fare cose autorizzate. C'è una gamma di "sicurezza". Spesso, più un sistema è sicuro, più diventa scomodo per gli utenti autorizzati svolgere il proprio lavoro. Ad un certo punto la sicurezza è talmente stretta che il sistema è praticamente inutilizzabile.

Ho detto questo nei commenti ma sembra che meriti una risposta completa.

Se stai usando SELinux, puoi configurarlo in modo tale che root non non cancelli i file di log. SELinux utilizza il Controllo di accesso obbligatorio (controllo basato sui ruoli) per determinare quali ruoli possono leggere / scrivere / eseguire ogni file, sopra Controllo di accesso discrezionale di Linux che stabilisce quali ogni utente / gruppo / tutti possono fare su un file - le tipiche autorizzazioni rwxrwxrwx.

Sembra che ci sia confusione su come SELinux potrebbe essere usato per realizzare questo, ma è abbastanza semplice. Un possibile punto di confusione è l'idea di un utente di Linux e di un ruolo di SELinux . Nulla cambia per quanto riguarda gli utenti Linux. SELinux aggiunge solo quello che Linux ha già. Quindi avresti impostato i tuoi utenti normalmente. root sarebbe lo stesso di sempre.

Quindi devi introdurre i ruoli di SELinux. Agli utenti Linux possono essere assegnati molti ruoli SELinux e i ruoli di un utente determinano cosa può fare sul sistema. Ora, la politica SELinux predefinita - "mirata" penso sia come si chiama - ha un utente non definito , che è analogo a un superutente. Di default, root viene assegnato come non confinato, quindi root può fare qualsiasi cosa proprio come potrebbe fare senza SELinux. Immagino che la maggior parte delle persone non modifichi la politica predefinita oi ruoli predefiniti in SELinux, quindi dà l'impressione che root possa fare tutto ciò che vuole.

Tuttavia, questo non è necessario . Se togli il ruolo di SELinux di root, allora non può fare nulla (non saresti nemmeno in grado di accedere). Prima di farlo, tuttavia, si desidera impostare un utente con il ruolo di amministratore di SELinux. Sia le politiche 'mirate' che quelle 'ml' sono dotate di tali ruoli di amministrazione incorporati, ma ho dimenticato come si chiama esattamente. Generalmente lo comunichi a uno degli amministratori di sistema in modo che possano modificare i criteri, i ruoli, ecc. SELinux se necessario.

La tua domanda raggiunge l'intero punto su SELinux e il suo sistema di accesso obbligatorio. La gente si è resa conto che ottenere root ha dato agli hacker troppe cose. Possono rovinare il tuo ssh, il tuo httpd e qualsiasi altra cosa vogliano. Ma con SELinux puoi limitare o rimuovere l'accesso root, quindi anche se qualcuno accede a root non può semplicemente distruggere il tuo sistema. Nota: questo vale per più di semplici file di registro. Questo vale per tutto sul sistema. Ottenere root diventa priva di significato molto rapidamente se configuri SELinux correttamente.

E per essere chiari - alcuni utenti a un certo punto devono essere in grado di eliminare i file di registro. Il punto non è quello di rendere impossibile l'eliminazione dei file di registro, il punto è rendere impossibile per root l'eliminazione di tutti i file di registro. Se qualcuno / qualcosa sul sistema può creare un file di log, allora può anche cancellare quel file di log, a meno che non si usi una sorta di memoria write-once come gli altri ho menzionato.

Quindi la domanda cambia leggermente: un hacker compromette il tuo servizio web e può successivamente eliminare i log ad esso associati, giusto? Ed è proprio quello che ci interessa, perché questo è il log che traccerà le loro azioni. Se possono ancora modificarlo, allora qual è il punto di tutto questo atto circense? Bene, la risposta è che potrebbe essere in grado di cancellare / modificare i file di log, a seconda del contesto in cui vengono eseguiti una volta che hanno sfruttato il sistema e se quel contesto ha il permesso di modificare il file di log rilevanti. Ma questa è una tana di coniglio in sé e questa risposta è abbastanza lunga così com'è. SELinux registra comunque le chiamate di sistema e l'hacker che ha compromesso il tuo servizio web non sarà in grado di modificare i log di SELinux (sono due contesti / ruoli separati nel sistema), quindi avrai almeno quello.

Per impostazione predefinita, nulla impedisce a un utente malintenzionato di eliminare i log per coprire le loro tracce, tuttavia, se un utente malintenzionato cancella i log, sarà ovvio che qualcosa è successo. Qualcosa di più intelligente dal punto di vista di un attaccante sta modificando i log per eliminare solo le sue tracce.

D'altra parte, è possibile implementare alcune misure per proteggere i registri, ad esempio inviarli in tempo reale a un server esterno.