FW: [cacti-announce] Cacti 0.8.6j Released (fwd)

Thu Jan 18 22:21:58 UTC 2007

On Thu, 18 Jan 2007, Berkman, Scott wrote:

> NMS Software should not be placed in the public domain/internet.  By the
> time anyone who would like to attack Cacti itself can access the server
> and malform an HTTP request to run this attack, then can also go see
> your entire topology and access your SNMP keys (assuming v1).  There is
> this Network Management theory called Out of Band Management.  If you
> are concerned about security, you should only be polling anything you
> expect to be secure on a private management link/network.  If you want
> to run an MRTG stats collector that is publicly visible and expect it to
> be secure, write it yourself or purchase it from a vendor that can
> support and guarantee the security of the product.

Sound theory. However as someone who has setup network management
& monitoring (both using open-source and proprietary software) dozen
times for multiple companies (and wrote software myself when necessary),
I can tell you that it can not work in every situation.

In particular while its correct idea to setup separate management
network for accessing devices through SNMP, the actual management
or monitoring workstation/server usually needs to be placed somewhere 
where its accessible from regular network, so that is exactly
how cacti is used. The correct setup would be to require SSL
connection (if its webinterface) and password authentication to
access your management/monitoring server and if it is necessary
to make data available to outside, then do it through separate
controlled interface. For example you could setup separate page
for read-only access to certain graphs using RRD files created
by cacti (and make sure CGI is not run under apache but under
its own user and that user is different then the one cacti is
using so that community strings in cacti are not available if
outside interface is hacked; note that I'm speaking really more
generally - I don't use cacti and do not know if it allows to
do it properly).

All that requires of course certain amount of security knowledge
and admin skills and sometimes even programming skills which
a lot of network administrators who choose to use cacti do not
have (in fact cacti seems so popular exactly because its easy
to setup by junior admins).

BTW - personally I use nagios for both monitoring and providing
graphing results for the data (that obviously reduces number of
SNMP queries as I do not need to do it twice) useing nagiosgrapher
with very heavy customization (I rewrote their webinterface and
parts of the library and collection), result looks like this:
  http://www.elan.net/~william/nagios/printscreen_ngrapher5_nagioshost.pdf
and some bits of software as far as I had time to release it is at 
http://www.elan.net/~william/nagios/

> Cacti is a free open source tool, and in my opinion these should never
> be expected to be 100% free of bugs, errors, and exploits.

You know, above applies to commercial software just as much as to
non-commercial/open-source. In fact the theory is that commercial
software has more bugs & security flows because its code is not
available and thus can not be examined by outsiders and similarly
for the same reasons the bugs are less often found and when it is,
the details about the bug may not be made available to the public
beyond some simple "software update". Just think of how many bugs
and security updates are released by software coming from Redmond
and compare to Linux, OpenBSD, FreeBSD, etc -

> If it is that is great.  I would say you get what you pay for

So free software like apache are no good, right? How may security
bugs is there again found in apache and compare that to IIS?

The reality is that nowdays "what you pay for" no longer works
when comparing open-source and commercial sofware. In fact commercial
is very often just repackaged open-source supported by some vendor,
i.e. enterprise companies just get a name to put blame to is there
is an issue (plus of course support since many companies would have
bunch of junior admins and only one or two senior engineers who are
always kept very busy).

-- 
William Leibzon
Elan Networks
william at elan.net