Caution The BIOS on Cisco IDS/IPS sensors is specific to Cisco IDS/IPS sensors and must only be upgraded under instructions from Cisco with BIOS files obtained from the Cisco website. Installing a non-Cisco or third-party BIOS on Cisco IDS/IPS sensors voids the warranty. For more information on how to obtain instructions and BIOS files from the Cisco website, see
Obtaining Cisco IPS Software.

Bug Toolkit

For the most complete and up-to-date list of caveats, use the Bug Toolkit to refer to the caveat release note. You can use the Bug Toolkit to search for known bugs based on software version, feature set, and keywords. The resulting matrix shows when each bug was integrated, or fixed if applicable. It also lets you save the results of a search in Bug Groups, and also create persistent Alert Agents that can feed those groups with new defect alerts.

Note You must be logged in to Cisco.com to access the Bug Toolkit.

If you are a registered Cisco.com user, you can view the Bug Toolkit at this URL:

Preventive Maintenance Actions

•Back up a good configuration. If your current configuration becomes unusable, you can replace it with the backup version.

•Save your backup configuration to a remote system.

•Always back up your configuration before you do a manual upgrade. If you have auto upgrades configured, make sure you do periodic backups.

•Create a service account.

A service account is needed for special debug situations directed by TAC.

Caution You should carefully consider whether you want to create a service account. The service account provides shell access to the system, which makes the system vulnerable. Analyze your situation to decide if you want a service account existing on the system.

Creating and Using a Backup Configuration File

To protect your configuration, you can back up the current configuration and then display it to confirm that is the configuration you want to save. If you need to restore this configuration, you can merge the backup configuration file with the current configuration or overwrite the current configuration file with the backup configuration file.

To back up your current configuration, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Save the current configuration.

sensor# copy current-config backup-config

The current configuration is saved in a backup file.

Step 3 Display the backup configuration file.

sensor# more backup-config

The backup configuration file is displayed.

Step 4 You can either merge the backup configuration with the current configuration, or you can overwrite the current configuration:

•Merge the backup configuration in to the current configuration.

sensor# copy backup-config current-config

•Overwrite the current configuration with the backup configuration.

sensor# copy /erase backup-config current-config

Backing Up and Restoring the Configuration File Using a Remote Server

Note We recommend copying the current configuration file to a remote server before upgrading.

Use the copy [/erase] source_url destination_urlkeyword command to copy the configuration file to a remote server. You can then restore the current configuration from the remote server. You are prompted to back up the current configuration first.

Options

The following options apply:

•/erase—Erases the destination file before copying.

This keyword only applies to the current-config; the backup-config is always overwritten. If this keyword is specified for destination current-config, the source configuration is applied to the system default configuration. If it is not specified for the destination current-config, the source configuration is merged with the current-config.

•source_url—The location of the source file to be copied. It can be a URL or keyword.

•destination_url—The location of the destination file to be copied. It can be a URL or a keyword.

•current-config—The current running configuration. The configuration becomes persistent as the commands are entered.

•backup-config—The storage location for the configuration backup.

The exact format of the source and destination URLs varies according to the file. Here are the valid types:

•ftp:—Source or destination URL for an FTP network server. The syntax for this prefix is:

