Cisco Intrusion Prevention System Sensor CLI Configuration Guide for IPS 7.2
Setting Up the Sensor
Downloads: This chapterpdf (PDF - 654.0KB) The complete bookPDF (PDF - 8.57MB) | Feedback

Table of Contents

Setting Up the Sensor

Setup Notes and Caveats

Understanding Sensor Setup

Changing Network Settings

Changing the Hostname

Changing the IP Address, Netmask, and Gateway

Enabling and Disabling Telnet

Changing the Access List

Changing the FTP Timeout

Adding a Login Banner

Configuring the DNS and Proxy Servers for Global Correlation and Automatic Update

Enabling SSHv1 Fallback

Changing the CLI Session Timeout

Changing Web Server Settings

Configuring Authentication and User Parameters

Adding and Removing Users

Configuring Authentication

Configuring Packet Command Restriction

Creating the Service Account

The Service Account and RADIUS Authentication

RADIUS Authentication Functionality and Limitations

Configuring Passwords

Changing User Privilege Levels

Showing User Status

Configuring the Password Policy

Locking User Accounts

Unlocking User Accounts

Configuring Time

Time Sources and the Sensor

Synchronizing IPS Module System Clocks with the Parent Device System Clock

Correcting Time on the Sensor

Configuring Time on the Sensor

Displaying the System Clock

Manually Setting the System Clock

Configuring Recurring Summertime Settings

Configuring Nonrecurring Summertime Settings

Configuring Time Zones Settings

Configuring NTP

Configuring a Cisco Router to be an NTP Server

Configuring the Sensor to Use an NTP Time Source

Configuring SSH

Understanding SSH

Adding Hosts to the SSH Known Hosts List

Adding Authorized RSA1 and RSA2 Keys

Generating the RSA Server Host Key

Configuring TLS

Understanding TLS

Adding TLS Trusted Hosts

Displaying and Generating the Server Certificate

Installing the License Key

Understanding the License Key

Service Programs for IPS Products

Obtaining and Installing the License Key

Licensing the ASA 5500-X IPS SSP

Uninstalling the License Key

Setup Notes and Caveats

The following notes and caveats apply to setting up the sensor:

  • By default SSHv2 is enabled and SSHv1 is disabled.
  • When updating the hostname, the CLI prompt of the current session and other existing sessions is not updated with the new hostname immediately. Subsequent CLI login sessions reflect the new hostname in the prompt.
  • Slashes are now valid for hostnames, for example, firewall5/ips.
  • Telnet is not a secure access service and therefore is disabled by default on the sensor. However, SSH is always running on the sensor and it is a secure service.
  • For automatic and global correlation updates to function, you must have either a DNS server or an HTTP proxy server configured at all times.
  • DNS resolution is supported for accessing the global correlation update server as well as www.cisco.com for automatic updates.
  • The default web server port is 443 if TLS is enabled and 80 if TLS is disabled.
  • The username command provides username and password authentication for login purposes only. You cannot use this command to remove a user who is logged in to the system. You cannot use this command to remove yourself from the system.
  • You cannot use the privilege command to give a user service privileges. If you want to give an existing user service privileges, you must remove that user and then use the username command to create the service account.
  • Do not make modifications to the sensor through the service account except under the direction of TAC. If you use the service account to configure the sensor, your configuration is not supported by TAC. Adding services to the operating system through the service account affects proper performance and functioning of the other IPS services. TAC does not support a sensor on which additional services have been added.
  • You should carefully consider whether you want to create a service account. The service account provides shell access to the system, which makes the system vulnerable. However, you can use the service account to create a password if the administrator password is lost. Analyze your situation to decide if you want a service account existing on the system.
  • Administrators may need to disable the password recovery feature for security reasons.
  • We recommend that you use an NTP server to regulate time on your sensor. You can use authenticated or unauthenticated NTP. For authenticated NTP, you must obtain the NTP server IP address, NTP server key ID, and the key value from the NTP server. You can set up NTP during initialization or you can configure NTP through the CLI, IDM, IME, or ASDM.
  • In addition to a valid Cisco.com username and password, you must also have a Cisco Services for IPS service contract before you can apply for a license key.

Understanding Sensor Setup

Setting up the sensor involves such tasks as changing sensor initialization information, adding and deleting users, configuring time and setting up NTP, creating a service account, configuring SSH and TLS, and installing the license key. You configured most of these settings when you initialized the sensor using the setup command.

For More Information

For more information on using the setup command to initialize the sensor, see Chapter3, “Initializing the Sensor”

Changing Network Settings

After you initialize your sensor, you may need to change some of the network settings that you configured when you ran the setup command. This section describes how to change network settings, and contains the following topics:

Changing the Hostname

Changing the FTP Timeout

Adding a Login Banner

Changing the Hostname


Note The CLI prompt of the current session and other existing sessions will not be updated with the new hostname. Subsequent CLI login sessions will reflect the new hostname in the prompt.



Note Slashes are now valid for hostnames, for example, firewall5/ips.


Use the host-name host_name command in the service host submode to change the hostname of the sensor after you have run the setup command. The default is sensor.

To change the sensor hostname, follow these steps:


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

Step 2 Enter network settings submode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Change the sensor hostname.

sensor(config-hos-net)# host-name firesafe
 

Step 4 Verify the new hostname.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2 default:
192.168.1.2/24,192.168.1.1
host-name: firesafe default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 5 To change the hostname back to the default setting, use the default form of the command.

sensor(config-hos-net)# default host-name
 

Step 6 Verify the change to the default hostname sensor.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2 default:
192.168.1.2/24,192.168.1.1
host-name: sensor <defaulted>
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 
 

Step 7 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 8 Press Enter to apply the changes or enter no to discard them.


 

Changing the IP Address, Netmask, and Gateway

Use the host-ip ip_address/netmask,default_gateway command in the service host submode to change the IP address, netmask, and default gateway after you have run the setup command. The default is 192.168.1.2/24,192.168.1.1.

The host-ip is in the form of IP Address/Netmask/Gateway: X.X.X.X/nn,Y.Y.Y.Y, where X.X.X.X specifies the sensor IP address as a 32-bit address written as 4 octets separated by periods where X = 0-255, nn specifies the number of bits in the netmask, and Y.Y.Y.Y specifies the default gateway as a 32-bit address written as 4 octets separated by periods where Y = 0-255.

To change the sensor IP address, netmask, and default gateway, follow these steps:


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

Step 2 Enter network settings mode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Change the sensor IP address, netmask, and default gateway.

sensor(config-hos-net)# host-ip 192.0.2.1/24,192.0.2.2
 

Note The default gateway must be in the same subnet as the IP address of the sensor or the sensor generates an error and does not accept the configuration change.


Step 4 Verify the new information.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2
default: 192.168.1.2/24,192.168.1.1
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
 

Step 5 To change the information back to the default setting, use the default form of the command.

sensor(config-hos-net)# default host-ip
 

Step 6 Verify that the host IP is now the default of 192.168.1.2/24,192.168.1.1.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.168.1.2/24,192.168.1.1 <defaulted>
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 7 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 8 Press Enter to apply the changes or enter no to discard them.


 

Enabling and Disabling Telnet


Caution Telnet is not a secure access service and therefore is disabled by default. However, SSH is always running on the sensor and it is a secure service.

Use the telnet-option {enabled | disabled} command in the service host submode to enable Telnet for remote access to the sensor. The default is disabled.

To enable or disable Telnet services, follow these steps:


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

Step 2 Enter network settings mode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Enable Telnet services.

sensor(config-hos-net)# telnet-option enabled
sensor(config-hos-net)#
 

Step 4 Verify that Telnet is enabled.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2
default: 192.168.1.2/24,192.168.1.1
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 5 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

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


Note To Telnet to the sensor, you must enable Telnet and configure the access list to allow the Telnet clients to connect.



 

For More Information

For the procedure for configuring the access list, see Changing the Access List.

Changing the Access List

Use the access-list ip_address/netmask command in the service host submode to configure the access list, the list of hosts or networks that you want to have access to your sensor. Use the no form of the command to remove an entry from the list. The default access list is empty.

The following hosts must have an entry in the access list:

  • Hosts that need to Telnet to your sensor.
  • Hosts that need to use SSH with your sensor.
  • Hosts, such as the IDM and the IME, that need to access your sensor from a web browser.
  • Management stations, such as the CSM, that need access to your sensor.
  • If your sensor is a master blocking sensor, the IP addresses of the blocking forwarding sensors must have an entry in the list.

To modify the access list, follow these steps:


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

Step 2 Enter network settings mode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Add an entry to the access list. The netmask for a single host is 32.

sensor(config-hos-net)# access-list 192.0.2.110/32
 

Step 4 Verify the change you made to the access-list.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.168.1.2/24,192.168.1.1 <defaulted>
host-name: sensor <defaulted>
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 2)
-----------------------------------------------
network-address: 10.1.9.0/24
-----------------------------------------------
network-address: 192.0.2.110/32
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
 

Step 5 Remove the entry from the access list.

sensor(config-hos-net)# no access-list 192.0.2.110/32
 

Step 6 Verify that the host is no longer in the list.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.168.1.2/24,192.168.1.1 <defaulted>
host-name: sensor <defaulted>
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 10.1.9.0/24
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 7 Change the value back to the default.

sensor(config-hos-net)# default access-list
 

Step 8 Verify the value has been set back to the default.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.168.1.2/24,192.168.1.1 <defaulted>
host-name: sensor <defaulted>
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 0)
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 9 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 10 Press Enter to apply the changes or enter no to discard them.


 

Changing the FTP Timeout


Note You can use the FTP client for downloading updates and configuration files from your FTP server.


Use the ftp-timeout command in the service host submode to change the number of seconds that the FTP client waits before timing out when the sensor is communicating with an FTP server. The default is 300 seconds.

To change the FTP timeout, follow these steps:


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

Step 2 Enter network settings mode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Change the number of seconds of the FTP timeout.

sensor(config-hos-net)# ftp-timeout 500
 

Step 4 Verify the FTP timeout change.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2
default: 192.168.1.2/24,192.168.1.1
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 500 seconds default: 300
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 5 Change the value back to the default.

sensor(config-hos-net)# default ftp-timeout
 

Step 6 Verify the value has been set back to the default.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2
default: 192.168.1.2/24,192.168.1.1
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
-----------------------------------------------
sensor(config-hos-net)#
 

Step 7 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 8 Press Enter to apply the changes or enter no to discard them.


 

Adding a Login Banner

Use the login-banner-text text_message command to add a login banner that the user sees during login. There is no default. When you want to start a new line in your message, press Ctrl-V Enter .

To add a login banner, follow these steps:


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

Step 2 Enter network settings mode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Add the banner login text.

sensor(config-hos-net)# login-banner-text This is the banner login text message.
 

Step 4 Verify the banner login text message.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2
default: 192.168.1.2/24,192.168.1.1
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: This is the banner login text message. default:
-----------------------------------------------
sensor(config-hos-net)#
 

Step 5 To remove the login banner text, use the no form of the command.

sensor(config-hos-net)# no login-banner-text
 

