Decoder: Konfigurieren der 10G-Funktion

Document created by RSA Information Design and Development on May 9, 2018
Version 1Show Document
  • View in full screen mode
 

In diesem Thema erfahren Administratoren, wie ein Paket-Decoder speziell für die Hochgeschwindigkeits-Paketerfassung mit NetWitness Suite 11.0 optimiert werden kann. Dies gilt für die Erfassung von Paketen über die 10G-Schnittstellenkarte. Für die Hochgeschwindigkeits-Paketerfassung ist eine sorgfältige Konfiguration erforderlich, da diese die Decoder-Hardware stark belastet. Lesen Sie daher das gesamte Thema, wenn Sie eine 10G-Erfassungslösung implementieren möchten.

RSA NetWitness Suite bietet Unterstützung für die Hochgeschwindigkeitserfassung auf dem Decoder. Sie können Netzwerkdatenpakete von schnelleren Netzwerken erfassen und Ihren Packet Decoder so optimieren, dass Netzwerkdatenverkehr bis zu 8 Gbit/s bei kontinuierlichem Durchsatz und bis zu 10 Gbit/s bei Belastungsspitzen erfasst werden kann, je nachdem, welche Parser und Feeds aktiviert sind.

Zu den Verbesserungen bei der Erfassung in diesen Umgebungen gehören folgende:

  • Verwendung der Treibererfassungsfunktion pf_ring, um die handelsübliche 10G-Netzwerkschnittstellenkarte von Intel für die Hochgeschwindigkeitserfassung nutzen zu können.
  • Einführung der assembler.parse.valve-Konfiguration, durch die die Anwendungsparser bei Überschreitung bestimmter Schwellenwerte automatisch deaktiviert werden, um die Gefahr eines Datenpaketverlusts einzudämmen. Wenn die Anwendungsparser deaktiviert sind, sind Parser der Netzwerkschicht weiterhin aktiv. Wenn die Statistikwerte wieder unter den Schwellenwert sinken, werden die Anwendungsparser automatisch erneut aktiviert.

Hardwarevoraussetzungen

  • Ein Decoder der Serie 4S oder 5
  • Eine Intel 82599-basierte Ethernetkarte, z. B. Intel x520. Alle von RSA bereitgestellten 10G-Karten erfüllen diese Anforderung. Zwei Beispiele:
    • Alle von RSA zur Verfügung gestellten SMC-10GE-Karten
    • Eine Dell Network Daughter Card mit einem Intel-Controller, die 10G-Netzwerkschnittstellen zur Verfügung stellt. Dies ist in jeglicher Hardware der Serie 5 enthalten.
  • Nur bei der Serie 4S/Dell R620: 96 GB DD3-1600-Arbeitsspeicher in Dual-Rank-DIMMs. Single-Rank-DIMMs können die Performance um bis zu 10 % verringern. Führen Sie zur Ermittlung der Geschwindigkeit und des Rank-Typs der installierten DIMMs folgenden Befehl aus:
    dmidecode -t 17.
  • Ausreichend großer und schneller Speicher zur Erfüllung der Erfassungsanforderungen. Überlegungen zum Speicher werden später in diesem Thema behandelt.
  • Jeder Packet Decoder wurde mit mindestens zwei DACs oder SAN-Verbindung konfiguriert.

Softwarevoraussetzungen

  • Bei Dell R620-basierten Systemen, z. B. der Serie 4S, muss das BIOS auf v1.2.6 oder höher aktualisiert werden.
  • Die 10G-Decoder-Funktion wird nur in von RSA bereitgestellten Decoder-Installations-Images unterstützt. Jegliche erforderliche Software wird standardmäßig installiert.
  • Wenn Sie ein Upgrade einer früheren Version durchführen, sollten Sie dies abgeschlossen haben, bevor Sie mit der Konfiguration fortfahren.

Installieren des 10G-Decoders

Hinweis: Wenn Sie über neue Hardware der Serie 5 verfügen, können Sie direkt mit „Konfigurieren des 10G-Decoders“ fortfahren.

Führen Sie die folgenden Schritte aus, um den NetWitness 10G-Decoder zu installieren:

Herunterladen und Aktualisieren des BIOS

