CLI: Beispiele für den Befehl „sdk content“

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

Das erste Beispiel für den NwConsole Befehl „sdk content“ unten ist einfach und zeigt alle Befehle, die Sie eingeben müssen. Die dann folgenden Beispiele zeigen nur die sdk content-Befehle. Im ersten Beispiel wird eine Protokolldatei erstellt und es werden die ersten 1.000 Protokolle von einem Concentrator abgerufen, der von einem Log Decoder aggregiert:

sdk open nw:://admin:netwitness@myconcentrator.local:50005

sdk output /tmp

sdk content sessions=1-1000 render=logs append=mylogs.log fileExt=.log

Dieses Skript gibt 1.000 Protokolle in die Datei /tmp/mylogs.log aus (vorausgesetzt, dass die Sitzungen 1 bis 1000 auf dem Service vorhanden sind). Die Protokolle liegen im Klartextformat vor. Der Parameter fileExt=.log ist erforderlich, um dem Befehl anzuzeigen, dass eine Protokolldatei ausgegeben werden soll.

sdk content sessions=1-1000 render=logs append=mylogs.log fileExt=.log includeHeaders=true separator=","

Mit diesem Befehl werden dieselben 1.000 Protokolle abgerufen wie oben, es wird jedoch der Protokoll-Header analysiert und Zeitstempel, Weiterleitung und andere Informationen über das Protokoll werden extrahiert und in einer CSV-Datei abgelegt.

Beispiel CSV: 1422401778,10.250.142.64,10.25.50.66,hop04b-LC1,%MSISA-4: 81.136.243.248...

Der Zeitstempel ist in der Epoch-Zeit angegeben. Die Parameter includeHeaders und separator können nur auf NetWitness Suite-Installationen 10.4.0.2 und höher verwendet werden.

sdk content sessions=l-now render=logs append=mylogs.log fileExt=.log includeHeaders=true separator="," where="risk.info='nw35120'"

Dieser Befehl schreibt eine Protokolldatei über den aktuellen Sitzungsbereich, aber nur für Protokolle, die risk.info='nw35120' entsprechen. Denken Sie daran, dass beim Hinzufügen einer Where-Klausel angeben eine Abfrage im Hintergrund durchgeführt wird, um die Sitzungs-IDs für den Export zu erfassen. Die Abfrage sollte auf einem Service ausgeführt werden, auf dem die entsprechenden Feldern indexiert sind (normalerweise ein Broker oder Concentrator). Da Sie eine Abfrage für das Feld risk.info durchführen, überprüfen Sie in diesem Fall den Service, auf dem Sie den Befehl ausführen, um sicherzustellen, dass er auf Wertebene indexiert ist (IndexValues, siehe die Datei index-concentrator.xml für Beispiele). Standardmäßig ist bei den meisten Decodern nur die Zeit indexiert. Wenn Sie ein anderes Feld als das Zeitfeld in der Where-Klausel verwenden, müssen Sie die Abfrage vom Decoder auf einen Concentrator, Broker oder Archiver mit den richtigen Indexebenen für die Abfrage verschieben. Weitere Informationen zur Indexierung und zum Schreiben von Abfragen finden Sie im Tuning-Leitfaden für NetWitness Suite-Core-Datenbanken.

sdk content sessions=l-now render=logs append=mylogs.log fileExt=.log includeHeaders=true separator="," where="threat.category exists && time='2015-01-05 15:00:00'-'2015-01-05 16:00:00'"

Dieser Befehl entspricht dem Befehl oben, sucht aber nur nach passenden Protokollen zwischen 15:00 Uhr und 16:00 Uhr (UTC) am 5. Januar 2015, die über den Metaschlüssel threat.category verfügen. Da diese Abfrage ebenfalls ein anderes Feld als die Zeit in der Where-Klausel enthält (threat.category), sollte sie auf einem Service ausgeführt werden, auf dem threat.category mindestens auf Ebene von IndexKeys indexiert ist (die Operatoren exists und !exists erfordern nur eine Indizierung auf Schlüsselebene, obwohl Werte ebenso funktionieren).

