Zentralisieren von Windows-Protokollen

Mit den Tools in diesem Artikel können Sie Ihre Windows-Ereignisprotokolle von mehreren Servern und Desktops zentralisieren. Durch die ordnungsgemäße Verwaltung Ihrer Protokolle können Sie den Zustand Ihrer Systeme verfolgen, Ihre Protokolldateien schützen und Inhalte filtern, um bestimmte Informationen zu finden.

Warum Protokolle zentralisieren?

Die Zentralisierung Ihrer Protokolle spart Zeit und erhöht die Zuverlässigkeit Ihrer Protokolldaten. Wenn Windows-Protokolldateien lokal auf jedem Server gespeichert sind, müssen Sie sich einzeln bei jedem Server anmelden, um sie durchzugehen und nach Fehlern oder Warnungen zu suchen. Wenn der Server nicht reagiert, haben Sie möglicherweise kein Glück. Wenn Sie nicht sicher sind, welche Server betroffen sind, müssen Sie jeden einzelnen durchsuchen, was in großen Netzwerken lange dauern kann. Die Protokolldateien sind auch an einem zentralen Speicherort sicherer, da die zentralisierten Sicherungskopien Ihrer Protokolle selbst dann nicht betroffen sind, wenn Ihre Instanzen beendet oder Ihre Dateien (absichtlich oder unabsichtlich) gelöscht werden.

Windows Event Subscription

Es ist möglich, dass ein Windows Server seine Ereignisse an einen Collector Server weiterleitet. In diesem Szenario wird der Collector-Server zu einem zentralen Repository für Windows-Protokolle von anderen Servern (Ereignisquellen genannt) im Netzwerk. Der Ereignisstrom von einer Quelle zu einem Collector wird als Abonnement bezeichnet.

Dieses Verfahren zeigt, wie es eingerichtet wird. Diese Schritte funktionieren unter Windows Server 2008 R2, Windows Server 2012 und Windows Server 2019.

Beispielsystem

Wir verwenden zwei Active Directory-domänengebundene Windows Server 2012-Systeme. Der Domainname ist mytestdomain.com und beide Maschinen sind mit der Domain registriert.

Quellserver MYTESTSQL hostet eine SQL Server 2014-Instanz. Collector Server MYTESTSERVER arbeitet als Ereignisprotokollabonnent, um alle SQL Server-bezogenen Protokolle von MYTESTSQL zu zentralisieren.

Einrichten

Aktivieren des Windows-Remoteverwaltungsdienstes

Windows Remote Management (WinRM) ist ein Protokoll zum systemübergreifenden Austausch von Informationen in Ihrer Infrastruktur. Sie müssen es auf jedem Ihrer Quellcomputer aktivieren, um Protokolldateien auszutauschen.

1. Melden Sie sich als lokaler oder Domänenadministrator remote am Quellcomputer (MYTESTSQL) an.
2. Aktivieren Sie den Windows-Remoteverwaltungsdienst über eine Eingabeaufforderung:

   winrm quickconfig

   Wenn er bereits ausgeführt wird, wird eine Meldung ähnlich diesem Beispiel angezeigt.

Konfigurieren des Windows-Ereignissammlerdienstes

Sie müssen den Windows-Ereignissammlerdienst auf Ihrem Collector-Server aktivieren, damit er Protokolle von Ihren Quellen empfangen kann.

1. Melden Sie sich als lokaler oder Domänenadministrator remote am Collector-Computer (MYTESTSERVER) an.
2. Konfigurieren Sie den Windows Event Collector-Dienst über eine Eingabeaufforderung:

   wecutil qcin

   Wenn Sie wie im Beispiel dazu aufgefordert werden, drücken Sie y

Konfigurieren der Ereignisprotokolllesergruppe

Standardmäßig sind bestimmte Protokolle auf Administratoren beschränkt. Dies kann zu Problemen beim Empfang von Protokollen von anderen Systemen führen. Um dies zu vermeiden, können Sie dem Collector-Computer Zugriff gewähren, indem Sie ihn der Gruppe Ereignisprotokollleser hinzufügen.

1. Gehen Sie zurück zum Quellcomputer (MYTESTSQL).
2. Öffnen Sie den Server-Manager.
3. Öffnen Sie die Computerverwaltung.
4. Erweitern Sie den Knoten Lokale Benutzer und Gruppen im Navigationsbereich, und wählen Sie Gruppen aus.
5. Doppelklicken Sie auf Ereignisprotokollleser.
6. Klicken Sie auf Hinzufügen, um das Dialogfeld Benutzer, Computer, Dienstkonten oder Gruppen auswählen zu öffnen.
7. Klicken Sie auf Objekttypen.
8. Überprüfen Sie Computer und klicken Sie auf OK.
   
