Datenbanktuning: Indexanpassung

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

In diesem Thema wird beschrieben, wie Sie mithilfe der angepassten Indexdatei den Index anpassen können. Jeder NetWitness NextGen-Service wird mit einer Standardindexkonfiguration installiert, die die Indexanforderungen der meisten Benutzer des Produkts erfüllen soll. Es ist allerdings möglich, neue Metaschlüssel zu indizieren, um den Index mit angepasstem Content zu verwenden, der angepasste Metadaten erzeugt hat.

Speicherorte der Indexkonfigurationsdatei

Die Indexanpassung erfolgt, indem an der angepassten Indexdatei Änderungen vorgenommen werden. Der Speicherort dieser Datei ist /etc/netwitness/ng/index-<servicename>-custom.xml Dabei gilt Folgendes: <servicename> entspricht dem Namen des Produkts, das Sie anpassen. Zum Beispiel ist die angepasste Indexdatei des Concentrator /etc/netwitness/ng/index-concentrator-custom.xml.

Concentrator-Produkte enthalten auch eine Datei, die die Standardindexkonfiguration beschreibt: /etc/netwitness/ng/index-concentrator.xml. Diese Datei ist als Vorlage nützlich, die zeigt, wie die angepasste Indexdatei formatiert ist.

Wenn Sie Anpassungen an dem Index in der angepassten Indexdatei vornehmen, setzen diese Anpassungen jeden Konflikt mit der Standardindexkonfiguration außer Kraft.

Sie können Änderungen an der angepassten Indexdatei vornehmen, während der Service noch ausgeführt wird. Wenn der Service einen Befehl zum Speichern des Index empfängt, werden die Änderungen an der angepassten Indexdatei gelesen und auf den Index angewendet.

Änderungen am Index können nur auf neu eingehende Daten angewendet werden. Daten können nicht im Nachhinein mit einer neuen angepassten Indexkonfiguration neu indiziert werden, außer durch einen erneuten Aufbau des Index.

Indexkonfigurationseinträge

Die angepasste Indexdatei ist ein XML-Dokument. Das Stammelement dieses Dokuments ist das Element language, in dem sich ein Element pro Metaschlüssel befindet, um die einzelnen angepassten Indizes yu beschreiben. Jedes Element der angepassten Indexkonfiguration sieht wie folgt aus:

 <key name="did" description="Decoder Source" level="IndexValues" format="Text" valueMax="100" /> 

Definitionen für jedes Attribut in diesem Element: Attribut | Beschreibung -|- name | Der Name des Metaschlüssels, der indiziert wird description | Eine für Menschen lesbare Beschreibung für die Metadaten type level | Der Indextyp, der für diesen Metaschlüssel erstellt wird valueMax | Die maximal eindeutigen Werte, die für diesen Schlüssel pro Scheibe gespeichert werden format | Das Format der Daten, das alle Metaelemente mit diesem Metaschlüsselnamen aufweisen.

In den nächsten Abschnitten werden diese Parameter detaillierter untersucht.

Metanamen

Der vom Index verwendete Metaname bezieht sich auf den Namen des Metaschlüssels, der in jedem Metaelement in der Metadatenbank vorhanden ist. Diese Metanamen werden von den Decodern beim Parsen erzeugt. Parser können entscheiden, Metadaten mit jedem beliebigen Metaschlüsselnamen zu erzeugen. Daher erlaubt Ihnen der angepasste Index, auszuwählen, welche der vom Decoder erzeugten Metaelemente indiziert werden.

Metaschlüsselnamen können 16 Zeichen lang sein und enthalten nur Buchstaben oder das Zeichen „.“.

Datentypen

Wenn der Decoder Metaelemente erzeugt, weist er einen Datentyp zu. Jeder Parser kann den Datentyp der Metadaten, die er erzeugt, selbst auswählen. Es gibt allerdings empfohlene und Standarddatentypen für jeden der Standardmetaschlüssel. Zum Beispiel werden ip.src und ip.dst als der IPv4-Metadatentyp gespeichert und alias.host wird als Textmetadatentyp gespeichert. Jeder Parser muss das Datenformat für jeden vom Decoder erzeugten Metaschlüssel festlegen.

