Ci sarà un cronjob che esegue logrotate giornalmente come root, puoi controllare la configurazione in /etc/logrotate.conf e /etc/logrotate.d/* . Se apporti delle modifiche, devi eseguire /usr/sbin/logrotate -dv /etc/logrotate.conf per assicurarti che non vi siano errori nella nuova configurazione.
Oltre a auth.log dovresti anche ruotare e mantenere wtmp e btmp (il secondo traccia i tentativi di accesso falliti), la maggior parte dei sistemi manterrà solo una rotazione di quelli.
L'impostazione normale è che /var/log/ non è scrivibile word, i file di log all'interno non sono nemmeno scrivibili a livello mondiale e talvolta non sono leggibili da tutti (quest'ultimo per file come auth.log che può contiene accidentalmente password inserito nei campi del nome utente, CWE-532 ).
Dovresti controllare che le autorizzazioni del file siano come previsto, che sia il lavoro di logrotate per creare nuovi file di log e impostare il proprietario / permessi corretti (vedi la direttiva create ). Tuttavia, l'impostazione predefinita è applicare le autorizzazioni e la proprietà del file corrente: se il proprietario / le autorizzazioni vengono modificate una volta, queste verranno mantenute su ogni nuova istanza di quel file di registro (quindi un errore precedente può tornare a perseguitarti).
Anche se un utente normale non può scrivere o modificare direttamente quei file, un utente locale può probabilmente aggiungerli indirettamente tramite syslog:
logger -p auth.info -it sshd \
"Accepted password for root from host.badguys.com port 31337 ssh2"
(La situazione è peggiore se si accettano messaggi syslog via UDP attraverso la rete, ma di solito non è abilitato di default in qualsiasi configurazione sana).
Questo è un esempio di CWE-117 , e mostra uno dei numerosi problemi con syslog.
È necessario utilizzare un metodo diverso per sovrascrivere o eliminare effettivamente i dati se un utente malintenzionato (o utente non fidato) acquisisce un accesso, ad es. escalation dei privilegi o uso creativo dei programmi setuid / setgid.
Tuttavia, vi è l'opportunità di attacchi di tipo denial-of-service qui. Se non si dispone di una qualche forma di limitazione della velocità o blocco su sshd , un utente malintenzionato potrebbe essere in grado di riempire i registri con la registrazione delle connessioni (e se si interrompe, potrebbe essere in grado di coprire le sue tracce con voci contraffatte). Se logrotate utilizza la rotazione basata sulle dimensioni (non quella predefinita) potrebbe essere in grado di ruotare le voci rivelatrici fuori dall'esistenza, senza privilegi aggiuntivi. Se si utilizza la rotazione basata sul tempo, potrebbe essere in grado di riempire banalmente il file system a cui si sta effettuando l'accesso e impedire la registrazione di altri eventi.
Per riassumere:
- se le autorizzazioni del file di log sono errate, sì un utente malintenzionato potrebbe rimuovere le voci del file di log rivelatore
(se un utente malintenzionato può sfruttare altre escalation di privilegi locali, può farlo comunque, ovviamente, ma ha un problema più grande)
- dovresti controllare che le autorizzazioni del file di log siano soddisfatte, ad es. non è scrivibile in tutto il mondo, e forse non è leggibile da tutto il mondo - la maggior parte delle configurazioni non codifica i permessi paranoici nel
logrotate.conf
- standard syslog ha un numero di problemi, tra cui autenticità, integrità e limitazione della velocità
- considera l'utilizzo di
/etc/hosts.allow per autorizzare i blocchi IP remoti per l'accesso sshd, se possibile, è una misura di mitigazione ragionevole
- dovresti usare qualche tipo di blocco dinamico (su un Pi potresti dare un'occhiata a Micro Fail2Ban )
Uno dei modi migliori per limitare ciò che un utente malintenzionato può fare nei file di registro è di collegarli a un sistema diverso su una rete protetta. Altre possibili soluzioni includono file solo append applicati dal sistema operativo (vedere questo su Unix e Linux.SE ), questo è antimanomissione .
Puoi anche leggere miglioramenti alla registrazione * nix in il blog del manutentore di rsyslog. Una delle funzioni discusse è link-timestamping , che è a prova di manomissione .