SNMP Version 3 More about VACM and USM Nick Urbanik 2003, 2005 Copyright Conditions: Open Publication License (see http://www.opencontent.org/openpub/) Goals of SNMPv3 (RFC 3411). . . . . . . . . VACM VACM . . . . . . . . . . . . . . . . . . . . . . . . Context . . . . . . . . . . . . . . . . . . . . . . . Context Example from RFC 3411 . . . . . isAccessAllowed from RFC 3415 . . . . . . VACM on Net-SNMP VACM on Net-SNMP . . . . . . . . . . . . . Net-SNMP VACM . . . . . . . . . . . . . . . . The access Keyword . . . . . . . . . . . . . . access: Security Model, Security Level . access: The prefix Parameter . . . . . . . access with SNMPv1, v2c . . . . . . . . . . The com2sec keyword . . . . . . . . . . . . . The group Keyword. . . . . . . . . . . . . . . vacm Views Views and the view Keyword . . . . . . . . The view Keyword — 2 . . . . . . . . . . . . View Mask The View Mask — 1 . . . . . . . . . . . . . . The Network Interface Table, ifTable . View Mask and the ifTable Walking ifTable — 1 . . . . . . . . . . . . . Walking ifTable — 2 . . . . . . . . . . . . . ifTable in Numbers — 1 . . . . . . . . . . . ifTable in Numbers — 2 . . . . . . . . . . . Instance Number . . . . . . . . . . . . . . . . . The View Mask — 2 . . . . . . . . . . . . . . The View Mask — 3 . . . . . . . . . . . . . . The View Mask — 4 . . . . . . . . . . . . . . vacm Examples Net-SNMP vacm Example 1 . . . . . . . . Net-SNMP VACM Example 1. . . . . . . . Net-SNMP VACM Example 2. . . . . . . . Cisco VACM Configuration . . . . . . . . . User-based Security Model User-based Security Model . . . . . . . . . . . . . . . . . . . . . . . . slide #2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . slide slide slide slide #3 #4 #5 #6 . slide #7 . slide #8 . slide #9 slide #10 slide #11 slide #12 slide #13 slide #14 . . . . . . . . . . . . . slide #15 . . . . . . . . . . . . . slide #16 . . . . . . . . . . . . . slide #17 . . . . . . . . . . . . . slide #18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . slide slide slide slide slide slide slide slide slide slide slide slide #19 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 . . . . . . . . . . . . . slide #31 Configuring USM Users — 1. . . Configuring USM Users — 2. . . Remotely Creating USM Users . References SNMP Standards and RFCs . . . References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . slide #32 . . . . . . . . . . . . . . . . . . . slide #33 . . . . . . . . . . . . . . . . . . . slide #34 . . . . . . . . . . . . . . . . . . . slide #35 . . . . . . . . . . . . . . . . . . . slide #36 Goals of SNMPv3 (RFC 3411) Avoid reinventing the wheel—use existing work Support secure set operation Support forward and backward compatibility Support remote configuration – usm and vacm configuration is through snmp tables and variables Security protection against: – modification of information by unauthorised parties – an unauthorised person masquerading as an authorised person – message stream modification by reordering, delaying or replaying exchanges – disclosure (eavesdropping) SNM — ver. 1.7 SNMP v3 — slide #2 VACM The View-based Access Control Model (VACM) vacm has five main components, as we mentioned earlier: – groups of users – security level, i.e., v1, v2c, usm – contexts — see slide 4 – MIB views, view families — see slide 9 – access policy, i.e., read only, read-write, notify, no access. How do we set up snmpv3 users on agents and network management software? How do we control access to a subset of mib variables on an agent? SNM — ver. 1.7 SNMP v3 — slide #3 Context Example from RFC 3411 SNMP Entity (identified by snmpEngineID, for example: ’800002b804616263’H (enterprise 696, string "abc") SNMP Engine (Identified by snmpEngineID) Message Processing Subsystem Access Control Subsystem Dispatcher Security Subsystem Command Responder Application (contextEngineID, example: ’800002b804616263’H) Example contextNames: "bridge1" "bridge2" "" (default) MIB Instrumentation context bridge MIB context bridge MIB context some MIB other MIB SNM — ver. 1.7 SNMP v3 — slide #5 Context An snmp context is a collection of management variables accessible by an snmp entity. Gives a way to group variables into collections with different access policies. Example from rfc 3411: See slide 4 – The engine uses the bridge mib defined in rfc 1493 – but the engine keeps management information for two separate bridges labeled bridge1 and bridge2 – Could be that neither bridge directly supports snmp, so another device on the lan collects data from the bridges using some other method – Makes this information available within the context SNM — ver. 1.7 SNMP v3 — slide #4 SNM — ver. 1.7 why from RFC 3415 who   securityModel      securityName where groupName contextName   securityModel      securityLevel viewName how    viewType (read/write/ notify) yes/no decision what object-type variableName (oid) which objectinstance SNMP v3 — slide #6 VACM on Net-SNMP Net-SNMP uses four /etc/snmp/snmpd.conf: – – keywords – – to set up vacm in The Keyword Specifies which group has access to which parts of the mib tree Has 8 parameters. Syntax (all on one line): access group context secmodel seclevel prefix readview writeview notifyview These set up access control to variables on the agent. – access and view determine what access is being controlled to. – group and com2sec determine who has this access. SNM — ver. 1.7 SNMP v3 — slide #7 Last three parameters readview views, defined by view statements. writeview notifyview are – Indicate which part of the mib tree has read access, which part of tree has write access, and which part has permission for access to send notifications (i.e., traps or inform requests) The group parameter is defined by a group statement – Represents a group of users Default context is the empty string "". See slide 4. SNM — ver. 1.7 SNMP v3 — slide #9 : Security Model, Security Level The parameter secmodel is the Security Model. Net-SNMP VACM secName ipSource default community   ¡ ¢ ¤ £ ¥   – Can be one of: any, v1, v2c or usm. – Should be set to match the snmp version of clients that will connect to this agent. Parameter seclevel Security Level tells whether we use authentication or encryption groupName model v1 v2c usm secName ¦§ ¡¨ © groupName context "" model v1 v2c usm any oidSubtree level noauth auth priv prefix exact prefix readScope viewName none writeScope viewName none notifyScope viewName none – Can be one of noauth, auth, or priv – Note that community strings are not counted as authentication, so for snmpv1 and snmpv2 we specify noauth – priv (privacy) means that we use both strong authentication and encryption.      ¥¤ ¤ viewName type included excluded [mask]   ¥ SNM — ver. 1.7 SNMP v3 — slide #8 SNM — ver. 1.7 SNMP v3 — slide #10 : The prefix Parameter The prefix parameter to access can be either exact or prefix. Indicates whether context name needs to match exactly or whether only the first part of the context name needs to match. The default value is exact. SNM — ver. 1.7 SNMP v3 — slide #11 The Syntax: Keyword maps pairs of Security Model and Security Name to a group name. group groupName securityModel securityName A Security Model is one of v1, v2c or usm. The Security Name is the user name. with SNMPv1, v2c For snmpv1 and snmpv2c clients – Security Level will be noauth, and – context will be empty (the empty string). SNM — ver. 1.7 SNMP v3 — slide #12 All members of one group have the same access rights. A user cannot belong to more than one group for each of the three security models. SNM — ver. 1.7 SNMP v3 — slide #14 The keyword Maps a community string and a source ip or network address to a security name (user name). Syntax: com2sec securityName source community Views and the Keyword The view determines what part of the mib access is controlled to. Uses concept of a subtree. – A subtree is a node in the mib tree and all the elements under that node. – In other words, all the mib elements in a subtree have the same common prefix. Syntax: view viewName incl/excl subtree mask(optional) SNMP v3 — slide #15 – The security name is used by the group keyword — see 8 – Source can be a hostname, a subnet or the word “default” A subnet can be written as IP/mask or IP/BITS, e.g., our lab subnet can be written as 172.19.64.0/255.255.192.0 or 172.19.64.0/18. Only needed for access control with snmpv1 and v2c – Not used with snmpv3 SNM — ver. 1.7 SNMP v3 — slide #13 SNM — ver. 1.7 The Keyword — 2 incl/excl can be either “included” or “excluded” – “included” means that the mib view includes all the elements of the subtree; – “excluded” means that the mib view excludes all the elements of the subtree. Walking —1 SNM — ver. 1.7 SNMP v3 — slide #16 The View Mask — 1 The optional view mask allows the access control to select individual rows in a table. rfc 3415 calls this a family of subtrees, since a row of n elements can be also represented by n subtrees rfc 3415 calls the mask the family mask SNM — ver. 1.7 SNMP v3 — slide #17 $ IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifDescr.1 = STRING: lo IF-MIB::ifDescr.2 = STRING: eth0 IF-MIB::ifType.1 = INTEGER: softwareLoopback(24) IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) IF-MIB::ifMtu.1 = INTEGER: 16436 IF-MIB::ifMtu.2 = INTEGER: 1500 IF-MIB::ifSpeed.1 = Gauge32: 10000000 IF-MIB::ifSpeed.2 = Gauge32: 100000000 IF-MIB::ifPhysAddress.1 = STRING: IF-MIB::ifPhysAddress.2 = STRING: 0:1:3:45:99:12 IF-MIB::ifAdminStatus.1 = INTEGER: up(1) IF-MIB::ifAdminStatus.2 = INTEGER: up(1) IF-MIB::ifOperStatus.1 = INTEGER: up(1) IF-MIB::ifOperStatus.2 = INTEGER: up(1) IF-MIB::ifInOctets.1 = Counter32: 1073820735 IF-MIB::ifInOctets.2 = Counter32: 1620632733 SNM — ver. 1.7 SNMP v3 — slide #19 Walking —2 The Network Interface Table, Under mib-2 is the important ifTable – Provides statistics on each network interface – includes such things as network traffic, errors,. . . – One row in the table for each network interface SNM — ver. 1.7 SNMP v3 — slide #18 IF-MIB::ifInUcastPkts.1 = Counter32: 2950449 IF-MIB::ifInUcastPkts.2 = Counter32: 105216646 IF-MIB::ifInDiscards.1 = Counter32: 0 IF-MIB::ifInDiscards.2 = Counter32: 0 IF-MIB::ifInErrors.1 = Counter32: 0 IF-MIB::ifInErrors.2 = Counter32: 0 IF-MIB::ifOutOctets.1 = Counter32: 1073821769 IF-MIB::ifOutOctets.2 = Counter32: 2594849796 IF-MIB::ifOutUcastPkts.1 = Counter32: 2950461 IF-MIB::ifOutUcastPkts.2 = Counter32: 81734428 IF-MIB::ifOutDiscards.1 = Counter32: 0 IF-MIB::ifOutDiscards.2 = Counter32: 0 IF-MIB::ifOutErrors.1 = Counter32: 0 IF-MIB::ifOutErrors.2 = Counter32: 0 IF-MIB::ifOutQLen.1 = Gauge32: 0 IF-MIB::ifOutQLen.2 = Gauge32: 0 IF-MIB::ifSpecific.1 = OID: SNMPv2-SMI::zeroDotZero IF-MIB::ifSpecific.2 = OID: SNMPv2-SMI::zeroDotZero SNM — ver. 1.7 SNMP v3 — slide #20 in Numbers — 1 $ .1.3.6.1.2.1.2.2.1.1.1 .1.3.6.1.2.1.2.2.1.1.2 .1.3.6.1.2.1.2.2.1.2.1 .1.3.6.1.2.1.2.2.1.2.2 .1.3.6.1.2.1.2.2.1.3.1 .1.3.6.1.2.1.2.2.1.3.2 .1.3.6.1.2.1.2.2.1.4.1 .1.3.6.1.2.1.2.2.1.4.2 .1.3.6.1.2.1.2.2.1.5.1 .1.3.6.1.2.1.2.2.1.5.2 .1.3.6.1.2.1.2.2.1.6.1 .1.3.6.1.2.1.2.2.1.6.2 .1.3.6.1.2.1.2.2.1.7.1 .1.3.6.1.2.1.2.2.1.7.2 .1.3.6.1.2.1.2.2.1.8.1 .1.3.6.1.2.1.2.2.1.8.2 .1.3.6.1.2.1.2.2.1.10.1 .1.3.6.1.2.1.2.2.1.10.2 SNM — ver. 1.7 = = = = = = = = = = = = = = = = = = INTEGER: 1 INTEGER: 2 STRING: lo STRING: eth0 INTEGER: softwareLoopback(24) INTEGER: ethernetCsmacd(6) INTEGER: 16436 INTEGER: 1500 Gauge32: 10000000 Gauge32: 100000000 STRING: STRING: 0:1:3:45:99:12 INTEGER: up(1) INTEGER: up(1) INTEGER: up(1) INTEGER: up(1) Counter32: 1073820735 Counter32: 1620632733 SNMP v3 — slide #21 Instance Number Notice that the index is the number at the end of the oid Called an instance number. Index starts from 1 Suppose we are an isp, want to allow customer A to view their own network interface, but not that of customer B, their competitor. Note that as we go along a row, the oid element just before the instance number changes Suppose customer A has a network interface with the index 5. $ .1.3.6.1.2.1.2.2.1.16.5 So want to allow access for customer A to .1.3.6.1.2.1.2.2.1.*.5 SNM — ver. 1.7 SNMP v3 — slide #23 in Numbers — 2 .1.3.6.1.2.1.2.2.1.11.1 .1.3.6.1.2.1.2.2.1.11.2 .1.3.6.1.2.1.2.2.1.13.1 .1.3.6.1.2.1.2.2.1.13.2 .1.3.6.1.2.1.2.2.1.14.1 .1.3.6.1.2.1.2.2.1.14.2 .1.3.6.1.2.1.2.2.1.16.1 .1.3.6.1.2.1.2.2.1.16.2 .1.3.6.1.2.1.2.2.1.17.1 .1.3.6.1.2.1.2.2.1.17.2 .1.3.6.1.2.1.2.2.1.19.1 .1.3.6.1.2.1.2.2.1.19.2 .1.3.6.1.2.1.2.2.1.20.1 .1.3.6.1.2.1.2.2.1.20.2 .1.3.6.1.2.1.2.2.1.21.1 .1.3.6.1.2.1.2.2.1.21.2 .1.3.6.1.2.1.2.2.1.22.1 .1.3.6.1.2.1.2.2.1.22.2 SNM — ver. 1.7 = = = = = = = = = = = = = = = = = = Counter32: 2950449 Counter32: 105216646 Counter32: 0 Counter32: 0 Counter32: 0 Counter32: 0 Counter32: 1073821769 Counter32: 2594849796 Counter32: 2950461 Counter32: 81734428 Counter32: 0 Counter32: 0 Counter32: 0 Counter32: 0 Gauge32: 0 Gauge32: 0 OID: SNMPv2-SMI::zeroDotZero OID: SNMPv2-SMI::zeroDotZero SNMP v3 — slide #22 The View Mask — 2 We 1 1 3 1      f can 6 1 1 1 provide 2 1 1 1 2 1 a 2 1 view 1 1 * 0 mask 5 1 * 0 * 0 to * 0 specify * 0 * 0 this: A zero in the bit mask is like a wildcard or “don’t care” specifier A mask of all 1’s is the same as a single view subtree specified by the family name (it’s the same as not specifying a mask) Here the mask is specified as ff.a0 For Net-SNMP, the mask is specified as a list of hexadecimal bytes separated with ‘.’ or ‘:’. SNM — ver. 1.7 SNMP v3 — slide #24                  f            a            0 The View Mask — 3 Note that in creating a view mask, we start from the left, writing hexadecimal digits. We don’t care about the bits representing non-existent elements after the end of the subtree parent. – I mean the bits to the right of the vertical line in slide 13 – These bits could be one or zero; I chose zero, since zero means “don’t care; you can use any value here” We can specify this family of view subtrees like this: Net-SNMP vacm Example 1 # sec.name source com2sec local localhost com2sec ictnetwork 172.19.64.0/18 # group group group group group.name MyRWGroup MyRWGroup MyROGroup MyROGroup sec.model v1 v2c v1 v2c community mypP?rC32 public sec.name local local ictnetwork ictnetwork # viewname incl/excl subtree view all included .1 # group.name context sec.model sec.level match access MyROGroup "" any noauth exact access MyRWGroup "" any noauth exact read write notif all none none all all none SNM — ver. 1.7 SNMP v3 — slide #27 This view can then be used in an access statement – see the example in slide 15 SNM — ver. 1.7 SNMP v3 — slide #25 The View Mask — 4 One bit in the view mask determines access to one element in the oid – It doesn’t matter how big or small the numerical component of the oid is – one bit controls whether different values for that component are included in the family of view subtrees or not rfc 3415 says that any bit mask is extended with 1’s to the same length in bits as the number of identifiers in the oid if it is shorter. As a consequence, a family mask of zero length corresponds to a single view subtree. SNM — ver. 1.7 SNMP v3 — slide #26 Net-SNMP VACM Example 1 In the example in 14, read-write access using the community string “mypP?rC32” is allowed from the same machine only (localhost). read only access is allowed from any machine in the ict laboratory subnet using the (badly chosen) community string “public”. No traps or inform requests can be sent by the agent. SNM — ver. 1.7 SNMP v3 — slide #28 Net-SNMP VACM Example 2 group companyA usm companyAManager group companyB usm companyBManager view viewA included IF-MIB::ifIndex.5 ff.a0 view viewB included IF-MIB::ifIndex.2 ff.a0 access companyA "" usm priv exact viewA none access companyB "" usm priv exact viewB none none none User-based Security Model usm allows remote configuration of users Securely supports strong authentication using md5 or sha1 and encryption using des Remotely create new users by cloning existing users Can only clone a user once Each user must be given access using vacm or that user account cannot be used – Add the user to a group – provide access to that group through views SNM — ver. 1.7 SNMP v3 — slide #31 companyAManager is a usm user that has read-only access to the ifTable row that corresponds to the company A’s own network interface, and no other access. companyBManager is a usm user that has read-only access to the ifTable row that corresponds to the company B’s own network interface, and no other access. SNM — ver. 1.7 SNMP v3 — slide #29 Configuring usm Users — 1 Cisco VACM Configuration Cisco ios specifies a view with the following syntax: snmp-server view viewA ifEntry.*.5 included snmp-server view viewB ifEntry.*.2 included Can specify a group with: snmp-server group groupA v3 auth read viewA Cisco uses the snmp-server user command to specify users and group membership See also pages 284–285 of Essential SNMP. SNM — ver. 1.7 SNMP v3 — slide #30 usm users can be created with the net-snmp-config program: Stop the agent first, then create the initial user: $ $ SNMPv3 pass phrases must be at least 8 characters long. We have created a user “myuser” with a password of “my password” and using md5 for authentication and des for encryption. Very simple access control has been added to /usr/share/snmp/ snmpd.conf allowing the user write access to entire tree SNM — ver. 1.7 SNMP v3 — slide #32 Configuring usm Users — 2 Now start the agent, and test the user. First we test without encryption, then with encryption: $ $ $ SNMP Standards and RFCs The standards were updated in December 2002 – Most (all?) text books are out of date RFC 1155 RFC 1157 RFC 1212 RFC 1215 RFC 1901 RFC 2570 RFC 2578 RFC 2579 RFC 2580 SNMPv1 SMIv1 Concise MIB definitions SNMPv1 traps SNMPv2c Old SNMPv3 overview SMIv2 SMIv2 textual conventions SMIv2 conformance RFC 3411 RFC 3412 RFC RFC RFC RFC 3413 3414 3415 3416 SNMPv3 architecture SNMPv3 message processing SNMPv3 applications SNMPv3 USM SNMPv3 VACM SNMPv2 protocol operations SNMPv2 transport mappings SNMPv2 MIB SNMP configuring networks info SNMP coexistence v1 v2 v3 best practice Can create as many users as you like in this way. Better to improve access control using vacm over the default of write access everywhere SNM — ver. 1.7 SNMP v3 — slide #33 RFC 3417 RFC 3418 RFC 3512 RFC 3584 SNM — ver. 1.7 SNMP v3 — slide #35 Remotely Creating USM Users We clone the first user we created: $ References rfcs 3411–3415. Available http://www.rfc-editor.org. from many sites, including See the Net-SNMP FAQ, in /usr/share/doc/net-snmp-5.2.1/FAQ. Also see /usr/share/doc/net-snmp-5.2.1/README.snmpv3. William Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Third edition, Addison-Wesley, 1999, 0-201-48534-6. – Pages 526, 527 explain the context example from rfc 2271 well. Actually, the example is changed slightly in rfc 3411 David Zeltersman, A Practical Guide to SNMPv3 and Network Management, Prentice Hall, 1999, 0-13-021453-1. Stephen B. Morris, Network Management, MIBs and MPLs: Principles, Design and Implementation, Prentice Hall, 2003, 0-13-101113-8. We now have created user nicku with the same password as the “myuser” user. Now change the password: $ – See man snmpusm and man snmpcmd Can put account information into a local ∼/.snmp/snmp.conf that is readable only by you – See man snmp.conf SNM — ver. 1.7 SNMP v3 — slide #34 James Boney, Cisco IOS In a Nutshell, O’Reilly, January 2002, 1-56592-942-X. Douglas R. Mauro and Kevin J. Schmidt, Essential SNMP, O’Reilly, July 2001, 0-596-00020-0. SNM — ver. 1.7 SNMP v3 — slide #36