--- /dev/null
+# Test
+
+Check and showcase alert verdicts when there are ``reject``, ``pass`` and
+``drop`` rules.
+
+# Behavior
+
+We expect to see ``drop`` and ``alert`` events with info about the ``reject``
+that will happen due to rule 2 for pcap_cnt 1 this is due to ``drop`` and ``reject``
+rules being triggered. For the other packets, we should see drops due to the
+flow being dropped as a result of rule 1.
+
+# Pcap
+
+Pcap comes from the test detect-app-layer-protocol-02 and is the result of a
+curl to www.testmyids.com.
--- /dev/null
+%YAML 1.1
+---
+
+action-order:
+ - drop
+ - reject
+ - alert
+ - pass
+
+outputs:
+ - eve-log:
+ enabled: yes
+ filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
+ filename: eve.json
+ types:
+ - alert:
+ verdict: yes
+ - drop:
+ flows: all
+ alerts: true
+ verdict: yes
+ - http
+ - anomaly
+
--- /dev/null
+drop tcp any any -> any 80 (sid:1; rev:1;)
+rejectdst tcp any any -> any 80 (sid:2; rev:1;)
+pass tcp any any -> any 80 (sid:3; rev:1;)
--- /dev/null
+requires:
+ features:
+ - LIBNET1.1
+
+args:
+- --simulate-ips
+
+pcap: ../detect-app-layer-protocol-02/input.pcap
+
+checks:
+ # checks for Suricata 6
+ - filter:
+ lt-version: 7
+ count: 1
+ match:
+ pcap_cnt: 1
+ event_type: drop
+ alert.action: blocked
+ alert.signature_id: 1
+ - filter:
+ lt-version: 7
+ count: 1
+ match:
+ pcap_cnt: 1
+ event_type: alert
+ alert.action: blocked
+ alert.signature_id: 1
+ - filter:
+ lt-version: 7
+ count: 1
+ match:
+ pcap_cnt: 1
+ event_type: alert
+ alert.action: blocked
+ alert.signature_id: 2
+
+ # checks for Suricata 7
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ pcap_cnt: 1
+ verdict.action: drop
+ verdict.reject-target: to_server
+ verdict.reject: ["tcp-reset"]
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 2
+ pcap_cnt: 1
+ verdict.action: drop
+ verdict.reject-target: to_server
+ verdict.reject: ["tcp-reset"]
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 1
+ verdict.action: drop
+ verdict.reject-target: to_server
+ verdict.reject: ["tcp-reset"]
+ - filter:
+ min-version: 7
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 3
+ verdict.action: alert
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 5
+ verdict.action: drop
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 6
+ verdict.action: drop
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 7
+ verdict.action: drop
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 8
+ verdict.action: drop
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 9
+ verdict.action: drop
+ - filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 10
+ verdict.action: drop
+
+ # Checks valid for both
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 5
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 6
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 7
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 8
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 9
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 10
--- /dev/null
+# Test
+
+Check and showcase alert verdicts when there are ``alert``, ``pass`` and
+``drop`` rules.
+
+# Behavior
+
+It's expected that Suricata will log out alerts for rules 1 and 3. Rule 2 would
+match if the flow weren't already 'passed' when it's triggered and also based on
+action order, and rule 4 isn't logged out with packet 4 as it's a 'pass' alert.
+
+Moreover, when the http transaction is finished, with packet 6 (pcap_cnt: 6),
+we should see an alert for rule 1, as it has a higher priority so is queue as an
+alert first, but still see the 'pass' verdict for same packet - which also leads
+to no alerts or drops for rule 2, that should trigger for packet 6.
+
+# Pcap
+
+Pcap comes from the test detect-app-layer-protocol-02 and is the result of a
+curl to www.testmyids.com.
+
--- /dev/null
+%YAML 1.1
+---
+
+action-order:
+ - alert
+ - pass
+ - drop
+ - reject
+
+outputs:
+ - eve-log:
+ enabled: yes
+ filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
+ filename: eve.json
+ types:
+ - alert:
+ verdict: yes
+ - drop:
+ flows: all
+ alerts: true
+ verdict: yes
+ - http
+ - flow
+
--- /dev/null
+alert http any any -> any any (sid:1;)
+# won't generate alert output nor a drop, as flow is passed
+drop http any any -> any any (content:"OK"; sid:2;)
+alert tcp any any -> any any (sid:3;)
+# won't generate alert output, as it's a pass rule
+pass http any any -> any any (content:"GET"; sid:4;)
--- /dev/null
+requires:
+ min-version: 7
+
+args:
+- --simulate-ips
+
+pcap: ../detect-app-layer-protocol-02/input.pcap
+
+checks:
+ - filter:
+ count: 2
+ match:
+ event_type: alert
+ alert.signature_id: 3
+ verdict.action: alert
+ - filter:
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ verdict.action: pass
+ - filter:
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 2
+ verdict.action: alert
+ - filter:
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 4
+ verdict.action: alert
+ - filter:
+ count: 0
+ match:
+ event_type: drop
+ alert.signature_id: 2
+ verdict.action: drop
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: pass
--- /dev/null
+# Test and Showcase the Verdict Field in IPS mode
+
+Showcase how a given packet may trigger ``alert`` rules and have a ``verdict``
+``drop`` or ``reject`` due to other rules or events.
+
+# Behavior
+
+For pcap_cnt 13, we'll see three events related to the same packet, one alert from
+an ``alert`` rule (sid: 1), another for a ``drop`` rule (sid: 3) and finally the
+``drop`` event. The verdict, in all three cases, will be ``drop``, due to rule
+sid 3.
+
+We should also see ``alert`` and ``drop`` associated with sid 2, which is a
+reject rule for the ICMP protocol.
+
+
+# Pcap
+
+Comes from the test `decode-teredo-01` as it has a good variety of protocols.
--- /dev/null
+alert http any any -> any any (sid: 1;)
+reject icmp any any -> any any (sid:2; rev:1;)
+drop http any any -> any any (sid:3;)
+
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ filetype: regular
+ filename: eve.json
+ types:
+ - alert:
+ verdict: yes
+ - drop:
+ flows: all
+ alerts: true
+ verdict: yes
+ - http
+ - anomaly
--- /dev/null
+requires:
+ min-version: 7
+ features:
+ - LIBNET1.1
+
+pcap: ../decode-teredo-01/input.pcap
+
+args:
+- --simulate-ips
+
+checks:
+ - filter:
+ count: 1
+ match:
+ event_type: alert
+ pcap_cnt: 13
+ alert.signature_id: 3
+ alert.action: blocked
+ verdict.action: drop
+ - filter:
+ count: 1
+ match:
+ event_type: alert
+ pcap_cnt: 13
+ alert.signature_id: 1
+ alert.action: allowed
+ verdict.action: drop
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ pcap_cnt: 13
+ drop.reason: rules
+ verdict.action: drop
+ - filter:
+ count: 1
+ match:
+ event_type: alert
+ verdict.action: drop
+ verdict.reject-target: to_client
+ verdict.reject: [icmp-prohib]
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ drop.reason: rules
+ verdict.action: drop
+ verdict.reject-target: to_client
+ verdict.reject: [icmp-prohib]
--- /dev/null
+Test
+====
+
+Check and capture the verdict behavior when Suricata is run in IDS mode.
+
+Behavior
+========
+
+We expect to see an alert for rule 3 as it should trigger for any TCP packet,
+but have the verdict action set to pass, ad there's another tcp rule for port
+443 that is a pass rule (sid 2). As the flow is passed, we don't expect to see
+an alert for rule 1.
+
+PCAP
+====
+
+Pcap comes from test tls-ja3s.
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ tagged-packets: yes
+ verdict: yes
+ - tls:
+ extended: yes # enable this for extended logging information
+ - drop:
+ alerts: yes # log alerts that caused drops
+ flows: all # start or all: 'start' logs only a single drop
+ # per flow direction. All logs each dropped pkt.
+ verdict: yes
+ - flow
+
+action-order:
+ - alert
+ - pass
+ - drop
+ - reject
--- /dev/null
+alert tls any any -> any any (msg:"matching TLS allowlisted"; flow:to_server,established; priority:2; sid:1;)
+pass tcp any any -> any 443 (priority:1; sid:2;)
+alert tcp any any -> any any (sid: 3;)
--- /dev/null
+requires:
+ min-version: 7
+
+pcap: ../tls/tls-ja3s/input.pcap
+
+args:
+- -k none
+
+checks:
+ - filter:
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 3
+ verdict.action: pass
+ - filter:
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ - filter:
+ count: 0
+ match:
+ event_type: drop
+ - filter:
+ count: 1
+ match:
+ event_type: tls
+ tls.sni: example.com
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: pass
--- /dev/null
+Test
+=====
+
+Test and showcase the verdict output for ``alert`` and ``pass`` rules in IDS mode.
+
+Behavior
+========
+
+This is a simple test to check that alerts that trigger for a packet that also
+triggers a pass rule will show the proper ``verdict.action: pass``, when they
+also trigger a ``pass`` rule.
+
+PCAP
+====
+
+Pcap comes from test alert-max/alert-max-append-higher-priority and was created
+with a scapy script.
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - stats:
+ enabled: yes
+ filename: stats.log
+ append: yes # append to file (yes) or overwrite it (no)
+ totals: yes # stats for all threads merged together
+ threads: no # per thread stats
+ - eve-log:
+ enabled: yes
+ filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
+ filename: eve.json
+ types:
+ - alert:
+ verdict: yes
+ - http
+ - flow
+
+action-order:
+ - alert
+ - pass
+ - drop
+ - reject
--- /dev/null
+alert tcp any any -> any any (msg:"Match rule 1"; dsize:<140; sid:1; rev:1;)
+alert http any any -> any any (msg:"Match rule 2"; uricontent:"/index.html"; sid:2; rev:1;)
+alert http any any -> any any (msg:"Match rule 3"; http.request_line; bsize:10<>100; sid:3; rev:1;)
+pass http any any -> any any (msg:"Match rule 4"; http.request_line; content:"GET /index.html HTTP/1.0"; sid:4;)
--- /dev/null
+requires:
+ min-version: 7
+
+args:
+- -k none
+- --runmode=single
+- --set stream.midstream=true
+
+pcap: ../alert-max/alert-max-append-higher-priority
+
+checks:
+# Subtest 1
+- filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ verdict.action: alert
+# Subtest 2
+- filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 2
+ verdict.action: pass
+# Subtest 3
+- filter:
+ min-version: 7
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 3
+ verdict.action: pass
+# Subtest 4
+- filter:
+ min-version: 7
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 4
+ verdict.action: pass
+# Subtest 5
+- filter:
+ count: 1
+ match:
+ event_type: http
+# Subtest 6
+- filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: pass
--- /dev/null
+#!/usr/bin/env python
+from scapy.all import *
+
+pkts = []
+
+pkts += Ether(dst='ff:ff:ff:ff:ff:ff', src='00:01:02:03:04:05')/ \
+ Dot1Q(vlan=6)/ \
+ IP(dst='1.2.3.4', src='5.6.7.8')/TCP(sport=6666, dport=63, flags='P''A')/"GET /index.html HTTP/1.0\r\nHost: www.openinfosecfoundation.org\r\nUser-Agent: This is a dummy message body\r\nContent-Type: text/html\r\n"
+
+wrpcap('input.pcap', pkts)
--- /dev/null
+# Test and Showcase the Verdict Field in IDS mode
+
+Showcase verdict field output with reject in IDS mode, for ICMP.
+
+# Behavior
+
+We should see an alert with ``verdict.action: alert`` and ``verdict.reject:
+[icmp-prohib]``.
+
+# Pcap
+
+Comes from the test `decode-teredo-01` as it has a good variety of protocols.
--- /dev/null
+alert http any any -> any any (sid: 1;)
+rejectboth icmp any any -> any any (sid:2; rev:1;)
+pass http any any -> any any (http.host; content: "www.wireshark.org"; sid:3;)
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ filetype: regular
+ filename: eve.json
+ types:
+ - alert:
+ verdict: yes
+ - drop:
+ flows: all
+ alerts: true
+ verdict: yes
+ - http
+ - flow
--- /dev/null
+requires:
+ min-version: 7
+ features:
+ - LIBNET1.1
+
+pcap: ../decode-teredo-01/input.pcap
+
+args:
+- --set stream.midstream=true
+
+checks:
+ - filter:
+ count: 28
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ verdict.action: alert
+ - filter:
+ count: 1
+ match:
+ event_type: alert
+ alert.signature_id: 2
+ verdict.action: alert
+ verdict.reject-target: both
+ verdict.reject: [icmp-prohib]
+ # match on rule `pass` for hostname www.wireshark.org
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: pass
+ flow.alerted: true
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ proto: IPv6-ICMP
+ flow.action: drop
--- /dev/null
+# Test
+
+Showcase and test verdict output with reject for UDP protocol.
+
+# Behavior
+
+We expect to see 2 alerts with the verdict field, informing
+`verdict.reject: [icmp-prohib]`.
+
+# PCAP
+
+Reused pcap from test bug-5633-gre-01.
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ filetype: regular
+ filename: eve.json
+ types:
+ - alert:
+ verdict: yes
+ - drop:
+ flows: all
+ alerts: true
+ verdict: yes
+ - http
+ - flow
--- /dev/null
+reject udp any any -> any any (content:"EVIL"; sid:1;)
--- /dev/null
+requires:
+ min-version: 7
+ features:
+ - LIBNET1.1
+
+pcap: ../bug-5633-gre-01/gre-udp.pcap
+
+args:
+- -k none
+
+checks:
+ - filter:
+ count: 2
+ match:
+ event_type: alert
+ verdict.action: alert
+ verdict.reject-target: to_client
+ verdict.reject: [icmp-prohib]
projects / thirdparty / suricata-verify.git / commitdiff
