registrazione dei comandi di Linux?

La cronologia di Bash non ti aiuterà contro un attaccante semi-competente nel solito caso.

C'è un'alternativa: il sottosistema di controllo. Installa auditd e configuralo, in modo che registri per esempio le esecuzioni del programma e altre cose che configuri. In pratica registra le chiamate di sistema effettuate in base ai filtri che hai creato.

Ora, se vuoi davvero dipendere dalla cronologia di bash, puoi renderlo più sicuro: le versioni recenti di bash possono accedere a syslog invece di un file utente locale. Quindi, syslog può essere reindirizzato a un server syslog remoto se questo è imporante per te.

non è di grande aiuto se si consente l'esecuzione di comandi non shell dalla shell. Ad esempio, puoi omettere bash eseguendo perl (o qualche altro linguaggio di scripting) e richiamando i comandi da lì - evaderà la registrazione bash.

Un utente malintenzionato che voleva effettivamente nascondere le sue tracce si limitava a modificare manualmente il file della cronologia.

Puoi rendere più difficile per un utente non root nascondere i comandi che ha già digitato in bash. Ma questo richiede solo che l'attaccante sia moderatamente competente.

• Se si rende la variabile HISTFILE sola lettura, bash salverà gli ultimi comandi $HISTFILESIZE in quel file quando esce. Puoi anche impostare HISTFILESIZE (e HISTSIZE ) di sola lettura e impostarli su un valore elevato. Tuttavia, questo è molto facilmente sconfitto, ad esempio utilizzando history built-in per disinfettare la cronologia prima di uscire. E poiché bash scrive le voci della cronologia quando esce e non dopo ogni comando, basta uscire bash con kill -9 $$ e nessuna cronologia verrà salvata. Si può dire a Zsh di salvare la cronologia dopo ogni comando, ma non in alcun modo che l'aggressore non possa annullare banalmente.
• Sotto Linux, puoi rendere il file della cronologia append-only con chattr +a ~user/.bash_history . Solo root può rimuovere l'attributo solo append da un file. Come visto sopra, questo significa solo che se l'attaccante commette un errore , non sarà in grado di cancellare le sue tracce.

Anche se si è riusciti a far registrare tutti i comandi da una particolare shell, ciò non sarebbe utile per la sicurezza. L'utente malintenzionato potrebbe semplicemente emettere comandi da un'altra applicazione, in modo tale da non generare alcuna bandiera rossa ed essere plausibilmente negabile. ( zsh , fish : ok, quindi preferisce quella shell. emacs , vi : così ha modificato un file di testo. ssh : presumibilmente voleva solo connettersi a un'altra macchina. ~/bin/foo : è solo una sceneggiatura innocente, ma chissà cosa erano due ore fa?)

Linux (come la maggior parte degli unix) ha un semplice sistema di controllo dei comandi chiamato accounting dei processi che di solito è abilitato di default: il nome eseguibile, tempo ed utente in esecuzione per ogni comando eseguito sono memorizzati in /var/log/account (la posizione esatta può variare tra le distribuzioni). Puoi visualizzare il file di registro con lastcomm . Questo può aiutarti nel tuo attuale sforzo forense, ma può essere sconfitto da un attaccante moderatamente competente (ad esempio collegando a fondo ogni eseguibile a /var/tmp/$name/ls ) - tutto quello che puoi sapere in modo affidabile è che c'era un'attività da quell'utente in un certo tempo.

Esistono pacchetti di auditing più approfonditi, in particolare il sottosistema di controllo che john ha suggerito . Cerca auditctl per trovare alcuni esempi su come configurarlo. Generalmente non è attivato per impostazione predefinita in quanto ha un impatto sulle prestazioni (non so quanto sia grave nella pratica).

Un altro semplice strumento che è (almeno in parte) predefinito è il tempo dei file. Se il ctime di un file proviene prima dell'intrusione, l'autore dell'attacco non lo ha modificato. Se hai abilitato i tempi di accesso ai file (questo era il caso per impostazione predefinita, ma ora è spesso disabilitato per le prestazioni, controlla le opzioni di montaggio di *atime ).

Tutto ciò presuppone che l'attaccante non abbia ottenuto la radice, altrimenti tutte le scommesse sono disattivate. Considera che l'aggressore potrebbe anche aver lasciato deliberatamente delle tracce che fanno sembrare che non abbia intensificato il suo accesso cancellando abilmente solo le tracce più compromettenti. Se sei preoccupato, reinstalla il sistema da backup puliti (e anche da altri sistemi che l'utente malintenzionato potrebbe aver raggiunto dopo l'irruzione iniziale).

Imposta tutte le shell degli utenti nella bash shell ristretta . In /etc/passwd imposta la shell su /bin/rbash (dovrebbe essere un simlink a / bin / bash) o /bin/bash -r

La shell con restrizioni Bash impedisce agli utenti di modificare le opzioni della shell come la cronologia dei comandi.

Inoltre, per integrare le idee sopra elencate, installerei e configurerei logwatch per l'esecuzione giornaliera (o più frequente) tramite cron e invierò via email i risultati a scopo di controllo.

Installazione e configurazione:

Linux basato su Debian digita il seguente comando -

apt-get install logwatch

Linux basato su Redhat digita il seguente comando -

yum install logwatch

Per personalizzare logwatch vai su / usr / share / doc / logwatch - * / directory e leggi il file HOWTO-Customize-LogWatch

Modifica il file logwatch.conf:

vi /etc/logwatch/conf/logwatch.conf

o

vi /usr/share/logwatch/default.conf/logwatch.conf

Leggi la pagina man di logwatch per ulteriori informazioni.