Module 6 Device Monitoring and Management

Secure Cisco IOS Image and Configuration Files

6.1.1 Cisco IOS Resilient Configuration Feature

The Cisco IOS resilient configuration feature allows for faster recovery if someone maliciously or
unintentionally reformats flash memory or erases the startup configuration file in nonvolatile
random-access memory (NVRAM). The feature maintains a secure working copy of the router IOS
image file and a copy of the running configuration file. These secure files cannot be removed by the
user and are referred to as the primary bootset.

Here are a few facts about the Cisco IOS resilient configuration:

 The configuration file in the primary bootset is a copy of the running configuration that was
in the router when the feature was first enabled.

 The feature secures the smallest working set of files to preserve persistent storage space.

 No extra space is required to secure the primary Cisco IOS image file. The feature
automatically detects image or configuration version mismatch.

 Only local storage is used for securing files, eliminating scalability maintenance challenges
from storing multiple images and configurations on TFTP servers.

 The feature can be disabled only through a console session.

Note: The feature is only available on older routers that support a PCMCIA Advanced Technology
Attachment (ATA) flash interface. Newer routers such as the ISR 4000 do not support this feature.

6.1.2 Enable the IOS Image Resilience Feature

The commands to secure the IOS image and running configuration file are shown in the example. To
secure the IOS image and enable Cisco IOS image resilience, use the secure boot-image global
configuration mode command. When enabled for the first time, the running Cisco IOS image is
secured and a log entry is generated. The Cisco IOS image resilience feature can only be disabled
through a console session using the no form of the command. This command functions properly only
when the system is configured to run an image from a flash drive with an ATA interface. Additionally,
the running image must be loaded from persistent storage to be secured as primary. Images that are
loaded from a remote location, such as a TFTP server, cannot be secured.

To take a snapshot of the router running configuration and securely archive it in persistent storage,
use the secure boot-config global configuration mode command, as shown in the figure. A log
message is displayed on the console notifying the user that configuration resilience is activated. The
configuration archive is hidden and cannot be viewed or removed directly from the CLI prompt. You
can use the secure boot-config command repeatedly to upgrade the configuration archive to a
newer version after new configuration commands have been issued.

Secured files do not appear in the output of a dir command that is issued from the CLI. This is
because the Cisco IOS file system prevents secure files from being listed. The running image and
running configuration archives are not visible in the dir command output. Use the show secure
bootset command to verify the existence of the archive, as shown in the figure.
6.1.3 The Primary Bootset Image

Restore a primary bootset from a secure archive after the router has been tampered with, as shown
in the following steps and example:

Step 1. Reload the router using the reload command. If necessary, issue the break sequence to enter
ROM monitor (ROMmon) mode.

Step 2. From ROMmon mode, enter the dir command to list the contents of the device that contains
the secure bootset file.

Step 3. Boot the router with the secure bootset image using the boot command followed by the
flash memory location (e.g. flash0), a colon, and the filename found in Step 2.

Step 4. Enter global configuration mode and restore the secure configuration to a filename of your
choice using the secure boot-config restore command followed by the flash memory location (e.g.
flash0), a colon, and a filename of your choice. In the figure, the filename rescue-cfg is used.

Step 5. Exit global configuration mode and issue the copy command to copy the rescued
configuration file to the running configuration.
6.1.4 Configure Secure Copy

The Cisco IOS Resilient feature provides a method for securing the IOS image and configuration files
locally on the device. The Secure Copy Protocol (SCP) feature is used to remotely copy these files.
SCP provides a secure and authenticated method for copying router configuration or router image
files to a remote location.

SCP relies on:

 SSH to secure communication

 AAA to provide authentication and authorization

Note: AAA configuration will be covered in greater detail in a later chapter.

Use the following steps to configure a router for server-side SCP with local AAA:

Step 1. Configure SSH, if not already configured.

Step 2. For local authentication, configure at least one local database user with privilege level 15.

Step 3. Enable AAA with the aaa new-model global configuration mode command.

Step 4. Use the aaa authentication login default local command to specify that the local database be
used for authentication.

Step 5. Use the aaa authorization exec default local command to configure command authorization.
In this example, all local users will have access to EXEC commands.

Step 6. Enable SCP server-side functionality with the ip scp server enable command.
In the example, R1 is now an SCP server and will use SSH connections to accept secure copy transfers
from authenticated and authorized users. Transfers can originate from any SCP client whether that
client is another router, switch, or workstation.

R1(config)# ip domain-name span.com

R1(config)# crypto key generate rsa general-keys modulus 2048

R1(config)# username Bob privilege 15 algorithm-type scrypt secret cisco12345

R1(config)# aaa new-model

R1(config)# aaa authentication login default local

R1(config)# aaa authorization exec default local

R1(config)# ip scp server enable

Now assume that we want to securely copy the backup configuration of a router named R2 to the
SCP server, which is R1. As shown in the command output below, we would use the copy command
on R2, and specify specify the source file location first (flash0:R2backup.cfg), and then the
destination (scp:). After answering the series of prompts to establish a connection to the SCP server
on R1, the file will be copied.

On R1, you can enter the debug ip scp command to watch the transfer proceed, as shown in the
following example. The most common authentication issue is an incorrect username/password
combination. There is also an authentication failure if the username/password combination was not
configured with the privilege 15 keyword on the SCP server.

6.1.5 Recover a Router Password

If a router is compromised or needs to be recovered from a misconfigured password, an

administrator must use password recovery procedures, such as those shown in the steps below. For
security reasons, password recovery requires the administrator to have physical access to the router
through a console cable. Depending on the device, the detailed procedure for password recovery
varies.
Step 1. Connect to the console port.

Step 2. Use the show version command to display the configuration register setting and document
the value (e.g., 0x2102).

Step 3. Power cycle the router.

Step 4. Issue the break sequence (e.g., CTRL-BREAK) to enter ROMMON mode.

Step 5. Change the default configuration register with the confreg 0x2142 command.

Step 6. Reboot the router by using the reset command in ROMMON mode.

Step 7. Press Ctrl-C to skip the initial setup procedure.

Step 8. Enter privileged EXEC mode.

Step 9. Copy the startup configuration to the running configuration using the copy startup-config
running-config command.

Step 10. Verify the configuration.

Step 11. Change the enable secret password.

Step 12. Enable all interfaces using the no shutdown command.

Step 13. Return the configuration register setting to the original setting that was documented in Step
2 with the config-register global configuration command. On the next reboot, the router will use
these settings and load the new startup configuration file that contains the changed password.

Step 14. Save the configuration changes.

6.1.6 Password Recovery

If someone gained physical access to a router, they could potentially gain control of that device
through the password recovery procedure. This procedure, if performed correctly, leaves the router
configuration intact. If the attacker makes no major changes, this type of attack is difficult to detect.
An attacker can use this attack method to discover the router configuration and other pertinent
information about the network, such as traffic flows and access control restrictions.

An administrator can mitigate this potential security breach by using the no service password-
recovery global configuration mode command. This command is a hidden Cisco IOS command and
has no arguments or keywords. If a router is configured with the no service password-recovery
command, all access to ROMmon mode is disabled.

When the no service password-recovery command is entered, a warning message displays and must
be acknowledged before the feature is enabled, as shown in the example.
When it is configured, the show running-config command displays a no service password-
recovery statement, as shown here.

As shown below, when the router is booted, the initial boot sequence displays a message stating
PASSWORD RECOVERY FUNCTIONALITY IS DISABLED.

To recover a device after the no service password-recovery command is entered, initiate the break
sequence within five seconds after the image decompresses during the boot. You are prompted to
confirm the break key action. After the action is confirmed, the startup configuration is completely
erased, the password recovery procedure is enabled, and the router boots with the factory default
configuration. If you do not confirm the break action, the router boots normally with the no service
password-recovery command enabled.

CAUTION: If the router flash memory does not contain a valid Cisco IOS image because of corruption
or deletion, the ROMmon xmodem command cannot be used to load a new flash image. To repair
the router, an administrator must obtain a new Cisco IOS image on a flash SIMM or on a PCMCIA
card. However, if an administrator has access to ROMmon they can restore an IOS file to flash
memory using a TFTP server. Refer to Cisco.com for more information regarding backup flash images.
Lock Down a Router Using AutoSecure
6.2.1 Discovery Protocols CDP and LLDP

Cisco routers are initially deployed with many services that are enabled by default. This is done for
convenience and to simplify the configuration process required to get the device operational.
However, some of these services can make the device vulnerable to attack if security is not enabled.
Administrators can also enable services on Cisco routers that can expose the device to significant
risk. Both of these scenarios must be considered when securing the network.

