Cisco IPS

Postings may contain unverified user-created content and change frequently.
The content is provided as-is and

is not warrantied by Cisco.
1
IDS/IPS - Top Commonly-Encountered
Problems (and Solutions)
IDS/IPS - Top Commonly-Encountered
Problems (and Solutions)

This is a TAC-maintained document containing a list of what TAC considers the top
problems (and questions) users may encounter with Cisco IDS/IPS sensor products. The
purpose of this document is to provide the community with an accessible, technically-
accurate, and well-maintained document that can be referenced for solutions.

IDS/IPS - Top Commonly-Encountered Problems (and Solutions) on page 1
Auto/Cisco.com Update on page 2
Enabling and Configuring Automatic Updates on page 2
Connectivity Requirements for Automatic Updates on page 3
Testing the Auto/Cisco.com Update Feature on page 4
Troubleshooting Auto/Cisco.com Update Failures on page 4
Event Store (Log Buffer) / Logging on page 5
SDEE (Security Device Event Exchange) on page 5
SNMP (Simple Network Management Protocol) Traps on page 6
IP Logging Actions on page 8
Global Correlation Inspection (Updates) on page 8
Enabling and Configuring Global Correlation Inspection (Updates) on
page 9
Connectivity Requirements for Global Correlation Inspection Updates on
page 10
Testing the Global Correlation Inspection (Updates) Feature on page
10
Troubleshooting Global Correlation Inspection (Update) Failures on page
11
IPv6 on page 13
Licensing on page 14
Obtaining a License-key File on page 14
Installing a License-key File on page 14
Manually Removing the Currently-installed License-key File on page
15
Self-signed TLS X.509 Server Certificate on page 15
Verifying the Sensor Certificate's Valid Date Range on page 16
IDS/IPS - Top Commonly-Encountered Problems (and Solutions)
Postings may contain unverified user-created content and change frequently. The content is provided as-is and
2
Re-generating the Sensor Certificate on page 17
Signature Definitions on page 18
Signature Details and More Information (Does Cisco Provide a Signature
for This Threat?) on page 19
False Positives and EAFs (Event Action Filters) on page 19
Cannot Enable and Unretire All Signatures on page 20
Unable to Access or Reach Sensor's Management (Command & Control) Interface on
page 21
Access-List (the Sensor's Built-in Firewall for Management Traffic) on
page 21
Management (Command & Control) IP Address and Default-gateway on
page 22
Testing Basic Network Connectivity on page 23
Verifying Sensor Operation (Receiving and Inspecting Traffic) on page 24
Sensing-interface Link Status and Total Packets Received on page
24
Virtual-sensor Sensing-interface Assignment and Total Packets
Processed on page 25
IDSM-2 Sensor Module - errSystemError -ct-sensorApp.XXX not responding, please
check system processes - The connect to the specified Io::ClientPipe failed. on page
27

Auto/Cisco.com Update

Sensors running software version 6.1 or later include a feature to automatically check for,
download, and install engine and signature definition updates directly from cisco.com on
a defined schedule, referred to as "Auto/Cisco.com Update". This functionality can reduce
recurring administrative overhead (vs. manually downloading and installing updates) and
helps ensure the sensor is detecting/protecting against the latest threats.

This feature does NOT automate software upgrades, only engine and signature definition
updates.

3
Enabling and Configuring Automatic Updates

The simplest/easiest method to enable and configure the Auto/Cisco.com Update feature
is via the sensor GUI (IDM) or IME (IPS Manager Express)'s Configuration > Sensor
Management > Auto/Cisco.com Update section. From that section, ensure the Enable
Signature and Engine Updates from Cisco.com check-box is checked and click the
Cisco.com Server Settings bar to expand the section and display the relevant fields/options.

A valid cisco.com (CCO) username and password must be provided. And a schedule,
including a start time, must be set (either Hourly or Daily). Generally, signature definition
updates are released approximately once every 1 - 2 weeks. As such, most users are well-
served by a Daily check; a more aggressive schedule is usually wasteful (bandwidth-wise).

NOTE: The default Cisco.com URL: value (https://198.133.219.25//cgi-bin/front.x/ida/locator/
locator.pl) is currently the only valid URL value. The double-forward slash following the IP
address is expected and required.

Connectivity Requirements for Automatic Updates

The sensor initially attempts to connect to the configured Cisco.com server (198.133.219.25)
over TCP port 443. If successful, it authenticates (using the configured cisco.com (CCO)
username/password) and retrieves the current update package filename and download
server information (IP address and path).

The sensor then attempts to connect to the download server over TCP port 80 and to
download the update package. The download server's IP address may and will change; as
such, generally the sensor requires full, unfiltered outbound Internet access for the Auto/
Cisco.com Update feature to function. Outbound access-lists on firewalls/routers may need
to be modified to permit the sensor access.

4
The Auto/Cisco.com Update feature does NOT support connectivity through non-transparent
proxy servers or any other system which requires authentication or other interaction/
response. Caching systems, content filters, and traffic optimizers or shapers may also
interfere with/deny/invalidate Auto/Cisco.com Update traffic, preventing the feature from
functioning. The sensor's Management (Command and Control) IP address should be
excluded/exempt from such systems.

Testing the Auto/Cisco.com Update Feature

There is currently no "Test Connectivity" function for quick testing on-demand. To force the
sensor to check for an update, modify the sensor's current Auto/Cisco.com Update settings,
scheduling the next update check to occur in the next few minutes by temporarily setting the
Frequency: value to Hourly - Every 1 hours, and setting the Start Time: a few minutes ahead
of the current sensor time.

The current sensor time can be obtained from the 'show clock' command output. Example:

sensor# show clock12:15:00 GMT-05:00 Wed May 1 2011

Troubleshooting Auto/Cisco.com Update Failures

After an Auto/Cisco.com Update schedule/attempt has occurred, success/failure details
can be found in the Auto Update Statistics section of the 'show stat host' command output.
Example:

sensor# show stat host | begin Auto UpdateAuto Update Statistics
lastDirectoryReadAttempt = 12:20:00 GMT-05:00 Wed May 01 2011 = Read directory:
http://user@72.163.7.55//swc/esd/guest/ = Success lastDownloadAttempt = 12:20:00
5
GMT-05:00 Wed May 01 2011 = Download: http://user@72.163.7.55//swc/esd/guest/IPS-
sig-S563-req-E4.pkg = Success lastInstallAttempt = 12:20:30 GMT-05:00 Wed May 01
2011 = IPS-sig-S563-req-E4: Update completed successfully = Success nextAttempt
= 12:20:00 GMT-05:00 Thu May 02 2011

Other than authentication failures (invalid cisco.com (CCO) username/password
combinations), connectivity failures (the sensor being unable to reach or download from
cisco.com) are most common. See the Connectivity Requirements for Automatic Updates
section of this document for details.

Event Store (Log Buffer) / Logging

The sensor makes use of a 32 MB circular buffer in-memory to store event data (Alerts). As
new events occur, the buffer fills. When it reaches capacity, new events override the oldest
events. This buffer serves as temporary storage for event data long enough for a configured
remote monitoring system(s) to poll the sensor for data and copy it off for long-term storage.
The size of the sensor's event store is not configurable (it is hard-coded).

Modern releases of the sensor software support two (2) "logging protocols": SDEE and
SNMP. Syslog is not supported nor available (except on software-based (IOS IPS) devices).
Email (SMTP) is also not supported nor available on the sensor itself (though some external
monitoring applications/devices (such as IME (IPS Manager Express) and CS-MARS) can
be configured to send Email Alert Notifications).

SDEE (Security Device Event Exchange)

6
SDEE (Security Device Event Exchange) is an application-level protocol used to exchange
data between clients and servers ("providers"). The sensor is a provider (with a built-
in web server and SDEE servlet). When properly configured, clients (such as IME (IPS
Manager Express) and CS-MARS) connect to the sensor via HTTPS (TLS/SSL) or HTTP,
authenticate, and if successful, exchange data. SDEE is the preferred protocol for data
exchange. The sensor's web server and SDEE servlet are both running by-default. As such,
generally the only configuration necessary on the sensor to allow a SDEE client access is to
add a permit entry for the SDEE client's IP address to the sensor's access-list.

SNMP (Simple Network Management Protocol) Traps

SNMP (Simple Network Management Protocol) is also an application-level protocol. Unlike
SDEE, SNMP Traps (aka "notifications") are not enabled by-default. If configured, the
sensor is considered a SNMP Agent, sending SNMP Traps to one (1) or more SNMP Trap
Destinations ("management systems").

To enable SNMP Traps, one (1) or more SNMP Trap Destinations must be specified (and,
if desired, a SNMP Community Name and Trap Port can be specified as well). To configure
a SNMP Trap Destination, login to the sensor using an administrative account and issue
the following commands (NOTE: In the example provided, the configured SNMP Trap
Destination has an IP address of 192.168.0.20. Replace that particular configuration line
accordingly with your actual SNMP Management System's IP address.). Example:

sensor# conf t
sensor(config)# service notification
sensor(config-not)# trap-destination 192.168.0.20
sensor(config-not-tra)# trap-community-name public
sensor(config-not-tra)# trap-port 162
7
sensor(config-not-tra)# exit
sensor(config-not)# enable-notifications true
sensor(config-not)# exit
Apply Changes?[yes]: yes

SNMP Traps are not generated for events by-default. The Request SNMP Trap Action
can be added to an EAO (Event Action Override) to remedy this (causing the Action to be
added whenever a signature fires). To configure such an EAO, login to the sensor using
an administrative account and issue the following commands (NOTE: In the example
provided, all Alerts (regardless of Risk Rating) will apply. If you only want SNMP Traps to be
generated for events of a particular Risk Rating, instead specify a desired Risk Rating range
(90-100 for High, 70-89 for Medium, 1-69 for Low)). Example:

sensor# conf t
sensor(config)# service event-action-rules rules0
sensor(config-eve)# overrides request-snmp-trap
sensor(config-eve-ove)# override-item-status enabled
sensor(config-eve-ove)# risk-rating-range 1-100
sensor(config-eve-ove)# exit
sensor(config-eve)# exit

Alternatively (instead of an EAO), if you only want SNMP Traps to be generated for specific
signatures, the Request SNMP Trap Action can be added to individual signatures on a per-
signature basis.

8

IP Logging Actions

The sensor includes three (3) Actions that can be used to automatically capture packets
relating to a signature firing: Log Attacker Packets, Log Victim Packets, and Log Pair
Packets. These IP Logging Actions are intended for troubleshooting or use under very-
controlled circumstances (where the Action(s) will not occur repeatedly). If the sensor
is configured in a way that results in one (1) or more of these Actions recurring in
succession, sensor performance will be impacted and depending on the degree of impact,
resource strains may result in undesirable sensor behavior (legitimate traffic being denied,
performance decreasing, sensor crashes or becomes unresponsive, etc.).

As such, it is generally never a good idea to configure these Actions as part of an EAO
(Event Action Override). Instead, they can be configured as-needed on a per-signature
basis, with the understanding that the sensor's primary purpose is not to capture and store
packet logs.

Global Correlation Inspection (Updates)

Sensors running software version 7.0 or later include a feature to automatically check for,
download, and install/maintain a database of global IP addresses that have a reputation
for malicious activity, referred to as "Global Correlation". The reputation data contained
in Global Correlation Updates is factored into the analysis (inspection) of network traffic,
increasing sensor efficacy.

The Global Correlation Inspection (Updates) feature increases the Risk Rating of an event if
the Attacker IP address is present in the Global Correlation database. Potentially, it can also
add either the Deny Packet Inline or Deny Attacker Inline Actions to an event. Full details
9
can be found in the official product configuration guide's Configuring Global Correlation
section.

Enabling and Configuring Global Correlation Inspection (Updates)

The Global Correlation Inspection (Updates) feature is enabled ("on") by-default. As such,
generally the only configuration change necessary on the sensor is to configure one (1) or
more valid, reachable DNS server(s).

To configure a DNS server, login to the sensor using an administrative account and issue
the following commands (NOTE: In the example provided, the configured DNS server has an
IP address of 192.168.0.10. Replace that particular configuration line accordingly with your
actual DNS server's IP address.). Example:

sensor# conf t
sensor(config)# service host
sensor(config-hos)# network-settings
sensor(config-hos-net)# dns-primary-server enabled
sensor(config-hos-net-ena)# address 192.168.0.10
sensor(config-hos-net-ena)# exit
sensor(config-hos-net)# exit
sensor(config-hos)# exit

10

Connectivity Requirements for Global Correlation Inspection Updates

The Global Correlation Inspection (Updates) feature requires the sensor to have one (1) or
more valid, reachable DNS server(s) configured. The sensor queries the configured DNS
server(s) to resolve the current IP address of update-manifests.ironport.com .

Once resolved, the sensor attempts to connect to update-manifests.ironport.com over
TCP port 443. If successful, it retrieves a list of current update files and download server
information (updates.ironport.com).

The sensor then queries the configured DNS server(s) to resolve updates.ironport.com -
served by Akamai. The query response/answer returned is determined using "geolocation"
- returning the optimal server IP address "closest" to the DNS requester's IP address. Since
the download server's IP address may and will change between requests, generally the
sensor requires full, unfiltered outbound Internet access for the Global Correlation Inspection
(Updates) feature to function. Outbound access-lists on firewalls/routers may need to be
modified to permit the sensor access.

The sensor then attempts to connect to the download server over TCP port 80 and to
download the update files.

Testing the Global Correlation Inspection (Updates) Feature

There is currently no "Test Connectivity" function for quick testing on-demand. To trigger
a GC update attempt, temporarily disable (then re-enable) the sensor's Global Correlation
Inspection setting. Example:
11

sensor# conf t
sensor(config)# service global-correlation
sensor(config-glo)# global-correlation-inspection off
sensor(config-glo)# exit
sensor(config-glo)# global-correlation-inspection on

Alternatively, simply wait for the next scheduled update attempt to occur (hard-coded to
occur every 300 seconds (5 minutes)).

Troubleshooting Global Correlation Inspection (Update) Failures

After a Global Correlation Inspection (Update) attempt has occurred, success/failure
indicators as well as attempt and failure counters can be found in the Updates section of the
'show stat global' command output. Example:

sensor# show stat global
Updates:
Status Of Last Update Attempt = Ok
12
Time Since Last Successful Update = 2 minutes
Counters:
Update Failures Since Last Success = 0
Total Update Attempts = 1
Total Update Failures = 0
Update Interval In Seconds = 300
Update Server = update-manifests.ironport.com
Update Server Address = 204.15.82.17
Current Versions:
config = 1234567890
drop = 1234567890
ip = 1234567890
rule = 1234567890

Connectivity failures (the sensor being unable to reach or download from the download
server(s)) are most common. See the Connectivity Requirements for Global Correlation
Inspection Updates section of this document for details. Additionally, ensure that the sensor:

1.) Is configured with a valid Management IP address and has working network (and
Internet) connectivity.
2.) Is configured with one (1) or more valid, reachable DNS server(s).
3.) Clock is accurate/correct (since SSL/TLS is involved in the initial GC update connection).
4.) Has a valid (and non-expired) .lic license-key file installed.

