Vous êtes sur la page 1sur 7

SNMP

The Simple Network Management Protocol (SNMP) is used by many organizations to keep
a good management and monitoring capability for all their devices. SNMP can be used for a
number of different things, from the monitoring and triggering of alerts to device
configuration.
SNMP is broken down into three components:
SNMP manager: The SNMP manager controls and monitors the devices within the network
using SNMP.
SNMP agent: The SNMP agent is the component that is run directly on the device and
maintains data and reports this data (if needed) to the SNMP manager.
MIB: The Management Information Base (MIB) is a virtual information storage location
that contains collections of managed objects. Within the MIB, there are objects that relate to
different defined MIB modules
The use of these three components can make a network easy to monitor and maintain. To obtain
information from the MIB on the SNMP agent, several different operations can be used:
Get: Used to get information from the MIB from an SNMP agent
Set: Used to set information to the MIB from an SNMP manager
Walk: Used to list information from successive MIB objects within a specified MIB
Trap: Used by the SNMP agent to send a triggered piece of information to the SNMP manager
Inform: The same as a trap, but adds an acknowledgment that is not provided with a trap.
There are also three main versions of SNMP that have been defined:
Version 1: This version was defined in RFC 1157 and utilizes community-based security.
Version 2c: This version was defined in RFCs 1901, 1905, and 1906 and utilizes communitybased security. Version 2c added some additional protocol operations and data types to version
1; these include a bulk retrieval mechanism.
Version 3: This version was defined in RFCs 3413 through 3415 and defines a new security
model that includes features that support message integrity, authentication and, encryption.
The community-based security method is known to be a large security vulnerability to
versions 1 and 2 because of its lack of encryption and authentication (other than a simple
community name). While the configuration of SNMP version 3 is more intensive, it should be
preferred when traffic is routed over untrusted networks.

Basic SNMP Parameter Configuration


The first things that are configured on a device include the system contact, device location,
and device serial number. The first SNMP command, which is used automatically, enables the
SNMP agent on the device.

SNMP View Configuration


To limit the amount of information that is available for those accessing the MIB objects on
a device, a view can be configured. A view is configured with the MIB objects that are allowed
(or disallowed) to be accessed by a specific community or group. It is through the configuration
of multiple view entries that the access control of the MIB objects is controlled.
Create and configure an SNMP view
Router(config)# snmp-server view <view-name> <oid-tree> [included | excluded]
Display information about the currently configured SNMP views
Router# show snmp view
SNMP Community Configuration (Versions 1 and 2c)
With SNMP versions 1 and 2c, a community string is used as the only form of
authentication. When configuring a community string, specific privileges can be given to those
authenticating with the correct string. Access can be given broadly with global read-only
and global read-write access as well as more specifically with an existing SNMP view. Access
to the SNMP agent can also be restricted through the use of a standard IP access list.
Create and configure an SNMP community
Router(config)# snmp-server community string [view view-name] [ro | rw] [access-list-number]
Display information about the currently configured SNMP communities
Router# show snmp community
SNMP V3
The configuration of SNMP version 3 is different from that of the other versions because
the security mechanism is much more complex and offers a much higher level of security.
Security is configured through the creation of users and groups; the groups are given access to
specific SNMP MIB objects through views, and the users are assigned to specific groups.
Version 3 also supports the use of both authentication (MD5 or Secure Hash Algorithm
[SHA]) and encryption (Data Encryption Standard [DES], Triple DES [3DES], or Advanced
Encryption Standard [AES]) of SNMP traffic. Users can be set up on the local device and/or on
the remote management server. The security digests required for authenticating and
encrypting packets utilize an EngineID that is automatically generated on the local device
(local EngineID) but is required to be configured for each remote device/remote management

