Network Management (NETW-1001)

Transcription

1 Network Management (NETW-1001) Dr. Mohamed Abdelwahab Saleh IET-Networks, GUC Spring 2017

2 TOC 1 SNMPv2 and SNMPv3

3 SNMPv2 More Operations SNMPv1 defines the GET, GETNEXT, SET, GETRESPONSE, and TRAP PDUs. SNMPv2 was developed to increase the functionality of SNMP. On top of the previous PDU types it defines some new PDUs such as the GETBULK, NOTIFICATION, INFORM PDUs. It also defines a new version of the Structure of Management Information called SMIv2, so that the syntax of MIBs is enhanced.

4 GETBULK PDU Has a similar behavior as the GETNEXT PDU. However: We can define how many objects that are lexicographically greater than the ones listed in the PDU are retrieved. For instance, we can specify that the values of the next 10 objects in the lexicographic ordering should be read. Contrast this to GETNEXT which reads the value of the 1 next object. The agent will send as many values as it can without exceeding the maximum PDU size of the GETRESPONSE PDU.

5 Notifications and Informs In SNMP v2 notifications are either traps or informs. Traps are PDUs sent from agent to manager to supply it with some important information. Traps are defined in MIBs. In SNMPv2, informs are acknowledged traps. When an agent sends an inform request (trap requiring acknowledgment) it waits for a response PDU. Retransmission occurs, up to a certain maximum count, when no acknowledgment is received.

6 SNMPv3 More Security SNMPv2 was never developed into a full standard because of disagreement on security features. SNMPv1 used community strings (passwords) to control access rights of user groups. Access rights such as read-only or read-write were defined. Groups of users were assigned community strings, a user supplying a certain community string to the SNMP agent was granted the rights corresponding to this string. However, community strings were sent in clear text which compromises the whole process. SNMPv3 does not define more functionalities for SNMP, but it defines a new security model.

7 SNMP Entities In SNMPv3, both agents and managers are called SNMP entities, the following is a functional block diagram for SNMP entities. SNMP entity SNMP Engine Dispatcher Message processing Security Access control Command generator Applications Notification receiver Proxy forwarder Command responder Notification generator Other

8 Functional Blocks of SNMP Entities Conceptually, a SNMP entity, contains a processing part (the engine) and a communication part (the applications) The communication part contains blocks that are responsible for sending and receiving messages. The engine part contains blocks responsible for further processing of the data in messages. The security and the access control blocks are responsible for the implementation of the security features in SNMPv3. SNMPv3 provides both authentication and privacy features.

9 Authentication and Privacy Authentication in SNMPv3 aims at providing assurance about the identity of SNMP entities during communication. Authentication features are implemented in order to prevent impersonation attacks, i.e., an entity pretending to be another entity. Also, authentication aims at preventing attackers from changing message data, i.e., variable bindings in a SET PDU. However it does not prevent the attackers from reading the data. Privacy features in SNMPv3 aims at protecting the secrecy of message data, i.e., preventing attackers from reading data. For authentication, SNMP entities sign the hash value of messages. For privacy, SNMP entities encrypt message data.

10 SNMPv3 Security Levels SNMPv3 defines three security levels numbered 1, 2, and 3: 1. No Authentication No privacy: No security features are used. 2. Authentication No Privacy: Authentication is used, namely by digitally signing a MD5 or SHA-1 hash value of the message. 3. Authentication Privacy: Both authentication and privacy features are used, where authentication is achieved by using digital signatures as explained above. Privacy is achieved by encrypting the message using the DES in CBC mode. The security level used during communication depends on the system configuration as will be seen.

11 Messages and Security Levels A m m, signature A (hash(m)) encrypt K (m), signature A (hash(m)) B No Authentication No privacy Authentication No privacy Authentication privacy

12 Security in SNMPv3 The Big Picture Users, objects, and rights. The use of signatures and encryption necessitates the storage of user names and their associated keys. For this, SNMPv3 uses a User-based Security Model (USM). Also, we need to group managed objects into groups for which we grant access to users according to rues. For this, SNMPv3 uses a View-based Access Control Model (VACM). An MIB view is a collection of objects. It is composed of a family of view subtrees. We need to decide which user has access to which views. For this we use a table that stores user rights. It contains the views for which the user has read rights, the views for which the user has write rights, and, finally, the views for which the user has notify rights.

13 Storing User Information Each SNMP entity has a table called usmusertable. It stores information about other SNMP entities in the network. The table contains the following columns: Username: The name used by the entity in communications to identify itself. Authentication protocol: The authentication (signature) protocol used by this Username it can be nil, or HMAC with MD5 or HMAC with SHA-1. Authentication key: The key used by HMAC. Privacy protocols: The encryption protocol used by Username. It can be nil, or DES. Privacy key: The key used in DES encryption.

14 Defining Views A view is a collection of managed objects to which access rights are granted. A view is composed of view subtrees, where view subtrees are defined by a combination of an OID called the family subtree and a mask. Views are defined in a table called vacmviewtreefamilytable. The first three columns with some example data are shown below: Family view name Family subtree Family mask important public theview none An object M belongs to a certain view if: 1. The OID of M contains at least the same number of subidentifiers as the OID of the family subtree. 2. The OID of M matches the OID of the family subtree at all positions (subidentifiers) where the mask bit equals 1.

15 Views and Objects Notes: An object may belong to more than one view. If the mask is shorter than the OID of the family subtree it is implicitly appended by 1 s. If the mask is not present, it is implicitly considered to be all 1 s. Example: Family view name Family subtree Family mask important public myview none In the following X means a don t care, i.e., can be any number: important contains all objects whose OID starts with public contains all objects whose OID starts with X.9 myview contains all objects whose OID starts with

16 Storing Users Rights to Views Now, we defined users and views. So, which user can access which view? and what is the mode of access? This information is stored in the vacmaccesstable. Some columns with example data are shown: User name Read view name Write view name Notify view name A important public public B important important myview The table above means that, for instance user A can access objects in the view called important in read-mode and objects in the view called public in write-mode, etc.

17 Security in Action Imagine the following scenario, where a NMS N wants to set the value of an object instance using agent A, suppose the NMS is used by user U, and U uses authentication and no privacy: 1 N A: U, sign U (hash(set(..., OID of object instance))), SET(..., OID of object instance) 2 A looks for the username U in the usmusertable to find out U s key and verify U s signature. 3 A looks in the vacmviewtreefamilytable to find out the view that the object belongs to. 4 A looks in the vacmaccesstable to find out if U has write access to the view. 5 Suppose U has write access. A sets the value according to request. 6 A N: sign A (GETRESPONSE(..., OID of object instance)), GETREPONSE(..., OID of object instance) 7 N looks for the username A in the usmusertable to find out A s key and verify A s signature.