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@elan.net