Hinweis: Bei früheren BIOS-Versionen vor v1.2.6 treten Probleme bei der eindeutigen Identifizierung des Orts der 10G-Erfassungskarte innerhalb des Systems auf. Es wird empfohlen, dass Kunden eine Aktualisierung auf das aktuelle BIOS v2.2.3 durchführen, aber es ist nicht erforderlich für 10G, wenn Sie v1.2.6 oder höher ausführen.

  1. Laden Sie BIOS v2.2.3 von folgendem Speicherort herunter:

    http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=V7P04

  2. Laden Sie das Updatepaket für Red Hat Linux herunter.
  3. Kopieren Sie die Datei auf den NetWitness-Server.
  4. Melden Sie sich als root an.
  5. Ändern Sie die Berechtigungen für die Datei auf execute.
  6. Führen Sie die folgende Datei aus:

    ./BIOS_V7P04_LN_2.2.3.BIN

  7. Starten Sie das System neu, wenn die Ausführung abgeschlossen und ein Neustart erforderlich ist.

Hinweis: Das BIOS-Installationsverfahren dauert ungefähr 10 Minuten.

Suchen nach den Decoder 10G-Paketen

Die zum Konfigurieren des 10G-Decoders erforderlichen Pakete sollten sich bereits im Decoder-Installations-Image befinden. Sie sollten keine zusätzlichen Pakete installieren müssen. Die Pakete, die die 10G-Treiberfunktion bieten, sind folgende:

  • pfring-dkms-6.5.0-6.rpm
  • ixgbe-zc-4.1.5.6-dkms.noarch.rpm

Überprüfen, ob 10G-Decoder-Pakete installiert sind

Die Installation der 10G-Decoder-Pakete wird automatisch durchgeführt. Daher sollten keine Maßnahmen zur Aktivierung der 10G-Funktion erforderlich sein.

  • Wenn Sie für die Kernel-Pakete ein Upgrade durchgeführt haben, ist ein Neustart erforderlich. Das Betriebssystem wird neu kompiliert und Treiber für den aktualisierten Kernel werden installiert.
  • Wenn Sie bei Auswahl des Erfassungsportadapters (im Folgenden beschrieben) zusätzliche PFRINGZC-Schnittstellen sehen, war die Installation erfolgreich.

Konfigurieren des 10G-Decoders

