Implementing Secure Converged Wide Area Networks (ISCW)

Lesson 9 – Module 5 – ‘Cisco Device Hardening’ Configuring SNMP Lesson 9 – Module 5 – ‘Cisco Device Hardening’

Module Introduction The open nature of the Internet makes it increasingly important for businesses to pay attention to the security of their networks. As organisations move more of their business functions to the public network, they need to take precautions to ensure that attackers do not compromise their data, or that the data does not end up being accessed by the wrong people. Unauthorised network access by an outside hacker or disgruntled employee can wreak havoc with proprietary data, negatively affect company productivity, and stunt the ability to compete. Unauthorised network access can also harm relationships with customers and business partners who may question the ability of companies to protect their confidential information, as well as lead to potentially damaging and expensive legal actions.

Objectives At the completion of this ninth lesson, you will be able to: Describe the concepts behind the use of SNMP Explain the various SNMP actions Explain why the use of SNMP v1 and 2 is not recommended Demonstrate how to configure Cisco routers to use SNMPv3

SNMP SNMP – the Simple Network Management Protocol - forms part of the internet protocol suite as defined by the IETF SNMP is used by network management systems to monitor network-attached devices for conditions that warrant administrative attention It consists of a set of standards for network management, including an Application Layer protocol, a database schema, and a set of data objects The current version is SNMPv3 SNPv1 and v2 are considered obsolete, and are extremely insecure. It is recommended they NOT be used on a publicly attached network

SNMP Components An SNMP-managed network consists of three key components: Managed devices Agents Network-management systems (NMSs) A managed device is a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices can be routers and access servers, switches and bridges, hubs, computer hosts, or printers. An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. An NMS executes applications that monitor (and possibly control) managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network. Ref: Wikepedia - SNMP

SNMP Managed Network

SNMPv1 and SNMPv2 Architecture SNMP asks agents embedded in network devices for information or tells the agents to do something.

SNMP Actions The SNMP protocol specifies (in version 1) five core PDUs: GET REQUEST - used to retrieve a piece of management information. GETNEXT REQUEST - used iteratively to retrieve sequences of management information. GET RESPONSE - used agent responds with data to get and set requests from the manager. SET REQUEST - used to initialise and make a change to a value of the network element. TRAP - used to report an alert or other asynchronous event about a managed subsystem. In SNMPv1, asynchronous event reports are called traps while they are called notifications in later versions of SNMP.

SNMP Actions Other PDUs were added in later versions, including: GETBULK REQUEST - a faster iterator used to retrieve sequences of management information. INFORM - an acknowledged trap. Typically, SNMP uses UDP ports 161 for the agent and 162 for the manager. The Manager may send Requests from any available ports (source port) to port 161 in the agent (destination port). The agent response will be given back to the source port. The Manager will receive traps on port 162. The agent may generate traps from any available port.

Community Strings SNMPv1 and SNMPv2 use a community string to access router SNMP agents SNMP community strings act like passwords An SNMP community string is a text string used to authenticate messages between a management station and an SNMP engine If the manager sends one of the correct read-only community strings, the manager can get information but NOT set information in an agent If the manager uses one of the correct read-write community strings, the manager can get or set information in the agent

Community Strings In effect, having read-write access is equivalent to having the enable password! SNMP agents accept commands and requests only from SNMP systems that use the correct community string. By default, most SNMP systems use a community string of “public” If the router SNMP agent is configured to use this commonly known community string, anyone with an SNMP system is able to read the router MIB Router MIB variables can point to entities like routing tables and other security-critical components of a router configuration, so it is very important that custom SNMP community strings are created

SNMP Security Models and Levels Definitions: Security model is a security strategy used by the SNMP agent. Security level is the permitted level of security within a security model. Model Level Authentication Encryption What Happens v1 noAuthNoPriv Community String No Authenticates with a community string match v2 v3 Username Authenticates with a username authNoPriv MD5 or SHA Provides HMAC MD5 or SHA algorithms for authentication authPriv DES Provides DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard

SNMPv3 Operational Model