9. Geben Sie MYTESTSERVER als Objektnamen ein und klicken Sie auf Namen prüfen. Wenn das Computerkonto gefunden wird, wird es mit einer Unterstreichung bestätigt.
10. Klicken Sie zweimal auf OK, um die Dialogfelder zu schließen.
    

Konfigurieren der Windows-Firewall

Wenn auf dem Quellcomputer die Windows-Firewall ausgeführt wird, stellen Sie sicher, dass Remoteereignisprotokollverwaltung und Remoteereignismonitordatenverkehr zulässig sind.

Erstellen eines Abonnements

Abonnements definieren die Beziehung zwischen einem Collector und einer Quelle. Sie können einen Collector so konfigurieren, dass er Ereignisse aus einer beliebigen Anzahl von Quellen empfängt (ein quellinitiiertes Abonnement), oder einen begrenzten Satz von Quellen angeben (ein Collector-initiiertes Abonnement). In diesem Beispiel erstellen wir ein Collector-initiiertes Abonnement, da wir wissen, welche Computerprotokolle wir empfangen möchten.

1. Starten Sie die Ereignisanzeige auf dem Collector Server MYTESTSERVER.
2. Wählen Sie im Navigationsbereich Abonnements aus
3. Klicken Sie im Aktionsbereich auf Abonnement erstellen.
   
4. Geben Sie in den Abonnementeigenschaften wie im Beispiel gezeigt Folgendes ein:
   Abonnementname: MYTESTSQL_EVENTS
   Beschreibung: Ereignisse vom Remote-Quellserver MYTESTSQL
   Zielprotokoll: Weitergeleitete Ereignisse
   Wählen Sie Collector initiated und klicken Sie auf Select Computers, um das Dialogfeld Computers zu öffnen.
   
5. Klicken Sie auf Domänencomputer hinzufügen.
6. Geben Sie MYTESTSQL als Objektnamen ein und klicken Sie auf Namen prüfen. Wenn der Computer gefunden wird, wird er mit einer Unterstreichung bestätigt.
7. Klicken Sie auf OK.
   
8. Klicken Sie auf OK, um zu den Abonnementeigenschaften zurückzukehren.
9. Klicken Sie auf Ereignisse auswählen, um den Abfragefilter zu öffnen, und geben Sie Folgendes ein, um den Remoteserver so einzustellen, dass alle Anwendungsereignisse der letzten 24 Stunden weitergeleitet werden:
   Protokolliert: Letzte 24 Stunden
   Alle Ereignisebenen überprüfen
   Nach Protokoll auswählen
   Ereignisprotokolle: Wählen Sie Anwendung aus der Dropdown-Liste
   
10. Klicken Sie auf OK, um zu den Abonnementeigenschaften zurückzukehren.
11. Klicken Sie auf Erweitert, um die erweiterten Abonnementeinstellungen zu öffnen, und geben Sie Folgendes ein:
    Maschinenkonto auswählen
    Latenz minimieren auswählen
    Protokoll: HTTP
    Port: 5985
    
12. Klicken Sie auf OK, um zu den Abonnementeigenschaften zurückzukehren.
13. Klicken Sie zum Schließen auf OK.

Der Abonnementknoten in der Ereignisanzeige des Collector-Computers zeigt jetzt das neue Abonnement an.

Ereignisse auf dem Collector-Computer überprüfen

Wählen Sie im Navigationsbereich auf dem Collector-Computer die Option Weitergeleitete Ereignisse aus.

Die Spalte Computer im Detailbereich gibt an, dass die Ereignisse vom Remotecomputer stammen MYTESTSQL.MYTESTDOMAIN.COM . Sie können das Collector-Abonnement aktivieren oder deaktivieren, indem Sie mit der rechten Maustaste auf das Abonnement klicken und Deaktivieren auswählen. Der Status des Abonnements wird dann im Hauptfenster als deaktiviert angezeigt. Ein aktives Collector-Abonnement bedeutet nicht, dass es erfolgreich ist. Um zu sehen, ob der Collector eine Verbindung zur Quelle herstellen kann, klicken Sie mit der rechten Maustaste auf das Abonnement und wählen Sie Laufzeitstatus. In diesem Beispiel kann der Collector keine Verbindung zur Quelle herstellen. Standardmäßig wird der Vorgang alle fünf Minuten wiederholt.

Wenn alles in Ordnung ist, zeigt der Abonnementlaufzeitstatus ein grünes Häkchen mit einem aktiven Status an.

