Keywords für Nutzdaten

Keywords für die Nutzdaten untersuchen den Inhalt eines Pakets oder eines bestimmten Puffers.

content

Das Keyword content ist die Basis für alle Signaturen. Sein Wert ist ein String zwischen doppelten Anführungszeichen:

content: "lorem ipsum";

Es können mehrere content-Keywords in einer Signatur verwendet werden.

Der Inhalt wird Byte-weise abgeglichen. Der Abgleich kann auf alle druckbaren Zeichen erfolgen, indem sie in das Keyword content eingetragen werden. Nicht druckbare Zeichen werden in hexadezimaler Schreibweise zwischen Pipe-Zeichen abgebildet.

Zum Beispiel:

content: "GET /|69 6E 64 65 78 2E 68 74 6D 6C| HTTP/1.0";

Beachten Sie, dass es reservierte Zeichen gibt, die Sie im Keyword content nicht verwenden können, da sie in der Signatur eine Bedeutung haben. Um Vergleiche mit diesen Zeichen anzustellen, müssen Sie die hexadezimale Schreibweise verwenden. Es ist Konvention, die Hexadezimalzahlen in Großbuchstaben zu schreiben. Reservierte Zeichen sind:

Zeichen

Hexadezimale Schreibweise

„

|22|

;

|3B|

:

|3A|

|

|7C|

Siehe die ASCII-Tabelle für eine umfassende Liste von Zeichen und ihren Hexadezimalwerten.

Weiterhin kann ! für Ausnahmen verwendet werden.

Zum Beispiel:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Outdated Firefox on
Windows"; content:"User-Agent|3A| Mozilla/5.0 |28|Windows|3B| ";
content:"Firefox/3."; distance:0; content:!"Firefox/3.6.13";
distance:-10; sid:9000000; rev:1;)

Hier bedeutet content:!"Firefox/3.6.13";, dass eine Warnung ausgelöst wird, wenn die verwendete Firefox-Version nicht 3.6.13 ist.

Standardmäßig wird beim Mustervergleich die Groß- und Kleinschreibung berücksichtigt.

nocase

Wenn Sie nicht zwischen Groß- und Kleinschreibung unterscheiden möchten, verwenden Sie den Modifikator nocase.

Platzieren Sie ihn nach dem Inhalt, der modifiziert werden soll. Zum Beispiel:

content: "abc"; nocase;

depth

Der Inhaltsmodifikator depth hat einen obligatorischen numerischen Wert, zum Beispiel:

depth:12;

Der Wert nach depth gibt an, wie viele Bytes ab Beginn der Nutzdaten geprüft werden.

offset

Das Keyword offset gibt an, ab welchem Byte die Nutzdaten auf einen Treffer geprüft werden.

Die Keywords offset und depth können kombiniert werden und werden oft gemeinsam verwendet.

Zum Beispiel:

content:"def"; offset:3; depth:3;

In diesem Beispiel werden die Nutzdaten ab dem dritten bis zum sechsten Byte geprüft.

distance

Das Keyword distance ist ein relativer Inhaltsmodifikator. Es gibt eine Beziehung zwischen dem aktuellen content-Keyword und dem vorausgehenden an. distance wird nach dem vorausgehenden Treffer wirksam.

Das Keyword distance hat einen obligatorischen vorzeichenbehafteten Wert. Dieser Wert gibt an, ab welchem Byte die Nutzdaten auf einen Treffer relativ zum vorhergehenden Treffer geprüft werden.

distance bestimmt, wo cognitix Threat Defender anfängt nach einem Muster zu suchen. Zum Beispiel bedeutet distance:5;, dass sich das Muster irgendwo nach dem vorhergehenden Treffer plus 5 Bytes befindet. Verwenden Sie within, um zu beschränken, wie weit nach dem letzten Treffer cognitix Threat Defender suchen soll.

within

Das Keyword within ist relativ zum vorausgehenden Treffer. Das Keyword within muss einen positiven Wert haben. Die Verwendung von within stellt sicher, dass es nur dann einen Treffer gibt, wenn der Inhalt innerhalb der festgelegten Anzahl von Bytes mit den Nutzdaten übereinstimmt.

startswith