SNMPv3 Operational Model The concepts of separate SNMP agents and SNMP managers do not apply in SNMPv3 SNMP combines these concepts into single SNMP entities Each managed node and the network management system (NMS) is a single entity There are two types of entities, each containing different applications: Managed node SNMP entities: The managed node SNMP entity includes an SNMP agent and an SNMP MIB. The agent implements the SNMP protocol and allows a managed node to provide information to the NMS and accept instructions from the NMS. The MIB defines the information that can be collected and used to control the managed node. Information that is exchanged using SNMP takes the form of objects from the MIB SNMP NMS entities: The SNMP entity on an NMS includes an SNMP manager and SNMP applications. The manager implements the SNMP protocol and collects information from managed nodes and sends instructions to the nodes. The SNMP applications are software applications used to manage the network

SNMPv3 Features and Benefits It is strongly recommend that all network management systems use SNMPv3 rather than SNMPv1 or SNMPv2 Features Message integrity: Ensures that a packet has not been tampered with in transit Authentication: Determines that the message is from a valid source Encryption: Scrambles the contents of a packet to prevent the packet from being seen by an unauthorised source Benefits Data can be collected securely from SNMP devices without fear of the data being tampered with or corrupted Confidential information, such as SNMP Set command packets that change a router configuration, can be encrypted to prevent the contents from being exposed on the network

Configuring an SNMP Managed Node These are the four configuration tasks used to set up SNMPv3 communications on a Cisco IOS router: Configure the SNMP-server engine ID to identify the devices for administrative purposes Configure the SNMP-server group names for grouping SNMP users Configure the SNMP-server users to define usernames that reside on hosts that connect to the local agent Configure the SNMP-server hosts to specify the recipient of a notification operation (trap or inform)

Configuring the SNMP-Server Engine ID (1) To configure a name for either the local or remote SNMP engine on the router, use the snmp-server engineID global configuration command. The SNMP engine ID is a unique string used to identify the device for administration purposes. An engine ID is not required for the device as a default string is generated using a Cisco enterprise number (1.3.6.1.4.1.9) and the MAC address of the first interface on the device. If an individualised ID is required do not specify the entire 24-character engine ID if the ID contains trailing zeros. Specify only the portion of the engine ID up to the point at which only zeros remain in the value. This portion must be 10 hexadecimal characters or more. For example, to configure an engine ID of 123400000000000000000000, specify snmp-server engineID local 1234000000.

Configuring the SNMP-Server Engine ID (1) A remote engine ID must be created when an SNMPv3 inform is configured The remote engine ID is used to compute the security digest for authenticating and encrypting packets that are sent to a user on the remote host Informs are acknowledged traps. The agent sends an inform to the manager. When the manager receives the inform, the manager sends a response to the agent. Thus, the agent knows that the inform reached the intended destination.

Configuring the SNMP-Server Group Names (2) To configure a new SNMP group, or a table that maps SNMP users to SNMP views, use the snmp-server group global configuration command This command groups SNMP users that reside on hosts that connect to the local SNMP agent An SNMP view is a mapping between SNMP objects and the access rights that are available for those objects An object can have different access rights in each view Access rights indicate whether the object is accessible by either a community string or a user

Configuring the SNMP-Server Group Names (2) Router(config)# snmp-server group groupname {v1 | v2c | v3 {auth | noauth | priv}} [read readview] [write writeview] [notify notifyview] [access access-list] Configures a new SNMP group or a table that maps SNMP users to SNMP views PR1(config)#snmp-server group johngroup v3 auth PR1(config)#snmp-server group billgroup v3 auth priv The top example shows how to define a group johngroup for SNMP v3 using authentication but not privacy (encryption) The bottom example shows how to define a group billgroup for SNMP v3 using both authentication and privacy

Configuring the SNMP-Server Users (3) To add a new user to an SNMP group, use the snmp-server user global configuration command To configure a user that exists on a remote SNMP device, specify the IP address or port number for the remote SNMP device where the user resides Also, before configuring remote users for that device, configure the SNMP engine ID using the command snmp-server engineID with the remote option The SNMP engine ID of the remote device is needed to compute the authentication and privacy digests from the password If the remote engine ID is not configured first, the configuration command will fail

