Hi
Michael Tremer schreef op ma 19-04-2021 om 14:37 [+0100]:
Hello,
On 15 Apr 2021, at 14:12, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
...
The purpose of my extension to the default is that a user can easily configure Zabbix to monitor "IPFire"-specific functionalities. Generic Linux metrics can be monitored by default Zabbix templates and agent built-in functionality eventually extended with user-defined scripts or modules.
Yes, and I am absolutely for it. The Zabbix Agent alone is not very useful when it does not understand the special metrics that IPFire has and exports them in some way or another.
That said, there is obviously always the problem that if a third person gains access to the monitoring system, they would have a full map of the entire network and loads of other metrics that are helpful to see whether their attack is effective and/or detected. That is something that is out of scope of this project and a risk that people need to evaluate elsewhere. Obviously no monitoring at all is not a solution either.
True that, a monitoring system an sich is a security risk and should be appropriately secured on its own. But is indeed not our scope here. What we can do to secure it a little bit more is adding a big remark to the wiki page for the user to seriously consider setting up encrypted agent communication so hackers on the network at least can't intercept the values coming from IPFire. But by default we can't set that up for the user as PSK's or certificates are required that only the user can provide.
The IPFire webgui has a nice overview of all vital IPFire services and their state, as well as for addon-services. A user can browse the status pages of the WebGUI to have a view of how their IPFire machine is running This is exactly what I want to provide to the Zabbix user, hence my copy of services.cgi-code.
Understood. Since the services.cgi code is a bit ugly, we might want to rethink how we solve this.
I would be in favour of a file that every add-on brings with it and that makes it show up on the services.cgi table as well as bringing some more meta information like the name of the initscript (if there is one) which you could then call by using addonctrl status.
For the add-on services at least, that sounds like a good idea. I see there is already a bit of metadata in /opt/pakfire/db/installed/meta-*. This could possibly be extended with an InitScript: entry? But I'm not sure how to do this as I'm not sure how and where this file is actually generated. A proper place to set the variable that would be used in the final meta-file if an initscript is present would be in the lfs call INSTALL_INITSCRIPT but also here I have no idea where this function INSTALL_INITSCRIPT is actually defined. So I'm just guessing that this is the ideal place.
Alternatively, I could 'parse' the output of the services-page of the webserver. But that is rather something one would do when trying to monitor a black-box.
That is going to break as soon as we touch any of the markup.
That's one of the reasons why I would like to avoid that. :-)
... I totally agree, I was only pointing out the *some* security there is, but that will indeed never be sufficient to allow full access to iptables or addonctrl by default.
I could live with the information leak (that is pretty much what Zabbix is designed for), but I cannot live with the possibility that breaking in the agent allows changing the iptables ruleset. Definitely not in the default configuration.
A user could, on his own risk, do that to maybe have the agent execute firewall-actions as a reaction to a detected network attack or so.. But that is not something we should provide by default.
What would a monitoring tool do with a dump of the iptables ruleset? I do not even understand where the use of this is.
The same as IPFire webgui currently does on netother.cgi?fwhits?day by calling /sbin/iptables -vnxL <chain> | grep "/* <rule> */" | awk '{ print $2 }';: keep history of and eventually react on the number of firewall-hits.
We have the following SUID binary:
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/misc-progs/getipstat.c...
It isn’t pretty, but dumps the entire iptables ruleset into files which you can then read.
This allows exposing the ruleset without giving the agent the option to run the iptables command as root.
At first, this sounded like the solution. But I found 2 problems with it:
- It generates a (few) fixed files with names that can't be customized. And it is called in guardian.cgi and iptables.cgi. So if it so happens that a user opens one of those 2 pages at the moment the zabbix agent is using that command; chances are that the file is removed again by the time the agent can parse it or incompletely (re)written. Resulting in the agent failing to collect the metrics accurately. (or one of those cgi's failing to give a correct output). A possible fix for this could be to have a command parameter on this tool that switches output to stdout, or that would let you define the output-filename.
- It doesn't call iptables with the -x parameter (to show the exact # of bytes in the output) which I really require. Rounded values up to K/M or even G are pretty useless for fine grained monitoring. Also here is a possible fix to accept a command line parameter to make the command call iptables with the -x parameter added. (as it is currently used by iptables, we probably don't want -x to be used by default, hence an optional parameter)
If you see no problem in these changes, I will try to submit a patch for it shortly.
About addonctrl where zabbix needs to call "addonctrl status" which requires root: I propose to add a wrapper script to the zabbix_agentd package that will call addonctrl status "$1" which then in turn can be added to the sudo list instead of addonctrl itself.
Regards
Robin
But you are completely right that access to iptables should be restricted to just that what we want to get from it, which can be achieved with a wrapper script as explained below in my previous mail.
-Michael
Regards
Robin