The Cisco Discovery Protocol (CDP) is an example of a service that is enabled by default on Cisco
routers. The Link Layer Discovery Protocol (LLDP) is an open standard that can be enabled on Cisco
devices, as well as other vendor devices that support LLDP.

LLDP configuration and verification is similar to CDP. In the figure, R1 and S1 are both configured with
LLDP, using the lldp run global configuration command. Both devices are running CDP by default. The
output for show cdp neighbors detail and show lldp neighbors detail will reveal a device’s address,
platform, and operating system details.

Unfortunately, attackers do not need to have CDP-enabled or LLDP-enabled devices to gather this
sensitive information. Readily available software, such as Universal Network CDP & LLDP Evaluator
(UNCLE), enable any computer on the network to capture and view CDP and LLDP information that is
sent on a LAN. In addition, CDP is vulnerable to CDP spoofing attacks because CDP uses a well known
multicast MAC address. This is a form of denial of service attack that can overwhelm device CDP
tables with false CDP messages.
6.2.2 Settings for Protocols and Services

Attackers choose services and protocols that make the network more vulnerable to malicious
exploitation.

Many of these features should be disabled or restricted in their capabilities based on the security
needs of an organization. These features range from network discovery protocols, such as CDP and
LLDP, to globally available protocols such as ICMP and other scanning tools.

Some of the default settings in Cisco IOS software are there for historical reasons. They were logical
default settings at the time the software was originally written. Other default settings make sense for
most systems, but can create security exposures if they are used in devices that form part of a
network perimeter defense. Still other defaults are required by standards but are not always
desirable from a security point of view.

The table summarizes the feature and default settings for protocols and services.

Feature Default

Cisco Discovery Protocol

Enabled
(CDP)

Link Layer Discovery

Disabled
Protocol (LLDP)

Configuration
Disabled
autoloading

FTP server Disabled

TFTP server Disabled

Network Time Protocol

Disabled
(NTP) service

Packet
assembler/disassembler Enabled
(PAD) service

TCP and User Datagram

Protocol (UDP) minor Enabled in versions 11.3 and later
services

Maintenance Operation
Enabled on most Ethernet interfaces
Protocol (MOP) service

Simple Network Enabled

Management Protocol
Feature Default

(SNMP)

HTTP or HTTPS
configuration and Setting is Cisco device dependent.
monitoring

Domain Name System

Enabled
(DNS)

Internet Control
Message Protocol (ICMP) Enabled
redirects

IP source routing Enabled

Finger service Enabled

ICMP unreachable
Enabled
notifications

ICMP mask reply Disabled

IP identification service Enabled

TCP keepalives Disabled

Gratuitous ARP (GARP) Enabled

Proxy ARP Enabled

The table below shows recommended security settings for protocols and services.

There are several important practices available to help ensure a device is secure:

 Disable unnecessary services and interfaces.

 Disable and restrict commonly configured management services, such as SNMP.

 Disable probes and scans, such as ICMP. Ensure terminal access security.

 Disable gratuitous and proxy Address Resolution Protocols (ARPs).

 Disable IP-directed broadcasts.

Feature Recommendation

Cisco Discovery Protocol (CDP) Should be disabled globally or on a per-interface basis if it is not required.
Feature Recommendation

Link Layer Discovery Protocol

Should be disabled globally or on a per-interface basis if it is not required.
(LLDP)

Configuration autoloading Should remain disabled when not in use by the router.

FTP server Should be disabled when it is not required.

TFTP server It should be disabled when it is not required.

Network Time Protocol (NTP)

It should remain disabled when it is not required.
service

Packet assembler/disassembler
It should be explicitly disabled when not in use.
(PAD) service

TCP and User Datagram Protocol

Disable this service explicitly.
(UDP) minor services

Maintenance Operation Protocol

It should be explicitly disabled when it is not in use.
(MOP) service

Simple Network Management

Disable this service when it is not required.
Protocol (SNMP)

HTTP or HTTPS configuration Disable service if it is not required. If this service is required, restrict access to
and monitoring the router HTTP or HTTPS service using access control lists (ACLs).

Disable when it is not required. If the DNS lookup service is required, ensure
Domain Name System (DNS)
that you set the DNS server address explicitly.

Internet Control Message

Disable when it is not required.
Protocol (ICMP) redirects

IP source routing Disable this service when it is not required.

Finger service Disable this service when it is not required.

ICMP unreachable notifications Disable on interfaces to untrusted networks.

ICMP mask reply Disable on interfaces to untrusted networks.

IP identification service Service should be explicitly disabled.

Feature Recommendation

Should be enabled globally to manage TCP connections and prevent certain

denial of service (DoS) attacks. Service is enabled in Cisco IOS Software
TCP keepalives
releases before Cisco IOS Release 12.0 and is disabled in Cisco IOS Release
12.0 and later. Disable this service when it is not required.

Gratuitous ARP (GARP) Disable gratuitous ARPs on each router interface unless this service is needed.

Disable this service on each interface unless the router is being used as a LAN
Proxy ARP
bridge.

6.2.3 Cisco AutoSecure

Released in IOS version 12.3, Cisco AutoSecure is a feature that is initiated from the CLI and executes
a script. AutoSecure first makes recommendations for fixing security vulnerabilities and then
modifies the security configuration of the router, as shown in the figure.

AutoSecure can lock down the management plane functions and the forwarding plane services and
functions of a router. There are several management plane services and functions:

 Secure BOOTP, CDP, FTP, TFTP, PAD, UDP, and TCP small servers, MOP, ICMP (redirects, mask-
replies), IP source routing, Finger, password encryption, TCP keepalives, gratuitous ARP, proxy
ARP, and directed broadcast

 Legal notification using a banner

 Secure password and login functions

 Secure NTP

 Secure SSH access

 TCP intercept services

There are three forwarding plane services and functions that AutoSecure enables:

 Cisco Express Forwarding (CEF)

 Traffic filtering with ACLs

 Cisco IOS firewall inspection for common protocols

AutoSecure is often used in the field to provide a baseline security policy on a new router. Features
can then be altered to support the security policy of the organization.
6.2.4 Cisco AutoSecure Command Syntax

Use the auto secure command to enable the Cisco AutoSecure feature setup. This setup can be
interactive or non-interactive. The figure shows the command syntax for the auto secure command.

Router# auto secure {no-interact | full} [forwarding | management] [ntp | login | ssh | firewall |
top-intercept]

Here are the command parameters.

Note: Options may vary by platform.

In interactive mode, the router prompts with options to enable and disable services and other
security features. This is the default mode, but it can also be configured using the auto secure
full command.

The non-interactive mode is configured with the auto secure no-interact command. This will
automatically execute the Cisco AutoSecure feature with the recommended Cisco default settings.
The auto secure command can also be entered with keywords to configure specific components,
such as the management plane (management keyword) and forwarding plane (forwarding keyword).

Optional Parameters Description

The user will not be prompted for any interactive configurations. No interactive dialogue
no-interact
parameters will be configured, including usernames or passwords.
Optional Parameters Description

full The user will be prompted for all interactive questions. This is the default setting.

forwarding Only the forwarding plane will be secured.

management Only the management plane will be secured.

ntp Specifies the configuration of the NTP feature in the AutoSecure CLI.

login Specifies the configuration of the login feature in the AutoSecure CLI.

ssh Specifies the configuration of the SSH feature in the AutoSecure CLI.

firewall Specifies the configuration of the firewall feature in the AutoSecure CLI.

tcp-intercept Specifies the configuration of the TCP intercept feature in the AutoSecure CLI.

6.2.5 Cisco AutoSecure Configuration Example

When the auto secure command is initiated, a CLI wizard steps the administrator through the
configuration of the device. User input is required.

The auto secure command is entered. The router displays the AutoSecure configuration wizard
welcome message, as shown.
The wizard gathers information about the outside interfaces, as shown

AutoSecure secures the management plane by disabling unnecessary services, as shown.

AutoSecure prompts for a banner, as shown.

AutoSecure prompts for passwords and enables password and login features, as shown.

Interfaces are secured, as shown.

The forwarding plane is secured, as shown.

6.2.6 Syntax Checker - Using the auto secure Command

In this Syntax Checker, you will use AutoSecure to secure R1.

 Configure Serial0/0/0 as the interface facing the internet. Note: The interface name is case-