Das Keyword startswith entspricht depth:<Musterlänge>;. Es nimmt keine Argumente an und muss einem content-Keyword folgen. Es modifiziert content, so dass es direkt am Beginn eines Puffers übereinstimmen muss.

Zum Beispiel:

content:"GET|20|"; startswith;

startswith ist eine verkürzte Notation für:

content:"GET|20|"; depth:4; offset:0;

startswith darf nicht zusammen mit depth, offset, within oder distance für dasselbe Muster verwendet werden.

endswith

Das Keyword endswith entspricht isdataat:!1,relative;. Es nimmt keine Argumente an und muss einem content-Keyword folgen. Es modifiziert content, so dass es direkt am Ende eines Puffers übereinstimmen muss.

Zum Beispiel:

content:".php"; endswith;

endswith ist eine verkürzte Notation für:

content:".php"; isdatat:!1,relative;

Bemerkung

Sie können startswith und endswith kombinieren, um zu prüfen, ob ein Muster den kompletten Puffer ausfüllt. Zum Beispiel:

http.uri; content:"/index.html"; startswith; endswith;

isdataat

Mit isdataat wird geprüft, ob sich Daten in einem bestimmten Teil der Nutzdaten befinden. Das Keyword beginnt mit einer positiven Zahl (der Position), optional gefolgt von einem Komma und relative. Mit relative wird geprüft, ob sich Daten in einem bestimmten Teil der Nutzdaten relativ zum vorausgehenden Treffer befinden.

Das folgende Beispiel illustriert eine Signatur, die nach Byte 512 der Nutzdaten sucht:

isdataat:512;

Das zweite Beispiel illustriert eine Signatur, die nach Byte 50 nach dem letzten Treffer sucht:

isdataat:50, relative;

Die Option rawbytes wird nicht unterstützt.

bsize

Das Keyword bsize vergleicht die Pufferlänge, um die Genauigkeit des Inhaltsvergleichs zu erhöhen. Zuvor konnte das mit isdataat umgesetzt werden.

dsize

Das Keyword dsize vergleicht die Größe der Nutzdaten des Pakets. Zum Beispiel können Sie mit diesem Keyword nach ungewöhnlichen Nutzdatengrößen suchen. Das ist zur Erkennung von Pufferüberläufen hilfreich.

byte_test

Das Keyword byte_test extrahiert die Anzahl der Bytes, die in bytes_to_convert spezifiziert sind, und führt eine mit operator ausgewählte Operation auf value bei offset aus.

Format:

byte_test:<bytes_to_convert>, [!]<operator>, <value>, <offset> \
         [, relative][, <endian>][, string, <num>][, dce]  \
         [, bitmask <bitmask_value>];
bytes_to_convert

Die Anzahl der ausgewählten zu konvertierenden Bytes des Pakets, zwischen 1-8.

value

Wert gegen den der konvertierte Wert getestet wird, zwischen 0 - 4294967295.

offset

Anzahl der Bytes in den Nutzdaten.

operator

  • ! Negation, kann den anderen Operatoren vorangestellt werden

  • < kleiner als

  • > größer als

  • = gleich

  • <= kleiner als oder gleich

  • >= größer als oder gleich

  • & bitweises UND

  • ^ bitweises ODER

relative

Offset relativ zum letzten Inhaltsvergleich.

endian

  • big (höchstwertiges Byte an kleinster Adresse)

  • little (höchstwertiges Byte an der höchsten Adresse)

string <num>

  • dec (konvertiert String zu dezimal)

  • hex (konvertiert String zu hexadezimal)

  • oct (konvertiert String zu oktal)

dce

nicht unterstützt

bitmask

nicht unterstützt

Zum Beispiel:

alert tcp any any -> any any (msg:" Matches User-Agent 'genua'"; \
http.header; content:"User-Agent: "; \
byte_test:5, =, 113685342544138, 0, relative, big; sid:1; rev:1)

alert http any any -> any any (msg:" Matches Content-Length value"; \
http.header; content:"Content-Length: "; \
byte_test:0, >=, 1000, 0, string, dec; sid:1; rev:1)

Beachten Sie, dass endian und string nicht gleichzeitig in einer byte_test-Operation verwendet werden können.

byte_jump

