Ereignisse - Häufig gestellte Fragen

Verwenden Sie diese häufig gestellten Fragen und Antworten zu Ereignissen, um zu verstehen, wie QRadar® Benutzeraktivitäten in Protokolldateien korreliert, um Angriffe zu generieren.

Was ist ein Ereignis?

In QRadarist ein Ereignis eine Nachricht, die von einer Einheit in Ihrem Netz empfangen und verarbeitet wird, und ein Protokoll einer bestimmten Aktion auf dieser Einheit. Beispielsweise sind eine SSH-Anmeldung auf einem UNIX-Server, eine VPN-Verbindung zu einem VPN-Gerät oder eine von Ihrer Perimeterfirewall protokollierte Zurückweisung durch eine Firewall Ereignisse. Diese Aktionen treten zu einem bestimmten Zeitpunkt auf und werden in Protokolldateien aufgezeichnet.

Was ist ein eindeutiges Ereignis?

QRadar identifiziert ein eindeutiges Ereignis anhand einer Reihe von Eigenschaften: Quellen-IP, Ziel-IP, Zielport, Protokoll, Benutzername und Protokollquellen-ID oder Ereignis-ID. Unter bestimmten Bedingungen ist auch der Quellenport relevant. Wenn vier Ereignisse mit denselben Schlüsseleigenschaften auftreten, werden sie 10 Sekunden lang zu einem einzigen Datensatz verbunden. Nach Ablauf dieses Zeitraums wiederholt sich der Zyklus.

Was ist das Verbinden von Ereignissen?

Durch das Verbinden von Ereignissen wird die Datenmenge verringert, die von der Ereignispipeline verarbeitet werden muss. Indem eintreffende Daten verbunden werden, können bei einem großen Ereignisanstieg Hunderttausende von Einzelereignissen in nur einige Dutzend Datensätze umgewandelt werden. Diese Aktion wird ausgeführt, während QRadar die Anzahl der tatsächlichen Ereignisse verwaltet. Durch die Verbindung kann QRadar einen Angriff in großem Umfang erkennen, aufzählen und verfolgen. Es dient auch zum Schutz der Leistungsfähigkeit der Pipeline, indem die Arbeitslast des Systems sowie der Speicherbedarf für diese Ereignisse reduziert wird.

Beim Normalisieren von Daten tritt eine Einschränkung der Verbindung von Ereignissen auf. Das erste Ereignis in einem verbundenen Datensatz wird als Basissatz verwendet und ist das einzige Ereignis, das einschließlich seiner Nutzdaten vollständig gespeichert wird. Für Einheiten und Protokollquellen, mit denen Audit- und Konformitätsanforderungen in Ihrer Umgebung verfolgt werden, können Sie das Verbinden von Ereignissen deaktivieren. Beispiele für solche Einheiten sind angepasste Anwendungen, Services mit Kundenkontakt, kritische Assets und andere wichtige Einheiten.

Welche Unterschiede bestehen zwischen den verschiedenen Ereignis- und Protokollquellen?

Viele verschiedene Protokollquellen und Arten von Protokollquellen werden von QRadarunterstützt, z. B. Firewalls, Authentifizierungsgeräte, Scanner, Dateiserver, Anwendungsplattformen usw. Jeder dieser Protokollquellentypen, auf den in QRadarBezug genommen wird, stellt eine andere Perspektive und einen anderen Typ von Informationen zu Ihrem Netz bereit. Beispielsweise dokumentiert eine Firewall die Anzahl der fernen Systeme, die versuchen, auf Ihr Netz zuzugreifen. Gleichzeitig liefert Ihnen ein Windows- oder LDAP -Authentifizierungsserver Informationen über lokale Mitarbeiter, die sich bei Netzwerkressourcen anmelden. Ihre Überwachungs-, Prüf-und Sicherheitsanforderungen beeinflussen die Arten von Protokollquellen, die Sie an QRadarsenden.