specific.

 Create an motd banner using #Unauthorized Access is Prohibited!#.

 Create a local username Admin01 and password Admin01pa55 to access the router.

 Configure a 60 second login shutdown if 2 failed login attempts are made within 30 seconds.

 Use example.com as the domain name for the SSH server.

 Do not configure CBAC firewall.

 Apply the configuration from AutoSecure to the running-config.

 Use AutoSecure to lock down the router.

 R1#auto secure
 --- AutoSecure Configuration ---

 *** AutoSecure configuration enhances the security of
 the router, but it will not make it absolutely resistant
 to all security attacks ***

 AutoSecure will modify the configuration of your device.
 All configuration changes will be shown. For a detailed
 explanation of how the configuration changes enhance security
 and any possible side effects, please refer to Cisco.com for
 AutoSecure documentation.
 At any prompt you may enter '?' for help.
 Use ctrl-c to abort this session at any prompt.

 Gathering information about the router for AutoSecure
 Is this router connected to Internet? [no]#yes
 Enter the number of interfaces facing the internet [1]#1

 Interface IP-Address OK? Method Status
Protocol
 Embedded-Service-Engine0/0 unassigned YES unset
administratively down down
 GigabitEthernet0/0 unassigned YES unset
administratively down down
 GigabitEthernet0/1 192.168.1.1 YES manual up
up
 Serial0/0/0 10.1.1.1 YES manual up
up
 Serial0/0/1 unassigned YES unset
administratively down down
 Enter the interface name that is facing the internet#Serial0/0/0

 Securing Management plane services...

 Disabling service finger
 Disabling service pad
 Disabling udp & tcp small servers
 Enabling service password encryption
 Enabling service tcp-keepalives-in
 Enabling service tcp-keepalives-out
 Disabling the cdp protocol

 Disabling the bootp server
 Disabling the http server
 Disabling the finger service
 Disabling source routing
 Disabling gratuitous arp

 Here is a sample Security Banner to be shown
 at every access to device. Modify it to suit your
 enterprise requirements.

 Authorized Access only
 This system is the property of So-&-So-Enterprise.
 UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED.
 You must have explicit permission to access this
 device. All activities performed on this device
 are logged. Any violations of access policy will result
 in disciplinary action.

 Enter the security banner {Put the banner between
 k and k, where k is any character}:
 ##Unauthorized Access is Prohibited!#

 Configuration of local user database
 Enter the username#Admin01
 Enter the password#Admin01pa55
 Confirm the password#Admin01pa55
 Configuring AAA local authentication
 Configuring console, Aux and vty lines for
 local authentication, exec-timeout, transport
 Securing device against Login Attacks
 Configure the following parameters
 Blocking Period when Login Attack detected#60
 Maximum Login failures with the device#2
 Maximum time period for crossing the failed login attempts#30
 Configure SSH server? [yes]#yes
 Enter the domain-name#example.com

 Configuring interface specific AutoSecure services
 Disabling the following ip services on all interfaces:

 no ip redirects
 no ip proxy-arp
 no ip unreachables
 no ip directed-broadcast
 no ip mask-reply
 Disabling mop on Ethernet interfaces

 Securing Forwarding plane services...

 Enabling unicast rpf on all interfaces connected
 to internet
 Configure CBAC Firewall feature? [yes/no]#no
 This is the configuration generated:

 no service finger
 no service pad
 no service udp-small-servers
 no service tcp-small-servers
 service password-encryption
 service tcp-keepalives-in
 service tcp-keepalives-out
 no cdp run
 no ip bootp server
 no ip http server
 no ip finger
 no ip source-route
 no ip gratuitous-arps
 no ip identd
 banner motd ^CUnauthorized Access is PROHIBITED^C
 security passwords min-length 6
 security authentication failure rate 10 log
 username Admin01 password 7 15330F010D247B7538326077
 aaa new-model
 aaa authentication login local_auth local
 line console 0
 login authentication local_auth
 exec-timeout 5 0
 transport output telnet
 line aux 0
 login authentication local_auth
 exec-timeout 10 0
 transport output telnet
 line vty 0 4
 login authentication local_auth
 transport input telnet
 line tty 1 2
 login authentication local_auth
 exec-timeout 15 0
 login block-for 60 attempts 2 within 30
 ip domain-name ccnasecurity.com
 crypto key generate rsa general-keys modulus 1024
 ip ssh time-out 60
 ip ssh authentication-retries 2
 line vty 0 4
 transport input ssh telnet
 service timestamps debug datetime msec localtime show-timezone
 service timestamps log datetime msec localtime show-timezone
 logging facility local2
 logging trap debugging
 service sequence-numbers
 logging console critical
 logging buffered
 interface Embedded-Service-Engine0/0
 no ip redirects
 no ip proxy-arp
 no ip unreachables
 no ip directed-broadcast
 no ip mask-reply
 no mop enabled
 interface GigabitEthernet0/0
 no ip redirects
 no ip proxy-arp
 no ip unreachables
 no ip directed-broadcast
 no ip mask-reply
 no mop enabled
 interface GigabitEthernet0/1
 no ip redirects
 no ip proxy-arp
 no ip unreachables
 no ip directed-broadcast
 no ip mask-reply
 no mop enabled
 interface Serial0/0/0
 no ip redirects
 no ip proxy-arp
 no ip unreachables
 no ip directed-broadcast
 no ip mask-reply
 interface Serial0/0/1
 no ip redirects
 no ip proxy-arp
  no ip unreachables
 no ip directed-broadcast
 no ip mask-reply
 access-list 100 permit udp any any eq bootpc
 interface Serial0/0/0
 ip verify unicast source reachable-via rx allow-default 100
 !
 end
 Apply this configuration to running-config? [yes]#yes

 Applying the config generated to running-config
 The name for the keys will be: R1.ccnasecurity.com

 % The key modulus size is 1024 bits
 % Generating 1024 bit RSA keys, keys will be non-exportable...
 [OK] (elapsed time was 3 seconds)

 R1#
 000046: *Dec 30 22:44:35.503 UTC: %AUTOSEC-1-MODIFIED: AutoSecure
configuration has been Modified on this device
 You successfully secured R1 using AutoSecure.

Routing Protocol Authentication

6.3.1 Dynamic Routing Protocols

Dynamic routing protocols are used by routers to automatically share information about the
reachability and status of remote networks. Dynamic routing protocols perform several activities,
including network discovery and maintaining routing tables.

Important advantages of dynamic routing protocols are the ability to select a best path, and the
ability to automatically discover a new best path when there is a change in the topology.

Network discovery is the ability of a routing protocol to share information about the networks that it
knows about with other routers that are also using the same routing protocol. Instead of depending
on manually configured static routes to remote networks on every router, a dynamic routing protocol
allows the routers to automatically learn about these networks from other routers. These networks,
and the best path to each, are added to the routing table of the router, and identified as a network
learned by a specific dynamic routing protocol.
The figure shows routers R1 and R2 using a common routing protocol to share network information.

6.3.2 Routing Protocol Spoofing

Routing systems can be attacked by disrupting peer network routers, or by falsifying or spoofing the
information carried within the routing protocols. Spoofing routing information may generally be used
to cause systems to misinform (lie to) each other, cause a DoS attack, or cause traffic to follow a path
it would not normally follow. There are several consequences of routing information being spoofed:

 Redirecting traffic to create routing loops

 Redirecting traffic so it can be monitored on an insecure link

 Redirecting traffic to discard it

Click the Play button on the animation to see an example of an attack that creates a routing loop.

Assume an attacker has been able to connect directly to the link between R1and R2. The attacker
sends R1 false routing information indicating that R2 is the preferred destination to the
192.168.10.0/24 network. Although R1 already has a routing table entry to the 192.168.10.0/24
network, the new route has a lower metric and therefore is the preferred entry in the routing table.

Consequently, when PC3 sends a packet to PC1 (192.168.10.10/24), R3 forward the packet to R2
which in turn forwards it to R1. R1 does not forward the packet to the PC1 host. Instead, it routes the
packet to R2 because the apparent best path to 192.168.10.0 /24 is through R2. When R2 gets the
packet, it looks in its routing table and finds a legitimate route to the 192.168.10.0/24 network
through R1 and forwards the packet back to R1, creating the loop. The loop was caused by the
misinformation injected into R1.

For more information about generic threats to routing protocols, search the internet for RFC 4593.
Mitigate against routing protocol attacks by configuring OSPF authentication.
The figure is an animation that demonstrates how an attacker can create a routing loop.

Attackers Can Manipulate Unauthenticated Routing Updates

