North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: william(at)elan.net
  • Date: Thu Jan 18 17:24:51 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
[email protected]