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. 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. If it is that is great. I would say you get what you pay for, but if you use good practices around it, cacti can be a very useful and powerful tool. That my 2 cents, -Scott ------------------------------------------------------------------------ ------------ Scott Berkman CCNP 404-975-0097 Network Engineer scott.berkman@reignmaker.net -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jon Lewis Sent: Thursday, January 18, 2007 3:40 PM To: Jeremy Chadwick Cc: Gadi Evron; nanog@merit.edu Subject: Re: FW: [cacti-announce] Cacti 0.8.6j Released (fwd) On Thu, 18 Jan 2007, Jeremy Chadwick wrote:
For those who don't have the time/care enough to go look at the Secunia report, I'll summarise it:
1) cmd.php and copy_cacti_user.php both blindly pass arguments passed in the URL to system(). This, IMHO, is reason enough to not run this software.
I've said this several times recently in less public places, but IMO, cacti is a bit of a security train wreck. The glaring problem isn't that the above mentioned php scripts have poor security / user supplied input sanitization. It's that those scripts were never intended to be run via the web server. So WTF are they doing in a directory served by the web server in a default cacti install? It seems to me, it would make much more sense for cacti to either split itself into 2 totally separate directories, one for things the web server needs to serve, one for everything else, or at least put all the 'web content' portions under one subdirectory of the cacti install directory, so that subdirectory can be either the DocumentRoot of a server or symlinked from elsewhere in a DocumentRoot. There's no reason for things like poller.php or any of the others that are only meant to be run by the admin from the commandline to be in directories served by the web server. I've heard from several people, and spent some time trying to help one of them, who had servers compromised (entry via cacti, then a local root compromise) over the past weekend due to this. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________