...but R2 knows better and sends packet back to R1 creating a loop.

R1 should forward here...

To: 192.168.10.10

R1 updates its routing table.

Tell R1: 192.168.10.10/24 is reachable through R2.

...but attacker manipulated R1’s routing information, so R1 forwards to R2...

6.3.3 OSPF MD5 Routing Protocol Authentication

OSPF supports routing protocol authentication using MD5. MD5 authentication can be enabled
globally for all interfaces or on a per interface basis.

Enable OSPF MD5 authentication globally:

 ip ospf message-digest-key key md5 password interface configuration command.

 area area-id authentication message-digest router configuration command.

 This method forces authentication on all OSPF enabled interfaces. If an interface is not
configured with the ip ospf message-digest-key command, it will not be able to form
adjacencies with other OSPF neighbors.

Enable MD5 authentication on a per interface basis:

 ip ospf message-digest-key key md5 password interface configuration command.

 ip ospf authentication message-digest interface configuration command.

The interface setting overrides the global setting. MD5 authentication passwords do not have to be
the same throughout an area. However, they do need to be the same between neighbors.

In this figure, R1 and R2 are configured with OSPF and routing is functioning properly. However, OSPF
messages are not authenticated or encrypted.

The figure shows two routers connected via a serial connection. Each router is also connected to a
gigabit ethernet network.

OSPF Configured Without Authentication

In the figure below, R1 and R2 are configured with OSPF MD5 authentication. Authentication is
configured on a per interface basis because both routers are using only one interface to form OSPF
adjacencies. Notice that when R1 is configured, OSPF adjacency is lost with R2 until R2 is configured
with the matching MD5 authentication.
6.3.4 OSPF SHA Routing Protocol Authentication

MD5 is now considered vulnerable to attacks and should only be used when stronger authentication
is not available. Cisco IOS release 15.4(1)T added support for OSPF SHA authentication, as detailed in
RFC 5709. Therefore, the administrator should use SHA authentication as long as all of the router
operating systems support OSPF SHA authentication.

OSPF SHA authentication includes two major steps. The syntax for the commands is shown in the
figure:

Step 1. Specify an authentication key chain in global configuration mode:

Configure a key chain name with the key chain command.

Assign the key chain a number and a password with the key and key-string commands.

Specify SHA authentication with the cryptographic-algorithm command.

(Optional) Specify when this key will expire with the send-lifetime command.
Step 2. Use the following syntax to assign the authentication key to the desired interfaces with the ip
ospf authentication key-chain command.

In the example that follows the figure, R1 and R2 are configured with OSPF SHA authentication using
a key named SHA256 and the key string ospfSHA256. Notice that when R1 is configured, OSPF
adjacency is lost with R2 until R2 is configured with the matching SHA authentication.

The figure shows two routers connected via a serial connection. Each router is also connected to a
gigabit ethernet network.

OSPF Configured with SHA Authentication

6.3.5 Syntax Checker- OSPF SHA Routing Protocol Authentication

Use this Syntax Checker to configure OSPF authentication using SHA 256.

To configure OSPF with SHA authentication, you must first configure a key chain:

Issue the key chain command to create a key chain named SHA256.

Assign the key chain number 1

Assign the key-string name of ospfSHA256.

Assign hmac-sha-256 as the cryptographic-algorithm.

Enter exit twice to exit key chain configuration.

R1(config)#key chain SHA256

R1(config-keychain)#key 1

R1(config-keychain-key)#key-string ospfSHA256

R1(config-keychain-key)#cryptographic-algorithm hmac-sha-256

R1(config-keychain-key)#exit

R1(config-keychain)#exit

Enter interface configuration mode and assign the key-chain SHA256 for OSPF authentication on
S0/0/0.

R1(config)#interface S0/0/0

R1(config-if)#ip ospf authentication key-chain SHA256

R1(config-if)#

*Mar 1 16:52:26.615: %OSPF-5-ADJCHG: Process 1, Nbr 10.2.2.2 on Serial0/0/0 from LOADING to

FULL, Loading Done

Issue the end command to exit configuration mode.

R1(config-if)#end

R1#

You successfully configured NTP authentication on R1.

Secure Management and Reporting
6.4.1 Types of Management Access

In a small network, managing and monitoring a small number of network devices is a straightforward
operation. However, in a large enterprise with hundreds of devices, monitoring, managing, and
processing log messages can be challenging. From a reporting standpoint, most networking devices
can send log data that can be invaluable when troubleshooting network problems or security threats.
This data can be viewed in real time, on demand, and in scheduled reports.

When logging and managing information, the information flow between management hosts and the
managed devices can take two paths:

 In-band - Information flows across an enterprise production network, the internet, or both,
using regular data channels.

 Out-of-band (OOB) - Information flows on a dedicated management network on which no

production traffic resides.

For example, the network in the figure has two network segments separated by a Cisco IOS router
that is providing firewall services to protect the management network. The connection to the
production network allows management hosts to access the internet and provides limited in-band
management traffic. In-band management occurs only when OOB management is not possible or
available. If in-band management is required, then that traffic should be sent securely using a private
encrypted tunnel or VPN tunnel.

The figure illustrates in-band management.

In-Band Management

The figure below shows more detail for the protected management network. This is where the
management hosts and terminal servers reside. When placed within the management network,
terminal servers offer OOB direct console connections over the management network to any
network device requiring management on the production network. Most devices should be
connected to this management segment and be configured using OOB management.

Because the management network has administrative access to nearly every area of the network, it
can be a very attractive target for hackers. The management module on the firewall incorporates
several technologies designed to mitigate such risks. The primary threat is a hacker attempting to
gain access to the management network. This can be accomplished through a compromised
managed host that a management device must access. To mitigate the threat of a compromised
device, strong access control should be implemented at the firewall and at every other device.
Management devices should be set up in a fashion that prevents direct communication with other
hosts on the same management subnet by using separate LAN segments or VLANs.

The figure illustrates out-of-band management.

Out of-Band Management

6.4.2 Out-of-Band and In-Band Access

As a general rule, for security purposes, OOB management is appropriate for large enterprise
networks. However, it is not always desirable. The decision to use OOB management depends on the
type of management applications running and the protocols being monitored. For example, consider
a situation in which two core switches are managed and monitored using an OOB network. If a
critical link between these two core switches fails on the production network, the application
monitoring those devices may never determine that the link has failed and never alert the
administrator. This is because the OOB network makes all devices appear to be attached to a single
OOB management network. The OOB management network remains unaffected by the downed link.
With management applications such as these, it is preferable to run the management application in-
band in a secure fashion.

OOB management guidelines are :

 Provide the highest level of security.

 Mitigate the risk of passing insecure management protocols over the production network.

In-band management is recommended in smaller networks as a means of achieving a more cost-

effective security deployment. In such architectures, management traffic flows in-band in all cases. It
is made as secure as possible using secure management protocols, for example using SSH instead of
Telnet. Another option is to create secure tunnels, using protocols such as IPsec, for management
traffic. If management access is not necessary at all times, temporary holes can be placed in a
firewall while management functions are performed. This technique should be used cautiously, and
all holes should be closed immediately when management functions are completed.
In-band management guidelines are:

 Apply only to devices that need to be managed or monitored.

 Use IPsec, SSH, or SSL when possible.
 Decide whether the management channel needs to be open at all times.

Finally, if using remote management tools with in-band management, be wary of the underlying
security vulnerabilities of the management tool itself. For example, SNMP managers are often used
to ease troubleshooting and configuration tasks on a network. However, SNMP should be treated
with the utmost care because the underlying protocol has its own set of security vulnerabilities.

Network Security Using Syslog

6.5.1 Introduction to Syslog

Like a Check Engine light on your car dashboard, the components in your network can tell you if
there is something wrong. The syslog protocol was designed to ensure that you can receive and
understand these messages. When certain events occur on a network, networking devices have
trusted mechanisms to notify the administrator with detailed system messages. These messages can
be either non-critical or significant. Network administrators have a variety of options for storing,
interpreting, and displaying these messages. They can also be alerted to those messages that could
have the greatest impact on the network infrastructure.

The most common method of accessing system messages is to use a protocol called syslog.
Syslog is a term used to describe a standard. It is also used to describe the protocol developed for
that standard. The syslog protocol was developed for UNIX systems in the 1980s but was first
documented as RFC 3164 by IETF in 2001.

Many networking devices support syslog, including routers, switches, application servers, firewalls,
and other network appliances. The syslog protocol allows networking devices to send their system
messages across the network to syslog servers.

Specifically, syslog uses UDP port 514 to send event notification messages across IP networks to
event message collectors. For example, the figure displays a router (R1) and a switch (S1) sending
system messages to a syslog server.

The figure shows a router labeled R 1 and a switch labeled S 1 sending system messages to a syslog
server.

There are several syslog server software packages for Windows and UNIX available. Many of them
are freeware.

The syslog logging service provides three primary functions, as follows:

 The ability to gather logging information for monitoring and troubleshooting

 The ability to select the type of logging information that is captured

 The ability to specify the destinations of captured syslog messages

6.5.2 Syslog Operation

On Cisco network devices, the syslog protocol starts by sending system messages and debug output
to a local logging process that is internal to the device. How the logging process manages these
messages and outputs is based on device configurations. For example, syslog messages may be sent
across the network to an external syslog server. Messages on the syslog server can then be filtered
without needing to access the actual device. Log messages and outputs stored on the external server
can be pulled into various reports for easier reading.

Alternatively, syslog messages may be sent to an internal buffer. Messages sent to the internal buffer
are only viewable through the CLI of the device.
Finally, the network administrator may specify that only certain types of system messages be sent to
various destinations. For example, the device may be configured to forward all system messages to
an external syslog server. However, debug-level messages are forwarded to the internal buffer and
are only accessible by the administrator from the CLI.

As shown in the figure, popular destinations for syslog messages include the:

 Logging buffer (RAM inside a router or switch)

 Console line

 Terminal line

 Syslog server

It is possible to remotely monitor system messages by viewing the logs on a syslog server, or by
accessing the device through Telnet, SSH, or through the console port.

6.5.3 Syslog Message Format

Cisco devices produce syslog messages as a result of network events. Every syslog message contains
a severity level and a facility.

The smaller numerical levels are the more critical syslog alarms. The severity level of the messages
can be set to control where each type of message is displayed (i.e. on the console or the other
destinations). The complete list of syslog levels is shown in the table.

Severity Name Severity Number Description

Emergency Level 0 System Unusable

Alert Level 1 Immediate Action Needed

Critical Level 2 Critical Condition

Error Level 3 Error Condition

 Severity Name Severity Number Description

Warning Level 4 Warning Condition

Notification Level 5 Normal, but Significant Condition

Informational Level 6 Informational Message

Debugging Level 7 Debugging Message

Each syslog level has its own meaning:

 Emergency Level 0 - Warning Level 4: These messages are error messages about software or
hardware malfunctions; these types of messages mean that the functionality of the device is
affected. The severity of the issue determines the actual syslog level applied.

 Notification Level 5: This notifications level is for normal, but significant events. For example,
interface up or down transitions, and system restart messages are displayed at the
notifications level.

 Informational Level 6: This is a normal information message that does not affect device
functionality. For example, when a Cisco device is booting, you might see the following
informational message: %LICENSE-6-EULA_ACCEPT_ALL: The Right to Use End User License
Agreement is accepted.

 Debugging Level 7: This level indicates that the messages are output generated from issuing
various debug commands.

6.5.4 Syslog Facilities

In addition to specifying the severity, syslog messages also contain information on the facility. Syslog
facilities are service identifiers that identify and categorize system state data for error and event
message reporting. The logging facility options that are available are specific to the networking
device. For example, Cisco 2960 Series switches running Cisco IOS Release 15.0(2) and Cisco 1941
routers running Cisco IOS Release 15.2(4) support 24 facility options that are categorized into 12
facility types.

Some common syslog message facility codes reported on Cisco IOS routers include:

 IF - Identifies that the syslog message was generated by an interface.

 IP - Identifies that the syslog message was generated by IP.

 OSPF - Identifies that the syslog message was generated by the OSPF routing protocol.

 SYS - Identifies that the syslog message was generated by the device operating system.

 IPSEC - Identifies that the syslog message was generated by the IP Security encryption
protocol.

By default, the format of syslog messages on the Cisco IOS Software is as follows:
%facility-severity-MNEMONIC: description

For example, sample output on a Cisco switch for an EtherChannel link changing state to up is:

%LINK-3-UPDOWN: Interface Port-channel1, changed state to up

Here the facility is LINK and the severity level is 3, with a MNEMONIC of UPDOWN.

The most common messages are link up and down messages, and messages that a device produces
when it exits from configuration mode. If ACL logging is configured, the device generates syslog
messages when packets match a parameter condition.

6.5.5 Configure Syslog Timestamps

By default, log messages are not timestamped. In the example, the R1 GigabitEthernet 0/0/0
interface is shutdown. The message logged to the console does not identify when the interface state
was changed. Log messages should be timestamped so that when they are sent to another
destination, such as a Syslog server, there is record of when the message was generated.

Use the command service timestamps log datetime to force logged events to display the date and
time. As shown in the command output, when the R1 GigabitEthernet 0/0/0 interface is reactivated,
the log messages now contain the date and time

Note: When using the datetime keyword, the clock on the networking device must be set, either
manually or through NTP, as previously discussed.

6.5.7 Syslog Systems

Syslog implementations always contain two types of systems:

 Syslog servers - Also known as log hosts, these systems accept and process log messages
from syslog clients.

 Syslog clients - Routers or other types of equipment that generate and forward log messages
to syslog servers.
The topology in the figure identifies the syslog server at IP address 10.2.2.6. The rest of the servers
and devices in the topology can be configured as syslog clients, which send syslog messages to the
syslog server.

The figure shows a syslog topology.

Syslog Reference Topology

6.5.8 Syslog Configuration

Configure system logging:

Step 1. Set the destination logging host using the logging [host] command.

Identify the destination syslog server using the logging host command

Parameter Description

hostname Specifies the name of the host you want to use as a syslog server.

ip-address Specifies the IP address of the host you want to use as a syslog server.

Router(config)# logging host [hostname | ip-address]

Step 2. (Optional) Set the log severity (trap) level using the logging trap command.

Note: An ISR defaults to Level 7 (debugging).

Router(config)# logging trap level

Step 3. (Optional) Set the source interface using the logging source-interface command.

This command specifies that syslog packets contain the IPv4 or IPv6 address of a specific interface
(e.g., a loopback interface), regardless of which interface the packet uses to exit the router.
Parameter Description

interface-type Specifies the interface type.

interface-number Specifies the interface number (for example, 0/1).

Router(config)# logging source-interface interface-type interface-number

Step 4. (Optional) Enable logging to all enabled destinations with the logging on command.

Note: Syslog logging is enabled by default.

Router(config)# logging on

The figure below shows a sample syslog configuration for R1. Use the show logging command to
view logging configuration and buffered syslog messages.

Sample Syslog Configuration

NTP Configuration
6.6.1 Time and Calendar Services

Before you get really deep into network management, the one thing that will help keep you on track
is ensuring that all of your components are set to the same time and date.

The software clock on a router or switch starts when the system boots. It is the primary source of
time for the system. It is important to synchronize the time across all devices on the network
because all aspects of managing, securing, troubleshooting, and planning networks require accurate
timestamping. When the time is not synchronized between devices, it will be impossible to
determine the order of the events and the cause of an event.

The date and time settings on a router or switch can be manually configured, as shown in the
example.

Although manually setting the time is easy, it is not practical in most networks. As a network grows, it
becomes difficult if not impossible to ensure that all infrastructure devices are operating with
synchronized time. Even in a smaller network environment, the manual method is not ideal. If a
router reboots, how will it get an accurate date and timestamp?

A better and more scalable solution is to implement Network Time Protocol (NTP) which is
documented in RFC 1305. NTP enables network devices (i.e., NTP clients) to synchronize their time
settings with an NTP authoritative time source such as an NTP server. The NTP time source can be a
device (e.g., a router) on the network that is selected as the private primary clock or it can be a
publicly available NTP server on the internet.
NTP source and clients open UDP port 123 to send and receive timestamps.

6.6.2 NTP Operation

NTP networks use a hierarchical system of time sources. Each level in this hierarchical system is called
a stratum. The stratum level is defined as the number of hop counts from the authoritative source.

The figure displays a sample NTP network.

The figure displays a sample Network Time Protocol (N T P) network. N T P servers are arranged in
three levels showing the three strata. Stratum 1 is connected to Stratum 0 clocks. Stratum 0 consists
of two N T P clocks. The N T P clocks are connected to 2 Stratum 1 N T P servers. The Stratum 1 N T P
servers are connected to 3 Stratum 2 N T P servers. The Stratum 2 N T P servers are connected to 4
Stratum 3 N T P servers.

The sample network consists of four stratum levels who acquire their times as follows:

 Stratum 1 server gets its time from the stratum 0 time source.

 Stratum 2 server gets its time from the stratum 1 server.

 Stratum 3 server gets its time from the stratum 2 server.

Stratum 0

This identifies a device providing the most authoritative time source. Stratum 0 devices including
atomic and GPS clocks are the most accurate authoritative time sources.

Specifically, NTP stratum 0 devices are non-network high-precision timekeeping devices assumed to
be accurate and with little or no delay associated with them. In the figure, they are represented by
the clock icon.
Stratum 1

NTP stratum 1 devices are network devices that are directly connected to the authoritative time
sources. They function as the primary network time standard to stratum 2 devices.

Stratum 2 and Lower

NTP stratum 2 servers are connected on a network to a stratum 1 device. Stratum 2 devices are NTP
clients and synchronize their time by using the NTP packets from a stratum 1 server such as a router.
They in turn can be NTP servers for stratum 3 devices.

NTP stratum levels are based on a scale of 0 (highest stratum level) to 15 (lowest stratum level). For
example, an NTP server in a low number stratum level is closer to the authorized time source than a
server in a high number stratum level.

The maximum stratum hop count is 15 (i.e., 0 – 15). Note that an NTP client that is not synchronized
with a server is assigned a stratum 16 level.

NTP servers in the same stratum level can be configured as peers to provide redundant time sources
for clients or to synchronize each other.

6.6.3 Configure and Verify NTP

The figure shows the topology used to demonstrate NTP configuration and verification.

Before NTP is configured on the network, the show clock command displays the current time on the
software clock, as shown in the example. With the detail option, notice that the time source is user
configuration. That means the time was manually configured with the clock command.

In our topology, and internet NTP server is the authoritative time source. However, a local network
device could be selected as the NTP authoritative time source using the ntp master [stratum] global
configuration command.

In the topology, R1 is an NTP client of the NTP server. Use the ntp server ip-address global config
command to configure 209.165.200.225 as the NTP server for R1.

To verify the time source is set to NTP, use the show clock detail command. Notice that now the time
source is NTP.
In the next example, the show ntp associations and show ntp status commands are used to verify
that R1 is synchronized with the NTP server at 209.165.200.225. Notice that R1 is synchronized with
a stratum 1 NTP server at 209.165.200.225, which is synchronized with a GPS clock. The show ntp
status command displays that R1 is now a stratum 2 device that is synchronized with the NTP server
at 209.165.220.225.

Note: The highlighted st stands for stratum.

Next, the clock on S1 is configured to synchronize to R1 with the ntp server command and then the
configuration is verified with the show ntp associations command, as displayed.

Output from the show ntp associations command verifies that the clock on S1 is now synchronized
with R1 at 192.168.1.1 via NTP. R1 is a stratum 2 device and NTP server to S1. Now S1 is a stratum 3
device that can provide NTP service to other devices in the network, such as end devices.
SNMP Configuration
6.7.1 Introduction to SNMP

Now that your network is mapped and all of your components are using the same clock, it is time to
look at how you can manage your network by using Simple Network Management Protocol (SNMP).

SNMP was developed to allow administrators to manage nodes such as servers, workstations,
routers, switches, and security appliances, on an IP network. It enables network administrators to
monitor and manage network performance, find and solve network problems, and plan for network
growth.

SNMP defines how management information is exchanged between network management

applications and management agents. It is an application layer protocol that provides a message
format for communication between managers and agents. The SNMP system consists of three
elements:

 SNMP manager

 SNMP agents (managed node)

 Management Information Base (MIB)

To configure SNMP on a networking device, it is first necessary to define the relationship between
the manager and the agent.

The SNMP manager is part of a network management system (NMS). The SNMP manager runs SNMP
management software.

As shown in the figure, the SNMP manager can collect information from an SNMP agent by using the
“get” action. It can change configurations on an agent by using the “set” action. In addition, SNMP
agents can forward information directly to a network manager by using “traps”.
The SNMP agent and MIB reside on SNMP client devices. Network devices that must be managed,
such as switches, routers, servers, firewalls, and workstations, are equipped with an SNMP agent
software module. The MIB stores data and operational statistics about the device.

The SNMP Manager sends a get request to SNMP agent to access stored data in the local MIB.
Specifically, the SNMP manager polls the agents and queries the MIB for SNMP agents on UDP port
161. SNMP agents send any SNMP traps to the SNMP manager on UDP port 162.

6.7.2 SNMP Operation

SNMP agents that reside on managed devices collect and store information about the device and its
operation. This information is stored by the agent locally in the MIB. The SNMP manager then uses
the SNMP agent to access information within the MIB.

There are two primary SNMP manager requests:

 get request - Used by the NMS to query the device for data.

 set request - Used by the NMS to change configuration variables in the agent device. A set
request can also initiate actions within a device. For example, a set request can cause a
router to reboot, send a configuration file, or receive a configuration file.

The SNMP manager uses the get and set actions to perform the operations described in the table.

Operation Description

get-request Retrieves a value from a specific variable.

Retrieves a value from a variable within a table; the SNMP manager does not need to
get-next-request know the exact variable name. A sequential search is performed to find the needed
variable from within a table.

Retrieves large blocks of data, such as multiple rows in a table, that would otherwise
get-bulk-request require the transmission of many small blocks of data. (Only works with SNMPv2 or
later.)

get-response Replies to a get-request, get-next-request, and set-request sent by an NMS.

set-request Stores a value in a specific variable.

The SNMP agent responds to SNMP manager requests as follows:

 Get an MIB variable - The SNMP agent performs this function in response to a GetRequest-
PDU from the network manager. The agent retrieves the value of the requested MIB variable
and responds to the network manager with that value.

 Set an MIB variable - The SNMP agent performs this function in response to a SetRequest-
PDU from the network manager. The SNMP agent changes the value of the MIB variable to
the value specified by the network manager. An SNMP agent reply to a set request includes
the new settings in the device.
The figure illustrates the use of an SNMP GetRequest to determine if interface G0/0/0 is up/up.

6.7.3 Management Information Base (MIB)

The MIB organizes variables hierarchically. MIB variables enable the management software to
monitor and control the network device. Formally, the MIB defines each variable as an object ID
(OID). OIDs uniquely identify managed objects in the MIB hierarchy. The MIB organizes the OIDs
based on RFC standards into a hierarchy of OIDs, usually shown as a tree.

The MIB tree for any given device includes some branches with variables common to many
networking devices and some branches with variables specific to that device or vendor.

RFCs define some common public variables. Most devices implement these MIB variables. In
addition, networking equipment vendors, like Cisco, can define their own private branches of the
tree to accommodate new variables specific to their devices.

The figure shows portions of the MIB structure defined by Cisco. Note how the OID can be described
in words or numbers to help locate a particular variable in the tree. OIDs belonging to Cisco, are
numbered as follows: .iso (1).org (3).dod (6).internet (1).private (4).enterprises (1).cisco (9).
Therefore, the OID is 1.3.6.1.4.1.9.
6.7.4 SNMP Versions

There are several versions of SNMP:

 SNMPv1 - This is the Simple Network Management Protocol, a Full Internet Standard, that is
defined in RFC 1157.

 SNMPv2c - This is defined in RFCs 1901 to 1908. It uses a community-string-based

Administrative Framework.

 SNMPv3 - This is an interoperable standards-based protocol originally defined in RFCs 2273

to 2275. It provides secure access to devices by authenticating and encrypting packets over
 the network. It includes these security features: message integrity to ensure that a packet
was not tampered with in transit, authentication to determine that the message is from a
valid source, and encryption to prevent the contents of a message from being read by an
unauthorized source.

All versions use SNMP managers, agents, and MIBs. Cisco IOS software supports the above three
versions. Version 1 is a legacy solution and is not often encountered in networks today. Therefore,
this course focuses on versions 2c and 3.

Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers
that is able to access the MIB of the agent is defined by a community string.

Unlike SNMPv1, SNMPv2c includes a bulk retrieval mechanism and more detailed error message
reporting to management stations. The bulk retrieval mechanism retrieves tables and large
quantities of information, minimizing the number of round-trips required. The SNMPv2c improved
error-handling includes expanded error codes that distinguish different kinds of error conditions.
These conditions are reported through a single error code in SNMPv1. Error return codes in SNMPv2c
include the error type.

Note: SNMPv1 and SNMPv2c offer minimal security features. Specifically, SNMPv1 and SNMPv2c can
neither authenticate the source of a management message nor provide encryption. SNMPv3 is most
currently described in RFCs 3410 to 3415. It adds methods to ensure the secure transmission of
critical data between managed devices.

SNMPv3 provides for both security models and security levels. A security model is an authentication
strategy set up for a user and the group within which the user resides. A security level is the
permitted level of security within a security model. A combination of the security level and the
security model determine which security mechanism is used when handling an SNMP packet.

There are available security models for SNMPv1, SNMPv2c, and SNMPv3. The table identifies the
characteristics of the different combinations of security models and levels.
A network administrator must configure the SNMP agent to use the SNMP version supported by the
management station. Because an agent can communicate with multiple SNMP managers, it is
possible to configure the software to support communications by using SNMPv1, SNMPv2c, or
SNMPv3.

6.7.5 SNMP Vulnerabilities

In any network topology, at least one manager node should run SNMP management software.
Network devices that can be managed, such as switches, routers, servers, and workstations, are
equipped with the SNMP agent software module. These agents are responsible for providing the
SNMP manager access to a local MIB, which stores data about device operation.

SNMP is vulnerable to attack precisely because SNMP agents can be polled with get requests and
accept configuration changes with set requests, as shown in the figure. For example, a set request
can cause a router to reboot, send a configuration file, or receive a configuration file. An SNMP agent
can also be configured to send out traps or notifications. In SNMPv1 and SNMPv2c, these requests
and notifications are not authenticated or encrypted.

SNMP Operation

The figure shows an S N M P manager collecting information from an S N M P agent. In the figure an
S N M P Manager, depicted as a P C, is connected to a router, a switch and a firewall router. The
devices connected to the S N M P Manager are labeled as S N M P Agents and Managed Nodes. An
arrow labeled trap is pointed to the S N M P Manager indicating that S N M P agent devices send
traps to the S N M P manager. Text above reads In S N M P v 1, asynchronous event reports are called
traps while in later versions they are called notifications. There are two arrows pointed towards the S
N M P agents labeled Get and Set. These indicate that the S N M P manager sends the S N M P agents
Get and Set actions. Text below reads The actions get and set are the vulnerabilities that open S N M
P to an attack.

6.7.6 SNMPv3

SNMPv3 authenticates and encrypts packets over the network to provide secure access to devices.
This addressed the vulnerabilities of earlier versions of SNMP.

SNMPv3 provides three security features:

 Message integrity and authentication - Ensures that a packet has not been tampered with in
transit, and is from a valid source.

 Encryption - Scrambles the contents of a packet to prevent it from being seen by an

unauthorized source.

 Access control - Restricts each principal to certain actions on specific portions of data.

6.7.7 SNMPv3 Security Configuration

SNMPv3 can be secured with only a few commands, as shown in the following steps.
Note: A full discussion of the configuration options for SNMPv3 is beyond the scope of this course.

Step 1. Configure an ACL that will permit access to authorized SNMP managers.

Router(config)# ip access-list acl-name

Router(config-std-nacl)# permit source_net

Step 2. Configure an SNMP view with the snmp-server view command to identify the MIB OIDs that
the SNMP manager will be able to read. Configuring a view is required to limit SNMP messages to
read-only access.

Router(config)# snmp-server view view-name oid-tree

SNMPv3 can be secured with only a few commands, as shown in the figure.

Step 3. Configure SNMP group features with the snmp-server group command:

 Configure a name for the group.

 Set the SNMP version to 3 with the v3 keyword.

 Require authentication and encryption with the priv keyword.

 Associate a view to the group and give it read only access with the read command.

 Specify the ACL configured in Step 1.

Router(config)# snmp-server group group-name v3 priv read view-name access [acl-number | acl-
name]

Step 4. Configure SNMP group user features with the snmp-server user command:

 Configure a username and associate the user with the group name configured in Step 3.

 Set the SNMP version to 3 with the v3 keyword.

 Set the authentication type to either md5 or sha and configure an authentication password.
SHA is preferred and should be supported by the SNMP management software.

 Require encryption with the priv keyword and configure an encryption password.

Router(config)# snmp-server user username group-name v3 auth {md5 | sha} auth-password priv
{des | 3des | aes {128 | 192 | 256}} priv-password

6.7.8 SNMPv3 Security Configuration Example

The figure shows an example configuration for securing SNMPv3.

Step 1. A standard ACL is named PERMIT-ADMIN and is configured to permit only the 192.168.1.0/24
network. All hosts attached to this network will be allowed to access the SNMP agent running on R1.

Step 2. An SNMP view is named SNMP-RO and is configured to include the entire iso tree from the
MIB. On a production network, the network administrator would probably configure this view to
include only the MIB OIDs that were necessary for monitoring and managing the network.
Step 3. An SNMP group is configured with the name ADMIN. SNMP is set to version 3 with
authentication and encryption required. The group is allowed read-only access to the view (SNMP-
RO). Access for the group is limited by the PERMIT-ADMIN ACL.

Step 4. An SNMP user, BOB, is configured as a member of the group ADMIN. SNMP is set to version
3. Authentication is set to use SHA, and an authentication password is configured. Although R1
supports up to AES 256 encryption, the SNMP management software only supports AES 128. So, the
encryption is set to AES 128, and an encryption password is configured.

6.7.9 Syntax Checker - SNMPv3 Security Configuration Example

Use this Syntax Checker to configure R1 with SNMPv3 authentication using an ACL.

Configure a standard access list named PERMIT-ADMIN on R1 to permit only the 192.168.1.0/24
network. Exit from ACL configuration to continue.

R1(config)#ip access-list standard PERMIT-ADMIN

R1(config-std-nacl)#permit 192.168.1.0 0.0.0.255

R1(config-std-nacl)#exit

Using the snmp-server view command, configure an SNMP view named SNMP-RO to include the
entire ISO tree from the MIB.

R1(config)#snmp-server view SNMP-RO iso included

Using the snmp-server group command, configure an SNMP group with the name ADMIN. Set SNMP
to version 3 with authentication and encryption required. Allow read-only access to the view SNMP-
RO, and limit access using the PERMIT-ADMIN ACL.

R1(config)#snmp-server group ADMIN v3 priv read SNMP-RO access PERMIT-ADMIN

Using the snmp-server user command, add an snmp user named BOB as a member of
the ADMIN group. Set SNMP to version 3 and set authentication to use SHA with a password
of cisco12345. Set the encryption to AES 128 with a password of cisco54321. After configuration is
complete, use the end command to exit configuration mode.

R1(config)#snmp-server user BOB ADMIN v3 auth sha cisco12345 priv aes 128 cisco54321

R1(config)#end

R1#

You successfully configured SNMPv3 authentication using an ACL on R1.

6.7.10 SNMPv3 Verification

Verify most of the SNMPv3 security configuration by viewing the running configuration, as shown in
in the figure. Notice that the snmp-server user configuration is hidden. Use the show snmp
user command to view the user information.

Verify that the SNMP manager can send get requests to R1 by using an SNMP management tool,
such as the ManageEngine’s free SNMP MIB Browser. Configure the tool with the user details, as
shown in the figure. When a user is configured, use the SNMP management tool’s features to test
that the configured user can access the SNMP agent.

Configure SNMP Manager Access to SNMP Agent

In the figure below, the network administrator entered the OID for the IP addressing table. The get
request returned all the addressing information for R1. The network administrator authenticated
with the appropriate credentials.

Configure SNMP Manager Get Request Example

Verify that the data was encrypted by running a protocol analyzer, such as Wireshark, and capture
the SNMP packets.

Do an internet search to see Keith Barker’s demonstration of configuring and verifying SNMPv3.

Wireshark Capture of Encrypted SNMPv3 Packets

Device Monitoring and Management Summary
6.8.1 What Did I Learn in this Module?

Secure Cisco IOS Image and Configuration Files

