I tentativi di accesso non riusciti devono essere registrati

Sì, i tentativi di accesso non riusciti devono essere registrati:

• Vuoi sapere quando le persone cercano di entrare
• Vuoi capire perché i tuoi account vengono bloccati

È anche molto importante - il precedente processo di registrazione di Windows non lo ha mai enfatizzato abbastanza - per registrare anche tentativi di accesso riusciti . Perché se hai una stringa di tentativi di accesso falliti, dovresti davvero sapere se l'ultimo è stato seguito da un login riuscito.

I log sono relativamente piccoli. Se ci fossero stati sufficienti tentativi di accesso che la registrazione avrebbe causato un problema, allora "non conoscere i tentativi" è probabilmente un problema peggiore di "averli scoperti quando abbiamo finito il disco."

Una rapida avvertenza - come sottolinea @Polynomial, la password non dovrebbe essere registrata (mi sembra di ricordare che 25 anni fa alcuni sistemi lo facevano ancora). Tuttavia, è anche necessario essere consapevoli del fatto che alcuni tentativi di accesso legittimi falliranno quando le persone inseriranno la propria password nel campo del nome utente, in modo che le password vengano registrate. Dubitare di me? Esegui il traino dei tuoi log per l'ID evento 4768 di Windows:

LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       gowenfawr-has-a-cool-password
    Supplied Realm Name:    TEST.INT
    User ID:            NULL SID

Di conseguenza, dovresti limitare l'accesso a questi log alle persone necessarie: non limitarti a riversarli in un SIEM a cui l'intera azienda ha accesso in lettura.

Aggiornamento per indirizzare la modifica della domanda:

Based on the answers so far, one other question that occurred to me is whether web server logs would be enough for logging such attempts. Would it be redundant to log them in the database?

Le migliori pratiche sono che i registri devono essere inoltrati a un aggregatore di registri separato in ogni caso, ad esempio, si consideri PCI DSS 10.5.4. In pratica, un tale aggregatore è solitamente un SIEM e funziona come un database piuttosto che come file di registro flat.

Quindi, sì, è "ridondante" per definizione, ma è il tipo di ridondanza che è una funzionalità di sicurezza, non un errore architettonico.

I vantaggi di registrarli in un database includono ricerca, correlazione e sommatoria. Ad esempio, la seguente ricerca di Splunk:

source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,host

Ci consentirà di ripristinare i fallimenti dell'autenticazione da parte dell'utente e dell'host:

Sinotichelapossibilitàdiinterrogarecampidiscreticome"utente" e "host" dipende dai log di prelievo di SIEM e dalla comprensione di cosa significa cosa. L'accessibilità di questi campi qui è un effetto collaterale di Splunk per l'analisi automatica dei log per me.

Dato che la tua domanda originale riguardava i limiti di spazio, va sottolineato che qualsiasi soluzione di database o SIEM richiederà più spazio su disco rispetto ai log di file di testo flat. Tuttavia, se si utilizza tale soluzione, quasi sempre la si inserisce in un server separato per motivi di sicurezza e di gestione dello spazio. (Esistono anche soluzioni SIEM-in-the-cloud per semplificarti la vita!)

Come complemento alla risposta di @ gowenfawr che spiega perché dovresti registrare questi tentativi, vorrei dire che ci sono modi per garantire che i log non esauriscano mai i tuoi dischi.

Almeno nel mondo Unix-Linux, strumenti come logrotate o rotatelogs permettono di cambiare il file di log quando le sue dimensioni superano una certa soglia. Sono comunemente usati con il server Apache (i rotatelogs provengono dalla base Apache) o con il sistema syslog.

Ad esempio logrotate è usato per rinominare un file di log (in un anello di un numero di copie, generalmente circa 10 di essi) eventualmente comprimerlo, e avverte il programma che genera il log per riaprire il suo file di registro inviandolo un segnale dedicato o tramite qualsiasi comando arbitrario.

In questo modo, se il tuo server è sottoposto a un attacco DoS, la dimensione dei tuoi file di log rimarrà sotto controllo. Ovviamente perderai gli eventi più vecchi, ma è decisamente meglio che arrestare il server a causa di una partizione del disco esaurita.

Dipende davvero dal valore che pensi di poter ricavare dalle informazioni. C'è un valore limitato nell'avere pagine di log che ti dicono che il tuo server è sotto attacco; è rivolto verso Internet e sarà probabilmente sottoposto a vari gradi di costante bombardamento per tutta la vita.

A seconda della configurazione del tuo server, è abbastanza possibile finire per creare un problema di disponibilità perché hai esaurito lo spazio su disco disponibile con i log. Succede. Gowenfawr ha ragione quando afferma che i registri non occupano molto spazio, ma questo è il motivo per cui i problemi relativi all'esaurimento dello spazio su disco possono richiedere anni per apparire, ma sono un grave problema quando lo fanno.

Se decidi di accedere, devi progettare una strategia di gestione dei log e prendere in considerazione alcuni dei seguenti:

• Che cosa ho intenzione di fare con i miei registri? Cosa succede dopo aver stabilito che qualcuno sta tentando di accedere al tuo sistema?
• I miei registri contengono dati potenzialmente sensibili? (Ricorda, gli utenti reali possono a volte ingrassare le loro credenziali). Se la risposta è sì, considera i registri di disinfezione prima di archiviarli o crittografarli una volta a riposo
• Verbosità ed eventi log
• Con quale frequenza devo ruotare i registri? La rotazione dei registri è un modo abbastanza standard per gestire le dimensioni dei registri. Può consentire di comprimere log vecchi e potenzialmente eliminare archivi di log particolarmente vecchi
• Informazioni sulla sicurezza e gestione degli eventi. _Hai accennato al fatto che il tuo server conterrà informazioni sensibili, a seconda di cosa potresti voler considerare esaminando i prodotti SIEM che possono fornirti utili informazioni basate sulla registrazione e altri dati come avvisi, dashboard, analisi forensi, ecc.

Parlando personalmente, tendo a trovare i log utili solo per l'analisi forense: aiutano a capire cosa è successo dopo una violazione riuscita. Come menzionato da Gowenfawr; la registrazione dei tentativi riusciti di accedere a un sistema sono (probabilmente più) importanti di quelli non riusciti.

Un ultimo punto, il tuo meccanismo di login dovrebbe essere costruito in modo tale che la probabilità che una forza bruta distribuita funzioni sempre è piccola. Non hai dato molti dettagli su ciò che hai costruito, ma usando forti algoritmi di back-end, in particolare hash computazionalmente costosi e l'introduzione del tempo di backoff nei tentativi di accesso può ridurre notevolmente le possibilità che un utente malintenzionato abbia mai accesso in questo modo. p>