Step 6 Verify the login text has been removed.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 192.0.2.1/24,192.0.2.2
default: 192.168.1.2/24,192.168.1.1
host-name: sensor default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: default:
-----------------------------------------------
sensor(config-hos-net)#
 

Step 7 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 8 Press Enter to apply the changes or enter no to discard them.


 

Configuring the DNS and Proxy Servers for Global Correlation and Automatic Update

Use the http-proxy , dns-primary-server , dns-secondary-server , and dns-tertiary-server commands in network-settings submode to configure servers to support the automatic update and global correlation features.

You must configure either an HTTP proxy server or DNS server to support automatic update and global correlation. You may need a proxy server to download automatic update and global correlation updates if you use proxy in your network. If you are using a DNS server, you must configure at least one DNS server and it must be reachable for automatic update and global correlation updates to be successful. You can configure other DNS servers as backup servers. DNS queries are sent to the first server in the list. If it is unreachable, DNS queries are sent to the next configured DNS server.


Caution For automatic and global correlation updates to function, you must have either a DNS server or an HTTP proxy server configured at all times.


Caution DNS resolution is supported for accessing the global correlation update server as well as www.cisco.com for automatic updates.

The following parameters apply:

  • http-proxy {no-proxy | proxy-sensor} —Configures the HTTP proxy server:

address ip_address —Specifies the IP address of the HTTP proxy server.

port port_number —Specifies the port number of the HTTP proxy server.

  • dns-primary-server {enabled | disabled} —Enables a DNS primary server:

address ip_address —Specifies the IP address of the DNS primary server.

  • dns-secondary-server {enabled | disabled} —Enables a DNS secondary server:

address ip_address —Specifies the IP address of the DNS secondary server.

  • dns-tertiary-server {enabled | disabled} —Enables the DNS tertiary server:

address ip_address —Specifies the IP address of the DNS tertiary server.

Configuring DNS and Proxy Servers for Automatic Update and Global Correlation

To configure DNS and proxy servers to support automatic update and global correlation, follow these steps:


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

Enter network settings submode.
sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 
Enable a proxy or DNS server to support global correlation:

a. Enable a proxy server.

sensor(config-hos-net)# http-proxy proxy-server
sensor(config-hos-net-pro)# address 10.10.10.1
sensor(config-hos-net-pro)# port 65
sensor(config-hos-net-pro)#
 

b. Enable a DNS server.

sensor(config-hos-net)# dns-primary-server enabled
sensor(config-hos-net-ena)# address 10.10.10.1
sensor(config-hos-net-ena)#
 
Verify the settings.
sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 10.89.147.24/25,10.89.147.126 default: 192.168.1.2/24,192.168.1.1
host-name: sensor <defaulted>
telnet-option: enabled default: disabled
sshv1-fallback: disabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: <defaulted>
dns-primary-server
-----------------------------------------------
enabled
-----------------------------------------------
address: 10.10.10.1
-----------------------------------------------
-----------------------------------------------
dns-secondary-server
-----------------------------------------------
disabled
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
dns-tertiary-server
-----------------------------------------------
disabled
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
http-proxy
-----------------------------------------------
proxy-server
-----------------------------------------------
address: 10.10.10.1
port: 65
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
sensor(config-hos-net)#
 

Step 5 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

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


 

For More Information

Enabling SSHv1 Fallback


Note The IPS supports managing both SSHv1 and SSHv2. The default is SSHv2, but you can configure the sensor to fallback to SSHv1 if the peer client/server does not support SSHv2


Use the sshv1-fallback {enabled | disabled} command in the service host submode to enable the sensor to fall back to SSH protocol version 1. Fallback to SSHv1 is provided in case the peer client/server does not support SSHv2. SSHv2 is the default SSH version.

To enable or disable SSHv1 fallback, follow these steps:


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

Step 2 Enter network settings mode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# network-settings
 

Step 3 Enable Telnet services.

sensor(config-hos-net)# sshv1-fallback enabled
sensor(config-hos-net)#
 

Step 4 Verify that SSHv1 fallback is enabled.

sensor(config-hos-net)# show settings
network-settings
-----------------------------------------------
host-ip: 10.106.164.52/24,10.106.164.1 default: 192.168.1.2/24,192.168.1.1
host-name: p32-ips4240-52 default: sensor
telnet-option: enabled default: disabled
sshv1-fallback: enabled default: disabled
access-list (min: 0, max: 512, current: 1)
-----------------------------------------------
network-address: 0.0.0.0/0
-----------------------------------------------
-----------------------------------------------
ftp-timeout: 300 seconds <defaulted>
login-banner-text: mmmm default:
sensor(config-hos-net)#
 

Step 5 Exit network settings mode.

sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

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


 

For More Information

For more information about configuring SSH, see Configuring SSH.

Changing the CLI Session Timeout

Use the cli-inactivity-timeout command in the service authentication submode to change the number of seconds that the CLI waits before timing out. Setting the CLI session timeout increases the security of a CLI session. The default is 0 seconds, which means that it is an unlimited value and thus will never time out. The valid range is 0 to 100,000 minutes.

To change the CLI session timeout, follow these steps:


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

Step 2 Enter authentication mode.

sensor# configure terminal
sensor(config)# service authentication
 

Step 3 Change the number of seconds of the CLI session timeout.

sensor(config-aut)# cli-inactivity-timeout 5000
 

Step 4 Verify the CLI session timeout change.

sensor(config-aut)# show settings
attemptLimit: 0 <defaulted>
password-strength
-----------------------------------------------
size: 8-64 <defaulted>
digits-min: 0 <defaulted>
uppercase-min: 0 <defaulted>
lowercase-min: 0 <defaulted>
other-min: 0 <defaulted>
number-old-passwords: 0 <defaulted>
-----------------------------------------------
permit-packet-logging: true <defaulted>
cli-inactivity-timeout: 5000 default: 0
sensor(config-aut)#
 

Step 5 Change the value back to the default.

sensor(config-aut)# default cli-inactivity-timeout
 

Step 6 Verify the value has been set back to the default.

sensor(config-aut)# show settings
attemptLimit: 0 <defaulted>
password-strength
-----------------------------------------------
size: 8-64 <defaulted>
digits-min: 0 <defaulted>
uppercase-min: 0 <defaulted>
lowercase-min: 0 <defaulted>
other-min: 0 <defaulted>
number-old-passwords: 0 <defaulted>
-----------------------------------------------
permit-packet-logging: true <defaulted>
cli-inactivity-timeout: 0 <defaulted>
sensor(config-aut)#
 

Step 7 Exit authentication mode.

sensor(config-aut)# exit
Apply Changes:?[yes]:
 

Step 8 Press Enter to apply the changes or enter no to discard them.


 

Changing Web Server Settings


Note The default web server port is 443 if TLS is enabled and 80 if TLS is disabled.


After you run the setup command, you can change the following web server settings: the web server port, whether TLS encryption is being used, the HTTP server header message, restriction of TLS client ciphers, web session inactivity timeout, and logging of web session inactivity timeouts.

HTTP is the protocol that web clients use to make requests from web servers. The HTTP specification requires a server to identify itself in each response. Attackers sometimes exploit this protocol feature to perform reconnaissance. If the IPS web server identified itself by providing a predictable response, an attacker might learn that an IPS sensor is present.

We recommend that you not reveal to attackers that you have an IPS sensor. Change the server-id to anything that does not reveal any information, especially if your web server is available to the Internet. For example, if you forward a port through a firewall so you can monitor a sensor remotely, you need to set the server-id .

The following parameters apply:

  • enable-tls {false | true} —Enables encryption (TLSv1) on the system. The default is enabled.
  • enable-websession-inactivity-timeout-logging {false | true} —Enables logging for web session inactivity timeouts. The default is disabled.
  • port port_number —Specifies the port on which the web server listens for connections. The valid range is 1 to 65535. The default is 443.
  • server-id server_id —Specifies the textual message the web server returns in the HTTP Server header. The default is HTTP/1.1 compliant configurable-service.
  • tls-client-ciphers-restriction {false | true} —Enables the client to use only restricted mode ciphers; disabling allows all ciphers. The default is enabled. When IPS acts as a TLS client, you can configure restriciton on the TLS ciphers.

Note Changes take place for the next sessions only. The current web session is not affected.


When enabled, the client can use the following restricted ciphers:

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

When disabled, the client can use the following ciphers:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

TLS_DHE_RSA_WITH_AES_256_CBC_SHA

TLS_DHE_DSS_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDH_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_DHE_DSS_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

  • websession-inactivity-timeout seconds —Specifies the duration in seconds at which inactive web sessions time out. The valid range is 600 to 3600 seconds. The default is 3600 seconds.

To change the web server settings, follow these steps:


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

Step 2 Enter web server mode.

sensor# configure terminal
sensor(config)# service web-server
 

Step 3 Change the port number.

sensor(config-web)# port 8080
 

If you change the port number from the default of 443 to 8080, you receive this message:

Warning: The web server’s listening port number has changed from 443 to 8080. This change will not take effect until the web server is re-started
 

Step 4 Enable TLS.

sensor(config-web)# enable-tls true
 

If you disable TLS, you receive this message:

Warning: TLS protocol support has been disabled. This change will not take effect until the web server is re-started.
 

Step 5 Change the HTTP server header.

sensor(config-web)# server-id Nothing to see here. Move along.
 

Step 6 Specify the web session inactivity timeout.

sensor(config-web)# websession-inactivity-timeout 800
 

Step 7 Turn on logging for web session inactivity timeouts.

sensor(config-web)# enable-websession-inactivity-timeout-logging true
 

Step 8 Turn on TLS client ciphers restriction.

sensor(config-web)# tls-client-ciphers-restriction enable
 

Step 9 Verify the web server changes.

sensor(config-web)# show settings
enable-tls: true default: true
port: 8080 default: 443
server-id: Nothing to see here. Move along. default: HTTP/1.1 compliant
configurable-service (min: 0, max: 99, current: 0)
-----------------------------------------------
-----------------------------------------------
websession-inactivity-timeout: 800 default: 3600
enable-websession-inactivity-timeout-logging: true default: false
tls-client-ciphers-restriction: enable default: enable
sensor(config-web)#
 

Step 10 To revert to the defaults, use the default form of the commands.

sensor(config-web)# default port
sensor(config-web)# default enable-tls
sensor(config-web)# default server-id
 

Step 11 Verify the defaults have been replaced.

sensor(config-web)# show settings
enable-tls: true <defaulted>
port: 443 <defaulted>
server-id: HTTP/1.1 compliant <defaulted>
configurable-service (min: 0, max: 99, current: 0)
-----------------------------------------------
-----------------------------------------------
websession-inactivity-timeout: 3600 <defaulted>
enable-websession-inactivity-timeout-logging: false <defaulted>
tls-client-ciphers-restriction: enable <defaulted>
sensor(config-web)#
 

Step 12 Exit web server submode.

sensor(config-web)# exit
Apply Changes:?[yes]:
 

Step 13 Press Enter to apply the changes or enter no to discard them.


Note If you change the port or enable TLS settings, you must reset the sensor to make the web server uses the new settings.



 

For More Information