The Cisco IOS resilient configuration feature allows for faster recovery if someone maliciously or
unintentionally reformats flash memory or erases the startup configuration file in nonvolatile
random-access memory (NVRAM). The feature maintains a secure working copy of the router IOS
image file and a copy of the running configuration file. These secure files cannot be removed by the
user and are referred to as the primary bootset. The feature is only available on older routers that
support a PCMCIA Advanced Technology Attachment (ATA) flash interface. Newer routers such as the
ISR 4000 do not support this feature. To secure the IOS image and enable Cisco IOS image resilience,
use the secure boot-image global configuration mode command. When enabled for the first time,
the running Cisco IOS image is secured and a log entry is generated. To take a snapshot of the router
running configuration and securely archive it in persistent storage, use the secure boot-config global
configuration mode command. The router can be configured to boot the secure image from
ROMmon mode. The configuration file can be copied from the secure location with secure boot-
config restore command. The Secure Copy Protocol (SCP) feature provides a secure and
authenticated method for copying router configuration or router image files to a remote location.
SCP relies on SSH for secure communication and AAA for authentication and authorization. If a router
has been compromised and the passwords changed to unknown values, a password recovery
procedure exists for booting the router without its configuration so passwords can be changed to
known values. This procedure may differ between different device models. Physical access to the
router and ROMmon mode are required. It is possible to disable access to the password recovery
procedure with the no service password-recovery command.

Lock Down a Router Using AutoSecure

Cisco routers are initially deployed with many services that are enabled by default. However, some of
these services, such as Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP), can
make the network vulnerable to attack. Both of these protocols can allow attackers to learn detailed
information about a router. Guidelines are provided for how each service on the router should be
configured for maximum security. The Cisco AutoSecure feature executes a script that makes
recommendations for fixing security vulnerabilities and then modifies the security configuration of
the router. AutoSecure enables three forwarding plane services, Cisco Express Forwarding (CEF),
traffic filtering with ACLs, and Cisco IOS firewall inspection. AutoSecure is often used in the field to
provide a baseline security policy on a new router. Features can then be altered to support the
security policy of the organization. When the auto secure command is entered, the device will
display the AutoSecure welcome message. AutoSecure will then gather information about the
current device configuration and enter a configuration dialog. It will then disable and enable services
and make other configuration changes to the device. When the wizard is complete, the running
configuration displays all configuration settings and changes. AutoSecure should be used when a
router is initially being configured. It is not recommended on production routers.

Routing Protocol Authentication

Dynamic routing protocols are used by routers to automatically share information about the
reachability and status of remote networks. Dynamic routing protocols perform several activities,
including network discovery and maintaining routing tables. Important advantages of dynamic
routing protocols are the ability to select a best path and the ability to automatically discover a best
new path when there is a change in the topology. Network discovery is the ability of a routing
protocol to dynamically share information about the networks that it knows about with other routers
that are using the same routing protocol. Routing systems can be attacked by disrupting peer
network routers, or by falsifying or spoofing the information carried within the routing protocols.
This may be used to cause systems to misinform (lie to) each other, cause a DoS attack, or cause
traffic to follow a path it would not normally follow. Routing protocol updates can be configured to
use MD5 or SHA authentication. This helps ensure that routing protocol updates are coming from
trusted sources. MD5 authentication is available for the OSPF routing protocol, however SHA is
preferred for greater security.

Secure Management and Reporting

Most network devices can gather and transmit log information that can be very valuable for
diagnosing network problems and detecting security incidents. In a small network, managing and
monitoring a small number of network devices is a straightforward operation. However, in a large
enterprise with hundreds of devices, monitoring, managing, and processing log messages can be
challenging. Information flow between log file collecting hosts and managed network devices can
take two paths. In-band information paths use the production network, the internet or both.
Management traffic is sent on the same network as user traffic. Out-of-band (OOB) management
paths use dedicated management networks which do not transmit user traffic. As a general rule, for
security purposes, OOB management is appropriate for large enterprise networks. However, it is not
always desirable. It depends on the management applications and protocols being monitored. In-
band management is recommended in smaller networks as a means of achieving a more cost-
effective security deployment. OOB management security guidelines are to provide the highest level
of security and mitigate the risk of passing insecure management protocols over the production
network. For in-band management, guidelines are to apply only to devices that need to be managed
or monitored, use IPSec, SSH, or SSL when possible, and decide whether the management channel
needs to be available at all times. If using remote management tools with in-band management, be
wary of the underlying security vulnerabilities of the management tool itself.

Network Security Using Syslog

The most common method of accessing system messages is to use a protocol called syslog. Many
networking devices support the syslog standard. The syslog protocol allows networking devices to
send their system messages across the network to syslog servers. The syslog logging service provides
the ability to gather logging information, select the type of information that is logged, and specify
the destination devices that will receive and store syslog messages. On Cisco network devices, the
syslog protocol can send system messages and debug command output to a local logging process
that is internal to the device or can send messages to an internal buffer. Messages sent to the
internal buffer can only be viewed through the CLI of the device. A device can be configured to send
syslog messages to a logging buffer, the console line, a terminal line, or an external syslog server.
Syslog messages contain a severity level that can range from Level 0 to Level 7. The lower the level
number, the higher the severity. For example, messages at Level 0 to Level 4 are about software or
hardware malfunctions. Level 5 messages indicate normal operation but are significant. Level 6
regards normal operating events, and Level 7 is for debugging messages. In addition, syslog messages
include a syslog facility code. Some facilities indicate the system, component, or protocol that
reported the message. The service timestamps log datetime command configures the device to use
system timestamps for all messages. The timestamps can come from the local device clock, or can be
synchronized between devices that are using the Network Time Protocol (NTP) for system time.
Syslog implementations consist of syslog servers, known as log hosts, that receive and store syslog
messages from across the network, and syslog clients that generate and forward syslog messages to
the syslog servers. A Cisco device is configured to use syslog by specifying the logging host with the
logging command, optionally setting the severity level of the messages to be logged with the logging
trap command, optionally setting the interface that should be a message source with the logging
source-interface command, and activating the logging process with the logging on command.

NTP Configuration
The software clock on a router or switch starts when the system boots. It is the primary source of
time for the system. It is important to synchronize the time across all devices on the network
because all aspects of managing, securing, troubleshooting, and planning networks require accurate
timestamping. When the time is not synchronized between devices, it will be impossible to
determine the order of the events and the cause of an event. Although the system time can be
manually set, it is much more desirable to configure devices to use the Network Time protocol (NTP)
to synchronize time between all network devices. NTP enables network devices (i.e., NTP clients) to
synchronize their time settings with an NTP authoritative time source such as an NTP server. The NTP
time source can be a device (e.g., a router) on the network that is selected as the private primary
clock or it can be a publicly available NTP server on the internet. NTP uses a hierarchical system of
time sources that are arranged in strata. Stratum 0 is the most authoritative time source and it may
use atomic or GPS clocks. Stratum 1 devices obtain their time information from Stratum 0 sources.
Stratum 1 devices are connected to the Stratum 0 time sources and are also accessible to enterprise
networks. Stratum 2 and lower devices function as network servers that provide time information to
network devices. They are connected to Stratum 1 devices or other network devices that are acting
as NTP servers. There are up to 16 NTP strata. The lower the strata number, the closer the source is
to the Strata 0 authoritative source. NTP is configured on a device with the ntp server command.

SNMP Configuration
Simple Network Management Protocol (SNMP) was developed to allow administrators to manage
nodes such as servers, workstations, routers, switches, and security appliances, on an IP network.
SNMP defines how management information is exchanged between network management
applications and management agents. It is an application layer protocol that provides a message
format for communication between managers and agents. The SNMP system requires three
elements and consists of an SNMP manager, SNMP agent, and the management information base
(MIB). The SNMP manager is part of a network management system (NMS) that runs SNMP
management software. SNMP agents reside on network devices and enable network data collection
and sharing. The MIB stores standardized variables that contain network data. The network manager
can send a get request to retrieve information from an agent's local MIB, or it can send a set request
to change the value of a variable in the MIB. The MIB organizes variables hierarchically. MIB variables
enable the management software to monitor and control the network device. RFCs define some
common public variables that most devices support. In addition, networking equipment vendors, like
Cisco, can define their own private branches of the tree to accommodate new variables specific to
their devices. There are three versions of SNMP. SNMPv1 is obsolete and mentioned only but
SNMPv2c and SNMPv3 are relevant to this course. SNMPv2c should be used at a minimum with
SNMPv3 strongly recommended. SNMPv1 and SNMPv2c offer minimal security features. Specifically,
SNMPv1 and SNMPv2c can neither authenticate the source of a management message nor provide
encryption. SNMPv3 adds methods to ensure the secure transmission of critical data between
managed devices. SNMPv3 provides for both security models and security levels. A security model is
an authentication strategy set up for a user and the group within which the user resides. A security
level is the permitted level of security within a security model. A combination of the security level
and the security model determine which security mechanism is used when handling an SNMP
packet. SNMPv3 authenticates and encrypts packets over the network to provide secure access to
devices. This addressed the vulnerabilities of earlier versions of SNMP.