Führen Sie die folgenden Schritte aus, um den 10G-Decoder zu konfigurieren:

  1. Klicken Sie in der Decoder Explorer-Ansicht mit der rechten Maustaste auf Decoder und wählen Sie Eigenschaften aus.
  2. Wählen Sie im Drop-down-Menü „Eigenschaften“ die Option reconfig aus und geben Sie die folgenden Parameter ein:
    update=1 op=10g
    Dadurch wird die Pipeline der Decoder-Paketverarbeitung für einen höheren Durchsatz von Rohdaten, aber weniger Parsingmöglichkeiten angepasst.
  3. Klicken Sie in der Ansicht Decoder Explorer mit der rechten Maustaste auf Datenbank und wählen Eigenschaften aus.
  4. Wählen Sie im Drop-down-Menü Eigenschaften die Option reconfig aus und geben Sie die folgenden Parameter ein:
    update=1 op=10g
    Dadurch wird die Paketdatenbank an die Verwendung von sehr großen Dateien und direktes I/O angepasst.
  5. Wählen Sie den Erfassungsportadapter aus. Hierzu gehören die folgenden Optionen:
    • Erfassung von einem Port: PFRINGZC,p1p1 oder PFRINGZC,p1p2
    • Erfassung von beiden Ports: Wählen Sie PFRINGZC,P1P1 aus und legen Sie in der Explorer-Ansicht capture.device.params = device=zc:p1p2,zc:p1p1 fest.
  6. Wenn der Schreib-Thread Schwierigkeiten hat, die Geschwindigkeit der Erfassung zu unterstützen, können Sie Folgendes versuchen:

    Ändern Sie /datebase/config/packet.integrity.flush zu normal.

    Hinweis: Sie können versuchen, packet.file.size auf einen höheren Wert einzustellen, aber halten Sie die Dateigröße unter 10 GB, da die gesamte Datei im Arbeitsspeicher gepuffert wird.

  7. (Optional) Das Parsen von Anwendungen ist äußerst CPU-intensiv und kann dazu führen, dass der Decoder Pakete verliert. Um Paketverluste durch das Anwendungsparsing zu vermeiden, können Sie /decoder/config/assembler.parse.valve auf true festlegen. Dies sind die Ergebnisse:

    • Wenn das Sitzungsparsing zum Engpass wird, werden die Anwendungsparser (HTTP, SMTP, FTP usw.) vorübergehend deaktiviert.
    • Sitzungen gehen nicht verloren, wenn die Anwendungsparser deaktiviert werden, nur die Genauigkeit des auf diesen Sitzungen durchgeführten Parsings nimmt ab.
    • Sitzungen, die geparst werden, wenn die Anwendungsparser deaktiviert sind, haben immer noch zugehörige Netzwerkmetadaten (vom Netzwerkparser).
    • Die Statistik /decoder/parsers/stats/blowoff.count zeigt die Anzahl aller Sitzungen an, die Anwendungsparser umgangen haben (Netzwerkparsing wird immer noch durchgeführt).
    • Wenn Sitzungsparsing nicht länger ein potentieller Engpass ist, werden die Anwendungsparser automatisch wieder aktiviert.
    • Der Assembler-Sitzungspool sollte groß genug sein, um Sitzungen nicht zu erzwingen.
    • Sie können über die Statistik /decoder/stats/assembler.sessions.forced ermitteln, ob Sitzungen erzwungen werden (die Werte würden ansteigen). Außerdem würde sich /decoder/stats/assembler.sessions innerhalb mehrerer hundert von /decoder/config/assembler.session.pool befinden.
  8. (Optional) Wenn Sie die MTU für die Erfassung anpassen möchten, fügen Sie den Parameter snaplen zu capture.device.params hinzu. Im Gegensatz zu früheren Versionen muss snaplen nicht auf eine bestimmte Grenze aufgerundet werden. Der Decoder passt die MTU an den Erfassungsschnittstellen automatisch an.

  9. Die folgenden Konfigurationsparameter sind veraltet und nicht mehr erforderlich:

    • Der core= parameter in capture.device.params
    • Alle Konfigurationsdateien im Verzeichnis /etc/pf_ring

    Hinweis: Ein nach dem Erstellen eines neuen Image installiertes Ethernetgerät benötigt keine Konfiguration zur Verwendung als Erfassungsgerät. Eine Konfiguration ist nur dann erforderlich, wenn es als Netzwerkschnittstelle verwendet wird oder wenn Systemprogramme ohne manuelle Konfiguration darauf zugreifen.

Typische Konfigurationsparameter

Typische Konfigurationsparameter sind unten aufgeführt. Die tatsächlichen Parameter variieren je nach Arbeitsspeichermenge und CPU-Ressourcen, die zur Verfügung stehen.

  1. Einstellungen für Sitzungs- und Paketpool (unter /decoder/config):
    • pool.packet.pages = 1000000
    • pool.session.pages = 300000
  2. Blockgröße des Paketschreibvorgangs unter (/database/config/packet.write.block Größe) festgelegt auf filesize

    Hinweis: Dies konfiguriert den Decoder, die Datei mit sehr langen Seiten zu puffern und für maximale Performance mithilfe von direktem I/O zu schreiben.

  3. Parse-Thread-Anzahl (unter /decoder/config)

    parse.threads =12

Überlegungen zum Speicher

Bei der Erfassung mit 10G-Leitungsgeschwindigkeit muss das Speichersystem, auf dem die Paket- und Metadatenbank liegt, in der Lage sein, einen Schreibdurchsatz von 1.400 MB/s aufrechtzuerhalten.

Verwenden der Hardware der Serie 4S (mit zwei oder mehreren DAC-Einheiten)

Die Serie 4S ist mit einem Hardware-RAID-SAS-Controller ausgerüstet, der einen aggregierten I/O-Durchsatz von 48 Gbit/s unterstützt. Er verfügt über acht externe 6-Gbit-Ports, die in zwei SAS-Kabeln mit je 4 Bahnen zusammengefasst sind. Die empfohlene Konfiguration für 10G sieht mindestens zwei ausgeglichen aufgeteilte DAC-Einheiten für diese zwei externen Verbindungen vor. Beispiel: Schließen Sie einen DAC an einen Port auf der SAS-Karte und dann den zweiten DAC an den anderen Port auf der SAS-Karte an.

Für Umgebungen mit mehr als zwei DACs verbinden Sie sie von jedem Port in ausgewogener Weise. Dafür ist unter Umständen eine erneute Verkabelung der DACs in der bestehenden Bereitstellung erforderlich. Dies sollte sich jedoch nicht auf die Daten auswirken, die bereits auf dem Decoder erfasst wurden.