• For the procedure for enabling SSHv1 fallback, see Enabling SSHv1 Fallback.

• For the procedure for resetting the appliance, see Resetting the Appliance.

• For the procedure for resetting the ASA 5585-X IPS SSP, see Reloading, Shutting Down, Resetting, and Recovering the ASA 5585-X IPS SSP.

Configuring Authentication and User Parameters

The following section explains how to create users, configure RADIUS authentication, create the service account, configure passwords, specify privilege level, view a list of users, configure password policy, and lock and unlock user accounts. It contains the following topics:

Adding and Removing Users

Configuring Authentication

Configuring Packet Command Restriction

Configuring the Password Policy

Adding and Removing Users

Use the username command to create users on the local system. You can add a new user, set the privilege level—administrator, operator, viewer—and set the password for the new user. Use the no form of this command to remove a user from the system. This removes the user from CLI and web access.


Caution The username command provides username and password authentication for login purposes only. You cannot use this command to remove a user who is logged in to the system. You cannot use this command to remove yourself from the system.

If you do not specify a password, the system prompts you for one. Use the password command to change the password for existing users. Use the privilege command to change the privilege for existing users.

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

You receive the following error messages if you do not create a valid password:

Error: setEnableAuthenticationTokenStatus : The password is too short.

  • Error: setEnableAuthenticationTokenStatus : Failure setting the account’s password: it does not contain enough DIFFERENT characters

Note You cannot use the privilege command to give a user service privileges. If you want to give an existing user service privileges, you must remove that user and then use the username command to create the service account.


To add and remove users, follow these steps:


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

Step 2 Enter configuration mode.

sensor# configure terminal
 

Step 3 Specify the parameters for the user.

sensor(config)# username username password password privilege administrator/operator/viewer
 

For example, to add the user “tester” with a privilege level of administrator and the password “testpassword,” enter the following command:


Note If you do not want to see the password in clear text, wait for the password prompt. Do not enter the password along with the username and privilege.


sensor(config)# username tester privilege administrator
Enter Login Password: ************
Re-enter Login Password: ************
sensor(config)#
 

Note If you do not specify a privilege level for the user, the user is assigned the default viewer privilege.


Step 4 Verify that the user has been added. A list of users is displayed.

sensor(config)# exit
sensor# show users all
CLI ID User Privilege
* 13491 cisco administrator
jsmith operator
jtaylor service
jroberts viewer
sensor#
 

Step 5 To remove a user, use the no form of the command.

sensor# configure terminal
sensor(config)# no username jsmith
 

Note You cannot use this command to remove yourself from the system.


Step 6 Verify that the user has been removed. The user jsmith has been removed.

sensor(config)# exit
sensor# show users all
CLI ID User Privilege
* 13491 cisco administrator
jtaylor service
jroberts viewer
sensor#
 


 

For More Information

Configuring Authentication


Caution Make sure you have a RADIUS server already configured before you configure RADIUS authentication on the sensor. IPS has been tested with CiscoSecure ACS 4.2 and 5.1 servers. Refer to your RADIUS server documentation for information on how to set up a RADIUS server.

You can create and remove users from the local sensor. You can only modify one user account at a time. Each user is associated with a role that controls what that user can and cannot modify. The requirements that must be used for user passwords are set with the password command.

Users are authenticated through AAA either locally or through RADIUS servers. Local authentication is enabled by default. You must configure RADIUS authentication before it is active.

You must specify the user role that is authenticated through RADIUS either by configuring the user role on the RADIUS server or specifying a default user role. The username and password are sent in an authentication request to the configured RADIUS server. The response of the server determines whether the login is authenticated.


Note If the sensor is not configured to use a default user role and the sensor user role information in not in the Accept Message of the CiscoSecure ACS server, the sensor rejects RADIUS authentication even if the CiscoSecure ACS server accepts the username and password.


You can configure a primary RADIUS server and a secondary RADIUS server. The secondary RADIUS server authenticates and authorizes users if the primary RADIUS server is unresponsive.

You can also configure the sensor to use local authentication (local fallback) if no RADIUS servers are responding. In this case, the sensor authenticates against the locally configured user accounts. The sensor will only use local authentication if the RADIUS servers are not available, not if the RADIUS server rejects the authentication requests of the user. You can also configure how users connected through the console port are authenticated—through local user accounts, through RADIUS first and if that fails through local user accounts, or through RADIUS alone.

To configure a RADIUS server, you must have the IP address, port, and shared secret of the RADIUS server. You must also either have the NAS-ID of the RADIUS server, or have the RADIUS server configured to authenticate clients without a NAS-ID or with the default IPS NAS-ID of cisco-ips.


Note Enabling RADIUS authentication on the sensor does not disconnect already established connections. RADIUS authentication is only enforced for new connections to the sensor. Existing CLI, IDM, and IME connections remain established with the login credentials used prior to configuring RADIUS authentication. To force disconnection of these established connections, you must reset the sensor after RADIUS is configured.


RADIUS Authentication Parameters

Use the aaa command in service aaa submode to configure either local authentication or authentication using a RADIUS server.

The following parameters apply:

  • local —Lets you specify local authentication. To continue to create users, use the password command.
  • radius —Lets you specify RADIUS as the method of authentication:

nas-id —Identifies the service requesting authentication. The value can be no nas-id , cisco-ips , or a NAS-ID already configured on the RADIUS server. The default is cisco-ips .

default-user-role —Lets you assign a default user role on the sensor that is only applied when there is NOT a Cisco av pair specifying the user role. The value can be unspecified , viewer , operator , or administrator . Service cannot be the default user role. The default is unspecified .

If you do not want to configure a default user role on the sensor that is applied in the absence of a Cisco av pair, you need to configure the Cisco IOS/PIX 6.x RADIUS Attributes [009\001] cisco-av-pair under the group or user profile with one of the following options: ips-role=viewer , ips-role=operator , ips-role=administrator , ips-role=service, or ips-role=unspecified . The default is ips-role=unspecified .


Note If the sensor is not configured to use a default user role and the sensor user role information in not in the Accept Message of the CiscoSecure ACS server, the sensor rejects RADIUS authentication even if the CiscoSecure ACS server accepts the username and password.



Note The default user role is used only when the user has not been configured with a specific role on the ACS server. Local users are always configured with a specific role so the default user role will never apply to locally authenticated users.



Caution Do not add multiple Cisco av-pairs with the same key or you cannot log in. You must have only one instance of ips-role=value. For example, do not use the following configuration:
ips-role= administer
ips-role=ad

local-fallback {enabled | disabled} —Lets you default to local authentication if the RADIUS servers are not responding. The default is enabled .

  • primary-server —Lets you configure the main RADIUS server:

server-address —IP address of the RADIUS server.

server-port —Port of the RADIUS server. If not specified, the default RADIUS port is used.

timeout (seconds)—Specifies the number of seconds the sensor waits for a response from a RADIUS server before it considers the server to be unresponsive.

shared-secret —The secret value configured on the RADIUS server. You must obtain the secret value of the RADIUS server to enter with the shared-secret command.


Note You must have the same secret value configured on both the RADIUS server and the IPS sensor so that the server can authenticate the requests of the client and the client can authenticate the responses of the server.


  • secondary-server {enabled | disabled} (Optional) Lets you configure a secondary RADIUS server:

server-address —IP address of the RADIUS server.

server-port —Port of the RADIUS server. If not specified, the default RADIUS port is used.

timeout (seconds)—Specifies the number of seconds the sensor waits for a response from a RADIUS server before it considers the server to be unresponsive.

shared-secret —The secret value configured on the RADIUS server. You must obtain the secret value of the RADIUS server to enter with the shared-secret command.


Note You must have the same secret value configured on both the RADIUS server and the IPS sensor so that the server can authenticate the requests of the client and the client can authenticate the responses of the server.


  • console-authentication —Lets you choose how users connected through the console port are authenticated:

local —Users connected through the console port are authenticated through local user accounts.

radius-and-local —Users connected through the console port are authenticated through RADIUS first. If RADIUS fails, local authentication is attempted. This is the default.

radius —Users connected through the console port are authenticated by RADIUS. If you also have local-fallback enabled, users can also be authenticated through the local user accounts.

Configuring Local or RADIUS Authentication


Caution Make sure you have a RADIUS server already configured before you configure RADIUS authentication on the sensor. IPS has been tested with CiscoSecure ACS 4.2 and 5.1 servers. Refer to your RADIUS server documentation for information on how to set up a RADIUS server.


Note Enabling RADIUS authentication on the sensor does not disconnect already established connections. RADIUS authentication is only enforced for new connections to the sensor. Existing CLI, IDM, and IME connections remain established with the login credentials used prior to configuring RADIUS authentication. To force disconnection of these established connections, you must reset the sensor after RADIUS is configured.


To configure local or RADIUS AAA authentication on the sensor, follow these steps:


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

Step 2 Enter configuration mode.

sensor# configure terminal
 

Step 3 Enter AAA submode.

sensor(config)# service aaa
sensor(config-aaa)#
 

Step 4 Configure local authentication. To continue to create users on the local system, enter yes to save your configuration, and use the username command in configure terminal mode. To configure AAA RADIUS authentication, go to Step 5.

sensor(config-aaa)# aaa local
sensor(config-aaa)# exit
Apply Changes?[yes]:yes
 

Step 5 Configure AAA RADIUS authentication:

a. Enter RADIUS authentication submode.

sensor(config-aaa)# aaa radius
sensor(config-aaa-rad)#
 

b. Enter the Network Access ID. The NAS-ID is an identifier that clients send to servers to communicate the type of service they are attempting to authenticate. The value can be no nas-id , cisco-ips , or a NAS-ID already configured on the RADIUS server. The default is cisco-ips.

sensor(config-aaa-rad)# nas-id cisco-ips
sensor(config-aaa-rad)#
 

c. (Optional) Configure a default user role if you are not configuring a Cisco av pair. You can configure a default user role on the sensor that is only applied when there is NOT a Cisco av pair specifying the user role. The values are unspecified , viewer , operator , or administrator . The default is unspecified .

sensor(config-aaa-rad)# default-user-role operator
sensor(config-aaa-rad)#
 

Note Service cannot be the default role.


d. Configure a Cisco av pair. If you do not want to configure a default user role on the sensor that is applied in the absence of a Cisco av pair, you need to configure the Cisco IOS/PIX 6.x RADIUS Attributes [009\001] cisco-av-pair under the group or user profile with one of the following options:

ips-role=viewer

ips-role=operator

ips-role=administrator

ips-role=service


Note If the sensor is not configured to use a default user role and the sensor user role information in not in the Accept Message of the CiscoSecure ACS server, the sensor rejects RADIUS authentication even if the CiscoSecure ACS server accepts the username and password.



Note The default user role is used only when the user has not been configured with a specific role on the ACS server. Local users are always configured with a specific role so the default user role will never apply to locally authenticated users.



Caution Do not add multiple Cisco av-pairs with the same key or you cannot log in. You must have only one instance of ips-role=value. For example, do not use the following configuration:
ips-role= administer
ips-role=ad

e. Configure the sensor to switch over to local authentication if the RADIUS server becomes unresponsive.

