Cisco Intrusion Prevention System Sensor CLI Configuration Guide for IPS 7.2

Understanding Preventive Maintenance

The following actions will help you maintain your sensor:

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

• Save your backup configuration to a remote system.
• Always back up your configuration before you do a manual upgrade. If you have auto upgrades configured, make sure you do periodic backups.
• Create a service account. A service account is needed for special debug situations directed by TAC.

For More Information

• For the procedure for backing up a configuration file, see Creating and Using a Backup Configuration File.

• For the procedure for using a remote server to copy and restore the a configuration file, see Backing Up and Restoring the Configuration File Using a Remote Server.
• For more information about the service account, see Creating the Service Account.

Creating and Using a Backup Configuration File

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

To back up your current configuration, follow these steps:

Step 2 Save the current configuration. The current configuration is saved in a backup file.

Step 3 Display the backup configuration file. The backup configuration file is displayed.

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

• Merge the backup configuration into the current configuration.

• Overwrite the current configuration with the backup configuration.

Backing Up and Restoring the Configuration File Using a Remote Server

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

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

The following parameters apply:

• /erase —Erases the destination file before copying.

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

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

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

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

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

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

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

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

Note You are prompted for a password.

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

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

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

Note You are prompted for a password. You must add the remote host to the SSH known hosts list.

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

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

Note The directory specification should be an absolute path to the desired file.

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

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

Note The directory specification should be an absolute path to the desired file. The remote host must be a TLS trusted host.

Backing Up the Current Configuration to a Remote Server

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

Enter yes to copy the current configuration to a backup configuration.

cfg 100% |************************************************| 36124 00:00

 

---

 

Restoring the Current Configuration From a Backup File

To restore your current configuration from a backup file, follow these steps:

---

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

Creating the Service Account

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

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

Note For IPS 5.0 and later, you can no longer remove the cisco account. You can disable it using the no password cisco command, but you cannot remove it. To use the no password cisco command, there must be another administrator account on the sensor. Removing the cisco account through the service account is not supported. If you remove the cisco account through the service account, the sensor most likely will not boot up, so to recover the sensor you must reinstall the sensor system image.

To create the service account, follow these steps:

Step 2 Enter configuration mode.

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

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

Step 5 Exit configuration mode.

When you use the service account to log in to the CLI, you receive this warning.

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 C-1 lists the password recovery methods according to platform.

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

• Using ROMMON

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 4345, IPS 4360, IPS 4510, IPS 4520, IPS 4520-XL 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 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, IPS 4520, IPS 4520-XL, 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 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:

Step 4 Enter the following command to reset the confreg value to 0:

Recovering the Password for the ASA 5500-X IPS SSP

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:

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:

Step 2 Press Enter to confirm.

Step 3 Verify the status of the module. Once the status reads Up , you can session to the ASA 5500-X IPS SSP.

Step 4 Session to the ASA 5500-X IPS SSP.

Step 5 Enter the default username ( cisco) and password ( cisco) at the login prompt.

Step 6 Enter your new password twice.

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 Password for the ASA 5585-X IPS SSP

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:

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:

Step 2 Press Enter to confirm.

Step 3 Verify the status of the module. Once the status reads Up , you can session to the ASA 5585-X IPS SSP.

Step 4 Session to the ASA 5585-X IPS SSP.

Step 5 Enter the default username ( cisco) and password ( cisco) at the login prompt.

Step 6 Enter your new password twice.

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

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 2 Enter global configuration mode.

Step 3 Enter host mode.

Step 4 Disable password recovery.

Disabling Password Recovery Using the IDM or IME

To disable password recovery in the IDM or IME, follow these steps:

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 2 Enter service host submode.

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

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.

Time Sources and the Sensor

Note We recommend that you use an NTP server to regulate time on your sensor. You can use authenticated or unauthenticated NTP. For authenticated NTP, you must obtain the NTP server IP address, NTP server key ID, and the key value from the NTP server. You can set up NTP during initialization or you can configure NTP through the CLI, IDM, IME, or ASDM.

The sensor requires a reliable time source. All events (alerts) must have the correct UTC and local time stamp, otherwise, you cannot correctly analyze the logs after an attack. When you initialize the sensor, you set up the time zones and summertime settings. This section provides a summary of the various ways to set the time on sensors.

The IPS Standalone Appliances

• Use the clock set command to set the time. This is the default.
• Configure the appliance to get its time from an NTP time synchronization source.

Note The currently supported Cisco IPS appliances are the IPS 4345, IPS 4360, IPS 4510, IPS 4520, and IPS 4520-XL.

The ASA IPS Modules

