Classification of Problem Areas

Sensor function problem areas can be classified as follows:

• Initial setup issues

• User management issues

• Software installation and upgrade issues

• Licensing issues

• Communication issues

• Issues with receiving events on monitoring device

• Blocking issues

• TCP reset issues

• Inline IPS issues

Initial Setup Issues

On a fresh installation, you must log in to the sensor using console or through a serial terminal using cisco/cisco as username/password. If you are prompted to change the password, that means that this is the first time you are accessing the sensor, because the password change option is given only during the first time you log in after the installation or re-image of the Sensor software. You must choose a strong password that is at least eight characters long, and is not a dictionary word.

When you log in to the sensor, first you should initialize the sensor with the setup command, which will allow you to enable the Command and Control port and assign the IP address and default gateway for the sensor, so that it can be managed remotely.

Work through the following steps to initialize the sensor:

Step 1.	Enter the setup command. The System Configuration Dialog, which is interactive, displays. The default settings are displayed as shown in Example 14-12. Example 14-12. Initializing the Sensor with the setup Command Sensor# setup -System Configuration Dialog- At any point you may enter a question mark '?' for help. Use ctrl-c to abort configuration dialog at any prompt. Default Settings are in square brackets '[]'. Current Configuration: networkParams ipAddress netmask defaultGateway hostname telnetOption accessList exit Initial Configuration Tasks timeParams summerTimeParams active-selection exit exit service webServer general ports exit exit
Step 2.	Press the spacebar to get to the following question: Continue with configuration dialog? [yes]: Press the spacebar to show one page at a time. Press Enter to show one line at a time.
Step 3.	Enter yes to continue.
Step 4.	Enter the hostname. The default hostname is sensor.
Step 5.	Enter the IP address, netmask, and the default gateway.
Step 6.	Enter the Telnet server status. You can disable or enable Telnet services. The default is disabled.
Step 7.	Enter the web server port. The web server port is the TCP port used by the web server (1 to 65535). The default is 443. Note that if you change the web server port, you must specify the port in the URL address of your browser when you connect to IPS Device Manager (IDM) in the format https://Sensor_IP:port. For example, if the sensor's IP address is 10.1.1.150, you can invoke the IDM with the https://10.1.1.150.
Step 8.	Configure the network access list as follows: When asked, "Modify current access list?", enter yes and then Press Enter as shown in Example 14-13 to delete or add entry to the ACL. Example 14-13. Partial Output of the setup Command to Add/Delete the ACL Modify current access list?[no]: yes Current access list entries: [1] 10.0.0.0/8 [2] 20.1.1.0/24 [3] 171.0.0.0/8 [4] 172.0.0.0/8 ! Choice 2 will delete 20.1.1.0/24 from the ACL Delete: 2 ! Hitting Return without specifying anything will skip the Delete option and take you ! to permit option Delete: ! Following line will allow 30.1.1.0/24 Permit: 30.1.1.0/24 ! Do not specify anything to skip the Permit option Permit: Modify system clock settings?[no]:yes Repeat these steps until you have entered all the networks you want to add to the access list.
Step 9.	Modify the system clock settings as follows: Enter yes to modify the system clock settings as shown in Example 14-13. Enter yes if you want to use NTP. Enter yes to modify summertime settings. Note that summertime is also known as Daylight Saving Time (DST). If your location does not use summertime, go to Step o. Enter recurring, date, or disable to specify how you want to configure summertime settings. The default is recurring. If you entered recurring, enter the month you want to start summertime settings. The default is apr. The valid entries are jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, and dec. Enter the week you want to start summertime settings. The default is first. The valid entries are first, second, third, fourth, fifth, and last. Enter the day you want to start summertime settings. The default is sun. The valid entries are sun, mon, tue, wed, thu, fri, and sat. Enter the time you want to start summertime settings. The default is 02:00:00. Note that the default recurring summertime parameters are correct for time zones in the United States. The default values specify a start time of 2 a.m. on the first Sunday in April, and a stop time of 2 a.m. on the fourth Sunday in October. The default summertime offset is 60 minutes. Enter the month you want summertime settings to end. The default is oct. The valid settings are jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, and dec. Enter the week you want the summertime settings to end. The default is last. The valid entries are first, second, third, fourth, fifth, and last. Enter the day you want the summertime settings to end. The default is sun. The valid entries are sun, mon, tue, wed, thu, fri, and sat. Enter the time you want summertime settings to end. The default is 02:00:00. Enter the DST zone. The zone name is a character string up to 128 characters long. Enter the summertime offset. The default is 60. Specify the summertime offset from UTC in minutes (negative numbers represent time zones west of the Prime Meridian). Enter yes to modify the system time zone. Enter the standard time zone name. The zone name is a character string up to 128 characters long. Enter the standard time offset. The default is 60. Your configuration appears with the following options: [0] Go to the command prompt without saving this config. [1] Return back to the setup without saving this config. [2] Save this configuration and exit setup.
Step 10.	Enter 2 to save the configuration.

User Management Issues

Based on different privilege levels, you can create users, delete them, change their privileges, or change their passwords. There are four levels of privileges available for users on Sensor: administrator, operator, service, and viewer. This section discusses how to create or modify user accounts. It also discusses details of the service account, a special account for password recovery and the troubleshooting that is necessary under special circumstances.

Creation and Modification of User Profiles

You can use the username command to add or delete users. Additionally, you can change the password or change the privilege levels of users with the username command. Example 14-14 shows how to create users, delete users, or change the user profiles.

Example 14-14. Creating and Deleting Users on the Sensor

! You need to login to Sensor with administrator user name. The following lines ! adding users with the administrator privilege sensor# configure terminal sensor(config)# username csids privilege administrator Enter Login Password: ***** Re-enter Login Password: ***** ! If you do not specify a privilege level for the user, the user is assigned the ! default viewer privilege. You can verify if the user is added by executing show ! users all after exiting from configuration mode ! If you want to remove the user just created, you can use the no form of the username ! command as shown in the following line. sensor(config)# no username csids ! If you want to change the password of the administrator, you can use the password ! command as shown in the following lines sensor# configure terminal sensor(config)# password Enter Old Login Password: ************ Enter New Login Password: ************ Re-enter New Login Password: ************ sensor(config)# ! If you want to change the password of another user, you must login to the Sensor ! with dministrator privilege, and change the password as follows. In the following ! example tester password is reset. sensor# configure terminal sensor(config)# password tester Enter New Login Password: ****** Re-enter New Login Password: ****** ! If you need to change the privileges of a user, you need to use the privilege ! command. ! Following lines shows how to change the user tester from viewer to administrator. sensor# show users all     CLI ID   User         Privilege *   7309     cisco        administrator              service      service              tester      viewer sensor# configure terminal sensor14(config)# privilege user tester administrator Warning: The privilege change does not apply to current CLI sessions. It will be  applied to subsequent logins. sensor(config)# exit sensor# show users all     CLI ID   User         Privilege *   7309     cisco        administrator              service      service              tester      administrator sensor# ! If you want to assign service privileges to an existing user, you must first remove ! the user and add it with service privileges. You cannot use the privilege command ! to accomplish this. sensor# 

Creating the Service Account

A service account is a special user account that is used under rare circumstances to recover user passwords or troubleshoot issues such as a sensor crash. In Sensor, it is possible to assign the same privilege to more than one user, with the exception of the service privilege. You can have only one service account on the sensor. To create the service account, you need to follow the same procedure as explained in Example 14-14. You need to be sure that you are adding a user with a service privilege level. It is important to note that if you want to assign service privileges to an existing user, you must first remove the user and add it with service privileges. You cannot use the privilege command to accomplish this.

After the creation of the service account, login to Sensor with this account and you will see the messages as shown in Example 14-15.

Example 14-15. Sample Run of Service Account Login

login: service Password: Last login: Fri Nov 5 16:49:11 from 171.69.89.219 ***NOTICE*** 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 If you require further assistance please contact us by sending email to [e-mail]. Press Enter to continue ************************ WARNING ************************ UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. This account is intended to be used for support and troubleshooting purposes only. Unauthorized modifications are not supported and will require this device to be re-imaged to guarantee proper operation. ********************************************************* bash-2.05a$ 

Caution

It's extremely important that you do not make any changes to the configuration of the sensor using the service account, except under the direction of Cisco Support. Modification of the configuration must be done at your own risk and is not supported by Cisco Systems, Inc.

Software Installation and Upgrade Issues

This section focuses primarily on the upgrade issues of the IDS 42xx series Sensor Appliances. Module software installation and upgrade issues are discussed in their respective chapters. For example, installation and upgrade issues for IDSM-2 are thoroughly discussed in Chapter 15, "Troubleshooting IDSM-2 Blades on Switch." Installing and upgrading to IPS version 5.0 is used as an example throughout this section. This section discusses the following items in details in:

• Obtaining sensor software

• IPS software image naming conventions

• Installing or re-imaging the ips appliances system image

  - Using CD-ROM

  - Using Trivial File Transfer Protocol (TFTP) server

• Disaster recovery plan

  - Recovering the application partition

  - Upgrading the recovery partition image

• Upgrading major/minor software or service pack/signature update

• Upgrading to IPS 5.0

Obtaining Sensor Software

There are two main ways to procure different types of IDS/IPS Sensor software: using a CD or downloading from the Cisco.com web site. System image is the only software image available on the CD (you will get the base software of IDS/IPS Sensor when you purchase the Sensor). You can order the CD from the following location: www.cisco.com/upgrade. However, all types of IDS/IPS Sensor software images (for example System image, service packs, signature upgrade, and so on) are downloadable from the Cisco.com web site. Before you are presented with the software download location, it is important that you take care of the following two issues:

• Applying for Cryptographic Access To download IDS/IPS Sensor software, you must have a Cisco.com user account with cryptographic access. To apply for cryptographic access with your Cisco.com (this account needs to have a smartnet contract) account, go to the following site and select the product for which you want cryptographic access and submit the request:

  http://www.cisco.com/pcgi-bin/Software/Crypto/crypto_main.pl

  If you do not have a Cisco.com user account, apply for it at the following location:

  http://tools.cisco.com/RPF/register/register.do

• Active Update Notification Subscribe to the mailing list of "Active Update Notification" for information about the latest update software from the following location:

  http://www.cisco.com/cgi-bin/front.x/ipsalerts/ipsalertsHome.pl

  You need to fill out a form that can be found at the "Active Update Notifications <http://www.cisco.com/offer/newsletter/123668_4/>" link under "Active Updates" on the right side of the page of the preceding link.

Now that you are ready with a Cisco.com user account with cryptographic capabilities, you can download all types of IDS/IPS Sensor software from the following location:

http://www.cisco.com/kobayashi/sw-center/ciscosecure/ids/crypto/

IPS Software Image Naming Conventions

If you have visited the link for IDS/IPS Sensor Software provided in the preceding section, you might already have realized how many different types of IDS/IPS Sensor software you need to deal with. Hence, having a clear understanding of the IDS/IPS software naming convention is extremely important. The naming convention of the IDS/IPS Sensor software may be categorized as follows:

• Platform-dependent image

• Platform-independent image

A more thorough discussion on naming conventions for both types of images is as follows.

Platform-Dependent Image

Following is a list of platform-dependent images available on different sensors:

• System image file (For all platforms) The system image includes the combined recovery and application image used to re-image an entire sensor.

• Recovery partition image file A recovery partition image file is a partition on the sensor that contains a full IPS application image to be used for recovery.

• Maintenance partition image file (IDSM-2 only) A maintenance partition image file is a full IPS image that can be used to re-image the maintenance partition of the IDSM-2.

• Recovery and Upgrade CD (All Sensors that have CD-ROM drives) This is a CD image for recovery or upgrade of an appliance that has a CD-ROM drive.

• Boot Loader (For NM-CIDS only) This is used for re-imaging NM-CIDS.

• Helper image (For NM-CIDS only) This is used to re-image a NM-CIDS hard disk drive.

Table 14-3 describes the platform-dependent releases.

Table 14-3. Platform-Dependent Releases

Release	Target Frequency	Identifier	Supported Platform	Example File Name
System image	Annually	sys	All	IPS-4255-K9-sys-1.1-a-5.0-2.img
Recovery partition image file	Annually	r	All Appliances	IPS-K9-r-1.1-a-5.0-2.pkg
Maintenance partition image	Annually	mp	IDSM-2 only	c6svc-mp.2-1-2.bin.gz
Recovery and upgrade CD	Annually or as needed	cd	All appliances with a CD-ROM drive	N/A
Boot loader	As needed	boot	NM-CIDS	servicesengine-boot-1.0-17-1_dev.bin
Helper image	As needed	helper	NM-CIDS	NM-CIDS-K9-helper-1.0-1.bin

Platform-Independent Image

Some platform-independent Sensor update files are base files, some are cumulative, and yet others are incremental. Knowing which Sensor software type is base, cumulative, or incremental, and their dependencies on each other, is extremely important. Following is an attempt to explain this level of detail:

• Major version A major version upgrade contains new functionality or an architectural change in the product. For example, the IPS 5.0 base version release includes everything since the previous major release (the minor version features, service pack fixes, and signature updates) plus any new changes. Major upgrade 5.0(1) requires 4.1. The 5.0(1) major upgrade is used only to upgrade 4.1 sensors to 5.0(1). If you are reinstalling 5.0(1) on a sensor that already has 5.0(1) installed, use the system image or recovery procedures rather than the major upgrade.

• Minor version A minor version upgrade is incremental to the major version. Minor version upgrades are also base versions for service packs. The first minor version upgrade for 5.0 is 5.1(1). Minor version upgrades are released for minor enhancements to the product. Minor version upgrades contain all previous minor features, service pack fixes, and signature updates since the last major version, and the new minor features being released. The minor upgrade requires the major version.

• Service pack Service packs are cumulative following a base version release (minor or major). Service packs are used for the release of defect fixes with no new enhancements. Service packs contain all the service pack fixes and signature updates since the last base version (minor or major) and the new defect fixes being released.

• Signature Update Signature updates are cumulative and increment by one with each new release (for example, S45, S46, S47). Signature updates include every signature since the initial signature release (S1) in addition to the new signatures being released.

• Patch release Patch releases are for interim fixes.

• Recovery Package As of the writing of this book, r 1.1 is the latest recovery image. This can be revised to r 1.2 if it is necessary to release a new recovery package that contains the same underlying application image. If there are defect fixes for the installer, for example, the underlying application version may still be 5.0(1), but the recovery partition image will be r 1.2.

Except for the Signature update file, the rest of the other IDS Sensor software update uses the format: IPS-update_type-x.y-z-.pkg. Following is the explanation of the image version format:

• update_type update_type can be maj for Major version, min is for Minor version, and so on

• x represents Major version

• y represents Minor version

• z represents Service Pack level

The signature file follows the following format to name its file: IPS-sig-Sx-minreq-5.0-1.pkg. Here sig is the update type, Sx is the signature level, and minreq defines the minimum software requirement before applying this signature. In this case, the minimum requirement is version 5.0-1. Table 14-4 summarizes different platform-independent software updates.

Table 14-4. Platform-Independent Release Examples

Release	Target Frequency	Identifier	Example File Name
Signature update	Weekly	sig	IPS-sig-S70-minreq-5.0-1.pkg
Service pack	Semi-annually or as needed	sp	IPS-K9-sp-5.0-2.pkg
Minor version	Annually	min	IPS-K9-min-5.1-1.pkg
Major version	Annually	maj	IPS-K9-maj-5.0-1.pkg
Patch release	As needed	patch	IPS-K9-patch-5.0-1pl.pkg
Recovery package	Annually or as needed	r	IPS-K9-r-1.1-a-5.0-1.pkg

Even though you become comfortable with the naming conventions and understand how to select and apply the software on the Sensor, it is strongly recommended to read the Readme file of the corresponding Sensor software.

Installing or Re-imaging the IPS Appliances System Image

As mentioned before, the system image is used to recover the whole sensor (both Maintenance and Application partitions). If you have a sensor with both application and maintenance partitions corrupted, then you need to re-image the sensor with the system image. Starting from version 5.0, the system image is the same for the appliance and the blades on the switch, router, and ASA. This section explains how to perform the installation or the upgrade of the Sensor Appliances. Depending on the model, you need to upgrade the sensor using either of the following two methods:

• Using a CD-ROM

• Using TFTP Server

Details on re-imaging using both methods follow.

Using a CD-ROM

You can use the recovery/upgrade CD on appliances that have a CD-ROM, such as the IDS-4210, IDS-4235, and IDS-4250. The recovery/upgrade CD re-images both the recovery and application partitions. Work through the following steps to re-image the Sensor Appliance which has the CD-ROM drive:

Step 1.	Insert the recovery/upgrade CD into the CD-ROM drive.
Step 2.	Power off the IDS appliance and then power it back on. The boot menu appears, which lists important notices and boot options.
Step 3.	Type k if you are installing from a keyboard, or type s if you are installing from a serial connection. A blue screen is displayed for several minutes without any status messages while the files are being copied from the CD to your appliance.
Step 4.	When you are finished with the installation, log in to the appliance by using a serial connection or with a monitor and keyboard. The default username and password is cisco/cisco.
Step 5.	When you are prompted, change the password. The passwords must be at least eight characters long and be strong, that is, they should not be dictionary words.
Step 6.	When you are in the sensor prompt, type the setup command to initialize the appliance.

This procedure almost always works, but, if for some reason the sensor does not boot from the upgrade CD-ROM, use the steps that follow to troubleshoot this issue:

Step 1.	Connect the sensor either with a keyboard and monitor, or through the serial port using a terminal server or laplink cable and PC. If connected through the serial port, console redirection must be enabled in the BIOS to change BIOS settings.
Step 2.	Reboot the sensor.
Step 3.	Use the arrow keys to select the Boot menu.
Step 4.	Navigate to the Boot Device Priority option, again using the arrow keys, and press Enter.
Step 5.	Change the boot order by selecting a drive using the arrow keys, and pressing + or to move the drive up or down in the list respectively. Boot order should be: [Removable Devices], [ATAPI CD-ROM Drive], [Hard Drive] ...
Step 6.	Click ESC to exit the Boot Device Priority submenu.
Step 7.	Use the arrow keys to navigate to the Exit menu.
Step 8.	Select Exit Saving Changes and click Enter.
Step 9.	Select Yes in the Setup Confirmation window, and click Enter.
Step 10.	The system will reboot.

Using TFTP Server

Some of the IPS Appliances, IDS-4215, IPS-4240, or IPS-4255 System Image, must be installed/re-imaged by using the ROMMON. This involves a TFTP server on which the image file is downloaded and then transferred from that to the sensor's compact flash. To install or re-image the sensor using the TFTP server, follow these steps:

Step 1.

Download the IPS system image file (for example IPS-4240-K9-sys-1.1-a-5.0-1.img) to the tftp root directory of a TFTP server from your IPS from the following location:

http://www.cisco.com/cgi-bin/tablebuild.pl/ips5-system

Step 2.

IDS-4215 must be running BIOS version 5.1.7 or later and ROMMON version 1.4 or later to install system image 5.0-1 or 5.0-2. If IDS-4215 does not have the correct BIOS and ROMMON versions, you must upgrade the BIOS and ROMMON before re-imaging (see Example 14-16 for details on upgrading BIOS and ROMMON). This problem is specific only to IDS-4215, not IPS-4240 and IPS-4255

Step 3.

Boot IPS Sensor.

Step 4.

Enter CTRL-R (for IDS-4215) or Press Break or Esc (for IPS-4240, and IPS-4255) within five seconds at the following prompt while the system is booting:

Evaluating Run Options... 

Step 5.

Check the current network settings with the following command:

rommon> set 

Step 6.

Use Table 14-5 to assign different network parameters. Note that not all values listed in Table 14-5 are required to establish network connectivity. The address, server, gateway, and image values are required.

Table 14-5. Commands That Can Be Entered in ROMMON of Sensor

Commands in ROMMON	Meaning of the commands
ADDRESS=IP_address	AddressLocal IP address of the sensor
CONFIG=name	ConfigApplication configuration file path/name
GATEWAY=IP_address	GatewayGateway IP address used by the sensor
IMAGE=name	ImageSystem image file path/name
PORT=name	PortEthernet interface port used for sensor management
SERVER=IP_address	ServerTFTP server IP address where the application image is stored
VLAN=ID_number	VLANVLAN ID number (leave as 0)

Step 7.

If needed, change the interface used for the TFTP download with the following command:

rommon> PORT=interface_name 

The default interface used for TFTP downloads is Management0/0, which corresponds to the MGMT interface of IPS-4240. For IDS-4215, Ports 0 (monitoring port) and 1 (command and control port) are labeled on the back of the chassis. If you want to use default setting, you do not need to use the port command to set up the port.

Step 8.

Assign an IP address for the local port on IPS. This IP address should be the same IP address that you used for the Command and Control interface under the normal mode of operations.

rommon> ADDRESS=ip_address 

Step 9.

Assign the TFTP server IP address with the following command:

rommon> SERVER=ip_address 

Step 10.

Assign the gateway IP address if the TFTP server is more than one hop away with the following command:

rommon> GATEWAY=ip_address 

Step 11.

Verify that you have access to the TFTP server by pinging it from your local Ethernet port with one of the following commands:

rommon> ping server_ip_address rommon> ping server 

Step 12.

Define the path and filename on the TFTP file server from which you are downloading the image using the following command:

rommon> IMAGE=path/file_name 

An example on a UNIX platform is as follows:

rommon> IMAGE=/system_images/IPS-4240-K9-sys-1.1-a-5.0-2.img 

Note that the path is relative to the UNIX TFTP server's default tftpboot directory. Images located in the default tftpboot directory do not have any directory names or slashes in the IMAGE specification.

An example on the Windows platform is as follows:

rommon> IMAGE=C:\system_images\IPS-4240-K9-sys-1.1-a-5.0-2.img 

Step 13.

Type set and press Enter to verify the network settings.

Step 14.

You can use the sync command to store these settings in NVRAM so they are maintained across boots. Otherwise, you must type this information each time you want to boot an image from ROMMON.

Step 15.

Download and install the system image with the following command:

rommon> tftp 

Caution

To avoid corrupting the system image, do not remove power from IPS-4240 while the system image is being installed.

Example 14-16. Upgrading the IDS-4215 BIOS and ROMMON

! Download the BIOS ROMMON upgrade utility (IDS-4215-bios-5.1.7-rom-1.4.bin) to the ! TFTP root directory of a TFTP server that is accessible from IDS-4215 from location: ! http://www.cisco.com/cgi-bin/tablebuild.pl/ips5-firmware ! Boot IDS-4215. While rebooting, IDS-4215 runs the BIOS POST. After the completion ! of POST, the console displays the message: Evaluating Run Options ...for about ! 5 seconds. Press Ctrl-R while this message is displayed to display the ROMMON menu. ! Specify an IP address for the local port on IDS-4215 rommon> address ip_address ! Specify the TFTP server IP address rommon> server ip_address ! Specify the gateway IP address rommon> gateway ip_address ! Verify that you have access to the TFTP server by pinging it from the local Ethernet ! port rommon> ping server_ip_address rommon> ping server ! Specify the filename on the TFTP file server from which you are downloading the ! image rommon> file filename ! For example rommon> file IDS-4215-bios-5.1.7-rom-1.4.bin ! Download and run the update utility rommon> tftp ! Type y at the upgrade prompt and the update is executed. IDS-4215 reboots when the update is complete. ! Do not remove power to IDS-4215 during the update process, otherwise the upgrade ! can get corrupted. 

If you run into a problem with TFTP upgrade, check the following items to resolve the issue:

• If the TFTP server is in a different network than the sensor, make sure TFTP traffic is not blocked by a firewall or any network device with an Access Control List (ACL).

• Be sure to tie the IP address to the proper interface of the sensor, and be sure the interface is connected to the network. If you encounter a layer II issue, check the cable and check the port on the switch to be sure that it's up.

• Note that the image name is case-sensitive. So pay extra attention when defining the image name properly.

• Choose the proper system image, as they are named with specific platform. For example IPS-4215-K9-sys-1.1-a-5.0-2.img is for IPS-4215 and should not be used to upgrade IPS-4255.

• Some TFTP servers limit the maximum file size that can be transferred to approximately 32 MB. Therefore, it is recommended to use the following tftp server:

  - For Windows, use Tftpd32 version 2.0, from the following location: http://tftpd32.jounin.net/

  - For UNIX, use Tftp-hpa series, from the following location: http://www.kernel.org/pub/software/network/tftp/

• Turn on logging on the TFTP server and be sure you see the request coming from Sensor.

• Make sure that the TFTP is set to Send and Receive both permissions. Additionally, be sure the TFTP server root directory allows Read permission.

Disaster Recovery Plan

For high availability, it's extremely important to have a Disaster Recovery Plan (DRP) for your sensor. You must ensure that if the Application image is corrupted, you can recover it easily from the Recovery Partition. Also, be sure that you have the latest version installed on the Recovery partition. Following are the important action items that are necessary for the seamless operation of IPS Sensor.

• Recovering the application partition

• Upgrading the recovery partition image

• Recovering a lost password

• Recovering a working configuration

The last two bullet items are discussed thoroughly in the section entitled "Preventive Maintenance" under the "Best Practices" section. This section explains the how to recover an application partition from the recovery partition, and how to upgrade the recovery partition to the latest version so that the sensor can be upgraded to the latest version if the application partition fails.

Recovering the Application Partition

If the application partition, which is used under normal operation by the sensor, becomes corrupted, you can use either the system image to re-image the sensor (as described in the preceding section), or recover it from the recovery partition. If the recovery partition also is corrupted, then re-imaging the sensor with the System Image is the only option. Otherwise, the best approach is to use the recovery partition to recover the sensor. This is extremely useful if the sensor is installed in a remote location and you do not have physical access to the sensor. This is because the IP address, netmask, access lists, time zone, and offset are saved and applied to the re-imaged application partition. So, after the recovery process, you can remotely SSH to the sensor with the default username and password (cisco/cisco) and initialize the sensor again with the setup command. You cannot use Telnet until you initialize the sensor because Telnet is disabled by default.

Work through the following steps to recover the sensor from the recovery partition:

Step 1.	Log in to the CLI of the sensor via SSH or Telnet using an account with administrator privileges.
Step 2.	Enter configuration mode with the following command: sensor# configure terminal
Step 3.	Recover the application partition image with the following command: sensor(config)# recover application-partition Warning: Executing this command will stop all applications and re-image the node to version 5.0(0.27)S91(0.27). All configuration changes except for network settings will be reset to default. Continue with recovery? []:
Step 4.	Type yes to continue. Shutdown begins immediately after you execute the recover command. Shutdown can take a while, and you will still have access to the CLI, but access will be terminated without warning.
Step 5.	Once the application partition is re-imaged using the image stored on the recovery partition, log back in to the sensor using SSH and execute the setup command to initialize the sensor.

Note

If for some reason, you cannot access the CLI to execute the recover application-partition command, you can reboot the sensor and select the option from the boot menu during the bootup process. This lets you boot to the recovery partition and re-image the application partition. Executing the recovery command in this way requires console or keyboard and monitor access to the sensor, which is possible on the appliances and NM-CIDS, but not on the IDSM-2 or ASA-SSM.

As you can see, Application Partition, using this procedure, uses the image stored in Recovery Partition. So, to install the most up-to-date version of the image on the application partition using Maintenance Partition, it is strongly recommended that you upgrade your recovery partition to the most recent version, as soon as it becomes available for download from Cisco.com. This is covered in the next section on how to upgrade the recovery partition.

Upgrading the Recovery Partition Image

As mentioned before, it is strongly recommended to upgrade the image on the recovery partition with the latest version so that it is ready if you need to recover the application partition on your appliance. It is important to understand that recovery partition images are generated for major and minor software releases and only in rare situations for service packs or signature updates.

Work through the following steps to perform the upgrade on the recovery partition from the application partition:

Step 1.	Log in to Sensor CLI using SSH or Telnet with administrator privilege, execute show version, and be sure that you are running IPS version 5.0(1) or later.
Step 2.	Download the recovery partition image file (IPS-K9-r-1.1-a-5.0-2.pkg) to an FTP, SCP, HTTP, or HTTPS server that is accessible from your sensor from the following location: http://www.cisco.com/cgi-bin/tablebuild.pl/ips5-system
Step 3.	Enter configuration mode with the following command: sensor# configure terminal
Step 4.	Initiate the upgrade process with the following command: sensor(config)# upgrade scp://user@server_ipaddress//upgrade_path/ IPS-K9-r-1.1-a-5.0-2.pkg To use FTP, use the following command: sensor(config)# upgrade ftp://user@server_ipaddress//upgrade_path/ IPS-K9-r-1.1-a-5.0-2.pkg
Step 5.	Type the server password when prompted.
Step 6.	The upgrade process begins.

Note

Always read the Readme file which is located at the same place on Cisco.com as the actual image. The preceding procedure is taken from the Readme file. If there are any changes in upgrade procedure, the most accurate and up-to-date information can be found in the Readme file.

