Re: [PATCH 4/4] [V2] zabbix_agentd: Add IPFire specific userparameters

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

[-- Attachment #1: Type: text/plain, Size: 6830 bytes --]

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(a)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;h=c806d54a9b0145aa2f0a11c848bc158f6e70a481;hb=HEAD
> 
> 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


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