Recovering the Password
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
Note Administrators may need to disable the password recovery feature for security reasons.
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.
Table E-1 lists the password recovery methods according to platform.
Table E-1 Password Recovery Methods According to Platform
|
|
|
4300 series sensors 4500 series sensors |
Standalone IPS appliances |
GRUB prompt or ROMMON |
ASA 5500-X IPS SSP ASA 5585-X IPS SSP |
ASA 5500 series adaptive security appliance IPS modules |
Adaptive security appliance CLI command |
Recovering the Password for the Appliance
This section describes the two ways to recover the password for appliances. It contains the following topics:
Using the GRUB Menu
Note You must have a terminal server or direct serial connection to the appliance to use the GRUB menu to recover the password.
For the IPS 4270-20, IPS 4345, IPS 4360, IPS 4510, and IPS 4520 appliances, the password recovery is found in the GRUB menu, which appears during bootup. When the GRUB menu appears, press any key to pause the boot process.
To recover the password on appliances, follow these steps:
Step 1
Reboot the appliance to see the GRUB menu.
GNU GRUB version 0.94 (632K lower / 523264K upper memory)
-------------------------------------------
2: Cisco IPS Clear Password (cisco)
-------------------------------------------
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
Commands before booting, or 'c' for a command-line.
Step 2 Press any key to pause the boot process.
Step 3 Choose 2: Cisco IPS Clear Password (cisco) . The password is reset to cisco . Log in to the CLI with username cisco and password cisco . You can then change the password.
Using ROMMON
For the IPS 4345, IPS 4360, IPS 4510, and IPS 4520, you can use the ROMMON to recover the password. To access the ROMMON CLI, reboot the sensor from a terminal server or direct connection and interrupt the boot process.
Note After recovering the password, you must reset the confreg to 0, otherwise, when you try to upgrade the sensor, the upgrade fails because when the sensor reboots, it goes to password recovery (confreg 0x7) rather than to the upgrade option.
To recover the password using the ROMMON CLI, follow these steps:
Step 1
Reboot the appliance.
Step 2 To interrupt the boot process, press ESC or Control-R (terminal server) or send a BREAK command (direct connection). The boot code either pauses for 10 seconds or displays something similar to one of the following:
-
Evaluating boot options
-
Use BREAK or ESC to interrupt boot
Step 3 Enter the following commands to reset the password:
Sample ROMMON session:
Booting system, please wait...
Embedded BIOS Version 1.0(11)2 01/25/06 13:21:26.17
Evaluating BIOS Options...
Launch BIOS Extension to setup ROMMON
Cisco Systems ROMMON Version (1.0(11)2) #0: Thu Jan 26 10:43:08 PST 2006
Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
MAC Address:000b.fcfa.d155
Update Config Register (0x7) in NVRAM...
Step 4 Enter the following command to reset the confreg value to 0:
Recovering the ASA 5500-X IPS SSP Password
You can reset the password to the default ( cisco ) for the ASA 5500-X IPS SSP 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 8.6.1 or later.
Use the sw-module module ips password-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 ASA 5500-X IPS SSP, follow these steps:
Step 1 Log into the adaptive security appliance and enter the following command:
asa# sw-module module ips password-reset
Reset the password on module ips? [confirm]
Step 2 Press Enter to confirm.
Password-Reset issued for module ips.
Step 3 Verify the status of the module. Once the status reads Up
, you can session to the ASA 5500-X IPS SSP.
Mod Card Type Model Serial No.
--- -------------------------------------------- ------------------ -----------
ips ASA 5555-X IPS Security Services Processor ASA5555-IPS FCH151070GR
Mod MAC Address Range Hw Version Fw Version Sw Version
--- --------------------------------- ------------ ------------ ---------------
ips 503d.e59c.7c4c to 503d.e59c.7c4c N/A N/A 7.1(4)E4
Mod SSM Application Name Status SSM Application Version
--- ------------------------------ ---------------- --------------------------
Mod Status Data Plane Status Compatibility
--- ------------------ --------------------- -------------
Mod License Name License Status Time Remaining
--- -------------- --------------- ---------------
ips IPS Module Enabled 210 days
Step 4 Session to the ASA 5500-X IPS SSP.
Opening command session with module ips.
Connected to module ips. Escape character sequence is 'CTRL-^X'.
Step 5 Enter the default username ( cisco) and password ( cisco) at the login prompt.
You are required to change your password immediately (password aged)
Changing password for cisco.
(current) password: cisco
Step 6 Enter your new password twice.
New password: new password
Retype new password: new password
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.
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.
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.
Recovering the ASA 5585-X IPS SSP Password
Note To reset the password, you must have ASA 8.2.(4.4) or later or ASA 8.4.2 or later. The ASA 5585-X IPS SSP is not supported in ASA 8.3(x).
You can reset the password to the default ( cisco ) for the ASA 5585-X IPS SSP using the CLI or the ASDM. Resetting the password causes it to reboot. IPS services are not available during a reboot.
Use the hw-module module slot_number password-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 ASA 5585-X IPS SSP, follow these steps:
Step 1 Log into the adaptive security appliance and enter the following command:
asa# hw-module module 1 password-reset
Reset the password on module in slot 1? [confirm]
Step 2 Press Enter to confirm.
Password-Reset issued for slot 1.
Step 3 Verify the status of the module. Once the status reads Up
, you can session to the ASA 5585-X IPS SSP.
Mod Card Type Model Serial No.
--- -------------------------------------------- ------------------ -----------
1 ASA 5585-X IPS Security Services Processor-4 ASA5585-SSP-IPS40 JAF1436ABSG
Mod MAC Address Range Hw Version Fw Version Sw Version
--- --------------------------------- ------------ ------------ ---------------
1 5475.d029.8c74 to 5475.d029.8c7f 0.1 2.0(12)3 7.1(4)E4
Mod SSM Application Name Status SSM Application Version
--- ------------------------------ ---------------- --------------------------
Mod Status Data Plane Status Compatibility
--- ------------------ --------------------- -------------
Step 4 Session to the ASA 5585-X IPS SSP.
Opening command session with slot 1.
Connected to slot 1. Escape character sequence is 'CTRL-^X'.
Step 5 Enter the default username ( cisco) and password ( cisco) at the login prompt.
You are required to change your password immediately (password aged)
Changing password for cisco.
(current) password: cisco
Step 6 Enter your new password twice.
New password: new password
Retype new password: new password
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.
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.
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.
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, IDM, or IME.
Disabling Password Recovery Using the CLI
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
Disabling Password Recovery Using the IDM or IME
To disable password recovery in the IDM or IME, follow these steps:
Step 1
Log in to the IDM or IME using an account with administrator privileges.
Step 2 Choose Configuration > sensor_name > Sensor Setup > Network .
Step 3 To disable password recovery, uncheck the Allow Password Recovery check box.
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
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>
Troubleshooting Password Recovery
When you 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 you attempt password recovery, 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. For the platforms that use external mechanisms, such as ROMMON, 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.
Troubleshooting the Appliance
This section contains information to troubleshoot the appliance. It contains the following topics:
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.
The Appliance and Jumbo Packet Frame Size
For IPS standalone appliances with 1 G and 10 G fixed or add-on interfaces, the maximum jumbo frame size is 9216 bytes.
Note A jumbo frame is an Ethernet packet that is larger than the standard maximum of 1518 bytes (including Layer 2 header and FCS).
Hardware Bypass and Link Changes and Drops
Note Hardware bypass is available on the 4GE bypass interface card, which is supported on the IPS 4270-20.
Properly configuring and deploying hardware bypass protects against complete link failure if the IPS appliance experiences a power loss, critical hardware failure, or is rebooted; however, a link status change still occurs when hardware bypass engages (and again when it disengages).
During engagement, the interface card disconnects both physical connections from itself and bridges them together. The interfaces of the connected devices can then negotiate the link and traffic forwarding can resume. Once the appliance is back online, hardware bypass disengages and the interface card interrupts the bypass and reconnects the links back to itself. The interface card then negotiates both links and traffic resumes.
There is no built-in way to completely avoid link status changes and drops. However, you can greatly reduce the interruption time (in some cases to sub-second times) by doing the following:
- Make sure you use CAT 5e/6-certified cabling for all connections.
- Make sure the interfaces of the connected devices are configured to match the interfaces of the appliance for speed/duplex negotiation (auto/auto).
- Enable portfast on connected switchports to reduce spanning-tree forwarding delays.
For More Information
For more information about the hardware bypass card on the IPS 4270-20, see Hardware Bypass.
Troubleshooting Loose Connections
Perform the following actions to troubleshoot loose connections on sensors:
- Make sure all power cords are securely connected.
- Make sure all cables are properly aligned and securely connected for all external and internal components.
- Remove and check all data and power cables for damage. Make sure no cables have bent pins or damaged connectors.
- Make sure each device is properly seated.
- If a device has latches, make sure they are completely closed and locked.
- Check any interlock or interconnect indicators that indicate a component is not connected properly.
- If problems continue, remove and reinstall each device, checking the connectors and sockets for bent pins or other damage.
Analysis Engine is Busy
After you reimage a sensor, the Analysis Engine is busy rebuilding Regex tables and does not respond to new configurations. You can check whether the Analysis Engine is busy by using the show statistics virtual-sensor command. You receive the following error message if the Analysis Engine is busy:
sensor# show statistics virtual-sensor
Error: getVirtualSensorStatistics : Analysis Engine is busy rebuilding regex tables. This may take a while.
When the 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
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.
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.
When you receive the errors that the Analysis Engine is busy, wait a while before trying to make configuration changes. Use the show statistics virtual-sensor command to find out when the Analysis Engine is available again.
Communication Problems
This section helps you troubleshoot communication problems with the 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. 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.
Total Packets Received = 0
Missed Packet Percentage = 0
Current Bypass Mode = Auto_off
MAC statistics from interface GigabitEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 0
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 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
Total Packets Received = 944333
Total Bytes Received = 83118358
Total Multicast Packets Received = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 397633
Total Bytes Transmitted = 435730956
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
Step 3 Make sure the sensor IP address is unique. If the management interface detects that another device on the network has the same IP address, it does not come up.
--- 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 '[]'.
host-ip 192.168.1.2/24,192.168.1.1
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. If the workstation network address is permitted in the sensor access list, go to Step 6.
--- 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 '[]'.
host-ip 192.168.1.2/24,192.168.1.1
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.
For More Information
Correcting a Misconfigured Access List
To correct a misconfigured access list, follow these steps:
Step 1
Log in to the CLI.
Step 2 View your configuration to see the access list.
sensor# show configuration | include access-list
Step 3 Verify that the client IP address is listed in the allowed networks. If it is not, add it.
sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
sensor(config-hos-net)# access-list 171.69.70.0/24
Step 4 Verify the settings.
sensor(config-hos-net)# show settings
-----------------------------------------------
host-ip: 192.168.1.2/24,192.168.1.1 default: 10.1.9.201/24,10.1.9.1
host-name: sensor-238 default: sensor
telnet-option: enabled default: disabled
access-list (min: 0, max: 512, current: 3)
-----------------------------------------------
network-address: 10.0.0.0/8
-----------------------------------------------
network-address: 64.0.0.0/8
-----------------------------------------------
network-address: 171.69.70.0/24
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
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. If the output says the command and control interface link status is down, there is a hardware issue or an IP address conflict.
Total Packets Received = 0
Missed Packet Percentage = 0
Current Bypass Mode = Auto_off
MAC statistics from interface GigabitEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 0
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 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
Total Packets Received = 1822323
Total Bytes Received = 131098876
Total Multicast Packets Received = 20
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 219260
Total Bytes Transmitted = 103668610
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
Step 3 Make sure the sensor cabling is correct.
Step 4 Make sure the IP address is correct.
For More Information
- To make sure the sensor cabling is correct, refer to the chapter for your sensor in this document.
- For the procedure for making sure the IP address is correct, refer to Configuring Network Settings .
The SensorApp and Alerting
This section helps you troubleshoot issues with the SensorApp and alerting. It contains the following topics:
The SensorApp Is Not Running
The sensing process, SensorApp, should always be running. If it is not, you do not receive any alerts. The SensorApp is part of the Analysis Engine, so you must make sure the Analysis Engine is running.
To make sure the Analysis Engine is running, follow these steps:
Step 1
Log in to the CLI.
Step 2 Determine the status of the Analysis Engine service and whether you have the latest software updates.
Cisco Intrusion Prevention System, Version 7.1(3)E4
Signature Update S605.0 2011-10-25
Platform: ASA5585-SSP-IPS10
Serial Number: 123456789AB
Sensor up-time is 13 days.
Using 4395M out of 5839M bytes of available memory (75% usage)
system is using 26.2M out of 160.0M bytes of available disk space (16% usage)
application-data is using 69.7M out of 171.6M bytes of available disk space (43%
boot is using 57.3M out of 70.5M bytes of available disk space (86% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96%
MainApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
AnalysisEngine S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CollaborationApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CLI S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
IPS-K9-7.1-3-E4 00:30:07 UTC Wed Nov 16 2011
Recovery Partition Version 1.1 - 7.1(3)E4
Host Certificate Valid from: 16-Nov-2011 to 16-Nov-2013
Step 3 If the Analysis Engine is not running, look for any errors connected to it.
sensor# show events error fatal past 13:00:00 | include AnalysisEngine
evError: eventId=1077219258696330005 severity=warning
time: 2004/02/19 19:34:20 2004/02/19 19:34:20 UTC
errorMessage: name=errUnclassified Generating new Analysis Engine configuration file.
Note The date and time of the last restart is listed. In this example, the last restart was on 2-19-2004 at 7:34.
Step 4 If you do not have the latest software updates, download them from Cisco.com. Read the Readme that accompanies the software upgrade for any known DDTS for the SensorApp or the Analysis Engine.
Step 5 If the Analysis Engine is still not running, enter show tech-support and save the output.
Step 6 Reboot the sensor.
Step 7 Enter show version after the sensor has stabilized to see if the issue is resolved.
Step 8 If the Analysis Engine still reads Not Running
, contact TAC with the original show tech support command output.
For More Information
Physical Connectivity, SPAN, or VACL Port Issue
If the sensor is not connected properly, you do not receive any alerts.
To make sure the sensor is connected properly, follow these steps:
Step 1
Log in to the CLI.
Step 2 Make sure the interfaces are up and that the packet count is increasing.
Total Packets Received = 0
Missed Packet Percentage = 0
Current Bypass Mode = Auto_off
MAC statistics from interface GigabitEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 0
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 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
Total Packets Received = 1830137
Total Bytes Received = 131624465
Total Multicast Packets Received = 20
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 220052
Total Bytes Transmitted = 103796666
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
Step 3 If the Link Status is down, make sure the sensing port is connected properly.
Step 4 Verify the interface configuration:
- Make sure you have the interfaces configured properly.
- Verify the SPAN and VACL capture port configuration on the Cisco switch.
Refer to your switch documentation for the procedure.
Step 5 Verify again that the interfaces are up and that the packet count is increasing.
For More Information
- For the procedure for properly installing the sensing interface on your sensor, refer to the chapter on your appliance in this document.
- For the procedures for configuring interfaces on your sensor, refer to Configuring Interfaces.
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 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.
- Make sure the sensor is seeing packets
- Make sure that alerts are being generated
- Make sure the sensing interface is in a virtual sensor
To make sure you can see alerts, follow these steps:
Step 1
Log in to the CLI.
Step 2 Make sure the signature is enabled.
sensor# configure terminal
sensor(config)# service signature-definition sig0
sensor(config-sig)# signatures 1300 0
sensor(config-sig-sig)# status
sensor(config-sig-sig-sta)# show settings
-----------------------------------------------
enabled: true <defaulted>
retired: false <defaulted>
-----------------------------------------------
sensor(config-sig-sig-sta)#
Step 3 Make sure you have Produce Alert configured.
sensor# configure terminal
sensor(config)# service signature-definition sig0
sensor(config-sig)# signatures 1300 0
sensor(config-sig-sig)# engine ?
normalizer Signature engine
sensor(config-sig-sig)# engine normalizer
sensor(config-sig-sig-nor)# event-action produce-alert
sensor(config-sig-sig-nor)# show settings
-----------------------------------------------
event-action: produce-alert default: produce-alert|deny-connection-inline
-----------------------------------------------
Step 4 Make sure the sensor is seeing packets.
sensor# show interfaces FastEthernet0/1
MAC statistics from interface FastEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 267581
Total Bytes Received = 24886471
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 57301
Total Bytes Transmitted = 3441000
Total Multicast Packets Transmitted = 0
Total Broadcast Packets Transmitted = 0
Total Jumbo Packets Transmitted = 0
Total Undersize Packets Transmitted = 0
Total Transmit Errors = 1
Total Transmit FIFO Overruns = 0
Step 5 Check for alerts.
sensor# show statistics virtual-sensor
SigEvent Preliminary Stage Statistics
Number of Alerts received = 0
Number of Alerts Consumed by AlertInterval = 0
Number of Alerts Consumed by Event Count = 0
Number of FireOnce First Alerts = 0
Number of FireOnce Intermediate Alerts = 0
Number of Summary First Alerts = 0
Number of Summary Intermediate Alerts = 0
Number of Regular Summary Final Alerts = 0
Number of Global Summary Final Alerts = 0
Number of Alerts Output for further processing = 0alertDetails: Traffic Source: int0 ;
Sensor Not Seeing Packets
If the sensor is not seeing any packets on the network, you could have the interfaces set up incorrectly.
If the sensor is not seeing packets, follow these steps:
Step 1
Log in to the CLI.
Step 2 Make sure the interfaces are up and receiving packets.
sensor# show interfaces GigabitEthernet0/1
MAC statistics from interface GigabitEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 0
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 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
Step 3 If the interfaces are not up, do the following:
- Check the cabling.
- Enable the interface.
sensor# configure terminal
sensor(config)# service interface
sensor(config-int)# physical-interfaces GigabitEthernet0/1
sensor(config-int-phy)# admin-state enabled
sensor(config-int-phy)# show settings
-----------------------------------------------
media-type: tx <protected>
admin-state: enabled default: disabled
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
Step 4 Check to see that the interface is up and receiving packets.
MAC statistics from interface GigabitEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 3
Total Bytes Received = 900
Total Multicast Packets Received = 3
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 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 ...
For More Information
For the procedure for installing the sensor properly, refer to your sensor chapter in this document.
Cleaning Up a Corrupted SensorApp Configuration
If the SensorApp configuration has become corrupted and the SensorApp cannot run, you must delete it entirely and restart the SensorApp.
To delete the SensorApp configuration, follow these steps:
Step 1
Log in to the service account.
Step 2 Su to root.
Step 3 Stop the IPS applications.
Step 4 Replace the virtual sensor file.
cp /usr/cids/idsRoot/etc/defVirtualSensorConfig.xml /usr/cids/idsRoot/etc/VS-Config/virtualSensor.xml
Step 5 Remove the cache files.
rm /usr/cids/idsRoot/var/virtualSensor/*.pmz
Step 6 Exit the service account.
Step 7 Log in to the sensor CLI.
Step 8 Start the IPS services.
Step 9 Log in to an account with administrator privileges.
Step 10 Reboot the sensor.
Warning: Executing this command will stop all applications and reboot the node.
Continue with reset? [yes]:yes
For More Information
For more information on IPS system architecture, refer to System Architecture.
Blocking
This section provides troubleshooting help for blocking and the ARC service. It contains the following topics.
Troubleshooting Blocking
After you have configured the ARC, you can verify if it is running properly by using the show version command. To verify that the ARC is connecting to the network devices, use the show statistics network-access command.
Note The ARC was formerly known as Network Access Controller. Although the name has been changed since IPS 5.1, it still appears in IDM, IME, and the CLI as Network Access Controller, nac, and network-access.
To troubleshoot the ARC, follow these steps:
1. Verify that the ARC is running.
2. Verify that the ARC is connecting to the network devices.
3. Verify that the Event Action is set to Block Host for specific signatures.
4. Verify that the master blocking sensor is properly configured.
For More Information
Verifying ARC is Running
Note The CLI output is an example of what your configuration may look like. It will not match exactly due to the optional setup choices, sensor model, and IPS 7.1 version you have installed.
To verify that the ARC is running, use the show version command. If the MainApp is not running, the ARC cannot run. The ARC is part of the MainApp.
To verify that the ARC is running, follow these steps:
Step 1
Log in to the CLI.
Step 2 Verify that the MainApp is running.
Cisco Intrusion Prevention System, Version 7.1(3)E4
Signature Update S605.0 2011-10-25
Platform: ASA5585-SSP-IPS10
Serial Number: 123456789AB
Sensor up-time is 13 days.
Using 4395M out of 5839M bytes of available memory (75% usage)
system is using 26.2M out of 160.0M bytes of available disk space (16% usage)
application-data is using 69.7M out of 171.6M bytes of available disk space (43%
boot is using 57.3M out of 70.5M bytes of available disk space (86% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96%
MainApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
AnalysisEngine S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CollaborationApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CLI S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
IPS-K9-7.1-3-E4 00:30:07 UTC Wed Nov 16 2011
Recovery Partition Version 1.1 - 7.1(3)E4
Host Certificate Valid from: 16-Nov-2011 to 16-Nov-2013
Step 3 If the MainApp displays Not Running
, the ARC has failed. Contact TAC.
For More Information
For more information on IPS system architecture, refer to System Architecture.
Verifying ARC Connections are Active
If the State is not Active
in the ARC statistics, there is a problem.
To verify that the State is Active in the statistics, follow these steps:
Step 1
Log in to the CLI.
Step 2 Verify that the ARC is connecting. Check the State section of the output to verify that all devices are connecting.
sensor# show statistics network-access
LogAllBlockEventsAndSensors = true
MaxDeviceInterfaces = 250
AclSupport = uses Named ACLs
Step 3 If the ARC is not connecting, look for recurring errors.
sensor# show events error hh:mm:ss month day year | include : nac
Example
sensor# show events error 00:00:00 Apr 01 2011 | include : nac
Step 4 Make sure you have the latest software updates.
Cisco Intrusion Prevention System, Version 7.1(3)E4
Signature Update S605.0 2011-10-25
Platform: ASA5585-SSP-IPS10
Serial Number: 123456789AB
Sensor up-time is 13 days.
Using 4395M out of 5839M bytes of available memory (75% usage)
system is using 26.2M out of 160.0M bytes of available disk space (16% usage)
application-data is using 69.7M out of 171.6M bytes of available disk space (43%
boot is using 57.3M out of 70.5M bytes of available disk space (86% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96%
MainApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
AnalysisEngine S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CollaborationApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CLI S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
IPS-K9-7.1-3-E4 00:30:07 UTC Wed Nov 16 2011
Recovery Partition Version 1.1 - 7.1(3)E4
Host Certificate Valid from: 16-Nov-2011 to 16-Nov-2013
Note If you do not have the latest software updates, download them from Cisco.com. Read the Readme that accompanies the software upgrade for any known DDTS for the ARC.
Step 5 Make sure the configuration settings for each device are correct (the username, password, and IP address).
Step 6 Make sure the interface and directions for each network device are correct.
Step 7 If the network device is using SSH-3DES, make sure that you have enabled SSH connections to the device.
Step 8 Verify that each interface and direction on each controlled device is correct.
For More Information
Device Access Issues
The 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
-----------------------------------------------
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)
-----------------------------------------------
-----------------------------------------------
enable-password: <hidden>
username: netrangr default:
-----------------------------------------------
-----------------------------------------------
cat6k-devices (min: 0, max: 250, current: 0)
-----------------------------------------------
-----------------------------------------------
router-devices (min: 0, max: 250, current: 1)
-----------------------------------------------
-----------------------------------------------
communication: telnet default: ssh-3des
nat-address: 0.0.0.0 <defaulted>
block-interfaces (min: 0, max: 100, current: 1)
-----------------------------------------------
-----------------------------------------------
pre-acl-name: <defaulted>
post-acl-name: <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
firewall-devices (min: 0, max: 250, current: 0)
-----------------------------------------------
-----------------------------------------------
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.
For More Information
For the procedure for verifying the interfaces and directions for each network device, see Verifying the Interfaces and Directions on the Network Device.
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.
To perform a manual block using IDM, choose Monitoring > Sensor Monitoring > Time-Based Actions > Host Blocks . To perform a manual block using IME, choose Configuration > sensor_name > Sensor Monitoring > Time-Based Actions > Host Blocks .
To initiate a manual block to a bogus host, follow these steps:
Step 1 Enter ARC general submode.
sensor# configure terminal
sensor(config)# service network-access
sensor(config-net)# general
Step 2 Start the manual block of the bogus host IP address.
sensor(config-net-gen)# block-hosts 10.16.0.0
Step 3 Exit general submode.
sensor(config-net-gen)# exit
Step 4 Press Enter to apply the changes or type no to discard them.
Step 5 Telnet to the router and verify that a deny entry for the blocked address exists in the router ACL. Refer to the router documentation for the procedure.
Step 6 Remove the manual block by repeating Steps 1 through 4 except in Step 2 place no in front of the command.
sensor(config-net-gen)# no block-hosts 10.16.0.0
Enabling SSH Connections to the Network Device
If you are using SSH-3DES as the communication protocol for the network device, you must make sure you have enabled it on the device.
To enable SSH-3DES connections to the network device, follow these steps:
Step 1 Log in to the CLI.
Step 2 Enter configuration mode.
sensor# configure terminal
Step 3 Enable SSH-3DES.
sensor(config)# ssh-3des host blocking_device_ip_address
Step 4 Type yes when prompted to accept the device.
Blocking Not Occurring for a Signature
If blocking is not occurring for a specific signature, check that the event action is set to block the host.
To make sure blocking is occurring for a specific signature, follow these steps:
Step 1 Log in to the CLI.
Step 2 Enter signature definition submode.
sensor# configure terminal
sensor(config)# service signature-definition sig0
Step 3 Make sure the event action is set to block the host.
Note If you want to receive alerts, you must always add produce-alert any time you configure the event actions.
sensor(config-sig)# signatures 1300 0
sensor(config-sig-sig)# engine normalizer
sensor(config-sig-sig-nor)# event-action produce-alert|request-block-host
sensor(config-sig-sig-nor)# show settings
-----------------------------------------------
event-action: produce-alert|request-block-host default: produce-alert|deny
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
Step 4 Exit signature definition submode.
sensor(config-sig-sig-nor)# exit
sensor(config-sig-sig)# exit
Step 5 Press Enter to apply the changes or type no to discard them.
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 Log in to the CLI.
Step 2 View the ARC statistics and verify that the master blocking sensor entries are in the statistics.
sensor# show statistics network-access
Step 3 If the master blocking sensor does not show up in the statistics, you need to add it.
Step 4 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 5 Exit network access general submode.
sensor(config-net-gen)# exit
Step 6 Press Enter to apply the changes or type no to discard them.
Step 7 Verify that the block shows up in the ARC statistics.
sensor# show statistics network-access
Step 8 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
Step 9 If the remote master blocking sensor is using TLS for web access, make sure the forwarding sensor is configured as a TLS host.
sensor# configure terminal
sensor(config)# tls trust ip master_blocking_sensor_ip_address
For More Information
For the procedure to configure the sensor to be a master blocking sensor, refer to Configuring the Sensor to be a Master Blocking Sensor .
Logging
TAC may suggest that you turn on debug logging for troubleshooting purposes. Logger 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. This section contains the following topics:
Enabling Debug Logging
Caution
Enabling debug logging seriously affects performance and should only be done when instructed by TAC.
To enable debug logging, follow these steps:
Step 1 Log in to the service account.
Step 2 Edit the log.conf file to increase the size of the log to accommodate the additional log statements.
vi /usr/cids/idsRoot/etc/log.conf
Step 3 Change fileMaxSizeInK=500
to fileMaxSizeInK=5000
.
Step 4 Locate the zone and CID section of the file and set the severity to debug.
Step 5 Save the file, exit the vi editor, and exit the service account.
Step 6 Log in to the CLI as administrator.
Step 7 Enter master control submode.
sensor# configure terminal
sensor(config)# service logger
sensor(config-log)# master-control
Step 8 Enable debug logging for all zones.
sensor(config-log-mas)# enable-debug true
sensor(config-log-mas)# show settings
-----------------------------------------------
enable-debug: true default: false
individual-zone-control: false <defaulted>
-----------------------------------------------
Step 9 Turn on individual zone control.
sensor(config-log-mas)# individual-zone-control true
sensor(config-log-mas)# show settings
-----------------------------------------------
enable-debug: true default: false
individual-zone-control: true default: false
-----------------------------------------------
Step 10 Exit master zone control.
sensor(config-log-mas)# exit
Step 11 View the zone names.
sensor(config-log)# show settings
-----------------------------------------------
enable-debug: false <defaulted>
individual-zone-control: true default: false
-----------------------------------------------
zone-control (min: 0, max: 999999999, current: 14)
-----------------------------------------------
zone-name: AuthenticationApp
severity: warning <defaulted>
severity: debug <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
zone-name: ctlTransSource
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
-----------------------------------------------
Step 12 Change the severity level (debug, timing, warning, or error) for a particular zone.
sensor(config-log)# zone-control IdsEventStore severity error
sensor(config-log)# show settings
-----------------------------------------------
enable-debug: true default: false
individual-zone-control: true default: false
-----------------------------------------------
zone-control (min: 0, max: 999999999, current: 14)
-----------------------------------------------
zone-name: AuthenticationApp
severity: warning <defaulted>
severity: debug <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: error default: warning
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
zone-name: ctlTransSource
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
-----------------------------------------------
Step 13 Turn on debugging for a particular zone.
sensor(config-log)# zone-control nac severity debug
sensor(config-log)# show settings
-----------------------------------------------
enable-debug: true default: false
individual-zone-control: true default: false
-----------------------------------------------
zone-control (min: 0, max: 999999999, current: 14)
-----------------------------------------------
zone-name: AuthenticationApp
severity: warning <defaulted>
severity: debug <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: error default: warning
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
severity: warning <defaulted>
zone-name: ctlTransSource
severity: warning <defaulted>
severity: warning <defaulted>
severity: debug default: warning
severity: warning <defaulted>
severity: warning <defaulted>
-----------------------------------------------
Step 14 Exit the logger submode.
Step 15 Press Enter to apply changes or type no to discard them:
For More Information
For a list of what each zone name refers to, see Zone Names.
Zone Names
Table E-2 lists the debug logger zone names:
Table E-2 Debug Logger Zone Names
|
|
AD |
Anomaly Detection zone |
AuthenticationApp |
Authentication zone |
Cid |
General logging zone |
Cli |
CLI zone |
IdapiCtlTrans |
All control transactions zone |
IdsEventStore |
Event Store zone |
MpInstaller |
IDSM-2 master partition installer zone |
cmgr |
Card Manager service zone |
cplane |
Control Plane zone |
csi |
CIDS Servlet Interface |
ctlTransSource |
Outbound control transactions zone |
intfc |
Interface zone |
nac |
ARC zone |
rep |
Reputation zone |
sched |
Automatic update scheduler zone |
sensorApp |
AnalysisEngine zone |
tls |
SSL and TLS zone |
For More Information
To learn more about the IPS Logger service, refer to Logger .
Directing cidLog Messages to SysLog
It might be useful to direct cidLog messages to syslog.
To direct cidLog messages to syslog, follow these steps:
Step 1
Go to the idsRoot/etc/log.conf file.
Step 2 Make the following changes:
a. Set [logApp] enabled=false
Comment out the enabled=true
because enabled=false
is the default.
b. Set [drain/main] type=syslog
The following example shows the logging configuration file:
;-------- FIFO parameters --------
;-------- logApp zone and drain parameters --------
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.
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.
Note TCP Resets are not supported over MPLS links or the following tunnels: GRE, IPv4 in IPv4, IPv6 in IPv4, or IPv4 in IPv6.
To troubleshoot a reset not occurring for a specific signature, follow these steps:
Step 1
Log in to the CLI.
Step 2 Make sure the event action is set to TCP reset.
sensor# configure terminal
sensor(config)# service signature-definition sig0
sensor(config-sig)# signatures 1000 0
sensor(config-sig-sig)# engine atomic-ip
sensor(config-sig-sig-ato)# event-action reset-tcp-connection|produc-alert
sensor(config-sig-sig-ato)# show settings
-----------------------------------------------
event-action: produce-alert|reset-tcp-connection default: produce-alert
fragment-status: any <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
specify-ip-payload-length
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
Step 3 Exit signature definition submode.
sensor(config-sig-sig-ato)# exit
sensor(config-sig-sig)# exit
Step 4 Press Enter to apply the changes or type no to discard them.
Step 5 Make sure the correct alarms are being generated.
sensor# show events alert
evAlert: eventId=1047575239898467370 severity=medium
signature: sigId=20000 sigName=STRING.TCP subSigId=0 version=Unknown
addr: locality=OUT 172.16.171.19
addr: locality=OUT 172.16.171.13 port: 23
Step 6 Make sure the switch is allowing incoming TCP reset packet from the sensor. Refer to your switch documentation for more information.
Step 7 Make sure the resets are being sent.
root# ./tcpdump -i eth0 src host 172.16.171.19
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0
13:58:03.823929 172.16.171.19.32770 > 172.16.171.13.telnet: R 79:79(0) ack 62 win 0
13:58:03.823930 172.16.171.19.32770 > 172.16.171.13.telnet: R 80:80(0) ack 62 win 0
13:58:03.823930 172.16.171.19.32770 > 172.16.171.13.telnet: R 80:80(0) ack 62 win 0
13:58:03.823930 172.16.171.19.32770 > 172.16.171.13.telnet: R 80:80(0) ack 62 win 0
Software Upgrades
This section helps in troubleshooting software upgrades. It contains the following topics:
Upgrading and Analysis Engine
When you upgrade an IPS sensor , you may receive an error that the Analysis Engine is not running:
sensor#
upgrade scp://user@10.1.1.1/upgrades/IPS-K9-7.1-2-E4.pkg
Warning: Executing this command will apply a major version upgrade to the application partition. The system may be rebooted to complete the upgrade.
Continue with upgrade?: yes
Error: AnalysisEngine is not running. Please reset box and attempt upgrade again.
If you receive this error, you must get the Analysis Engine 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 the setup command and remove the interfaces from the virtual sensor vs0. When it is not monitoring traffic, Analysis Engine usually stays up and running. You can upgrade at this time. After the upgrade, add the interfaces back to the virtual sensor vs0 using the setup command.
Or you can use the system image file to reimage the sensor directly to the version you want. You can reimage a sensor and avoid the error because the reimage process does not check to see if the Analysis Engine is running.
Caution Reimaging using the system image file restores all configuration defaults.
For More Information
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 and engine version listed in the filename.
- Engine updates require the major or minor version in the engine update filename. Service packs require the correct minor version.
- Minor versions require the correct major version.
- Major versions require the previous major version.
For More Information
To understand how to interpret the IPS software filenames, see IPS Software Versioning.
Issues With Automatic Update
Caution In IPS 7.1(5)E4 and later the default value of the Cisco server IP address has been changed from 198.133.219.25 to 72.163.4.161 in the Auto Update URL configuration. If you have automatic update configured on your sensor, you may need to update firewall rules to allow the sensor to connect to this new IP address.
The following list provides suggestions for troubleshooting automatic updates:
– Create a service account. Su to root and run TCPDUMP on the command and control interface to capture packets between the sensor and the FTP server.
– Use the upgrade command to manually upgrade the sensor.
– Look at the TCPDUMP output for errors coming back from the FTP server.
- Make sure the sensor is in the correct directory. The directory must be specified correctly. This has caused issues with Windows FTP servers. Sometimes an extra “/” or even two “/” are needed in front of the directory name. To verify this, use the same FTP commands you see in the TCPDUMP output through your own FTP connection.
- You must use the Windows FTP server setup option to emulate UNIX file structure and not MS-DOS file structure.
- If you are using SCP, make sure you have added the SSH host key to the known hosts list.
- If you get an unauthorized error message while configuring an automatic update, make sure you have the correct ports open on any firewalls between the sensor and Cisco.com. For example, you need port 443 for the initial automatic update connection to www.cisco.com, and you need port 80 to download the chosen package from a Cisco file server. The IP address may change for the Cisco file server, but you can find it in the lastDownloadAttempt section in the output of the show statistics host command.
Try the manual upgrade command before attempting the automatic update. If it works with the upgrade command and does not work with the automatic update, try the following:
- Determine which IPS software version your sensor has.
- Make sure the passwords are configured for automatic update. Make sure they match the same passwords used for manual update.
- Make sure that the filenames in the FTP server are exactly what you see on Downloads on Cisco.com. This includes capitalization. Some Windows FTP servers allow access to the file with the incorrect capitalization but the sensor ultimately rejects the file because the name has changed.
- If necessary, run TCPDUMP on automatic update. You can compare the successful manual update with the unsuccessful automatic update and troubleshoot from there.
For More Information
Updating a Sensor with the Update Stored on the Sensor
You can store the update package in the /var directory on the sensor and update the sensor from there if you need to.
To update the sensor with an update stored on the sensor, follow these steps:
Step 1
Log in to the service account.
Step 2 Obtain the update package file from Cisco.com.
Step 3 FTP or SCP the update file to the sensor /usr/cids/idsRoot/var directory.
Step 4 Set the file permissions:.
chmod 644 ips_package_file_name
Step 5 Exit the service account.
Step 6 Log in to the sensor using an account with administrator privileges.
Step 7 Store the sensor host key.
sensor# configure terminal
sensor(config)# service ssh
sensor(config-ssh)# rsa1-keys sensor_ip_address
Step 8 Upgrade the sensor.
sensor(config)# upgrade scp://service@sensor_ip_address/upgrade/ips_package_file_name
For More Information
For the procedure for obtaining Cisco IPS software, see Obtaining Cisco IPS Software.
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:
Health and Network Security Information
Caution When the sensor is first starting, it is normal for certain health metric statuses to be red until the sensor is fully up and running.
Note The ASA 5500-X IPS SSP and the ASA 5585-X IPS SSP do not support bypass mode. The adaptive security appliance will either fail open, fail close, or fail over depending on the configuration of the adaptive security appliance and the type of activity being done on the IPS.
Use the show health command in privileged EXEC mode to display the overall health status information of the sensor. The health status categories are rated by red and green with red being critical.
To display the overall health status of the sensor, follow these steps:
Step 1
Log in to the CLI.
Step 2 Show the health and security status of the sensor.
Overall Health Status Red
Health Status for Failed Applications Green
Health Status for Signature Updates Green
Health Status for License Key Expiration Red
Health Status for Running in Bypass Mode Green
Health Status for Interfaces Being Down Red
Health Status for the Inspection Load Green
Health Status for the Time Since Last Event Retrieval Green
Health Status for the Number of Missed Packets Green
Health Status for the Memory Usage Not Enabled
Health Status for Global Correlation Red
Health Status for Network Participation Not Enabled
Security Status for Virtual Sensor vs0 Green
Tech Support Information
The show tech-support command is useful for capturing all sensor status and configuration information. This section describes the show tech-support command, and contains the following topics:
Understanding the show tech-support Command
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 Always run the show tech-support command before contacting TAC.
Displaying Tech Support Information
Note The show tech-support command now displays historical interface data for each interface for the past 72 hours.
Use the show tech-support [ page ] [ destination-url destination_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 the 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.
- 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
Varlog Files
The /var/log/messages file has the latest logs. A new softlink called varlog has been created under the /usr/cids/idsRoot/log folder that points to the /var/log/messages file. Old logs are stored in varlog.1 and varlog.2 files. The maximum size of these varlog files is 200 KB. Once they cross the size limit the content is rotated. The content of varlog, varlog.1, and varlog.2 is displayed in the output of the show tech-support command.
Displaying Tech Support Information
To display tech support information, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 View the output on the screen. 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
sensor# show tech-support page
Step 3 To send the output (in HTML format) to a file:
a. Enter the following command, followed by a valid destination. The password:
prompt appears.
sensor# show tech-support destination-url destination_url
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
b. Enter the password for this user account. The Generating report:
message is displayed.
Tech Support Command Output
Note This output example shows the first part of the command and lists the information for the interfaces, authentication, and the Analysis Engine.
Note The CLI output is an example of what your configuration may look like. It will not match exactly due to the optional setup choices, sensor model, and IPS 7.1 version you have installed.
The following is an example of the show tech-support command output:
sensor# show tech-support page
This Report was generated on Wed Nov 30 23:40:09 2011.
Cisco Intrusion Prevention System, Version 7.1(3)E4
Signature Update S605.0 2011-10-25
Platform: ASA5585-SSP-IPS10
Serial Number: 123456789AB
Sensor up-time is 13 days.
Using 4395M out of 5839M bytes of available memory (75% usage)
system is using 26.2M out of 160.0M bytes of available disk space (16% usage)
application-data is using 69.7M out of 171.6M bytes of available disk space (43%
boot is using 57.3M out of 70.5M bytes of available disk space (86% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96%
MainApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
AnalysisEngine S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CollaborationApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CLI S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
IPS-K9-7.1-3-E4 00:30:07 UTC Wed Nov 16 2011
Recovery Partition Version 1.1 - 7.1(3)E4
Host Certificate Valid from: 16-Nov-2011 to 16-Nov-2013
Output from show interfaces
Total Packets Received = 4285610
Total Bytes Received = 548558080
Missed Packet Percentage = 0
MAC statistics from interface Management0/0
Interface function = Command-control interface
Total Packets Received = 9584350
Total Bytes Received = 986355666
Total Multicast Packets Received = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 7205444
Total Bytes Transmitted = 1376470584
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
MAC statistics from interface PortChannel0/0
Interface function = Sensing interface
Hardware Bypass Capable = No
Hardware Bypass Paired = N/A
Admin Enabled Status = Enabled
Missed Packet Percentage = 0
Total Packets Received = 4285610
Total Bytes Received = 548558080
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 0
Total Receive FIFO Overruns = 0
Total requests for buffer when none available = 0
Total Packets Transmitted = 4285610
Total Bytes Transmitted = 548558080
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 Management0/1
Interface function = Reserved for future use
Output from show statistics authentication
totalAuthenticationAttempts = 237
failedAuthenticationAttempts = 14
Output from show statistics analysis-engine
Analysis Engine Statistics
Number of seconds since service started = 1150851
Processing Load Percentage
The rate of TCP connections tracked per second = 0
The rate of packets per second = 0
The rate of bytes per second = 0
Total number of packets processed since reset = 0
Total number of IP packets processed since reset = 0
Total number of packets transmitted = 4285631
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.
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
Version Information
The show version command is useful for obtaining sensor information. This section describes the show version command, and contains the following topics:
Understanding the show version Command
The show version command shows the basic sensor information 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, choose Monitoring > Sensor Monitoring > Support Information > Diagnostics Report. To get the same information from IME, choose Configuration > sensor_name > Sensor 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.
Note The CLI output is an example of what your configuration may look like. It will not match exactly due to the optional setup choices, sensor model, and IPS 7.1 version you have installed.
To display the version and configuration, follow these steps:
Step 1
Log in to the CLI.
Step 2 View version information.
Cisco Intrusion Prevention System, Version 7.1(3)E4
Signature Update S605.0 2011-10-25
Platform: ASA5585-SSP-IPS10
Serial Number: 123456789AB
Sensor up-time is 13 days.
Using 4395M out of 5839M bytes of available memory (75% usage)
system is using 26.2M out of 160.0M bytes of available disk space (16% usage)
application-data is using 69.7M out of 171.6M bytes of available disk space (43%
boot is using 57.3M out of 70.5M bytes of available disk space (86% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96%
MainApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
AnalysisEngine S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CollaborationApp S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
CLI S-2011_NOV_16_00_20_7_1_3_46 (Release) 2011-11-16T00:23:0
IPS-K9-7.1-3-E4 00:30:07 UTC Wed Nov 16 2011
Recovery Partition Version 1.1 - 7.1(3)E4
Host Certificate Valid from: 16-Nov-2011 to 16-Nov-2013
Note If the —-MORE-—
prompt is displayed, press the spacebar to see more information or Ctrl-C to cancel the output and get back to the CLI prompt.
Step 3 View configuration information.
Note You can use the more current-config or show configuration commands.
sensor# more current-config
! ------------------------------
! Current configuration last modified Tue Nov 22 16:11:35 2011
! ------------------------------
! Signature Update S605.0 2011-10-25
! ------------------------------
! ------------------------------
! ------------------------------
service event-action-rules rules0
! ------------------------------
host-ip 192.168.1.2/24, 192.168.1.1
dns-primary-server disabled
! ------------------------------
! ------------------------------
! ------------------------------
! ------------------------------
service signature-definition sig0
! ------------------------------
! ------------------------------
service trusted-certificates
! ------------------------------
! ------------------------------
service anomaly-detection ad0
! ------------------------------
service external-product-interface
! ------------------------------
! ------------------------------
service global-correlation
! ------------------------------
! ------------------------------
Statistics Information
The show statistics command is useful for examining the state of the sensor services. This section describes the show statistics command, and contains the following topics:
Understanding the show statistics Command
The show statistics command provides a snapshot of the state of the sensor services. The following services provide statistics:
- AnalysisEngine
- Authentication
- Denied Attackers
- Event Server
- Event Store
- Host
- Logger
- Attack Response (formerly known as Network Access)
- Notification
- SDEE Server
- Transaction Server
- Transaction Source
- Virtual Sensor
- Web Server
Note To get the same information from IDM, choose Monitoring > Sensor Monitoring > Support Information > Statistics. To get the same information from IME, choose Configuration > sensor_name > Sensor Monitoring > Support Information >Statistics.
Displaying Statistics
Use the show statistics [analysis-engine | anomaly-detection | authentication | denied-attackers | event-server | event-store | external-product-interface | global-correlation | host | logger | network-access | notification | os-identification | sdee-server | transaction-server | virtual-sensor | web-server ] [ clear ] command to display statistics for each sensor application.
Use the show statistics { anomaly-detection | denied-attackers | os-identification | virtual-sensor } [ name | clear ] command 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 the Analysis Engine.
sensor# show statistics analysis-engine
Analysis Engine Statistics
Number of seconds since service started = 431157
Processing Load Percentage
The rate of TCP connections tracked per second = 0
The rate of packets per second = 0
The rate of bytes per second = 0
Total number of packets processed since reset = 0
Total number of IP packets processed since reset = 0
Total number of packets transmitted = 133698
Total number of packets denied = 203
Total number of packets reset = 3
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.
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
Inspector active call create delete loadPct
AtomicAdvanced 0 2312 4 4 33
MSRPC_UDP 0 1808 1575 1575 0
MultiString 0 145 10 10 2
ServiceDnsUdp 0 1841 3 3 0
ServiceGeneric 0 2016 14 14 1
ServiceNtp 0 3682 3176 3176 0
ServiceRpcUDP 0 1841 3 3 0
ServiceRpcTCP 0 130 9 9 0
ServiceSMBAdvanced 0 139 3 3 0
SweepUDP 0 1808 1555 1555 6
SweepOtherTcp 0 288 6 6 0
TrojanUdp 0 1808 1555 1555 0
ReputationFilterVersion = 0
AlertsWithModifiedRiskRating = 0
AlertsWithGlobalCorrelationDenyAttacker = 0
AlertsWithGlobalCorrelationDenyPacket = 0
AlertsWithGlobalCorrelationOtherAction = 0
AlertsWithAuditRepDenies = 0
ReputationForcedAlerts = 0
EventStoreInsertTotal = 0
EventStoreInsertWithHit = 0
EventStoreInsertWithMiss = 0
EventStoreDenyFromGlobalCorrelation = 0
EventStoreDenyFromOverride = 0
EventStoreDenyFromOverlap = 0
EventStoreDenyFromOther = 0
ReputationFilterDataSize = 0
ReputationFilterPacketsInput = 0
ReputationFilterRuleMatch = 0
DenyFilterHitsGlobalCorrelation = 0
SimulatedReputationFilterPacketsInput = 0
SimulatedReputationFilterRuleMatch = 0
SimulatedDenyFilterInsert = 0
SimulatedDenyFilterPacketsInput = 0
SimulatedDenyFilterRuleMatch = 0
TcpDeniesDueToGlobalCorrelation = 0
TcpDeniesDueToOverride = 0
TcpDeniesDueToOverlap = 0
SimulatedTcpDeniesDueToGlobalCorrelation = 0
SimulatedTcpDeniesDueToOverride = 0
SimulatedTcpDeniesDueToOverlap = 0
SimulatedTcpDeniesDueToOther = 0
LateStageDenyDueToGlobalCorrelation = 0
LateStageDenyDueToOverride = 0
LateStageDenyDueToOverlap = 0
LateStageDenyDueToOther = 0
SimulatedLateStageDenyDueToGlobalCorrelation = 0
SimulatedLateStageDenyDueToOverride = 0
SimulatedLateStageDenyDueToOverlap = 0
SimulatedLateStageDenyDueToOther = 0
SubmittedBytes = 72258005
TCPMissedPacketsDueToUpdate = 0
UDPMissedPacketsDueToUpdate = 0
MaliciousSiteDenyHitCounts
MaliciousSiteDenyHitCountsAUDIT
Step 3 Display the statistics for anomaly detection.
sensor# show statistics anomaly-detection
Statistics for Virtual Sensor vs0
Next KB rotation at 10:00:01 UTC Sat Jan 18 2008
Statistics for Virtual Sensor vs1
Next KB rotation at 10:00:00 UTC Sat Jan 18 2008
Step 4 Display the statistics for authentication.
sensor# show statistics authentication
totalAuthenticationAttempts = 128
failedAuthenticationAttempts = 0
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.
Step 6 Display the statistics for the Event Server.
sensor# show statistics event-server
Step 7 Display the statistics for the Event Store.
sensor# show statistics event-store
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 filtered events not written to the event store = 850763
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
Error events, warning = 669
Alert events, informational = 0
Alert events, threat rating 0-20 = 0
Alert events, threat rating 21-40 = 0
Alert events, threat rating 41-60 = 0
Alert events, threat rating 61-80 = 0
Alert events, threat rating 81-100 = 0
Cumulative number of each type of event
Error events, warning = 669
Alert events, informational = 0
Alert events, threat rating 0-20 = 0
Alert events, threat rating 21-40 = 0
Alert events, threat rating 41-60 = 0
Alert events, threat rating 61-80 = 0
Alert events, threat rating 81-100 = 0
Step 8 Display the statistics for global correlation.
sensor# show statistics global-correlation
Total Connection Attempts = 0
Total Connection Failures = 0
Connection Failures Since Last Success = 0
Status Of Last Update Attempt = Disabled
Time Since Last Successful Update = never
Update Failures Since Last Success = 0
Total Update Attempts = 0
Total Update Failures = 0
Update Interval In Seconds = 300
Update Server = update-manifests.ironport.com
Update Server Address = Unknown
Unlicensed = Global correlation inspection and reputation filtering have been
disabled because the sensor is unlicensed.
Action Required = Obtain a new license from http://www.cisco.com/go/license.
Step 9 Display the statistics for the host.
sensor# show statistics host
Last Change To Host Config (UTC) = 25-Jan-2012 02:59:18
Command Control Port Device = Management0/0
= ma0_0 Link encap:Ethernet HWaddr 00:04:23:D5:A1:8D
= inet addr:10.89.130.98 Bcast:10.89.131.255 Mask:255.255.254.0
= UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
= RX packets:1688325 errors:0 dropped:0 overruns:0 frame:0
= TX packets:38546 errors:0 dropped:0 overruns:0 carrier:0
= collisions:0 txqueuelen:1000
= RX bytes:133194316 (127.0 MiB) TX bytes:5515034 (5.2 MiB)
= Base address:0xcc80 Memory:fcee0000-fcf00000
Note: CPU Usage statistics are not a good indication of the sensor processin load. The Inspection Load Percentage in the output of 'show inspection-load' should be used instead.
Usage over last 5 seconds = 0
Usage over last minute = 2
Usage over last 5 minutes = 2
Usage over last 5 seconds = 0
Usage over last minute = 1
Usage over last 5 minutes = 1
Memory usage (bytes) = 1889357824
Memory free (bytes) = 2210988032
lastDirectoryReadAttempt = N/A
lastDownloadAttempt = N/A
Auxilliary Processors Installed
Step 10 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
The number of log messages written to the message log by severity
Step 11 Display the statistics for the ARC.
sensor# show statistics network-access
LogAllBlockEventsAndSensors = true
MaxDeviceInterfaces = 250
Communications = ssh-3des
Communications = ssh-3des
InterfaceName = ethernet0/1
InterfacePostBlock = Post_Acl_Test
InterfaceName = ethernet0/1
InterfacePreBlock = Pre_Acl_Test
InterfacePostBlock = Post_Acl_Test
InterfacePreBlock = Pre_Acl_Test
InterfacePostBlock = Post_Acl_Test
AclSupport = Does not use ACLs
AclSupport = Does not use ACLs
AclSupport = Does not use ACLs
AclSupport = uses Named ACLs
Step 12 Display the statistics for the notification application.
sensor# show statistics notification
Number of SNMP set requests = 0
Number of SNMP get requests = 0
Number of error traps sent = 0
Number of alert traps sent = 0
Step 13 Display the statistics for OS identification.
sensor# show statistics os-identification
Statistics for Virtual Sensor vs0
Step 14 Display the statistics for the SDEE server.
sensor# show statistics sdee-server
Blocked Subscriptions = 1
Maximum Available Subscriptions = 5
Maximum Events Per Retrieval = 500
Last Read Time = 23:54:16 UTC Wed Nov 30 2011
Last Read Time (nanoseconds) = 1322697256078549000
Step 15 Display the statistics for the transaction server.
sensor# show statistics transaction-server
totalControlTransactions = 35
failedControlTransactions = 0
Step 16 Display the statistics for a virtual sensor.
sensor# show statistics virtual-sensor vs0
Statistics for Virtual Sensor vs0
Name of current Signature-Defintion 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 = 1151770
MemoryMaxCapacity = 3500000
MemoryMaxHighUsed = 4193330
MemoryCurrentAllo = 805452
MemoryCurrentUsed = 789047
Processing Load Percentage = 1
Total packets processed since reset = 0
Total IP packets processed since reset = 0
Total IPv4 packets processed since reset = 0
Total IPv6 packets processed since reset = 0
Total IPv6 AH packets processed since reset = 0
Total IPv6 ESP packets processed since reset = 0
Total IPv6 Fragment packets processed since reset = 0
Total IPv6 Routing Header packets processed since reset = 0
Total IPv6 ICMP 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 = 0
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 GRE Packets processed since reset = 0
Total GRE Fragment Packets processed since reset = 0
Total GRE Packets skipped since reset = 0
Total GRE Packets with Bad Header skipped since reset = 0
Total IpIp Packets with Bad Header skipped since reset = 0
Total Encapsulated Tunnel Packets with Bad Header skipped 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 cross queue TCP packets processed since reset = 0
Total cross queue UDP packets processed since reset = 0
Packets dropped due to regex resources unavailable 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
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
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
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 constraints
TCP nodes keyed on both IP addresses and both ports = 0
Packets dropped because they would exceed Database insertion rate limits = 0
Fragment Reassembly Unit Statistics for this Virtual Sensor
Number of fragments currently in FRU = 0
Number of datagrams currently in FRU = 0
Number of fragments received since reset = 0
Number of fragments forwarded since reset = 0
Number of fragments dropped since last reset = 0
Number of fragments modified since last reset = 0
Number of complete datagrams reassembled since last reset = 0
Fragments hitting too many fragments condition since last reset = 0
Number of overlapping fragments since last reset = 0
Number of Datagrams too big since last reset = 0
Number of overwriting fragments since last reset = 0
Number of Inital fragment missing since last reset = 0
Fragments hitting the max partial dgrams limit since last reset = 0
Fragments too small since last reset = 0
Too many fragments per dgram limit since last reset = 0
Number of datagram reassembly timeout since last reset = 0
Too many fragments claiming to be the last since last reset = 0
Fragments with bad fragment flags since last reset = 0
TCP Normalizer stage statistics
Dropped packets from queue = 0
Dropped packets due to deny-connection = 0
Current Streams Closed = 0
Current Streams Closing = 0
Current Streams Embryonic = 0
Current Streams Established = 0
Current Streams Denied = 0
Total SendAck Limited Packets = 0
Total SendAck Limited Streams = 0
Total SendAck Packets Sent = 0
Statistics for the TCP Stream Reassembly Unit
Current Statistics for the TCP Stream Reassembly Unit
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
Cumulative Statistics for the TCP Stream Reassembly Unit since reset
TCP streams that have been tracked since last reset = 0
TCP streams that had a gap in the sequence jumped = 0
TCP streams that was abandoned due to a gap in the sequence = 0
TCP packets that arrived out of sequence order for their stream = 0
TCP packets that arrived out of state order for their stream = 0
The rate of TCP connections tracked per second since reset = 0
SigEvent Preliminary Stage Statistics
Number of Alerts received = 0
Number of Alerts Consumed by AlertInterval = 0
Number of Alerts Consumed by Event Count = 0
Number of FireOnce First Alerts = 0
Number of FireOnce Intermediate Alerts = 0
Number of Summary First Alerts = 0
Number of Summary Intermediate Alerts = 0
Number of Regular Summary Final Alerts = 0
Number of Global Summary Final Alerts = 0
Number of Active SigEventDataNodes = 0
Number of Alerts Output for further processing = 0
Step 17 Display the statistics for the web server.
sensor# show statistics web-server
remote host = 64.101.182.167
session is persistent = no
number of requests serviced on current connection = 1
last request method = GET
last request URI = cgi-bin/sdee-server
last protocol version = HTTP/1.1
session state = processingGetServlet
number of server session requests handled = 957134
number of server session requests rejected = 0
total HTTP requests handled = 365871
maximum number of session objects allowed = 40
number of idle allocated session objects = 12
number of busy allocated session objects = 1
number of TCP socket failure messages logged = 0
number of TLS socket failure messages logged = 0
number of TLS protocol failure messages logged = 0
number of TLS connection failure messages logged = 595015
number of TLS crypto warning messages logged = 0
number of TLS expired certificate warning messages logged = 0
number of receipt of TLS fatal alert message messages logged = 594969
crypto library version = 6.2.1.0
Step 18 Clear the statistics for an application, for example, the logging application. The statistics are retrieved and cleared.
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
The number of log messages written to the message log by severity
Step 19 Verify that the statistics have been cleared. The statistics now all begin from 0.
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
The number of log messages written to the message log by severity
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:
Understanding the show interfaces Command
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:
Total Packets Received = 0
Missed Packet Percentage = 0
Current Bypass Mode = Auto_off
MAC statistics from interface GigabitEthernet0/1
Missed Packet Percentage = 0
Total Packets Received = 0
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 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
Total Packets Received = 2211296
Total Bytes Received = 157577635
Total Multicast Packets Received = 20
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 239723
Total Bytes Transmitted = 107213390
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
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
There are five types of events:
- evAlert—Intrusion detection alerts
- evError—Application errors
- evStatus—Status changes, such as an IP log being created
- 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.
Understanding the show events Command
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.
Here are the parameters for the show events command:
alert Display local system alerts.
error Display error events.
hh:mm[:ss] Display start time.
nac Display NAC shun events.
past Display events starting in the past specified time.
status Display status events.
Displaying Events
Note The Event Store has a fixed size of 30 MB for all platforms.
Note Events are displayed as a live feed. To cancel the request, press Ctrl-C.
Use the show events [{ alert [informational] [low] [medium] [high] [ include-traits traits ] [ exclude-traits traits ] [ min-threat-rating min-rr ] [ max-threat-rating max-rr ] | error [warning] [error] [fatal] | NAC | status }] [ hh:mm:ss [ month day [ year ]] | past hh:mm:ss ] command to display events from Event Store. 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.
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 the 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 —Specifies the 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.
- NAC —Displays the ARC (block) requests.
Note The ARC is formerly known as NAC. This name change has not been completely implemented throughout the IDM, the IME, and the CLI for Cisco IPS 7.1.
- status —Displays status events.
- past —Displays events starting in the past for the specified hours, minutes, and seconds.
- hh:mm:ss —Specifies the hours, minutes, and seconds in the past to begin the display.
Note The show events command continues to display events until a specified event is available. To exit, press Ctrl-C.
Displaying Events
To display events from the Event Store, follow these steps:
Step 1
Log in to the CLI.
Step 2 Display all events starting now. The feed continues showing all events until you press Ctrl-C .
evError: eventId=1041472274774840147 severity=warning vendor=Cisco
time: 2011/01/07 04:41:45 2011/01/07 04:41:45 UTC
errorMessage: name=errWarning received fatal alert: certificate_unknown
evError: eventId=1041472274774840148 severity=error vendor=Cisco
time: 2011/01/07 04:41:45 2011/01/07 04:41:45 UTC
errorMessage: name=errTransport WebSession::sessionTask(6) TLS connection exception: handshake incomplete.
Step 3 Display the block requests beginning at 10:00 a.m. on February 9, 2011.
sensor# show events NAC 10:00:00 Feb 9 2011
evShunRqst: eventId=1106837332219222281 vendor=Cisco
appName: NetworkAccessControllerApp
time: 2011/02/09 10:33:31 2011/08/09 13:13:31
host: connectionShun=false
protocol: numericType=0 other
evAlertRef: hostId=esendHost 123456789012345678
Step 4 Display errors with the warning level starting at 10:00 a.m. on February 9, 2011.
sensor# show events error warning 10:00:00 Feb 9 2011
evError: eventId=1041472274774840197 severity=warning vendor=Cisco
time: 2011/01/07 04:49:25 2011/01/07 04:49:25 UTC
errorMessage: name=errWarning received fatal alert: certificate_unknown
Step 5 Display alerts from the past 45 seconds.
sensor# show events alert past 00:00:45
evIdsAlert: eventId=1109695939102805307 severity=medium vendor=Cisco
time: 2011/03/02 14:15:59 2011/03/02 14:15:59 UTC
signature: description=Nachi Worm ICMP Echo Request id=2156 version=S54
addr: locality=OUT 10.89.228.202
addr: locality=OUT 10.89.150.185
evIdsAlert: eventId=1109695939102805308 severity=medium vendor=Cisco
Step 6 Display events that began 30 seconds in the past.
sensor# show events past 00:00:30
evStatus: eventId=1041526834774829055 vendor=Cisco
time: 2011/01/08 02:41:00 2011/01/08 02:41:00 UTC
controlTransaction: command=getVersion successful=true
description: Control transaction response.
evStatus: eventId=1041526834774829056 vendor=Cisco
time: 2011/01/08 02:41:00 2011/01/08 02:41:00 UTC
description: session opened for user cisco by cisco(uid=0)
Clearing Events
Use the clear events command to clear the Event Store.
To clear events from the Event Store, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Clear the Event Store.
Warning: Executing this command will remove all events currently stored in the event store.
Step 3 Enter yes to clear the events.
cidDump Script
If you do not have access to the IDM, the 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.
For More Information
For the procedure for putting a file on the Cisco FTP site, see Uploading and Accessing Files on the Cisco FTP Site.
Uploading and Accessing Files on the Cisco FTP Site
You can upload large files, for example, cidDump.html, the show tech-support command output, and cores, to the ftp-sj server.
To upload and access files on the Cisco FTP site, follow these steps:
Step 1
Log in to ftp-sj.cisco.com as anonymous.
Step 2 Change to the /incoming directory.
Step 3 Use the put command to upload the files. Make sure to use the binary transfer type.
Step 4 To access uploaded files, log in to an ECS-supported host.
Step 5 Change to the /auto/ftp/incoming directory.