server when exchanging packets (remote EngineID). Remote users can also be configured, but
the remote EngineID is required before these users can be created to ensure proper security
exchange information. These are the commands that are required to create and configure SNMPv3
users and groups.
Create and configure an SNMP v3 group.
Router(config)# snmp-server group group-name {v3 {auth | noauth | priv}} [read read-view]
[write write-view] [notify notify-view] [access [acl-number | acl-name]]
Create and configure an SNMP v3 user
Router(config)# snmp-server user <username> <group-name> [remote host [udp-port port]]
{v3 [encrypted] [auth {md5 | sha} auth-password]} [priv {des | 3des | aes {128 |
192 | 256}} privpassword]
Configure the local EngineID
Router(config)# snmp-server engineID local engineid-string
Configure a remote EngineID
Router(config)# snmp-server engineID remote {ipv4-ip-address | ipv6-address}[udp-port udpport-number]vengineid-string
Display the currently configured SNMP groups
Router# show snmp group
Display the currently configured SNMP users
Router# show snmp user
Display the currently configured EngineIDs
Router# show snmp engineID
Basic Notification Configuration
One of the main capabilities with SNMP is the ability to have the devices send messages
to a central server for recording purposes or to alert a device of a problem. These messages
can be in the form of a trap or inform; the difference between the two is that an inform
requires an acknowledgment from the server while a trap does not. An SNMP version 3 inform
also requires that a remote EngineID is configured to ensure that the acknowledgment
security information is able to be correctly calculated.
Configure a remote SNMP v3 user
Router(config)# snmp-server user username group-name remote host [udp-port port]{v3
[encrypted] [auth {md5 | sha} auth-password]} [priv {des | 3des | aes {128 | 192
|256}} privpassword]
Configure an SNMP notification host (trap or inform)
Router(config)# snmp-server host {hostname | ipaddress} [traps | informs] [version {1 | 2c | 3
[auth | noauth | priv]}] {community-string | username}[udp-port port] [notification-type]
Configure the notification types to be sent in a trap or inform (this command works with both traps

and informs; the configuration of the snmp-server host command dictates which type is sent)
Router(config)# snmp-server enable traps [notificationtype]
Display the currently configured notification hosts
Router# show snmp host
CPU and Memory Thresholding
One of the ways to monitor whether an attack is occurring on a device is through the simple
monitoring of device resources, including CPU and memory utilization. This is done by configuring
the use of CPU or memory threshold monitoring. Both of these features can be combined with a
remote management server to notify an organization when the CPU and memory conditions on a
device become critical.
CPU Thresholding Configuration
The configuration of CPU thresholding utilizes two different types of threshold: rising and
falling. The rising threshold is triggered when the CPU utilization exceeds a configured threshold. A
falling threshold is triggered when the CPU utilization falls back below a configured threshold.
Configure the use of a rising (and falling, if needed) CPU threshold
Router(config)# process cpu threshold type {total | process | interrupt} percentage
interval seconds [falling fall-percentage interval seconds]
Configure the use of an SNMP trap (or inform) should a CPU threshold message be triggered
Router(config)# snmp-server enable traps cpu threshold
Memory Threshold Configuration
The memory threshold feature also has two different options that can be configured. These
include an ability to trigger a message when the device memory goes below a configured level
and/or the ability to reserve an amount of memory to be used for critical notifications.
Configure the use of a memory threshold message should the device memory go below the
configured level
Router(config)# memory free low-watermark {processor <threshold> | io <threshold>}
Configure a memory reserve that is used to ensure that critical notifications can be sent
Router(config)# memory reserve critical <kilobytes>
Cisco IOS Flexible Packet Matching (FPM)
Networks are experiencing increasing sophisticated attacks that require mitigating tools that
are as flexible as possible. Cisco IOS Flexible Packet Matching (FPM) is a set of classes and
policies that provides pattern matching capability for more granular and customized packet filters
for Layer 2 to 7bit/byte matching capability deep into the packet at any offset within the packet
header and payload.
It is a powerful, easy, and rapid deployment mechanism that enables users to specify criteria
to match against any part of a packet (header and payload) and define the action to take. In short,
FPM is able to classify a packet based on its characteristics and take appropriate action.
Why Needed
There are three main reasons for Cisco IOS Flexible Packet Matching (FPM):
Sophisticated attacks: characteristics of common attacks have evolved beyond current filtering
tools like ACLs (i.e. limited matching criteriaprotocol, port, ip address, etc.)
Rapid Mitigation: customers must stop attacks immediately without waiting for a vendor to

develop a signature or new code (i.e. IPS or ACL).


Finer Granularity: goes beyond static attributes allowing you to specify arbitrary bits/bytes at
any offset within the entire packet (header or payload), minimizing inadvertent blocking of
legitimate business traffic
How does FPM Work
Cisco IOS Flexible Packet Matching (FPM) uses the following characteristics to ensure users
successfully mitigate attacks.
Is a stateless solution and inspects one packet at a time.
Matches on all static packet characteristics like protocol, port, IP address.
Uses a Protocol Header Description File (PHDF) that allows the user to define a class match
criteria based on any field in the protocol header.
Supports an offset, size and string keywords, and regular expressions (regex) to allow the user to
match on strings or bytes in the packet payload.
Uses class-map and policy-map configuration syntax to specify the protocol stack, the match
criteria and action to take
Restrictions
The following restrictions apply when using Cisco IOS Flexible Packet Matching (FPM):
Since Cisco IOS Flexible Packet Matching (FPM) is stateless, it cannot keep track of port
numbers being used by protocols that dynamically negotiate ports. Thus, when using FPM, port
numbers must be explicitly specified.
Cisco IOS Flexible Packet Matching (FPM) does not keep track of the connection state and so
no connection attributes are retained.
Cisco IOS Flexible Packet Matching (FPM) cannot perform IP fragmentation or TCP flow
reassembly.
Cisco IOS Flexible Packet Matchings PHDFs describe protocols with static fields and lengths.
Prior to 12.4(15)T, FPM supports searching for patterns up to 32 bytes long within the first 256
bytes of the packet. After 12.4(15)T, FPM supports searching for patterns up to 256 bytes long
anywhere within the entire packet.
Steps to Configure Cisco IOS Flexible Packet Matching (FPM)
These steps required to create an FPM policy using IOS command-line interface (CLI). It
contains the following steps:
Step 1. Load the protocol header description file(s) (PHDF)
Step 2. Define the protocol stack (IP-UDP, IP-TCP, etc.)
Step 3. Define FPM match criteria filter (class-map)
Step 4. Define action to take on classes (Policy-map)
Step 5. Apply service policy to an interface
1. Load the Protocol Header Description File
The first step is to load the protocol header description file (PHDF) into router memory. A
PHDF is an XML file that allows the user to take advantage of the flexibility of XML to describe
almost any protocol header.
PHDFs are analogous to stencils. A PHDF outlines the structure of packets in an XML
format thus allowing IOS to understand the protocol and the packet structure. The field names that
are defined within the PHDFs are used for defining the packet filters.
The IP PHDF defines the header field names (i.e. Version, IHL, TOS, etc), the length of
the fields and the location of the fields within the packet. The PHDFs simplifies FPM
configurations by allowing the users to reference the field names described in the PHDF instead of
having to define the actual offsets within the packet in the routers configuration.
Although users can write their own custom PHDFs, it is recommended that users use the files

