--- /dev/null
+# Description
+
+Ensure that Suricata logs the expected amount of applayer protocol events,
+when there are packet and flow drops.
+
+# Expected behavior
+
+Application layer events for dropped packets or flows should be logged as part
+of the drop event, when their corresponding transaction is completed (which also
+happens when the flow is dropped). Therefore, we should not see ``sip`` events
+after ``pcap_cnt: 4``, since there's a drop in ``pcap_cnt: 5`` and the flow is
+dropped with packets 6 and 7 due to the applayer error exception policy.
+
+# Redmine ticket
+
+https://redmine.openinfosecfoundation.org/issues/5802
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ tagged-packets: yes
+ - anomaly:
+ enabled: yes
+ types:
+ decode: no
+ stream: yes
+ applayer: 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.
+ - flow
+ - sip
+
+action-order:
+ - pass
+ - drop
+ - reject
+ - alert
--- /dev/null
+alert tcp any any -> any any (flow:to_server; sid:1;)
+drop udp any any -> any any (flow:to_server; sid:2;)
--- /dev/null
+pcap: ../sip-body-frames/public-cloudshark-sip-s0.pcap
+args:
+- --set app-layer.error-policy=drop-flow
+- --simulate-ips
+- -k none
+checks:
+ - filter:
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ - filter:
+ count: 4
+ match:
+ event_type: alert
+ alert.signature_id: 2
+ - filter:
+ count: 3
+ match:
+ event_type: sip
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ tagged-packets: yes
+ - anomaly:
+ enabled: yes
+ types:
+ decode: no
+ stream: yes
+ applayer: 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.
+ - flow
+ - sip
+
+action-order:
+ - pass
+ - drop
+ - reject
+ - alert
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ tagged-packets: yes
+ - anomaly:
+ enabled: yes
+ types:
+ decode: no
+ stream: yes
+ applayer: 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.
+ - flow
+ - sip
+
+action-order:
+ - pass
+ - drop
+ - reject
+ - alert
--- /dev/null
+alert tcp any any -> any any (flow:to_server; sid:1;)
+alert udp any any -> any any (flow:to_server; sid:2;)
--- /dev/null
+pcap: ../sip-body-frames/public-cloudshark-sip-s0.pcap
+args:
+- --simulate-ips
+- -k none
+- --set app-layer.error-policy=drop-packet
+checks:
+ - filter:
+ count: 0
+ match:
+ event_type: alert
+ alert.signature_id: 1
+ - filter:
+ count: 3
+ match:
+ event_type: alert
+ alert.signature_id: 2
--- /dev/null
+Test
+====
+
+It seems that Suricata will log an applayer event for a dropped flow, for the
+second packet of the flow. This test demonstrates such behavior, so we can
+investigate it.
+
+This test demonstrates this behavior with the SMB version 3 protocol.
+
+
+PCAP
+====
+
+PCAP found on Wireshark Wiki.
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ - flow
+ - dcerpc
+ - smb
+ - drop:
+ alerts: yes
+ flows: all
--- /dev/null
+drop dcerpc any any -> any any (msg:"dcerpc rule"; sid:1;)
--- /dev/null
+args:
+- --simulate-ips
+- --set stream.midstream=true
+- -k none
+
+checks:
+ - filter:
+ count: 0
+ match:
+ pcap_cnt: 2
+ event_type: smb
+ - filter:
+ count: 19
+ match:
+ event_type: drop
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: drop
+
--- /dev/null
+Test
+====
+
+It seems that Suricata will log an applayer event for a dropped flow, for the
+second packet of the flow. This test demonstrates such behavior, so we can
+investigate it.
+
+This test demonstrates this behavior with the HTTP protocol.
+
+
+PCAP
+====
+
+PCAP is the result of extracting the http packets from a pcap representing a
+curl to the www.testmyids.com site.
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ - flow
+ - http
+ - drop:
+ alerts: yes
+ flows: all
--- /dev/null
+drop http any any -> any any (msg:"http rule"; sid:1;)
--- /dev/null
+args:
+- --simulate-ips
+- --set stream.midstream=true
+- -k none
+
+checks:
+ - filter:
+ count: 1
+ match:
+ event_type: http
+ pcap_cnt: 2
+ - filter:
+ count: 1
+ match:
+ event_type: drop
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: drop
+
--- /dev/null
+Test
+====
+
+It seems that Suricata will log an applayer event for a dropped flow, for the
+second packet of the flow. This test demonstrates such behavior, so we can
+investigate it.
+
+This test demonstrates this behavior with the SMB version 3 protocol.
+
+
+PCAP
+====
+
+PCAP found on Wireshark Wiki.
--- /dev/null
+%YAML 1.1
+---
+
+outputs:
+ - eve-log:
+ enabled: yes
+ types:
+ - alert:
+ - flow
+ - smb
+ - drop:
+ alerts: yes
+ flows: all
--- /dev/null
+drop smb any any -> any any (msg:"smb rule"; sid:2;)
--- /dev/null
+args:
+- --simulate-ips
+- --set stream.reassembly.depth=0
+- --set stream.midstream-policy=drop-flow
+- -k none
+
+checks:
+ - filter:
+ count: 1
+ match:
+ event_type: smb
+ pcap_cnt: 2
+ - filter:
+ count: 53
+ match:
+ event_type: drop
+ - filter:
+ count: 1
+ match:
+ event_type: flow
+ flow.action: drop
+
requires:
- min-version: 7
+ min-version: 7
args:
- --set threshold-file=${TEST_DIR}/threshold.config
match:
event_type: drop
drop.reason: threshold detection_filter
+# due to the drops, we don't expect to see any http event
+ - filter:
+ count: 0
+ match:
+ event_type: http