Kann die Syntaxanalyse von Ereignissen bei Verwendung einer Lastausgleichsfunktion von einem beliebigen Ereigniskollektor ausgeführt werden? Werden mehrere Protokollquellen erstellt?

Jede Syslog-basierte Quelle, die Daten an eine Lastausgleichsfunktion vor QRadar sendet, kann auf allen Ereigniskollektoren analysiert werden. Alle automatisch erkannten Protokollquellen in QRadar können von jedem Ereigniskollektor in der Implementierung verarbeitet werden. Wenn die automatische Erkennung ausgelöst wird und eine Anforderung zum Erstellen einer Protokollquelle an QRadar Consolegesendet wird, wird die Protokollquelle erstellt. Innerhalb einer Minuten sind alle Ereignisprozessoren und -kollektoren über die Existenz dieser neuen Protokollquelle informiert, und jegliche Daten, die an einen beliebigen Ereignisprozessor gesendet werden, werden automatisch dieser Protokollquelle zugeordnet. Sie können also eine Lastausgleichsfunktion vor mehreren Ereigniskollektoren und -prozessoren aktivieren.

In diesem Szenario wird eine Protokollquelle erstellt. In den ersten paar Minuten, nachdem eine Protokollquelle erkannt wurde, können mehrere Prozessoren den Befehl create (Erstellen) senden, doch es wird nur eine Protokollquelle erstellt. Wenn der Protokollquellenmanager in QRadar Console den Befehl create empfängt, erstellt er die Protokollquelle, wenn die Protokollquelle nicht vorhanden ist. Wenn die Protokollquelle bereits vorhanden ist, ignoriert der Protokollquellenmanager die Anforderung zum Erstellen.

Was bedeuten die unterschiedlichen Zeitmarken in den Ereignisdetails?

Diese Zeitmarken können unterschiedliche Werte haben, je nachdem, woher die Daten stammen, wann die Daten angekommen sind und wann sie in QRadargeschrieben wurden. In der folgenden Liste werden die verschiedenen Zeitmarken erläutert:
  • Startzeit
    Ein Ereignisdatensatz, der darstellt, wann das Ereignis von einem QRadar -Ereigniskollektorempfangen wird Sobald ein Ereignis in der Pipeline ankommt, wird im Speicher ein Objekt erstellt und dieser Zeitpunkt in der Zeitmarke Startzeit festgelegt.
  • Uhrzeit der Speicherung
    Dies gibt an, zu welchem Zeitpunkt die Daten am Ende der Verarbeitung durch die Ereignispipeline von der Komponente Ariel auf den Datenträger geschrieben werden. Anhand dieser Zeitmarke lässt sich bestimmen, ob Ereignisse in der Ereignispipeline aus Leistungs- oder Lizenzgründen in eine Warteschlange eingereiht werden.
  • Protokollquellenzeit
    Dies ist die Zeitangabe aus den Ereignisnutzdaten, normalerweise die Uhrzeit im Syslog-Header. Einige Protokollquellen enthalten jedoch die Zeitmarken in den Nutzdaten, wie z. B. Windows-Protokolle, die ein Feld MessageTime im Hauptteil der Nutzdaten enthalten. Wenn die Nutzdaten keine Zeitangabe enthalten, wird das Feld Protokollquellenzeit mit demselben Wert gefüllt, wie das Feld Startzeit.

Wie ordnet QRadar Ereignissen eine Quellen-und eine Ziel-IP-Adresse zu?