sensor(config-aaa-rad)# local-fallback enabled
sensor(config-aaa-rad)#
 

Step 6 Configure the primary RADIUS server:

a. Enter primary server submode.

sensor(config-aaa-rad)# primary-server
sensor(config-aaa-rad-pri)#
 

b. Enter the RADIUS server IP address.

sensor(config-aaa-rad-pri)# server-address 10.1.2.3
sensor(config-aaa-rad-pri)#
 

c. Enter the RADIUS server port. If not specified, the default RADIUS port is used.

sensor(config-aaa-rad-pri)# server-port 1812
sensor(config-aaa-rad-pri)#
 

d. Enter the amount of time in seconds you want to wait for the RADIUS server to respond.

sensor(config-aaa-rad-pri)# time-out 5
sensor(config-aaa-rad-pri)#
 

e. Enter the secret value that you obtained from the RADIUS server. The shared secret is a piece of data known only to the parties involved in a secure communication.

sensor(config-aaa-rad-pri)# shared-secret kkkk
sensor(config-aaa-rad-pri)#
 

Note You must have the same secret value configured on both the RADIUS server and the IPS sensor so that the server can authenticate the requests of the client and the client can authenticate the responses of the server.


Step 7 (Optional) Enable a secondary RADIUS server to perform authentication in case the primary RADIUS server is not responsive:

a. Enter secondary server submode.

sensor(config-aaa-rad)# secondary-server enabled
sensor(config-aaa-rad-sec)#
 

b. Enter the IP address of the second RADIUS server.

sensor(config-aaa-rad-sec)# server-address 10.4.5.6
sensor(config-aaa-rad-sec)#
 

c. Enter the RADIUS server port. If not specified, the default RADIUS port is used.

sensor(config-aaa-rad-sec)# server-port 1812
sensor(config-aaa-rad-sec)#
 

d. Enter the amount of time in seconds you want to wait for the RADIUS server to respond.

sensor(config-aaa-rad-sec)# time-out 8
sensor(config-aaa-rad-sec)#
 

e. Enter the secret value you obtained for this RADIUS server. The shared secret is a piece of data known only to the parties involved in a secure communication.

sensor(config-aaa-rad-sec)# shared-secret yyyyy
sensor(config-aaa-rad-sec)#
 

Note You must have the same secret value configured on both the RADIUS server and the IPS sensor so that the server can authenticate the requests of the client and the client can authenticate the responses of the server.


Step 8 Specify the type of console authentication.

sensor(config-aaa-rad)# console-authentication radius-and-local
sensor(config-aaa-rad)#
 

You can choose local, local and RADIUS, or RADIUS.

Step 9 Verify the settings:

sensor(config-aaa-rad)# show settings
radius
-----------------------------------------------
primary-server
-----------------------------------------------
server-address: 10.1.2.3
server-port: 1812 <defaulted>
shared-secret: kkkk
timeout: 3 <defaulted>
-----------------------------------------------
secondary-server
-----------------------------------------------
enabled
-----------------------------------------------
server-address: 10.4.5.6
server-port: 1816 default: 1812
shared-secret: yyyyy
timeout: 8 default: 3
-----------------------------------------------
-----------------------------------------------
nas-id: cisco-ips default: cisco-ips
local-fallback: enabled default: enabled
console-authentication: radius-and-local <defaulted>
default-user-role: operator default: unspecified
-----------------------------------------------
sensor(config-aaa-rad)#
 

Step 10 Exit AAA mode.

sensor(config-aaa-rad)# exit
sensor(config-aaa)# exit
Apply Changes:?[yes]:
 

Step 11 Press Enter to apply the changes or enter no to discard them.


 

For More Information

Configuring Packet Command Restriction

Use the permit-packet-logging command to restrict the use of packet capture-related commands—packet capture/display and IP logging—for local and AAA RADIUS users. The default is to permit packet capture/display and IP log commands. Local users with the correct permissions can use the packet capture/display and IP log commands. AAA RADIUS users with the correct av-pair can use the packet capture/display and IP log commands.


Note IP log actions configured for signatures are not impacted by the packet command restriction feature.


When you modify the packet command restriction option, you receive the following warning:

Modified packet settings would take effect only for new sessions, existing sessions will continue with previous settings.
 

The following parameters apply:

  • permit-packet-logging true —Allows users to execute packet-related commands based on privilege level.
  • permit-packet-logging false —Restricts all users from executing any packet-related commands.

AAA RADIUS Users

AAA RADIUS users with the correct av-pair are authorized to execute packet capture/display and IP logging commands. RADIUS users with no av-pair value are restricted. The correct av-pair, permit-packet-logging=true , allows users to execute packet-related commands based on privilege level. This av-pair is in addition to the authentication role related av-pair:

  • ips-role=viewer
  • ips-role=operator
  • ips-role=administrator
  • ips-role=service

Status Events

As part of the packet command restriction option, status events are triggered for the following actions:

  • When an administrator enables or disables the packet command restriction.
  • When an authorized user executes any of the restricted commands.
  • When an unauthorized user executes any of the restricted commands.

To permit or restrict packet command restrictions, follow these steps:


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

Step 2 Enter authentication submode.

sensor# configure terminal
sensor(config)# service authentication
sensor(config-aut)#
 

Step 3 Allow AAA RADIUS users with the correct av-pair ( permit-packet-logging=true ) and local users with the correct privilege levels to execute all packet capture/display and IP log commands.

sensor(config-aut)# permit-packet-logging true
 

Note Existing CLI sessions are not affected by the changes made in restriction settings.


Step 4 Check your new setting.

sensor(config-aut)# show settings
attemptLimit: 0 <defaulted>
password-strength
-----------------------------------------------
size: 8-64 <defaulted>
digits-min: 0 <defaulted>
uppercase-min: 0 <defaulted>
lowercase-min: 0 <defaulted>
other-min: 0 <defaulted>
number-old-passwords: 0 <defaulted>
-----------------------------------------------
permit-packet-logging: true default: true
cli-inactivity-timeout: 0 <defaulted>
sensor(config-aut)#
 

Step 5 Restrict all users from executing packet capture/display and IP log commands.

sensor(config-aut)# permit-packet-logging false
 

Step 6 Check your new setting.

sensor(config-aut)# show settings
attemptLimit: 0 <defaulted>
password-strength
-----------------------------------------------
size: 8-64 <defaulted>
digits-min: 0 <defaulted>
uppercase-min: 0 <defaulted>
lowercase-min: 0 <defaulted>
other-min: 0 <defaulted>
number-old-passwords: 0 <defaulted>
-----------------------------------------------
permit-packet-logging: false default: true
cli-inactivity-timeout: 0 <defaulted>
sensor(config-aut)#
 

Step 7 Exit authentication mode.

sensor(config-aut)# exit
Apply Changes:?[yes]:
 

Step 8 Press Enter to apply the changes or enter no to discard them.


 

Creating the Service Account

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

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


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


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


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


To create the service account, follow these steps:


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

Step 2 Enter configuration mode.

sensor# configure terminal
 

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

sensor(config)# user username privilege service
 

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

Error: Only one service account may exist
 

Step 5 Exit configuration mode.

sensor(config)# exit
sensor#
 

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

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


 

The Service Account and RADIUS Authentication

If you are using RADIUS authentication and want to create and use a service account, you must create the service account both on your sensor and on the RADIUS server. You must use local authentication to access the service account on the sensor. The service account must be created manually as a local account on the sensor. Then when you configure RADIUS authentication, the service account must also be configured manually on the RADIUS server with the accept message set to ip-role=service.

When you log in to the service account, you are authenticated against both the sensor account and the RADIUS server account. By whatever method you use to access the service account—serial console port, direct monitor/keyboard (for sensors that support it), or a network connection, such as SSH or Telnet—you have to log in using local authentication.

RADIUS Authentication Functionality and Limitations

The current AAA RADIUS implementation has the following functionality and limitations:

  • Authentication with a RADIUS server—However, you cannot change the password of the RADIUS server from the IPS.
  • Authorization—You can perform role-based authorization by specifying the IPS role of the user on the RADIUS server.
  • Accounting—The login attempts of the user and the configuration changes are logged as events locally on the IPS. However, these account messages are not communicated to the RADIUS server.

Configuring Passwords

Use the password command to update the password on the local sensor. You can also use this command to change the password for an existing user or to reset the password for a locked account. For IPS 7.2(1)E4, a valid password is 8 to 32 characters long. For IPS 7.2(2)E4 and later, a valid password is 6 to 127 characters long. All characters except space are allowed.

To change the password, follow these steps:


Step 1 To change the password for another user or reset the password for a locked account, follow these steps:

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

b. Enter configuration mode.

sensor# configure terminal
 

c. Change the password for a specific user. This example modifies the password for the user “tester.”

sensor(config)# password tester
Enter New Login Password: ******
Re-enter New Login Password: ******
 

Step 2 To change your password, follow these steps:

a. Log in to the CLI.

b. Enter configuration mode.

sensor# configure terminal
 

c. Change your password.

sensor(config)# password
Enter Old Login Password:************
Enter New Login Password: ************
Re-enter New Login Password: ************
 


 

For More Information

For the procedures for recovering sensor passwords, see Recovering the Password.

Changing User Privilege Levels


Note You cannot use the privilege command to give a user service privileges. If you want to give an existing user service privileges, you must remove that user and then use the username command to create the service account. There can only be one person with service privileges.


Use the privilege command to change the privilege level—administrator, operator, viewer—for a user.

To change the privilege level for a user, follow these steps:


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

Step 2 Verify the current privilege of the user jsmith .

sensor# show users all
CLI ID User Privilege
* 13491 cisco administrator
jsmith viewer
operator operator
service service
viewer viewer
sensor#
 

Step 3 Change the privilege level from viewer to operator.

sensor# configure terminal
sensor(config)# privilege user jsmith operator
Warning: The privilege change does not apply to current CLI sessions. It will be applied to subsequent logins.
sensor(config)#
 

Step 4 Verify that the privilege of the user has been changed. The privilege of the user jsmith has been changed from viewer to operator .

sensor(config)# exit
sensor# show users all
 
CLI ID User Privilege
* 13491 cisco administrator
jsmith operator
operator operator
service service
viewer viewer
sensor#
 

Step 5 Display your current level of privilege.

sensor# show privilege
Current privilege level is administrator
 


 

For More Information

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

Showing User Status


Note All IPS platforms allow ten concurrent log in sessions.


Use the show users command to view information about the username and privilege of all users logged in to the sensor, and all user accounts on the sensor regardless of login status. An asterisk (*) indicates the current user. If an account is locked, the username is surrounded by parentheses. A locked account means that the user failed to enter the correct password after the configured attempts.

To show user information, follow these steps:


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

Step 2 Verify the users logged in to the sensor.

sensor# show users
CLI ID User Privilege
* 13491 cisco administrator
sensor#
 

Step 3 Verify all users. The account of the user jsmith is locked.

sensor# show users all
CLI ID User Privilege
* 13491 cisco administrator
5824 (jsmith) viewer
9802 tester operator
sensor#
 

Step 4 To unlock the account of jsmith, reset the password.