13

IPv6

The sensor does not currently support management or monitoring via IPv6. There is an
existing, open enhancement request to add support for such functionality in a future release:

CSCsa60286 - Support IPv6 on Command & Control (Management) interface

Sensors running software version 6.2 or later do support inspection of IPv6 traffic, though
the following restrictions apply:

-The AD (Anomaly Detection) feature does not support IPv6 addresses/traffic.
-The Request Block Connection, Request Block Host, and Request Rate Limit Actions do
not support IPv6 addresses/traffic.
-The AIM-IPS and NME-IPS sensor modules do not support IPv6 traffic inspection because
the router models they are supported/installed in do not send them IPv6 data.
-The AIP-SSC-5 and AIP-SSM-10, 20, and 40 sensor modules require their host ASA to be
running software version 8.2(1) or later in order to support IPv6 traffic inspection.
-The IDSM-2 sensor module does not officially support IPv6 traffic inspection (though it may
work).

14
Licensing

The sensor requires a valid (and non-expired) .lic license-key file in order to download/install
signature definition updates and make use of the Global Correlation feature (present in
software version 7.0 and later). If no license-key file is installed or if the currently-installed
license-key file expires, these features will cease to function until a valid replacement
license-key file is installed.

To qualify for a license-key file, a sensor must be covered by an active SMARTnet and
Cisco Services for IPS (IPS SVC) contract. To purchase a contract, contact your Partner/
Reseller or Cisco Account Team.