Upgrading Major/Minor Software or Service Pack/Signature Update

The upgrade process for the Major/Minor Software or Service Pack/Signature is the same for all platforms. There are several ways you can upgrade the sensor as follows:

• Automatic upgrade using the CLI of the sensor

• Manual upgrade using CLI of the sensor

• Upgrade using IDM or IPS MC (See Chapter 18 for more details.)

This section explains how to perform the Manual and Automatic upgrade using CLI on the sensor.

Automatic Upgrade Using the CLI of the Sensor

The auto update feature automatically upgrades the sensor based on a pre-configured time. You can configure the sensor to look for new upgrade files in your upgrade directory of FTP or SCP server automatically. Hence, you must download the software upgrade from Cisco.com and copy it to the upgrade directory of FTP or SCP server before the sensor can poll for automatic upgrades.

Work through the following steps to schedule automatic upgrades on the sensor using CLI:

Step 1.	Log in to the CLI of Sensor through SSH or Telnet using an account with administrator privileges.
Step 2.	Enable the auto-upgrade feature on the sensor with the following command: sensor# configure terminal sensor(config)# service host sensor(config-hos)# auto-upgrade-option enabled
Step 3.	Specify the scheduling: For calendar scheduling, which starts upgrades at specific times on specific day, use the following commands: sensor(config-hos-ena)# schedule-option calendar-schedule sensor(config-hos-ena-cal# days-of-week sunday sensor(config-hos-ena-cal# times-of-day 12:00:00 For periodic scheduling, which starts upgrades at specific periodic intervals, use the following commands: sensor(config-hos-ena)# schedule-option periodic-schedule sensor(config-hos-ena-per)# interval 24 sensor(config-hos-ena-per)# start-time 13:00:00
Step 4.	Specify the IP address of the file server (this can be an FTP or SCP server) with the following commands: sensor(config-hos-ena-per)# exit sensor(config-hos-ena)# ip-address 10.1.1.100
Step 5.	Specify the directory where the upgrade files are located on the file server (FTP or SCP server) with the following command: sensor(config-hos-ena)# directory /download/update
Step 6.	Specify the username for authentication on the file server (FTP/SCP): sensor(config-hos-ena)# user-name cisco
Step 7.	Specify the password of the user with the following command: sensor(config-hos-ena)# password Enter password[]: ****** Re-enter password: ******
Step 8.	Specify the file server protocol: To use FTP server, use the following command: sensor(config-hos-ena)# file-copy-protocol ftp To use SCP, use the following command: sensor(config-hos-ena)# file-copy-protocol scp To add the host when SCP is used, use the following command to add the SCP server to the trusted-host list: sensor(config-hos-ena)# exit sensor(config-hos)# exit Apply Changes:?[yes]: sensor(config)# ssh host-key 10.1.1.100 MD5 fingerprint is F3:10:3E:BA:1E:AB:88:F8:F5:56:D3:A6:63:42:1C:11 Bubble Babble is xucis-hehon-kizog-nedeg-zunom-kolyn-syzec-zasyk- symuf-rykum-sexyx Would you like to add this to the known hosts table for this host?[yes] Sensor(config)#

When the sensor is underused, it is strongly recommended to schedule the timing to be automatic, such as at midnight or during the weekend. Other than that, the troubleshooting is centered on the communication issues between the sensor and the FTP or SCP server, which is discussed thoroughly in the next section, on manual upgrade.

Manual Upgrade With the CLI of the Sensor

You must have the IPS subscription license to update your sensor (see the "Licensing Issues" section for more details). The upgrade procedure is the same for Major/Minor version, or Service Pack or signature upgrade. The procedure that follows explains how to upgrade a signature (IPS-sig-S169-minreq-5.0-1.pkg) update. The same procedure can be used to upgrade the sensor for Major/Minor version and Service Pack:

Step 1.	Log in to the Sensor CLI using Administrator account.
Step 2.	Back up a working copy of your sensor as explained in the "Best Practices" section of this chapter.
Step 3.	Execute show version on the sensor and get the current version Sensor is running.
Step 4.	Go to the following site to get the Readme file of the version of Signature upgrade file: http://www.cisco.com/cgi-bin/tablebuild.pl/ips5-sigup Read through the Readme file and determine the minimum version requirement. Another way to verify the version requirement is to look at the name of the signature file. For this example, use the IPS-sig-S169-minreq-5.0-1.pkg file. As the name implies, the minimum requirement for upgrading this signature is that you are running 5.0(1) or 5.0(2).
Step 5.	Download the binary file IPS-sig-S169-minreq-5.0-1.pkg to an ftp, scp, http, or https server on your network from: http://www.cisco.com/cgi-bin/tablebuild.pl/ips5-sigup You must preserve the original file name.
Step 6.	Type the following command to enter Configuration mode: Sensor#configure terminal
Step 7.	Initiate the upgrade process by executing the following command: upgrade [URL]/IPS-sig-S169-minreq-5.0-1.pkg Here, the [URL] is the uniform resource locator pointing to where the signature update package is located. For example, to retrieve the update via FTP, type the following: Sensor(config)#upgrade ftp://<username>@<ip-address>//<directory>/IPS- sig-S169-minreq-5.0-1.pkg The available transport methods are: SCP, FTP, HTTP, or HTTPS.
Step 8.	Enter the appropriate password when prompted.
Step 9.	To complete the upgrade, type yes when prompted.

To uninstall the version S169 signature update on a 5.0(1) or 5.0(2) sensor and return the sensor to its previous state, follow these steps:

Step 1.	Log in to the CLI using an account with administrator privileges.
Step 2.	Type the following command to enter configuration mode: Sensor# configure terminal
Step 3.	Type the following command to start the downgrade: Sensor(config)# downgrade

Sometimes, manual upgrade using Sensor CLI does not work due to FTP transfer problems. To work around that problem, transfer the file to the sensor manually, and then upgrade from the sensor itself. You might have to do this under some circumstances. Work through the following steps to accomplish this task:

Step 1.	Log in using the "service" account (and do not "su" to root); the prompt will look like: bash-2.05a$
Step 2.	Connect to the FTP server with the following command: bash-2.05a$ ftp ftp_server_address
Step 3.	Set up the ftp client to use a "binary" mode to get the file using the following command: ftp> bin
Step 4.	Be sure that the update file is in the FTP server using the following command: ftp> ls
Step 5.	Retrieve the file (you may Copy and Paste the filename from the previous output from ls command): ftp> get upgrade_file
Step 6.	Close the FTP connection and quit from FTP client with the following commands: ftp> close ftp> quit
Step 7.	Be sure the file is transferred to the sensor with the following command: bash-2.05a$ ls You should see the upgrade file that you downloaded from the ftp server.
Step 8.	Log out of the service account: bash-2.05a$ exit
Step 9.	Log in to Sensor using administrator account.
Step 10.	Enter configuration mode with the following command: sensor# configure terminal
Step 11.	Download the key from the sensor itself by specifying its own IP address with the following command: sensor(config)# ssh host-key [sensor_ip_address] Type yes to accept the key
Step 12.	Apply the upgrade with the following command: sensor(config)# upgrade scp:// User: service_account_user_name Server's IP Address: sensor_ip_address Port[22]: File name: upgrade_file Password: ********** Warning: Executing this command will apply a signature update to the application partition. Continue with upgrade? : yes sensor(config)#

If you run into a problem with the manual upgrade, go through the following list to troubleshoot the issue:

• Check the connectivity problem Be sure your sensor can ftp or ssh or Telnet on port 80/443 from the sensor to the FTP, SCP server, or HTT/HTTPS server. This can be done from the sensor after logging into the service account. If you have connectivity problems, be sure that you do not have a firewall between the sensor and the FTP or SCP or HTTP/HTTPS server that might be blocking the necessary port. If SCP is used, be sure to add the SCP server in the trusted host of the sensor with the ssh host-key command.

• Be careful with file naming When downloading the update file from the Cisco.com web site, be sure that the file name is not changed. Some browsers might add an extra extension to the file, so be careful about that. The file is case-sensitive, so be sure to compare the name of the file after you download from Cisco.com.

• Check that the file path is correct If the correct path of the file is not specified, the sensor will be unable to pull the file. Use the following syntax for proper directory path:

  - For FTP server, use the following syntax:

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

  - For SCP, use the following syntax:

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

  - For http, use the following syntax:

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

  - For https, use the following syntax:

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

• Settings for FTP server If FTP server is used, try to avoid using an anonymous user for upgrades. Also, remove any extra banners and allow the passive FTP.

• Avoid busy hours for upgrade Try to avoid upgrading during the busy hours when Sensor processes a lot of traffic. Otherwise, Sensor might become unresponsive. If you have to perform the upgrade, then be sure to shut down the sensing interface or unplug the cable from the sensing interface. When the upgrade is completed, connect the cable back on the sensing interface or bring the sensing interface up.

• Do not reboot the sensor Depending on the traffic load or amount of configuration, Sensor might appear unresponsive for a long time during the upgrade or downgrade process. Be patient, and do not reboot the sensor; otherwise, Sensor might become corrupted, and re-imaging will be only option left.

Upgrading to IPS 5.0

There are two ways to upgrade your sensor to IPS 5.0:

• Using a system image

• Using a major software update

More details on these methods follow.

Using System Image

If you use the system image to re-image the sensor completely, then you will lose all the configurations. There is no way that you can use the old configuration. There is no external tool that converts the IDS 4.x version configuration to the IPS 5.x version configuration. The only advantage with re-imaging the sensor is that you do not need to upgrade your sensor to a specific version before upgrading to 5.x. As of the writing of this book, the latest version of system file for IPS is 5.0(2), which can be downloaded from the following location:

http://www.cisco.com/cgi-bin/tablebuild.pl/ips5-system

If you have a CD-ROM on the sensor and if your contract entitles you to do so, you can order the CD from the following location:

www.cisco.com/upgrade

The procedure for re-imaging the system image of the sensor is explained in the section entitled "Installing or Re-imaging the IPS Appliances System Image."

Using a Major Software Update

To maintain the configuration of the sensor (this is the preferred method), use the major software update to upgrade your sensor to IPS 5.x. All the older versions of IDS need to be upgraded to 4.1 with the latest signature upgrade; otherwise, the major version upgrade will fail.

As of the writing of this book, the major upgrade file required to upgrade the version to IPS 5.0 is IPS-K9-maj-5.0-1-S149.rpm.pkg (version 5.0.1), which can be downloaded from the following location:

http://www.cisco.com/cgi-bin/tablebuild.pl/ips5

The procedure for the upgrade can be found in the Readme file. Refer to "Upgrading Major/ Minor Software or Service pack/Signature Update" for additional details.

For a seamless upgrade to IPS version 5.0, keep the following important points in mind:

• Back up the running configuration and the show version output so you may downgrade if required and still have a working configuration.

• You cannot use the downgrade command to downgrade from 5.0(1) to 4.x; rather you need to re-image the sensor with a system file.

• If you have 4.0 installed on your sensor, you must upgrade to 4.1, then upgrade to 5.0.

• Upgrading from 4.1 to 5.0 converts the sensor configuration to IPS 5.0 format. The upgrade might stop if it comes across a value that it cannot translate. If this occurs, the resulting error message provides enough information to adjust the parameter to an acceptable value. After editing the configuration, try the upgrade again.

• In 4.x, custom signature IDs start at 20000. Any custom signatures that you have created in 4.x are converted to the 5.0 custom signature ranges, which begin at 60000.

• In 4.x, there is a parameter that lets you enable and disable signatures. In 5.0, there is a similar parameter, but there is also a parameter that lets you retire and unretire signatures. When you upgrade to 5.0, some signatures will be marked as enabled; however, they might also have been retired in 5.0, and therefore the enabled setting would be ignored. You must manually unretire the signature to ensure that it is enabled.

• In 5.0, you receive messages indicating that you need to install a license. The sensor functions properly without a license, but you need a license to install signature updates. The following section describes the procedure.

Licensing Issues

The IPS software requires you to have a subscription license to process signature updates. This is a new feature on version IPS 5.0. Earlier versions do not require this license. On IPS 5.0, without the license, the sensor will function correctly; however, you will not be able to upgrade a new signature without a license. Sections that follow explain how to procure the license key from Cisco.com and install it on the sensor.

How Do I Know if I have A Valid License?

You can view the status of the IPS subscription license key in two ways:

• Using CLI

• Using IDM

Using CLI

When you log in to Sensor using SSH or Telnet, the banner displays the licensing information. For example, if your sensor is not licensed, you will see the following message:

***LICENSE NOTICE*** There is no license key installed on the system. Please go to http://www.cisco.com/go/license to obtain a new license or install a   license. 

You can also find out the license information by using the show version command as shown in Example 14-1. In the show version output, the sensor will display the following line if your sensor is not licensed:

No license present 

Using IDM

Just as with CLI, when you log in to IDM, a dialog box informs you of your license status. It will tell you whether you have a trial, invalid, or expired license key. With no license key, an invalid license key, or an expired license key, you can continue to use IDM and the sensor, but you cannot download signature updates.

You can also find the IPS license information on IDM by clicking Configuration > Licensing.

How to Procure The License Key From Cisco.com

You can procure the license in two ways: via e-mail or by using IDM. When you use IDM, you can make the license request directly to the Cisco.com licensing server (IDM has this information built in) to pull the license key and install it at the same time. For that, you must have connectivity from the sensor to the Internet. However, to get the license key separately and then install it either via CLI or IDM, go to the following site:

http://www.cisco.com/go/license

You must know your IPS device serial number to obtain a license key. You can find the IPS device serial number IDM by clicking Configuration > Licensing or obtain it through the CLI by using the show version command.

Follow the steps to get the license key via e-mail:

Step 1.	Go to www.cisco.com/go/license.
Step 2.	Fill in the required fields. The most important piece of information is the correct IPS device serial number because the license key only functions on the device with that number.
Step 3.	Your Cisco IPS Signature Subscription Service license key will be sent by e-mail to the e-mail address you specified. If you want to license the sensor using IDM, save the license file to a hard drive or to a network drive that is accessible by the client that is running the Device Manager.
Step 4.	To license the sensor using CLI, transfer this license key to the sensor, a process which is discussed in the next section.

Note

To obtain a license, you must have a Cisco Service for IPS contract. Contact your reseller, Cisco service or product sales to purchase a contract. You can install the first few signature updates for 5.0 without a license. This gives you time to get your sensor licensed. If you are unable to get your sensor licensed because of confusion with your contract, you can obtain a 60-day trial license that supports signature updates that require licensing.

Licensing the Sensor