sensor# configure terminal
sensor(config)# password jsmith
Enter New Login Password: ******
Re-enter New Login Password: ******
 


 

Configuring the Password Policy

As sensor administrator, you can configure how passwords are created. All user-created passwords must conform to the policy that you set up. You can set login attempts and the size and minimum characters requirements for a password. The minimum password length is eight characters. If you forget your password, there are various ways to recover the password depending on your sensor platform.


Caution If the password policy includes minimum numbers of character sets, such as upper case or number characters, the sum of the minimum number of required character sets cannot exceed the minimum password size. For example, you cannot set a minimum password size of eight and also require that passwords must contain at least five lowercase and five uppercase characters.

Example

For example, you can set a policy where passwords must have at least 10 characters and no more than 40, and must have a minimum of 2 upper case and 2 numeric characters. Once that policy is set, every password configured for each user account must conform to this password policy.

To set up a password policy, follow these steps:


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

Step 2 Enter password strength authentication submode.

sensor# configure terminal
sensor(config)# service authentication
sensor(config-aut)# password-strength
 

Step 3 Set the minimum number of numeric digits that must be in a password. The range is 0 to 64.

sensor(config-aut-pas)# digits-min 6
 

Step 4 Set the minimum number of nonalphanumeric printable characters that must be in a password. The range is 0 to 64.

sensor(config-aut-pas)# other-min 3
 

Step 5 Set the minimum number of uppercase alphabet characters that must be in a password. The range is 0 to 64.

sensor(config-aut-pas)# uppercase-min 3
 

Step 6 Set the minimum number of lower-case alphabet characters that must be in a password.

sensor(config-aut-pas)# lowercase-min 3
 

Step 7 Set the number of old passwords to remember for each account. A new password cannot match any of the old passwords of an account.

sensor(config-aut-pas)# number-old-passwords 3
 

Step 8 Check your new setting.

sensor(config-aut-pas)# show settings
password-strength
-----------------------------------------------
size: 8-64 <defaulted>
digits-min: 6 default: 0
uppercase-min: 3 default: 0
lowercase-min: 3 default: 0
other-min: 3 default: 0
number-old-passwords: 3 default: 0
-----------------------------------------------
sensor(config-aut-pas)#
 


 

For More Information

For the procedures for recovering sensor passwords, see Recovering the Password.

Locking User Accounts


Note When you configure account locking, local authentication, as well as RADIUS authentication, is affected. After a specified number of failed attempts to log in locally or in to a RADIUS account, the account is locked locally on the sensor. For local accounts, you can reset the password or use the unlock user username command to unlock the account. For RADIUS user accounts, you must use the unlock user username command to unlock the account.



Note For RADIUS users, the attempt limit feature is enforced only after the RADIUS user’s first successful login to the sensor.


Use the attemptLimit number command in authentication submode to lock accounts so that users cannot keep trying to log in after a certain number of failed attempts. The default is 0, which indicates unlimited authentication attempts. For security purposes, you should change this number.

To configure account locking, follow these steps:


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

Step 2 Enter service authentication submode.

sensor# configure terminal
sensor(config)# service authentication
 

Step 3 Set the number of attempts users will have to log in to accounts.

sensor(config-aut)# attemptLimit 3
 

Step 4 Check your new setting.

sensor(config-aut)# show settings
attemptLimit: 3 defaulted: 0
sensor(config-aut)#
 

Step 5 Set the value back to the system default setting.

sensor(config-aut)# default attemptLimit
 

Step 6 Check that the setting has returned to the default.

sensor(config-aut)# show settings
attemptLimit: 0 <defaulted>
sensor(config-aut)#
 

Step 7 Check to see if any users have locked accounts. The account of the user jsmith is locked as indicated by the parentheses.


Note When you apply a configuration that contains a non-zero value for attemptLimit, a change is made in the SSH server that may subsequently impact your ability to connect with the sensor. When attemptLimit is non-zero, the SSH server requires the client to support challenge-response authentication. If you experience problems after your SSH client connects but before it prompts for a password, you need to enable challenge-response authentication. Refer to the documentation for your SSH client for instructions.


sensor(config-aut)# exit
sensor(config)# exit
sensor# show users all
CLI ID User Privilege
* 1349 cisco administrator
5824 (jsmith) viewer
9802 tester operator
 

Step 8 To unlock the account of jsmith, reset the password.

sensor# configure terminal
sensor(config)# password jsmith
Enter New Login Password: ******
Re-enter New Login Password: ******
 


 

For More Information

For the procedure for unlocking the user accounts, see Unlocking User Accounts.

Unlocking User Accounts

Use the unlock user username command in global configuration mode to unlock local and RADIUS accounts for users who have been locked out after a specified number of failed attempts.

To configure account unlocking, follow these steps:


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

Step 2 Check to see if any users have locked accounts. The account of the user jsmith is locked as indicated by the parentheses.

sensor# show users all
CLI ID User Privilege
* 1349 cisco administrator
5824 (jsmith) viewer
9802 tester operator
 

Step 3 Enter global configuration mode.

sensor# configure terminal
sensor(config)#
 

Step 4 Unlock the account.

sensor(config)# unlock user jsmith
 

Step 5 Check your new setting. The account of the user jsmith is now unlocked as indicated by the lack of parenthesis.

sensor# show users all
CLI ID User Privilege
* 1349 cisco administrator
5824 jsmith viewer
9802 tester operator
 


 

For More Information

For the procedure for locking the user accounts, see Locking User Accounts.

Configuring Time

This section describes the importance of having a reliable time source for the sensor. It contains the following topics:

Time Sources and the Sensor

Configuring Time on the Sensor

Time Sources and the Sensor


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


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

The IPS Standalone Appliances

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

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


The ASA IPS Modules

  • The ASA 5500-X IPS SSP and ASA 5585-X IPS SSP automatically synchronize their clocks with the clock in the adaptive security appliance in which they are installed. This is the default.
  • Configure them to get their time from an NTP time synchronization source, such as a Cisco router other than the parent router.

Synchronizing IPS Module System Clocks with the Parent Device System Clock

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

Correcting Time on the Sensor

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

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

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


Note You cannot remove individual events.


Configuring Time on the Sensor

This section describes how to configure time on the sensor so that your events are time-stamped correctly. It contains the following topics:

Displaying the System Clock

Configuring Nonrecurring Summertime Settings

Displaying the System Clock

Use the show clock [ detail ] command to display the system clock. You can use the detail option to indicate the clock source (NTP or system) and the current summertime setting (if any). The system clock keeps an authoritative flag that indicates whether the time is authoritative (believed to be accurate). If the system clock has been set by a timing source, such as NTP, the flag is set.

Table 4-1 lists the system clock flags.

 

Table 4-1 System Clock Flags

Symbol
Description

*

Time is not authoritative.

(blank)

Time is authoritative.

.

Time is authoritative, but NTP is not synchronized.

To display the system clock, follow these steps:


Step 1 Log in to the CLI.

Step 2 Display the system clock.

sensor# show clock
*19:04:52 UTC Thu Apr 03 2008
 

Step 3 Display the system clock with details. The following example indicates that the sensor is getting its time from NTP and that is configured and synchronized.

sensor# show clock detail
20:09:43 UTC Thu Apr 03 2011
Time source is NTP
Summer time starts 03:00:00 UTC Sun Mar 09 2011
Summer time stops 01:00:00 UTC Sun Nov 02 2011
 

Step 4 Display the system clock with details. The following example indicates that no time source is configured.

sensor# show clock detail
*20:09:43 UTC Thu Apr 03 2011
No time source
Summer time starts 03:00:00 UTC Sun Mar 09 2011
Summer time stops 01:00:00 UTC Sun Nov 02 2011
 


 

Manually Setting the System Clock


Note You do not need to set the system clock if your sensor is synchronized by a valid outside timing mechanism such as an NTP clock source.


Use the clock set hh:mm [:ss] month day year command to manually set the clock on the appliance. Use this command if no other time sources are available. The clock set command does not apply to the following platforms, because they get their time from the adaptive security appliance in which they are installed:

  • ASA 5500-X IPS SSP
  • ASA 5585-X IPS SSP

To manually set the clock on the appliance, follow these steps:


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

Step 2 Set the clock manually.

sensor# clock set 13:21 Mar 29 2011
 

Note The time format is 24-hour time.



 

Configuring Recurring Summertime Settings


Note Summertime is a term for daylight saving time.


Use the summertime-option recurring command to configure the sensor to switch to summertime settings on a recurring basis. The default is recurring.

To configure the sensor to switch to summertime settings on a recurring basis, follow these steps:


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

Step 2 Enter summertime recurring submode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# summertime-option recurring
 

Step 3 Enter start summertime submode.

sensor(config-hos-rec)# start-summertime
 

Step 4 Configure the start summertime parameters:

a. Enter the day of the week you want to start summertime settings.

sensor(config-hos-rec-sta)# day-of-week monday
 

b. Enter the month you want to start summertime settings.

sensor(config-hos-rec-sta)# month april
 

c. Enter the time of day you want to start summertime settings. The format is hh:mm:ss.

sensor(config-hos-rec-sta)# time-of-day 12:00:00
 

d. Enter the week of the month you want to start summertime settings. The values are first through fifth, or last.

sensor(config-hos-rec-sta)# week-of-month first
 

e. Verify your settings.

sensor(config-hos-rec-sta)# show settings
start-summertime
-----------------------------------------------
month: april default: april
week-of-month: first default: first
day-of-week: monday default: sunday
time-of-day: 12:00:00 default: 02:00:00
-----------------------------------------------
sensor(config-hos-rec-sta)#
 

Step 5 Enter end summertime submode.

sensor(config-hos-rec-sta)# exit
sensor(config-hos-rec)# end-summertime
 

Step 6 Configure the end summertime parameters:

a. Enter the day of the week you want to end summertime settings.

sensor(config-hos-rec-end)# day-of-week friday
 

b. Enter the month you want to end summertime settings.

sensor(config-hos-rec-end)# month october
 

c. Enter the time of day you want to end summertime settings. The format is hh:mm:ss.

sensor(config-hos-rec-end)# time-of-day 05:15:00
 

d. Enter the week of the month you want to end summertime settings. The values are first through fifth, or last.

sensor(config-hos-rec-end)# week-of-month last
 

e. Verify your settings.

sensor(config-hos-rec-end)# show settings
end-summertime
-----------------------------------------------
month: october default: october
week-of-month: last default: last
day-of-week: friday default: sunday
time-of-day: 05:15:00 default: 02:00:00
-----------------------------------------------
sensor(config-hos-rec-end)#
 

Step 7 Specify the local time zone used during summertime.

sensor(config-hos-rec-end)# exit
sensor(config-hos-rec)# summertime-zone-name CDT
 

Step 8 Specify the offset.

sensor(config-hos-rec)# offset 60
 

Step 9 Verify your settings.

