Protokolle von Aruba Wireless Controller und Access Point erfassen

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie mit Bindplane Logs von Aruba Wireless Controller und Access Point erfassen. Der Parser verarbeitet SYSLOG-Nachrichten und extrahiert Felder mit Details zu Beobachter, Vermittler und Zugriffspunkt. Anschließend werden diese Felder dem Unified Data Model (UDM) zugeordnet und die Ereignisdaten werden mit dem Schweregrad des Sicherheitsergebnisses angereichert. Außerdem werden verschiedene Fehlerbedingungen während des Prozesses behandelt.

Hinweise

  • Prüfen Sie, ob Sie eine Google Security Operations-Instanz haben.
  • Achten Sie darauf, dass Sie Windows 2016 oder höher oder einen Linux-Host mit systemd verwenden.
  • Wenn Sie einen Proxy verwenden, müssen die Firewallports geöffnet sein.
  • Sie benötigen privilegierten Zugriff auf einen Aruba Wireless Controller.

Authentifizierungsdatei für die Aufnahme in Google SecOps abrufen

  1. Melden Sie sich in der Google SecOps-Konsole an.
  2. Rufen Sie SIEM-Einstellungen > Collection Agents auf.
  3. Laden Sie die Authentifizierungsdatei für die Aufnahme herunter. Speichern Sie die Datei sicher auf dem System, auf dem BindPlane installiert wird.

Google SecOps-Kundennummer abrufen

  1. Melden Sie sich in der Google SecOps-Konsole an.
  2. Rufen Sie die SIEM-Einstellungen > „Profil“ auf.
  3. Kopieren und speichern Sie die Kunden-ID aus dem Bereich Organisationsdetails.

BindPlane-Agent installieren

Fenstereinbau

  1. Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.

  2. Führen Sie dazu diesen Befehl aus:

    msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Linux-Installation

  1. Öffnen Sie ein Terminal mit Root- oder Sudo-Berechtigungen.

  2. Führen Sie dazu diesen Befehl aus:

    sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Zusätzliche Installationsressourcen

BindPlane-Agent zum Erfassen von Syslog-Daten und Senden an Google SecOps konfigurieren

  1. Greifen Sie auf die Konfigurationsdatei zu:

    1. Suchen Sie die Datei config.yaml. Normalerweise befindet es sich unter Linux im Verzeichnis /etc/bindplane-agent/ oder unter Windows im Installationsverzeichnis.
    2. Öffnen Sie die Datei mit einem Texteditor (z. B. nano, vi oder Notepad).

  2. Bearbeiten Sie die Datei config.yamlso:

    receivers:
    udplog:
        # Replace the port and IP address as required
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the path to the credentials file you downloaded in Step 1
        creds: '/path/to/ingestion-authentication-file.json'
        # Replace with your actual customer ID from Step 2
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        # Add optional ingestion labels for better organization
        ingestion_labels:
            log_type: ARUBA_WIRELESS
            raw_log_field: body

service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - udplog
            exporters:
                - chronicle/chronicle_w_labels

  3. Ersetzen Sie den Port und die IP-Adresse nach Bedarf in Ihrer Infrastruktur.

  4. Ersetzen Sie <customer_id> durch die tatsächliche Kunden-ID.

  5. Aktualisieren Sie /path/to/ingestion-authentication-file.json auf den Pfad, in dem die Authentifizierungsdatei im Abschnitt Google SecOps-Aufnahmeauthentifizierungsdatei abrufen gespeichert wurde.

Bindplane-Agent neu starten, um die Änderungen zu übernehmen

  • Führen Sie den folgenden Befehl aus, um den Bindplane-Agent unter Linux neu zu starten:

    sudo systemctl restart bindplane-agent

  • Wenn Sie den Bindplane-Agent unter Windows neu starten möchten, können Sie entweder die Konsole Dienste verwenden oder den folgenden Befehl eingeben:

    net stop BindPlaneAgent && net start BindPlaneAgent

