Large number of events with /libhtp::request_uri_not_seen

Help
1

Environment:

Debian 11
Suricata 6.0.14 running with af-packet mode
Traffic: 500-600 Mbps on 2 interfaces (mostly HTTP traffic on port 80)

How I installed Suricata: build from source using commands:
+) bash scripts/bundle.sh
+) bash autogen.sh
+) configure
+) make
Then run Suricata using command:
+) ./src/suricata -c /opt/napt/conf/suricata/suricata.yaml --af-packet=ens1f0np0 --af-packet=ens1f1np1

Issue: After running Suricata for some time, I am seeing a large number of events with /libhtp::request_uri_not_seen.

I have already adjusted the following configuration settings:

http.memcap
stream.memcap
stream.reassembly.memcap
stream.reassembly.depth
http.libhtp.default-config.request-body-limit
response-body-limit
However, the error persists.

When I increase stream.reassembly.depth from 100MB to 1GB and replay the PCAP file (using the -r option of Suricata), the issue does NOT occur. However, when capturing live traffic, I still get the error.

Here is the current configuration I am using:

suricata (1) (2).yaml (70.2 KB)

2

Suricata 6 is EOL, please upgrade first to at least Suricata 7 (7.0.12) or directly to the latest stable Suricata 8 (8.0.1)

3

Currently, due to some reasons, I’m unable to upgrade Suricata. Is there any way to fix this issue(?) on version 6?

4

You could try the latest 6.0.19 as well, but there have been many fixes in 7 and also in 8 so there is a high chance this issue might not appear anymore in supported versions.

5

@dachoa1005 We faced this recently with Suricata 7.0.6 version. In our case, it turned out to be due to TCP stream reaching reassembly depth. As stream is not being created, application layer parsing also stops at that point.

TCP packets are still subjected to Detect() work-flow. Whenever there is a signature match with a single TCP packet, alerts are generated. But, as there is no application layer parsing, http data is not available in such alerts

This seems to be, as per design. When we increased reassembly depth (beyond the TCP packet that matched with the signature), we could see http data in alerts.