935732 - OpSec/Secreview: Enable network access for Nagios Livestatus data

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Review Request, task)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

+++ This bug was initially created as a clone of Bug #934340 +++

Initial Questions:

Project/Feature Name: Enable network access for Nagios Livestatus data
Tracking  ID:
Description:
Livestatus is a plugin to Nagios that provides a programmable interface into retrieving status data and interacting with Nagios. Currently the plugin is installed as accessible to the local system via a socket. The purpose of this bug is to enable access through TCP sockets via xinetd.

Currently the plugin is used by the Nagios IRC bots and some helper scripts (https://mana.mozilla.org/wiki/display/SYSADMIN/nagiosctl, etc.) since traditional interfacing with Nagios is excessively slow and inefficient (parsing status and log files). Making it available over the network would provide for dashboards[1][2] and other tools.

Access control can be handled by a simple HTTP application that would proxy requests through the TCP socket behind LDAP auth.


[1] http://mathias-kettner.com/checkmk_multisite.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=884307
Additional Information:
http://mathias-kettner.de/checkmk_livestatus.html
Key Initiative: Product Support
Release Date: 2013-11-11
Project Status: ready
Mozilla Data: No
Mozilla Related: 
Separate Party: No

Comment 1

[Michal Purzynski [:michal`] (use NEEDINFO)]

Who is going to be a consumer of this data? What kind of applications will be logging in here?

Comment 2

[Michal Purzynski [:michal`] (use NEEDINFO)]

Where can I learn more about the architecture? I need some clarifications how it's going to look like, as that's something new for me.

1. You are saying that xinetd will handle the incoming connections. What kind of application will xinetd start?
2. Where is the place for the HTTP kind of proxy?
3. Is it going to be runing on the nagios hosts only or all of our infrastructure?
4. Can we use HTTPS for that?

Comment 3

[Michal Purzynski [:michal`] (use NEEDINFO)]

/etc/xinetd.d/livestatus

service livestatus
{
	type		= UNLISTED
	port		= 6557
	socket_type	= stream
	protocol	= tcp
	wait		= no
# limit to 100 connections per second. Disable 3 secs if above.
	cps             = 100 3
# set the number of maximum allowed parallel instances of unixcat.
# Please make sure that this values is at least as high as
# the number of threads defined with num_client_threads in
# etc/mk-livestatus/nagios.cfg
        instances       = 500
# limit the maximum number of simultaneous connections from
# one source IP address
        per_source      = 250
# Disable TCP delay, makes connection more responsive
	flags           = NODELAY
	user		= nagios
	server		= /usr/bin/unixcat
	server_args     = /var/lib/nagios/rw/live
# configure the IP address(es) of your Nagios server here:
#	only_from       = 127.0.0.1 10.0.20.1 10.0.20.2
	disable		= no
}

Is that the example xinetd configuration AKA how it will look like?

Still need to understand where the HTTP(S) proxy place is. Thanks! :)

Comment 4

[Ashish Vijayaram [:ashish]]

(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #2)
> Where can I learn more about the architecture? I need some clarifications
> how it's going to look like, as that's something new for me.
> 
> 1. You are saying that xinetd will handle the incoming connections. What
> kind of application will xinetd start?
Comment 3.

> 2. Where is the place for the HTTP kind of proxy?
Ideally through httpd that already runs on the servers and configured for /nagios 

> 3. Is it going to be runing on the nagios hosts only or all of our
> infrastructure?
Only on nagios hosts

> 4. Can we use HTTPS for that?
We could, although this is all internal for now

Comment 5

[Ashish Vijayaram [:ashish]]

To answer your question about http program, I don't have the code yet but it should be a simple HTTP to TCP wrapper, mostly to handle auth. I would ideally need both (restricted) TCP as well as HTTP access because some applications like the dashboard[3] work on TCP whereas there has been requests for HTTP methods in[4].

[3] http://mathias-kettner.com/checkmk_multisite_setup.html
[4] Bug 884307

Comment 6

[Michal Purzynski [:michal`] (use NEEDINFO)]

OK, I don't see any further issues here, the rest is up to AppSec to review the application. Closing this bug. Let's just make sure we filter access so it's only accessible from whatever hosts need it and not anything else.