Aruba Wireless Controller und Access Point konfigurieren

  1. Melden Sie sich in der Aruba-Controller-Web-UI an.
  2. Wählen Sie im oberen Menü Konfiguration > System aus.
  3. Wählen Sie Logging aus, um die Seite mit der Logging-Konfiguration zu öffnen.
  4. Klicken Sie im Bereich Syslog-Server auf + Hinzufügen, um einen neuen Syslog-Server hinzuzufügen.
  5. Ein neues Formular wird angezeigt, in das Sie die folgenden Informationen eingeben müssen:
    • Name: Geben Sie einen eindeutigen Namen für den Syslog-Server ein, z. B. Google SecOps Syslog.
    • IP-Adresse: Geben Sie die Bindplane-IP-Adresse ein.
    • Port: Geben Sie die Bindplane-Portnummer ein (normalerweise 514 für UDP).
    • Logging Facility: Wählen Sie im Menü local6 aus (wird häufig für Netzwerkgeräte verwendet).
    • Logging Level (Logebene): Wählen Sie Informational (Informationen) aus, um Informationslogs zu erfassen.
    • Format: Wählen Sie das Format bsd-standard aus. Dies ist das standardmäßige Syslog-Format, das von Aruba-Controllern verwendet wird.
  6. Klicken Sie auf Einreichen, um Ihre Einstellungen zu speichern.
  7. Klicken Sie auf Ausstehende Änderungen.

  8. Klicken Sie auf Änderungen bereitstellen, um die neue Syslog-Serverkonfiguration anzuwenden.

  9. Rufen Sie die Einstellungen für Protokollierungsebene auf und legen Sie die Protokollierungsebene für jede der folgenden Kategorien auf Informationen fest:

    • Netzwerk
    • Alle
    • Cluster
    • DHCP
    • GP
    • Mobilitätshilfen
    • Paket-Dump
    • SDN

UDM-Zuordnungstabelle