• The ASA 5500-X IPS SSP and ASA 5585-X IPS SSP automatically synchronize their clocks with the clock in the adaptive security appliance in which they are installed. This is the default.

• Configure them to get their time from an NTP time synchronization source, such as a Cisco router other than the parent router.

For More Information

For the procedure for configuring NTP, see Configuring NTP .

Synchronizing IPS Clocks with Parent Device Clocks

The ASA IPS modules (ASA 5500-X IPS SSP and ASA 5585-X IPS SSP) synchronize their clocks to the parent chassis clock (adaptive security appliance) each time the IPS boots up and any time the parent chassis clock is set. The IPS clock and parent chassis clock tend to drift apart over time. The difference can be as much as several seconds per day. To avoid this problem, make sure that both the IPS clock and the parent clock are synchronized to an external NTP server. If only the IPS clock or only the parent chassis clock is synchronized to an NTP server, the time drift occurs.

Verifying the Sensor is Synchronized with the NTP Server

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

To verify the NTP configuration, follow these steps:

Step 2 Generate the host statistics.

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

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

Correcting Time on the Sensor

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

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

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

Note You cannot remove individual events.

For More Information

For the procedure for clearing events, see Clearing Events.

External Product Interfaces Issues

When the external product interface receives host posture and quarantine events, the following issues can arise:

• The sensor can store only a certain number of host records:

– If the number of records exceeds 10,000, subsequent records are dropped.

– If the 10,000 limit is reached and then it drops to below 9900, new records are no longer dropped.

• Hosts can change an IP address or appear to use another host IP address, for example, because of DHCP lease expiration or movement in a wireless network. In the case of an IP address conflict, the sensor presumes the most recent host posture event to be the most accurate.
• A network can include overlapping IP address ranges in different VLANs, but host postures do not include VLAN ID information. You can configure the sensor to ignore specified address ranges.
• A host can be unreachable from the CSA MC because it is behind a firewall. You can exclude unreachable hosts.
• The CSA MC event server allows up to ten open subscriptions by default. You can change this value. You must have an administrative account and password to open subscriptions.
• CSA data is not virtualized; it is treated globally by the sensor.
• Host posture OS and IP addresses are integrated into passive OS fingerprinting storage. You can view them as imported OS profiles.
• You cannot see the quarantined hosts.
• The sensor must recognize each CSA MC host X.509 certificate. You must add them as a trusted host.
• You can configure a maximum of two external product devices.

For More Information

• For more information on working with OS maps and identifications, see Adding, Editing, Deleting, and Moving Configured OS Maps and Displaying and Clearing OS Identifications.

• For the procedure for adding trusted hosts, see Adding TLS Trusted Hosts.

External Product Interfaces Troubleshooting Tips

To troubleshoot external product interfaces, check the following:

• Make sure the interface is active by checking the output from the show statistics external-product-interface command in the CLI, or choose Monitoring > Sensor Monitoring > Support Information > Statistics in the IDM and check the Interface state line in the response, or choose Configuration > sensor_name > Sensor Monitoring > Support Information > Statistics in the IME, and check the Interface state line in the response.
• Make sure you have added the CSA MC IP address to the trusted hosts. If you forgot to add it, add it, wait a few minutes and then check again.
• Confirm subscription login information by opening and closing a subscription on the CSA MC using the browser.
• Check the Event Store for the CSA MC subscription errors.

For More Information

• For the procedure for adding trusted hosts, see Adding TLS Trusted Hosts .

• For the procedure for displaying events, see Displaying Events.

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.

The 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:

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:

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.

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 4200 series sensor. It contains the following topics:

• Cannot Access the Sensor CLI Through Telnet or SSH
• Correcting a Misconfigured Access List
• Duplicate IP Address Shuts Interface Down

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 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.

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.

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.

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

• For the procedure for enabling and disabling Telnet on the sensor, see Enabling and Disabling Telnet.

• For the various ways to open a CLI session directly on the sensor, see Chapter2, “Logging In to the Sensor”

• For the procedure for changing the IP address, see Changing the IP Address, Netmask, and Gateway.

• For the procedure for changing the access list, see Correcting a Misconfigured Access List.

Correcting a Misconfigured Access List

To correct a misconfigured access list, follow these steps:

Step 2 View your configuration to see the access list.

Step 3 Verify that the client IP address is listed in the allowed networks. If it is not, add it.

Step 4 Verify the settings.

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 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.

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 Cisco Intrusion Prevention System Appliances and Modules Installation Guide for IPS 7.2 .

• For the procedure for making sure the IP address is correct, see Changing 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

• Physical Connectivity, SPAN, or VACL Port Issue
• Unable to See Alerts

• Sensor Not Seeing Packets

