[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

1246.0. "DECbridge 900MX access control" by LISSYS::DOMINGUES () Fri Jul 22 1994 15:59

Hi there,

I have a customer that needs more security on SNMP management and he is asking
for an access control based on IP address of remote NMS information and if
possible on the remote user. The community name is not enough from is point of
view.

Do we support this functionality on DECbridge 900 MX ?

thanks in advance,

//Manuel
T.RTitleUserPersonal
Name
DateLines
1246.1Yes, we support source address checking.NACAD::GALLAGHERFri Jul 22 1994 16:4855
We support security based on ip source address in our "public-common.mib".
The DECbridge900MX supports this mib.  The public-common mib can be 
retrieved from gatekeeper.dec.com.  An explanation of the mib objects
is attached.

HUBwatch doesn't currently support the objects in this mib group.
A generic mib-browsing tool can be used to set these objects.

						-Shawn
--  +
--  
--  SNMP Authentication Database.
--
--  The Simple  Network  Management  Protocol  (SNMP)  employs  a  "trivial"
--  authentication  scheme  based on "community names".  Community names are
--  textual strings which represent access to a set of objects with a set of
--  access rights.
--  
--  The SNMP Authentication Group  contains  objects  which  provide  access
--  rights  for  three communities:  read-only, read-write, and traps.  Each
--  of the three communities  contain  a  community  string  object,  and  a
--  UserTable.
--  
--  The community string provides the name of the community.  All  community
--  strings  are  initially  "public".   The default community string may be
--  changes to provide additional security.   For  example,  the  read-write
--  community  may  be  changed from "public" to "secret".  This only allows
--  read-write access to users who know the  "secret"  read-write  community
--  string.
--  
--  The UserTable is a table of  authorized  users  of  the  community.   By
--  default,  all  users  (who known the community string) are authorized to
--  use the community.  Each communities UserTable  contains  three  object:
--  UserAddr, UserMask, and UserStatus.
--  
--  UserAddr is the IP  address  of  an  authorized  user,  or  a  group  of
--  authorized  users.   Initially,  all  users are allowed access.  Writing
--  16.21.16.128 to an entry  of  the  read-only  UserTable  prohibits  read
--  access from any host but 16.21.16.128.
--  
--  UserMask is used to provide 'wildcard' authorized users.  This  mask  is
--  applied  to  the  incoming  IpAddress and the value of the corresponding
--  UserAddr.  If the resulting incoming IpAddress and _UserAddr match,  the
--  message   is   considered   authorized.    (For   example,  UserAddr  of
--  16.21.16.128 and UserMask of 0xffffff00 allows users from 16.21.16.0  to
--  16.21.16.255 to be authorized on the community.)
--  
--  UserStatus is used to create and delete entries.  Entries are created by
--  setting  UserAddress.   Entries  are  deleted  by  setting UserStatus to
--  invalid(2).  Invalid entries are removed from the UserTable.
--  
--  All trap, read-only, and read-write  community string are  non-volatile.
--  All UserTable information is also non-volatile.
--  -