Hello,
I’m using Suricata 6.0.5
my http.log failed to log all http requests
But it’s look like alerts log doing well when I triggered alerts.
Hello,
I’m using Suricata 6.0.5
my http.log failed to log all http requests
But it’s look like alerts log doing well when I triggered alerts.
Thanks for including the Suricata version you’re using.
Other things that will help tracking down the problem are
suricata.yaml
)stats.log
)Hi Jeff,
I have sent the files to you in person.
Important- i have checked the YAML in my lab env and it works perfect, so maybe it’s a performance issue that could be handle with different config or so
Thanks.
Hi,
I will appreciate any reply
Thanks
Thanks to Jeff who resolve my problem!
The fix is to add this to suricata.yaml:
stream:
midstream: true
The default value is false; when set to true, Suricata will track sessions even if the session initiation isn’t seen by Suricata.
Also I increased the memcap size and depth
Is there packet loss during the rush hours?
Packet loss is caused by back pressure on resources used to handle packets:
Without a full picture of the software and hardware components, increasing the memory limits for Suricata may be one of the recommended actions for reducing packet drops.
I believe packet loss is not the problem, because-
Can you tell the difference between snort sigs and HTTP logs? why do the sigs work fine and the HTTP logs doesn’t?
Alerts (generated when traffic matches one or more rules) and logs are closely related but different. When a log entry is written, information that has been collected will be added to the entry.
HTTP logs are influenced by configuration settings. There are 2 types of HTTP logging
You’re using a customized Suricata configuration file with Suricata 6.0.5
I’d suggest using the latest stable Suricata release – 6.0.10 and using the configuration file from that release and then assess things, including the amount of HTTP logs.
Suricata has several memory related configuration settings; some of these are dependent on the amount of compute and memory resources available and the expected traffic load. Generally, values are chosen to avoid drops, resource exhaustions and provide normal operation for the deployment model (ids vs ips).