sdk content sessions=l-now render=logs append=mylogs fileExt=.log where="event.source begins 'microsoft'" maxFileSize=1gb

Dieser Befehl erstellt mehrere Protokolldateien, die jeweils nicht größer als 1 GiB sind. Den Dateinamen wird mylogs vorangestellt und das Datum und die Uhrzeit des ersten Paket/Protokoll-Zeitstempels in der Datei angehängt. Einige Beispieldateinamen: mylogs-1-2015-Jan-28T11_08_14.log, mylogs-2-2015-Jan-28T11_40_08.log and mylogs-3-2015-Jan-28T12_05_47.log. Auf Versionen, die älter als Security Analytics 10.5 sind, ist das T-Trennzeichen zwischen Datum und Uhrzeit ein Leerzeichen.

sdk content sessions=l-now render=pcap append=mypackets where="service=80,21 && time='2015-01-28 10:00:00'-'2015-01-28 15:00:00'" splitMinutes=5 fileExt=.pcap

Dieser Befehl erfasst alle Pakete im Fünf-Stunden-Zeitraum für die Servicetypen 80 und 21 und schreibt eine PCAP-Datei. Alle 5 Minuten wird eine neue PCAP-Datei geschrieben.

sdk content time1="2015-01-28 14:00:00" time2="2015-01-28 14:15:00" render=pcap append=mydecoder fileExt=.pcap maxFileSize=512mb sessions=l-now

Seien Sie bei diesem Befehl vorsichtig. Warum? Er funktioniert für Pakete und Protokolle und ist extrem schnell. Der Nachteil ist, dass alles zurückgegeben wird, was zwischen den beiden Zeitbereichen liegt und Sie keine Where-Klausel verwenden können. Auch hier beginnt das Rück-Streaming nahezu sofort und es muss nicht erst eine Abfrage im Back-end durchgeführt werden. Da alles mithilfe sequenzieller I/O gelesen wird, kann die Netzwerkverbindung zwischen Server und Client voll ausgelastet werden. Es wird mit der Erstellung von Dateien begonnen, denen mydecoder vorangestellt wird, und mit einer neuen Datei fortgefahren, sobald eine Größe von 512 MiB erreicht ist.

sdk tailLogs

oder (der entsprechende Befehl):

sdk content render=pcap console=true sessions=now-u

Dies ist ein nützlicher Befehl. Er verwendet im Hintergrund sdk content. Der Zweck dieses Befehls ist es, alle eingehenden Protokolle auf einen Log Decoder anzuzeigen. Nicht mehr. Es handelt sich um einen sehr einfachen Befehl. Wenn Protokolle den Log Decoder erreichen (der Befehl kann auch auf einem Broker oder Concentrator ausgeführt werden) werden Sie auf dem Konsolenbildschirm ausgegeben. Dies ist eine hervorragende Möglichkeit, um festzustellen, ob die Erfassung auf dem Log Decoder erfolgt und was genau den Log Decoder erreicht. Dieser Befehl wird im kontinuierlichen Modus ausgeführt. Verwenden Sie ihn nicht, wenn die Erfassung auf dem Log Decoder mit der höchsten Aufnahmerate erfolgt (der Befehl kann nicht Schritt halten). Er ist aber zu Überprüfungs- oder Troubleshooting-Zwecken nützlich.

sdk tailLogs where="device.id='ciscoasa'" pathname=/mydir/anotherdir/mylogs

Dieser Befehl ist derselbe wie oben, jedoch werden nur Protokolle ausgegeben, die der Where-Klausel entsprechen. Die Ausgabe erfolgt zudem nicht über die Konsole, sondern in einen Satz Protokolldateien unter /mydir/anotherdir, die nicht größer als 1 GiB werden. Dies ist natürlich auch mit dem Befehl sdk content möglich, aber es erfordert mit diesem Befehl weniger Schreibarbeit, wenn Ihnen das Standardverhalten ausreicht.

sdk content sessions=now-u render=pcap where="service=80" append=web-traffic fileExt=.pcap maxFileSize=2gb maxDirSize=100gb