Wenn Sie neue Speicherkapazität hinzufügen, verwenden Sie das derzeit verfügbare Skript NwMakeArray, um die DAC-Einheiten bereitzustellen. Das Skript fügt automatisch einen DAC pro Ausführung hinzu (d. h. wenn drei DACs hinzugefügt werden sollen, muss das Skript dreimal ausgeführt werden). Die DACs werden der NwDecoder10G-Konfiguration als separate Mount-Punkte hinzugefügt. Die unabhängigen Mount-Punkte sind wichtig, da sie NwDecoder10G ermöglichen, I/O-Schreibvorgänge der Erfassung von I/O-Lesevorgängen zu trennen, die zum Erfüllen der Paketinhaltsanforderungen erforderlich sind.

Verwenden von SAN und anderen Speicherkonfigurationen

Der Decoder ermöglicht jede Speicherkonfiguration, die die Anforderung für kontinuierlichen Durchsatz erfüllt. Der standardmäßige 8-Gbit-FC-Link zu einem SAN ist nicht ausreichend, um Paketdaten bei 10G zu speichern. Um ein SAN verwenden zu können, muss daher ggf. eine Linkzusammenfassung mithilfe eines Software-RAID-Schemas auf mehreren Zielen durchgeführt werden. Somit sind Umgebungen mit SAN erforderlich, um die Verbindung zum SAN mit mehreren FCs zu konfigurieren.

Überlegungen zum Parsing und Inhalt

Das Parsen von Rohdatenpaketen bei hohen Geschwindigkeiten bringt einzigartige Herausforderungen mit sich. Angesichts der höheren Sitzungs- und Paketraten kommt der Parsingeffizienz die höchste Bedeutung zu. Ein einziger ineffizienter Parser (der zu lange für die Paketuntersuchung braucht) kann das gesamte System bis zu einem Punkt verlangsamen, an dem Pakete an der Karte abgewiesen werden.

Beginnen Sie anfängliche 10G-Tests nur mit nativen Parsern (außer SMB/WebMail). Verwenden Sie native Parser, um eine Baseline-Performance ohne oder mit nur sehr wenigen Paketverlusten zu ermitteln. Laden Sie keine Live-Inhalte herunter, bis dies erfolgt ist und das System die Erfassung bei hohen Geschwindigkeiten nachweislich ohne Probleme durchführt.

Nachdem das System betriebsbereit ist und reibungslos funktioniert, sollten Live-Inhalte (insbesondere Parser) sehr langsam hinzugefügt werden. 

Best Practices

Unabhängig davon, ob Sie ein derzeit bereitgestelltes System aktualisieren oder ein neues System bereitstellen, wird empfohlen, dass Sie die folgenden Best Practices anwenden, um die Gefahr eines Datenpaketverlusts weitestgehend zu vermeiden. Ein Vorbehalt besteht dabei, wenn Sie eine aktuelle 10G-Bereitstellung aktualisieren, jedoch keinen zusätzlichen Datenverkehr hinzufügen. Beispielsweise sollte bei einem aktuellen Decoder, der die Erfassung von einer 10G-Karte mit einem kontinuierlichen 2G-Durchsatz durchführt, keine Performanceabweichung auftreten, es sei denn, die Aktualisierung bedingt auch das Hinzufügen von zusätzlichem Datenverkehr für die Erfassung.

  • Integrieren Sie Baseline-Parser (außer SMB/Webmail, die in der Regel eine hohe CPU-Auslastung haben) und überwachen Sie sie, um sicherzustellen, dass nur wenige oder gar keine Datenpakete verloren gehen.
  • Beim Hinzufügen zusätzlicher Parser dürfen Sie nur jeweils einen oder zwei Parser gleichzeitig hinzufügen.
  • Messen Sie die Auswirkung des neu hinzugefügten Inhalts auf die Performance, vor allem in Spitzenzeiten mit hohem Datenverkehrsaufkommen.
  • Wenn nun im Gegensatz zu vorher Paketverluste auftreten, deaktivieren Sie alle neu hinzugefügten Parser, aktivieren Sie sie einzeln nacheinander und messen Sie die Auswirkung. Hierdurch kann leichter ermittelt werden, welche Parser sich negativ auf die Performance auswirken. Es besteht die Möglichkeit, die Parser umzugestalten, um eine bessere Performance zu erzielen, oder den Funktionsumfang nur auf die für das Fallbeispiel des Kunden erforderlichen Funktionen zu reduzieren.
  • Obwohl Feeds sich nur geringfügig auf die Performance auswirken, sollten sie auch überprüft und schrittweise hinzugefügt werden, um die Messung der Performanceauswirkungen zu erleichtern.
  • Bei Anwendungsregeln lassen sich auch eher nur geringfügige Auswirkungen feststellen, obwohl es sich dennoch empfiehlt, nicht zu viele Regeln gleichzeitig hinzuzufügen, ohne die Auswirkung auf die Performance zu messen.

