snmp over internet "best practice"

Russell Adams RLAdams at AdamsInfoServ.Com
Fri Aug 24 19:11:51 CEST 2007


I bet you're referencing my post. ;]

Perhaps SNMP v3 is better, but the crux of the matter is that SNMP v1
was completely insecure. There used to be a mindset of "anything but
SNMP v1", which is where my comment originated.

The argument was always SNMP (inferring v1), versus NRPE. I've been an
advocate of using SNMP because there was little client software to
maintain.

So I'll clarify:

SNMPv1 should be ok when used on a trusted internal network, setup for
read only access limited to the Nagios host only (and a spare). Do not
use SNMPv1 over the internet or other untrusted networks.

That being said, perhaps someone more familiar with the advances in
SNMPv2 and v3 can speak up as to whether the problems have been
resolved.

Remember, it isn't strictly limited to encryption and authentication
in the protocol, but the implementation of each SNMPD. I'm not
familiar with the history of exploits or broken daemons across
OSes. The protocol may be fixed, but if there are known problems with
vulnerable SNMPD's, then there's still an issue using it on the net.

Common sense would indicate that the same best practices for SNMPv1
(read only access and limiting queries to the Nagios host IP address
(and a spare!)) should help minimize any issues with SNMPv3.

Hopefully we can start a useful discussion on the relative merits of
SNMPv3.

Russell


On Fri, Aug 24, 2007 at 11:42:30AM -0500, Aaron wrote:
> I joined the list recently and while doing some searching for answers 
> came across a "best practices" thread.  One of the things listed in the 
> thread was using snmp whenever possible with the statement that it 
> should only be used on the local networks.
> 
> I'm wondering if this is also the popular belief "best practice" even if 
> you're using snmp v3 and if so why.  I was about to deploy snmp v3 
> active checks to check things like cpu and disk loads and then i saw 
> this post.  I thought that was the whole point of v3 with SHA and AES 
> encryptions and authentication so that we could use it over the net.
> 
> Thanks in advance.
> 
> Aaron
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
------------------------------------------------------------------
Russell Adams                            RLAdams at AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/users/attachments/20070824/d16cd9ee/attachment.sig>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


More information about the Users mailing list