Obtaining a License-key File

If the sensor has full Internet access, the simplest/easiest method to obtain and install a
license-key file is via the sensor GUI (IDM) or IME (IPS Manager Express)'s Configuration
> Sensor Management > Licensing section by ensuring the Update From: option is set to
Cisco.com, then clicking the Update License button.

Alternatively, the sensor's license-key file can be manually downloaded from the cisco.com
website here.

One-time 60-day "trial" or "evaluation" license-key files can be requested here.

Installing a License-key File

15
License-key files can be manually installed via the sensor GUI (IDM), IME (IPS Manager
Express), or via the sensor CLI. From IDM or IME's Configuration > Sensor Management
> Licensing section, ensure the Update From: option is set to License File, then click the
Browse Local button and locate/select the .lic license-key file on your local client machine.
Finally, click the Update License button to upload and install the license-key file onto the
sensor.

Alternatively, from the sensor CLI, the license-key file can be downloaded from a FTP,
HTTP[S], or SCP server and installed onto the sensor using the copy command. Example:

sensor# copy ftp: license-key

Manually Removing the Currently-installed License-key File

Under some circumstances it may be necessary to remove (delete) the currently-installed
license-key file from the sensor before a replacement license-key file can be installed. This
can be done by logging into the sensor CLI using a Service Account, then:

-bash-2.05b$ /bin/su -
Password: (input Service Account's password again and press <ENTER>)
-bash-2.05b# rm /usr/cids/idsRoot/shared/ips.lic

Self-signed TLS X.509 Server Certificate

16
The sensor includes a built-in HTTPS web server which provides access to the sensor GUI
(IDM) for remote management as well as access to the sensor's event store and status
information (for remote SDEE monitoring applications and devices (such as IME or CS-
MARS)). To provide security, this web server makes use of the TLS protocol. The sensor
generates a self-signed TLS X.509 server certificate when first installed (and subsequently
if/when the sensor's Management IP address is changed). This certificate is valid for two (2)
years from the date it was generated. After which it must be manually re-generated.

This problem is most-often observed when using IME (IPS Manager Express) to manage/
monitor the sensor, and an error such as the following is encountered:

"IOException when try to get certificate: java.security.cert.CertificateExpiredException:
NotAfter: "

Verifying the Sensor Certificate's Valid Date Range

In modern releases of the sensor software, this certificate's valid date range is visible at the
end of the show version command output. Example:

sensor# show version
Cisco Intrusion Prevention System, Version 7.0(5)E4
...
Host Certificate Valid from: 01-May-2011 to 01-May-2013

17
Re-generating the Sensor Certificate

If the sensor's self-signed certificate has expired (i.e. the valid date range has passed), it
will need to be re-generated by logging into the sensor using an administrative account and
then:

1.) Verifying that the sensor's clock is correct (accurately set) and if not, correcting it.
Example:

sensor# show clock12:15:00 GMT-05:00 Wed May 1 2011
sensor# clock set 12:30:00 MAY 1 2011

2.) Then issuing the following command:

sensor# tls generate-key

Both an MD5 and a SHA1 fingerprint for the new TLS certificate will be shown after the
re-generation completes. These values can be compared (if desired) to what is shown in
a remote monitoring application/device (such as IME or CS-MARS) to verify that remote
monitoring application/device is in-fact connecting to the sensor's web server.

After the sensor certificate is re-generated, it must be accepted into any remote monitoring
applications/devices in-use (such as IME and CS-MARS). To accept the new certificate in
IME, edit the sensor device via the IME Home screen's Device List and click the OK button.
When prompted, accept the new certificate.
18

Signature Definitions

The sensor primarily makes use of signature-based inspection technology to detect and
identify network intrusions and threats. Signatures consist of a set of match conditions,
parameters, and patterns. As the sensor inspects network traffic, it compares it against
active signatures. When a match is found, the sensor can take action, such as producing an
alert or denying the matched ("trigger") traffic.

The default signature policy is considered to be an optimal base signature configuration.
This policy is maintained by Cisco's IPS Signature Development team, is re-tested and
updated with each release, and focuses specifically on providing the latest threat protection
while remaining efficient performance-wise. This default policy changes between signature
definition updates (new signatures are added, old/obsolete signatures are retired, etc.). As
such, it is included with each signature definition update and is automatically updated on the
sensor when a new signature definition update is installed.