Wenn ein angepasster Index zum Concentrator hinzugefügt wird, muss der Datentyp des angepassten Index mit dem Format der vom Decoder erzeugten Daten übereinstimmen. Wenn die Typen nicht übereinstimmen, versucht der Concentrator, die erzeugten Metadaten in den Typ zu konvertieren, der für den angepassten Index angegeben wurde. Allerdings schlagen diese Konvertierungen manchmal fehl und der resultierende Index kann undefinierte Ergebnisse produzieren.

Ebenso gilt: Wenn viele Decoder und Concentrator als Teil einer NetWitness-Installation zusammen eingesetzt werden, müssen sie sich auf die Typen für jeden Metaschlüssel einigen. Konflikte zwischen NetWitness NextGen-Services in Bezug auf Metadatentypen können zu undefiniertem Verhalten führen.

In der folgenden Tabelle sind die Metadatentypen geyeigt, die von den NetWitness NextGen-Services unterstützt werden.

                                                                                           
Typ Größe in Byte Beschreibung
Int8 1 Signierte 8-Bit-Ganzzahl
UInt8 1 Unsignierte 8-Bit-Ganzzahl
Int16 2 Signierte 16-Bit-Ganzzahl
UInt16 2 Unsignierte 16-Bit-Ganzzahl
Int32 4 Signierte 32-Bit-Ganzzahl
UInt32 4 Unsignierte 32-Bit-Ganzzahl
Int64 8 Signierte 64-Bit-Ganzzahl
UInt64 8 Unsignierte 64-Bit-Ganzzahl
UInt128 16 Unsignierte 128-Bit-Ganzzahl
Float32 4 32-Bit-Gleitkommazahl, einfache Genauigkeit
Float64 8 64-Bit-Gleitkommazahl, doppelte Genauigkeit
Zeit t 8 Unix epoc Zeitstempel
Binär 1–255 Arbiträre Binärdaten
Text 1–255 UTF-8 Codierte Textdaten
IPv4 4 IPv4-Adressbyte
IPv6 16 IPv6-Adressbyte
MAC 6 MAC-Adressbyte

Beim Definieren eines angepassten Index ist es wichtig, den besten Datentyp für die Metadaten zu verwenden. Speichern Sie zum Beispiel niemals IP-Adressen als Text, da die Textrepräsentation mehr Byte benötigt als die IPv4-Repräsentation.

Indexlevel

Es gibt drei Level, oder Typen, der Indexierung: IndexNone, IndexKeys und IndexValues.

IndexNone

Dieser Typ eines angepassten Index ist gar kein richtiger Index. Angepasste Indexeinträge mit dem Level IndexNone bestehen nur, um den Metaschlüssel zu definieren und zu dokumentieren. IndexNone-Einträge können in angepassten Decoder-Indexen verwendet werden, um einen spezifischen Datentyp für einen Metaschlüssel über alle Parser auf einem Decoder durchzusetzen.

IndexKeys

Dieser Typ eines angepassten Index zeigt an, dass der Index nur solche Sitzungen nachverfolgt, die Metaelemente mit diesem Metaschlüsselnamen enthalten. Allerdings indiziert er keine eindeutigen Werte in der Metadatenbank für den Metaschlüssel.

Key-Level-Indexe lassen sich mit viel weniger Speicherplatz, Arbeitsspeicher und CPU-Zeit managen, aber sie erfordern viel mehr Arbeit von der Abfrage-Engine, wenn Sie mit ihnen Abfrage- oder Wertoperationen durchführen.

Wenn er in einer Where-Klausel verwendet wird, kann ein auf dem Key-Level indexierter Metaschlüssel nur verwendet werden, um Operationen wie „existiert“ oder „!existiert“ zu lösen.

IndexValues

Dieser Typ von angepasstem Index hält Sitzungen, die jeden einzelnen eindeutigen Wert für den Metaschlüssel enthalten. Dieser Indextyp ist auch als „vollständiger Index“ bekannt.

Dieser Indextyp ist erforderlich für die effiziente Verarbeitung der meisten Where-Klauseln und für die Verwendung dieses Metaschlüssels als fieldName-Parameter eines Wertaufrufs.

Value Max

Value max ist ein Parameter, der einen sehr signifikanten Einfluss auf die Genauigkeit und Performance eines Wert-Level-Index haben kann.

