È possibile utilizzare gli strumenti in questo articolo per centralizzare i log degli eventi di Windows da più server e desktop. Amministrando correttamente i log, è possibile monitorare lo stato dei sistemi, proteggere i file di log e filtrare i contenuti per trovare informazioni specifiche.
- Perché centralizzare i log?
- Windows Event Subscription
- Sistema di esempio
- Setup
- Abilita il servizio di gestione remota di Windows
- Configurare il servizio di raccolta eventi di Windows
- Configurare il gruppo Lettori log eventi
- Configurare Windows Firewall
- Creare una sottoscrizione
- Verifica eventi nel computer Collector
- Creare una vista personalizzata (opzionale)
- Servizi di registrazione di Windows
- Installa NXLog
- Configura NXLog
- File Logs
- IIS Logs
- SQL Server Error Logs
- Inoltro dei log a un server
- Crittografia dei log con TLS
Perché centralizzare i log?
Centralizzare i log consente di risparmiare tempo e aumenta l’affidabilità dei dati di log. Quando i file di log di Windows vengono memorizzati localmente su ciascun server, è necessario accedere individualmente a ciascuno di essi per esaminarli e cercare eventuali errori o avvisi. Se il server non risponde, potresti essere sfortunato. Se non si è sicuri di quali server sono interessati, si deve cacciare attraverso ciascuno di essi, che può richiedere molto tempo su reti di grandi dimensioni. I file di registro sono anche più sicuri in una posizione centralizzata perché anche quando le istanze vengono terminate o i file vengono eliminati (intenzionalmente o meno), le copie di backup centralizzate dei log non vengono influenzate.
Windows Event Subscription
È possibile per un server Windows inoltrare i propri eventi a un server collector. In questo scenario, il server di raccolta diventa un repository centrale per i registri di Windows da altri server (chiamati origini eventi) nella rete. Il flusso di eventi da un’origine a un raccoglitore è chiamato abbonamento.
Questa procedura dimostra come configurarlo. Questi passaggi funzionano su Windows Server 2008 R2, Windows Server 2012 e Windows Server 2019.
Sistema di esempio
Stiamo utilizzando due sistemi Windows Server 2012 con dominio Active Directory. Il nome di dominio è mytestdomain.com ed entrambe le macchine sono registrate con il dominio.
Server sorgente MYTESTSQL ospita un’istanza di SQL Server 2014. Collector server MYTESTSERVER funziona come un abbonato registro eventi per centralizzare tutti i registri relativi a SQL Server da MYTESTSQL.
Setup
Abilita il servizio di gestione remota di Windows
Windows Remote Management (WinRM) è un protocollo per lo scambio di informazioni tra i sistemi dell’infrastruttura. È necessario abilitarlo su ciascuno dei computer di origine per lo scambio di file di registro.
- Accedere in remoto al computer di origine (MYTESTSQL) come amministratore locale o di dominio.
- Abilita il servizio di gestione remota di Windows da un prompt dei comandi:
winrm quickconfig
Se è già in esecuzione, viene visualizzato un messaggio simile a questo esempio.
Configurare il servizio di raccolta eventi di Windows
È necessario abilitare il servizio di raccolta eventi di Windows sul server di raccolta per consentire la ricezione dei log dalle origini.
- Accedere in remoto al computer collector (MYTESTSERVER) come amministratore locale o di dominio.
- Configurare il servizio di raccolta eventi di Windows da un prompt dei comandi:
wecutil qcin
Se richiesto come nell’esempio, premere y
Configurare il gruppo Lettori log eventi
Per impostazione predefinita, alcuni registri sono limitati agli amministratori. Ciò potrebbe causare problemi durante la ricezione di registri da altri sistemi. Per evitare ciò, è possibile concedere l’accesso al computer del collector aggiungendolo al gruppo Lettori registro eventi.
- Torna al computer di origine (MYTESTSQL).
- Apri Gestore server.
- Apri Gestione computer.
- Espandere il nodo Utenti e Gruppi locali dal riquadro di navigazione e selezionare Gruppi.
- Fare doppio clic su Lettori registro eventi.
- Fare clic su Aggiungi per aprire la finestra di dialogo Seleziona utenti, Computer, Account di servizio o gruppi.
- Fare clic su Tipi di oggetto.
- Controllare i computer e fare clic su OK.
- Immettere MYTESTSERVER come nome dell’oggetto e fare clic su Controlla nomi. Se viene trovato l’account del computer, viene confermato con una sottolineatura.
- Fare clic su OK due volte per chiudere le finestre di dialogo.
Configurare Windows Firewall
Se il computer di origine esegue Windows Firewall, assicurarsi che consenta la gestione remota del registro eventi e il monitoraggio remoto del traffico degli eventi.
Creare una sottoscrizione
Le sottoscrizioni definiscono la relazione tra un collector e un’origine. È possibile configurare un collector in modo che riceva eventi da un numero qualsiasi di origini (una sottoscrizione avviata dall’origine) o specificare un insieme limitato di origini (una sottoscrizione avviata dall’origine). In questo esempio, creiamo una sottoscrizione avviata da collector poiché sappiamo quali registri del computer vogliamo ricevere.
- Avviare l’applicazione Visualizzatore eventi sul server di raccolta MYTESTSERVER.
- Selezionare Sottoscrizioni dal riquadro di navigazione
- Fare clic su Crea sottoscrizione nel riquadro Azioni.
- Nelle Proprietà della sottoscrizione, immettere quanto segue, come mostrato nell’esempio:
Nome della sottoscrizione: MYTESTSQL_EVENTS
Descrizione: Eventi dal server di origine remoto MYTESTSQL
Registro di destinazione: Eventi inoltrati
Selezionare Collector avviato e fare clic su Seleziona computer per aprire la finestra di dialogo Computer.
- Fare clic su Aggiungi computer di dominio.
- Immettere MYTESTSQL come nome dell’oggetto e fare clic su Controlla nomi. Se il computer viene trovato, viene confermato con una sottolineatura.
- Fare clic su OK.
- Fare clic su OK per tornare alle Proprietà della sottoscrizione.
- Fare clic su Seleziona eventi per aprire il filtro query e immettere quanto segue per impostare il server remoto per inoltrare tutti gli eventi dell’applicazione delle ultime 24 ore:
Registrato: Ultime 24 ore
Controlla tutti i livelli di eventi
Seleziona per registro
Registri eventi: seleziona Applicazione dall’elenco a discesa
- Fare clic su OK per tornare alle Proprietà della sottoscrizione.
- Fare clic su Avanzate per aprire le impostazioni di abbonamento avanzate e immettere quanto segue:
Selezionare Account macchina
Selezionare Riduci latenza
Protocollo: HTTP
Porta: 5985
- Fare clic su OK per tornare alle Proprietà della sottoscrizione.
- Fare clic su OK per chiudere.
Il nodo di sottoscrizione nel visualizzatore eventi del computer collector ora mostra la nuova sottoscrizione.
Verifica eventi nel computer Collector
Selezionare Eventi inoltrati dal riquadro di spostamento del computer collector.
La colonna Computer nel riquadro Dettagli indica che gli eventi provengono dal computer remoto MYTESTSQL.MYTESTDOMAIN.COM. È possibile attivare o disattivare l’abbonamento collector facendo clic destro sulla sottoscrizione e scegliendo Disattiva. Lo stato dell’abbonamento viene quindi visualizzato come disabilitato nella finestra principale. Un abbonamento collector attivo non significa che sta avendo successo. Per vedere se il collettore può connettersi alla sorgente, fare clic destro sulla sottoscrizione e selezionare Stato di runtime. In questo esempio, il collector non può connettersi all’origine. Per impostazione predefinita, si riprova ogni cinque minuti.
Se tutto è OK, Subscription Runtime Status mostra un segno di spunta verde con uno stato attivo.
Creare una vista personalizzata (opzionale)
Una volta inoltrati gli eventi, è possibile creare viste personalizzate per visualizzare gli eventi consolidati. Ad esempio, è possibile creare una vista personalizzata per gli eventi di errore. Questo esempio crea una vista personalizzata per i messaggi relativi a SQL Server. Un computer di raccolta può ospitare migliaia di record da decine di server. L’utilizzo di una vista personalizzata consente di creare un ordine da un sovraccarico di informazioni. Per passaggi dettagliati, vedere la sezione Creazione di una vista personalizzata in Nozioni di base di registrazione di Windows.
Servizi di registrazione di Windows
Esistono diversi servizi Windows che è possibile utilizzare per centralizzare tutti i dati di registrazione su un servizio di registrazione esterno. Questi servizi inviano i log su syslog a un server di log multipiattaforma o a un servizio di registrazione basato su cloud come SolarWinds® Loggly®.
Consigliamo NXLog, un popolare servizio scaricabile gratuitamente che viene eseguito in background. In alternativa, ci sono syslog-ng e Rullante, che sono servizi che raccolgono i file di registro. Tutti questi servizi forniscono un supporto professionale aggiuntivo a pagamento.
Installa NXLog
Questo esempio installa e configura NXlog per impacchettare i file di registro.
Scarica e installa la versione corrente di NXlog. Il download include un programma di installazione intuitivo. Una volta completata l’installazione, aprire il file di configurazione. Per impostazione predefinita, il file di configurazione NXLog si trova a C:/Program File (x86)/nxlog/conf / nxlog.conf
È possibile creare diversi tipi di moduli di configurazione.
- Ingressi per l’origine dei log
- Uscite per dove inviare i log
- Percorsi per mappare gli input agli output
Ogni volta che si apportano modifiche al file di configurazione di NXlog, è necessario riavviare il servizio nxlog.
Configura NXLog
Questo esempio modifica il file di configurazione di NXLog per centralizzare i log degli eventi di Windows. Aggiungendo il frammento di codice qui sotto alla fine del tuo nxlog.il file conf abilita il modulo e gli dà il nome “eventlog”. Il modulo di input im_msvistalog invia nuove voci al registro eventi di Windows, inclusi gli eventi relativi a sistema, hardware, applicazione e sicurezza.
# Windows Event Log<Input eventlog># Uncomment im_msvistalog for Windows Vista/2008 and laterModule im_msvistalog# Uncomment im_mseventlog for Windows XP/2000/2003# Module im_mseventlog# If you prefer to send events as JSON dataExec $Message = to_json();</Input>
File Logs
NXLog può essere utilizzato per leggere i file di log memorizzati su un’unità. In questo esempio, il nome del file è FILE1. SavePos TRUE significa che NXLog traccerà la sua posizione corrente nel file di registro all’uscita. Exec Message Message = ra raw_event significa che NXLog acquisirà il messaggio di log non elaborato senza applicare alcuna formattazione aggiuntiva. Il nome del file può anche includere directory o wild card.
<Input FILE1>Module im_fileFile "FILE1"SavePos TRUEExec $Message = $raw_event;</Input>
IIS Logs
Come abbiamo trattato nella sezione Windows Logging Basics, IIS logs contengono log di accesso memorizzati in formato W3C. Si consiglia di convertirli in formato JSON per una facile elaborazione da uno strumento di gestione dei log. NXLog può fare questa conversione utilizzando l’estensione W3C. Assicurati di utilizzare il formato corretto nel file di configurazione, in modo che l’analisi avvenga correttamente e includi i file di registro da tutti i tuoi siti.
<Extension w3c>Module xm_csvFields $date, $time, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $csUser-Agent, $cs-Referer, $sc-status, $sc-substatus, $sc-win32-status, $time-takenFieldTypes string, string, string, string, string, string, integer, string, string, string, string, integer, integer, integer, integerDelimiter ' 'QuoteChar '"'EscapeControl FALSEUndefValue -</Extension># Convert the IIS logs to JSON and use the original event time<Input IIS_Site1>Module im_fileFile "C:/inetpub/logs/LogFiles/W3SVC1/u_ex*"SavePos TRUEExec if $raw_event =~ /^#/ drop();else{w3c->parse_csv();$SourceName = "IIS";$Message = to_json();}</Input>
SQL Server Error Logs
SQL Server è la piattaforma di database di punta di classe enterprise di Microsoft. Viene fornito in una suite di strumenti di database e data warehouse. SQL Server in genere ha i propri registri salvati nella directory di installazione dell’applicazione nel file system di Windows. Il percorso predefinito per SQL Server 2012 è C:/Program File / Microsoft SQL Server / MSSQL11.MSSQLSERVER / MSSQL / Log. Le voci del registro vengono inviate anche al registro eventi dell’applicazione Windows.
Le operazioni di SQL Server come backup e ripristino, timeout di query o I/O lenti sono quindi facili da trovare dal registro eventi dell’applicazione Windows, mentre i messaggi relativi alla sicurezza come i tentativi di accesso non riusciti vengono acquisiti nel registro eventi di sicurezza di Windows.
Inoltro dei log a un server
NXLog può inoltrare i log da uno qualsiasi degli input sopra descritti a una destinazione esterna, ad esempio un server di log o un servizio di gestione dei log basato su cloud. Per fare ciò, NXLog utilizza concetti chiamati Output e Route. Gli output sono moduli che forniscono funzionalità per l’invio di log a una destinazione, ad esempio un file o un server remoto. I percorsi sono i percorsi che un messaggio di log prende da un input (ad esempio il modulo im_msvistalog) a un output (ad esempio un servizio di gestione dei log).
Per inoltrare i log, aggiungi un modulo di output nel tuo nxlog.file di configurazione conf. Quindi aggiungi un modulo Route per inviare i log dagli input scelti alle uscite scelte. In questo esempio, stiamo inviando i log come syslog su TCP all’host HOSTNAME sulla porta syslog predefinita 514. Creiamo un percorso che prende i registri dall’input eventlog e lo invia al nuovo output (denominato out):
<Output out>Module om_tcpHost HOSTNAMEPort 514</Output><Route 1>Path eventlog => out</Route>
Diverse soluzioni di gestione dei log offrono istruzioni di configurazione specifiche per la registrazione di Windows. Loggly è un esempio di un provider e ha informazioni più dettagliate sulla configurazione di NXLog per raccogliere i file di registro nella loro guida, la registrazione da Windows.
Crittografia dei log con TLS
Per impostazione predefinita, i log inviati via Internet vengono trasmessi in chiaro. Ciò significa che gli spioni possono intercettare e visualizzare i dati di registro. È consigliabile crittografare i dati di registro quando sono in transito, specialmente se contengono informazioni sensibili come dettagli di identificazione personale, dati regolamentati dal governo o informazioni finanziarie. Il protocollo più comune per la crittografia della comunicazione syslog è TLS o Transport Layer Security.
TLS crittografa i log, impedendo a chiunque di curiosare su dati sensibili nei log. La migliore pratica è non registrare informazioni come le password, ma alcune applicazioni lo fanno comunque. La crittografia TLS aiuta a mantenere questi dati più sicuri. La crittografia impedisce alle parti malevoli situate tra le origini e le destinazioni del registro di leggere o modificare i dati del registro.
Ecco un esempio di configurazione di NXLOG con crittografia TLS per Loggly.
- Scarica il certificato digitale di Loggly dalla pagina di configurazione di NXLog TLS.
- Copia il file del certificato digitale nella directory NXLog cert:
copia loggly_full.tcr C:/Program File * / nxlog / cert - Configura il tuo modulo di output con om_ssl e il percorso del certificato. La porta syslog predefinita per i registri crittografati è 6514. AllowUntrusted FALSE impedisce una connessione al server se il certificato non è attendibile o autofirmato:
<Output out>Module om_sslHost server.example.comPort 6514CAFile %CERTDIR%/example.crtAllowUntrusted FALSE<Output>