Configuring the SNMP-Server Users (3) Configure a new user to an SNMP group Router(config)# snmp-server user username groupname [remote ip-address [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password [priv des56 priv-password]]} [access access-list] The first example (below) shows how to define a user John belonging to the group johngroup. Authentication uses the password john2passwd and no privacy (no encryption) is applied. The second example shows how user Bill, belonging to the group billgroup, is defined using the password bill3passwd and privacy (encryption) is applied PR1(config)#snmp-server user John johngroup v3 auth md5 john2passwd PR1(config)#snmp-server user Bill billgroup v3 auth md5 bill3passwd des56 password2 PR1(config)#snmp-server group johngroup v3 auth PR1(config)#snmp-server group billgroup v3 auth priv

Configuring the SNMP-Server Hosts (4) To specify the recipient of an SNMP notification operation, use the snmp-server host global configuration command. snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when the receiver receives traps The sender cannot determine if the traps were received An SNMP entity that receives an inform request acknowledges the message with an SNMP response PDU. Informs consume more computing resources in the agent and in the network. If an snmp-server host command is NOT entered, no notifications are sent. To configure the router to send SNMP notifications, at least one snmp-server host command must be entered If the command is entered with no keywords, all trap types are enabled for the host.

Configuring the SNMP-Server Hosts (4) To be able to send an “inform,” perform these steps: Configure a remote engine ID. Configure a remote user. Configure a group on a remote device. Enable traps on the remote device. Enable the SNMP manager.

Configuring the SNMP-Server Hosts (4) Configures the recipient of an SNMP trap operation Router(config)# snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] The example (below) shows how to send configuration informs to the 10.1.1.1 remote host PR1(config)#snmp-server engineID remote 10.1.1.1 1234 PR1(config)#snmp-server user bill billgroup remote 10.1.1.1 v3 PR1(config)#snmp-server group billgroup v3 noauth PR1(config)#snmp-server enable traps PR1(config)#snmp-server host 10.1.1.1 inform version 3 noauth bill PR1(config)#snmp-server manager

SNMP – Types of Traps Trap Description bgp Sends Border Gateway Protocol (BGP) state change traps. config Sends configuration traps. hsrp Sends Hot Standby Router Protocol (HSRP) notifications. sdlc Sends Synchronous Data Link Control (SDLC) traps. snmp Sends SNMP traps defined in RFC 1157. syslog Sends error message traps (Cisco Syslog MIB). Specify the level of messages to be sent with the logging history level command. tty Sends Cisco enterprise-specific traps when a TCP connection closes. x25 Sends X.25 event traps.

SNMPv3 Configuration The next slide shows how to configure Cisco IOS routers for SNMPv3. The router Trap_sender is configured to send traps to the NMS host with the IP address 172.16.1.1. The traps are encrypted using the credentials that are configured for the local user snmpuser who belongs to the group snmpgroup. The Trap_sender router sends traps that are related to CPU, configuration, and SNMP. The trap packets are sourced from the router loopback 0 interface The router Walked_device is configured so that the NMS host can read the MIBs on the local device. The NMS server needs to use the username credentials that are configured on the Walked_device (snmpuser with respective authentication and encryption passwords) to gain access to the SNMP information of the router

SNMPv3 Configuration Example Trap_sender(config)#snmp-server group snmpgroup v3 auth Trap_sender(config)#snmp-server group snmpgroup v3 priv Trap_sender(config)#snmp-server user snmpuser snmpgroup v3 auth md5 authpassword priv des56 encryptpassword Trap_sender(config)#snmp-server enable traps cpu Trap_sender(config)#snmp-server enable traps config Trap_sender(config)#snmp-server enable traps snmp Trap_sender(config)#snmp-server host 172.16.1.1 traps version 3 priv snmpuser Trap_sender(config)#snmp-server source-interface traps loopback 0 Walked_device(config)#snmp-server group snmpgroup v3 auth Walked_device(config)#snmp-server group snmpgroup v3 priv Walked_device(config)#snmp-server user snmpuser snmpgroup v3 auth md5 authpassword priv des56 encrypt password