To return the sensor's current signature policy to default, login to the sensor using an
administrative account and issue the following commands:

sensor# conf t
sensor(config)# service signature-definition sig0
sensor(config-sig)# default signatures
sensor(config-sig)# exit
19

Signature Details and More Information (Does Cisco Provide a Signature for This
Threat?)

Cisco's Security Intelligence Operations site (previously referred to as "IntelliShield" or
"MySDN") hosts an interactive search tool for signatures that provides important details
(descriptions, recommended filters, known benign triggers (false positives), and associated
first and 3rd-party alerts). This is the first resource (besides reviewing signatures on the
sensor itself) to check for more information about signatures or to determine if Cisco
provides a signature for a specific threat.

If no results are found when searching for a specific threat, Cisco's IPS Signature
Development team can be reached for inquiry by emailing ips-signature-team@cisco.com .
To expedite a response, be sure to include details such as:

-Sensor software and signature definition versions (Example: 7.0(5)E4 S563)
-Specific threat name(s) in-question and any known alias(es)
-URL(s) to 3rd-party write-up(s) regarding threat

False Positives and EAFs (Event Action Filters)

If a signature is firing falsely on the sensor (against traffic that should not meet the
signature's criteria or traffic known to be non-malicious) an EAF (Event Action Filter) can be
created to prevent the sensor from taking action unnecessarily against this trigger traffic.

20
The simplest/easiest method to create an EAF is via the sensor GUI (IDM) or IME (IPS
Manager Express)'s Configuration > Policies > Event Action Rules > rules0 section. On the
right-hand side of that section is a row of tabs, the second being Event Action Filters. From
that tab/section, click the Add button to create a new EAF.

A dialog window will pop-up with fields pre-populated with default values. Generally the
Signature ID: field value should be modified to the signature in-question, the Attacker
IPv4 Address: field value should be modified to the source(s) of the False Positive,
and if applicable/known, the Victim IPv4 Address: field value should be modified to the
destination(s). Click the small button to the right of the Actions to Subtract: field to choose
which action(s) should not occur when these conditions are met. Most often this will include
the Produce Alert action and potentially others. Click the OK button and the Apply button
when done to create and activate the EAF. NOTE: EAFs do not affect existing Alerts (from
signature fires in the past), only new signature fires/actions that would occur going forward.

Full details for all available EAF fields/values can be found in the official product
configuration guide's Configuring Event Action Filters section.

Cannot Enable and Unretire All Signatures

Modern sensor signature definition releases contain more than 5,000 individual signatures,
but not all are enabled/active by-default. Which signatures are enabled/active by-default
is determined by Cisco's IPS Signature Development team and changes from release to
release as new signatures are added and old signatures become obsolete.

Users may be inclined to select and enable all signatures expecting that this would provide
the most protection possible. This however is not the case. Signatures may have been
retired for any number of reasons, such as: the signature triggered falsely, the signature
was replaced by a newer/better signature, the signature was complex or resource-intensive
enough that it imposed a noticeable performance/resource impact to the sensor, the threat
the signature detected/protected against is no longer relevant, etc.
21

As such, it is never a good idea to attempt to enable and unretire all signatures en mass.
Doing so will almost certainly result in undesirable sensor behavior (legitimate traffic
being denied, performance decreasing, sensor crashes or becomes unresponsive, etc.).
Signatures that are manually enabled and/or unretired should always be thoroughly
researched and understood prior to doing so.

Unable to Access or Reach Sensor's Management (Command &
Control) Interface

