]> git.ipfire.org Git - thirdparty/suricata.git/commitdiff
userguide/eve: format and reorganize alert section 9318/head 9323/head
authorJuliana Fajardini <jufajardini@oisf.net>
Thu, 22 Dec 2022 23:47:24 +0000 (20:47 -0300)
committerJuliana Fajardini <jufajardini@oisf.net>
Tue, 1 Aug 2023 17:01:30 +0000 (14:01 -0300)
The `field action` portion seemed to be comprised of a more generic
section that followed it. Also formatted the section for lines to be
within the character limit.

(cherry picked from commit 9900bdc162cc876151e680ea088f89b54edb038f)

doc/userguide/output/eve/eve-json-format.rst

index 2a2e557480cced366f8ae971c5f31797418be3be..d713bb338e95607979372eb7b339bd72d73846ab 100644 (file)
@@ -73,23 +73,17 @@ generated the event.
 Event type: Alert
 -----------------
 
-Field action
-~~~~~~~~~~~~
-
-Possible values: "allowed" and "blocked"
-
-Example:
-
-::
-
-
-  "action":"allowed"
+This field contains data about a signature that matched, such as
+``signature_id`` (``sid`` in the rule) and the ``signature`` (``msg`` in the
+rule).
 
-Action is set to "allowed" unless a rule used the "drop" action and Suricata is in IPS mode, or when the rule used the "reject" action.
-
-It can also contain information about Source and Target of the attack in the alert.source and alert.target field it target keyword is used in
+It can also contain information about Source and Target of the attack in the
+``alert.source`` and ``alert.target`` field if target keyword is used in
 the signature.
 
+This event will also have the ``pcap_cnt`` field, when running in pcap mode, to
+indicate which packet triggered the signature.
+
 ::
 
    "alert": {
@@ -109,6 +103,56 @@ the signature.
        "port": 80
      },
 
+Action field
+~~~~~~~~~~~~
+
+Possible values: "allowed" and "blocked".
+
+Example:
+
+::
+
+  "action":"allowed"
+
+Action is set to "allowed" unless a rule used the "drop" action and Suricata is
+in IPS mode, or when the rule used the "reject" action. It is important to note
+that this does not necessarily indicate the final verdict for a given packet or
+flow, since one packet may match on several rules.
+
+.. _verdict-alert:
+
+Verdict
+~~~~~~~
+
+An object containning info on the final action that will be applied to a given
+packet, based on all the signatures triggered by it and other possible events
+(e.g., a flow drop). For that reason, it is possible for an alert with
+an action ``allowed`` to have a verdict ``drop``, in IPS mode, for instance, if
+that packet was dropped due to a different alert.
+
+* Action: ``alert``, ``pass``, ``drop`` (this latter only occurs in IPS mode)
+* Reject-target: ``to_server``, ``to_client``, ``both`` (only occurs for 'reject' rules)
+* Reject: an array of strings with possible reject types: ``tcp-reset``,
+  ``icmp-prohib`` (only occurs for 'reject' rules)
+
+Example:
+
+::
+
+    "verdict": {
+       "action": "drop",
+       "reject-target": "to_client",
+       "reject": "[icmp-prohib]"
+     }
+
+
+Pcap Field
+~~~~~~~~~~
+
+If pcap log capture is active in `multi` mode, a `capture_file` key will be added to the event
+with value being the full path of the pcap file where the corresponding packets
+have been extracted.
+
 Event type: Anomaly
 -------------------