4-6. Monitoring a Firewall with SNMP Simple Network Management Protocol (SNMP) is a protocol that allows the exchange of information about managing a network device. Cisco firewalls can participate in SNMP as follows: A Management Information Base (MIB) is a collection of variables stored on a network device. The device can update the variables, or they can be queried from an external source. MIBs are structured according to the SNMP MIB module language, which is based on the Abstract Syntax Notation 1 (ASN.1) language. An SNMP agent runs on a firewall and maintains various MIB variables. Any query of the variables must be handled through the agent. The SNMP agent can also send unsolicited messages, or traps, to an SNMP manager. Traps are used to alert the manager of changing conditions on the firewall. An SNMP manager is usually a network management system that queries MIB variables, can set MIB variables, and receives traps from a collection of network devices. Cisco firewalls can use SNMP version 1 (SNMPv1), the original version. SNMPv1, based on RFC 1157, has only basic cleartext community strings for security. Access is limited to read-only requests from the IP addresses of one or more SNMP managers. Firewalls running PIX 7.x can also support SNMP version 2c (SNMPv2c), an enhanced version based on RFCs 1901, 1905, and 1906. SNMPv2c improves on bulk information retrieval and error reporting but still uses only basic cleartext community strings and IP addresses to provide security. (SNMP security is available only in SNMPv3, which currently is not supported on any Cisco firewall platform.)
TIP SNMP requests and responses are sent using UDP port 161. Notifications or traps are sent using UDP port 162. The SNMP management station can be located on any interface of a firewall, provided that the firewall has sufficient routing information to reach it. Overview of Firewall SNMP Support Firewalls can participate in SNMP by maintaining several MIBs. The MIB values are constantly updated with the current values that are in use. For example, one MIB parameter records the average firewall CPU load over a 5-second period. This is based on the CPU usage measurements that can also be shown from the firewall command-line interface. SNMP MIBs represent data as a hierarchical tree structure; each MIB variable is referenced by its object identifier (OID). OIDs are formed by concatenating the name or number of a tree branch as the tree is followed from the root to the object's location in dotted notation. Figure 4-12 shows the top layers of the standard MIB tree, along with the lower layers that apply to firewalls. The root layer is unnamed. All MIB variables that are useful for network management are located under the internet subtree. Following the tree structure downward, internet is referenced as OID iso.org.dod.internet or 1.3.6.1. Figure 4-12. SNMP MIB Structure
TIP Your SNMP management station needs to have several firewall-specific MIBs compiled into its database. Make sure you find these MIBS: IF-MIB, RFC1213-MIB, CISCO-MEMORY-POOL-MIB, CISCO-PROCESS-MIB, ENTITY-MIB, and CISCO-FIREWALL-MIB. PIX 7.x also adds CISCO-IPSEC-FLOW-MONITOR-MIB, CISCO-FIPS-STAT-MIB, and ALTIGA-SSL-STATS-MIB. These can all be obtained for free from Cisco.com at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml or directly through FTP from ftp://ftp.cisco.com/pub/mibs/supportlists/pix/pix-supportlist.html. Firewall MIBs A firewall uses the mgmt subtree (iso.org.dod.internet.mgmt or 1.3.6.1.2) to contain several useful objects, all organized under the mib-2 subtree (1.3.6.1.2.1). These objects are defined in the RFC1213-MIB file (1.3.6.1.2.1.11). They fall into these categories: system Descriptions of the firewall, uptime, and network services interfaces Parameters and counters for each interface ip IP addresses, subnet masks, and broadcast addresses assigned to each interface
Many of the values maintained in the mib-2 subtree can also be seen with the show snmp-server (PIX 6.x), show running-config snmp-server (PIX 7.x), show version, and show interface EXEC commands. The EntityMIB subtree (1.3.6.1.2.1.47) is also included. It is defined by the ENTITY-MIB file, which is based on RFC 1212. This was added to PIX 7.x to support the firewall chassis and field-replaceable units (FRUs) available on the ASA platforms. The private (1.3.6.1.4) subtree contains one subtree, enterprise (1.3.6.1.4.1), where all network vendor-specific objects are located. The Cisco private MIB structure is contained in the cisco subtree (1.3.6.1.4.1.9). The set of specific MIBs that are included under the cisco MIB tree varies according to the hardware platform (router, switch, firewall, and so on). A firewall maintains several subtrees under iso.org.dod.internet.private.enterprise.cisco.mgmt, as follows: The ciscoMemoryPool subtree (1.3.6.1.4.1.9.9.48) has objects that are defined in the CISCO-MEMORY-POOL-MIB file. These describe the current status of firewall memory. It can also be seen with the show blocks EXEC command. The ciscoProcess subtree (1.3.6.1.4.1.9.9.109) is defined by the CISCO-PROCESS-MIB file. These values describe the firewall's CPU usage over 5-second, 1-minute, and 5-minute periods. The same values can be seen with the show cpu usage EXEC command. The ciscoFirewall subtree (1.3.6.1.4.1.9.9.147) is defined by the CISCO-FIREWALL-MIB file. A number of values are maintained that describe the current memory buffer usage (cfwBuffer-Stat) and the connection usage (cfwConnectionStat) in the firewall. These correspond to the output of the show memory and show conn count EXEC commands, respectively. The ciscoIpSecFlowMonitorMIB subtree (1.3.6.1.4.1.9.9.171) is defined by the CISCO-IPSEC-FLOW-MONITOR-MIB file. This was added to PIX 7.x to support IPSec VPN functionality to report on tunnel statistics. The ciscoRemoteAccessMonitorMIB subtree (1.3.6.1.4.1.9.9.392) is defined by the CISCO-REMOTE-ACCESS-MONITOR-MIB file. This was added to PIX 7.x to support VPN client session statistics. It is derived from the ALTIGA-SESSION-STATS-MIB file. The ciscoFipsStatsMIB subtree (1.3.6.1.4.1.9.9.999999) is defined by the CISCO-FIPS-STAT-MIB file. This was added to PIX 7.x to support reporting on IPSec cryptographic engine operations. The altigaSSLstats subtree (1.3.6.1.4.1.3076.2.1.2.26) is defined by the ALTIGA-SSL-STATS-MIB file. This was added to PIX 7.x to support reporting on SSL session statistics. It's primarily used for the WebVPN feature.
Firewall SNMP Traps A firewall can send notification or trap messages to SNMP management stations when certain events occur. This allows the management station to receive alerts in real time and relay them to the appropriate networking personnel. Generic traps are sent when firewall links (interfaces) go up or down, when the firewall is reloaded (a "warm start") or booted up (a "cold start" after power is applied) for some reason, and when an SNMP poll has been received with an incorrect community string. Syslog messages can also be sent as SNMP traps if the firewall is configured to do so. When SNMP traps are sent, the firewall's OID is included. This allows the SNMP management station to determine what type of device has sent the trap. Cisco firewall models use the unique OIDs shown in Table 4-8. Notice that the OIDs use most of the same tree hierarchy as SNMP MIBs. For example, 1.3.6.1.4.1.9. would lead to the private.enterprise.cisco. subtree. This is followed by .1., which points to the Cisco products subtree, which is followed by a number that uniquely identifies the firewall model. Table 4-8. Firewall OID Values Used in SNMP TrapsFirewall Model | OID |
|---|
PIX 501 | 1.3.6.1.4.1.9.1.417 | PIX 506 | 1.3.6.1.4.1.9.1.389 | PIX 506E | 1.3.6.1.4.1.9.1.450 | PIX 515 | 1.3.6.1.4.1.9.1.390 | PIX 515E | 1.3.6.1.4.1.9.1.451 | PIX 520 | 1.3.6.1.4.1.9.1.391 | PIX 525 | 1.3.6.1.4.1.9.1.392 | PIX 535 | 1.3.6.1.4.1.9.1.393 | Catalyst 6500 FWSM | 1.3.6.1.4.1.9.1.522 | ASA 5510 | 1.3.6.1.4.1.9.1.450 | ASA 5520 | 1.3.6.1.4.1.9.1.448 | ASA 5540 | 1.3.6.1.4.1.9.1.449 | Other (original PIX models) | 1.3.6.1.4.1.9.1.227 |
The only exception is when Syslog messages are sent as SNMP traps with the logging history command. The OID used is always 1.3.6.1.4.1.9.9.41.2, regardless of the sending firewall platform. TIP You can find the entire list of Cisco product OIDs in the CISCO-PRODUCT-MIB file at ftp://ftp.cisco.com/pub/mibs/oid/CISCO-PRODUCTS-MIB.oid. SNMP Configuration You can use the following steps to configure SNMP operation so that a firewall or security appliance platform can be remotely monitored: 1. | Define the SNMP identity. Identify the firewall location: FWSM 2.x | Firewall(config)# snmp-server location string | PIX 6.x | Firewall(config)# snmp-server location string | PIX 7.x | Firewall(config)# snmp-server location string |
Someone at a management station can learn of the firewall's location by querying the location. This is given by string (a text string of up to 127 characters, including spaces). Identify the firewall administrator: FWSM 2.x | Firewall(config)# snmp-server contact string | PIX 6.x | Firewall(config)# snmp-server contact string | PIX 7.x | Firewall(config)# snmp-server contact string |
Querying this string tells someone who to contact in case of firewall problems or issues. The contact information is given by string (a text string of up to 127 characters).
| 2. | Allow SNMP access. Permit access for a specific management station: FWSM 2.x | Firewall(config)# snmp-server host if_name ip_addr [poll | TRap] [udp-port port] | PIX 6.x | Firewall(config)# snmp-server host if_name ip_addr [poll | trap] | PIX 7.x | Firewall(config)# snmp-server host if_name ip_addr [poll | trap] [community commstr] [version version] [udp-port udp_port] |
The management station can be found on the firewall interface named if_name (inside or outside, for example) at IP address ip_addr. This command may be repeated to define up to five different stations for PIX 6.x or up to 32 stations for PIX 7.x and FWSM. The type of access opened to the management station is given by the poll or trap keywords. With poll, the station is allowed to poll the firewall with SNMP queries. The trap keyword allows the firewall to send SNMP traps to the management station. By default, only the cold start, link up/down, and SNMP authentication failure traps are sent. On an FWSM platform, you can add the udp-port keyword to specify the UDP port that is used when sending SNMP traps. If neither keyword is given, both poll and trap actions are permitted. Specifying poll causes traps to be denied, and specifying trap causes polls to be denied. PIX 7.x allows additional SNMP parameters to be set on a per-server basis. You can use the community keyword to specify a community string commstr (up to 32 characters, without spaces) that is used as a weak authentication for the server. If a community string is not defined with this command, a global community string (defined in Step 2b) is automatically configured for the server. If no global string has been defined, the server entry is marked as "pending" until a valid community string is defined. By default, SNMP version 1 is used. You can use the version keyword to specify the SNMP version that the server uses as version (1 for SNMPv1 or 2c for SNMPv2c). If the server uses something other than the default UDP port 161, you can set the UDP port to udp_port (0 to 65535). Define an SNMP community string: FWSM 2.x | Firewall(config)# snmp-server community key | PIX 6.x | Firewall(config)# snmp-server community key | PIX 7.x | Firewall(config)# snmp-server community key |
A community string acts as a shared secret password that authenticates any management station's SNMP polls. If the string key (up to 32 characters, without spaces; the default is public) matches between the incoming polls and the firewall itself, the polls are answered. If this command is not entered, default community string public is used. PIX 7.x uses this command to define one "global" community string that can be used for any SNMP server that is configured without one. If this command is not entered, there is no default community string. TIP Even though the SNMP community string is sent as cleartext within SNMP packets, it should still be viewed as a rudimentary password security method. Therefore, you should always change its value to something other than the default "public." (Optional) Define the SNMP poll UDP port: FWSM 2.x | | PIX 6.x | | PIX 7.x | Firewall(config)# snmp-server listen-port port |
PIX 7.x uses this command to define a "global" UDP port that can be used to listen for SNMP polls. By default, UDP port 161 is used. This can be overridden on a per-host basis with the snmp-server host command. (Optional) Send specific trap types: FWSM 2.x | Firewall(config)# snmp-server enable traps {all | type} | PIX 6.x | Firewall(config)# snmp-server enable traps | PIX 7.x | Firewall(config)# snmp-server enable traps {all | type} |
In FWSM 2.x and PIX 6.x, only generic SNMP traps are sent to any management station configured for traps. This includes cold start, link up/down, and SNMP authentication failure traps. You can also send Syslog messages as SNMP traps with this command. You can set the severity level threshold of the messages to be sent with the logging history level command. PIX 7.x and FWSM offer more types of traps to be identified and sent. The all keyword allows all types of traps. You can specify a trap type as one of the following sets of keywords: - firewall [security] Traps are sent for any type of firewall inspection, content inspection, attack detection, and so on, as defined in the CISCO-FIREWALL-MIB file. The security traps are assumed, whether or not the security keyword is given. - snmp [authentication] [coldstart] [linkdown] [linkup] Generic SNMP traps are sent for SNMP authentication failures, firewall cold starts (power cycles), and interface state changes. These are defined in the SNMPv2-MIB file. If only the snmp keyword is given, all the optional keywords are assumed. - syslog Syslog messages are sent as SNMP traps. You should also set the severity level threshold of the messages to be sent with the logging history level command.
|
The following trap type and keywords can be used on PIX 7.x platforms only: - entity [config-change] [fru-insert] [fru-remove] Traps are sent if the firewall configuration is changed or if an FRU is installed or removed (ASA platforms only). These are defined in the CISCO-ENTITY-FRU-CONTROL-MIB file. If only the entity keyword is given, all the optional keywords are assumed. - ipsec [start] [stop] Traps are sent based on IPSec tunnel creation and deletion, as defined in the CISCO-IPSEC-FLOW-MONITOR-MIB file. If only the ipsec keyword is given, the other options are assumed. - remote-access [session-threshold-exceeded] Traps are sent as VPN clients connect and disconnect, as defined in the CISCO-REMOTE-ACCESS-MONITOR-MIB file. Optionally, traps can be sent if the number of VPN client sessions exceeds a threshold.
|