Während ein Decoder Pakete oder Protokolle parst, ist es erlaubt, Metadaten jeden Typs mit jedem Wert zu erstellen. Normalerweise werden diese Metaelemente aus Daten erstellt, die direkt aus dem Paket oder Protokoll kopiert wurden. Daher kann jeder eindeutige Metawerte in Reaktion auf beinahe jedes Ereignis erstellen.

Die Performance des Index hängt direkt von der Anzahl eindeutiger Werte ab, die er für jeden Metaschlüssel gefunden hat. Während die Anzahl eindeutiger Werte steigt, kann die Rate, mit der neue Metadaten indexiert werden, abnehmen und die Geschwindigkeit, mit der Abfragen abgeschlossen werden, nimmt ab. Da jede beliebige Person die Erstellung eindeutiger Metawerte beeinflussen kann, ist es für jede beliebige Person möglich, die Performance des Index zu beeinflussen.

Der Parameter value max begrenzt die Anzahl eindeutiger Werte, die in den Index eingehen können. So kann kein böswilliger Benutzer das System mit einer großen Anzahl eindeutiger Werte überfluten, um das NetWitness-System funktionsunfähig zu machen.

Es ist wichtig, einen maximalen Wert für jeden Metaschlüssel einzustellen, dessen Wert möglicherweise direkt durch eingehende Pakete oder Protokolle beeinflusst wird.

Der maximale Wert gilt nur für Werte, die seit dem letzten Speichervorgang des Index hinzugefügt wurden.

Der Grenzwert dafür, wie hoch der maximale Wert eingestellt werden kann, variiert von Version zu Version und hängt von der Menge des verfügbaren RAM für den NetWitness NextGen-Service ab. Für die Version 10.3 liegt der empfohlene obere Grenzwert für value max bei 5.000.000 für jeden Metaschlüssel. Wenn es viele angepasste Indexe gibt, dann muss value max möglicherweise niedriger sein.

maxLength

Der Parameter „maxLength“ wird ausschließlich für den Metadatentyp word verwendet. Er muss mit der entsprechenden Einstellung für /decoder/parsers/config/token.max.length/ im Log Decoder-Service übereinstimmen, der Tokenmetadaten erzeugt. Der Index verwendet „maxLength“, um Suchbegriffe richtig zu interpretieren, die in die SDK-Funktion msearch eingegeben werden.

Umbenennen von Schlüsseln

Die Indexsprache unterstützt das Konzept der Umbenennung von Schlüsseln. Diese Funktion wird verwendet, um die Abwärtskompatibilität für neue Schlüsselnamen bereitzustellen, um alte Schlüsselnamen einzustellen und zu ersetzen. Eine Umbenennung wird erreicht, indem Sie rename-Elemente zu dem Schlüssel hinzufügen. Damit wird angegeben, dass der übergeordnete Schlüssel den Schlüssel im rename-Element umbenennt. Mit der Schlüsseldefinition unten wird beispielsweise ein neuer Schlüssel mit dem Namen port_src definiert, der den Schlüssel tcp.srcport umgebenennt.

 <key name="port_src" description="Source Port" format="UInt16" level="IndexValues"> <rename name="tcp.srcport"/> </key> 

Das rename-Element weist die Datenbank darauf hin, dass bei Verwendung des übergeordneten Schlüssels, in diesem Fall port_src, sowohl die Metadatenelemente vom Typ „port_src“ als auch Metadatenelemente vom Typ „tcp.srcport“ eingeschlossen werden. Daher können neue Metadatenelemente mithilfe von port_src zur Datenbank hinzugefügt und aus dieser abgefragt werden und solche Abfragen geben Informationen zurück, die zuvor auch in „tcp.srcport“ gespeichert wurden.

Das rename-Element akzeptiert ein einziges Attribut, name, das auf einen zuvor definierten Schlüssel verweist.

Schlüssel, auf die von rename-Elementen verwiesen wird, müssen denselben Typ wie der übergeordnete Schlüssel aufweisen.

Schlüssel, auf die von rename-Elementen verwiesen wird, müssen denselben Indexlevel wie der übergeordnete Schlüssel aufweisen.

Wenn ein Schlüssel in einer benutzerdefinierten Indexdatei neu definiert wird und der neu definierte Schlüssel rename-Elemente enthält, ersetzen diese rename-Elemente alle zuvor definierten rename-Elemente.

Previous Topic:Abfragen
You are here
Table of Contents > Indexanpassung

Attachments

    Outcomes