© 2007 Cisco Systems, Inc. All rights reserved.ISCW-Mod5_L9 1 Implementing Secure Converged Wide...

© 2007 Cisco Systems, Inc. All rights reserved.ISCW-Mod5_L9 1

Implementing Secure Converged Wide Area Networks (ISCW)


Lesson 9 – Module 5 – ‘Cisco Device Hardening’

Configuring SNMP


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:1. Managed devices

2. Agents

3. Network-management systems (NMSs)

1. 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.

2. 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.

3. 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:

1. GET REQUEST - used to retrieve a piece of management information.

2. GETNEXT REQUEST - used iteratively to retrieve sequences of management information.

3. GET RESPONSE - used agent responds with data to get and set requests from the manager.

4. SET REQUEST - used to initialise and make a change to a value of the network element.

5. 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

Model Level Authentication Encryption What Happens

v1 noAuthNoPriv Community String

No – Authenticates with a community string match

v2 noAuthNoPriv Community String

No – Authenticates with a community string match

v3 noAuthNoPriv Username No – Authenticates with a username

authNoPriv MD5 or SHA No – Provides HMAC MD5 or SHA algorithms for authentication

authPriv MD5 or SHA DES – Provides HMAC MD5 or SHA algorithms for authentication

– Provides DES 56-bit encryption in addition to authentication based on the CBC-DES (DES-56) standard

Definitions:• Security model is a security strategy used by the SNMP agent.

• Security level is the permitted level of security within a security model.


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

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

It is strongly recommend that all network management systems use SNMPv3 rather than SNMPv1 or SNMPv2


Configuring an SNMP Managed Node

These are the four configuration tasks used to set up SNMPv3 communications on a Cisco IOS router:

1. Configure the SNMP-server engine ID to identify the devices for administrative purposes

2. Configure the SNMP-server group names for grouping SNMP users

3. Configure the SNMP-server users to define usernames that reside on hosts that connect to the local agent

4. 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)

•snmp-server group groupname {v1 | v2c | v3 {auth | noauth | priv}} [read readview] [write writeview] [notify notifyview] [access access-list]

Router(config)#

• 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)

•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]

Router(config)#

• Configure a new user to an SNMP group

PR1(config)#snmp-server user John johngroup v3 auth md5 john2passwd PR1(config)#snmp-server user Bill billgroup v3 auth md5 bill3passwd des56

password2PR1(config)#snmp-server group johngroup v3 auth PR1(config)#snmp-server group billgroup v3 auth priv

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


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.



To be able to send an “inform,” perform these steps:

1. Configure a remote engine ID.

2. Configure a remote user.

3. Configure a group on a remote device.

4. Enable traps on the remote device.

5. Enable the SNMP manager.



snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]

Router(config)#

• Configures the recipient of an SNMP trap operation

PR1(config)#snmp-server engineID remote 10.1.1.1 1234PR1(config)#snmp-server user bill billgroup remote 10.1.1.1 v3PR1(config)#snmp-server group billgroup v3 noauthPR1(config)#snmp-server enable traps PR1(config)#snmp-server host 10.1.1.1 inform version 3 noauth billPR1(config)#snmp-server manager

The example (below) shows how to send configuration informs to the 10.1.1.1 remote host


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 privTrap_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 configTrap_sender(config)#snmp-server enable traps snmpTrap_sender(config)#snmp-server host 172.16.1.1 traps version 3 priv snmpuserTrap_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 privWalked_device(config)#snmp-server user snmpuser snmpgroup v3 auth md5 authpassword priv des56 encrypt password


Date post:	14-Dec-2015
Category:	Documents
Upload:	carmen-parmentier
View:	218 times
Download:	0 times

© 2007 Cisco Systems, Inc. All rights reserved.ISCW-Mod5_L9 1 Implementing Secure Converged Wide...

Documents