Re: [Zabbix-users] How to automatically create host macro by discovery rule for use with discovered items/triggers.

[Shane C. <sc...@ew...>]

That’s actually the approach we have been taking until now, however with a huge number of cyber attacks now targeted at industrial infrastructure, it’s not enough to just sit around and wait for the producer to release an update.  The standards that we are required to adhere to are requiring us to be even more proactive.  That includes making a best effort to address zero day threats that have not been patched by the producer.  Should a threat arise that a patch has not been released for, we still have to take immediate action to prevent the attack until such a patch becomes available.  I agree we should use the right tools for the job, and Zabbix is definitely not the right tool for the job, however I have to work with the tools I’m being given, and this seems like it would be a very simple task for Zabbix if not for the macro restrictions.  Setting up a central database and monitoring the database is an option although it would get pretty complicated setting up triggers to compare version numbers in the database to the version numbers detected on each host.

Shane Corbin
Electrical Engineer/IT Administrator
Direct: (217) 893-5526
Office: (217) 892-4322
Call via Teams<callto:sc...@ew...>
Chat via Teams<https://teams.microsoft.com/l/chat/0/0?users=sc...@ew...>

From: Guus Snijders <gsn...@gm...>
Sent: Friday, September 10, 2021 4:08 AM
To: Shane Corbin <sc...@ew...>; zabbix-users <zab...@li...>
Subject: Re: [Zabbix-users] How to automatically create host macro by discovery rule for use with discovered items/triggers.

Op vr 10 sep. 2021 08:20 schreef Shane Corbin <sc...@ew...<mailto:sc...@ew...>>:
Thanks for the response Shawn.  That’s kind of disappointing.  I first considered separate templates for each piece of software I am concerned about, but unfortunately I am concerned about all of them no matter how big or small.  [···]

As for RHEL not incrementing version numbers when patching vulns is… well.. disappointing and quite irresponsible of them.  That’s exactly what minor version numbers are for.  Not surprising though, we intentionally avoid RHEL for many other reasons, this is just yet another reason to continue on that path.

Just a suggestion, but why not flip the logic around and report the available updates for $system?

One thing we *know* in advance is that we're running vulnerable software, but when a new vulnerability is found, we still rely on the distributor for an update to fix the vulnerability. So why would we chase changing version numbers?

If you really want to know, you could query the package db and store the relevant version numbers in a central DB (for all running systems!), and then monitor that DB for relevant versions.
You should probably include pkg release numbers, but that shouldn't be that hard.

Zabbix is about performance and availability, just use the right tools for the right purpose.


Just my € 0.02


mvg, Guus Snijders