sensor(config-hos-rec)# show settings
recurring
-----------------------------------------------
offset: 60 minutes default: 60
summertime-zone-name: CDT
start-summertime
-----------------------------------------------
month: april default: april
week-of-month: first default: first
day-of-week: monday default: sunday
time-of-day: 12:00:00 default: 02:00:00
-----------------------------------------------
end-summertime
-----------------------------------------------
month: october default: october
week-of-month: last default: last
day-of-week: friday default: sunday
time-of-day: 05:15:00 default: 02:00:00
-----------------------------------------------
-----------------------------------------------
 

Step 10 Exit recurring summertime submode.

sensor(config-hos-rec)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 11 Press Enter to apply the changes or enter no to discard them.


 

Configuring Nonrecurring Summertime Settings


Note Summertime is a term for daylight saving time.


Use the summertime-option non-recurring command to configure the sensor to switch to summer time settings on a one-time basis. The default is recurring.

To configure the sensor to switch to summertime settings on a one-time basis, follow these steps:


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

Step 2 Enter summertime non-recurring submode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# summertime-option non-recurring
 

Step 3 Enter start summertime submode.

sensor(config-hos-non)# start-summertime
 

Step 4 Configure the start summertime parameters:

a. Enter the date you want to start summertime settings. The format is yyyy-mm-dd.

sensor(config-hos-non-sta)# date 2004-05-15
 

b. Enter the time you want to start summertime settings. The format is hh:mm:ss.

sensor(config-hos-non-sta)# time 12:00:00
 

c. Verify your settings.

sensor(config-hos-non-sta)# show settings
start-summertime
-----------------------------------------------
date: 2004-05-15
time: 12:00:00
-----------------------------------------------
sensor(config-hos-non-sta)#
 

Step 5 Enter end summertime submode.

sensor(config-hos-non-sta)# exit
sensor(config-hos-non)# end-summertime
 

Step 6 Configure the end summertime parameters:

a. Enter the date you want to end summertime settings. The format is yyyy-mm-dd.

sensor(config-hos-non-end)# date 2004-10-31
 

b. Enter the time you want to end summertime settings. The format is hh:mm:ss.

sensor(config-hos-non-end)# time 12:00:00
 

c. Verify your settings.

sensor(config-hos-non-end)# show settings
end-summertime
-----------------------------------------------
date: 2004-10-31
time: 12:00:00
-----------------------------------------------
sensor(config-hos-non-end)#
 

Step 7 Specify the local time zone used during summertime.

sensor(config-hos-non-end)# exit
sensor(config-hos-non)# summertime-zone-name CDT
 

Step 8 Specify the offset.

sensor(config-hos-non)# offset 60
 

Step 9 Verify your settings.

sensor(config-hos-non)# show settings
non-recurring
-----------------------------------------------
offset: 60 minutes default: 60
summertime-zone-name: CDT
start-summertime
-----------------------------------------------
date: 2004-05-15
time: 12:00:00
-----------------------------------------------
end-summertime
-----------------------------------------------
date: 2004-10-31
time: 12:00:00
-----------------------------------------------
-----------------------------------------------
sensor(config-hos-non)#
 

Step 10 Exit non-recurring summertime submode.

sensor(config-hos-non)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 11 Press Enter to apply the changes or enter no to discard them.


 

Configuring Time Zones Settings

Use the time-zone-settings command to configure the time zone settings on the sensor, such as the time zone name the sensor displays whenever summertime settings are not in effect and the offset.

To configure the time zone settings on the sensor, follow these steps:


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

Step 2 Enter time zone settings submode.

sensor# configure terminal
sensor(config)# service host
sensor(config-hos)# time-zone-settings
 

Step 3 Configure the time zone name that is displayed whenever summertime settings are not in effect. The default is UTC.

sensor(config-hos-tim)# standard-time-zone-name CST
 

Step 4 Configure the offset in minutes. The offset is the number of minutes you add to UTC to get the local time. The default is 0.

sensor(config-hos-tim)# offset -360
 

Step 5 Verify your settings.

sensor(config-hos-tim)# show settings
time-zone-settings
-----------------------------------------------
offset: -360 minutes default: 0
standard-time-zone-name: CST default: UTC
-----------------------------------------------
sensor(config-hos-tim)#
 

Step 6 Exit time zone settings submode.

sensor(config-hos-tim)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]:
 

Step 7 Press Enter to apply the changes or enter no to discard them.


 

Configuring NTP

This section describes how to configure a Cisco router to be an NTP server and how to configure the sensor to use an NTP server as its time source. It contains the following topics:

Configuring a Cisco Router to be an NTP Server

Configuring a Cisco Router to be an NTP Server

The sensor requires an authenticated connection with an NTP server if it is going to use the NTP server as its time source. The sensor supports only the MD5 hash algorithm for key encryption. Use the following procedure to activate a Cisco router to act as an NTP server and use its internal clock as the time source.


Caution The sensor NTP capability is designed to be compatible with Cisco routers acting as NTP servers. The sensor may work with other NTP servers, but is not tested or supported.


Note Remember the NTP server key ID and key values. You need them along with the NTP server IP address when you configure the sensor to use the NTP server as its time source.


To set up a Cisco router to act as an NTP server, follow these steps:


Step 1 Log in to the router.

Step 2 Enter configuration mode.

router# configure terminal
 

Step 3 Create the key ID and key value. The key ID can be a number between 1 and 65535. The key value is text (numeric or character). It is encrypted later.

router(config)# ntp authentication-key key_ID md5 key_value
 

Example

router(config)# ntp authentication-key 100 md5 attack
 

Note The sensor only supports MD5 keys.



Note Keys may already exist on the router. Use the show running configuration command to check for other keys. You can use those values for the trusted key in Step 4.


Step 4 Designate the key you just created in Step 3 as the trusted key (or use an existing key). The trusted key ID is the same number as the key ID in Step 3.

router(config)# ntp trusted-key key_ID
 

Example

router(config)# ntp trusted-key 100
 

Step 5 Specify the interface on the router with which the sensor will communicate.

router(config)# ntp source interface_name
 

Example

router(config)# ntp source FastEthernet 1/0
 

Step 6 Specify the NTP master stratum number to be assigned to the sensor. The NTP master stratum number identifies the relative position of the server in the NTP hierarchy. You can choose a number between 1 and 15. It is not important to the sensor which number you choose.

router(config)# ntp master stratum_number
 

Example

router(config)# ntp master 6
 


 

Configuring the Sensor to Use an NTP Time Source

The sensor requires a consistent time source. We recommend that you use an NTP server. Use the following procedure to configure the sensor to use the NTP server as its time source. You can use authenticated or unauthenticated NTP.


Note For authenticated NTP, you must obtain the NTP server IP address, NTP server key ID, and the key value from the NTP server.



Caution The sensor NTP capability is designed to be compatible with Cisco routers acting as NTP servers. The sensor may work with other NTP servers, but is not tested or supported.

To configure the sensor to use an NTP server as its time source, follow these steps:


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

Step 2 Enter configuration mode.

sensor# configure terminal
 

Step 3 Enter service host mode.

sensor(config)# service host
 

Step 4 Configure unauthenticated NTP:

a. Enter NTP configuration mode.

sensor(config-hos)# ntp-option enabled-ntp-unauthenticated
 

b. Specify the NTP server IP address.

sensor(config-hos-ena)# ntp-server ip_address
 

c. Verify the unauthenticated NTP settings.

sensor(config-hos-ena)# show settings
enabled-ntp-unauthenticated
-----------------------------------------------
ntp-server: 10.89.147.45
-----------------------------------------------
sensor(config-hos-ena)#
 

Step 5 Configure authenticated NTP:

a. Enter NTP configuration mode.

sensor(config-hos)# ntp-option enable
 

b. Specify the NTP server IP address and key ID. The key ID is a number between 1 and 65535. This is the key ID that you already set up on the NTP server.

sensor(config-hos-ena)# ntp-servers ip_address key-id key_ID
 

Example

sensor(config-hos-ena)# ntp-servers 10.16.0.0 key-id 100
 

c. Specify the key value NTP server. The key value is text (numeric or character). This is the key value that you already set up on the NTP server.

sensor(config-hos-ena)# ntp-keys key_ID md5-key key_value
 

Example

sensor(config-hos-ena)# ntp-keys 100 md5-key attack
 

d. Verify the NTP settings.

sensor(config-hos-ena)# show settings
enabled
-----------------------------------------------
ntp-keys (min: 1, max: 1, current: 1)
-----------------------------------------------
key-id: 100
-----------------------------------------------
md5-key: attack
-----------------------------------------------
-----------------------------------------------
ntp-servers (min: 1, max: 1, current: 1)
-----------------------------------------------
ip-address: 10.16.0.0
key-id: 100
-----------------------------------------------
-----------------------------------------------
sensor(config-hos-ena)#
 

Step 6 Exit NTP configuration mode.

sensor(config-hos-ena)# exit
sensor(config-hos)# exit
Apply Changes:?[yes]
 

Step 7 Press Enter to apply the changes or enter no to discard them.


 

Configuring SSH

This section describes SSH on the sensor, and contains the following topics:

Understanding SSH

Adding Authorized RSA1 and RSA2 Keys

Understanding SSH

SSH provides strong authentication and secure communications over channels that are not secure. SSH encrypts your connection to the sensor and provides a key so you can validate that you are connecting to the correct sensor. SSH also provides authenticated and encrypted access to other devices that the sensor connects to for blocking. The IPS supports managing both SSHv1 and SSHv2. The default is SSHv2, but you can configure the sensor to fallback to SSHv1 if the peer client/server does not support SSHv2.

SSH authenticates the hosts or networks using one or both of the following:

  • Password
  • User RSA public key

Note SSH never sends passwords in clear text.


SSH protects against the following:

  • IP spoofing—A remote host sends out packets pretending to come from another trusted host.

Note SSH even protects against a spoofer on the local network who can pretend he is your router to the outside.


  • IP source routing—A host pretends an IP packet comes from another trusted host.
  • DNS spoofing—An attacker forges name server records.
  • Interception of clear text passwords and other data by intermediate hosts.

• Manipulation of data by those in control of intermediate hosts.

  • Attacks based on listening to X authentication data and spoofed connection to the X11 server.

Adding Hosts to the SSH Known Hosts List

You must add hosts to the SSH known hosts list so that the sensor can recognize the hosts that it can communicate with through SSH. These hosts are SSH servers that the sensor needs to connect to for upgrades and file copying, and other hosts, such as Cisco routers, firewalls, and switches that the sensor will connect to for blocking.

For SSHv1, use the ssh host-key ip-address rsa1-key [ key-modulus-length public-exponent public-modulus ] command to add an entry to the known hosts list. If you do not know the values for the modulus, exponent, and length, the system displays the bubble babble for the requested IP address. You can then choose to add the key to the list. To modify a key for an IP address, the entry must be removed and recreated. Use the no form of the command to remove the entry.


Caution When you use the ssh host-key command, the SSH server at the specified IP address is contacted to obtain the required key over the network. The specified host must be accessible at the moment the command is issued. If the host is unreachable, you must use the full form of the command, ssh host-key ip-address rsa1-key [key-modulus-length public-exponent public-modulus], to confirm the fingerprint of the key displayed to protect yourself from accepting the key of an attacker.

For SSHv2, use the ssh host-key ip-address rsa-key key command to add an entry to the known hosts list.