Logfeld UDM-Zuordnung Logik
Additional Info read_only_udm.security_result.description Der Wert von Additional Info aus dem Rohlog wird dem UDM-Feld security_result.description zugeordnet.
AP read_only_udm.target.hostname Wenn der Wert im Rohlog vorhanden ist, wird der Wert nach AP: extrahiert und dem UDM-Feld target.hostname zugeordnet.
BSSID read_only_udm.target.mac, read_only_udm.principal.resource.name (wenn der Ressourcentyp BSSID ist) Der BSSID-Wert aus dem Rohlog wird target.mac zugeordnet. Er wird auch als Ressourcenname verwendet, wenn principal.resource.type gleich BSSID ist.
COMMAND read_only_udm.principal.process.command_line Der Befehlswert aus dem Rohlog wird dem UDM-Feld principal.process.command_line zugeordnet.
Dst-MAC read_only_udm.target.mac Falls vorhanden, wird der Dst-MAC-Wert aus dem Rohlog dem UDM-Feld target.mac zugeordnet.
SERVER read_only_udm.target.hostname Wenn der Servername im Rohlog vorhanden ist, wird er dem UDM-Feld target.hostname zugeordnet.
SERVER-IP read_only_udm.target.ip Wenn vorhanden, wird die Server-IP-Adresse aus dem Rohlog dem UDM-Feld target.ip zugeordnet.
Src-MAC read_only_udm.principal.mac Falls vorhanden, wird der Src-MAC-Wert aus dem Rohlog dem UDM-Feld principal.mac zugeordnet.
SSID read_only_udm.target.resource.name (wenn der Ressourcentyp „SSID“ ist) Der SSID-Wert aus dem Rohlog wird als Ressourcenname verwendet, wenn target.resource.type gleich SSID ist.
USER read_only_udm.target.user.userid Wenn sie vorhanden ist, wird die Nutzer-ID aus dem Rohlog dem UDM-Feld target.user.userid zugeordnet.
USERIP read_only_udm.principal.ip, read_only_udm.observer.ip Wenn vorhanden, wird die Nutzer-IP aus dem Rohlog dem UDM-Feld principal.ip und observer.ip zugeordnet.
USERMAC read_only_udm.principal.mac Wenn vorhanden, wird die MAC-Adresse des Nutzers aus dem Rohlog dem UDM-Feld principal.mac zugeordnet.
USERNAME read_only_udm.principal.user.userid Wenn der Nutzername im Rohlog vorhanden ist, wird er dem UDM-Feld principal.user.userid zugeordnet.
action read_only_udm.security_result.action Der Aktionswert aus dem Rohlog (z.B. permit, deny) wird dem UDM-Feld security_result.action zugeordnet.
apname read_only_udm.target.hostname Wenn vorhanden, wird der AP-Name aus dem Rohlog dem UDM-Feld target.hostname zugeordnet.
bssid read_only_udm.target.mac Falls vorhanden, wird der BSSID-Wert aus dem Rohlog dem UDM-Feld target.mac zugeordnet.
collection_time.seconds read_only_udm.metadata.event_timestamp.seconds Der Sekundenwert der Erfassungszeit aus dem Rohlog wird dem UDM-Feld metadata.event_timestamp.seconds zugeordnet.
device_ip read_only_udm.intermediary.ip Die Geräte-IP aus dem Rohlog oder von logstash wird dem UDM-Feld intermediary.ip zugeordnet.
dstip read_only_udm.target.ip Wenn vorhanden, wird die Ziel-IP-Adresse aus dem Rohlog dem UDM-Feld target.ip zugeordnet.
dstport read_only_udm.target.port Falls vorhanden, wird der Zielport aus dem Rohlog dem UDM-Feld target.port zugeordnet.
event_id read_only_udm.metadata.product_event_type Die Ereignis-ID aus dem Rohlog wird verwendet, um das Feld metadata.product_event_type im UDM zu erstellen. Es wird mit Event ID: vorangestellt.
event_message read_only_udm.security_result.summary Die Ereignisnachricht aus dem Rohlog wird dem UDM-Feld security_result.summary zugeordnet.
log.source.address read_only_udm.observer.ip Die Logquellenadresse wird dem UDM-Feld observer.ip zugeordnet.
log_type read_only_udm.metadata.log_type Der Logtyp aus dem Rohlog wird dem UDM-Feld metadata.log_type zugeordnet.
logstash.collect.host read_only_udm.observer.ip oder read_only_udm.observer.hostname Der Logstash-Erfassungs-Host wird entweder observer.ip zugeordnet, wenn es sich um eine IP-Adresse handelt, oder observer.hostname, wenn es sich um einen Hostnamen handelt.
logstash.ingest.host read_only_udm.intermediary.hostname Der Logstash-Aufnahmehost wird dem UDM-Feld intermediary.hostname zugeordnet.
logstash.process.host read_only_udm.intermediary.hostname Der Host des Logstash-Prozesses wird dem UDM-Feld intermediary.hostname zugeordnet.
program read_only_udm.target.application Der Programmname aus dem Rohlog wird dem UDM-Feld target.application zugeordnet.
serverip read_only_udm.target.ip Wenn vorhanden, wird die Server-IP-Adresse aus dem Rohlog dem UDM-Feld target.ip zugeordnet.
servername read_only_udm.target.hostname Wenn der Servername im Rohlog vorhanden ist, wird er dem UDM-Feld target.hostname zugeordnet.
srcip read_only_udm.principal.ip Wenn vorhanden, wird die Quell-IP-Adresse aus dem Rohlog dem UDM-Feld principal.ip zugeordnet.
srcport read_only_udm.principal.port Falls vorhanden, wird der Quellport aus dem Rohlog dem UDM-Feld principal.port zugeordnet.
syslog_host read_only_udm.intermediary.hostname Der Syslog-Host aus dem Rohlog wird dem UDM-Feld intermediary.hostname zugeordnet.
timestamp read_only_udm.metadata.event_timestamp Der Zeitstempel aus dem Rohlog wird geparst und dem UDM-Feld metadata.event_timestamp zugeordnet.
userip read_only_udm.principal.ip, read_only_udm.observer.ip Wenn vorhanden, wird die Nutzer-IP aus dem Rohlog dem UDM-Feld principal.ip und observer.ip zugeordnet.
usermac read_only_udm.principal.mac Wenn vorhanden, wird die MAC-Adresse des Nutzers aus dem Rohlog dem UDM-Feld principal.mac zugeordnet.
username read_only_udm.principal.user.userid Wenn der Nutzername im Rohlog vorhanden ist, wird er dem UDM-Feld principal.user.userid zugeordnet. Abgeleitet von event_id und der Logik im Parser. Wird vom Parser anhand der Ereignis-ID und des Inhalts der Log-Nachricht bestimmt. Hartcodiert auf Wireless. Hartcodiert auf Aruba. Wird vom Parser anhand der Ereignis-ID und des Inhalts der Log-Nachricht bestimmt. Wird vom Parser anhand der Ereignis-ID und des Inhalts der Log-Nachricht bestimmt. Mit regulären Ausdrücken aus der Roh-Log-Nachricht extrahiert. Wird vom Parser anhand der Ereignis-ID und des Inhalts der Log-Nachricht bestimmt. Ein leeres Objekt wird hinzugefügt, wenn „event_type“ USER_LOGIN oder ein zugehöriges Authentifizierungsereignis ist. Wird vom Parser basierend auf dem im Ereignis verwendeten Netzwerkprotokoll bestimmt (z.B. TCP, UDP, ICMP, IGMP). Enthält zusätzliche Felder, die unter bestimmten Bedingungen aus dem Rohlog extrahiert wurden. Wenn beispielsweise ap_name vorhanden ist, wird es als Schlüssel/Wert-Paar hinzugefügt. Auf BSSID setzen, wenn eine BSSID im Kontext des Hauptkontos vorhanden ist. Wird auf SSID gesetzt, wenn im Kontext des Ziels eine SSID vorhanden ist. Enthält Schlüssel/Wert-Paare mit relevanten Informationen zur Erkennung, die aus dem Rohlog extrahiert wurden, z. B. BSSID oder SSID.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten