Which SNMP version requires authentication and validation between managed devices and the network management console before messages can be exchanged?

SNMP

The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. SNMP messages are encoded as ASN.1 binary using BER encoding, and run over UDP/161 and UDP/162. SNMP enables network administrators to manage network performance and to find and solve network problems. Three versions of SNMP exist: SNMP version 1 (SNMPv1), SNMP version 2 (SNMPv2), and SNMP version 3 (SNMPv3). SNMPv1 and SNMPv2 have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Neither version provides for any authentication or encryption. SNMPv3 includes, among other things, a model for access control and security as well as for a new architecture. SNMPv3 has yet to attain wide acceptance; thus, SNMPv1 and SNMPv2 still predominate.

An SNMP network normally consists of three key components: managed devices, agents, and network-management systems (NMSs). A managed device is a network node that contains an SNMP agent. Almost every networked device functions as a managed device. An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. Applications such as HP Openview or Tivoli are examples of NMSs.

Managed devices are monitored and controlled using three basic SNMP commands: read, write, and trap. These commands are defined as follows:

The read command is used by an NMS to monitor managed devices.

The write command is used by an NMS to control managed devices.

The trap command is used by managed devices to asynchronously report events to the NMS.

Additionally, NMS and other applications (such as GetIF; see www.wtcs.org/snmp4tpc/getif.htm) can read and display the Management Information Base (MIB). A MIB is a (sometimes vendor-supplied) collection of information about the managed device that is organized hierarchically. The MIB contains fields that list all of the data the managed device can make available to the NMS.

SNMP community strings and some device configuration data are often among the first findings in penetration tests or vulnerability assessments. Most administrators forget about this threat or simply ignore it.

The best method for securing SNMP today is to turn it off. In VoIP networks, most IPenabled telephones use SNMPV1 and SNMPv2 for configuration and performance monitoring. Thus, it is often impossible to disable this service. If you must run SNMP over your internal networks, then adopt the following practices:

Immediately change the default read/write community strings

Do not use the default “public” or “private” string.

Do not use a string that would be easy to guess, such as the company’s name or phone number.

Do not use a text-only string; use an alphanumeric string (both text and numerals).

Use both uppercase and lowercase letters (community strings are case-sensitive).

Use a community string that is at least eight characters long.

Employ ingress and egress filtering at the nearest network border, or limit SNMP to specific management and configuration VLANs.

Allow SNMP traffic to only a few authorized internal hosts. Only a few network management systems need to initiate SNMP request messages. Thus, administrators can configure SNMP agents to prohibit request messages from unauthorized hosts.

Managers and Agents

SNMP managed devices are typically controlled by a network management station (NMS). The NMS polls devices periodically, querying for status information, sends configuration changes as necessary. The NMS also listens for traps or notifications. In this manner, the NMS functions similarly to a centralized log collector. The primary reason to support SNMP is so log events can be exported to traditional NMS’s like HP’s OpenView. But they can also be exported to log collection systems.

The exact manner of configuring SNMP traps varies with each device. This document at the following link describes in more detail how to configure all aspects of SNMP on IOS 12: http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf014.html.

This document is a good mix of general introduction to SNMP as well as practical guide to configuring SNMP which, while geared toward IOS, is general enough that it can be used as a guide to other systems.

As with syslog, something has to be listening for the SNMP traps. The receiver can be a NMS, or you can run some SNMP daemon on your favorite flavor of Unix. Net-SNMP is the most popular open source SNMP toolkit. It is comprised of useful command-line tools and an SNMP trap daemon (snmpd) which runs on most flavors of Unix and Windows. The official Web site is http://www.net-snmp.org/

VPN and IPSec Security Management

The IPSec suite is used to seamlessly integrate security features, such as authentication, integrity, and confidentiality into IP packets.You can configure an encrypted and authenticated communication path between two clients, routers, or firewalls.

IPSec can function in two modes: tunnel and transport mode. Transport mode is used to provide end-to-end security between two nodes. Transport mode will protect all traffic between the source and destination with IPSec. In tunnel mode IPSec, the end nodes do not necessarly use or support IPSec. Instead, an IPSec- enabled security gateway or firewall functions as an IPSec peer for the communication between the end nodes. For example, a roaming user on the Internet connects to the enterprise e-mail server using an IPSec tunnel to the enterprise firewall. The traffic between the roaming user and the e-mail server is protected with IPSec up to the firewall. From there, the traffic is forwarded to the -mail server unprotected.

IPSec uses two security protocols to provide data protection. The first one is Authentication Fleader (AH) protocol, which provides data integrity, data source authentication, and protection against replay attacks. When this protocol is used, the original IP packet is encapsulated into a packet that contains an extra header (AH), which contains an authentication value calculated from the contents of the packet. This value is checked when the packet arrives at its destination, ensuring the its contents were not modified on the way. The AH protocol does not provide data confidentiality, because information is not encrypted.

The second is the Encapsulation Security Payload (ESP) protocol, which provides data confidentiality, data integrity, data source authentication, and protection against replay attacks. The data confidentiality is accomplished by encrypting the original IP packet and encapsulating it into a new IP packet with the ESP header attached. The ESP header contains connection-specific encryption information in the form of reference to the Security Association (SA).This information is used on the other end of the connection to decrypt the packet after its arrival and check that the original data was not modified in any way.

The SA contains information on security protocols and encryption algorithms used to protect data for a specific connection, along with what data should be protected and which endpoints are used.

CSPM supports the configuration for IPSec SAs through the use of tunnel templates, tunnel groups, and policies.You can use the tunnel template to define the algorithms and protocols that will be used for encryption of data across the tunnel for confidentiality or authentication purposes. The tunnel group is based on one associated tunnel template and defines the tunnel peers or endpoints. This ensures that peers which are part of one tunnel group will reference the same protocols and algorithms. This will reduce risks of introducing errors when manually configuring each peer or endpoint for the tunnels. You can use the security policies to determine between services that should be routed through the tunnels, and services that should be routed using other methods.

For more information on IPSec, see Chapter 8.

CSPM allows you to create three basic types of tunnels:

Managed Device-to-Managed Device Managed Device-to- Managed Device tunnels are used to securely transmit data between two managed devices (PIX firewalls or IPSec routers) across a public network, creating a VPN between two locations.

Policy Distribution Point-to-Managed Device A policy distribution point is the component of CSPM that issues commands to managed devices (such as routers or Cisco Secure IDS sensors). Policy Distribution Point-to-Managed Device tunnels are used to securely transmit Managed Device configuration information to the Managed Devices over a public network. They can be used, for example, to configure and monitor remote devices over the Internet.

Remote User Tunnels Remote user tunnels allow remote users secure access to internal network resources over a public network.

CSPM supports both manual and IKE tunnels. There are many preconfigured templates that can be used for creating your own tunnels. You can use them as they are or change any parameters so they suit your network setup. Figure 12.2 demonstrates one of these templates.

As you can see, CSPM supports all standard Cisco IPSec configuration parameters. After the template is configured, it is applied to a tunnel group to provide peers with protocol information.

Installing Policy and Device Configurations

When an administrator must deploy configuration changes to the managed device, they will want to verify them prior to deployment. First, an administrator may wish to leverage the “Policy Check” feature. This is only available if you have enabled it in the “Admin Setting” section. Policy Check runs a validation process against all the Policy Packages in the domain and will indicate conflicts, shadowed policies, duplicate objects, and candidates for optimizations (see Figure 9.10).

After you are comfortable with your packages and are ready to deploy them, the “Install” wizard will walk you through the process. You will be prompted to install all pending changes including the Policy Package data or to just install the device level configurations. If you choose to deploy all pending changes, the wizard will allow the selection of which Policy Packages are to be deployed and to which of the targeted devices. During the wizard execution process, the interface to zone mappings will be validated, giving you an opportunity to preview the changes. After successful deployment, the FortiManager will save a new revision in the device’s revision history, assisting with future auditing (see Figure 9.11).

The MIB and SMI

The agent software has access to the current value of various objects in the managed device. The exact function and meaning of an object, and the relationship of one object to another, is described in the MIB for the managed device. The MIB is a crucial concept in all network management standards, not only in SNMP, although there are many MIBs for devices used on the Internet.

The MIB is a database description of all fields (objects) that make up the totality of information an agent can furnish to a manager console when requested. So, a MIB is most often just a piece of paper that says things such as “the first field is alphanumeric, 20 characters long, and contains the name of the vendor” and “the fifth field is an integer and contains the number of bad packets received.” Not that this is rendered in plain English. A special ISO “language” called ASN.1 (Abstract Syntax Notation version 1) is used to represent all fields of the MIB database in very terse and cryptic language that all MIB implementers understand.

SNMP Operation

The SNMP protocol works under a very simplified model of data collection and control of the managed devices. Only a few basic commands are used in the SNMP protocol, such as GETREQUEST, GETNEXTREQUEST, SETREQUEST, and TRAP. An NMS invokes GETREQUEST to collect data from a device, and GETNEXTREQUEST to retrieve the next value in a set. An NMS can also invoke the SETREQUEST command to save data to a managed device. The TRAP command is the only one not initiated by the NMS; it is sent out by the client to report any unusual activity it has detected.

On the client side, the Management Information Base (MIB) acts as a tree that catalogs all of the various data components of the system or device. Each of these data components are known by their object identifiers (OIDs). The OID is made up of multiple sets of numbers, each separated by a period, in a structured order similar to that of an IP address. As a general rule, all OIDs begin with .1.3.6.1.2.1, except on many Cisco devices which use .1.3.6.1.4.1.9. To request a data value, an established OID must be specified. For example, to request the system up time, OID .1.3.6.1.2.1.1.2 is read.

Version Control

Nagios’ configuration language is like a stripped-down programming language with object-oriented features; treat your Nagios configuration as you would any other application source code. The larger and more heterogeneous the environment is, the more complex configurations can become, even when designed carefully to take advantage of the inheritance model the Nagios configuration language supports. In an environment where there is enough trust to give coworkers the ability to manage their own configurations, the risk of losing important configuration code increases. Finally, there is the risk of losing a configuration should an intruder break in to the host Nagios runs on.

Version control can help resolve all of these situations. It mitigates the risks associated with having multiple authors working on the same code at the same time. It provides an easy way to have live backups of Nagios configurations and lets administrators see who changed what, and when. In this section, we show how version control can help make your configuration easier to use, change, and share.

The larger the configuration, the trickier it becomes to remember the changes made to the configuration. Place the configuration under version control and it becomes easy to see what changes have been made to the configuration. Additionally, the comments provided give context and rationale for why changes were made. Version control also allows for tagging specific releases of a configuration. If an organization has implemented a redundant cold backup system, a version control system can easily compare two configuration releases and quickly synchronize a live system and a cold backup system. Finally, most version control systems also provide a Web interface that allows users to browse the source, compare arbitrary revisions, and create and associate actions with code (trouble tickets, bug reports, etc). This can make it easy for an administrator to keep track of what has changed and remember why changes were made in the first place.

As mentioned before in this book, Nagios can facilitate communications between groups in an organization and help them communicate the status of managed devices and services within an organization to operational staff. Once an organization starts seeing the value Nagios can provide in these areas, domain experts within an organization might start to develop their own ideas of what they want to monitor and how they want to monitor the services and hosts that are important to them. Eventually trust might develop between the administrators and these users and you may decide to allow users to make their own configuration changes. Even with this trust in place administrators probably do not want users to make configuration changes to service and host monitoring policies that other groups in an organization have established. Version control systems can be used to control access to areas of a configuration tree by setting up group-specific subdirectories that are stored in projects made specifically for each group. For example, if there is a Unix group, a Windows group, and a router group, the configuration directives in nagios.cfg might look like this:

cfg_dir=/usr/local/nagios/etc/groups/windows

cfg_dir=/usr/local/nagios/etc/groups/unix

cfg_dir=/usr/local/nagios/etc/groups/router

Each subdirectory could then be set up as a version-controlled repository. This allows each group to check out its own configuration project, make changes to it, and check changes back in. They never need interactive login access to the physical monitoring host. After changes are made, a code review can be done (very important), the configuration can be tested, and the new code can then be applied to the system. Version control will not keep people from writing malicious code or creating files with incorrect syntax, so make sure a human reviews each group's changes before they are applied to the Nagios host.

This way of thinking about configuration can also be very useful for a consulting business. For example, a business might have a client with whom there is a fair amount of trust, yet that client requires service or hosting checking functionality specific to their application or network. Administrators might not be comfortable giving clients SSH access to the Nagios host as it contains configurations from other customers. In this case, the Nagios configuration tree might look something like Figure 2.9.

The Nagios cfg_dir section might look like this:

cfg_dir=/usr/local/nagios/etc/customers/Ultimate_Domains/bin

cfg_dir=/usr/local/nagios/etc/customers/Ultimate_Domains/etc

cfg_dir=/usr/local/nagios/etc/customers/CVK9_Services/bin

cfg_dir=/usr/local/nagios/etc/customers/CVK9_Services/etc

For each customer custom scripts would be stored in the bin/ subdirectory, and custom configurations in the etc/ subdirectory. We also recommend making use of the custom attributes feature of Nagios 3 to create base host or service configuration for each customer that contains company-specific information. This meta-data can later be used in notifications to provide contact information or other company-specific information to the people receiving the alerts. A base service configuration with custom attributes is shown in this example:

define service {

use generic-service # Inherit from the generic-service definition that comes with Nagios

name ud-base

hostgroups ultimatedomains

notification_interval 120

notification_period 24×7

contact_groups ultimatedomains

__ud_base /usr/local/nagios/etc/clients/Ultimate_Domains # Custom commands can refer to this

__customer_notes Ask for Jarred if you need to speak to someone who knows all the applications well

__customer_address 111 Example Avenue, Sometown, Florida. 00000

__customer_phone 555–1212

register 0

}

We recommend using a double-underscore “__” as a prefix to custom attributes; when the variables are used in services or hosts the _HOST or _SERVICE prefix is separated from the variable name by a single underscore. For example, in a command definition, __customer_phone becomes:

$_SERVICE_CUSTOMER_PHONE$

An example check command that uses the __ud_base and other custom variables:

define command {

command_name check_ud_keyword_search

command_line $_SERVICE_UD_BASE$/bin/check_keyword_search.pl -s $_SERVICE_UD_KEYWORD_SEARCH_TERM$ -e $_SERVICE_UD_KEYWORD_SEARCH_ENV$ -w $_SERVICE_UD_KEYWORD_SEARCH_WARN$ -c $_SERVICE_UD_KEYWORD_SEARCH_CRIT$

}

Losing a configuration, whether it is due to mistyping, a system break-in by an attacker, or system failure is painful. Set up a revision control repository for the Nagios monitoring host on a host that is separate from Nagios on the network so that even if the monitoring host is compromised or fails, there is a recent backup to roll back to quickly. Version control should never be used as the backup system for a host, yet it certainly makes an excellent addition to backup systems and is a very fast way to restore a configuration should something bad happen.

Version control of configuration code is often not considered at all when implementing a monitoring system with Nagios. Nagios’ configuration language is rich and can help model services and hosts in complex environments—making the loss of a well-designed configuration a painful event. Make wise use of version control and there will be peace of mind for administrators, flexibility for users, and customers can have control over their custom service checks and the ability to easily see what changes are made to their monitoring configuration.

Nagios as a Monitor of Monitors

A monitor of monitors (MOM) is a centralized console that receives events from remote applications, displays alerts, and can poll locally managed devices for status. It is important when designing a monitoring system to empower the staff who manage applications and systems within an organization with as much control over their monitoring systems as possible (Figure 6.1). It is also very important to let specialists in an organization use the tools they know work best for the type of monitoring they wish to do. For example, a network security team might prefer to manage its own instances of Snort, Tripwire and Nessus. Even these specialized systems will produce some alarms and events that your tier-1 and tier-2 staff need to know about due to their potential impact. Instead of forcing them to have to learn and use multiple tools to see these alerts, simplify their lives by letting the application experts decide which alarms need to be seen, and have the specialists configure their tools to forward these alerts to the central management server. SNMP traps or the Nagios NSCA frameworks can both be used for this purpose.

Nagios can fill this manager of managers role quite well. It can receive and display SNMP traps using SNMPTT and some simple integration code, it can receive passive events using the NSCA framework, and it can poll systems and applications in an organization for status. With its extensive visualization add-ons (NagVis, PHP, Nagios Looking Glass, to name a few), Nagios can provide end users with a multitude of customized views of data stored in Nagios. When planning a new Nagios installation or integrating Nagios into an existing organization, think about how Nagios might work in this role. Using Nagios as a Monitor of Monitors can make your life easier as an integrator. It also may make it much easier to convince an organization to adopt Nagios; not much thrills IT managers (especially service desk managers) more than hearing that they can simplify life for their staff while providing them with greater insight into IT operations.

Fault Management

Within the ISO framework, fault management is responsible for detecting, correlating, and providing the necessary interfaces for correcting a failure within the managed devices. A failure may be defined as an event within the network causing the system to operate outside its normal operating conditions. The failure may be defined as transient or persistent, requiring the management system to have the capacity to detect either condition under all operating environments.

Upon detection and correction of a failure condition it is critical the management system is capable of recording all events surrounding the event to permanent record. Once the system has been restored to normal operation, each failure condition should be evaluated in detail to make sure all events leading up to the failure are well understood. Any possible corrective action to prevent the conditions from occurring again should be put into place.

Events and alarms are typically displayed within the management system as a sorted table listing each of the conditions the system has detected.

Fig. 14.5 shows an example alarm and event table in an FTTx NMS/EMS.

The key attributes of an alarm or event include the ID of the condition, the severity of the problem as defined by the operator (critical/major/minor), the source of the condition including the device name and type, the time the condition was received by the management system and finally the number of times this condition has been reported by the network element.

In today’s environment of a distributed management system it is important for a network operator to ACKnowledge each alarm they are working to resolve. This tells the operator’s staff that a colleague has already begun taking action on the condition received by the system. Enforcing this discipline is critical in order to avoid one of two undesirable outcomes: either two people start working on the same problem and work at cross-purpose, or everyone assumes someone else has it, so no one works on it.

Alarm and event notification is critical to a fault management system in order to facilitate automatic reporting to staff. Notifications are typically set up for particular alarm/event, severity level, frequency, and device types through email, SMS text message, voice message, and system alarm. These features are critical to allow for indications of various conditions and escalated problems within a managed system to be easily communicated to the staff.

Hardening Infrastructure Devices

Don’t overlook hardening your infrastructure devices. Not all routers and switches have administrative capability, but many do. For those that do, referred to as managed devices, they usually allow you to control many aspects of the device, including redirecting traffic to ports of your choosing and basically enabling or disabling all traffic flow through the device. Given the often central role these devices fulfill in your network, control over one of them will often mean control over your entire business. For this reason, you should exercise the same care and due diligence in securing your infrastructure devices as you would your critical servers. The same high-level bullets for hardening host-based systems also apply to managed infrastructure devices.

Most managed devices will have a means to authenticate using a local account as well as a central authentication server, such as TACACS or RADIUS. Ensure that the accounts are secured and a high-quality password is used. Sometimes even routers and switches will have unneeded services installed by default. One common example is enabling an HTTP interface for managing the devices. While this can certainly be handy, often the Web interface opens up an entire category of potential security risks that would not otherwise be present. The highest level of security is achieved by disabling any services that are not needed. Conservative timeouts for abandoned sessions and a login warning banner are advisable security measures.

You will also need to update the software on the device. Given the criticality and potential scope of impact for these devices if an update causes a problem, these devices are rarely configured to update automatically. In most cases, this will be a manual process which you must incorporate into your patch management and change management processes. Pay extra attention to any device connected to the Internet as these are going to be attacked on a regular basis. You must secure them before you connect them to the Internet, or you will likely lose control of them in short order.