Try   HackMD
Device Management Configuration

Network Security Using Syslog

When certain events occur on a network, networking devices have trusted mechanisms to notify the administrator with detailed system messages. Syslog is the most common method of accessing system messages sent across the network. Syslog uses UDP port 514 to send event notification messages across IP networks to event message collectors.

The syslog logging service on Cisco IOS 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

Cisco network devices send 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. The network administrator may specify that only certain types of system messages be sent to various destinations. Popular destinations for syslog messages include the in-memory Logging Buffer, the Console line, the Terminal line, or an external 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.

Syslog Message Format

Cisco devices produce syslog messages containing a severity level and a facility.

Smaller numerical levels represent more critical syslog alarms. The severity level of the messages can be set to control where each type of message should be displayed.

The available syslog levels include:

Severity Level Description
Emergency 0 System Unusable
Alert 1 Immediate Action Needed
Critical 2 Critical Condition
Error 3 Error Condition
Warning 4 Warning Condition
Notification 5 Normal But Signficant Condition
Informational 6 Informational Message
Debugging 7 Debugging Message
  • Emergency (Level 0) - Warning (Level 4): Error messages about software or hardware malfunctions. The severity of the issue determines the exact syslog level applied.
  • Notification (Level 5): Used for normal, but important events. Interface Up or Down transitions, and System Restart messages are displayed at the notifications level.
  • Informational (Level 6): Useful messages that do not indicate changes to device functionality.
  • Debugging (Level 7): This level is used for output generated by debug commands.

Syslog facilities are service identifiers that identify and categorize system state data for error and event message reporting. By default, the format of syslog messages on the Cisco IOS Software is:

%facility-severity-MNEMONIC: message 

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

  • IF — generated by an interface.
  • IP — generated by IP.
  • OSPF — generated by the OSPF routing protocol.
  • SYS — generated by the device operating system.
  • IPSEC — generated by the IP Security encryption protocol.

Syslog Timestamps

By default, log messages are not timestamped. Use the command service timestamps log datetime to force logged events to display the date and time.

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

Syslog Implemenation

Syslog implementations must 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.

Configure Syslog reporting on a device using the following procedure:

  1. Set the destination logging host using the logging [hostname | ip-address] command.
  2. (Optional) Set the log severity (trap) level using the logging trap level command.
  3. (Optional) Set the source interface using the logging source-interface interface command.
  4. (Optional) Enable logging to all enabled destinations with the logging on command.
  5. Verify implemenation using the show logging command.
R1(config)# logging 10.2.2.6
R1(config)#
! *Sep 25 12:57:14.120: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.2.2.6 port 514 started - CLI initiated
R1(config)#
R1(config)# logging trap informational
R1(config)# logging source-interface lo0
R1(config)# logging on 
R1(config)# end
R1#
! *Sep 25 12:58:29.591: %SYS-5-CONFIG_I: Configured from console by console
R1#
R1# show logging
! Syslog logging: enabled (0 messages dropped, 2 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering ! disabled)
! 
! <...output truncated...>
! 
R1# 

NTP Configuration

Network Time Protocol (NTP) enables network devices to synchronize their time settings with an NTP authoritative time source such as an NTP server. 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 maximum stratum hop count is 15 (i.e., 0 – 15). NTP servers in the same stratum level can be configured as peers to provide redundant time sources for clients or to synchronize each other.

NTP stratum 0 devices are non-network high-precision timekeeping devices assumed to be accurate and with little or no delay associated with them.

An NTP client that is not synchronized with a server is assigned a stratum 16 level.

A local network device could be selected as the NTP authoritative time source using the ntp master [stratum] global configuration command.

NTP Configuration with Authentication:

  1. Enable NTP authentication.
  2. Define an authentication key.
  3. Identify the trusted key to use for NTP authentication.
  4. Configure the NTP server to bind to.
R1(config)# ntp authenticate
R1(config)# ntp authentication-key ntpKey md5 cisco123
R1(config)# ntp trusted-key ntpKey
R1(config)# ntp server 192.168.1.5
R1(config)# ntp update-calendar
R1(config)# end
R1# 
R1# show clock detail 
! 21:41:56.657 UTC Fri Mar 6 2015
! Time source is NTP
R1# show ntp status 
! Clock is synchronized, stratum 2, reference is 209.165.200.225
! nominal freq is 250.0000 Hz, actual freq is 249.9995 Hz, precision is 2**19
! <...output truncated...>
!
R1# show ntp associations detail
! 10.1.1.2 configured, ipv4, our_master, sane, valid, stratum 3
! ref ID 104.232.3.3    , time D8A49DA4.A83132C7 (21:41:56.657 UTC Fri Mar 6 2015)
! <...output truncated...>
!
R1# 

It may take several minutes for a configured NTP client to become synced with the NTP server.

Additional devices may be configured to use an available NTP client as an intermediary NTP server via the ntp server command. This will place the additional device at a lower stratum than the intermediary.

NTP source and clients open UDP port 123 to send and receive timestamps.

Simple Network Management Protocol

Simple Network Management Protocol (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.

SNMPv3 provides secure access to devices by utilizing message integrity checks, authentication, and encryption.

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.

The SNMP agent and MIB reside on SNMP client devices. The MIB stores data and operational statistics about the device.

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.

The Management Information Base (MIB) enables the management software to monitor and control the network device. The MIB organizes variables hierarchically into a tree-like data structure. The records within the data tree uniquely identify managed objects (as OID strings) used to monitor and control the network device.

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.

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.
get-next-request
Retrieves a value from a variable within a table; the SNMP manager does not need to know the exact variable name. A sequential search is performed to find the needed variable from within a table.
get-bulk-request
Retrieves large blocks of data, such as multiple rows in a table, that would otherwise 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.

SNMP Security

In SNMPv1 and SNMPv2c, get/set-requests and response-notifications are not authenticated or encrypted, and are thus more vulnerable to hijacking.

The latest version of SNMP is SNMPv3. Both of the earlier SNMPv1 and SNMPv2c standards 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 "secret" community string.

By contrast, the SNMPv3 standard defines three levels of access restriction:

Level Auth Method Encryption
noAuthNoPriv Username Only None
authNoPriv MD5 or SHA Key None
authPriv MD5 or SHA Key DES or AES

Because an agent can communicate with multiple SNMP managers, it is possible to configure the software to support communications using multiple SNMP standards.

SNMP Configuration

A network administrator must configure the SNMP agent to use the SNMP version supported by the management station.

SNMPv3 can be secured with only a few steps:

  1. Configure an ACL that will permit access to authorized SNMP managers, using the ip access-list acl-name global configuration command, followed by the permit address mask command.
  2. Configure an SNMP view with the snmp-server view view-name oid-tree 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.
  3. Configure an SNMP group 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.
  4. Configure group users 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.
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
R1(config)# snmp-server view SNMP-RO iso included
R1(config)# snmp-server group ADMIN v3 priv read SNMP-RO access PERMIT-ADMIN
R1(config)# snmp-server user BOB ADMIN v3 auth sha cisco12345 priv aes 128 cisco54321
R1(config)# end
R1#

Verify configuration via

R1# show run | include snmp 
! snmp-server group ADMIN v3 priv read SNMP-RO access PERMIT-ADMIN 
! snmp-server view SNMP-RO iso included
R1#
R1# show snmp user  
! User name: BOB 
! Engine ID: 80000009030030F70DA30DA0 
! storage-type: nonvolatile active 
! Authentication Protocol: SHA 
! Privacy Protocol: AES128 
! Group-name: ADMIN 
!
R1#