Benutzerdefinierte Ansicht erstellen (Optional)

Sobald die Ereignisse weitergeleitet wurden, können Sie benutzerdefinierte Ansichten erstellen, um die konsolidierten Ereignisse anzuzeigen. Sie können beispielsweise eine benutzerdefinierte Ansicht für Fehlerereignisse erstellen. In diesem Beispiel wird eine benutzerdefinierte Ansicht für SQL Server–bezogene Nachrichten erstellt. Ein Collector-Computer kann Tausende von Datensätzen von Dutzenden von Servern hosten. Mithilfe einer benutzerdefinierten Ansicht können Sie aus einer Überlastung von Informationen eine Reihenfolge erstellen. Detaillierte Schritte finden Sie im Abschnitt Erstellen einer benutzerdefinierten Ansicht in Windows-Protokollierungsgrundlagen.

Windows-Protokollierungsdienste

Es gibt mehrere Windows-Dienste, mit denen Sie alle Ihre Protokollierungsdaten für einen externen Protokollierungsdienst zentralisieren können. Diese Dienste senden Protokolle über Syslog an einen plattformübergreifenden Protokollserver oder cloudbasierten Protokollierungsdienst wie SolarWinds® Loggly®.

Wir empfehlen NXLog, einen beliebten, frei herunterladbaren Dienst, der im Hintergrund läuft. Alternativ gibt es syslog-ng und Snare, die Dienste sind, die Ihre Protokolldateien sammeln. Alle diese Dienste bieten zusätzliche professionelle Unterstützung gegen eine Gebühr.

Install NXLog

In diesem Beispiel wird NXlog installiert und konfiguriert, um Ihre Protokolldateien zu verpacken.

Laden Sie die aktuelle Version von NXlog herunter und installieren Sie sie. Der Download enthält ein intuitives Installationsprogramm. Öffnen Sie nach Abschluss der Installation die Konfigurationsdatei. Standardmäßig befindet sich die NXLog-Konfigurationsdatei unter C:/Program Dateien (x86)/nxlog/conf/nxlog.conf

Sie können verschiedene Arten von Konfigurationsmodulen erstellen.

• Eingaben für die Quelle Ihrer Protokolle
• Ausgaben für wohin die Protokolle gesendet werden sollen
• Routen zum Zuordnen Ihrer Eingaben zu Ihren Ausgängen

Wenn Sie Änderungen an der NXlog-Konfigurationsdatei vornehmen, müssen Sie den NXlog-Dienst neu starten.

NXLog konfigurieren

In diesem Beispiel wird die NXLog-Konfigurationsdatei geändert, um Ihre Windows-Ereignisprotokolle zu zentralisieren. Fügen Sie das Code-Snippet unten am Ende Ihres nxlog hinzu.conf-Datei aktiviert das Modul und gibt ihm den Namen „eventlog“. Das Eingabemodul im_msvialog sendet neue Einträge in das Windows-Ereignisprotokoll, einschließlich System-, hardware-, anwendungs- und sicherheitsrelevanter Ereignisse.

# 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>

Dateiprotokolle

Mit NXLog können auf einem Laufwerk gespeicherte Protokolldateien gelesen werden. In diesem Beispiel lautet der Dateiname FILE1. SavePos TRUE bedeutet, dass NXLog beim Beenden seinen aktuellen Speicherort in der Protokolldatei verfolgt. Exec $Message = $raw_event bedeutet, dass NXLog die rohe Protokollnachricht aufnimmt, ohne zusätzliche Formatierung anzuwenden. Der Dateiname kann auch Verzeichnisse oder Platzhalter enthalten.

<Input FILE1>Module im_fileFile "FILE1"SavePos TRUEExec $Message = $raw_event;</Input>

IIS-Protokolle

Wie im Abschnitt Grundlagen der Windows-Protokollierung beschrieben, enthalten IIS-Protokolle Zugriffsprotokolle, die im W3C-Format gespeichert sind. Wir empfehlen Ihnen, sie zur einfachen Verarbeitung durch ein Protokollverwaltungstool in das JSON-Format zu konvertieren. NXLog kann diese Konvertierung mit der W3C-Erweiterung durchführen. Stellen Sie sicher, dass Sie das richtige Format in der Konfigurationsdatei verwenden, damit die Analyse korrekt erfolgt und Sie Protokolldateien von allen Ihren Sites einschließen.

<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-Fehlerprotokolle