There are two ways to license the sensor:

• Using IDM

• Using CLI

Using IDM

To install the sensor license, follow these steps:

Step 1.	Click Configuration > Licensing. The Licensing panel displays.
Step 2.	Choose the method for delivering the license. Select Cisco Connection Online to obtain the license from Cisco.com. The Device Manager contacts the license server on Cisco.com and sends the server the serial number to obtain the license key. This is the default method.
Step 3.	If you have already received the license via e-mail, check the License file box, and click on Browse Local to upload the file from your local hard disk of your PC.
Step 4.	Click Update License.
Step 5.	The Licensing dialog box appears. Click Yes to continue.
Step 6.	Click OK.

Using CLI

Once you get the license via e-mail as explained in the section entitled "How to Procure The License Key From Cisco.com," licensing Sensor requires you to transfer the license key to Sensor. Work through the following steps to license the sensor with SCP using CLI:

Step 1.	Save the license key to a system that has a web server, FTP server, or SCP server.
Step 2.	Log in to the sensor using an account with administrator privileges, and copy the license key to the sensor with the following command: sensor# copy scp://user@10.89.147.3://tftpboot/dev.lic license-key Password: *******
Step 3.	Verify that the sensor is licensed with the show version command as shown in Example 14-17: Example 14-17. Shows the Sensor Is Licensed with the show version Command sensor# show version Application Partition: Cisco Intrusion Prevention System, Version 5.0(1)S149.0 OS Version 2.4.26-IDS-smp-bigphys Platform: IPS-4255-K9 Serial Number: JAB0815R0JS ! The following line shows that the license is still valid Licensed, expires: 19-Dec-2005 UTC Sensor up-time is 2 days. Using 706699264 out of 3974291456 bytes of available memory (17% usage) system is using 17.3M out of 29.0M bytes of available disk space (59% usage) application-data is using 36.5M out of 166.8M bytes of available disk space (23% usage) boot is using 39.4M out of 68.6M bytes of available disk space (61% usage) MainApp 2005_Feb_18_03.00 (Release) 2005-02-18T03:13:47-0600 Running AnalysisEngine 2005_Feb_15_03.00 (QATest) 2005-02-15T12:59:35-0600 Running CLI 2005_Feb_18_03.00 (Release) 2005-02-18T03:13:47-0600 Upgrade History: IDS-K9-maj-5.0-1- 14:16:00 UTC Thu Mar 04 2004 Recovery Partition Version 1.1 - 5.0(1)S149 sensor#
Step 4.	Copy your license key from the sensor to a server to keep a backup copy of the license with the following command: sensor# copy license-key scp://user@10.1.1.100://tftpboot/user.lic Password: ******* sensor#

Communication Issues

You can connect to the sensor in a number of ways: Telnet, SSH, IDS MC (or IDM), Security Monitor and so on. The sections that follow discuss some of the connectivity issues:

• Basic connectivity issues

• Connectivity issues between IPS sensor and IPS MC or IDM

• Connectivity issues between IPS Sensor and security monitor

Basic Connectivity Issues

There might be several reasons why you cannot connect to the sensor either via Telnet or SSH. Work through the following steps to troubleshoot the connectivity issue to the sensor:

Step 1.	Ping to the sensor and see if you can ping to the Command and Control interface of the sensor.
Step 2.	If you cannot ping, log in to the sensor CLI through a console, terminal, or module session.
Step 3.	Be sure that the sensor's management interface is enabled: sensor# show interfaces Interface Statistics Total Packets Received = 0 Total Bytes Received = 0 Missed Packet Percentage = 0 Current Bypass Mode = Auto_off MAC statistics from interface GigabitEthernet0/1 ! The following line indicates that Media Type is backplane which is an ! indication that this is not Command & Control port Media Type = backplane Missed Packet Percentage = 0 Inline Mode = Unpaired Pair Status = N/A Link Status = Up Link Speed = Auto_1000 Link Duplex = Auto_Full Total Packets Received = 0 Total Bytes Received = 0 Total Multicast Packets Received = 0 Total Broadcast Packets Received = 0 Total Jumbo Packets Received = 0 Total Undersize Packets Received = 0 Total Receive Errors = 0 Total Receive FIFO Overruns = 0 Total Packets Transmitted = 0 Total Bytes Transmitted = 0 Total Multicast Packets Transmitted = 0 Total Broadcast Packets Transmitted = 0 Total Jumbo Packets Transmitted = 0 Total Undersize Packets Transmitted = 0 Total Transmit Errors = 0 Total Transmit FIFO Overruns = 0 MAC statistics from interface GigabitEthernet0/0 ! The following line indicates the Media Type TX which means this is a ! Command and Control Port Media Type = TX Link Status = Up Link Speed = Auto_100 Link Duplex = Auto_Full Total Packets Received = 1822323 Total Bytes Received = 131098876 Total Multicast Packets Received = 20 Total Receive Errors = 0 Total Receive FIFO Overruns = 0 Total Packets Transmitted = 219260 Total Bytes Transmitted = 103668610 Total Transmit Errors = 0 Total Transmit FIFO Overruns = 0 sensor# 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 4.	Duplicate IP Address Shuts Interface Down If another host in the network using the same IP address as the sensor comes 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.
Step 5.	Be sure the sensor's cabling is correct.
Step 6.	Be sure the sensor's IP address is unique and correct with the setup command. sensor# setup --- System Configuration Dialog --- At any point you may enter a question mark '?' for help. User ctrl-c to abort configuration dialog at any prompt. Default settings are in square brackets '[]'. Current Configuration: service host network-settings host-ip 10.89.130.108/23,10.89.130.1 host-name sensor telnet-option enabled access-list 0.0.0.0/0 ftp-timeout 300 no login-banner-text exit --MORE-- If the management interface detects that another device on the network has the same IP address, it will not come up. So, change the IP address, subnet mask, and default gateway of the sensor.
Step 7.	Be sure that the management port is connected to an active port. If the Command and Control port is not connected to an active port, the management interface will not come up on the sensor.
Step 8.	Be sure that the IP address of the workstation that is trying to connect to the sensor is permitted in the sensor's access list: sensor# setup --- System Configuration Dialog --- At any point you may enter a question mark '?' for help. User ctrl-c to abort configuration dialog at any prompt. Default settings are in square brackets '[]'. Current Configuration: service host network-settings host-ip 10.89.130.108/23,10.89.130.1 host-name sensor telnet-option enabled access-list 0.0.0.0/0 ftp-timeout 300 no login-banner-text exit --MORE Sensor# If the workstation's network address is permitted in the sensor's access list, go to Step 6.
Step 9.	Add a permit entry for the workstation's network address, save the configuration, and try to connect again. You can run the setup command to add addition, IP address, or network address on the sensor. Or, you can follow Example 14-18 to add permit to the access-list on the Sensor: Example 14-18. Verifying the Access List and Permitting or Denying on the ACL on Sensor ! View the current access-list configuration on the Sensor. sensor# show configuration | include access-list access-list 10.0.0.0/8 access-list 64.0.0.0/8 sensor# ! Verify that the client IP address is listed in the allowed networks. If it is not, ! add it with the following commands. sensor# configure terminal sensor(config)# service host sensor(config-hos)# network-settings sensor(config-hos-net)# access-list 171.69.70.0/24 ! Now verify the settings sensor(config-hos-net)# show settings network-settings ----------------------------------------------- host-ip: 10.89.149.238/25,10.89.149.254 default: 10.1.9.201/24,10.1.9.1 host-name: qsensor-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> ----------------------------------------------- sensor(config-hos-net)#
Step 10.	Be sure that 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, be sure that 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's IP address, and the sensor is in front of the firewall, be sure that the sensor's access list contains a permit entry for the workstation's translated address.
Step 11.	You can connect and you are getting login prompt but authentication fails. Check to see if logins to the account have been disabled due to the failed login limit being reached. The sensor provides the configuration option to limit the number of consecutive failed login attempts. Once this limit is reached the account becomes locked until it is administratively unlocked. This option is disabled by default. It can be enabled in the CLI. To determine if a failed login attempt limit is enabled, enter the authentication service configuration mode and use the show settings command. If the attemptLimit is greater than zero, the failed login attempt limit is set to this value. Set the attemptLimit value to zero to disable this account-locking feature. This feature is required to satisfy the government's Common Criteria for security devices. To check the failed login count, log into the service accountif possible. From the service account shell, run the command pam_tally. The output shows the number of failed login attempts for each account. To reset the count, run pam_tallyreset. This command will reset the failed login counts.

Connectivity Issues Between IPS Sensor and IPS MC or IDM

If you have problems with importing the sensor's configuration or pushing the configuration or signature upgrade, work through the following steps to troubleshoot the issue:

Step 1.	Go through the "Basic Connectivity Issues" section to ensure the basic network connectivity between the IDM or IPS MC.
Step 2.	For IPS MC or the IDM to function correctly, ensure that TCP/22 (SSH) and TCP/443 (SSL) are not blocked by any network devices between the sensor and the IPS MC.
Step 3.	Log in to IPS Sensor and execute the show version command. Ensure that MainApp is running; otherwise, IPS MC or IDM will not be able to connect to the IPS Sensor.
Step 4.	If the MainApp is shown not running, upgrade to the latest version of Sensor, and reboot the sensor. If the problem persists, get the show tech-support output and send the output file to the developer for root cause analysis.

Connectivity Issues Between IPS Sensor and Security Monitor

Security Monitor is used as a reporting tool for the IPS events. Work through the following steps to troubleshoot issues with connecting the Security Monitor with IPS Sensor:

Step 1.	In the Security Monitor go to Monitor > Connections and verify that the connection status is shown as TLS-Connected for the sensor that is experiencing connectivity problems. If you have any other status, go to the next step.
Step 2.	Go through the Basic Connectivity Issues section to ensure the basic connectivity.
Step 3.	Try to access the Event-Server using the browser with the following address: https://<sensor's IP address>/cgi-bin/event-server If the event-server is not accessible, then log in to the sensor and execute show version to ensure that MainApp is running, as the web server is part of MainApp. Upgrade to the latest version of IPS Sensor. If that does not resolve the problem, reboot the sensor. If you still have issues, look for any possible bugs on the sensor and on the Security Monitor.
Step 4.	If the MainApp is running, use any network devices between IPS Sensor and Security Monitor to ensure that tcp/22 (for SSH) and tcp/443 (SSL) are open.

Issues with Receiving Events on Monitoring Device

If you are unable to receive any events on the Monitoring device (for example, on the Security Monitor), the cause of the problem might be either on a sensor or monitoring device. This section goes delves into troubleshooting steps for situations in which you are not able to generate events on the sensor itself. Troubleshooting the "not showing events" problem on the Security Monitor is discussed in detail in Chapter 22, "Troubleshooting Security Monitors." There might be several reasons why Sensor might not be generating events. These are the most important reasons:

• Sensorapp is not running

• Physical Connectivity, SPAN, or VACL Port Issues

• Unable to see alerts

The sections that follow explain the preceding bulleted items in detail. But first ensure that the Sensor is indeed not generating any events by using the show events command as shown in Example 14-19.

Example 14-19. Checking To See if the Events Are Generated on the Sensor in Last 30 Minutes

Sensor# show events past 00:30:00 evAlert: eventId=1047568419898617804 severity=informational originator: hostId: sj_4250_40 appName: sensorApp appInstanceId: 1006 time: 2003/04/21 16:12:14 2003/04/21 16:12:14 PST interfaceGroup: 0 vlan: 0 signature: sigId=2151 sigName=Large ICMP subSigId=0 version=S37 participants: attack: attacker: proxy=false addr: locality=OUT 172.16.171.13 victim: addr: locality=OUT 171.69.89.32 Sensor# 

SensorApp Is Not Running

The SensorApp is the sensing process, which is part of AnalysisEngine, and it must always be running to receive any alerts. Work through the following steps to troubleshoot the SensorApp not running issue:

Step 1.	Log in to the sensor either via SSH or Telnet.
Step 2.	Find out the status of the AnalysisEngine service with the show version output as shown in Example 14-20. Example 14-20. show version Output Showing the AnalysisEngine Is Not Running sensor# show version Application Partition: Cisco Intrusion Prevention System, Version 5.0(1)S149.0 OS Version 2.4.26-IDS-smp-bigphys Platform: IDS-4235 Serial Number: CGTWJ11 Trial license, expires: 27-Apr-2006 UTC Sensor up-time is 3 days. Using 247812096 out of 923549696 bytes of available memory (26% usage) system is using 17.3M out of 29.0M bytes of available disk space (59% usage) application-data is using 31.9M out of 174.7M bytes of available disk space (19% usage) boot is using 40.5M out of 75.9M bytes of available disk space (56% usage) application-log is using 531.2M out of 2.8G bytes of available disk space (20% usage) MainApp 2005_Mar_04_14.23 (Release) 2005-03-04T14:35:11-0600 Running ! The following line shows the AnalysisEngine is not running. Hence SensorApp is not ! running AnalysisEngine 2005_Mar_04_14.23 (Release) 2005-03-04T14:35:11-0600 Not Running CLI 2005_Mar_04_14.23 (Release) 2005-03-04T14:35:11-0600 Upgrade History: IDS-K9-maj-5.0-1- 22:16:00 UTC Thu Mar 04 2004 Recovery Partition Version 1.1 - 5.0(1)S149 sensor#
Step 3.	If the AnalysisEngine is not running, look for any errors pertaining to AnalysisEngine, as shown in Example 14-21. Example 14-21. Analysis Engine Error, Which Shows the Last Restart Was on March 20, 2005 sensor# show events error fatal past 08:30:00 | include AnalysisEngine evError: eventId=1077219258696330005 severity=warning originator: hostId: sensor appName: sensorApp appInstanceId: 1045 time: 2005/03/20 10:35:00 2005/03/20 10:35:00 UTC errorMessage: name=errUnclassified Generating new Analysis Engine configuration file. Sensor#
Step 4.	As a first step to resolve the issue that the SensorApp is not running, check to see if a large number of signatures are set to ipLogging. If so, disable ipLogging, and check to see if this resolves the issue.
Step 5.	If you still have problems, reboot the sensor to solve the problem.
Step 6.	Check to see if you are running the latest version of Sensor. If not, go to the IPS Software download center on Cisco.com and go through the Readme file of the latest version. Check to see if there is any bug being reported pertaining to AnalysisEngine.
Step 7.	Upgrade to the latest version of IPS software and see if the problem disappears.
Step 8.	If the AnalysisEngine is not coming up even after you have completed the previous steps, get the show tech-support (coredump included) output and contact Cisco TAC support for further analysis.