The following parameters apply:

  • ip address —Specifies the IP address to add to the system.
  • rsa-key —Specifies the RSA (SSHv2) key details.

key —Specifies the Base64 encoded public key.

  • rsa1-key —Specifies the RSA1 (SSHv1) key details:

key-modulus-length —Specifies an ASCCI decimal integer in the range[511, 2048].

public-exponent —Specifies an ASCII decimal integer in the range [3, 2^32].

public-modulus —Specifies an ASCII decimal integer, x , such that (2^(key-modulus-length-1)) < x < (2^(key-modulus-length)).

To add a host to the SSH known hosts list, follow these steps:


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

Step 2 Enter configuration mode.

sensor# configure terminal
 

Step 3 Add an entry to the known hosts list.

sensor(config)# ssh host-key 10.16.0.0
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]
 

The Bubble Babble appears. You are prompted to add it to the known hosts list.

If the host is not accessible when the command is issued, this message appears.

Error: getHostSshKey : Failed to fetch RSA key
 

Step 4 Enter yes to have the fingerprint added to the known hosts list.

Step 5 Verify that the host was added.

sensor(config)# exit
sensor# show ssh host-keys
10.89.146.110
 

Step 6 View the key for a specific IP address.

sensor# show ssh host-keys 10.16.0.0
1024 35 139306213541835240385332922253968814685684523520064131997839905113640120217816869696708721704631322844292073851730565044879082670677554157937058485203995572114631296604552161309712601068614812749969593513740598331393154884988302302182922353335152653860589163651944997842874583627883277460138506084043415861927
Bubble Babble: xebiz-vykyk-fekuh-rukuh-cabaz-paret-gosym-serum-korus-fypop-huxyx
sensor#
 

Step 7 Remove an entry. The host is removed from the SSH known hosts list.

sensor(config)# no ssh host-key 10.16.0.0
 

Step 8 Verify the host was removed. The IP address no longer appears in the list.

sensor(config)# exit
sensor# show ssh host-keys
 


 

Adding Authorized RSA1 and RSA2 Keys

Use the ssh authorized-key command to define public keys for a client allowed to use RSA1 or RSA2 authentication to log in to the local SSH server. The default is RSA2. You can configure the sensor to fall back to RSA1. To modify an authorized key, you must remove and recreate the entry. Use the no form of the command to remove the entry. Users can only create and remove their own keys.

The following parameters apply:

  • id —Specifies a 1 to 256-character string that uniquely identifies the authorized key. You can use numbers, “_,” and “-,” but spaces and “?” are not accepted.
  • rsa-pubkey —Specifies the RSA (SSHv2) key details.

pubkey —Specifies the Base64 encoded public key.

  • rsa1-pubkey —Specifies the RSA1 (SSHv1) key details:

key-modulus-length —Specifies an ASCCI decimal integer in the range[511, 2048].

public-exponent —Specifies an ASCII decimal integer in the range [3, 2^32].

public-modulus —Specifies an ASCII decimal integer, x, such that (2^(key-modulus-length-1)) < x < (2^(key-modulus-length)).

Each user who can log in to the sensor has a list of authorized public keys. An SSH client with access to any of the corresponding RSA private keys can log in to the sensor as the user without entering a password.

For SSHv1, use an RSA key generation tool on the client where the private key is going to reside. Then, display the generated public key as a set of three numbers (modulus length, public exponent, public modulus) and enter those numbers as parameters for the ssh authorized-key command. For SSHv2, you just need the ID and the public key.


Note You configure your own list of SSH authorized keys. An administrator cannot manage the list of SSH authorized keys for other users on the sensor.



Note An SSH authorized key provides better security than passwords if the private key is adequately safeguarded. The best practice is to create the private key on the same host where it will be used and store it with a pass phrase on a local file system. To minimize password or pass phrase prompts, use a key agent.


To add a key entry to the SSHv1 or SSHv2 authorized keys list for the current user, follow these steps:


Step 1 Log in to the CLI.

Step 2 Add a key to the authorized keys list for the current user.


Note You receive an error message if you try to add a key less than the 2048-bit key size and if the measured key length and input key length do not match.


For SSHv1:

sensor# configure terminal
sensor(config)# ssh authorized-key mhs rsa1-pubkey 512 34 8777777777777
 
sensor(config)#
 

For SSHv2:

sensor# configure terminal
sensor(config)# ssh authorized-key phs rsa-pubkey AAAAAAAAAAslkfjslkfjsjfs
 

Step 3 Enter yes to add the key to the authorized key list.

Step 4 Verify that the key was added.

sensor(config)# exit
sensor# show ssh authorized-keys
mhs
phs
sensor#
 

Step 5 View the key for a specific ID.

sensor# show ssh authorized-keys mhs
512 34 8777777777777
sensor#
 

Step 6 Remove an entry from the list of SSH authorized keys.

sensor# configure terminal
sensor(config)# no ssh authorized-key mhs rsa1-key
 

Step 7 Verify the entry was removed.

sensor(config)# exit
sensor# show ssh authorized-keys
 

Step 8 If you enter the former ID, you receive an error message.

sensor# show ssh authorized-keys mhs
Error: Requested id does not exist for the current user.
sensor#
 


 

Generating the RSA Server Host Key

The server uses the SSHv1 or SSHv2 host key to prove its identity. Clients know they have contacted the correct server when they see a known key. The sensor generates an SSHv1 or SSHv2 host key the first time it starts up.

Use the ssh generate-key command to change the SSH server host key. The displayed fingerprint matches the one displayed in the remote SSH client in future connections with this sensor if the remote client is using SSH.


Note The sensor only supports RSA keys. Peers that communicate with IPS need to support RSA keys; otherwise, the connection is not established.


To generate a new SSH server host key, follow these steps:


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

Step 2 Generate the new server host key.

sensor# ssh generate-key
RSA1 Bubble Babble: xucor-gidyg-comym-zipib-pilyk-vucal-pekyd-hipuc-tuven-gigyr-fixyx
RSA Bubble Babble: xucot-sapaf-sufiz-duriv-rigud-kezol-tupif-buvih-zokap-sohoz-kixox
sensor#
 

Caution The new key replaces the existing key, which requires you to update the known hosts tables on remote systems with the new host key so that future connections succeed. You can update the known hosts tables on remote systems using the ssh host-key command.

Step 3 Display the current SSH server host key. The sensor displays the RSA1 (SSHv1) and the RSA (SSHv2) keys.

sensor# show ssh server-key
RSA1 Key: 2048 65537 21281522654207836691935756443555553045267729811163188158123
19221105282706971156372834395971442406711584211050336190060471149429624658777668
77772213935517164097668879617982452141055538222385354775671320871325156194364534
01964293900473562985740703815287014221909604447874565966052932190994239169399973
09451774745322103150629685832787333113245586019053499876586171642882215702812368
29552879443164044336379548314607826859130457872422419997317349512539506437629934
62410481738789963850532157078406908293224279442047344280835594921181229802312694
953678513524852911662327237984274983550808940893737598517019547234622411280871
RSA1 Bubble Babble: xucor-gidyg-comym-zipib-pilyk-vucal-pekyd-hipuc-tuven-gigyr-fixyx
 
RSA Key: AAAAB3NzaC1yc2EAAAADAQABAAABAQC/zpG5nXqlAfc/aNzgQweipp9tjAqd1Xr5tuCJa+m
ccscEPHc25zUKLQG+8HkvieG2Pf11Y7mZk2POJICjXSV5izFczaFnZhBBUS+QOMH0nsk+S6F9Cujmz99
/OseRwQK16o2o2ds9otNfctAhVgex86SX5cWI0dyAYU1ZpwZCpK5sKxTtgzUkOEOSFPcHthf1DJvJfuj
1rWSJ/VAUHH4T5aomZ4m/is8jTp+nog5O5tDt6huqWYZt6MNTRoXTq0UgDgGOlueoGM6Sqk0nCwUlsBG
TNaEoJbN0elRk+qNnSGo4FQYLVCryMZYi6GOxZVxwPST3IGuEHTunAw6aUnRl
RSA Bubble Babble: xucot-sapaf-sufiz-duriv-rigud-kezol-tupif-buvih-zokap-sohoz-kixox
sensor#
 


 

For More Information

For the procedure for updating the known hosts table, see Adding Hosts to the SSH Known Hosts List.

Configuring TLS

This section describes TLS on the sensor, and contains the following topics:

Understanding TLS

Understanding TLS

The Cisco IPS contains a web server that is running the IDM. Management stations connect to this web server. Blocking forwarding sensors also connect to the web server of the master blocking sensor. To provide security, this web server uses an encryption protocol known as TLS, which is closely related to SSL protocol. When you enter a URL into the web browser that starts with https:// ip_address , the web browser responds by using either TLS or SSL protocol to negotiate an encrypted session with the host.


Caution The web browser initially rejects the certificate presented by the IDM because it does not trust the certificate authority (CA).


Note The IDM is enabled by default to use TLS and SSL.We highly recommend that you use TLS and SSL.


The process of negotiating an encrypted session in TLS is called “handshaking,” because it involves a number of coordinated exchanges between client and server. The server sends its certificate to the client. The client performs the following three-part test on this certificate:

1. Is the issuer identified in the certificate trusted?

Every web browser ships with a list of trusted third-party CAs. If the issuer identified in the certificate is among the list of CAs trusted by your browser, the first test is passed.

2. Is the date within the range of dates during which the certificate is considered valid?

Each certificate contains a Validity field, which is a pair of dates. If the date falls within this range of dates, the second test is passed.

3. Does the common name of the subject identified in the certificate match the URL hostname?

The URL hostname is compared with the subject common name. If they match, the third test is passed.

When you direct your web browser to connect with the IDM, the certificate that is returned fails because the sensor issues its own certificate (the sensor is its own CA) and the sensor is not already in the list of CAs trusted by your browser.

When you receive an error message from your browser, you have three options:

  • Disconnect from the site immediately.
  • Accept the certificate for the remainder of the web browsing session.
  • Add the issuer identified in the certificate to the list of trusted CAs of the web browser and trust the certificate until it expires.

The most convenient option is to permanently trust the issuer. However, before you add the issuer, use out-of-band methods to examine the fingerprint of the certificate. This prevents you from being victimized by an attacker posing as a sensor. Confirm that the fingerprint of the certificate appearing in your web browser is the same as the one on your sensor.


Caution If you change the organization name or hostname of the sensor, a new certificate is generated the next time the sensor is rebooted. The next time your web browser connects to the IDM, you will receive the manual override dialog boxes. You must perform the certificate fingerprint validation again for Internet Explorer and Firefox.

Adding TLS Trusted Hosts

In certain situations, the sensor uses TLS/SSL to protect a session it establishes with a remote web server. For these sessions to be secure from man-in-the-middle attacks you must establish trust of the TLS certificates of the remote web servers. A copy of the TLS certificate of each trusted remote host is stored in the trusted hosts list.

Use the tls trusted-host ip-address ip-address [ port port ] command to add a trusted host to the trusted hosts list. This command retrieves the TLS certificate from the specified host/port and displays its fingerprint. You can accept or reject the fingerprint based on information retrieved directly from the host you are requesting to add. The default port is 443.

