Re: net-snmp security conundrum

Brian Jones <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <CAABZye_inr9GhBjSsDQ9MbF2wkxjhgpSyNoMGctKPpGRSoTKpg@mail.gmail.com>
So If I'm sitting on your network somewhere, and I issue the following
command, what happens?

snmpusm -v 3 -u secureUser -a MD5 -A whoAreYou -X whoAreYou -l authPriv \
yourAppliance create anotherUser secureUser

Is anotherUser created?   If not, can you explain to me what is
preventing anotherUser from being created?

Are you suppressing persistent data by passing the '-C' flag to snmpd
as well?  If not, what ends up in your persistent data file
(/var/net-snmp/snmpd.conf by default) the next time you -HUP snmpd?




On Thu, Oct 20, 2011 at 1:25 PM, Gary Dunlap <[email protected]> wrote:
>
> My implementation is on a local linux system, also for a product appliance, and I don’t have the notion of a remote station updating it.  So it’s not updated via MIBs.
>
>
>
> I let v1/v2c users discover MIB-II info but restrict them from the rest, if there are any SNMPv3 users defined.  I’d be interested to know if that meets the community’s definition of SNMPv3/v2 coexistence.  I didn’t find much by researching it.
>
>
>
> So below is an example snmpd.conf that configures a v3 user, but lets v2 users be controlled by community strings and limited to a particular view.
>
>
>
> # cat snmpd.conf
>
> rwuser secureUser
>
> createUser secureUser MD5 "whoAreYou" DES "whoAreYou"
>
> trapsink 10.134.1.9
>
> view mgmtprivate included .1.3.6.1.2.1.1
>
> view mgmtprivate included .1.3.6.1.4
>
> rocommunity public default -V mgmtprivate
>
> rwcommunity private default -V mgmtprivate
>
> trapcommunity public
>
> engineIDType 3
>
>
>
> From: Brian Jones [mailto:[email protected]]
> Sent: Thursday, October 20, 2011 2:13 PM
> To: Gary Dunlap
> Cc: [email protected]
>
> Subject: Re: net-snmp security conundrum
>
>
>
> How do you handle the case of a user created via snmp from a remote station?  In this case the GUI would have no idea about that user.  Do you simply not allow rwusers? or rwcommunities if you are also supporting 1,2c?
>
> On Thu, Oct 20, 2011 at 1:03 PM, Gary Dunlap <[email protected]> wrote:
>
> Are you talking about snmpd?  I just edit/recreate snmpd.conf to match the users defined in the GUI, then give snmpd the interrupt to re-read snmpd.conf.  As far as which snmpd.conf, it’s the one supplied when starting snmpd, in my case “-c/cfg/etc/config/snmpd.conf”.
>
>
>
> Gary
>
>
>
> From: Brian Jones [mailto:[email protected]]
> Sent: Thursday, October 20, 2011 1:46 PM
> To: [email protected]
> Subject: net-snmp security conundrum
>
>
>
> I am trying to write a GUI for net-snmp on a FreeBSD based appliance and I am struggling with the security model.  The way I see it, I can create/modify usmUsers in one of two ways.
>
> 1) via directly editing the static and persistent config files
> 2) via commands like snmpuser
>
>
> If I chose method 1, then I need some way to associate the rouser/rwuser line in the static config with the appropriate usmUser line in the persistent config, and I can't seem to find a way to do that.
>
> If I choose method 2, then I need to have an rwuser for use by the GUI whose password can only be modified from localhost.  I suspect this might be possible to do using views, but I sure haven't been able to figure it out yet.
>
>
> Thoughts, comments, opinions, please.
>
>

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.