• Cleaning Up a Corrupted SensorApp Configuration

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 2 Determine the status of the Analysis Engine service and whether you have the latest software updates.

Step 3 If the Analysis Engine is not running, look for any errors connected to it.

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

• For more information on IPS system architecture, see ChapterA, “System Architecture”

• For the procedure for obtaining the latest Cisco IPS software, see Obtaining Cisco IPS Software.

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 2 Make sure the interfaces are up and that the packet count is increasing.

Step 3 If the Link Status is down, make sure the sensing port is connected properly:

• Make sure the sensing port is connected properly on the appliance.
• Make sure the sensing port is connected to the correct SPAN or VACL capture port on IDSM2.

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 Cisco Intrusion Prevention System Appliances and Modules Installation Guide for IPS 7.2 .

• For the procedures for configuring interfaces on your sensor, see Chapter5, “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 2 Make sure the signature is enabled.

Step 3 Make sure you have Produce Alert configured.

Step 4 Make sure the sensor is seeing packets.

Step 5 Check for alerts.

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 2 Make sure the interfaces are up and receiving packets.

Step 3 If the interfaces are not up, do the following:

• Check the cabling.

• Enable the interface.

Step 4 Check to see that the interface is up and receiving packets.

For More Information

For the procedure for installing the sensor properly, refer to your sensor chapter in Cisco Intrusion Prevention System Appliances and Modules Installation Guide for IPS 7.2 .

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 2 Su to root.

Step 3 Stop the IPS applications.

Step 4 Replace the virtual sensor file.

Step 5 Remove the cache files.

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.

For More Information

To learn more about IPS system architecture, see Appendix A, “System Architecture.”

Blocking

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

• Troubleshooting Blocking

• Verifying the ARC is Running
• Verifying ARC Connections are Active
• Device Access Issues
• Verifying the Interfaces and Directions on the Network Device
• Enabling SSH Connections to the Network Device

• Blocking Not Occurring for a Signature

• Verifying the Master Blocking Sensor Configuration

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

• For the procedure to verify that the ARC is running, see Verifying the ARC is Running.

• For the procedure to verify that the ARC is connecting, see Verifying ARC Connections are Active.
• For the procedure to verify that the Event Action is set to Block Host, see Blocking Not Occurring for a Signature.

• For the procedure to verify that the master blocking sensor is properly configured, see Verifying the Master Blocking Sensor Configuration.

• For a discussion of ARC architecture, see Attack Response Controller.

Verifying the ARC is Running

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 2 Verify that the MainApp is running.

Step 3 If the MainApp displays Not Running , the ARC has failed. Contact TAC.

For More Information

To learn more about IPS system architecture, see Appendix A, “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 2 Verify that the ARC is connecting. Check the State section of the output to verify that all devices are connecting.

Step 3 If the ARC is not connecting, look for recurring errors.

Example

Step 4 Make sure you have the latest software updates.

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

• For the procedure for obtaining the latest Cisco IPS software, see Obtaining Cisco IPS Software.

• For more information about configuring devices, see Device Access Issues.

• For the procedure for verifying the interfaces and directions for each network device, see Verifying the Interfaces and Directions on the Network Device.

• For the procedure for enabling SSH, see Enabling SSH Connections to the Network Device.

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.

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.

Note To perform a manual block using IDM, choose Configuration > Sensor Management > Time-Based Actions > Host Blocks. To perform a manual block using IME, choose Configuration > sensor_name > Sensor Management > Time-Based Actions > Host Blocks.

To initiate a manual block to a bogus host, follow these steps:

Step 1 Enter ARC general submode.

Step 2 Start the manual block of the bogus host IP address.

Step 3 Exit general submode.

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.

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.

Step 3 Enable SSH-3DES.

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.

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.

Step 4 Exit signature definition submode.

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.

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.

Step 5 Exit network access general submode.

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.

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.

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.

For More Information

For the procedure to configure the sensor to be a master blocking sensor, see 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

• Zone Names
• Directing cidLog Messages to SysLog

Enabling Debug Logging

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.

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.

Step 8 Enable debug logging for all zones.

Step 9 Turn on individual zone control.

Step 10 Exit master zone control.

Step 11 View the zone names.

Step 12 Change the severity level (debug, timing, warning, or error) for a particular zone.

Step 13 Turn on debugging for a particular zone.

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 C-2 lists the debug logger zone names:

For More Information

To learn more about the IPS Logger service, see 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 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:

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.

TCP Reset Not Occurring for a Signature

Note There is only one sensing interface on the ASA IPS modules (ASA 5500-X IPS SSP and ASA 5585-X IPS SSP), so you cannot designate an alternate TCP reset interface.

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 2 Make sure the event action is set to TCP reset.

