Suricata Alerts/Logs View broken due to Advanced Configuration Pass-Through
-
the pass-through arguments, which work as intended, are as follows:
default-log-dir: /mnt/log/suricata/suricata_ix132671 logging: outputs: - file: filename: /mnt/log/suricata/suricata_ix132671/suricata.log
but now the package doesn't see the logged data (presumably still looking at the default install, "/var/log/suricata/..." path).
from the Logs View tab, each log says "Log file does not exist or that logging feature is not enabled." but the logs are successfully being written to the new location.
can the Suricata package install be modified in a persistent way to look for the logfiles in a custom location?
-
@cyberconsultants I wonder if this is related to my other forum post i put up today.
I got no logging for a rule. I know its working but nothing is in the alerts tab. -
@michmoor said in Suricata Alerts/Logs View broken due to Advanced Configuration Pass-Through:
I wonder if this is related to my other forum post i put up today.
no, it isn't.
-
@cyberconsultants said in Suricata Alerts/Logs View broken due to Advanced Configuration Pass-Through:
can the Suricata package install be modified in a persistent way to look for the logfiles in a custom location?
No, currently the package expects the logs to reside in
/var/log/suricata/
. I suppose you could manually create your own symlink at the FreeBSD shell prompt to redirect the default logging directory to some other physical path if desired. -
@bmeeks hey Bill, that's exactly the direction we planned to investigate after first getting your input. thanks for the reply.
again and FWIW—the passed-through logging config works as expected. for posterity, we ended up copy/pasting the entire "logging:" config section into the Advanced Configuration Pass-Through setting. but now to be able to use the pf GUI to perform the occassional cursory 'Alerts' check would be a total and persistent solution to excess OS disk writes and storage size due to logging.
will follow-up and/or maybe submit a Redmine if this evolves into a coherent feature request.
-
@michmoor said in Suricata Alerts/Logs View broken due to Advanced Configuration Pass-Through:
@cyberconsultants I wonder if this is related to my other forum post i put up today.
I got no logging for a rule. I know its working but nothing is in the alerts tab.There was a bug report upstream in Suricata some time back about certain circumstances where the logic would drop a packet but not log the reason (alert). I was thinking that was addressed, but maybe it was not fully fixed ???
It's also possible that a rule may have a
noalert
tag in it. That suppresses alerts. Not sure how that impacts a DROP action, but I would expect such a rule to also not drop the traffic. I have never tested that, though.The
noalert
tag is part of the flowbits logic for rules, and allows a given rule to trigger a flowbit state without generating a corresponding alert for that trigger. If you are using SID MGMT to change all the rules in a given category to DROP, then perhaps you are also changing some flowbitsnoalert
rules to DROP when typically they are set for ALERT. Just a guess as I have not investigated this, but perhaps that results in an unanticipated situation in the Suricata binary. -