Darüber hinaus können durch die empfohlenen Konfigurationsänderungen, die im Abschnitt „Konfiguration“ erläutert werden, potenzielle Probleme minimiert werden.

Getestete Live-Inhalte

Die folgenden Parser können für unser Test-Dataset alle (nicht jeder einzelne) bei 10G ausgeführt werden:

  • MA-Inhalte (7 Lua-Parser,1 Feed, 1 Anwendungsregel)
  • 4 Feeds (alert ids info, nwmalwaredomains, warning und suspicious)
  • 41 Anwendungsregeln
  • DNS_verbose_lua (DNS deaktivieren)
  • fingerprint_javascript_lua
  • fingerprint_pdf_lua
  • fingerprint_rar_lua
  • fingerprint_rtf_lua
  • MAIL_lua (MAIL deaktivieren)
  • SNMP_lua (SNMP deaktivieren)
  • spectrum_lua
  • SSH_lua (SSH deaktivieren)
  • TLS_lua
  • windows_command_shell
  • windows_executable

NICHT GETESTET:

  • SMB_lua, natives SMB standardmäßig deaktiviert
  • html_threat

ANDERE:

  • HTTP_lua, reduziert die Erfassungsrate von >9G auf <7G. Bei knapp unter 5G kann dieser Parser statt des nativen Parsers ohne Verluste (zusätzlich zur Liste oben) verwendet werden. 
  • „xor_executable“ lastet die Parser-CPU zu 100 % aus und beim System können aufgrund des Parsebackups Verluste auftreten.

Aggregationsanpassungen basierend auf getesteten Live-Inhalten

Ein 10G-Decoder kann bei Ausführung bei einer Geschwindigkeit von 10G die Aggregation für einen einzigen Concentrator übernehmen. Bereitstellungen, die Malware Analysis, Event Stream Analysis, Warehouse Connector und Reporting Engine verwenden, beeinträchtigen voraussichtlich die Performance und können zu Paketverlusten führen.

Beim getesteten Szenario aggregiert der Concentrator 45–70.000 Sitzungen/Sek. Der 10G-Decoder erfasst 40–50.000 Sitzungen/Sek. Bei den oben genannten Inhalten entspricht dies ca. 1,5 bis 2 Millionen Meta/Sek. Aufgrund der großen Anzahl von Sitzungen werden die folgenden Konfigurationsänderungen empfohlen:

  • Mit der „nice“-Aggregation auf dem Concentrator kann die Performanceauswirkung auf dem 10G-Decoder begrenzt werden. Mit dem folgenden Befehl wird die „nice“-Aggregation aktiviert.
    /concentrator/config/aggregate.nice = true
  • Aufgrund der großen Anzahl von Sitzungen auf dem Concentrator sollten Sie erwägen, den Modus „parallel values“ auf dem Concentrator zu aktivieren, indem Sie den Wert /sdk/config/parallel.values auf 16 festlegen. Hierdurch wird die Investigation-Performance verbessert, wenn die Anzahl der Sitzungen pro Sekunde über 30.000 liegt.
  • Wenn mehrere Aggregationsstreams erforderlich sind, hat das Aggregieren vom Concentrator geringere Auswirkungen auf den Decoder.
  • Weitere Prüfungen auf Inhalte und Parsing sind für Bereitstellungen erforderlich, bei denen andere NetWitness Suite-Komponenten verwendet werden sollen (z. B. Warehouse, Malware Analysis, ESA und Reporting Engine).

 

You are here
Table of Contents > Decoder und Log Decoder – zusätzliche Verfahren > Konfigurieren der 10G-Funktion

Attachments

    Outcomes