Hello Robin,
On 2 Oct 2025, at 22:04, Robin Roevens <[email protected]> wrote:
Hi Michael
I saw there is a suricata-reporter in the upcoming CU. And I was
wondering if I could add an additional reporter into it for sending
alerts straight to Zabbix, next to syslog and email.
I think that is a great idea!
I have already been experimenting with parsing fast.log using the
zabbix_agentd, which seems to work quite well. But since there is now a
reporter, it would be nice to have it support sending alerts to zabbix
directly instead of zabbix separately monitoring the fast.log file.
Parsing log files like that is never fun. I also think that I remember that
suricata has deprecated support for writing fast.log, but then it does not seem
to be deprecated any more. Looking at the alternative EVE format, fast.log is
just there to have something that is somewhat human-readable, but at the same
time does not carry a lot of information.
If that would be ok for you. There are 2 possible ways to do this:
- using the zabbix_utils python library:
https://blog.zabbix.com/python-zabbix-utils/27056/
- or using the zabbix_sender command utility that currently gets
installed when installing zabbix_agentd
The IPS could generate a lot of alerts. Especially when there is bursts in
(malicious) traffic and I am already unhappy with calling sendmail - but there
I have no other choice.
The daemon initially had some worker daemons so that reading from Suricata
would be entirely decoupled from processing any messages. However, Python’s
multiprocessing capabilities are really bad and so now it is a threaded
implementation. Python isn’t good at that either, but when we are calling a
subprocess the GIL is being released and so we should not actually spend too
much time in the Python code itself.
This has to be considered when adding yet another output so that the process
does not get stalled when Zabbix does not respond, is overwhelmed or anything
else. We could simply combat that by adding a couple more worker threads if
necessary - but I am getting ahead of myself.
So the Python module would be by far preferable. It seems to have a nice API,
but we will have to check how it works underneath to reach the objectives
outlined above.
I assume, using the python library will probably be the most performant
option; But then I should also create a zabbix_utils python library
pak-file?
Hmm, this is where it is getting interesting.
The suricata-reporter stuff is supposed to be rather distro agnostic. Besides
Python itself, it only has a dependency to sqlite3 (which normally comes with
the Python standard library) and reportlab to generate the PDFs. The goal is to
run it on IPFire 2 for now, but it would also be pretty much ready as is to run
in IPFire 3 some day. Of course it runs on any other distro - although I don’t
know what it would do on a non-Linux OS.
I would like to keep it lightweight and hopefully some more people would adopt
it.
I believe adding zabbix should be done as an optional dependency. We could
simply try to import the Zabbix modules. If they are there, the process has
support for Zabbix. If not, then not. That could simply be handled at runtime.
That way, we could have zabbix as an add-on in IPFire instead of adding it to
the core distribution and if other people want to run the whole thing, they can
enjoy a minimum amount of dependencies and don’t have to build/install any
zabbix packages if they don’t need them.
Both the python module and the commandline cli have the possibility to
get zabbix server connection info from the zabbix_agentd configfile so
config of the reporter would be something like:
[zabbix]
enabled = true
zabbix_agentd_config = /etc/zabbix_agentd/zabbix_agentd.conf
alert_item_key = ipfire.suricata.event.get
I mean, this is all up to you. I would definitely do this bit:
[zabbix]
enabled = true
That way it is consistent with the remainder. Any other options, well I don’t
know what you would need :) I do enjoy a daemon that does not need a lot of
configuration though and therefore can be run with only a very small
configuration as it relies on sensible defaults.
Then the reporter can format the incoming suricata alert/event as json
and send it to the configured alert_item_key on the zabbix server as
configured in the zabbix_agentd.conf
We do store the entire JSON object as it comes from Suricata in the sqlite3
database. That way we have all the information that could possible be available
to us even though we don’t need everything right now. The fast.log format
definitely lacks a lot of important information, but it is nicely readable.
Depending on what processing Zabbix can do later and what information it
permanently-ish stores, I would send the whole lot. The JSON objects are small
enough and over the wire they would compress nicely, too. On the daemon side I
wouldn’t implement this to be configurable because that only makes everything
more complicated.
Is this something you are open to? Then I can try to create a patch for
suricata-reporter. (where should I then submit it? Also on this list?)
Yes, very much so.
Patches can go on this list.
Let’s talk about any implementation details in advance. I feel a little bit
precious about this program because it is nice, shiny and new and the code is
very simple. I would like to keep it that way.
If not I will have to continue working on the fast.log parsing.
Don’t. That will only make you unhappy.
And while on the topic of monitoring suricata; I would like to get some
extra stats from it, which, for as far as I currently know, can be
retrieved using the suricata unix-socket that is currently disabled by
default on ipfire. Many seem to use a 'suricatasc' tool to query
suricata using that socket, but that tool is not available on ipfire.
What stats do you want/need?
I am happy to turn on the socket and built the tool. Does it come with the
suricata package?
Please submit patches :) I think this could be done first before diving into
Zabbix because it should be a very simple change.
Is it possible to have it on ipfire?, or should I start experimenting
using socat?
No, if there are tools built already, use the code that is available.
And if succesful, is it then allowed for a future zabbix_agentd addon
pak to enable that socket in the suricata config?
Enable the socket by default. It won’t hurt anyone.
If you dislike the idea of enabling and querying the socket, another
possibility is having suricata dump stats in a seperate stats.log which
I should then be able to parse using Zabbix.
Hmm, but then we are back to parsing logs. That is never fun.
Before I start any implementations, what are your thoughts about all
this ?
Very very happy with this here.
Let me know how I can help.
-Michael
Regards
Robin
--
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.