Each certificate is stored with an identifier field ( id ). For the IP address and default port, the identifier field is ipaddress . For the IP address and specified port, the identifier field is ipaddress:port .


Caution TLS at the specified IP address is contacted to obtain the required fingerprint over the network. The specified host must by accessible at the moment the command is issued. Use an alternate method to confirm the fingerprint to protect yourself from accepting a certificate of an attacker.

To add a trusted host to the trusted hosts list, follow these steps:


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

Step 2 Add the trusted host.

sensor# configure terminal
sensor(config)# tls trusted-host ip-address 10.16.0.0
Certificate SHA1 fingerprint is B1:6F:F5:DA:F3:7A:FB:FB:93:E9:2D:39:B9:99:08:D4:
47:02:F6:12
Would you like to add this to the trusted certificate table for this host?[yes]:
 

The SHA1 fingerprints appear. You are prompted to add the trusted host.

If the connection cannot be established, the transaction fails.

sensor(config)# tls trusted-host ip-address 10.89.146.110 port 8000
Error: getHostCertificate : socket connect failed [4,111]
 

Step 3 Enter yes to accept the fingerprint. The host is added to the TLS trusted host list. The Certificate ID stored for the requested certificate is displayed when the command is successful.

Certificate ID: 10.89.146.110 successfully added to the TLS trusted host table.
sensor(config)#
 

Step 4 Verify that the host was added.

sensor(config)# exit
sensor# show tls trusted-hosts
10.89.146.110
sensor#
 

Step 5 View the fingerprint for a specific host.

sensor# show tls trusted-hosts 10.89.146.110
SHA1: B1:6F:F5:DA:F3:7A:FB:FB:93:E9:2D:39:B9:99:08:D4:47:02:F6:12
sensor#
 

Step 6 Remove an entry from the trusted hosts list.

sensor# configure terminal
sensor(config)# no tls trusted-host 10.89.146.110
 

Step 7 Verify the entry was removed from the trusted host list. The IP address no longer appears in the list.

sensor(config)# exit
sensor# show tls trusted-hosts
No entries
 


 

Displaying and Generating the Server Certificate

A TLS certificate is generated when the sensor is first started. Use the tls generate-key command to generate a new server self-signed X.509 certificate. The IP address of the sensor is included in the certificate. If you change the sensor IP address, the sensor automatically generates a new certificate.


Caution The new certificate replaces the existing certificate, which requires you to update the trusted hosts lists on remote systems with the new certificate so that future connections succeed. You can update the trusted hosts lists on remote IPS sensors using the tls trusted-host command. If the sensor is a master blocking sensor, you must update the trusted hosts lists on the remote sensors that are sending block requests to the master blocking sensor.

To generate a new TLS certificate, follow these steps:


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

Step 2 Generate the new certificate.

sensor# tls generate-key
SHA1 fingerprint is 4A:2B:79:A0:82:8B:65:3A:83:B5:D9:50:C0:8E:F6:C6:B0:30:47:BB
sensor#
 

Step 3 Verify that the key was generated.

sensor# show tls fingerprint
SHA1: 4A:2B:79:A0:82:8B:65:3A:83:B5:D9:50:C0:8E:F6:C6:B0:30:47:BB
sensor#
 


 

For More Information

For the procedure for updating the trusted hosts lists on remote sensors, see Adding TLS Trusted Hosts.

Installing the License Key

This section describes the IPS license key and how to install it. It contains the following topics:

Understanding the License Key

Understanding the License Key

Although the sensor functions without the license key, you must have a license key to obtain signature updates and use the global correlation features. To obtain a license key, you must have the following:

  • Cisco Service for IPS service contract—Contact your reseller, Cisco service or product sales to purchase a contract.

• Your IPS device serial number—To find the IPS device serial number in the IDM or the IME, for the IDM choose Configuration > Sensor Management > Licensing , and for the IME choose Configuration > sensor_name > Sensor Management > Licensing , or in the CLI use the show version command.

  • Valid Cisco.com username and password.

Trial license keys are also available. If you cannot get your sensor licensed because of problems with your contract, you can obtain a 60-day trial license that supports signature updates that require licensing.

You can obtain a license key from the Cisco.com licensing server, which is then delivered to the sensor. Or, you can update the license key from a license key provided in a local file. Go to http://www.cisco.com/go/license and click IPS Signature Subscription Service to apply for a license key.

You can view the status of the license key in these places:

  • The IDM Home window Licensing section on the Health tab
  • The IDM Licensing pane ( Configuration > Licensing )
  • The IME Home page in the Device Details section on the Licensing tab
  • License Notice at CLI login

Whenever you start the IDM, the IME, or the CLI, you are informed of your license status—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 the IDM, the IME, and the CLI, but you cannot download signature updates.

If you already have a valid license on the sensor, you can click Download on the License pane to download a copy of your license key to the computer that the IDM or the IME is running on and save it to a local file. You can then replace a lost or corrupted license, or reinstall your license after you have reimaged the sensor.

Service Programs for IPS Products

You must have a Cisco Services for IPS service contract for any IPS product so that you can download a license key and obtain the latest IPS signature updates. If you have a direct relationship with Cisco Systems, contact your account manager or service account manager to purchase the Cisco Services for IPS service contract. If you do not have a direct relationship with Cisco Systems, you can purchase the service account from a one-tier or two-tier partner.

When you purchase the following IPS products you must also purchase a Cisco Services for IPS service contract:

  • IPS 4345
  • IPS 4345-DC
  • IPS 4360
  • IPS 4510
  • IPS 4520
  • IPS 4520-XL

When you purchase an ASA 5500 series adaptive security appliance product that does not contain IPS, you must purchase a SMARTnet contract.


Note SMARTnet provides operating system updates, access to Cisco.com, access to TAC, and hardware replacement NBD on site.


When you purchase an ASA 5500 series adaptive security appliance product that ships with an IPS module installed, or if you purchase one to add to your ASA 5500 series adaptive security appliance product, you must purchase the Cisco Services for IPS service contract.


Note Cisco Services for IPS provides IPS signature updates, operating system updates, access to Cisco.com, access to TAC, and hardware replacement NBD on site.


For example, if you purchase an ASA 5585-X and then later want to add IPS and purchase an ASA-IPS10-K9, you must now purchase the Cisco Services for IPS service contract. After you have the Cisco Services for IPS service contract, you must also have your product serial number to apply for the license key.


Caution If you ever send your product for RMA, the serial number changes. You must then get a new license key for the new serial number.

Obtaining and Installing the License Key


Note You cannot install an older license key over a newer license key.


Use the copy source-url license_file_name license-key command to copy the license key to your sensor.

The following parameters apply:

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

  • destination-url —The location of the destination file to be copied. It can be a URL or a keyword.
  • license-key —The subscription license file.
  • license_file_name —The name of the license file you receive.

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

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

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

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

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

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

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


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


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

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

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

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


Note If you use HTTPS protocol, the remote host must be a TLS trusted host.


Installing the License Key

To install the license key, follow these steps:


Step 1 Log in to Cisco.com .

Step 2 Apply for the license key at this URL: www.cisco.com/go/license .


Note In addition to a valid Cisco.com username and password, you must also have a Cisco Services for IPS service contract before you can apply for a license key.


Step 3 Fill in the required fields. Your Cisco IPS Signature Subscription Service license key will be sent by email to the e-mail address you specified.


Note You must have the correct IPS device serial number and product identifier (PID) because the license key only functions on the device with that number.


Step 4 Save the license key to a system that has a Web server, FTP server, or SCP server.

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

Step 6 Copy the license key to the sensor.

sensor# copy scp://user@192.168.1.2/24://tftpboot/dev.lic license-key
Password: *******
 

Step 7 Verify the sensor is licensed.

sensor# show version
Application Partition:
 
Cisco Intrusion Prevention System, Version 7.2(1)E4
 
Host:
Realm Keys key1.0
Signature Definition:
Signature Update S697.0 2013-02-15
OS Version: 2.6.29.1
Platform: IPS4360
Serial Number: FCH1504V0CF
Licensed, expires: <07-Aug-2013 UTC >
Sensor up-time is 3 days.
Using 14470M out of 15943M bytes of available memory (90% usage)
system is using 32.4M out of 160.0M bytes of available disk space (20% usage)
application-data is using 87.1M out of 376.1M bytes of available disk space (24% usage)
boot is using 61.2M out of 70.1M bytes of available disk space (92% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96% usage)
 
 
MainApp V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500 Running
AnalysisEngine V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500 Running
CollaborationApp V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500 Running
CLI V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500
 
Upgrade History:
 
IPS-K9-7.2-1-E4 11:17:07 UTC Thu Jan 10 2013
 
Recovery Partition Version 1.1 - 7.2(1)E4
 
Host Certificate Valid from: 17-Apr-2013 to 18-Apr-2015
 
sensor#
 


 

Licensing the ASA 5500-X IPS SSP

For the ASA 5500-X series adaptive security appliances with the IPS SSP, the ASA requires the IPS Module license. To view your current ASA licenses, in ASDM choose Home > Device Dashboard > Device Information > Device License . For more information about ASA licenses, refer to the licensing chapter in the configuration guide. After you obtain the ASA IPS Module license, you can obtain and install the IPS license key.

For More Information

Uninstalling the License Key

Use the erase license-key command to uninstall the license key on your sensor. This allows you to delete an installed license key from a sensor without restarting the sensor or logging into the sensor using the service account.

To uninstall the license key, follow these steps:


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

Step 2 Uninstall the license key on the sensor.

sensor# erase license-key
Warning: Executing this command will remove the license key installed on the sensor.
 
You must have a valid license key installed on the sensor to apply the Signature Updates and use the Global Correlation features.
 
Continue? []: yes
sensor#
 

Step 3 Verify the sensor key has been uninstalled.

sensor# show version
Application Partition:
 
Cisco Intrusion Prevention System, Version 7.2(1)E4
 
Host:
Realm Keys key1.0
Signature Definition:
Signature Update S697.0 2013-02-15
OS Version: 2.6.29.1
Platform: IPS4360
Serial Number: FCH1504V0CF
No license present
Sensor up-time is 3 days.
Using 14470M out of 15943M bytes of available memory (90% usage)
system is using 32.4M out of 160.0M bytes of available disk space (20% usage)
application-data is using 87.1M out of 376.1M bytes of available disk space (24% usage)
boot is using 61.2M out of 70.1M bytes of available disk space (92% usage)
application-log is using 494.0M out of 513.0M bytes of available disk space (96% usage)
 
 
MainApp V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500 Running
AnalysisEngine V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500 Running
CollaborationApp V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500 Running
CLI V-2013_04_10_11_00_7_2_1 (Release) 2013-04-10T11:05:55-0500
 
Upgrade History:
 
IPS-K9-7.2-1-E4 11:17:07 UTC Thu Jan 10 2013
 
Recovery Partition Version 1.1 - 7.2(1)E4
 
Host Certificate Valid from: 17-Apr-2013 to 18-Apr-2015
 
sensor#