vacm.ucd-snmp.txt

`Date: Tue, 6 Apr 1999 03:09:55 -0800  
From: + + <[email protected]>  
To: [email protected]  
Subject: ucd snmp vacm's public community access auth probs?  
  
I have found a feature in the vacm ucd-snmp v3.52 and v3.6, when setting up snmp services under Linux RH 5.2.  
  
By default, v3.5.2 always delivers the system mib subtree and v3.6 the entire mib tree. Both requests are made with the public  
community name. All the machines capable of connecting to your snmp port, will have access to that information.  
  
Quite contrary to what the documentation says, you can't change this behaviour with the vacm configuration file  
(/etc/snmp/snmpd.conf).  
  
You can try, but it's ignored. I have tried to change v3.5.2, since I needed the entire mib tree for monitoring the Linux  
machines with Netview, under the public community.  
  
A quick and dirty fix for 3.5.2 is changing the source file snmplib/snmp_api.c.  
  
Where you are reading DEFAULT_COMMUNITY "public", change the public string to something hard to guess (and make it long, too).  
After compiling and instaling the modified snmpd, you can configure the public community as you wish.  
  
This quirk doesn't work anymore for v3.6. A workaround for restriting access could be ipchains rules under Linux.  
  
Regards,  
Rui  
  
---  
Rui Fernando Ferreira Ribeiro  
IT Consultant  
CASE  
  
  
  
  
-----== Sent via Deja News, The Discussion Network ==-----  
http://www.dejanews.com/ Easy access to 50,000+ discussion forums  
  
----------------------------------------------------------------------------------  
  
Date: Thu, 15 Apr 1999 03:11:29 -0800  
From: Rui Ribeiro <[email protected]>  
To: [email protected]  
Subject: Re: ucd snmp vacm's public community access auth probs?  
  
Since the first posting I have clarified a few points with some hints from Wes Hardaker ([email protected]).  
  
ucd-snmp v3.5.2 has indeed the described problem. v3.6 no longer suffers from it, but the RH smnpd default directory is no  
longer recognized under it (RH joys).  
  
I was wrong about v3.6 since when not configured, it answers to requests from any snmp community (this apparently is  
documented). The best way to check for configuration errors is invoking snmpd with the -L -D options.  
  
Fixes:  
  
. upgrade to 3.6, since it also has a better support for snmp traps  
. swapping to another Linux dristribution? :(  
  
Regards,  
Rui  
  
---  
Rui Fernando Ferreira Ribeiro  
IT Consultant  
CASE  
  
`