Dieser Befehl beginnt mit dem Schreiben von PCAPs des gesamten Webdatenverkehrs ab der letzten Sitzung einschließlich aller neu eingehenden Sitzungen, für die „service=80“ zutrifft. Es werden PCAPs mit einer maximalen Größe von 2 GiB geschrieben und wenn alle PCAPs im Verzeichnis zusammen mehr als 100 GiB groß sind, werden so lange die ältesten PCAPs gelöscht, bis das Verzeichnis um 10 % kleiner als die maximale Größe ist. Beachten Sie, dass die Überprüfung der Verzeichnisgröße nicht präzise ist und standardmäßig nur alle 15 Minuten erfolgt. Sie können die Anzahl der Minuten zwischen den Überprüfungen durch Übergabe von cacheMinutes als Parameter anpassen, dies funktioniert aber nur in Security Analytics 10.5 und höher.

sdk content sessions=79000-79999 render=nwd append=content-%1%.nwd metaFormatFilename=did

Dies ist eine Art Backupbefehl. Es werden 1.000 Sitzungen erfasst und ihr gesamter Inhalt (Sitzungen, Metadaten, Pakete oder Protokolle) wird im NWD-Format (NetWitness Data Format) ausgegeben. NWD ist ein spezielles Format, das ohne Analyse in ein Paket oder einen Log Decoder reimportiert werden kann. Prinzipiell wird die ursprünglich analysierte Sitzung ohne Änderungen importiert. Der Zeitstempel wird ebenfalls nicht verändert. Wenn die Analyse ursprünglich vor 6 Monaten erfolgte, wird beim Import der Zeitstempel mit dem Datum von vor 6 Monaten beibehalten. 

Hinweis: Erwarten Sie bei diesem Befehl keine großartige Performance, insbesondere nicht bei Paketen. Das Sammeln der Pakete für eine Sitzung umfasst viel zufällige I/O und kann den Export drastisch verlangsamen. Protokolle sind von diesem Problem nicht so stark betroffen (nur ein Protokoll pro Sitzung), aber im Hintergrund dieses Befehls wird die „/sdk content“-API verwendet. Dabei handelt es sich nicht um eine performanceorientierte Streaming-API wie beispielsweise „/sdk packets“. Erwarten Sie daher also keine großartige Performance.

Der Parameter metaFormatFilename ist bei diesem Befehl sehr hilfreich. Wenn Sie diesen Befehl auf einem Concentrator mit mehr als einem Service ausführen, werden die NWD-Dateinamen mit dem Metawert did für jede Sitzung erstellt („%1%“ im angehängten Parameter wird durch den Wert von did ersetzt). Jeder Dateiname gibt genau an, von welchem Decoder die Daten stammen.

sdk content session=l-u where="service=80,139,25,110" render=files maxDirSize=200mb cacheMinutes=10

Dies ist ein weiterer nützlicher Befehl. Er funktioniert sehr ähnlich wie unser altes Visualize-Produkt, wenn Sie das Ausgabeverzeichnis mit Windows-Explorer im Symbolmodus kombinieren. Der Befehl extrahiert die Daten aus dem gesamten Web-, E-Mail- und SMB-Datenverkehr. Dies umfasst alle möglichen Dateien, z. B. Bilder, .zip-Dateien, Videos, PDF-Dateien, Office-Dokumente, Textdateien, ausführbare Dateien und Audiodateien. Wenn dabei Schadsoftware extrahiert wird, wird diese vom Virenscanner markiert. Sie müssen sich jedoch keine Gedanken machen, durch den Befehl wird nichts ausgeführt, daher wird der Computer nicht infiziert (es sei denn, Sie versuchen selbst, die Schadsoftware auszuführen). Der Befehl kann allerdings nützlich sein, denn wenn Sie Schadsoftware finden, zeigt der Dateiname an, aus welcher Sitzungs-ID diese extrahiert wurde. Sie können dann diese Sitzungs-ID abfragen und sehen, welcher Host potenziell mit der Schadsoftware infiziert wurde und Maßnahmen ergreifen. Mit den Parametern includeFileTypes oder excludeFileTypes können Sie filtern, was extrahiert wird (siehe Hilfe zum Befehl). Wenn Sie beispielsweise excludeFileTypes=".exe;.dmg;.msi" hinzufügen, werden keine ausführbaren Dateien und Installationsprogramme extrahiert. Dieser Befehl wird ununterbrochenen ausgeführt und extrahiert Dateien aus allen vorhandenen und neuen Sitzungen. Sobald das Verzeichnis mehr als 200 MiB Dateien enthält, wird es automatisch alle 10 Minuten bereinigt. 