QRadar -Ereignisse erfordern sowohl eine Quellen-als auch eine Ziel-IP. QRadar verwendet die folgenden Positionen, um eine IP-Adresse zu lokalisieren:

  • In den Ereignisnutzdaten (erste Methode)
    Unterstützte Protokollquellen (und universelle Protokollquellen, falls Sie Ihre eigenen regulären Ausdrücke für die Syntaxanalyse erstellen) durchsuchen die Nutzdaten der empfangenen Ereignisse nach einer Quellen- und Ziel-IP-Adresse. Wenn diese Adressen gefunden werden, werden sie in die zugeordneten Felder Source und Destination der Ereignisdatensätze eingefügt. Wenn die Nutzdaten keine IP-Adressen enthalten, werden die nachfolgend beschriebenen Methoden verwendet.
  • Im Feld Hostname des Syslog-Headers (zweite Methode)
    Wenn die Ereignisnutzdaten keine IP-Adressen enthalten, wird das Feld Hostname des Syslog-Headers verwendet. Das Feld Hostname ist gängig bei Ereignissen von Ereignisquellen, die in dem Feld nur die Angabe Quellenadresse haben, wie z. B. Web-Serviceprotokolle, die nur die IP-Adresse des fernen Hosts enthalten. Bei diesen Ereignistypen wird die Ziel-IP-Adresse mit der Angabe aus dem Syslog-Header oder aus dem Feld Hostname des Ereignisses gefüllt. Wenn der Syslog-Header oder das Feld Hostname keine IP-Adresse, sondern einen Hostnamen enthält, wird keine DNS-Suche durchgeführt, sondern stattdessen die dritte Methode verwendet.
  • In der Quellen-IP-Adresse des Netzpakets (dritte Methode)
    Wenn weder in den Ereignisnutzdaten noch im Feld Hostname des Syslog-Headers IP-Adressen vorhanden sind, wird die Quellen-IP-Adresse des Netzpakets als IP-Adresse verwendet. Wenn die Quellen-IP-Adresse aus den Nutzdaten ermittelt werden konnte, wird die Paket-IP-Adresse nur im Feld Destination IP address (Ziel-IP-Adresse) verwendet. In diesem Fall war die Einheit, die QRadar sendet, die Zieladresse des Ereignisses. Manchmal kann weder die Quellen- noch die Ziel-IP-Adresse weder in den Nutzdaten noch im Feld Hostname des Syslog-Headers ermittelt werden. In diesem Fall wird sowohl der Quellen- als auch der Ziel-IP-Adresse die IP-Adresse des Netzpakets zugewiesen.

Wie ordnet QRadar IP-Adressen von zentralen Syslog-Servern und NAT-Einheiten zu?

Wenn Sie über eine vorhandene zentrale Syslog-Service-Infrastruktur verfügen oder eine Weiterleitungsregel zu diesem Gerät hinzufügen, die einen Datenstrom aller Ereignisse in das QRadar-System kopiert. Die IP-Adresse, die von QRadar verwendet wird, ist die IP-Paketadresse. Wenn Sie einen zentralen Syslog-Server nutzen, wird die IP-Adresse des Servers in vielen Ereignissen und in den Protokollquellennamen verwendet.

Um diese Situation zu vermeiden, konfigurieren Sie den zentralen Syslog-Server so, dass jedem neuen Syslog-Header ein Präfix hinzugefügt wird. Dieser neue Header enthält die ursprüngliche Quellen-IP-Adresse des Pakets, das empfangen wurde. In diesem Verfahren, das beim Weiterleiten von Ereignissen üblich ist, stellt QRadar diese Option als Teil der Konfiguration für Weiterleitungsziele bereit. Wenn Sie das Präfix hinzufügen, befindet sich die IP-Adresse der ursprünglichen Ereignisquelleneinheit immer im Syslog-Headerfeld Hostname und QRadar verwendet diese IP-Adresse in den Ereignissen. Bei NAT-Einheiten müssen Sie eventuell bis zu den Protokollquelleneinheiten zurückgehen und diese so konfigurieren, dass statt des zeichenfolgebasierten Hostnamens die IP-Adresse des Hosts im Feld Hostname des Syslog-Headers verwendet wird. Bei den syslog-ng-Services wird diese Option beispielsweise als chain_hostname bezeichnet.

(Zurück nach oben)