SQL Server ist Microsofts Flaggschiff-Datenbankplattform der Enterprise-Klasse. Es kommt in einer Reihe von Datenbank- und Data-Warehouse-Tools. SQL Server verfügt normalerweise über eigene Protokolle, die im Installationsverzeichnis der Anwendung im Windows-Dateisystem gespeichert sind. Der Standardspeicherort für SQL Server 2012 ist C:/Program Dateien/Microsoft SQL Server/MSSQL11.MSSQLSERVER/MSSQL/Log. Die Protokolleinträge werden auch an das Windows-Anwendungsereignisprotokoll gesendet.

SQL Server-Vorgänge wie Sichern und Wiederherstellen, Abfragezeitüberschreitungen oder langsame E / A sind daher leicht aus dem Windows-Anwendungsereignisprotokoll zu finden, während sicherheitsbezogene Meldungen wie fehlgeschlagene Anmeldeversuche im Windows-Sicherheitsereignisprotokoll erfasst werden.

Weiterleiten von Protokollen an einen Server

NXLog kann Protokolle von jeder der oben beschriebenen Eingaben an ein externes Ziel wie einen Protokollserver oder einen cloudbasierten Protokollverwaltungsdienst weiterleiten. Zu diesem Zweck verwendet NXLog Konzepte, die als Ausgaben und Routen bezeichnet werden. Ausgaben sind Module, die Funktionen zum Senden von Protokollen an ein Ziel bereitstellen, z. B. eine Datei oder einen Remoteserver. Routen sind die Pfade, die eine Protokollnachricht von einer Eingabe (z. B. dem Modul im_msvialog) zu einer Ausgabe (z. B. einem Protokollverwaltungsdienst) nimmt.

Um Protokolle weiterzuleiten, fügen Sie ein Ausgabemodul in Ihrem nxlog hinzu.conf-Konfigurationsdatei. Fügen Sie dann ein Routenmodul hinzu, um Protokolle von den ausgewählten Eingängen an die ausgewählten Ausgänge zu senden. In diesem Beispiel senden wir Protokolle als Syslog über TCP an den Host-HOSTNAMEN über den Standard-Syslog-Port 514. Wir erstellen eine Route, die Protokolle aus der Eventlog-Eingabe entnimmt und an die neue Ausgabe (mit dem Namen out) sendet):

<Output out>Module om_tcpHost HOSTNAMEPort 514</Output><Route 1>Path eventlog => out</Route>

Mehrere Protokollverwaltungslösungen bieten spezifische Setup-Anweisungen für die Windows-Protokollierung. Loggly ist ein Beispiel für einen Anbieter und enthält detailliertere Informationen zum Einrichten von NXLog zum Sammeln Ihrer Protokolldateien in dessen Handbuch Logging from Windows.

Protokolle mit TLS verschlüsseln

Standardmäßig werden über das Internet gesendete Protokolle im Klartext übertragen. Dies bedeutet, dass Schnüffler Ihre Protokolldaten abfangen und anzeigen können. Es empfiehlt sich, Ihre Protokolldaten während der Übertragung zu verschlüsseln, insbesondere wenn sie vertrauliche Informationen wie persönliche Identifikationsdaten, staatlich regulierte Daten oder Finanzinformationen enthalten. Das gebräuchlichste Protokoll zur Verschlüsselung der Syslog-Kommunikation ist TLS oder Transport Layer Security.

TLS verschlüsselt Ihre Protokolle und verhindert, dass jemand vertrauliche Daten in Ihren Protokollen ausspioniert. Best Practice ist nicht, Informationen wie Passwörter zu protokollieren, aber einige Anwendungen tun es trotzdem. TLS-Verschlüsselung hilft, diese Daten sicherer zu halten. Die Verschlüsselung verhindert, dass böswillige Parteien, die sich zwischen Ihren Protokollquellen und -zielen befinden, Ihre Protokolldaten lesen oder ändern.

Hier ist ein Beispiel zum Einrichten der NXLog-Konfiguration mit TLS-Verschlüsselung für Loggly.

1. Laden Sie das digitale Zertifikat von Loggly von der NXLog TLS-Konfigurationsseite herunter.
2. Kopieren Sie die digitale Zertifikatsdatei in Ihr NXLog-Zertifikatsverzeichnis:
   Kopieren Sie loggly_full.crt C:/Program Dateien*/nxlog/cert
3. Konfigurieren Sie Ihr Ausgabemodul mit om_ssl und dem Speicherort des Zertifikats. Der Standard-Syslog-Port für verschlüsselte Protokolle ist 6514. AllowUntrusted FALSE verhindert eine Verbindung zum Server, wenn das Zertifikat nicht vertrauenswürdig oder selbstsigniert ist:

   <Output out>Module om_sslHost server.example.comPort 6514CAFile %CERTDIR%/example.crtAllowUntrusted FALSE<Output>