Hinweis: Dieser Befehl ist nur für Paketsitzungen sinnvoll, nicht für Protokolle.

sdk content session=1-now where="time='2015-01-27 12:00:00'-'2015-01-27 13:00:00' && (service=25,110,80)" subdirFileTypes="audio=.wav;.mp3;.aac; video=.wmv;.flv;.mp4;.mpg;.swf; documents=.doc;.xls;.pdf;.txt;.htm;.html images=.png;.gif;.jpg;.jpeg;.bmp;.tif;.tiff archive=.zip;.rar; other=*" renameFileTypes=".download|.octet-stream|.program|.exe;.jpeg|.jpg" render=files maxDirSize=500mb

Dieser Befehl extrahiert Dateien aus HTTP- und E-Mail-Sitzungen aus einem 1-Stunden-Zeitraum und gruppiert die extrahierten Dateien dann in Verzeichnisse, die durch den Parameter subdirFileTypes angegeben werden. Beispielsweise werden alle extrahierten Audiodateien mit der Erweiterung .wav, .mp3 oder .aac im Unterverzeichnis „audio“ platziert, dass unter dem angegebenen Ausgabeverzeichnis erstellt wird. Gleiches gilt für alle anderen in diesem Parameter angegebenen Gruppen. Einige Dateien werden außerdem automatisch basierend auf der Dateierweiterung umbenannt. Dies wird von renameFileTypes ausgeführt. Jede Datei mit der Erweiterung .download, .octet-stream oder .program wird in .exe umbenannt. Dateien mit der Erweiterung .jpeg werden in .jpg umbenannt. Sobald das oberste Verzeichnis 500 MiB überschreitet, werden die ältesten Dateien bereinigt. Dieser Befehl wird bei der zum Zeitpunkt des Befehlsstarts letzten Sitzung beendet.

sdk search session=l-now where="service=80,25,110" search="keyword='party' sp ci"

Dieser Befehl durchsucht alle Pakete und Protokolle (Parameter sp) nach dem Schlüsselwort party. Wenn „party“ an einer beliebigen Stelle in den Paketen oder Protokollen gefunden wird, wird die Sitzungs-ID zusammen mit dem gefundenen Text und dem umgebenden Text als Kontext ausgegeben. Die Where-Klausel gibt an, dass nur Web- und E-Mail-Datenverkehr durchsucht wird. Der Parameter ci bedeutet, dass es sich um eine Suche ohne Berücksichtigung der Groß-/Kleinschreibung handelt. Sie können regex durch keyword ersetzen, dann wird eine Regex-Suche durchgeführt.

sdk search session=l-now search="keyword='checkpoint' sp ci" render=log append=checkpoint-logs.log fileExt=.log

Dies ist ein interessantes Befehlsbeispiel. Bei diesem Befehl werden alle Protokolle (dies funktioniert auch mit Paketen) nach dem Schlüsselwort checkpoint durchsucht. Wird dieses gefunden, so wird das Protokoll in eine Datei checkpoint-logs.log extrahiert. Dieser Befehl bietet eine Vielzahl an Möglichkeiten. Prinzipiell wird die Sitzung bei einer ermittelten Übereinstimmung an den Inhaltsaufruf übergeben. Alle nicht erkannten Parameter, die Sie an sdk search übergeben, werden an den Inhaltsaufruf übergeben. Dadurch wird der volle Funktionsumfang des sdk content-Abrufs ermöglicht, aber nur für die Sitzungen ausgeführt, für die Treffer bei der Inhaltssuche erzielt werden. Leistungsstarke Befehle wollen überlegt eingesetzt werden.

You are here
Table of Contents > CLI: Beispiele für den Befehl „sdk content“

Attachments

    Outcomes