Access-List (the Sensor's Built-in Firewall for Management Traffic)

The sensor includes a firewall which utilizes an access-list to govern what remote IP
address(es) is allowed to reach its Management (Command & Control) interface. As
part of the basic initialization process, the sensor's access-list should be modified to
specify management subnets or IP addresses that require access to manage/monitor the
sensor. Until this is done, the sensor will not be reachable over the network and will only be
accessible via its Console port.

To review the sensor's current access-list entry(ies), login to the sensor using an
administrative account and issue the following command (NOTE: Most often this would be
performed over the sensor's Console port):

sensor# show conf | include access-list

22
To modify the sensor's access-list, login to the sensor using an administrative account and
issue the following commands (NOTE: In the example provided, the 192.168.0.0/24 subnet
(192.168.0.0-192.168.0.255) is added to the sensor's access-list to allow access to manage/
monitor the sensor. Replace that particular configuration line accordingly with your actual
subnet. If you need to add multiple subnets, repeat that line (one per subnet)):

sensor# conf t
sensor(config-hos-net)# access-list 192.168.0.0/24

Management (Command & Control) IP Address and Default-gateway

The sensor's Management (Command & Control) interface also needs to be assigned a
unique (not already in-use) IP address that is valid for the subnet/VLAN it is connected to.
Additionally, it needs to be provided with a valid default-gateway (route to get outside the
local network). To review the sensor's current IP address and default-gateway, login to the
sensor using an administrative account and issue the following command (NOTE: Most often
this would be performed over the sensor's Console port):

sensor# show conf | include host-ip

The syntax is <IP_ADDRESS>/<SUBNET>,<DEFAULT_GATEWAY>
23

To modify the sensor's Management (Command & Control) IP address, login to the sensor
using an administrative account and issue the following commands (NOTE: In the example
provided, the sensor's Management IP address is set to 192.168.0.2 and its default-gateway
is set to 192.168.0.1. Replace that particular configuration line accordingly with the actual
IP address and default-gateway you wish to assign the sensor and be sure it is valid for the
subnet/VLAN the sensor's Management (Command & Control) interface is connected to):

sensor# conf t
sensor(config-hos-net)# host-ip 192.168.0.2/24,192.168.0.1

Testing Basic Network Connectivity

To test basic network connectivity and to verify that the sensor is able to reach the
configured default-gateway, login to the sensor and make use of the ping command.
NOTE: In the example provided, the default-gateway that connectivity is being tested to is
192.168.0.1. Replace that particular value accordingly with the actual default-gateway IP
address that was configured on the sensor:

sensor# ping 192.168.0.1PING 192.168.0.1 (192.168.0.1): 56 data bytes64 bytes from
192.168.0.1: icmp_seq=0 ttl=255 time=0.4 ms64 bytes from 192.168.0.1: icmp_seq=1
24
ttl=255 time=1.0 ms64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.0 ms64 bytes
from 192.168.0.1: icmp_seq=3 ttl=255 time=1.0 ms

--- 192.168.0.1 ping statistics ---4 packets transmitted, 4 packets received, 0% packet
lossround-trip min/avg/max = 0.4/0.8/1.0 ms

Verifying Sensor Operation (Receiving and Inspecting Traffic)

Sensing-interface Link Status and Total Packets Received

Verify that the sensor's sensing interface(s) is both Up and receiving traffic by logging into
the sensor and issuing the following command:

sensor# show interface

In the output, find the applicable section for the sensing interface(s) in-question and confirm
that the Link Status value is "Up". If so, note the value shown for the Total Packets Received
counter. After a few seconds, run the command again and compare the current value to the
previous. If the value has increased, the sensing interface(s) in-question is Up and receiving
traffic. Example:

MAC statistics from interface GigabitEthernet0/0 Interface function = Sensing interface
25
Link Status = Up
Total Packets Received = 100

MAC statistics from interface GigabitEthernet0/0 Interface function = Sensing interface
Link Status = Up
Total Packets Received = 150

If a sensing interface's Link Status value is expected to be "Up", but is not, verify that it
is properly physically connected to a switchport or other network device. If so, verify that
the switchport or other network device is configured properly and the remote interface (the
switchport or NIC on the other network device) is not administratively-disabled ("shutdown").
If needed, try swapping cables with another that is known to be good.

If a sensing interface's Total Packets Received counter is not incrementing, check the
configuration of the switchport or other network device that the sensing interface is
connected to. If the sensing interface is supposed to be the destination of a SPAN/monitor
session, verify the SPAN/monitor configuration on the switch the sensing interface is
connected to.

Virtual-sensor Sensing-interface Assignment and Total Packets Processed

Verify that the sensor's virtual-sensor(s) has at least one (1) sensing interface assigned and
is inspecting traffic by logging into the sensor and issuing the following command:

sensor# show stat virtual
26

In the output, find the List of interfaces monitored by this virtual sensor line and confirm that
at least one (1) sensing interface(s) is listed. Additionally, find the Total packets processed
since reset line/counter and confirm its value is greater-than (>) zero (0). Example:

sensor# show stat virtual
Statistics for Virtual Sensor vs0 List of interfaces monitored by this virtual sensor =
GigabitEthernet0/0
General Statistics for this Virtual Sensor
Total packets processed since reset = 200

If there is no sensing interface(s) listed (or, if additional sensing interfaces need to be
assigned), login to the sensor using an administrative account and issue the following
commands (NOTE: In the example provided, the GigabitEthernet0/0 sensing interface is
assigned to virtual-sensor vs0. Replace that particular configuration line accordingly with
the actual sensing interface you wish to assign to the virtual-sensor. If you need to assign
multiple sensing interfaces, repeat that line (one per sensing interface)):

sensor# conf tsensor(config)# service analysis-engine sensor(config-ana)# virtual-sensor
vs0sensor(config-ana-vir)# physical-interface GigabitEthernet0/0sensor(config-ana-vir)# exit
sensor(config-ana)# exitApply Changes?[yes]: yes

NOTE: The above example assigns a Promiscuous sensing interface to the vs0 virtual-
sensor. Inline sensing interfaces must first be "paired" together and then the logical pair
assigned to a virtual-sensor. Details can be found in the official product configuration guide's
Configuring Interfaces section.

27

IDSM-2 Sensor Module - errSystemError -ct-sensorApp.XXX not
responding, please check system processes - The connect to
the specified Io::ClientPipe failed.

Symptom:

When attempting to access an IDSM-2 sensor via its GUI (IDM) or via IME (IPS Manager
Express), an error such as the following is encountered:

"errSystemError -ct-sensorApp.XXX not responding, please check system processes - The
connect to the specified Io::ClientPipe failed."

Additionally, review of the 'show version' command output indicates the AnalysisEngine
(sensorApp process) to be "Not Running".

Conditions:

IDSM-2 sensor module running 7.0(x) software release. Global Correlation Inspection
feature enabled (On). A 'show tech' command output includes a sensorApp process core
containing lines similar to the following:

cat /usr/cids/idsRoot/core/sensorApp/core.txt
28
...
/usr/cids/idsRoot/bin/
sensorApp(_ZN3Cid3Rep9RepIpData13ApplyIpUpdateEPKcPNS0_8RepScoreE+)

Solution:

This problem is tracked as defect CSCti79423. It can be encountered on the IDSM-2
platform when a Global Correlation Update occurs. A fix for this is currently planned for
inclusion in the next 7.0 release (7.0(6)).

In the interim, the only workaround to ensure that the sensor does not re-encounter this
defect is to disable Global Correlation Inspection (Updates) as such:

sensor# conf t
sensor(config-glo)# global-correlation-inspection off

After making the above configuration change, a reboot of the affected IDSM-2 sensor
module should restore it to service:

sensor# reset

Cisco IPS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco IPS

Uploaded by

Copyright:

Available Formats

Postings may contain unverified user-created content and change frequently.

The content is provided as-is and

You might also like