ftp:[//[username@] location]/relativeDirectory]/filename

ftp:[//[username@]location]//absoluteDirectory]/filename

•scp:—Source or destination URL for the SCP network server. The syntax for this prefix is:

scp:[//[username@] location]/relativeDirectory]/filename

scp:[//[username@] location]//absoluteDirectory]/filename

Note If you use FTP or SCP protocol, you are prompted for a password. If you use SCP protocol, you must also add the remote host to the SSH known hosts list.

•http:—Source URL for the web server. The syntax for this prefix is:

http:[[/[username@]location]/directory]/filename

•https:—Source URL for the web server. The syntax for this prefix is:

https:[[/[username@]location]/directory]/filename

Note HTTP and HTTPS prompt for a password if a username is required to access the website. If you use HTTPS protocol, the remote host must be a TLS trusted host.

Caution Copying a configuration file from another sensor may result in errors if the sensing interfaces and virtual sensors are not configured the same.

Backing Up the Current Configuration to a Remote Server

To back up your current configuration to a remote server, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Warning: Replacing existing network-settings may leave the box in an unstable state.

Would you like to replace existing network settings
(host-ipaddress/netmask/gateway/access-list) on sensor before proceeding? [no]:

sensor#

Step 4 Enter no to retain the currently configured hostname, IP address, subnet mask, management interface, and access list. We recommend you retain this information to preserve access to your sensor after the rest of the configuration has been restored.

Creating the Service Account

You can create a service account for TAC to use during troubleshooting. Although more than one user can have access to the sensor, only one user can have service privileges on a sensor. The service account is for support purposes only.

Caution Do not make modifications to the sensor through the service account except under the direction of TAC. If you use the service account to configure the sensor, your configuration is not supported by TAC. Adding services to the operating system through the service account affects proper performance and functioning of the other IPS services. TAC does not support a sensor on which additional services have been added.

Note The root user password is synchronized to the service account password when the service account is created. To gain root access you must log in with the service account and switch to user root with the su - root command.

Caution You should carefully consider whether you want to create a service account. The service account provides shell access to the system, which makes the system vulnerable. However, you can use the service account to create a new password if the administrator password is lost. Analyze your situation to decide if you want a service account existing on the system.

To create the service account, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Enter configuration mode.

sensor# configure terminal

Step 3 Specify the parameters for the service account.

sensor(config)# userusernameprivilege service

The username follows the pattern ^[A-Za-z0-9()+:,_/-]+$, which means the username must start with a letter or number, and can include any letter A to Z (capital or small), any number 0 to 9, - and _, and can contain 1 to 64 characters.

Step 4 Specify a password when prompted.

A valid password is 8 to 32 characters long. All characters except space are allowed. If a service account already exists for this sensor, the following error is displayed and no service account is created:

Error: Only one service account may exist

Step 5 Exit configuration mode.

sensor(config)# exit

sensor#

When you use the service account to log in to the CLI, you receive the following warning:

UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. This account is intended to be
used for support and troubleshooting purposes only. Unauthorized modifications are not
supported and will require this device to be reimaged to guarantee proper operation.

Password Recovery

For most IPS platforms, you can now recover the password on the sensor rather than using the service account or reimaging the sensor. This section describes how to recover the password for the various IPS platforms. It contains the following topics:

Understanding Password Recovery

Password recovery implementations vary according to IPS platform requirements. Password recovery is implemented only for the cisco administrative account and is enabled by default. The IPS administrator can then recover user passwords for other accounts using the CLI. The cisco user password reverts to cisco and must be changed after the next login.

Note Administrators may need to disable the password recovery feature for security reasons.

Password Recovery for the IDSM2

To recover the password for the IDSM2, you must install a special password recovery image file. This installation only resets the password, all other configuration remains intact. The password recovery image is version-dependent and can be found on the Cisco Download Software site. For IPS 6.x, download WS-SVC-IDSM2-K9-a-6.0-password-recovery.bin.gz. For IPS 7.x, download WS-SVC-IDSM2-K9-a-7.0-password-recovery.bin.gz.

FTP is the only supported protocol for image installations, so make sure you put the password recovery image file on an FTP server that is accessible to the switch. You must have administrative access to the Cisco 6500 series switch to recover the password on the IDSM2.

During the password recovery image installation, the following message appears:

Upgrading will wipe out the contents on the hard disk.

Do you want to proceed installing it [y|n]:

This message is in error. Installing the password recovery image does not remove any configuration, it only resets the login account.

Once you have downloaded the password recovery image file, follow the instructions to install the system image file but substitute the password recovery image file for the system image file. The IDSM2 should reboot in to the primary partition after installing the recovery image file. If it does not, enter the following command from the switch:

hw-module module module_number reset hdd:1

Note The password is reset to cisco. Log in to the CLI with username cisco and password cisco. You can then change the password.

Password Recovery for the AIP SSM

You can reset the password to the default (cisco) for the AIP SSM using the CLI or the ASDM. Resetting the password causes it to reboot. IPS services are not available during a reboot.

Note To reset the password, you must have ASA 7.2.2 or later.

Use the hw-module moduleslot_numberpassword-reset command to reset the password to the default cisco. If the module in the specified slot has an IPS version that does not support password recovery, the following error message is displayed:

ERROR: the module in slot <n> does not support password recovery.

To reset the password on the AIP SSM, follow these steps:

Step 1 Log into the adaptive security appliance and enter the following command to verify the module slot number:

This product contains cryptographic features and is subject to United States and local
country laws governing import, export, transfer and use. Delivery of Cisco cryptographic
products does not imply third-party authority to import, export, distribute or use
encryption. Importers, exporters, distributors and users are responsible for compliance
with U.S. and local country laws. By using this product you agree to comply with
applicable laws and regulations. If you are unable to comply with U.S. and local laws,
return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to export@cisco.com.

***LICENSE NOTICE***

There is no license key installed on this IPS platform. The system will continue to
operate with the currently installed signature set. A valid license must be obtained in
order to apply signature updates. Please go to http://www.cisco.com/go/license to obtain a
new license or install a license.

aip_ssm#

Using the ASDM

To reset the password in the ASDM, follow these steps:

Step 1 From the ASDM menu bar, choose Tools > IPS Password Reset.

Note This option does not appear in the menu if there is no IPS present.

Step 2 In the IPS Password Reset confirmation dialog box, click OK to reset the password to the default (cisco). A dialog box displays the success or failure of the password reset. If the reset fails, make sure you have the correct ASA and IPS software versions.

Step 3 Click Close to close the dialog box. The sensor reboots.

Password Recovery for the AIM IPS

To recover the password for the AIM IPS, use the clear password command. You must have console access to the AIM IPS and administrative access to the router.

To recover the password for the AIM IPS, follow these steps:

Step 1 Log in to the router.

Step 2 Enter privileged EXEC mode on the router.

router> enable

Step 3 Confirm the module slot number in your router.

router# show run | include ids-sensor

interface IDS-Sensor0/0

router#

Step 4 Session in to the AIM IPS.

router# service-moduleids-sensorslot/port session

Example:

router# service-moduleids-sensor 0/0 session

Step 5 Press Control-shift-6 followed by x to navigate to the router CLI.

Step 6 Reset the AIM IPS from the router console.

router# service-moduleids-sensor0/0 reset

Step 7 Press Enter to return to the router console.

Step 8 When prompted for boot options, enter *** quickly. You are now in the bootloader.

Step 9 Clear the password.

ServicesEngine boot-loader# clear password

The AIM IPS reboots. The password is reset to cisco. Log in to the CLI with username cisco and password cisco. You can then change the password.

Disabling Password Recovery

Caution If you try to recover the password on a sensor on which password recovery is disabled, the process proceeds with no errors or warnings, however, the password is not reset. If you cannot log in to the sensor because you have forgotten the password, and password recovery is set to disabled, you must reimage your sensor.

Password recovery is enabled by default. You can disable password recovery through the CLI or IDM.

To disable password recovery in the CLI, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Enter global configuration mode.

sensor# configure terminal

Step 3 Enter host mode.

sensor(config)# service host

Step 4 Disable password recovery.

sensor(config-hos)# password-recovery disallowed

To disable password recovery in IDM, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Verifying the State of Password Recovery

Use the show settings | include password command to verify whether password recovery is enabled.

To verify whether password recovery is enabled, follow these steps:

Step 1 Log in to the CLI.

Step 2 Enter service host submode.

sensor# configure terminal

sensor (config)# service host

sensor (config-hos)#

Step 3 Verify the state of password recovery by using the include keyword to show settings in a filtered output.

sensor(config-hos)# show settings | include password

password-recovery: allowed <defaulted>

sensor(config-hos)#

Troubleshooting Password Recovery

To troubleshoot password recovery, pay attention to the following:

•You cannot determine whether password recovery has been disabled in the sensor configuration from the ROMMON prompt, GRUB menu, switch CLI, or router CLI. If password recovery is attempted, it always appears to succeed. If it has been disabled, the password is not reset to cisco. The only option is to reimage the sensor.

•You can disable password recovery in the host configuration, so for the platforms that use external mechanisms, such as the NM CIDS bootloader, ROMMON, and the maintenance partition for the IDSM2, although you can run commands to clear the password, if password recovery is disabled in the IPS, the IPS detects that password recovery is not allowed and rejects the external request.

•To check the state of password recovery, use the show settings | include password command.

•When performing password recovery for the NM CIDS, do not use the reboot command to restart the NM CIDS. This causes the recovery action to be ignored. Use the boot disk command.

•When performing password recovery on the IDSM2, you see the following message: Upgrading will wipe out the contents on the storage media. You can ignore this message. Only the password is reset when you use the specified password recovery image.

Correcting Time on the Sensor

If you set the time incorrectly, your stored events will have the incorrect time because they are stamped with the time the event was created.

The Event Store time stamp is always based on UTC time. If during the original sensor setup, you set the time incorrectly by specifying 8:00 p.m. rather than 8:00 a.m., when you do correct the error, the corrected time will be set backwards. New events might have times older than old events.

For example, if during the initial setup, you configure the sensor as central time with daylight saving time enabled and the local time is 8:04 p.m., the time is displayed as 20:04:37 CDT and has an offset from UTC of -5 hours (01:04:37 UTC, the next day). A week later at 9:00 a.m., you discover the error: the clock shows 21:00:23 CDT. You then change the time to 9:00 a.m. and now the clock shows 09:01:33 CDT. Because the offset from UTC has not changed, it requires that the UTC time now be 14:01:33 UTC, which creates the time stamp problem.

To ensure the integrity of the time stamp on the event records, you must clear the event archive of the older events by using the clear events command.

Note MIB II is available on the sensor, but we do not support it. We know that some elements are not correct (for example, the packet counts from the IF MIB on the sensing interfaces). While you can use elements from MIB II, we do not guarantee that they all provide correct information. We fully support the other listed MIBs and their output is correct.

Note CISCO-PROCESS-MIB is available on the sensor, but we do not support it. We know that some elements are not available. While you can use elements from CISCO-PROCESS-MIB, we do not guarantee that they all provide correct information. We fully support the other listed MIBs and their output is correct.

When to Disable Anomaly Detection

If you have your sensor configured to see only one direction of traffic, you should disable anomaly detection. Otherwise, you will receive many alerts, because anomaly detection sees asymmetric traffic as having incomplete connections, that is, like worm scanners, and fires alerts.

To disable anomaly detection, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Enter analysis engine submode.

sensor# configure terminal

sensor(config)# service analysis-engine

sensor(config-ana)#

Step 3 Enter the virtual sensor name that contains the anomaly detection policy you want to disable.

sensor(config-ana)# virtual-sensor vs0

sensor(config-ana-vir)#

Step 4 Disable anomaly detection operational mode.

sensor(config-ana-vir)# anomaly-detection

sensor(config-ana-vir-ano)# operational-mode inactive

sensor(config-ana-vir-ano)#

Step 5 Exit analysis engine submode.

sensor(config-ana-vir-ano)# exit

sensor(config-ana-vir)# exit

sensor(config-ana-)# exit

Apply Changes:?[yes]:

Step 6 Press Enter to apply your changes or enter no to discard them.

For More Information

For more information on anomaly detection asymmetric traffic and worms, see Worms.

External Product Interfaces Troubleshooting Tips

To troubleshoot external product interfaces, check the following:

•Make sure the interface is active by checking the output from the show statistics external-product-interface command in the CLI or by choosing IDM Monitor > Statistics in IDM. Check the Interface state line in the response.

•Make sure you have added the CSA MC IP address to the trusted hosts. If you forgot to add it, add it, wait a few minutes and then check again.

•Confirm subscription login information by opening and closing a subscription on CSA MC using the browser.

PIX 7.1 Devices and Normalizer Inline Mode

For IPS 5.0, 5.1, and 6.0, normalizer inline mode may deny packets and/or connections if a PIX 7.1 device is in the traffic flow and the PIX device has been configured for the MSS workaround as documented at:

Certain web applications on port 80 cause the PIX device to require the MSS workaround. If that workaround is active, the IPS must have a complimentary workaround.

Problem There is an incompatibility with PIX and IPS when the PIX MSS workaround has been applied. The show stat vi command shows many deny packet or deny connection actions along with many 13xx signature firings.

Solution Disable or remove all actions from the following normalizer signatures: 1306 and 1311.

Troubleshooting the 4200 Series Appliance

Tip Before troubleshooting the appliance, check the Caveats section of the Readme for the software version you have installed on your sensor to see if you are dealing with a known issue.

This section contains information to troubleshoot the 4200 series appliance, and contains the following topics:

Analysis Engine is Busy

After you reimage a sensor, Analysis Engine is busy rebuilding Regex tables and does not respond to new configurations. You can check whether Analysis Engine is busy by using the show statistics virtual-sensor command. You receive the following error message if Analysis Engine is busy:

sensor# show statistics virtual-sensor

Error: getVirtualSensorStatistics : Analysis Engine is busy rebuilding regex tables. This
may take a while.

sensor#

When Analysis Engine is busy rebuilding Regex tables, you receive an error message if you try to update a configuration, for example, enabling or retiring a signature:

sensor# configure terminal

sensor(config)# service sig sig0

sensor(config-sig)# sig 2000 0

sensor(config-sig-sig)# status enabled

sensor(config-sig-sig)# status

sensor(config-sig-sig-sta)# enabled true

sensor(config-sig-sig-sta)# retired false

sensor(config-sig-sig-sta)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes?[yes]:

Error: editConfigDeltaSignatureDefinition : Analysis Engine is busy rebuilding regex
tables. This may take a while.

The configuration changes failed validation, no changes were applied.

Would you like to return to edit mode to correct the errors? [yes]: no

No changes were made to the configuration.

sensor(config)#

If you try to get the virtual sensor statistics immediately after you boot a sensor, you receive an error message. Although the sensor has rebuilt the cache files, the virtual sensor is not finished initializing.

sensor# show statistics virtual-sensor

Error: getVirtualSensorStatistics : Analysis Engine is busy.

sensor#

When you receive the errors that Analysis Engine is busy, wait a while before trying to make configuration changes. Use the show statistics virtual-sensor command to find out when Analysis Engine is available again.

Connecting IPS-4240 to a Cisco 7200 Series Router

When an IPS 4240 is connected directly to a 7200 series router and both the IPS 4240 and the router interfaces are hard-coded to speed 100 with duplex Full, the connection does not work. If you set the IPS 4240 to speed Auto and duplex Auto, it connects to the router but only at speed 100 and duplex Half.

To connect correctly at speed 100 and duplex Full, set the interfaces of both the IPS 4240 and the router to speed Auto and duplex Auto. Also, if either interface is hard-coded, you must make the connection using a crossover cable.

Communication Problems

This section helps you troubleshoot communication problems with the 4200 series sensor. It contains the following topics:

Cannot Access the Sensor CLI Through Telnet or SSH

If you cannot access the sensor CLI through Telnet (if you already have it enabled) or SSH, follow these steps:

Step 1 Log in to the sensor CLI through a console, terminal, or module session.

Step 2 Make sure that the sensor management interface is enabled.

sensor# show interfaces

Interface Statistics

Total Packets Received = 0

Total Bytes Received = 0

Missed Packet Percentage = 0

Current Bypass Mode = Auto_off

MAC statistics from interface GigabitEthernet0/1

Media Type = backplane

Missed Packet Percentage = 0

Inline Mode = Unpaired

Pair Status = N/A

Link Status = Up

Link Speed = Auto_1000

Link Duplex = Auto_Full

Total Packets Received = 0

Total Bytes Received = 0

Total Multicast Packets Received = 0

Total Broadcast Packets Received = 0

Total Jumbo Packets Received = 0

Total Undersize Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 0

Total Bytes Transmitted = 0

Total Multicast Packets Transmitted = 0

Total Broadcast Packets Transmitted = 0

Total Jumbo Packets Transmitted = 0

Total Undersize Packets Transmitted = 0

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

MAC statistics from interface GigabitEthernet0/0

Media Type = TX

Link Status = Up

Link Speed = Auto_100

Link Duplex = Auto_Full

Total Packets Received = 944333

Total Bytes Received = 83118358

Total Multicast Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 397633

Total Bytes Transmitted = 435730956

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

sensor#

The management interface is the interface in the list with the status line Media Type = TX. If the Link Status is Down, go to Step 3. If the Link Status is Up, go to Step 5.

Step 3 Make sure the sensor IP address is unique.

sensor# setup

--- System Configuration Dialog ---

At any point you may enter a question mark '?' for help.

User ctrl-c to abort configuration dialog at any prompt.

Default settings are in square brackets '[]'.

Current Configuration:

service host

network-settings

host-ip 10.89.130.108/23,10.89.130.1

host-name sensor

telnet-option enabled

access-list 0.0.0.0/0

ftp-timeout 300

no login-banner-text

exit

If the management interface detects that another device on the network has the same IP address, it does not come up.

Step 4 Make sure the management port is connected to an active network connection.

If the management port is not connected to an active network connection, the management interface does not come up.

Step 5 Make sure the IP address of the workstation that is trying to connect to the sensor is permitted in the sensor access list.

sensor# setup

--- System Configuration Dialog ---

At any point you may enter a question mark '?' for help.

User ctrl-c to abort configuration dialog at any prompt.

Default settings are in square brackets '[]'.

Current Configuration:

service host

network-settings

host-ip 10.89.130.108/23,10.89.130.1

host-name sensor

telnet-option enabled

access-list 0.0.0.0/0

ftp-timeout 300

no login-banner-text

exit

--MORE--

If the workstation network address is permitted in the sensor access list, go to Step 6.

Step 6 Add a permit entry for the workstation network address, save the configuration, and try to connect again.

Step 7 Make sure the network configuration allows the workstation to connect to the sensor.

If the sensor is protected behind a firewall and the workstation is in front of the firewall, make sure the firewall is configured to allow the workstation to access the sensor. Or if the workstation is behind a firewall that is performing network address translation on the workstation IP address, and the sensor is in front of the firewall, make sure that the sensor access list contains a permit entry for the workstation translated address.

Duplicate IP Address Shuts Interface Down

If you have two newly imaged sensors with the same IP address that come up on the same network at the same time, the interface shuts down. Linux prevents the command and control interface from activating if it detects an address conflict with another host.

To verify that the sensor in question does not have an IP address conflict with another host on the network, follow these steps:

Step 1 Log in to the CLI.

Step 2 Determine whether the interface is up.

sensor# show interfaces

Interface Statistics

Total Packets Received = 0

Total Bytes Received = 0

Missed Packet Percentage = 0

Current Bypass Mode = Auto_off

MAC statistics from interface GigabitEthernet0/1

Media Type = backplane

Missed Packet Percentage = 0

Inline Mode = Unpaired

Pair Status = N/A

Link Status = Up

Link Speed = Auto_1000

Link Duplex = Auto_Full

Total Packets Received = 0

Total Bytes Received = 0

Total Multicast Packets Received = 0

Total Broadcast Packets Received = 0

Total Jumbo Packets Received = 0

Total Undersize Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 0

Total Bytes Transmitted = 0

Total Multicast Packets Transmitted = 0

Total Broadcast Packets Transmitted = 0

Total Jumbo Packets Transmitted = 0

Total Undersize Packets Transmitted = 0

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

MAC statistics from interface GigabitEthernet0/0

Media Type = TX

Link Status = Up

Link Speed = Auto_100

Link Duplex = Auto_Full

Total Packets Received = 1822323

Total Bytes Received = 131098876

Total Multicast Packets Received = 20

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 219260

Total Bytes Transmitted = 103668610

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

sensor#

If the output says the command and control interface link status is down, there is a hardware issue or an IP address conflict.

Unable to See Alerts

If you are not seeing alerts, try the following:

•Make sure the signature is enabled.

•Make sure the signature is not retired.

•Make sure that you have Produce Alert configured as an action.

Note If you choose Produce Alert, but come back later and add another event action and do not add Produce Alert to the new configuration, alerts are not be sent to the Event Store. Every time you configure a signature, the new configuration overwrites the old one, so make sure you have configured all the event actions you want for each signature.

Bad Memory on the IDS 4250-XL

Some IDS 4250-XLs were shipped with faulty DIMMs on the XL cards. The faulty DIMMs cause the sensor to hang or SensorApp to stop functioning and generate a core file. For the procedure for checking the IDS 4250-XL for faulty memory, refer to Partner Field Notice 52563.

Blocking

This section provides troubleshooting help for blocking and the ARC service. It contains the following topics.

Troubleshooting Blocking

After you have configured ARC, you can verify if it is running properly by using the show version command. To verify that ARC is connecting to the network devices, use the show statistics network-access command.

Note ARC was formerly known as Network Access Controller. Although the name has been changed since IPS 5.1, it still appears in IDM and the CLI as Network Access Controller, nac, and network-access.

To troubleshoot ARC, follow these steps:

1. Verify that ARC is running.

2. Verify that ARC is connecting to the network devices.

3. Verify that the Event Action is set to Block Host for specific signatures.

Device Access Issues

ARC may not be able to access the devices it is managing. Make sure the you have the correct IP address and username and password for the managed devices and the correct interface and direction configured.

Note SSH devices must support SSH 1.5. The sensor does not support SSH 2.0.

To troubleshoot device access issues, follow these steps:

Step 1 Log in to the CLI.

Step 2 Verify the IP address for the managed devices.

sensor# configure terminal

sensor (config)# service network-access

sensor(config-net)# show settings

general

-----------------------------------------------

log-all-block-events-and-errors: true <defaulted>

enable-nvram-write: false <defaulted>

enable-acl-logging: false <defaulted>

allow-sensor-block: false <defaulted>

block-enable: true <defaulted>

block-max-entries: 250 <defaulted>

max-interfaces: 250 <defaulted>

master-blocking-sensors (min: 0, max: 100, current: 0)

-----------------------------------------------

-----------------------------------------------

never-block-hosts (min: 0, max: 250, current: 0)

-----------------------------------------------

-----------------------------------------------

never-block-networks (min: 0, max: 250, current: 0)

-----------------------------------------------

-----------------------------------------------

block-hosts (min: 0, max: 250, current: 0)

-----------------------------------------------

-----------------------------------------------

block-networks (min: 0, max: 250, current: 0)

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

user-profiles (min: 0, max: 250, current: 1)

-----------------------------------------------

profile-name: r7200

-----------------------------------------------

enable-password: <hidden>

password: <hidden>

username: netrangr default:

-----------------------------------------------

-----------------------------------------------

cat6k-devices (min: 0, max: 250, current: 0)

-----------------------------------------------

-----------------------------------------------

router-devices (min: 0, max: 250, current: 1)

-----------------------------------------------

ip-address: 10.89.147.54

-----------------------------------------------

communication: telnet default: ssh-3des

nat-address: 0.0.0.0 <defaulted>

profile-name: r7200

block-interfaces (min: 0, max: 100, current: 1)

-----------------------------------------------

interface-name: fa0/0

direction: in

-----------------------------------------------

pre-acl-name: <defaulted>

post-acl-name: <defaulted>

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

-----------------------------------------------

firewall-devices (min: 0, max: 250, current: 0)

-----------------------------------------------

-----------------------------------------------

sensor(config-net)#

Step 3 Manually connect to the device to make sure you have used the correct username, password, and enable password, and to ensure that the device is reachable from the sensor:

a. Log in to the service account.

b. Telnet or SSH to the network device to verify the configuration.

c. Make sure you can reach the device.

d. Verify the username and password.

Step 4 Verify that each interface and direction on each network device is correct.

Verifying the Interfaces and Directions on the Network Device

To verify that each interface and direction on each controlled device is correct, you can send a manual block to a bogus host and then check to see if deny entries exist for the blocked addresses in the ACL of the router.

Verifying the Master Blocking Sensor Configuration

To verify that a master blocking sensor is set up properly or to troubleshoot a master blocking sensor that is not set up properly, you can use the show statistics network-access command. Make sure that the forwarding sensor is set up as TLS trusted host if the remote master blocking sensor is using TLS for web access.

To verify a master blocking sensor configuration, follow these steps:

Step 1 View the ARC statistics and verify that the master blocking sensor entries are in the statistics.

sensor# show statistics network-access

Current Configuration

AllowSensorShun = false

ShunMaxEntries = 250

MasterBlockingSensor

SensorIp = 10.89.149.46

SensorPort = 443

UseTls = 1

State

ShunEnable = true

ShunnedAddr

Host

IP = 122.122.122.44

ShunMinutes = 60

MinutesRemaining = 59

Step 2 If the master blocking sensor does not show up in the statistics, you need to add it.

Step 3 Initiate a manual block to a bogus host IP address to make sure the master blocking sensor is initiating blocks.

sensor# configure terminal

sensor(config)# service network-access

sensor(config-net)# general

sensor(config-net-gen)# block-hosts 10.16.0.0

Step 4 Exit network access general submode.

sensor(config-net-gen)# exit

sensor(config-net)# exit

Apply Changes:? [yes]:

Step 5 Press Enter to apply the changes or type no to discard them.

Step 6 Verify that the block shows up in the ARC statistics.

sensor# show statistics network-access

Current Configuration

AllowSensorShun = false

ShunMaxEntries = 100

State

ShunEnable = true

ShunnedAddr

Host

IP = 10.16.0.0

ShunMinutes =

Step 7 Log in to the CLI of the master blocking sensor host, and using the show statistics network-access command, verify that the block also shows up in the master blocking sensor ARC statistics.

sensor# show statistics network-access

Current Configuration

AllowSensorShun = false

ShunMaxEntries = 250

MasterBlockingSensor

SensorIp = 10.89.149.46

SensorPort = 443

UseTls = 1

State

ShunEnable = true

ShunnedAddr

Host

IP = 10.16.0.0

ShunMinutes = 60

MinutesRemaining = 59

Step 8 If the remote master blocking sensor is using TLS for web access, make sure the forwarding sensor is configured as a TLS host.

Logging

TAC may suggest that you turn on debug logging for troubleshooting purposes. LogApp controls what log messages are generated by each application by controlling the logging severity for different logging zones. By default, debug logging is not turned on.

If you enable individual zone control, each zone uses the level of logging that it is configured for. Otherwise, the same logging level is used for all zones.

The syslog output is sent to the syslog facility local6 with the following correspondence to syslog message priorities:

LOG_DEBUG, // debug

LOG_INFO, // timing

LOG_WARNING, // warning

LOG_ERR, // error

LOG_CRIT // fatal

Note Make sure that your /etc/syslog.conf has that facility enabled at the proper priority.

Caution The syslog is much slower than logApp (about 50 messages per second as opposed to 1000 or so). We recommend that you enable debug severity on one zone at a time.

Verifying the Sensor is Synchronized with the NTP Server

In IPS 6.0, you cannot apply an incorrect NTP configuration, such as an invalid NTP key value or ID, to the sensor. If you try to apply an incorrect configuration, you receive an error message. To verify the NTP configuration, use the show statisticshost command to gather sensor statistics. The NTP statistics section provides NTP statistics including feedback on sensor synchronization with the NTP server.

To verify the NTP configuration, follow these steps:

Step 1 Log in to the sensor.

Step 2 Generate the host statistics.

sensor# show statistics host

...

NTP Statistics

remote refid st t when poll reach delay offset jitter

11.22.33.44 CHU_AUDIO(1) 8 u 36 64 1 0.536 0.069 0.001

LOCAL(0) 73.78.73.84 5 l 35 64 1 0.000 0.000 0.001

ind assID status conf reach auth condition last_event cnt

1 10372 f014 yes yes ok reject reachable 1

2 10373 9014 yes yes none reject reachable 1

status = Not Synchronized

...

Step 3 Generate the hosts statistics again after a few minutes.

sensor# show statistics host

...

NTP Statistics

remote refid st t when poll reach delay offset jitter

*11.22.33.44 CHU_AUDIO(1) 8 u 22 64 377 0.518 37.975 33.465

LOCAL(0) 73.78.73.84 5 l 22 64 377 0.000 0.000 0.001

ind assID status conf reach auth condition last_event cnt

1 10372 f624 yes yes ok sys.peer reachable 2

2 10373 9024 yes yes none reject reachable 2

status = Synchronized

Step 4 If the status continues to read Not Synchronized, check with the NTP server administrator to make sure the NTP server is configured correctly.

TCP Reset Not Occurring for a Signature

If you do not have the event action set to reset, the TCP reset does not occur for a specific signature.

To troubleshoot a reset not occurring for a specific signature, follow these steps:

If you receive this error, you must get AnalysisEngine running before trying to upgrade again. This error is often caused by a defect in the currently running version. Try rebooting the sensor, and after reboot, run setup and remove the interfaces from the virtual sensor vs0. When it is not monitoring traffic, AnalysisEngine usually stays up and running. You can upgrade to 6.0 at this time. After the upgrade to 6.0, add the interfaces back to the virtual sensor vs0 using the setup command.

Or you can use the recovery CD (if your sensor has a CD-ROM) or the system image file to reimage directly to 6.0. You can reimage a 5.x sensor to 6.0 because the reimage process does not check to see AnalysisEngine is running.

Caution Reimaging using the CD or system image file restores all configuration defaults.

Which Updates to Apply and Their Prerequisites

You must have the correct service pack and minor and major version of the software. If you are having trouble with applying new software, make sure that you are applying the proper updates with the proper prerequisites:

•Signature updates require the minimum version listed in the filename.

Increasing the Memory Size of the Java Plug-In

Caution This section applies to IPS 6.0 only. If you have upgraded to IPS 6.0(2), you can disregard this section.

To correctly run IDM, your browser must have Java Plug-in 1.4.2 or 1.5 installed. By default the Java Plug-in allocates 64 MB of memory to IDM. IDM can run out of memory while in use, which can cause IDM to freeze or display blank screens. Running out of memory can also occur when you click Refresh. An OutofMemoryError message appears in the Java console whenever this occurs. You must change the memory settings of Java Plug-in before using IDM. The mandatory minimum memory size is 256 MB.

Note We recommend that you use Sun Microsystems Java. Using any other version of Java could cause problems with IDM.

Note In the Java 2 SDK, this file is located at <SDK installation directory>/jre/bin/ControlPanel. For example if your Java 2 SDK is installed at /usr/j2se, the full path is /usr/j2se/jre/bin/ControlPanel.

Note In a Java 2 Runtime Environment installation, the file is located at <JRE installation directory>/bin/ControlPanel.

Step 3 If you have Java Plug-in 1.4.2 installed:

a. Click the Advanced tab.

b. In the Java RunTime Parameters field, enter -Xms256m.

c. Click Apply and close the Java Control Panel.

Step 4 If you have Java Plug-in 1.5 installed:

a. Click the Java tab.

b. Click View under Java Applet Runtime Settings.

c. In the Java Runtime Parameters field, enter -Xms256m, and then click OK.

Cannot Launch IDM - Loading Java Applet Failed

Possible Cause This condition can occur if multiple Java Plug-ins (1.4.x and/or 1.3.x) are installed on the machine on which you are launching the IDM.

Recommended Action Clear the Java cache and remove temp files and clear history in the browser you are using. The result is that neither of these plug-ins will be used by default and each applet should use the correct plug-in.

Cannot Launch IDM -Analysis Engine Busy

Possible Cause This condition can occur if the Analysis Engine in the sensor is busy getting ready to perform a task and so does not respond to IDM.

Recommended Action Wait for a while and try again to connect.

IDM, Remote Manager, or Sensing Interfaces Cannot Access the Sensor

If IDM, a remote manager, or sensing interfaces cannot access the sensor, but you can access the sensor CLI using SSH or Telnet (if enabled), follow these steps:

Step 1 Make sure the network configuration allows access to the web server port that is configured on the sensor:

sensor# setup

--- System Configuration Dialog ---

At any point you may enter a question mark '?' for help.

User ctrl-c to abort configuration dialog at any prompt.

Default settings are in square brackets '[]'.

Current Configuration:

service host

network-settings

host-ip 10.89.130.108/23,10.89.130.1

host-name sensor

telnet-option enabled

access-list 0.0.0.0/0

ftp-timeout 300

no login-banner-text

exit

time-zone-settings

offset 0

standard-time-zone-name UTC

exit

summertime-option disabled

ntp-option disabled

exit

service web-server

port 443

exit

Step 2 If network devices, such as routers, switches, or firewalls, are between the sensor and the workstation, make sure these devices are configured to allow the workstation to access the sensor web server port.

All remote management communication is performed by the sensor web server.

Signatures Not Producing Alerts

If you are not seeing any alerts when signatures are firing, make sure that you have configured Produce Alert as an event action.

Caution You cannot add other actions each time you configure the event actions. You are actually replacing the list of event actions every time you configure it, so make sure you choose Produce Alert every time you configure event actions.

For example, if you choose Produce Alert, but later add another event action and do not add Produce Alert to the new configuration, alerts are not sent to the Event Store.

To make sure you are getting alerts, run statistics for the virtual sensor and event store.

Diagnosing IDSM2 Problems

Use the following list to diagnose IDSM2 problems:

•The ribbon cable between the IDSM2 and the motherboard is loose.

During physical handling of the module, the connector can come loose from the base card, and cause the daughter card and the base card to lose contact with each other. A loose ribbon cable connector causes an on-line diagnostic error on ports 7 and 8. The module cannot operate when this condition exists. For more information, refer to Partner Field Notice 52816.

•Some IDSM2s were shipped with faulty DIMMs. For the procedure for checking the IDSM2 for faulty memory, refer to Partner Field Notice 52563.

•The hard-disk drive fails to read or write. When the hard-disk drive has been in constant use for extended periods of time (for more than 2 weeks), multiple symptoms, such as the following, can occur:

–An inability to log in

–I/O errors to the console when doing read/write operations (the ls command)

–Commands do not execute properly (cannot find the path to the executable)

The switch reports that the module is ok, but if you log in to the Service account and try to execute commands, you see that the problem exists. The 4.1(4) service pack alleviates this problem, but if you reimage the IDSM2 with the 4.1(4) application partition image, you must apply the 4.1(4b) patch. For more information, refer to CSCef12198.

•SensorApp either crashes or takes 99% of the CPU when IP logging is enabled for stream-based signatures (1300 series). For the workaround, refer to CSCed32093.

•The IDSM2 appears to lock up and remote access is prohibited (SSH, Telnet, IDM, Event Server, Control Transaction Server, and IP log Server). This defect is related to using SWAP. The IDSM2 responds to pings. Apply the 4.1(4) service pack to resolve this issue. For more information, refer to CSCed54146.

•Shortly after you upgrade the IDSM2 or you tune a signature with VMS, the IDSM2 becomes unresponsive and often produces a SensorApp core file. Apply the 4.1(4b) patch to fix this issue.

•Confirm that the IDSM2 has the supported configurations.

If you have confirmed that the IDSM2 does not suffer from any of the problems listed above and yet it appears unresponsive, for example, you cannot log in through SSH or Telnet, nor can you session to the switch, determine if the IDSM2 responds to pings and if you can log in through the service account. If you can log in, obtain a cidDump and any core files and contact TAC.

For More Information

•For information about the Bug Toolkit and how to access it, see Bug Toolkit.

Note It is normal for the status to read other when the IDSM2 is first installed. After the IDSM2 completes the diagnostics routines and comes online, the status reads ok. Allow up to 5 minutes for the IDSM2 to come online.

Step 3 If the status does not read ok, turn the module on.

router# set module power up module_number

Status LED On But the IDSM2 Does Not Come Online

If the status indicator is on, but the IDSM2 does not come online, try the following troubleshooting tips:

Using the TCP Reset Interface

The IDSM2 has a TCP reset interface—port 1. The IDSM2 has a specific TCP reset interface because it cannot send TCP resets on its sensing ports.

If you have reset problems with the IDSM2, and the switch is running Catalyst software, try the following:

•If the sensing ports are access ports (a single VLAN), you need to configure the reset port to be in the same VLAN.

•If the sensing ports are dot1q trunk ports (multi-VLAN), the sensing ports and reset port all must have the same native VLAN, and the reset port must trunk all the VLANs being trunked by both the sensing ports.

Note In Cisco IOS when the IDSM2 is in promiscuous mode, the IDSM2 ports are always dot1q trunk ports (even when monitoring only 1 VLAN), and the TCP reset port is automatically set to a trunk port and is not configurable.

Connecting a Serial Cable to the IDSM2

You can connect a serial cable directly to the serial console port on the IDSM2. This lets you bypass the switch and module network interfaces.

To connect a serial cable to the IDSM2, follow these steps:

Step 1 Locate the two RJ-45 ports on the IDSM2.

You can find them approximately in the center of the mother board. If you are facing the module faceplate, the RJ-45 port on the right is the serial console port.

Step 2 Connect a straight-through cable to the right port on the IDSM2, and then connect the other end of the cable to a terminal server port.

If you have problems with recovering the AIP SSM, use the debug module-boot command to see the output as the AIP SSM boots. Make sure you have the correct IP address for the TFTP server and you have the correct file on the TFTP server. Then use the hw-module module 1 recover command again to recover the AIP SSM:

Failover Scenarios

The following failover scenarios apply to the ASA in the event of configuration changes, signature/signature engine updates, service packs, and SensorApp crashes on the AIP SSM.

Single ASA in Fail-Open Mode

•If the ASA is configured in fail-open mode for the AIP SSM, and the AIP SSM experiences a configuration change or signature/signature engine update, traffic is passed through the ASA without being inspected.

•If the ASA is configured in fail-open mode for the AIP SSM, and the AIP SSM experiences a SensorApp crash or a service pack upgrade, traffic is passed through the ASA without being inspected.

Single ASA in Fail-Close Mode

•If the ASA is configured in fail-close mode for the AIP SSM, and the AIP SSM experiences a configuration change or a signature/signature engine update, traffic is stopped from passing through the ASA.

•If the ASA is configured in fail-close mode for the AIP SSM, and the AIP SSM experiences a SensorApp crash or a service pack upgrade, traffic is stopped from passing through the ASA.

Two ASAs in Fail-Open Mode

•If the ASAs are configured in fail-open mode and if the AIP SSM on the active ASA experiences a configuration change or a signature/signature engine update, traffic is still passed through the active ASA without being inspected. Failover is not triggered.

•If the ASAs are configured in fail-open mode, and if the AIP SSM on the active ASA experiences a SensorApp crash or a service pack upgrade, failover is triggered and traffic passes through the AIP SSM that was previously the standby module.

Two ASAs in Fail-Close Mode

•If the ASAs are configured in fail-close mode, and if the AIP SSM on the active ASA experiences a configuration change or a signature/signature engine update, traffic is stopped from passing through the active ASA. No failover is triggered.

•If the ASAs are configured in fail-close mode, and if the AIP SSM on the active ASA experiences a SensorApp crash or a service pack upgrade, failover is triggered and traffic passes through the module that was previously the standby for the AIP SSM.

The AIP SSM and the Data Plane

Symptom The AIP SSM data plane is kept in the Up state while applying signature updates. You can check the AIP SSM data plane status by using the show module command during signature updates.

Possible Cause Bypass mode is set to off. The issue is seen when updating signatures, and when you use either CSM or IDM to apply signature updates. This issue is not seen when upgrading IPS system software.

The AIP SSM and the Normalizer Engine

The majority of the features in the Normalizer engine are not used on the AIP SSM, because the ASA itself handles the normalization. Packets on the ASA IPS modules go through a special path in the Normalizer that only reassembles fragments and puts packets in the right order for the TCP stream. The Normalizer does not do any of the normalization that is done on an inline IPS appliance, because that causes problems in the way the ASA handles the packets.

TCP Reset Differences Between IPS Appliances and the AIP SSM

The IPS appliance sends TCP reset packets to both the attacker and victim when reset-tcp-connection is selected. The IPS appliance sends a TCP reset packet only to the victim under the following circumstances:

•When a deny-packet-inline or deny-connection-inline is selected

•When TCP-based signatures and reset-tcp-connection have NOT been selected

In the case of the AIP SSM, the TCP reset request is sent to the ASA, and then the ASA sends the TCP reset packets. The ASA sends TCP reset packets to both the attacker and victim when the reset-tcp-connection is selected. When deny-packet-inline or deny-connection-inline is selected, the ASA sends the TCP reset packet to either the attacker or victim depending on the configuration of the signature. Signatures configured to swap the attacker and victim when reporting the alert can cause the ASA to send the TCP reset packet to the attacker.

Interoperability With Other IPS Network Modules

The Cisco access routers only support one IDS/IPS module per router. If you have more than one IDS/IPS module installed, the most capable card is enabled. The most capable hierarchy is:

1. AIM IPS

2. NM CIDS

This means, for example, that if both modules are installed, the AIM IPS disables the NM CIDS. If there are multiple modules with the same level of capability, the first one discovered is enabled and all others are disabled.

You cannot bring up, enable, or configure a disabled module. To bring up a less capable module, you must remove the more capable module from the router and reboot. Disabled modules are reported in the show diag command output. The state of the module is reported as present but disabled.

If the most capable module slot and port do not match the interface ids slot/port configuration command, the most capable module is disabled with the following warning:

The module in slot x will be disabled and configuration ignored.

The correct slot/port number are displayed so that you can change the configuration.

Verifying Installation and Finding the Serial Number

Use the show inventory command in privileged EXEC mode to verify the installation of the AIM IPS.

Note You can also use this command to find the serial number of your AIM IPS for use in troubleshooting with TAC. The serial number appears in the PID line, for example, SN:FHH102300KS.

Gathering Information

You can use the following CLI commands and scripts to gather information and diagnose the state of the sensor when problems occur. You can use the show tech-support command to gather all the information of the sensor, or you can use the other individual commands listed in this section for specific information. This section contains the following topics:

Overview

The show tech-support command captures all status and configuration information on the sensor and includes the current configuration, version information, and cidDump information. The output can be large, over 1 MB. You can transfer the output to a remote system. For the procedure for copying the output to a remote system, see Displaying Tech Support Information.

Note To get the same information from IDM, choose Monitoring > Support Information > System Information.

Note Always run the show tech-support command before contacting TAC.

Displaying Tech Support Information

Use the show tech-support [page] [destination-urldestination_url] command to display system information on the screen or have it sent to a specific URL. You can use the information as a troubleshooting tool with TAC.

The following parameters are optional:

•page—Displays the output, one page of information at a time.

Press Enter to display the next line of output or use the spacebar to display the next page of information.

•destination-url—Indicates the information should be formatted as HTML and sent to the destination that follows this command. If you use this keyword, the output is not displayed on the screen.

•destination_url—Indicates the information should be formatted as HTML. The URL specifies where the information should be sent. If you do not use this keyword, the information is displayed on the screen.

To display tech support information, f ollow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 View the output on the screen.

sensor# show tech-support page

The system information appears on the screen, one page at a time. Press the spacebar to view the next page or press Ctrl-C to return to the prompt.

Step 3 To send the output (in HTML format) to a file, follow these steps:

a. Enter the following command, followed by a valid destination.

sensor# show tech-support destination-url destination_url

You can specify the following destination types:

•ftp:—Destination URL for FTP network server. The syntax for this prefix is ftp:[[//username@location]/relativeDirectory]/filename or ftp:[[//username@location]//absoluteDirectory]/filename.

•scp:—Destination URL for the SCP network server. The syntax for this prefix is scp:[[//username@]location]/relativeDirectory]/filename or scp:[[//username@]location]//absoluteDirectory]/filename.

For example, to send the tech support output to the file /absolute/reports/sensor1Report.html:

sensor# show tech support dest
ftp://csidsuser@10.2.1.2//absolute/reports/sensor1Report.html

The password: prompt appears.

b. Enter the password for this user account.

The Generating report: message is displayed.

Tech Support Command Output

The following is an example of the show tech-support command output:

Note This output example shows the first part of the command and lists the information for the Interfaces, ARC, and cidDump services.

Overview

The show version command shows the general health of the sensor and can indicate where a failure is occurring. It gives the following information:

•Which applications are running

•Versions of the applications

•Disk and memory usage

•Upgrade history of the applications

Note To get the same information from IDM or ASDM, choose Monitoring > Support Information > Diagnostics Report.

Displaying Version Information

Use the show version command to display version information for all installed operating system packages, signature packages, and IPS processes running on the system. To view the configuration for the entire system, use the more current-config command.

To display the version and configuration, follow these steps:

Step 1 Log in to the CLI.

Step 2 View version information.

sensor# show version

Application Partition:

Cisco Intrusion Prevention System, Version 6.0(0.22)S212.0

Host:

Realm Keys key1.0

Signature Definition:

Signature Update S212.0 2006-02-13

OS Version: 2.4.30-IDS-smp-bigphys

Platform: IPS-4240-K9

Serial Number: P3000000653

No license present

Sensor up-time is 16 days.

Using 445308928 out of 1984688128 bytes of available memory (22% usage)

system is using 17.4M out of 29.0M bytes of available disk space (60% usage)

application-data is using 35.0M out of 166.8M bytes of available disk space (22% usage)

boot is using 36.6M out of 68.6M bytes of available disk space (56% usage)

Use the show statistics [anomaly-detection | denied-attackers | os-identification | virtual-sensor] [name | clear] to display statistics for these components for all virtual sensors. If you provide the virtual sensor name, the statistics for that virtual sensor only are displayed.

Note The clear option is not available for the analysis engine, anomaly detection, host, network access, or OS identification applications.

To display statistics for the sensor, follow these steps:

Step 1 Log in to the CLI.

Step 2 Display the statistics for Analysis Engine.

sensor# show statistics analysis-engine

Analysis Engine Statistics

Number of seconds since service started = 1421127

Measure of the level of current resource utilization = 0

Measure of the level of maximum resource utilization = 0

The rate of TCP connections tracked per second = 0

The rate of packets per second = 0

The rate of bytes per second = 0

Receiver Statistics

Total number of packets processed since reset = 0

Total number of IP packets processed since reset = 0

Transmitter Statistics

Total number of packets transmitted = 0

Total number of packets denied = 0

Total number of packets reset = 0

Fragment Reassembly Unit Statistics

Number of fragments currently in FRU = 0

Number of datagrams currently in FRU = 0

TCP Stream Reassembly Unit Statistics

TCP streams currently in the embryonic state = 0

TCP streams currently in the established state = 0

TCP streams currently in the closing state = 0

TCP streams currently in the system = 0

TCP Packets currently queued for reassembly = 0

The Signature Database Statistics.

Total nodes active = 0

TCP nodes keyed on both IP addresses and both ports = 0

UDP nodes keyed on both IP addresses and both ports = 0

IP nodes keyed on both IP addresses = 0

Statistics for Signature Events

Number of SigEvents since reset = 0

Statistics for Actions executed on a SigEvent

Number of Alerts written to the IdsEventStore = 0

sensor#

Step 3 Display the statistics for anomaly detection.

sensor# show statistics anomaly-detection

Statistics for Virtual Sensor vs0

No attack

Detection - ON

Learning - ON

Next KB rotation at 10:00:01 UTC Sat Jan 18 2003

Internal Zone

TCP Protocol

UDP Protocol

Other Protocol

External Zone

TCP Protocol

UDP Protocol

Other Protocol

Illegal Zone

TCP Protocol

UDP Protocol

Other Protocol

Statistics for Virtual Sensor vs1

No attack

Detection - ON

Learning - ON

Next KB rotation at 10:00:00 UTC Sat Jan 18 2003

Internal Zone

TCP Protocol

UDP Protocol

Other Protocol

External Zone

TCP Protocol

UDP Protocol

Other Protocol

Illegal Zone

TCP Protocol

UDP Protocol

Other Protocol

sensor#

Step 4 Display the statistics for authentication:

sensor# show statistics authentication

General

totalAuthenticationAttempts = 128

failedAuthenticationAttempts = 0

sensor#

Step 5 Display the statistics for the denied attackers in the system.

sensor# show statistics denied-attackers

Denied Attackers and hit count for each.

Denied Attackers and hit count for each.

Statistics for Virtual Sensor vs0

Denied Attackers with percent denied and hit count for each.

Denied Attackers with percent denied and hit count for each.

Statistics for Virtual Sensor vs1

Denied Attackers with percent denied and hit count for each.

Denied Attackers with percent denied and hit count for each.

sensor#

Step 6 Display the statistics for Event Server.

sensor# show statistics event-server

General

openSubscriptions = 0

blockedSubscriptions = 0

Subscriptions

sensor#

Step 7 Display the statistics for Event Store.

sensor# show statistics event-store

Event store statistics

General information about the event store

The current number of open subscriptions = 2

The number of events lost by subscriptions and queries = 0

The number of queries issued = 0

The number of times the event store circular buffer has wrapped = 0

Number of events of each type currently stored

Debug events = 0

Status events = 9904

Log transaction events = 0

Shun request events = 61

Error events, warning = 67

Error events, error = 83

Error events, fatal = 0

Alert events, informational = 60

Alert events, low = 1

Alert events, medium = 60

Alert events, high = 0

sensor#

Step 8 Display the statistics for the host.

sensor# show statistics host

General Statistics

Last Change To Host Config (UTC) = 16:11:05 Thu Feb 10 2005

Command Control Port Device = FastEthernet0/0

Network Statistics

fe0_0 Link encap:Ethernet HWaddr 00:0B:46:53:06:AA

inet addr:10.89.149.185 Bcast:10.89.149.255 Mask:255.255.255.128

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:1001522 errors:0 dropped:0 overruns:0 frame:0

TX packets:469569 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:57547021 (54.8 Mib) TX bytes:63832557 (60.8 MiB)

Interrupt:9 Base address:0xf400 Memory:c0000000-c0000038

NTP Statistics

status = Not applicable

Memory Usage

usedBytes = 500592640

freeBytes = 8855552

totalBytes = 509448192

Swap Usage

Used Bytes = 77824

Free Bytes = 600649728

Total Bytes = 600727552

CPU Statistics

Usage over last 5 seconds = 0

Usage over last minute = 1

Usage over last 5 minutes = 1

Memory Statistics

Memory usage (bytes) = 500498432

Memory free (bytes) = 894976032

Auto Update Statistics

lastDirectoryReadAttempt = N/A

lastDownloadAttempt = N/A

lastInstallAttempt = N/A

nextAttempt = N/A

sensor#

Display the statistics for the logging application:

sensor# show statistics logger

The number of Log interprocessor FIFO overruns = 0

The number of syslog messages received = 11

The number of <evError> events written to the event store by severity

Fatal Severity = 0

Error Severity = 64

Warning Severity = 35

TOTAL = 99

The number of log messages written to the message log by severity

Fatal Severity = 0

Error Severity = 64

Warning Severity = 24

Timing Severity = 311

Debug Severity = 31522

Unknown Severity = 7

TOTAL = 31928

sensor#

Step 9 Display the statistics for ARC.

sensor# show statistics network-access

Current Configuration

LogAllBlockEventsAndSensors = true

EnableNvramWrite = false

EnableAclLogging = false

AllowSensorBlock = false

BlockMaxEntries = 11

MaxDeviceInterfaces = 250

NetDevice

Type = PIX

IP = 10.89.150.171

NATAddr = 0.0.0.0

Communications = ssh-3des

NetDevice

Type = PIX

IP = 10.89.150.219

NATAddr = 0.0.0.0

Communications = ssh-des

NetDevice

Type = PIX

IP = 10.89.150.250

NATAddr = 0.0.0.0

Communications = telnet

NetDevice

Type = Cisco

IP = 10.89.150.158

NATAddr = 0.0.0.0

Communications = telnet

BlockInterface

InterfaceName = ethernet0/1

InterfaceDirection = out

InterfacePostBlock = Post_Acl_Test

BlockInterface

InterfaceName = ethernet0/1

InterfaceDirection = in

InterfacePreBlock = Pre_Acl_Test

InterfacePostBlock = Post_Acl_Test

NetDevice

Type = CAT6000_VACL

IP = 10.89.150.138

NATAddr = 0.0.0.0

Communications = telnet

BlockInterface

InterfaceName = 502

InterfacePreBlock = Pre_Acl_Test

BlockInterface

InterfaceName = 507

InterfacePostBlock = Post_Acl_Test

State

BlockEnable = true

NetDevice

IP = 10.89.150.171

AclSupport = Does not use ACLs

Version = 6.3

State = Active

Firewall-type = PIX

NetDevice

IP = 10.89.150.219

AclSupport = Does not use ACLs

Version = 7.0

State = Active

Firewall-type = ASA

NetDevice

IP = 10.89.150.250

AclSupport = Does not use ACLs

Version = 2.2

State = Active

Firewall-type = FWSM

NetDevice

IP = 10.89.150.158

AclSupport = uses Named ACLs

Version = 12.2

State = Active

NetDevice

IP = 10.89.150.138

AclSupport = Uses VACLs

Version = 8.4

State = Active

BlockedAddr

Host

IP = 22.33.4.5

Vlan =

ActualIp =

BlockMinutes =

Host

IP = 21.21.12.12

Vlan =

ActualIp =

BlockMinutes =

Host

IP = 122.122.33.4

Vlan =

ActualIp =

BlockMinutes = 60

MinutesRemaining = 24

Network

IP = 111.22.0.0

Mask = 255.255.0.0

BlockMinutes =

sensor#

Step 10 Display the statistics for the notification application.

sensor# show statistics notification

General

Number of SNMP set requests = 0

Number of SNMP get requests = 0

Number of error traps sent = 0

Number of alert traps sent = 0

sensor#

Step 11 Display the statistics for the SDEE server.

sensor# show statistics sdee-server

General

Open Subscriptions = 0

Blocked Subscriptions = 0

Maximum Available Subscriptions = 5

Maximum Events Per Retrieval = 500

Subscriptions

sensor#

Step 12 Display the statistics for the transaction server.

sensor# show statistics transaction-server

General

totalControlTransactions = 35

failedControlTransactions = 0

sensor#

Step 13 Display the statistics for a virtual sensor.

sensor# show statistics virtual-sensor vs0

Statistics for Virtual Sensor vs0

Name of current Signature-Definition instance = sig0

Name of current Event-Action-Rules instance = rules0

List of interfaces monitored by this virtual sensor =

General Statistics for this Virtual Sensor

Number of seconds since a reset of the statistics = 1421711

Measure of the level of resource utilization = 0

Total packets processed since reset = 0

Total IP packets processed since reset = 0

Total packets that were not IP processed since reset = 0

Total TCP packets processed since reset = 0

Total UDP packets processed since reset = 0

Total ICMP packets processed since reset = 0

Total packets that were not TCP, UDP, or ICMP processed since reset =

Total ARP packets processed since reset = 0

Total ISL encapsulated packets processed since reset = 0

Total 802.1q encapsulated packets processed since reset = 0

Total packets with bad IP checksums processed since reset = 0

Total packets with bad layer 4 checksums processed since reset = 0

Total number of bytes processed since reset = 0

The rate of packets per second since reset = 0

The rate of bytes per second since reset = 0

The average bytes per packet since reset = 0

Denied Address Information

Number of Active Denied Attackers = 0

Number of Denied Attackers Inserted = 0

Number of Denied Attacker Victim Pairs Inserted = 0

Number of Denied Attacker Service Pairs Inserted = 0

Number of Denied Attackers Total Hits = 0

Number of times max-denied-attackers limited creation of new entry = 0

Number of exec Clear commands during uptime = 0

Denied Attackers and hit count for each.

Denied Attackers with percent denied and hit count for each.

The Signature Database Statistics.

The Number of each type of node active in the system (can not be reset

Total nodes active = 0

TCP nodes keyed on both IP addresses and both ports = 0

UDP nodes keyed on both IP addresses and both ports = 0

IP nodes keyed on both IP addresses = 0

The number of each type of node inserted since reset

Total nodes inserted = 0

TCP nodes keyed on both IP addresses and both ports = 0

UDP nodes keyed on both IP addresses and both ports = 0

IP nodes keyed on both IP addresses = 0

The rate of nodes per second for each time since reset

Nodes per second = 0

TCP nodes keyed on both IP addresses and both ports per second = 0

UDP nodes keyed on both IP addresses and both ports per second = 0

IP nodes keyed on both IP addresses per second = 0

The number of root nodes forced to expire because of memory constraint

Step 15 To clear the statistics for an application, for example, the logging application.

sensor# show statistics logger clear

The number of Log interprocessor FIFO overruns = 0

The number of syslog messages received = 141

The number of <evError> events written to the event store by severity

Fatal Severity = 0

Error Severity = 14

Warning Severity = 142

TOTAL = 156

The number of log messages written to the message log by severity

Fatal Severity = 0

Error Severity = 14

Warning Severity = 1

Timing Severity = 0

Debug Severity = 0

Unknown Severity = 28

TOTAL = 43

The statistics were retrieved and cleared.

Step 16 Verify that the statistics have been cleared.

sensor# show statistics logger

The number of Log interprocessor FIFO overruns = 0

The number of syslog messages received = 0

The number of <evError> events written to the event store by severity

Fatal Severity = 0

Error Severity = 0

Warning Severity = 0

TOTAL = 0

The number of log messages written to the message log by severity

Fatal Severity = 0

Error Severity = 0

Warning Severity = 0

Timing Severity = 0

Debug Severity = 0

Unknown Severity = 0

TOTAL = 0

sensor#

The statistics all begin from 0.

Interfaces Information

The show interfaces command is useful for gathering information on the sensing and command and control interfaces. This section describes the show interfaces command, and contains the following topics:

Overview

You can learn the following information from the show interfaces command:

•Whether the interface is up or down

•Whether or not packets are being seen, and on which interfaces

•Whether or not packets are being dropped by SensorApp

•Whether or not there are errors being reported by the interfaces that can result in packet drops

The show interfaces command displays statistics for all system interfaces. Or you can use the individual commands to display statistics for the command and control interface (show interfaces command_control_interface_name), the sensing interface (show interfaces interface_name).

Interfaces Command Output

The following example shows the output from the show interfaces command:

sensor# show interfaces

Interface Statistics

Total Packets Received = 0

Total Bytes Received = 0

Missed Packet Percentage = 0

Current Bypass Mode = Auto_off

MAC statistics from interface GigabitEthernet0/1

Media Type = backplane

Missed Packet Percentage = 0

Inline Mode = Unpaired

Pair Status = N/A

Link Status = Up

Link Speed = Auto_1000

Link Duplex = Auto_Full

Total Packets Received = 0

Total Bytes Received = 0

Total Multicast Packets Received = 0

Total Broadcast Packets Received = 0

Total Jumbo Packets Received = 0

Total Undersize Packets Received = 0

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 0

Total Bytes Transmitted = 0

Total Multicast Packets Transmitted = 0

Total Broadcast Packets Transmitted = 0

Total Jumbo Packets Transmitted = 0

Total Undersize Packets Transmitted = 0

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

MAC statistics from interface GigabitEthernet0/0

Media Type = TX

Link Status = Up

Link Speed = Auto_100

Link Duplex = Auto_Full

Total Packets Received = 2211296

Total Bytes Received = 157577635

Total Multicast Packets Received = 20

Total Receive Errors = 0

Total Receive FIFO Overruns = 0

Total Packets Transmitted = 239723

Total Bytes Transmitted = 107213390

Total Transmit Errors = 0

Total Transmit FIFO Overruns = 0

sensor#

Events Information

You can use the show events command to view the alerts generated by SensorApp and errors generated by an application. This section describes the show events command, and contains the following topics:

Sensor Events

•evLogTransaction—Record of control transactions processed by each sensor application

•evShunRqst—Block requests

Events remain in the Event Store until they are overwritten by newer events.

Overview

The show events command is useful for troubleshooting event capture issues in which you are not seeing events in Event viewer or Security Monitor. You can use the show events command to determine which events are being generated on the sensor to make sure events are being generated and that the fault lies with the monitoring side.

You can clear all events from Event Store by using the clear events command.

Events are displayed beginning at the start time. If you do not specify a start time, events are displayed beginning at the current time. If you do not specify an event type, all events are displayed.

Note Events are displayed as a live feed until you press Ctrl-C to cancel the request.

The following options apply:

•alert—Displays alerts. Provides notification of some suspicious activity that may indicate an attack is in process or has been attempted. Alert events are generated by Analysis Engine whenever a signature is triggered by network activity.

If no level is selected (informational, low, medium, or high), all alert events are displayed.

•include-traits—Displays alerts that have the specified traits.

•exclude-traits—Does not display alerts that have the specified traits.

•traits—Trait bit position in decimal (0 to 15).

•min-threat-rating—Displays events with a threat rating above or equal to this value. The default is 0. The valid range is 0 to 100.

•max-threat-rating—Displays events with a threat rating below or equal to this value. The default is 100. The valid range is 0 to 100.

•error—Displays error events. Error events are generated by services when error conditions are encountered. If no level is selected (warning, error, or fatal), all error events are displayed.

•log—Displays log events. Log events are generated when a transaction is received and responded to by an application. Contains information about the request, response, success or failure of the transaction.

•NAC—Displays ARC (block) requests.

Note ARC is formerly known as NAC. This name change has not been completely implemented throughout the IDM and CLI for IPS 6.0.

•status—Displays status events.

•past—Displays events starting in the past for the specified hours, minutes, and seconds.

•hh:mm:ss—Hours, minutes, and seconds in the past to begin the display.

Note The show events command waits until a specified event is available. It continues to wait and display events until you press Ctrl-C to exit.

Clearing Events

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Clear Event Store.

sensor# clear events

Warning: Executing this command will remove all events currently stored in the event
store.

Continue with clear? []:

Step 3 Enter yes to clear the events.

cidDump Script

If you do not have access to IDM, IME, or the CLI, you can run the underlying script cidDump from the Service account by logging in as root and running /usr/cids/idsRoot/bin/cidDump. The path of the cidDump file is /usr/cids/idsRoot/htdocs/private/cidDump.html.

cidDump is a script that captures a large amount of information including the IPS processes list, log files, OS information, directory listings, package information, and configuration files.

To run the cidDump script, follow these steps:

Step 1 Log in to the sensor Service account.

Step 2 Su to root using the Service account password.

Step 3 Enter the following command.

/usr/cids/idsRoot/bin/cidDump

Step 4 Enter the following command to compress the resulting /usr/cids/idsRoot/log/cidDump.html file.

gzip /usr/cids/idsRoot/log/cidDump.html

Step 5 Send the resulting HTML file to TAC or the IPS developers in case of a problem.