published on http://www.cisco.com/cgi-bin/tablebuild.pl/fpm since they suffice for most situations.


Note: If using an image prior to 12.4(11)T, then you must download the PHDF files to your
router flash. Images after 12.4(11)T have the PHDFs built into IOS.
To load the PHDF, enter the following command at the router configure terminal prompt.
load protocol location{system | flash | disk#}: filename { ether.phdf | ip.phdf | tcp.phdf | udp.phdf |
icmp.phdf | ipv6.phdf}

2. Define Protocol Stack (Class-map Type Stack)


The second step is to define the protocol stack using class maps. The stack class allows us
to logically define protocol relationships. In this step, the class map type stack should be defined.
class-map [type {stack | access-control}] class-map-name [match-all | match-any]
Router(config)# class-map type stack ip-udp match-all match field protocol protocol-field {eq
[mask] | neq [mask] | gt | lt | range range | regex string} value [next next-protocol]
example
Router(config-cmap)# match field ip protocol eq 0x11 next udp
3. Define Cisco IOS Flexible Packet Matching (FPM) Match Criteria Filter
The third step is to define the Cisco IOS Flexible Packet Matching (FPM) match criteria
filter using class maps. The access-control class allows us to describe granular details about a
particular packet. In this step, the class map type access-control should be defined along with the
match criteria.
Cisco IOS Flexible Packet Matching (FPM) is a packet classification feature that allows
users to define one or more classes of network traffic by pairing standard matching operators with
userdefined protocol header fields.
class-map [type {stack | access-control}] class-map-name [match-all | match-any]
Router(config)# class-map type access-control slammer match-all
description character-string
Router(config-cmap)# description "match on slammer packets"
match field protocol protocol-field {eq [mask] | neq [mask] | gt | lt | range range | regex string}
value [next next-protocol]
Router(config-cmap)# match field udp dest-port eq 1434

match start {l2-start | l3-start} offset number size number {eq | neq | gt | lt | range range | regex

string} value [value2]


Router(config-cmap)# match start l3-start offset 224 size 4 eq 0x4011010
4. Define Action to Take on Classes (Policy-map type access-control)
The fourth step is to create the hierarchical Cisco IOS Flexible Packet Matching (FPM)
policy that defines the action to take on classes. A policy includes the policy map; that is, after a
class map has been defined, a policy map is needed to bind the match to an action. A policy map is
an ordered set of classes and associated actions, such as drop, log, or send ICMP unreachable.
policy-map [type access-control] policy-map-name
Router(config)# policy-map type access-control fpm-udp-policy
description character-string
Router(config-pmap)# description "policy for UDP based attacks"
class class-name [insert-before class-name]
Router(config-pmap)# class slammer
[drop | log | send-response | service-policy]
Router(config-pmap)# drop
Chain the first policy with its class to the stack class:
Router(config)# policy-map type access-control fpm-policy
Router(config-pmap)# class ip_udp
service-policy policy-map-name
Router(config-pmap-c)# service policy fpm-udp-policy
5. Apply Service Policy to an Interface
To apply the policy on an interface, issue the following the commands:
interface type name
Router(config)# interface gigabitEthernet 0/1
service-policy [type access-control] {input | output} policy-map-name
Router(config-if)# service-policy type access-control input fpm-policy
Show Commands and References:
show policy-map interface [type access-control] interface-name [input | output ]
Router# show policy-map interface type access-control interface gigabit 0/1
To track all FPM events, enter the following command at the router prompt.
debug fpm event
Router#debug fpm event

Vous aimerez peut-être aussi