Physical Connectivity, SPAN, or VACL Port Issues

If the sniffing port is not connected to a switch analyzer port (SPAN) or VACL (VACL stands for VLAN ACL) destination port correctly, or if you have misconfiguration on the switch, you will have problems getting the packets from the switch. Work through the following steps to troubleshoot issues pertaining to receiving traffic from the switch or the hub:

Step 1.	Sniffing Interface Connected to the wrong port on the Switch The Command and Control port is used to send the alarms to the Security Monitor, and the sniffing interface is used to capture the traffic feed from the switch. So, if you choose the wrong interface for the wrong task, for example, you connect the Command and Control port to the sniffing or VACL destination port on the switch, and you will not get the traffic feed, hence no alarm. Be sure that interfaces are up and counters are increasing by executing the show interface command as shown in Example 14-22. In this example, Media Type = backplane indicates a sniffing port. Example 14-22. A Working Sensing Interface sensor# show interfaces Interface Statistics Total Packets Received = 0 Total Bytes Received = 0 Missed Packet Percentage = 0 Current Bypass Mode = Auto_off MAC statistics from interface GigabitEthernet0/1 ! The following line indicates that GigabitEthernet0/1 interface is the sniffing ! interface. This interface should to be connected to the SPAN or the VACL destination ! port Media Type = backplane Missed Packet Percentage = 0 Inline Mode = Unpaired Pair Status = N/A Link Status = Up Link Speed = Auto_1000 Link Duplex = Auto_Full Total Packets Received = 0 Total Bytes Received = 0 Total Multicast Packets Received = 0 Total Broadcast Packets Received = 0 Total Jumbo Packets Received = 0 Total Undersize Packets Received = 0 Total Receive Errors = 0 Total Receive FIFO Overruns = 0 Total Packets Transmitted = 0 Total Bytes Transmitted = 0 Total Multicast Packets Transmitted = 0 Total Broadcast Packets Transmitted = 0 Total Jumbo Packets Transmitted = 0 Total Undersize Packets Transmitted = 0 Total Transmit Errors = 0 Total Transmit FIFO Overruns = 0 MAC statistics from interface GigabitEthernet0/0 ! The media type TX indicates that this is the Command and Control port Media Type = TX Link Status = Up Link Speed = Auto_100 Link Duplex = Auto_Full Total Packets Received = 1830137 Total Bytes Received = 131624465 Total Multicast Packets Received = 20 Total Receive Errors = 0 Total Receive FIFO Overruns = 0 Total Packets Transmitted = 220052 Total Bytes Transmitted = 103796666 Total Transmit Errors = 0 Total Transmit FIFO Overruns = 0 Sensor# Check to see that the sensing port is connected to the correct span port or the VACL destination port on the switch.
Step 2.	If the Link Status in Example 14-22 shows down, work through the following steps to correct the problem: Be sure that the sensor's sniffing interface is enabled and receiving traffic. You can use the setup command or follow Example 14-23 to enable the sniffing interface on the sensor. Example 14-23. Checking and Enabling the Sensing Interface sensor# configure terminal sensor(config)# service interface sensor(config-int)# physical-interfaces gigabitEthernet0/0 ! The following command shows the configuration for the sniffing interface sensor(config-int-phy)# show settings <protected entry> name: GigabitEthernet0/0 ----------------------------------------------- media-type: tx <protected> description: <defaulted> ! The following line shows the admin-state is disabled administratively. admin-state: disabled default: disabled duplex: auto <defaulted> speed: auto <defaulted> alt-tcp-reset-interface ----------------------------------------------- none ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- ! The following line shows how to enable the sniffing interface sensor(config-int-phy)# admin-state enabled ! Check the configuration settings again to see if the admin-state is enabled sensor(config-int-phy)# show settings <protected entry> name: GigabitEthernet0/0 ----------------------------------------------- media-type: tx <protected> description: <defaulted> ! Following line indicates the admin-state is enabled admin-state: enabled default: disabled duplex: auto <defaulted> speed: auto <defaulted> alt-tcp-reset-interface ----------------------------------------------- none ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- sensor(config-int-phy)# exit sensor(config-int)# exit Apply Changes:?[yes]: sensor(config)# exit ! Check to see if the sensing interface is shown UP or Down. sensor# show interfaces gigabitEthernet0/0 ! Extra lines are removed Media Type = TX ! Following line shows the link status is Up Link Status = Up ! Extra lines are removed sensor# If the sniffing interface is up, but the link status is still shown as down, be sure a working cable is connected properly to the sensing port with the switch. Check the switch configuration, identify the SPAN or VACL destination port, and connect the sensor's sniffing port to this port.
Step 3.	Check to see if the SPAN or VACL configuration is configured correctly. If, over a period of time, the sniffing interface is connected to the switch port, and is shown as up in the interface statistics, but the counters for incoming packets are not incrementing, or are staying at zero, then most likely the problem is an incorrect configuration of SPAN or VACL on the switch. Check to see if the SPAN or VACL destination port on the switch is up, sending traffic, and configured correctly.

Unable to See Alerts

If you do not see any events generated with the show events command on the sensor, work through the following steps to troubleshoot the problem:

