[PATCH 0/5] Add Zabbix functionality to suricata-reporter

[Robin Roevens <robin.roevens@disroot.org>]

Hi all,

As discussed here earlier, I've worked on implementing sending
Suricata alerts straight to Zabbix from within suricata-reporter instead
of trying to parse the suricata logging separately using the Zabbix agent.

For this I use the zabbix-utils python library, which I submited here
also as a separate pak (but meanwhile already requires an update, which
I will post soon). This set of patches makes suricata-reporter able to
directly communicate to a Zabbix server without having the zabbix_agentd
pak installed, sending suricata alerts in real-time.

As Zabbix supports sending items in bulk, I have opted to create an
async background task that will send all events from last 1 second in
bulk so that even in the case that there are hundreds of incoming
alerts, Zabbix server is only contacted once per second.

When for some reason sending to Zabbix server fails, it will be retried
3 times and then the background task will be suspended until a new
suricata event comes in. That will wake the task again and retry to send all
pending events. In environments with many events, that may actually not
have that much of an effect. But in the average environment, this will
give the Zabbix Server some breathing space as it failing to receive our
events, may indicate a Zabbix server overload. 

For this I have to keep track which events are sent and which are
pending. So I added a column in the database that keeps track of that.

I have also added an alert_max_age config parameter that allows the user
to set how long suricata-reporter should retry to send events to Zabbix.
Events older than that set age, will no longer be sent to Zabbix.
This also give the user the implicit option to send older events when
only just enabling the zabbix sending functionality, since the DB column
exists and no event was ever sent to Zabbix, all events will be
'pending". At first run with zabbix functionality enabled, all events up
to alert_max_age that are in the database will be sent to zabbix
immediatly.

All events sent to Zabbix contain the timestamp of retrieval by
suricata-reporter, so Zabbix will register and order them as received on that
timestamp independently of the actual time Zabbix itself received the
event.

This is my first adventure in Python async programming, so I hope I did
not make any flagrant mistakes. But the code has been running here for
weeks now without any problem. I have not actually tested large bursts
of events, as I could not simulate that.. But I did make Zabbix server
slow, unavailable and finally replaced it with netcat (to accept the connection, but
not react on it) and I had the connection with the server off for a few
hours to then re-establish the connection to see hundereds of pending events 
being registered in only a few milliseconds.
I did not notice any problems with suricata-reporter in any of these
cases.

Regards

Robin

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.