Table Of Contents
Monitoring Sensor Health
Using the Sensor Health Function
Understanding Sensor Health Messages
Configuring the Sensor Health Function
Understanding Cisco Incident Control System Support
Monitoring Sensor Health
Beginning with Management Center for IPS Sensors (IPS MC) 2.1, the Sensor Health function determines whether sensors being managed by IPS MC can be reached and are functioning properly. The Sensor Health function periodically polls each sensor to determine its state and reports this back to you via the Object Selector, email notification, Audit Log, and Progress Viewer. When a sensor does not respond to the polling, the following occurs:
•
The sensor's icon appears red in the object selector
•An error field is added to the sensor database table
•A message describing the sensor problem appears in the yellow tool tip box when you hold your mouse over the sensor icon in the Object Selector.
You can obtain a more detailed explanation of the sensor health problem from the Progress Viewer or by running an Audit Log report.
Beginning with IPS MC 2.2, the Sensor Health function includes the detection of out-of-band (OOB) changes. The detection of OOB changes works on IOS IPS devices and 5.x sensors and detects differences between parameters reported by the sensor and the corresponding information in the IPS MC database. These parameters include:
For IOS IPS devices:
•Last SDF (signature definition file) load time
•IOS IPS version change
•The "V" version change
For 5.x sensors:
•The current sensor signature update "S" version and "V" version contrasted to the versions stored in the IPS MC database
•The current configuration token on the device contrasted to the token value stored in the IPS MC database
OOB changes occur whenever a device receives configuration changes by a means other than IPS MC; for example, by command line interface (CLI) changes, changes from Cisco Incident Control System (ICS) update, or changes from a Cisco Security Monitoring, Analysis and Response System (CS MARS) update.
When OOB changes are detected, the device is shown as a yellow icon. A message describing the device OOB change appears in the yellow tool tip box when you hold your mouse over the device icon, as shown in the following figure:
To re-synchronize the information and update the IPS MC database, you must re-import the configuration from the device.
Using the Sensor Health Function
Although the Sensor Health function operates without user intervention, you must configure the function itself and understand the error messages that the system displays.
This section contains the following topics:
•Understanding Sensor Health Messages
•Configuring the Sensor Health Function
Understanding Sensor Health Messages
The system uses Sensor Health messages of three types:
•Operational Error Messages—These messages are generated by the Sensor Health function as operational error messages. These messages describe how the error might have occurred and provide either a corrective measure or a likely remedy when it is unclear how to fix the problem.
For information on these messages, see Table 7-1.
•Sensor Specific Error Messages—These messages include several substitution variables that are resolved at run time when a message is generated. The variable names clarify what values are provided in the messages.
For information on these messages, see Table 7-2.
•Warning Messages—These messages are generated by the Sensor Health function and warn of specific sensor error conditions.
For information on these messages, see Table 7-3.
The messages of each type are described in the tables that follow.
Table 7-1 Operational Error Messages
Message
|
Description
|
The IDS MC database could not be opened. The status of the sensors can't be determined until a connection to the database can be established.
|
The database is down, or SystemConfig.xml has been damaged. Restarting the daemon manager and logging in to IPS MC should provide more detail into why this error is occurring.
|
The MC is unable to provide email notification since there is no email server defined. Please define the email server if you would like email notification.
|
The system has been configured to send notification email but no recipient has been defined. When this occurs the system adds the email messages to the Audit Log and the Progress Viewer (even if it is not configured to do so) so that the messages are not lost and can be seen.
|
Table 7-2 Sensor Specific Error Messages
Message
|
Description
|
The sensor $SENSORNAME at the IP address $ADDRESS could not be queried, the credentials supplied are not authorized for this sensor.
|
The system fails to log in to the sensor. You must modify the username and password in IPS MC to be able to log in to the sensor. You do not need to restart the Sensor Health function, because each time the function runs it gets credentials from the MC database.
|
The sensor $SENSORNAME at the IP address $ADDRESS could not be contacted, no response was received and the operation timed out.
|
The connection could not be established and a timeout occurs. Because this failure can also occur during import and deployment to the sensor, the same troubleshooting tips for import and deployment apply here as well.
|
The sensor $SENSORNAMEat the IP address $ADDRESS responded, but timed out during the query of its status.
|
The user can log in and open a connection, but the connection times out so the status query fails. Occasionally this happens when networks are congested or when QoS has dropped the priority of the packets because the status query appears as an HTTP transaction to the QoS. Because this failure would also occur during import and deployment to the sensor, the same troubleshooting tips for import and deployment apply here as well.
|
The sensor $SENSORNAME reports that $PACKETDROPPED percent of the packets are being dropped.
|
The sensor has reported that packets are being dropped, and the percentage of packets dropped has reached the DroppedPacketThreshold value.
|
The sensor $SENSORNAME reports that it is running low on resources. You may need to close any open CLI sessions to the sensor and disable non-essential signatures to alleviate this problem.
|
The sensor has reported that its criticality level has exceeded the CriticalityErrorThreshold value.
|
The sensor $SENSORNAME reports that the daemon $DAEMONNAME has a status of $DAEMONSTATUS.
|
The sensor has reported that one of the daemons has a status of anything other than "running". The reported state from the sensor is included in the $DAEMONSTATUS.
|
The sensor $SENSORNAME reports it's version as $SENSORVERSION but the MC reports version $MCVERSION. There appears to have been a change on the sensor that needs to be synchronized with the MC.
|
The sensor is running a software version different from the one IPS MC reports for the sensor. This can be corrected by either re-importing the sensor in to IPS MC, or by upgrading or downgrading the sensor software. Future deployment will fail because the version is different from what IPS MC expects.
|
Table 7-3 Warning Messages
Message
|
Description
|
The sensor $SENSORNAME was omitted from status query by configuration. Please correct the configuration file if this was not intended.
|
The sensor has been configured as part of the user configuration OmitList. This message is a warning that the sensor did not have its status checked.
|
The sensor $SENSORNAME reports that resources are low but not yet critical. You may want to close any open CLI sessions and review the list of non-essential enabled signatures if this condition continues.
|
The criticality level of the sensor is greater than or equal to the CriticalityWarningThreshold value but has not met or exceeded the CriticalityErrorThreshold value.
|
The query of status for sensor $SENSORNAME was postponed; there is a signature update or service pack being applied to the sensor at this time.
|
The sensor has a signature or service pack update scheduled to occur within SchedulingThreshold minutes from now. The status of the sensor has not been checked and will most likely be checked upon the next invocation of the sensor health function, assuming a second update is not scheduled for the sensor in the interim.
|
The query of status for sensor $SENSORNAME was postponed; there is a configuration deployment in progress for the sensor at this time.
|
The sensor has a configuration deployment scheduled to occur within SchedulingThreshold minutes from now. The status of the sensor has not been checked and will most likely be checked upon the next invocation of the Sensor Health function assuming a second deployment is not scheduled for the sensor in the interim.
|
Configuring the Sensor Health Function
You must configure the Sensor Health function for it to properly function in your IPS MC. After it is configured the Sensor Health function operates without intervention.
The elements of configuration on the Sensor Health page are detailed in Table 7-4.
Table 7-4 Element Definitions
Configuration Element
|
Description
|
Enable
|
Select this check box to enable the Sensor Health function.
|
Email Address for Summary Information
|
Email is sent to this address which reports the time of the check and the status of each sensor that was checked. You can enter multiple values as a comma-separated list.
|
Email Address for Errors Only
|
Email is sent to this address when a faulty sensor is detected, or if a sensor is unreachable. The email lists the sensor name, IP address of the sensor, the time of the check, and a short message listing the problem. You can enter multiple values as a comma-separated list.
|
Send Email For Individual Errors
|
Select this check box to have an individual message sent to the configured email address regarding each sensor that appears to have a fault. (Individual emails keep the text size of each message as small as possible so that emails sent to a pager have a better chance of being sent in their entirety.)
|
Send to Progress Viewer
|
Select this check box to enable status information to be sent to the Progress Viewer. A single large message with the complete status is sent to the Progress Viewer.
|
Send to Audit Log
|
Select this check box to enable all errors to be logged to the Audit Log; successful status checks are not sent to the Audit Log.
|
Run Frequency
|
The period of time, in minutes, between runs of the Sensor Health function. If the frequency is set to a low value and a second run is scheduled before the first completes, the second run will not start until the first completes. 60 is the default, providing a check once an hour for all IDS sensors. Valid entries range from 1 to 1440 (24 hours) minutes.
|
Run Waiting Period
|
If this value is non-zero then, regardless of the Run Frequency, the Sensor Health function waits at least this period of time in minutes before running again. It ranges from 0 to 1440 minutes with a default of 15 minutes. If the Sensor Health function runs and exceeds the Run Frequency in elapsed time, the next invocation of the Sensor Health function will be scheduled Run Waiting Period from the end of the current run.
|
Scheduling Threshold
|
If a sensor has a pending deployment or signature update that will occur within this threshold (specified in minutes), it will not be included in the next run of the Sensor Health function. If there are sensors that are located on a slow network and the function takes a long time to complete, this value should be increased; doing so ensures that the function does not report false errors when the sensor is unavailable or unresponsive due to deployment or signature updates. The default for this field is 30 minutes. Valid entries range from 5 minutes to 1440 minutes.
|
Omit Sensor List
|
This is a comma-separated list of sensor names that will be omitted from status checks. If a sensor is down (for service or other reasons) the Sensor Health function does not need to check its status. Rather than generating errors for sensors that you know are not operating, you can add the sensor name to the Omit Sensor List so that those sensors are not reported upon. A warning reminds you that the sensors were not checked.
|
Max Number of Threads
|
The Sensor Health function is multi-threaded so that it can complete as quickly as possible. This setting restricts the number of threads and thus the number of concurrent connections to sensors. This could be needed if the IPS MC system is heavily loaded with connections and it runs out of sockets. The default for this field is 20 threads. The range for this value is from 1 to 25.
|
Dropped Packet Threshold
|
This setting is the number of packets that must be dropped before an error condition is said to exist. This value is initially set to 1, so that any dropped packets are considered an error condition that needs to be reported. This is a global value used for all sensors that are monitored by the Sensor Health function. This value has a range from 0 to 100. Setting this value to 0 means that dropped packets will not be considered an error and no check for dropped packets will be done. This setting is not applicable to IOS IPS devices.
|
Criticality Error Threshold
|
This value regulates the generation of errors according to resources on the sensor. When this value is met or exceeded for the Criticality Level in the analysis engine, an error is generated for the sensor. This is a global value used for all sensors that are monitored by this function. This value has a range of 1 to 100, with a default of 3. This setting is not applicable to IOS IPS devices.
|
Criticality Warning Threshold
|
This value regulates the issuance of warnings according to resources on the sensor. The default for this value is 1, in which case a value here of CriticalityErrorThreshold-1 will generate a warning for the sensor. This is a global value used for all sensors that are monitored by this tool. This value has a legal range of 1 to 100, with a default of 1. This setting is not applicable to IOS IPS devices.
|
To configure the Sensor Health function, follow these steps:
Step 1 Select Admin > System Configuration.
Step 2 In the TOC, select Sensor Health.
The Sensor Health page appears.
Step 3 To enable the Sensor Health function, select the Enable check box.
Step 4 To configure one or more email addresses to receive summary information, enter them as comma-separated values in Email Address for Summary Information.
Step 5 To configure one or more email addresses to receive error information, enter them as comma-separated values in Email Address for Errors Only.
Step 6 To enable the sending of individual fault messages, select the Send Email For Individual Errors check box.
Step 7 To send status information to the Progress Viewer, select the Send to Progress Viewer check box.
Step 8 To send status information to the Audit Log, select the Send to Audit Log check box.
Step 9 Specify the Run Frequency with a value, in minutes, for how often you want the health of your sensors checked.
Step 10 Specify the Run Waiting Period with a value in minutes.
Step 11 Specify the Scheduling Threshold with a value in minutes.
Step 12 To specify sensors to be omitted from Sensor Health monitoring, list them as comma-separated values in the Omit Device List.
Step 13 Specify the Max Number of Threads.
Step 14 Specify the Dropped Packet Threshold.
Tip The Dropped Packet Threshold field does not apply to IOS devices.
Step 15 Specify the Criticality Error Threshold.
Tip The Criticality Error Threshold field does not apply to IOS devices.
Step 16 Specify the Criticality Warning Threshold.
Tip The Criticality Warning Threshold field does not apply to IOS devices.
Step 17 Click Apply.
The new Sensor Health configuration is saved.
Understanding Cisco Incident Control System Support
Cisco Incident Control System (Cisco ICS), provided through Cisco Incident Control Center (Cisco ICC), enables extended protection across Cisco IOS routers [2.002(001)IOS in version 12.4(4)T and later], switches, and IPS devices.
In coordination with Trend Micro's incident control solutions, Cisco ICS prevents the spread of day-zero outbreaks in three ways:
1. Cisco ICS issues temporary ACLs to those Cisco mitigation devices that can block such traffic, typically using a protocol and port pair block. This temporary block is referred to as an Outbreak Prevention Access Control List (OPACL) and is expected to deploy within 30 minutes of an outbreak detection.
2. As soon as a signature is available, Cisco ICS updates all Cisco IPS devices running on your network with the signature required to detect and prevent the specific threat. This signature is referred to as an Outbreak Prevention Signature (OPSig) and should be available within 2 hours of outbreak detection.
3. Updated signatures are developed and made available from Cisco.com (for more information on updates, see Using Update Files, page 8-1). This updated signature renders the OPSig obsolete.
For more detailed information on Cisco ICS go to http://www.cisco.com/go/ics.
Beginning with version 2.2, IPS MC supports Cisco ICS in the following ways:
•Views OPACLs and OPSIGs.
•Pre-populates the IPS MC database with 2.002(001) default configuration, to reflect the multi-string engine. All the Trend Micro OPSigs use this engine, which was introduced in the IPS Sensors 5.1+.
•Imports OPACL and OPSIG configurations from a device.
•Edits, tunes, and deploys OPSIGs.
•Performs configuration difference (config diff) operations on OPSIG configurations.
•Enables copies of OPSIGs to IOS IPS devices.
•Indicates on the signature summary page whether a signature has been rendered obsolete.
In IPS MC, the OPACLs carry Sig ID 50000 with SubSig ID 0, 1, or 2. OPSIGs carry a Sig ID between 50001 and 59,999. Default signatures are designated with the S aspect; and secondary signatures, including the OPACLs and OPSIGs, are designated with the V aspect. To determine the aspect (or version level) of a device's signature, on the Sensor page, position your mouse over the sensor icon and read the attributes, including version, from the yellow tooltip box that appears.
You can also read version information from the corresponding Identification page in the Configuration Settings area.