Step 1.	Check to see if the virtual-sensor statistics is showing any alerts, as shown in Example 14-24. Example 14-24. Verifying that Alerts Are Being Generated on the Sensor 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#
Step 2.	Be sure that the signature is enabled and not retired, as shown in Example 14-25. Example 14-25. Signature Is Enabled and Is Not Retired 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 status ----------------------------------------------- ! The following line indicates that the signature is enabled. enabled: true <defaulted> ! The following line indicates that the signature is not retired. retired: false <defaulted> ----------------------------------------------- Sensor#
Step 3.	Be sure that you have Produce Alert configured as an action. If you have Produce Alert configured as event-action, but add another event-action later and do not add Produce Alert to the new configuration, alerts will not be sent to the Event Store. Every time you configure a signature, the new configuration overwrites the old one, so be sure you have configured all the event actions you want for each signature, as shown in Example 14-26. Example 14-26. Configuring And Checking Event Action Type Produce Alert sensor# configure terminal sensor(config)# service signature-definition sig0 sensor(config-sig)# signatures 1300 0 sensor(config-sig-sig)# engine normalizer ! Make sure to define multiple event-action with pipe sensor(config-sig-sig-nor)# event-action produce-alert || deny-connection-inline sensor(config-sig-sig-nor)# show settings normalizer ----------------------------------------------- ! Event-action types are shown as configured earlier event-action: produce-alert default: produce-alert| deny-connection-inline edit-default-sigs-only ----------------------------------------------- sensor#
Step 4.	Be sure the sensor is receiving packets from the network. Go through section entitled "Physical Connectivity, SPAN, or VACL Port Issue" for guidance on troubleshooting issues pertaining to the fact that the sensor is not able to receive any packets from the switch.
Step 5.	Be sure that there is no filter that is applied to the sensor that could be blocking the events. If you do not see the events, you need to be sure that you do not have the attacker address configured as filtering to eliminate the false positive. It is not very uncommon to define a filter for *ALL* signatures accidentally. The best way to find out if you have a filter in place is to execute this command on the sensor: show configuration | include EventFilter. If there is any filter for *ALL* then you will see a line similar to the following: EventFilter Filters DestAddrs * Exception False SIGID * SourceAddrs * SubSig * From the IDM on the sensor (https://sensorip), go to Configuration > Event Action Rules > Event Action Filters and analyze all the filters defined, and either edit or remove the incorrect filters.

Blocking Issues

In addition to events logging, the sensor can be configured to take actions in response to malicious activities against your network. If you are running Promiscuous mode, there are two options available on sensor software for taking actions against malicious activities: Blocking and tcp reset. Inline mode has two more option types in addition to these two options.

Network Access Controller (NAC), the blocking application on the sensor, starts and stops blocks on routers, switches, PIX Firewalls, Firewall Services Module (FWSM), and ASA. Network Access Controller blocks the IP address on the devices it is managing. It sends the same block to all the devices it is managing, including any other master blocking sensors. Network Access Controller monitors the time for the block and removes the block after the time has expired.

As most blocking-related issues arise because of lack of understanding, lack of planning, and misconfiguration, this section presents everything you need to be aware of, works through the configuration, and concludes with troubleshooting. Following is a list of items discussed in this section:

• Types of blocking

• ACL or VACL considerations on the managed devices

• Supported managed devices and versions

• Proper planning for blocking

• Master Blocking Sensor (MBS)

• Configuration steps for blocking

• Configuring steps for the Master Blocking Sensor (MBS)

• Troubleshooting steps for blocking

A thorough discussion follows section by section, based on the preceding list.

Types of Blocking

Not every managed device supports all types of blocking that can be performed by the sensor. So it is important to understand the different types of blocking that the sensor can perform and how each type of managed device works with these types. Following is a list of three types of blocks that are supported by the sensor:

• Host block Blocks all traffic from a given IP address. So it works based on source IP address. Cisco Secure firewalls (PIX, FWSM, and ASA series) perform Host block even if they are configured for Connection block.

• Connection block Blocks traffic from a given source IP address/port to a given destination IP address/destination port for a specific protocol. So it relies on 5-tuples (Source and Destination IP addresses and ports, and the protocol). As mentioned before, connection blocks are not supported on Cisco Secure firewalls. Firewalls only support host blocks with additional connection information. Understand that multiple connection blocks from the same source IP address to either a different destination IP address or destination port automatically switch the block from a connection block to a host block.

• Network block Blocks all traffic from a given network. It is possible to initiate host and connection blocks manually or automatically when a signature is triggered, but network blocks can only be initiated manually.

Note

Blocking is a different feature altogether than the sensor's ability to drop packets in Inline mode when deny packet inline, deny connection inline, and deny attacker inline action types are configured. So, do not confuse these actions with Blocking.

ACL or VACL Consideration on the Managed Devices

On Cisco routers and Catalyst 6500 series switches, Network Access Controller creates blocks by applying ACLs or VACLs. ACLs and VACLs permit or deny passage of data packets through interface ports or VLANs. Each ACL or VACL contains permit and deny conditions that apply to IP addresses. The PIX Firewall, FWSM, and ASA do not use ACLs or VACLs. The built-in shun/no shun command is used. As the implementation of ACL and VACL is very similar for blocking performed by Sensor, the discussion focuses only on ACL, which is also appropriate for VACL. Several ACLs are used with the blocking. Hence it's critical to understand use of these ACLs:

• Two ACLs used by Network Access Controller NAC uses two ACLs to manage devices. Only one is active at any one time. It uses the offline ACL name to build the new ACL, and then applies it to the interface.

• Pre-Block ACL The Pre-Block ACL is mainly used for permitting the networks or hosts that you do not want the sensor to ever block. When a packet is checked against the ACL, the first line that is matched determines the action. If the first line matched is a permit line from the Pre-Block ACL, the packet is permitted even though there might be a deny line (from an automatic block) listed later in the ACL. The Pre-Block ACL can override the deny lines resulting from the blocks. To modify the Pre-Block ACL on the router, you need to disable blocking from the sensor, make the changes on the ACL, and then re-enable the blocking on the sensor.

• Post-Block ACL The Post-Block ACL is best used for additional blocking or permitting that you want to occur on the same interface or direction. If you have an existing ACL on the interface or direction that the sensor will manage, that existing ACL can be used as a Post-Block ACL. If you do not have a Post-Block ACL, the sensor inserts a permit ip any any at the end of the new ACL. If you need to modify the Post-Block ACL on the router, you need to disable blocking from the sensor, make the changes on the ACL, and then re-enable the blocking on the sensor.

You need to create and save Pre-Block and Post-Block ACLs in your router configuration. These ACLs must be extended IP ACLs, either named or numbered. See your router documentation for more information on creating ACLs.

Enter the names of these ACLs that are already configured on your router in the Pre-Block ACL and Post-Block ACL fields on the sensor. When the sensor starts up, it reads the contents of the two ACLs. It creates a third ACL (the active ACL of two ACLs used by NAC to manage blocking) with the following entries:

• A permit line for the sensor's IP address

• Copies of all configuration lines of the Pre-Block ACL

• A deny line for each address being blocked by the sensor

• Copies of all configuration lines of the Post-Block ACL

• If the Post-Block ACL is not configured, then add permit ip any any to allow the rest of the traffic. In the case of VACL and IDSM-2, the last statement is permit ip any any capture, with capture argument appended.

• The sensor applies the new ACL to the interface and direction that you designate. When the new ACL is applied to an interface or direction of the router, it removes the application of any other ACL to that interface or direction.

Note

The Pre-Block or Post-Block ACL names are not used when Sensor creates and names the third ACL and applies it on the managed device.

Supported Managed Devices and Versions

Network Access Controller supports up to 250 devices in any combination by default. As not every network device and version of the device can be configured to be a managed device, it is important to know which devices and versions can be used as managed devices. Following is a list of such versions and devices:

• Routers using Cisco IOS 11.2 or later (using ACLs) include, Cisco 1600 series router, Cisco 1700 series router, Cisco 2500 series router, Cisco 2600 series router, Cisco 2800 series router, Cisco 3600 series router, Cisco 3800 series router, Cisco 7200 series router, and Cisco 7500 series router.

• Catalyst 5000 switches with Route Switch Module (RSM) with IOS 11.2(9)P or later (Using ACLs).

• Catalyst 6500 switches and 7600 routers with IOS 12.1(13)E or later (using ACLs).

• Catalyst 6500 switches and 7600 routers with Catalyst software version 7.5(1) or later (Using VACLs), which include Supervisor Engine 1A with Policy Feature Card (PFC), Supervisor Engine 1A with Multilayer Switching Feature Card (MSFC)1, Supervisor Engine 1A with MFSC2, Supervisor Engine 2 with MSFC2, and Supervisor Engine 720 with MSFC3. It is important to note that VACL blocking is supported on the Supervisor Engine and ACL blocking is supported on the MSFC.

• PIX Firewall with version 6.0 or later (shun command) which includes all platforms 501, 506E, 515E, 525, and 535.

• ASA with version 7.0 or later (With shun command), which includes platforms ASA-5510, ASA-5520, and ASA-5540.

• FWSM 1.1 or later (With shun command). If ASA or FWSM is configured in multi-mode, blocking is not supported for the admin context. Blocking is only supported in single mode and in multi-mode customer context.

So, as you can see, you can configure blocking using either ACLs, VACLS, or the shun command, depending on the types of platforms used as managed devices.

Proper Planning for Blocking

Implementing the blocking feature requires proper planning, as there are serious consequences in terms of blocking legitimate traffic. You can disrupt the network by blocking routing protocol traffic and experience other problems. With proper planning, you can implement blocking without any trouble. Following is a list that will assist you in the planning required to implement the blocking feature:

• Obtain a clear understanding of the network topology, and be absolutely sure about the devices which should be managed by the sensor for blocking.

• Find out the network or host addresses that should never be blocked. One such example is the sensor's IP address itself.

• From the administrators responsible for each device, obtain the usernames, passwords, enable passwords, and connection types (Telnet or SSH) needed to log into each device. If possible, get permission to access the managed devices.

• Be absolutely sure that you know the interface names of the managed device and the directions in which Sensor should apply the blocking.

• Understand which interfaces should and should not be blocked and in which direction (in or out). You do not want to accidentally shut down an entire network.

• Carefully define the network or host address that should never be blocked with the Pre-Block ACL or VACL. For additional blocking, use Post-Block ACL or VACL if needed. Get their names as they appear on the managed devices.

• Do not configure multiple sensors to control blocking on the same device. If multiple sensors are needed, configure one sensor as the master blocking sensor to manage the devices, and the other sensors can forward their block requests to the master blocking sensor. This brings up the discussion that follows on Master Blocking Sensor.

Master Blocking Sensor (MBS)

If you are monitoring more than one network by using multiple sensors, and if more than one sensor needs to initiate blocking to the same managed device, serious disruption to the traffic might occur. Hence, only one sensor must control the blocking for the managed devices. This is the role of the master blocking sensor (MBS). In this case, the MBS should be configured to control blocking for all managed devices. The non-MBS, also known as the blocking forwarding sensor, should be configured not to control blocking for a managed device, but rather to communicate its blocks to the MBS sensor.

You do not need any special configuration on the MBS to designate it to be an MBS. Most of the configuration is done on the blocking forwarding sensor, which forwards the block request to the MBS. You can configure one MBS to forward block requests to another MBS. But, you need to be extremely careful with a circular block that might occur if misconfigured. For example, assume that SensorA is configured as MBS for SensorB and SensorB is also configured as MBS for SensorA. Both SensorA and SensorB will forward the block request to each other, causing a circular block. With two sensors this can be easily avoided by merely configuring one for the MBS and one for the other sensor which is also acting as MBS for some other sensor (for example SensorC). But, if you have a complex setup with a number of sensors acting as MBS for non-MBS sensors in addition to the MBS Sensor, extra caution is warranted.

Configuration Steps for Blocking

Work through the following steps to configure blocking on the IOS router:

Step 1.	Configure user profiles on the sensor so that Sensor can log in to the managed device. The user profile contains user id, password, and enable password information. If the username or password is not needed to log in to the device, you do not need to set a value for it. You must create a user profile before configuring the blocking device. Example 14-27 shows how to create a user profile on the sensor for the router. Example 14-27. Setting up User Profiles on the Sensor ! Log in to the Sensor's CLI using an account with administrator privileges and enter ! network access mode sensor# configure terminal sensor(config)# service network-access ! Create the user profile name sensor(config-net)# user-profiles ROUTER_PROFILE ! Type the username for that user profile sensor(config-net-use)# username cisco ! Specify the password for the user sensor(config-net-use)# password Enter password[]: ******** Re-enter password:******** ! Specify the enable password for the user sensor(config-net-use)# enable-password Enter enable-password[]: ******** Re-enter enable-password ******** ! Verify the user profile settings sensor(config-net-use)# show settings profile-name: ROUTER_PROFILE ----------------------------------------------- enable-password: <hidden> password: <hidden> username: cisco default: ----------------------------------------------- sensor(config-net-use)# ! Exit network access submode sensor(config-net-use)# exit sensor(config-net)# exit Apply Changes:?[yes]: ! Press Enter to apply the changes or type no to discard them. Sensor#
Step 2.	If a managed device is configured with SSH, execute the following command on the sensor for each managed device to add them as trusted hosts. Otherwise, skip this step. Sensor# configure terminal sensor(config)# ssh host-key <device's IP address>
Step 3.	Enter the network access submode of the sensor as follows: sensor# configure terminal sensor(config)# service network-access
Step 4.	Set the IP address for the router controlled by Network Access Controller and define the user profile name as follows: sensor(config-net)# router-devices ip_address sensor(config-net-rou)# profile-name user_profile_name It is important to note that Network Access Controller accepts any command you type. So be sure that you type the correct profile name.
Step 5.	Define a communication method with the following command to access the sensor: sensor(config-net-rou)# communication [telnet | ssh-des | sh-3des] If no communication is specified, SSH 3DES is used.
Step 6.	If a NAT device is used between the sensor and the managed device, specify the sensor's NAT address with the following command: sensor(config-net-rou)# nat-address nat_address
Step 7.	Set the interface name and direction with the following command: sensor(config-net-rou)# block-interfaces interface_name [in | out] The name of the interface must either be the complete name of the interface or an abbreviation that the router recognizes with the interface command.
Step 8.	Optionally, add the pre-ACL name as follows: sensor(config-net-rou-blo)# pre-acl-name pre_acl_name
Step 9.	Optionally, add the post-ACL name as follows: sensor(config-net-rou-blo)# post-acl-name post_acl_name
Step 10.	Exit the network access submode as follows: sensor(config-net-rou-blo)# exit sensor(config-net-rou)# exit sensor(config-net)# exit sensor(config)# exit Apply Changes:?[yes]:
Step 11.	Press Enter to apply the changes or type no to discard them.
Step 12.	Execute show settings to verify the correctness of the NAC configuration.

Blocking configuration for Native IOS on the switch or the MSFC uses the same procedure as blocking configuration for IOS on the router. The configuration for the VACL on the Hybrid mode is very similar to the configuration of IOS router, with the exceptions of the syntax. Example 14-28 shows the Blocking configuration for the CatOS (hybrid mode).

Example 14-28. Blocking Configuration on the Sensor for CatOS on Switch 6500 and 7600 Series Router

! Log in to the CLI using an account with administrator privileges and enter. Enter ! network access submode. sensor# configure terminal sensor(config)# service network-access ! Set the IP address for the router controlled by Network Access Controller sensor(config-net)# cat6k-devices ip_address ! Type the user profile name that you created in Configuring User Profiles. sensor(config-net-cat)# profile-name user_profile_name ! Network Access Controller accepts anything you type. It does not check to see if ! the logical device exists. Designate the method used to access the sensor. sensor(config-net-cat)# communication [telnet | ssh-des/ | sh-3des] ! If unspecified, SSH 3DES is used. If you are using DES or 3DES, you must use the ! command ssh host-key ip_address to accept the key or Network Access Controller ! cannot connect to the device. Specify the sensor's NAT address. sensor(config-net-cat)# nat-address nat_address ! Specify the VLAN number. sensor(config-net-cat)# block-vlans vlan_number ! (Optional) Add the pre-VACL name sensor(config-net-cat-blo)# pre-vacl-name pre_vacl_name ! (Optional) Add the post-VACL name. sensor(config-net-cat-blo)# post-vacl-name post_vacl_name ! Exit network access submode sensor(config-net-cat-blo)# exit sensor(config-net-cat)# exit sensor(config-net)# exit sensor(config)# exit Apply Changes:?[yes]: ! Press Enter to apply the changes or type no to discard them. Sensor# 

Blocking is performed differently on the firewalls, as discussed before. Example 14-29 shows the configuration steps required to configure Blocking on Sensor for Cisco firewalls.

Example 14-29. Configuration Steps Required to Configure Blocking on Cisco Firewalls

! Log in to the Sensor's CLI using an account with administrator privileges and enter ! network access submode sensor# configure terminal sensor(config)# service network-access ! Set the IP address for the firewall controlled by Network Access Controller sensor(config-net)# firewall-devices ip_address ! Type the user profile name that you created in Configuring User Profiles. sensor(config-net-fir)# profile-name user_profile_name ! Network Access Controller accepts anything you type. It does not check to see if ! the logical device exists. Designate the method used to access the sensor. sensor(config-net-fir)# communication [telnet | ssh-des | sh-3des] ! If unspecified, SSH 3DES is used. If you are using DES or 3DES, you must use the ! command ssh host-key ip_address to accept the key or Network Access Controller ! cannot connect to the device. ! Specify the sensor's NAT address sensor(config-net-fir)# nat-address nat_address ! Exit network access submode. sensor(config-net-fir)# exit sensor(config-net)# exit sensor(config)# exit Apply Changes:?[yes]: ! Press Enter to apply the changes or type no to discard them. Sensor# 

Configuring Steps for the Master Blocking Sensor (MBS)

Work through the following steps to configure Master Blocking Sensor (MBS):

Step 1.	Open two Telnet or SSH sessions, and log in to the sensor using an account with administrator privileges on both the master blocking sensor and the blocking forwarding sensor.
Step 2.	On the Master Blocking Sensor, check to see if it requires TLS and what port is used with following commands: MBS# configure terminal MBS(config)# service web-server MBS(config-web)# show settings ! The following line indicates that TLS is required to connect to this MBS enable-tls: true <defaulted> port: 443 <defaulted> server-id: HTTP/1.1 compliant <defaulted> MBS(config-web)# Configure TLS if necessary.
Step 3.	Get the fingerprints of the Master Blocking Sensor's host certificate with the command show tls fingerprint.
Step 4.	On the blocking forwarding sensor, configure it to accept the X.509 certificate of the Master Blocking Sensor (MBS) by using the following command: sensor(config-web)# exit sensor(config)# tls trusted-host ip-address mbs_ip_address port port_number If, for example, 10.1.1.50 is the address of the master blocking sensor and its web server is listening on port 443, execute the following command on the blocking forwarding sensor: sensor(config)# tls trusted-host ip-address 10.1.1.50 port 443 Certificate MD5 fingerprint is F4:4A:14:BA:84:F4:51:D0:A4:E2:15:38:7E:77:96:D8Certificate SHA1 fingerprint is 84:09:B6:85:C5:43:60:5B:37:1E:6D:31:6A:30:5F:7E:4D:4D:E8:B2 Would you like to add this to the trusted certificate table for this host?[yes]: You are prompted to accept the certificate based on the certificate's fingerprint. Compare this fingerprint with the one collected from Step 3. If it matches, type yes or click the Return button.
Step 5.	Enter network access mode, then go under general submode and define the MBS information with the commands shown in Example 14-30: Example 14-30. Defining Master Blocking Sensor Configuration on the Blocking Forwarding Sensor sensor(config)# service network-access sensor(config-net)# general ! The following line defines the MBS's IP address sensor(config-net-gen)# master-blocking-sensors mbs_ip_address ! Specify the username for an administrative account on the master blocking sensor sensor(config-net-gen-mas)# username username ! Specify the password for the user sensor(config-net-gen-mas)# password Enter password []: ***** Re-enter mbs-password []: ***** sensor(config-net-gen-mas)# ! Specify the port number for the host's HTTP communications. sensor(config-net-gen-mas)# port port_number ! The default is 80/443 if not specified. ! Set the status of whether or not the host uses TLS/SSL sensor(config-net-gen-mas)# tls [true | false] sensor(config-net-gen-mas) ! If you set the value to true, you need to use the command tls trusted-host ! ip-address ! mbs_ip_address. ! Exit network access submode sensor(config-net-gen-mas)# exit sensor(config-net-gen)# exit sensor(config-net)# exit sensor(config)# exit Apply Changes:?[yes]: ! Press Enter to apply the changes or type no to discard them. Sensor#
Step 6.	On the master blocking sensor, add the block forwarding sensor's IP address to the access list.
Step 7.	As shown in Example 14-31, initiate a manual block from the blocking forwarding sensor to a bogus host IP address to make sure the master blocking sensor is initializing blocks: Example 14-31. Initiating Manual Blocking from the Blocking Forwarding Sensor sensor# configure terminal sensor(config)# service network-access sensor(config-net)# general sensor(config-net-gen)# block-hosts 10.10.10.100 ! Exit network access general submode sensor(config-net-gen)# exit sensor(config-net)# exit Apply Changes:? [yes]: ! Press Enter to apply the changes or type no to discard them. ! Verify that the block shows up in the Network Access Controller's statistics sensor# show statistics network-access Current Configuration AllowSensorShun = false ShunMaxEntries = 100 State ShunEnable = true ShunnedAddr Host IP = 10.10.10.100 ShunMinutes = Sensor#
Step 8.	Log in to the Master Blocking Sensor host's CLI and, using the show statistics network-access command, verify that the block also shows up in the master blocking sensor Network Access Controller's statistics, as shown in Example 14-32. Example 14-32. Verifying the Statistics on the MBS MBS# show statistics network-access Current Configuration AllowSensorShun = false ShunMaxEntries = 250 MasterBlockingSensor SensorIp = 10.1.1.100 SensorPort = 443 UseTls = 1 State ShunEnable = true ShunnedAddr Host ! This is Manual Blocking that is initiated from the forwarding sensor. This ! indicates that blocking forwarding sensor is appropriately forwarding the block ! request. IP = 10.10.10.100 ShunMinutes = 60 MinutesRemaining = 59 MBS#
Step 9.	Log in to the managed devices and execute show access-list on IOS or show shun on PIX OS to verify if the blocking takes place.

Caution

Only one sensor should control all blocking interfaces on a device.

Troubleshooting Steps for Blocking

Several factors might cause blocking to work incorrectly on the sensor. As a fact-finding step, it is imperative to verify that blocking is functioning. The sections that follow discuss blocking verifications procedure followed by the possible causes of blocking failure along with steps to solve the problems. The sections that follow cover the following topics:

• Verifying that blocking is functioning correctly

• Network Access Controller (NAC) is not running

• Sensor is unable to connect to the managed devices

• Blocking is not occurring for a specific signature

• Master blocking is not working

Verifying that Blocking is Functioning Correctly

After you configure blocking, you should first check to see that the blocking is working properly. This will ensure that blocking will work at the time of the attack. Checking is accomplished by initiating the sending of a manual block to a bogus host and then checking to see if deny entries exist for the blocked addresses in the router's ACL or, in the case of PIX firewall, checking to see if the shun is created for the bogus IP address.

You can initiate the manual block as shown in Example 14-33.

Example 14-33. Initiating a Manual Block to a Bogus IP Address to the Sensor

! Enter Network Access Controller general sub mode with the following commands sensor# configure terminal sensor(config)# service network-access sensor(config-net)# general ! Start the manual block of the bogus host IP address sensor(config-net-gen)# block-hosts 10.1.1.0 ! Exit general sub mode sensor(config-net-gen)# exit sensor(config-net)# exit Apply Changes:? [yes]: ! Press Enter to apply the changes or type no to discard them. ! If you want to remove manual block, you can execute the following command sensor(config-net-gen)# no block-hosts 10.1.1.0 sensor(config-net-gen)# 

If your managed device is a router, use Telnet to access the router and execute a show access-list command. If the blocking is working correctly, you should see that the bogus IP address is being denied.

If your managed device is a PIX firewall or FWSM, execute show shun and it will show that the bogus IP address is being shunned.

Note

You can also perform a manual block from IDM by clicking Monitoring > Active Host Blocks.

If your network is under attack, and if you want to verify that the blocking is working on the sensor, you can execute the show event | include sig_id command, which will display the event that is triggered for the attack. If the field for "shun" is set to true for this attack event, look at the time on the field. If the field is set to False or does not exist, then the sensor is not even attempting to block for that alert. Once you have verified the alert as the field for shun set to true, look at the time on the field. Then execute show event nac <time> <date>, but replace the time and date with the time and date just before when your alarm fired, so that you can capture the details of the NAC event that was fired. Now, you can go to the managed devices and check to see if the ACL is applied on the routers and switches, and if the shun command is applied on the PIX firewall or FWSM.

Network Access Controller (NAC) is not running

If the blocking fails with the test described in the preceding section, you should first be sure that the Network Access Controller, which is responsible for blocking, is running. To verify if Network Access Controller is running, you can execute the show version command on the Sensor CLI. In IDS version 4.x, you will see a separate process for NAC, but in version IPS 5.x, Network Access Controller (NAC) is part of MainApp. So, if MainApp is not running, the Network Access Controller cannot run. Example 14-34 shows a sample output of show version that shows that MainApp is not running.

Example 14-34. MainApp Is not Running in show version Output

sensor# show version Application Partition: Cisco Intrusion Prevention System, Version 5.0(1.1)S152.0 OS Version 2.4.26-IDS-smp-bigphys Platform: IPS-4255-K9 Serial Number: JAB0815R017 No license present Sensor up-time is 3 days. Using 734863360 out of 3974291456 bytes of available memory (18% usage) system is using 17.3M out of 29.0M bytes of available disk space (59% usage) application-data is using 35.6M out of 166.8M bytes of available disk space (23% usage) boot is using 40.5M out of 68.6M bytes of available disk space (62% usage) ! The following line shows the MainApp is not running, which means NAC is also not ! running MainApp         2005_Mar_04_14.23   (Release) 2005-03-04T14:35:11-0600 Not Running AnalysisEngine  2005_Mar_18_12.53   (Release) 2005-03-18T13:03:21-0600 Running CLI             2005_Mar_04_14.23   (Release) 2005-03-04T14:35:11-0600 Upgrade History:   IDS-K9-sp-5.0-1.1-   12:53:00 UTC Fri Mar 18 2005 Recovery Partition Version 1.1 - 5.0(1.1) sensor# 

The preceding example shows that MainApp is Not Running. This usually happens if you run into software corruption or bugs. If you are not already running the latest version, a quick remedy would be to upgrade the latest version of the code on the sensor from the following location:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids11/cliguide/cliobtsw.htm#wp1034270

It is also advisable to read the Readme file of the latest version of Sensor to see if there is any bug related to NAC that is fixed on the latest version of code. If upgrade does not resolve the issue, consult with Cisco Support for further diagnosis of the problem before you proceed with re-imaging the sensor.

Sensor is Unable to Connect to the Managed Devices

If you followed the steps in the preceding section, you verified that MainApp (NAC) is running. Next you need to verify that the sensor can connect to the managed devices. There are two ways to verify this. Work through the steps that follow to verify whether the sensor is connecting to the managed devices:

Step 1.	Verify that Network Access Controller Connections are Active Execute the show statistics network-access command to verify that the state is Active as shown in Example 14-35. If the State is not Active in the Network Access Controller statistics, there is a problem with connecting to the managed devices. Example 14-35. State Is Active for Network Access Control sensor# show statistics network-access | include State State State = Active sensor# If you have more than one managed device configured and you need to identify a specific device that is having connectivity problems, it is advisable to find out if there is any problem with any of the managed devices of the preceding example. If there is, then you might want to execute the show statistics network-access command without the additional filter, as shown in Example 14-36. Example 14-36. The Statistics Details of Network Access Control sensor# show statistics network-access Current Configuration LogAllBlockEventsAndSensors = true EnableNvramWrite = false EnableAclLogging = false AllowSensorBlock = false BlockMaxEntries = 250 MaxDeviceInterfaces = 250 NetDevice Type = Cisco IP = 10.89.147.54 NATAddr = 0.0.0.0 Communications = telnet BlockInterface InterfaceName = fa0/0 InterfaceDirection = in State BlockEnable = true NetDevice IP = 10.89.147.54 AclSupport = uses Named ACLs Version = 12.2 State = Active sensor#
Step 2.	If the Network Access Controller is not connecting, you can look for recurring errors with the following command: show events error hh:mm:ss month day year | include : nac Example 14-37 shows a recurring error since May 01, 2005, as the sensor is unable to connect to the managed device. Example 14-37. Recurring Error When the Sensor Is Unable to Connect to the Managed Device sensor# show events error 00:00:00 May 01 2005 | include : nac evError: eventId=1111046752731786193 severity=error vendor=Cisco originator: hostId: sensor13 appName: nac appInstanceId: 301 time: 2005/05/04 17:38:47 2005/05/04 09:38:47 UTC ! The following message appears multiple times and indicates that the Sensor is ! unable to connect to the managed device. errorMessage: name=errSystemError Unable to execute a host block [171.69.75.13] because all of the devices are not reachable evError: eventId=1111046752731786197 severity=error vendor=Cisco originator: hostId: sensor13 appName: nac appInstanceId: 301 time: 2005/05/04 17:38:47 2005/05/04 09:38:47 UTC errorMessage: name=errSystemError Unable to execute a host block [171.69.75.13] because all of the devices are not reachable ! Rest of the output is removed Sensor# If the previous steps reveal that the problem is with the connectivity between the sensor and the managed devices, work through the following steps to troubleshoot connectivity issues:
Step 3.	Make sure the configuration settings (the username, password, and IP address) for each device are correct. Example 14-38 shows how to verify the settings: Example 14-38. Verifying the NAC Configuration sensor# configure terminal sensor (config)# service network-access sensor(config-net)# show settings general ----------------------------------------------- log-all-block-events-and-errors: true <defaulted> enable-nvram-write: false <defaulted> enable-acl-logging: false <defaulted> allow-sensor-block: false <defaulted> block-enable: true <defaulted> block-max-entries: 250 <defaulted> max-interfaces: 250 <defaulted> master-blocking-sensors (min: 0, max: 100, current: 0) ----------------------------------------------- ----------------------------------------------- never-block-hosts (min: 0, max: 250, current: 0) ----------------------------------------------- ----------------------------------------------- never-block-networks (min: 0, max: 250, current: 0) ----------------------------------------------- ----------------------------------------------- block-hosts (min: 0, max: 250, current: 0) ----------------------------------------------- ----------------------------------------------- block-networks (min: 0, max: 250, current: 0) ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- user-profiles (min: 0, max: 250, current: 1) ----------------------------------------------- profile-name: r7200 ----------------------------------------------- enable-password: <hidden> password: <hidden> username: netrangr default: ----------------------------------------------- ----------------------------------------------- cat6k-devices (min: 0, max: 250, current: 0) ----------------------------------------------- ----------------------------------------------- router-devices (min: 0, max: 250, current: 1) ----------------------------------------------- ip-address: 10.89.147.54 ----------------------------------------------- communication: telnet default: ssh-3des nat-address: 0.0.0.0 <defaulted> profile-name: r7200 block-interfaces (min: 0, max: 100, current: 1) ----------------------------------------------- interface-name: fa0/0 direction: in ----------------------------------------------- pre-acl-name: <defaulted> post-acl-name: <defaulted> ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- firewall-devices (min: 0, max: 250, current: 0) ----------------------------------------------- ----------------------------------------------- sensor(config-net)#
Step 4.	Check to see if the sensor is blocking itself as shown in Example 14-39. Example 14-39. Shows How to Check to See if the Sensor Is Configured to Block Itself sensor# configure terminal sensor(config)# service network-access ! Enter general submode sensor(config-net)# general ! Configure the sensor to block itself sensor(config-net-gen)# allow-sensor-block true ! By default, this value is false. Verify the settings sensor(config-net-gen)# show settings general ----------------------------------------------- log-all-block-events-and-errors: true <defaulted> enable-nvram-write: false <defaulted> enable-acl-logging: false <defaulted> ! As shown in the following line, default is False, but Sensor blocking is set to True allow-sensor-block: true default: false block-enable: true default: true block-max-entries: 100 default: 250 --MORE-- Sensor# If the preceding example reveals that you are indeed blocking the sensor itself, this might cause the sensor to be unable to connect to the managed device. On the Cisco Router or on switches, you can work around this problem, but on the Cisco firewall, sensor blocking must be set to False with the following command: sensor(config-net-gen)# allow-sensor-block false
Step 5.	If the configuration looks good after you have followed the previous step, log in to the service account on the sensor and manually connect to the device to ensure that you have used the correct username, password, and enable password, and to ensure that the device is reachable from the sensor. Log in to the service account on the sensor. Use Telnet or SSH to access the managed device with the login ID and password that you have defined for the NAC configuration on the Sensor. If you cannot connect, check the managed device configuration to make sure that Telnet or SSH is allowed from the sensor. If you can connect to the managed devices but cannot log in, you need to troubleshoot the issue on the managed device for the login. If you cannot log in to the managed device from the service account, the NAC on the sensor will also be unable to log in to the managed device. So be sure that you can Telnet or SSH into the Managed device to log in and make configuration changes. If you use Telnet and cannot get the login prompt, go to Step 3 for additional troubleshooting. If you use SSH, go to Step 4. If Telnet and SSH both return the login prompt, and you cannot log in, then go to Step 5.
Step 6.	If you cannot Telnet from the service account of the sensor, work through the following steps to troubleshoot the issue: Telnet to the managed device from another host in the network and see if you get the Telnet login prompt. If you are not getting a Telnet prompt, the incoming interface ACL probably is blocking all Telnet, or the managed device is not configured for Telnet login at all. However, if you are getting a Telnet login prompt from another host, the probable cause of the problem is that Sensor is not allowed to the managed device. If the managed device is a router, be sure that the sensor's IP address is allowed on the incoming interface ACL (if ACL is applied) and also allowed on the ACL that is applied as the access-class under line vty 0 4. If the managed device is a PIX firewall or FWSM, execute the show telnet command and be sure that the Sensor IP address is allowed. If the Sensor IP address is not allowed, add the sensor IP address as one of the allowed IPs for Telnet. If the managed device is a switch, be sure the ACL is allowing the Sensor's IP address.
Step 7.	If you are using SSH to connect to the managed devices, be sure that the managed device supports SSH 1.5. The sensor does not support SSH 2.0. Work through the following steps to troubleshoot the SSH issue: Try to connect to the managed devices using another machine in the network with an SSH client. If you cannot get any login prompt, the problem might be with the ACL dropping the SSH packets. Also, you might have not have configured SSH on the managed device. Depending on whether you are using SSH-DES or SSH-3DES as the communication protocol for the network device, you need to configure it on the sensor and also with the command shown in Example 14-40: Example 14-40. Downloading the Public Key from the PIX Firewall sensor# configure terminal ! Enable SSH with the following command. sensor(config)# ssh host 10.1.1.100 ! Type yes when prompted to accept the device. MD5 fingerprint is 70:33:DC:DB:DD:85:CE:C9:02:D4:D0:30:D2:B3:49:E5 Bubble Babble is xitak-ducun-muteg-lilos-luhok-vuzut-kyhop-dibul-mehur-vebak-texex Would you like to add this to the known hosts table for this host?[yes]: sensor(config)# exit sensor# If the public key from the managed device is not downloaded, or if it is downloaded but becomes corrupted, you will receive the message similar to the ones shown in example 14-41. To resolve the issue, regenerate the RSA key on the managed device (in this case PIX firewall) and then download the key as per Example 14-42. Example 14-41. debug Messages Shown on the PIX Firewall When the Public Key Is Not Downloaded to the Sensor PIX# debug ssh 2933: SSH0: send SSH message: outdata is NULL 2934: SSH0: receive SSH message: 83 (83) 2935: SSH0: client version is - SSH-1.5-OpenSSH_3.7.1p2 2936: SSH0: begin server key generation 2937: SSH0: complete server key generation, elapsed time = 780 ms 2938: SSH0: declare what cipher(s) we support: 0x00 0x00 0x00 0x0c 2939: SSH0: send SSH message: SSH_SMSG_PUBLIC_KEY (2) 2940: SSH0: SSH_SMSG_PUBLIC_KEY message sent 2941: SSH0: TCP read failed, error code = 0x86300003 "TCP connection closed" 2942: SSH0: receive SSH message: [no message ID: variable *data is NULL] 2943: SSH0: Session disconnected by SSH server - error 0x03 "TCP connection closed" PIX# To resolve the issue, regenerate the RSA key on the managed device (in this case PIX firewall) as shown in Example 14-42, and then download the key as per Example 14-40. Example 14-42. Removing and Regenerating A Key on the PIX Firewall PIX(config)# ca zeroize rsa PIX(config)# ca generate rsa key 1024 PIX(config)# ca save all If the SSH is getting a login prompt but is unable to log in to the sensor from the service account of the sensor, go to the next step.
Step 8.	If the SSH or Telnet presents a login prompt and you cannot log in, troubleshoot the issue on the managed devices themselves. If AAA is used for authentication, on the router, run debug aaa authentication, on the switch run set trace tacacs/radius 4, and on the PIX set debug level logging and analyze the debug output to see why the authentication is failing. The username and password that will be used for the sensor to log in must have a high enough privilege to write an access-list to the managed device.
Step 9.	Verify 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 managed device's ACL. You can either execute the show running-config or the show access-list command to verify whether the manual blocking is applied on the managed devices, such as on routers. On the PIX firewall, you can verify this by executing the show ssh command.

Blocking is Not Occurring for a Specific Signature

If blocking is not working for a specific signature, from IDM or IPS MC, edit the signature and check if the event action is set to block the host. If it is not, correct action needs to be set. Example 14-43 shows how to set the event action to block, and how to verify the settings.

Example 14-43. Configuration and Verifications of the Blocking Configuration for a Signature

sensor# configure terminal sensor(config)# service signature-definition sig0 sensor(config-sig)# ! Make sure the event action is set to block the host: ! 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    normalizer    -----------------------------------------------       event-action: produce-alert|request-block-host default: produce-alert|deny -connection-inline       edit-default-sigs-only       -----------------------------------------------          default-signatures-only          -----------------------------------------------             specify-service-ports             -----------------------------------------------                no                -----------------------------------------------                -----------------------------------------------             -----------------------------------------------             specify-tcp-max-mss             -----------------------------------------------                no                -----------------------------------------------                -----------------------------------------------             -----------------------------------------------             specify-tcp-min-mss             -----------------------------------------------                no                -----------------------------------------------                ----------------------------------------------- --MORE-- ! Exit signature definition submode sensor(config-sig-sig-nor)# exit sensor(config-sig-sig)# exit sensor(config-sig)# exit Apply Changes:?[yes]: Sensor# 

Note

If you want to receive alerts, you must always add produce-alert any time you configure the event actions.

Master Blocking is Not Working

Troubleshooting for Master Blocking Sensor is very similar to blocking sensor troubleshooting. Hence the discussion in the preceding sections also applies to the master blocking sensor. This section explains additional specifics pertaining to the master blocking sensor which should be used in addition to the blocking troubleshooting.

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. Be sure that the forwarding sensor is set up as a TLS trusted host if the remote master blocking sensor is using TLS for web access.

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

Step 1.

View the Network Access Controller's statistics on the sensor that is configured to forward the blocking to the master blocking sensor, and verify that the master blocking sensor entries are in the statistics as shown in Example 14-44. Example 14-44. Network Access Statistics on the Sensor Forwarding Blocking Request sensor# show statistics network-access Current Configuration AllowSensorShun = false ShunMaxEntries = 250 MasterBlockingSensor SensorIp = 10.89.149.46 SensorPort = 443 UseTls = 1 State ShunEnable = true ShunnedAddr Host IP = 122.122.122.44 ShunMinutes = 60 MinutesRemaining = 59 Sensor#

Step 2.

If the master blocking sensor does not show up in the statistics, you need to add it (see the Configuration section for more details).

TCP Reset Issues

TCP reset is another response that the IPS sensor can provide to an event in both Inline and Promiscuous mode. Work through the following steps to troubleshoot the issues pertaining to TCP reset on the IPS sensor:

Step 1.	Be sure that the TCP reset is working You can verify that the TCP reset is working or not by executing show events alert as shown in Example 14-45. Example 14-45. The Output of the show events alert Command sensor# show events alert evAlert: eventId=1047575239898467370 severity=medium originator: hostId: sj_4250_40 appName: sensorApp appInstanceId: 1004 signature: sigId=20000 sigName=STRING.TCP subSigId=0 version=Unknown addr: locality=OUT 172.16.171.19 port: 32771 victim: addr: locality=OUT 172.16.171.13 port: 23 actions: ! Following line indicates that the TCP reset sent is set to TRUE tcpResetSent: true sensor#
Step 2.	Be sure that the correct alarms are being generated as shown in Example 14-45. If the correct alarm is not being generated, the most probable cause of the problem is that the signature is not enabled. Enable the specific signature to resolve the problem.
Step 3.	Be sure that TCP resets are being sent with the help of the tcpdump command, as shown in Example 14-46. Example 14-46. TCP Reset Is Working 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
Step 4.	TCP Reset is not occurring for a signature. If the reset is not occurring for a specific signature, it is most likely that the TCP reset is not being set for the signature. Configure event-action to be TCP reset as shown in Example 14-47. Example 14-47. Checking if TCP Reset Is Configured and Configuring TCP Reset for a Specific Signature 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 atomic-ip ----------------------------------------------- event-action: produce-alert|reset-tcp-connection default: produce-alert fragment-status: any <defaulted> specify-l4-protocol ----------------------------------------------- no ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- specify-ip-payload-length ----------------------------------------------- no ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- specify-ip-header-length ----------------------------------------------- no ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- specify-ip-tos ----------------------------------------------- --MORE-- sensor(config-sig-sig-ato)# exit sensor(config-sig-sig)# exit sensor(config-sig)# exit Apply Changes:?[yes]:
Step 5.	If the reset is not working for any signature, but the signature event-action is configured for TCP reset, be sure the switch is allowing incoming TCP reset packets from the sensor on the port where the sniffing port is connected. (Refer to the "Case Studies" section of this chapter for additional details.)
Step 6.	Some switches do not allow incoming packets on SPAN destination ports. This is necessary if you wish to use TCP Reset. The third interface on the IDS-4250-XL and IDSM-2 can allow you to work around this problem by having a non-SPAN port send the TCP RST packets. However, be sure that the reset port is connected to the same switch as the sniffing ports of the XL card. If the sniffing ports are access ports (single VLAN), the reset port should be configured to be in the same VLAN. Note that if the 2 XL ports are access ports for different VLANs, the reset port can only be configured for one of these VLANs; use dot1q trunk ports to overcome this limitation. If the sniffing ports are Dot1q trunk ports (multi-VLAN), the sniffing ports and reset ports all must have the same Native VLAN, and the reset port must trunk all of the VLANs being trunked by both sniffing ports.

Inline IPS Issues

This section presents configuration steps and troubleshooting steps with the Inline IPS Sensor mode.

Configuration Steps

To configure Inline mode for an IPS Sensor, you must configure the switch and the sensor. You can either use CLI or IDM/IPS MC to configure Inline mode on the sensor. It is advisable to configure the switch first and then the sensor. In this section, you will use IDSM-2 for the Inline mode configuration. However, the configuration steps for the Sensor Appliance are the same. The only difference is that the port used for different VLANs for the IDSM-2 is within the switch itself. For Sensor appliances, these ports are the physical ports. This section explains how to configure the following switch running Catalyst software, in addition to Cisco IOS software and the sensor itself.

• Switch configuration running Catalyst software

• Switch configuration running Cisco IOS software

• IPS sensor configuration

Switch Configuration Running Catalyst Software

Configure IDSM-2 monitoring ports as trunk ports for inline operation for Catalyst software 8.4(1) or later with Supervisor Engine 1a, Supervisor Engine 2, Supervisor Engine 32, or Supervisor Engine 720. Because the native VLAN is the same as the sole VLAN being trunked, the traffic is not 802.1q encapsulated.

Caution

The default configuration for IDSM-2 ports 7 and 8 is to trunk all VLANs 1 to 4094. If you clear the IDSM-2 configuration (clear configuration module_number), IDSM-2 will be trunking all VLANs. If the IDSM-2 interfaces are configured for inline, spanning tree loops will likely be created and a storm will occur. A storm occurs when numerous packets loop and never reach their destinations.

To configure the monitoring ports on IDSM-2 for inline mode, work through the following steps:

Step 1.	Log in to the console of the switch.
Step 2.	Enter privileged mode with the following command: cat6k> enable
Step 3.	Set the native VLAN for each IDSM-2 monitoring port with the following command: cat6k (enable)> set vlan vlan_number slot_number/port_number As an example, the following two lines show that sniffing ports 5/7 and 5/8 are mapped to VLANs 500 and 550 respectively. cat6k (enable)> set vlan 500 5/7 cat6k (enable)> set vlan 550 5/8 Note that for the IDSM-2 blade, the sniffing ports are slot/7 and slot/8. If you connect your Sensor Appliance to the switch, you need to map these connected ports to the respective VLANs. Although for IDSM-2, the ports are fixed based on the slot number where the blade is inserted, Sensor sniffing interfaces can be connected to any ports you choose.
Step 4.	Clear all VLANs from each IDSM-2 monitoring port except for the native VLAN on each port (500 for port 7 and 550 on port 8) using the following command: cat6k (enable)> clear trunk slot_number/port_number vlan_range For this specific example, use the following commands to clear the trunk for all other VLANs except the native ones for the respected ports: cat6k (enable)> clear trunk 5/7 1-499,501-4094 cat6k (enable)> clear trunk 5/8 1-549,551-4094
Step 5.	Enable Bpdu spantree filtering on the IDSM-2 monitoring ports using the following command: cat6k (enable)> set spantree bpdu-filter 5/7-8 enable

Switch Configuration Running Cisco IOS Software

Configure the IDSM-2 (if Sensor, use the sensing ports connected to the switch) monitoring ports as access ports for inline operation. Note that Etherchannelling inline IDSM-2 is not yet supported in Cisco IOS. Cisco IOS software 12.2(18) SXE with Supervisor Engine 720 supports only one IDSM-2 inline between two VLANs.

Work through the following steps to configure VLANs for the Inline mode:

Step 1.	Log in to the switch console.
Step 2.	Enter configuration mode using the following command: router# configure terminal
Step 3.	Create two VLANs, one for each side of the inline IDSM-2 with the following commands: router(config)# vlan vlan_number router(config)# name vlan_name router(config)# exit router# exit
Step 4.	If you have not done so already, configure an IOS access port for each interface on each inline VLAN: Enter global configuration mode with the following command: router# configure terminal Select the IOS interface to be configured with the following command: router(config)# interface interface_name Enter a description so that you know what the interface is for: router(config-if)# description description Configure the interface as a Layer 2 switch port: router(config-if)# switchport Configure the access mode VLAN: router(config-if)# switchport access vlan vlan_number Configure the interface/port to be an access port: router(config-if)# switchport mode access Exit global configuration mode: router(config-if)# exit router# exit
Step 5.	Configure one IDSM-2 data port to be on each of the two VLANs you created in Step 3. router# configure terminal router(config)# intrusion-detection module slot_number data-port data_port_number access-vlan vlan_number router(config)# exit
Step 6.	Verify the configuration with the following steps. In these examples, the IDSM-2 in slot 5 is inline between VLANs 500 and 550. The IDSM-2 data port 1 is on VLAN 500 and data port 2 is on VLAN 550 Verify the IDSM-2 intrusion detection settings: router# show run | include intrusion-detection intrusion-detection module 5 management-port access-vlan 100 intrusion-detection module 5 data-port 1 access-vlan 500 intrusion-detection module 5 data-port 2 access-vlan 550 router# Verify that the IDSM-2 data port 1 is an access port on VLAN 500: router# show intrusion-detection module slot_number data-port data_port_number state For this example, use the following command: router# show intrusion-detection module 5 data-port 1 state Intrusion-detection module 5 data-port 1: Switchport: Enabled Administrative Mode: static access Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 500 (inline-vlan-1) Trunking Native Mode VLAN: 1 (default) Trunking VLANs Enabled: NONE Pruning VLANs Enabled: 2-1001 Vlans allowed on trunk:500 Vlans allowed and active in management domain: 500 Vlans in spanning tree forwarding state and not pruned: 500 Administrative Capture Mode: Disabled Administrative Capture Allowed-vlans: <empty> Verify the VLAN number: router# show vlan id vlan_number For this specific example use the following command: router# show vlan id 500 VLAN Name Status Ports ------- ---------------------------- --------- ----------------------- 500 engineering active Gi3/2, Gi13/d1 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ------- ---- ---------- ----- ------ ------ -------- ---- -------- --- 500 enet 100661 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ---------------------------------- router#

IPS Sensor Configuration

Once you have finished with switch configuration, the next step is to configure the sensor (in this case IDSM-2 blade) for Inline mode. Work through the following configuration steps to accomplish this task:

Step 1.	Log in to the CLI using an account with administrator privileges.
Step 2.	Enter interface submode: sensor# configure terminal sensor(config)# service interface
Step 3.	Name the inline pair: sensor(config-int)# inline-interfaces PAIR_ENGINEERING
Step 4.	Configure the two interfaces into a pair: sensor(config-int-inl)# interface1 GigabitEthernet0/7 sensor(config-int-inl)# interface2 GigabitEthernet0/8
Step 5.	Add a description of the interface pair: sensor(config-int-inl)# description PAIR_ENGINEERING = Gig0/7 & Gig0/8
Step 6.	Verify the settings: sensor(config-int-inl)# show settings name: PAIR_ENGINEERING ----------------------------------------------- description: PAIR_ENGINEERING = Gig0/7 & Gig0/8 default: interface1: GigabitEthernet0/7 interface2: GigabitEthernet0/8 -----------------------------------------------
Step 7.	Exit inline interfaces submode: sensor(config-int-inl)# exit sensor(config-int)# exit Apply Changes:?[yes]:
Step 8.	Press Enter to apply the changes, or type no to discard them.
Step 9.	Enter analysis engine mode to assign the interfaces to the virtual sensor: sensor# configure terminal ssensor(config)# service analysis-engine sensor(config-ana)# virtual-sensor vs0 sensor(config-ana-vir)# logical-interface PAIR_ENGINEERING
Step 10.	Exit analysis engine mode: sensor(config-ana-vir)# exit sensor(config-ana)# exit sensor(config)# Apply Changes:?[yes]:
Step 11.	Press Enter to apply the changes or type no to discard them.

Troubleshooting Steps

Troubleshooting connectivity issues, signature generation issues, TCP Reset issues, blocking issues, and so on that were discussed for Promiscuous mode are the same for Inline mode. This section explains some of the problems that you might encounter with the Inline mode only:

• Misconfiguration of the switch If the switch VLANs are not configured correctly, traffic might not be going through the sensor. This will result in the traffic not being analyzed.

• Promiscuous Mode Before deploying the sensor using Inline mode, it is strongly recommended that you run the sensor in Promiscuous mode to determine the amount of traffic and events that are being generated. This can be useful to eliminate the false positive or false negative. Keep in mind that Inline mode will have more performance impact than the Promiscuous mode. So, you should rate the sensor accordingly.

• Bypass Mode If you have packet drops, or the performance degrades to an unacceptable level, analyze the statistics using the show statistics virtual-sensor command. Enable the bypass mode so that you know whether there is a hardware or software issue. If with bypass mode, you are having performance or packet drops issues, you are running into a hardware problem. Otherwise, you are dealing with a software issue, in particular AnalysisEngine. So, search for a possible bug on Cisco.com (using the bug tool kit, at: http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl) or upgrade to the latest version of IPS Sensor. To enable bypass mode, see Example 14-48:

Example 14-48. Configuring Bypass Mode on the Sensor Running Inline Mode

sensor# configure terminal sensor(config)# service interface sensor(config-int)# bypass-mode on sensor1-23(config-int)# exit Apply Changes:?[yes]: Warning: Setting bypass-mode to on caused all intrusion-prevention packet inspection   to be disabled. sensor1-23(config)# exit sensor1-23# 

Remember that if you set the bypass-mode, the AnalysisEngine is bypassed completely; hence the sensor does not enforce any security. So be sure to change the bypass-mode back to auto once troubleshooting is performed, or turn on Promiscuous mode if Inline mode drops packets or causes performance problems that are unacceptable. This will give Cisco Systems, Inc. time to perform analysis and come up with a permanent fix.