Step 3 Exit signature definition submode.

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

Step 5 Make sure the correct alarms are being generated.

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.

Software Upgrades

This section helps in troubleshooting software upgrades. It contains the following topics:

• Upgrading Error

• Which Updates to Apply and Their Prerequisites

• Issues With Automatic Update

• Updating a Sensor with the Update Stored on the Sensor

Upgrading Error

When you upgrade an IPS sensor , you may receive an error that the Analysis Engine is not running:

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.

For More Information

• For more information on running the setup command, see Chapter3, “Initializing the Sensor”

• For more information on reimaging your sensor, see Chapter21, “Upgrading, Downgrading, and Installing System Images”

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

The following list provides suggestions for troubleshooting automatic updates:

• Run TCPDUMP:

– 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.

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

• For the procedure for creating the service account, see Creating the Service Account.

• For the procedure for reimaging your sensor, see Chapter21, “Upgrading, Downgrading, and Installing System Images”

• For the procedure for adding hosts to the SSH known hosts list, see Adding Hosts to the SSH Known Hosts List.

• For the procedure for determining the software version, see Displaying Version 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 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:.

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.

Step 8 Upgrade the sensor.

For More Information

For the procedure for obtaining Cisco IPS software, see Obtaining Cisco IPS Software.

Cannot Launch the IDM - Loading Java Applet Failed

Symptom The browser displays Loading Cisco IDM. Please wait ... At the bottom left corner of the window, Loading Java Applet Failed is displayed.

Possible Cause This condition can occur if multiple Java Plug-ins are installed on the machine on which you are launching the IDM.

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

To clear the cache, follow these steps:

Step 1 Close all browser windows.

Step 2 If you have Java Plug-in 1.3. x installed:

a. Click Start > Settings > Control Panel > Java Plug-in 1.3.x .

b. Click the Advanced tab.

c. Under Java Runtime Environment, select JRE 1.3.x from the drop-down menu.

d. Click the Cache tab.

e. Click Clear .

Step 3 If you have Java Plug-in 1.4. x installed:

a. Click Start > Settings > Control Panel > Java Plug-in 1.4.x .

b. Click the Advanced tab.

c. Under Java Runtime Environment, select JRE 1.3.x from the drop-down menu.

d. Click the Cache tab.

e. Click the Browser tab.

f. Deselect all browser check boxes.

g. Click Clear Cache .

Step 4 Delete the temp files and clear the history in the browser.

Cannot Launch the IDM-The Analysis Engine Busy

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

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

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

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

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

For More Information

• For the procedure for enabling and disabling Telnet on the sensor, see Enabling and Disabling Telnet.

• For the procedure for configuring the web server, see Changing Web Server Settings.

Signatures Not Producing Alerts

If you are not seeing any alerts when signatures are firing, make sure that you have configured Produce Alert as an event action. For example, if you choose Produce Alert, but later add another event action and do not add Produce Alert to the new configuration, alerts are not sent to the Event Store. To make sure you are getting alerts, check the statistics for the virtual sensor and the Event Store.

For More Information

• For more information about event actions, see Event Actions.
• For the procedure for configuring event actions, see Assigning Actions to Signatures.
• For the procedure for obtaining statistics about the virtual sensor and Event Store, see Displaying Statistics.

Time Synchronization on IME and the Sensor

Symptom The IME displays No Data Available on the Events dashboard. A historical query does not return any events; however, events are coming in to the IME and they appear in the real-time event viewer.

Possible Cause The time is not synchronized between the sensor and the IME local server. The IME dashboards use a time relative to the IME local time. If these times are not synchronized, the query does not return any results. When you add a sensor to the IME, it checks for the time synchronization and warns you to correct it if is in wrong. The IME also displays a clock warning in Home > Devices > Device List to warn you about problems with synchronization.

Recommended Action Change the time settings on the sensor or the IME local server. In most cases, the time change is required for the sensor because it is configured with the incorrect or default time.

For More Information

• For more information on time and the sensor, see Time Sources and the Sensor.

• For the procedure for changing the time on the sensor, see Correcting Time on the Sensor.

Not Supported Error Message

Symptom The IME displays Not Supported in the device list table and in some gadgets, and no data is included.

Possible Cause Click Details to see an explanation for this message. The IME needs IPS 6.1 or later to obtain certain information. The IME still operates with event monitoring and reporting for IPS 5.0 and later and specific IOS IPS versions, but some functions, such as health information and integrated configuration, are not available.

Recommended Action Upgrade to IPS 6.1 or later.

Health and Status Information

To see the general health of the ASA 5500-X IPS SSP, use the show module ips details command.