Snort / Suricata multi-interface - watchdog / database
-
All,
Service watchdog -
When multiple instances of an IDS are at play, what is the expected behavior of this service? Have experienced some crashes of the IDS (snort in this case) and in each case, the service was not restarted and no notification was received. Hoping that someone may know the expected behavior(s), to at least understand what one should/shouldn't expect. Noting that the service watchdog only shows "<IDS NAME>" (singular option) and doesn't reveal something like "<IDS> - <interface description>" to infer cognizance of multiple interfaces, if multiple instances are present - does this mean only the first is monitored? none are monitored? other?Database -
Given an environment where PostgreSQL is the standard (MySQL not being an option), any possibility for inclusion of the PostgreSQL output plugin for Barnyard2?Thanks!
-
@justme2 said in Snort / Suricata multi-interface - watchdog / database:
All,
Service watchdog -
When multiple instances of an IDS are at play, what is the expected behavior of this service? Have experienced some crashes of the IDS (snort in this case) and in each case, the service was not restarted and no notification was received. Hoping that someone may know the expected behavior(s), to at least understand what one should/shouldn't expect. Noting that the service watchdog only shows "<IDS NAME>" (singular option) and doesn't reveal something like "<IDS> - <interface description>" to infer cognizance of multiple interfaces, if multiple instances are present - does this mean only the first is monitored? none are monitored? other?Database -
Given an environment where PostgreSQL is the standard (MySQL not being an option), any possibility for inclusion of the PostgreSQL output plugin for Barnyard2?Thanks!
A quick search of this forum with the terms "Snort" and "Service Watchdog" or "Suricata" and "Service Watchdog" should uncover several posts from me explaining that Service Watchdog should never ever be used with either of the IDS/IPS packages. Most especially when running multiple interfaces. Service Watchdog is not designed for the IDS/IPS packages and thus has no knowledge of how to properly monitor if the service or services are running nor does it know how to properly restart them. It also is totally oblivious to nightly rules updates and their resulting automatic service restarts. Service Watchdog will foolishly attempt to restart the IDS/IPS service while the service is already attempting to restart on its own. That results in either a crash of the service, or worse, multiple duplicate instances running on the same interface.
Short version of above -- DO NOT use Service Watchdog with either Snort or Suricata.
-
RE: service watchdog - understood.
Any thoughts on support for PostgreSQL in Barnyard2?
Thanks!
-
barnyard2 is deprecated/obsolete/no one is working at it. it's there only because it's still a dependency for snort/suricata. based on what @bmeeks said, there is plan to remove it completely
there is Zero chance that PostgreSQL will ever be implemented. -
@justme2 said in Snort / Suricata multi-interface - watchdog / database:
RE: service watchdog - understood.
Any thoughts on support for PostgreSQL in Barnyard2?
Thanks!
As @kiokoman stated, Barnyard2 maintenance, on FreeBSD at least, appears to have died. There have been no material updates to the source code in several years. A pfSense user did submit a fix for a MySQL syntax error for the pfSense package, but to my knowledge that fix has not been propagated upstream to FreeBSD. There were plans some time back from upstream for Suricata to discontinue support for the Unified2 log output required by Barnyard2 (at least required for efficient operation). If those upstream plans become reality, then Barnyard2 will be removed from Suricata. Suricata prefers the EVE JSON format for log outputs, and thus third-party tools that support EVE JSON inputs are better suited for Suricata users on pfSense.
Snort may continue Barnyard2 support for a while, but I expect even them to slowly transition to something based on JSON output. That is the new preferred logging format for Snort3.
-
One of the primary concerns is being able to get the data ("out" of the firewall) into a data engine for event correlation. One of many examples would be Splunk. Currently, Barnyard2 provides syslog capability that enables simplified separation of the event streams (ability to prescribe specific facility and destination for output separate from the firewall's syslog and without having to clog the firewall's logs with IDS/IPS logging data). Sounds like the upcoming changes could become a step backwards if it makes it more difficult to get the data out of the firewall, despite improvements in logging format, no?
In reviewing the Suricata documentation a bit more, it appears to offer the ability to tailor output (directly?) to syslog - including the ability to modify the output format as to match a required SEIM input format.
FWIW - have been involved in the administration of a couple firewalls over many years that are on FreeBSD (currently 12.0-p10), using PF with Snort, Barnyard2, etc. and those utilize the PostgreSQL output plugin - which has been available from the FreeBSD ports for many years. Somewhat surprised that the output plugin wasn't included for Barnyard2 in PFSense, while MySQL was included.
Including a small perl script that may be helpful to sort suppress lists, as these can often be a quagmire to wade through when looking to manage via the file itself as they can become quite huge and being able to see suppressed items in a logical order makes it a bit easier.
sort-suppress.pl.gz