Mit dem Keyword byte_jump kann bytes_to_convert von einem offset ausgewählt und der Erkennungszeiger an diese Position bewegt werden. Nachfolgende Inhaltsvergleiche basieren dann auf der neuen Position.

Format:

byte_jump:<bytes_to_convert>, <offset> [, relative][, multiplier <mult_value>] \
  [, <endian>][, string, <number_type>][, align][, from_beginning][, from_end] \
  [, post_offset <adjustment value>][, dce][, bitmask <bitmask_value>];
bytes_to_convert

Die Anzahl der ausgewählten zu konvertierenden Bytes des Pakets, zwischen 1-8.

offset

Anzahl der Bytes in den Nutzdaten.

relative

Offset relativ zum letzten Inhaltsvergleich.

multiplier

Multipliziert das konvertierte Byte mit dem Wert.

endian

  • big (höchstwertiges Byte an kleinster Adresse)

  • little (höchstwertiges Byte an der höchsten Adresse)

string <num>

  • dec (konvertiert String zu dezimal)

  • hex (konvertiert String zu hexadezimal)

  • oct (konvertiert String zu oktal)

align

Rundet die Zahl zur nächsten 32-Bit-Grenze auf.

from_beginning

Springt vom Anfang des Pakets vorwärts, anstatt von der Stelle des Erkennungszeigers.

from_end

nicht unterstützt

post_offset

Nachdem die Sprungoperation durchgeführt wurde, wird die angegebene Anzahl von Bytes zusätzlich gesprungen.

dce

nicht unterstützt

bitmask

nicht unterstützt

Zum Beispiel:

alert tcp any any -> any any (msg:"Jump on binary newline 10 bytes forward"; \
content:"/index.html HTTP/1.0\"; byte_jump:1,1,relative,big; \
content:\"genua\"; distance:0; sid:1; rev:1;)

byte_extract

Bemerkung

cognitix Threat Defender unterstützt dieses Keyword nicht.

pcre (Perl Compatible Regular Expressions)

Das Keyword pcre führt Vergleiche mit regulären Ausdrücken durch.

Der Vergleich mit regulären Ausdrücken verursacht einen hohen Verarbeitungsaufwand und wird oft mit dem Keyword content kombiniert. So wird der reguläre Ausdruck nur angewendet, wenn zuerst content trifft.

Format von pcre:

pcre:"/<regex>/<modifiers>";

Im folgenden Beispiel trifft die Signatur, wenn die Nutzdaten sechs aufeinanderfolgende Zahlen enthalten:

pcre:"/[0-9]{6}/";

Bemerkung

Die folgenden Zeichen müssen im Inhalt maskiert werden: ; \ "

Perl/PCRE-kompatible Modifikatoren

Das Vergleichsverhalten und die Syntaxinterpretation von PCREs kann durch verschiedene Flags verändert werden. Die unterstützten Flags werden hier mit einer kurzen Beschreibung und den internen PCRE-Namen in Klammern aufgeführt.

  • i (PCRE_CASELESS)

    Wird dieser Modifikator verwendet, stimmen Buchstaben im Muster sowohl mit großen und kleinen Buchstaben überein.

  • m (PCRE_MULTILINE)

    Standardmäßig behandelt PCRE den Subject String als einzelne „Zeile“ von Buchstaben (selbst wenn er tatsächlich Zeilenumbrüche enthält). Das Metazeichen „Zeilenanfang“ (^) trifft nur am Anfang des Strings, während das Metazeichen „Zeilenende“ ($) nur am Ende des Strings oder vor einem abschließenden Zeilenumbruch trifft (sofern nicht der E-Modifikator gesetzt ist). Wenn dieser Modifikator gesetzt ist:

    • ^: trifft zusätzlich nach jedem Zeilenumbruchzeichen (und am Anfang des Strings).

    • $: trifft zusätzlich vor jedem Zeilenumbruchzeichen (und am Ende des Strings).

    Wenn es keine \n-Zeichen im Subject String oder keine Vorkommen von ^ oder $ in einem Muster gibt, hat das Setzen dieses Modifikators keine Wirkung.

  • s (PCRE_DOTALL)

    Wird dieser Modifikator verwendet, stimmt ein Punkt-Metazeichen im Muster mit allen Zeichen einschließlich Zeilenumbrüchen überein. Ohne den Modifikator werden Zeilenumbrüche ausgeschlossen. Unabhängig von diesem Modifikator stimmt eine negative Klasse, wie [^a], immer mit Zeilenumbruchzeichen überein.

  • x (PCRE_EXTENDED)

    Wenn dieser Modifikator gesetzt ist, werden Whitespace-Zeichen im Muster vollständig ignoriert, es sei denn, sie sind maskiert oder befinden sich innerhalb einer Zeichenklasse. Außerdem leitet in diesem Modus # einen Zeilenkommentar ein (der sich bis zum nächsten \n-Zeichen (inklusive) erstreckt). #-Zeichen, die maskiert sind oder sich in einer Zeichenklasse befinden, werden normal behandelt. Whitespace-Zeichen dürfen nicht innerhalb von Sonderzeichensequenzen in einem Muster auftreten, z. B. in der Sequenz (?(, die ein konditionales Untermuster einführt.

  • A (PCRE_ANCHORED)

    Wenn dieser Modifikator gesetzt ist, wird das Muster zwingend „verankert“, d.h. es kann nur am Anfang des durchsuchten Strings (dem „Subject String“) übereinstimmen. Dieser Effekt kann auch mit entsprechenden Konstrukten (^) im Muster selbst erreicht werden.

  • E (PCRE_DOLLAR_ENDONLY)

    Wird dieser Modifikator verwendet, trifft ein Dollar-Metazeichen im Muster nur am Ende des Subject String. Ohne diesen Modifikator trifft ein Dollar-Zeichen auch direkt vor dem letzten Zeichen, wenn es sich um einen Zeilenumbruch handelt (aber nicht vor anderen Zeilenumbrüchen). Dieser Modifikator wird ignoriert wenn der Modifikator m gesetzt ist.

Bemerkung

Manchmal wird dieser Modifikator mit dem Buchstaben D dargestellt (z. B. PHP).

  • G (PCRE_UNGREEDY)

    Dieser Modifikator kehrt die „Greediness“ der Quantifikatoren um, so dass sie nicht standardmäßig greedy sind, sondern greedy werden, wenn ihnen ein ? folgt. Kann auch durch den Modifikator (?U) innerhalb des Musters gesetzt werden. Dies kann auch erreicht werden, indem die Greediness aller Quantifikatoren einzeln durch Anhängen eines Fragezeichens umgekehrt wird (z. B. .* -> .*?, .+ -> .+?, x? -> x??).

Bemerkung

In der Regel wird dieser Modifikator mit dem Buchstaben U dargestellt.

Angepasste Modifikatoren

Die folgenden angepassten Modifikatoren sind verfügbar:

  • R: Prüft relativ zum letzten Mustertreffer. Vergleichbar mit distance:0;.

  • B: pcre-Kompatibilitätsmodifikator. Dieser Modifikator hat keinen Effekt.

  • O: nicht unterstützt

Angepasste Zielmodifikatoren

Es gibt mehrere angepasste Modifikatoren, mit denen festgelegt werden kann, mit welchem Puffer das Muster übereinstimmen soll. Diese stammen hauptsächlich aus der Zeit, in der Modifier Keywords zur Angabe des Zielpuffers verwendet wurden, anstelle der inzwischen vorherrschenden Sticky Buffer Keywords. Sie sollten als veraltet betrachtet werden und die Sticky Buffer Keywords sind zu bevorzugen.

  • C: Trifft auf denselben Puffer zu wie http.cookie.

  • D: nicht unterstützt

  • H: Trifft auf denselben Puffer zu wie http.header.

  • I: Trifft auf denselben Puffer zu wie http.uri.raw.

  • M: Trifft auf denselben Puffer zu wie http.method.

  • P: Trifft auf denselben Puffer zu wie http.request_body.

  • Q: Trifft auf denselben Puffer zu wie http.response_body.

  • S: Trifft auf denselben Puffer zu wie http.stat_code.

  • U: Synonym von I.

  • V: Trifft auf denselben Puffer zu wie http.user_agent.

  • W: Trifft auf denselben Puffer zu wie http.host.

  • Y: Trifft auf denselben Puffer zu wie http.stat_msg.

  • Z: Trifft auf denselben Puffer zu wie http.host.raw.