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

Mon Jan 22 05:35:13 UTC 2007

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/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070121/8fddba90/attachment.sig>