Re: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
On Thu, Jan 18, 2007 at 02:33:10PM -0700, 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). I think there are a few factors at work here: 1) PHP is very easy to learn, but deals primarily with web input (i.e. potentially hostile). Since most novice programmers are happy to get the software working, they rarely ever consider the problem of trying to make it not not work. In other words, that it always behave correctly. That problem and assurance is much, much more difficult than just getting the software to work. You can't test it into the software. You can't rely on a good history to indicate there are no latent problems. 2) Furthermore, this is a service that is designed primarily for public consumption, unlike say NFS; it cannot be easily firewalled at the network layer if there is a problem or abuse. 3) The end devices rarely support direct VPN connections, and redundant infrastructure just for monitoring is expensive. 4) The functionality controlled by the user is too complicated. If all you are doing is serving images of graphs, generate them for the common scenarios and save them to a directory where a much more simple program can serve them. That is, most of the dynamically-generated content doesn't need to be generated on demand. If you're pulling data from a database, pull it all and generate static HTML files. Then you don't even need CGI functionality on the end-user interface. It thus scales much better than the dynamic stuff, or SSL-encrypted sessions, because it isn't doing any computation. As they say, there are two ways to design a secure system: 1) Make it so simple that there are obviously no vulnerabilities. 2) Make it so complex that there are no obvious vulnerabilities. I prefer the former, however unsexy and non-interactive it may be. write it yourself or purchase it from a vendor that can support and guarantee the security of the product. Unless you're a skilled programmer with a good understanding of secure coding techniques, the first suggestion could be dangerous. It seems that too many developers try to do things themselves without any research into similar programs and the kinds of security risks they faced, and end up making common mistakes in the form of security vulnerabilities. And no vendor of popular software I know of can guarantee that it is secure. I have seen a few companies that employ formal methods in their design practices and good software engineering techniques in the coding process, but they are almost unheard of. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -- URL:http://www.subspacefield.org/~travis/ pgpoqADlrhvFN.pgp Description: PGP signature
Re: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
On Thu, Jan 18, 2007 at 11:40:06AM -0600, Gadi Evron wrote: Many of us run cacti. FYI. Thanks for posting this, even though it's slightly OT. Not to start an opinion war, but those who do run Cacti should really consider removing this software from their boxes permanently. http://secunia.com/advisories/23528/ 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. 2) cmd.php and copy_cacti_user.php both blindly pass arguments passed in the URL to whatever SQL back-end is used (MySQL most commonly); no escaping or sanitising is done. Otherwise known as an SQL injection flaw. There are other flaws mentioned, but they're simply subsets of the above two. Also, register_argc_argv is enabled (rightfully so) by default in PHP, so don't let that decrease the severity of this atrocity. (I can forgive SQL injections, but cannot blindly calling system()). I'd been considering (off and on for about a year) using Cacti for statistics gathering, and now I'm glad I didn't. This kind-of flaw reflects directly on the programming ethics and of the authors behind this software. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
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_
RE: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
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 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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_
RE: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
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]
RE: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
On Thu, 2007-01-18 at 14:33 -0700, Berkman, Scott wrote: There is this Network Management theory called Out of Band Management. Which is rarely properly applied. I lost count of the data centers that block mgmt traffic from external customers, but leave internal systems (which are often sublet to all sorts of external customers) wide open to mgmt servers/devices. Unfortunately mgmt systems need access to whatever they are monitoring, so if you're monitoring customer systems then you are more than likely exposed and should take high-priority at tightening your NMS systems. I know, I work for a NMS vendor and I wouldn't sign my name certifying that our stuff is secure. It's funny how pen testing seems to avoid NMS stuff. -Jim P. signature.asc Description: This is a digitally signed message part
Re: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
* Berkman, Scott [EMAIL PROTECTED] [2007-01-18 22:34]: 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. very much opposed to commercial software, where you can be 100% sure that they are full of bugs, errors, and exploits -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
