cisco-ips

Postings may contain unverified user-created content and change frequently. The content is provided as-is andis not warrantied by Cisco.

1

IDS/IPS - Top Commonly-EncounteredProblems (and Solutions)

IDS/IPS - Top Commonly-EncounteredProblems (and Solutions)

This is a TAC-maintained document containing a list of what TAC considers the topproblems (and questions) users may encounter with Cisco IDS/IPS sensor products. Thepurpose 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 1Auto/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

15Self-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)


2

• Re-generating the Sensor Certificate on page 17Signature Definitions on page 18

• Signature Details and More Information (Does Cisco Provide a Signaturefor 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 onpage 21

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

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

• Testing Basic Network Connectivity on page 23Verifying Sensor Operation (Receiving and Inspecting Traffic) on page 24

• Sensing-interface Link Status and Total Packets Received on page24

• Virtual-sensor Sensing-interface Assignment and Total PacketsProcessed on page 25

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

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 ona defined schedule, referred to as "Auto/Cisco.com Update". This functionality can reducerecurring administrative overhead (vs. manually downloading and installing updates) andhelps ensure the sensor is detecting/protecting against the latest threats.

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



3

Enabling and Configuring Automatic Updates

The simplest/easiest method to enable and configure the Auto/Cisco.com Update featureis via the sensor GUI (IDM) or IME (IPS Manager Express)'s Configuration > SensorManagement > Auto/Cisco.com Update section. From that section, ensure the EnableSignature and Engine Updates from Cisco.com check-box is checked and click theCisco.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 definitionupdates 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 IPaddress 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 downloadserver information (IP address and path).

The sensor then attempts to connect to the download server over TCP port 80 and todownload the update package. The download server's IP address may and will change; assuch, 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 needto be modified to permit the sensor access.



4

The Auto/Cisco.com Update feature does NOT support connectivity through non-transparentproxy servers or any other system which requires authentication or other interaction/response. Caching systems, content filters, and traffic optimizers or shapers may alsointerfere with/deny/invalidate Auto/Cisco.com Update traffic, preventing the feature fromfunctioning. The sensor's Management (Command and Control) IP address should beexcluded/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 thesensor 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 theFrequency: value to Hourly - Every 1 hours, and setting the Start Time: a few minutes aheadof 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 detailscan 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://[email protected]//swc/esd/guest/ = Success lastDownloadAttempt = 12:20:00



5

GMT-05:00 Wed May 01 2011 = Download: http://[email protected]//swc/esd/guest/IPS-sig-S563-req-E4.pkg = Success lastInstallAttempt = 12:20:30 GMT-05:00 Wed May 012011 = 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/passwordcombinations), connectivity failures (the sensor being unable to reach or download fromcisco.com) are most common. See the Connectivity Requirements for Automatic Updatessection 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). Asnew events occur, the buffer fills. When it reaches capacity, new events override the oldestevents. This buffer serves as temporary storage for event data long enough for a configuredremote 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 andSNMP. 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 externalmonitoring applications/devices (such as IME (IPS Manager Express) and CS-MARS) canbe configured to send Email Alert Notifications).

SDEE (Security Device Event Exchange)

https://supportforums.cisco.com/docs/DOC-16545#Connectivity_Requirements_for_Automatic_Updates



6

SDEE (Security Device Event Exchange) is an application-level protocol used to exchangedata 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 (IPSManager 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 dataexchange. 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 toadd 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. UnlikeSDEE, SNMP Traps (aka "notifications") are not enabled by-default. If configured, thesensor is considered a SNMP Agent, sending SNMP Traps to one (1) or more SNMP TrapDestinations ("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 configurea SNMP Trap Destination, login to the sensor using an administrative account and issuethe following commands (NOTE: In the example provided, the configured SNMP TrapDestination has an IP address of 192.168.0.20. Replace that particular configuration lineaccordingly 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

https://supportforums.cisco.com/docs/DOC-16545#AccessList_the_Sensors_Builtin_Firewall_for_Management_Traffic



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 Actioncan be added to an EAO (Event Action Override) to remedy this (causing the Action to beadded whenever a signature fires). To configure such an EAO, login to the sensor usingan administrative account and issue the following commands (NOTE: In the exampleprovided, all Alerts (regardless of Risk Rating) will apply. If you only want SNMP Traps to begenerated 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 specificsignatures, 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 packetsrelating to a signature firing: Log Attacker Packets, Log Victim Packets, and Log PairPackets. These IP Logging Actions are intended for troubleshooting or use under very-controlled circumstances (where the Action(s) will not occur repeatedly). If the sensoris configured in a way that results in one (1) or more of these Actions recurring insuccession, 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-signaturebasis, with the understanding that the sensor's primary purpose is not to capture and storepacket 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 reputationfor malicious activity, referred to as "Global Correlation". The reputation data containedin 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 ifthe Attacker IP address is present in the Global Correlation database. Potentially, it can alsoadd 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 Correlationsection.

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) ormore valid, reachable DNS server(s).

To configure a DNS server, login to the sensor using an administrative account and issuethe following commands (NOTE: In the example provided, the configured DNS server has anIP address of 192.168.0.10. Replace that particular configuration line accordingly with youractual 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


http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_collaboration.html#wp1050709



10

Connectivity Requirements for Global Correlation Inspection Updates

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

Once resolved, the sensor attempts to connect to update-manifests.ironport.com overTCP port 443. If successful, it retrieves a list of current update files and download serverinformation (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. Sincethe download server's IP address may and will change between requests, generally thesensor requires full, unfiltered outbound Internet access for the Global Correlation Inspection(Updates) feature to function. Outbound access-lists on firewalls/routers may need to bemodified to permit the sensor access.

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

Testing the Global Correlation Inspection (Updates) Feature

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

http://www.akamai.com



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 tooccur every 300 seconds (5 minutes)).

Troubleshooting Global Correlation Inspection (Update) Failures

After a Global Correlation Inspection (Update) attempt has occurred, success/failureindicators 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 downloadserver(s)) are most common. See the Connectivity Requirements for Global CorrelationInspection 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 (andInternet) 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.

https://supportforums.cisco.com/docs/DOC-16545#Connectivity_Requirements_for_Global_Correlation_Inspection_Updates

https://supportforums.cisco.com/docs/DOC-16545#Connectivity_Requirements_for_Global_Correlation_Inspection_Updates

https://supportforums.cisco.com/docs/DOC-16545#Management_Command__Control_IP_Address_and_Defaultgateway

https://supportforums.cisco.com/docs/DOC-16545#Management_Command__Control_IP_Address_and_Defaultgateway

https://supportforums.cisco.com/docs/DOC-16545#Enabling_and_Configuring_Global_Correlation_Inspection_Updates

https://supportforums.cisco.com/docs/DOC-16545#Licensing



13

IPv6

The sensor does not currently support management or monitoring via IPv6. There is anexisting, 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, thoughthe 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 donot support IPv6 addresses/traffic.

-The AIM-IPS and NME-IPS sensor modules do not support IPv6 traffic inspection becausethe 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 berunning 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 maywork).

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsa60286



14

Licensing

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

To qualify for a license-key file, a sensor must be covered by an active SMARTnet andCisco 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 alicense-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 toCisco.com, then clicking the Update License button.

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

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

Installing a License-key File

https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet?FormId=1017

https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet?FormId=1016



15

License-key files can be manually installed via the sensor GUI (IDM), IME (IPS ManagerExpress), 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 theBrowse 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 thesensor.

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-installedlicense-key file from the sensor before a replacement license-key file can be installed. Thiscan 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

http://www.cisco.com/en/US/docs/security/ips/7.0/command/reference/crCmds.html#wp458440

http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_setup.html#wp1073485



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 statusinformation (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 sensorgenerates a self-signed TLS X.509 server certificate when first installed (and subsequentlyif/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 theend 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), itwill need to be re-generated by logging into the sensor using an administrative account andthen:

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 there-generation completes. These values can be compared (if desired) to what is shown ina remote monitoring application/device (such as IME or CS-MARS) to verify that remotemonitoring 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 monitoringapplications/devices in-use (such as IME and CS-MARS). To accept the new certificate inIME, 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 andidentify network intrusions and threats. Signatures consist of a set of match conditions,parameters, and patterns. As the sensor inspects network traffic, it compares it againstactive signatures. When a match is found, the sensor can take action, such as producing analert 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 andupdated with each release, and focuses specifically on providing the latest threat protectionwhile remaining efficient performance-wise. This default policy changes between signaturedefinition updates (new signatures are added, old/obsolete signatures are retired, etc.). Assuch, it is included with each signature definition update and is automatically updated on thesensor when a new signature definition update is installed.

To return the sensor's current signature policy to default, login to the sensor using anadministrative 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 associatedfirst and 3rd-party alerts). This is the first resource (besides reviewing signatures on thesensor itself) to check for more information about signatures or to determine if Ciscoprovides a signature for a specific threat.

If no results are found when searching for a specific threat, Cisco's IPS SignatureDevelopment team can be reached for inquiry by emailing [email protected] .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 thesignature's criteria or traffic known to be non-malicious) an EAF (Event Action Filter) can becreated to prevent the sensor from taking action unnecessarily against this trigger traffic.

http://tools.cisco.com/security/center/search.x?currentPage=&toggle=1&search=Signature

mailto:[email protected]



20

The simplest/easiest method to create an EAF is via the sensor GUI (IDM) or IME (IPSManager Express)'s Configuration > Policies > Event Action Rules > rules0 section. On theright-hand side of that section is a row of tabs, the second being Event Action Filters. Fromthat 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 theSignature ID: field value should be modified to the signature in-question, the AttackerIPv4 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 thedestination(s). Click the small button to the right of the Actions to Subtract: field to choosewhich action(s) should not occur when these conditions are met. Most often this will includethe Produce Alert action and potentially others. Click the OK button and the Apply buttonwhen done to create and activate the EAF. NOTE: EAFs do not affect existing Alerts (fromsignature 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 productconfiguration 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-defaultis determined by Cisco's IPS Signature Development team and changes from release torelease as new signatures are added and old signatures become obsolete.

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

http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_event_action_rules.html#wp1030749



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 trafficbeing denied, performance decreasing, sensor crashes or becomes unresponsive, etc.).Signatures that are manually enabled and/or unretired should always be thoroughlyresearched 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 IPaddress(es) is allowed to reach its Management (Command & Control) interface. Aspart of the basic initialization process, the sensor's access-list should be modified tospecify management subnets or IP addresses that require access to manage/monitor thesensor. Until this is done, the sensor will not be reachable over the network and will only beaccessible via its Console port.

To review the sensor's current access-list entry(ies), login to the sensor using anadministrative account and issue the following command (NOTE: Most often this would beperformed 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 andissue 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 actualsubnet. 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 aunique (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 thelocal network). To review the sensor's current IP address and default-gateway, login to thesensor using an administrative account and issue the following command (NOTE: Most oftenthis 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 sensorusing an administrative account and issue the following commands (NOTE: In the exampleprovided, the sensor's Management IP address is set to 192.168.0.2 and its default-gatewayis set to 192.168.0.1. Replace that particular configuration line accordingly with the actualIP address and default-gateway you wish to assign the sensor and be sure it is valid for thesubnet/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 theconfigured 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 is192.168.0.1. Replace that particular value accordingly with the actual default-gateway IPaddress that was configured on the sensor:

sensor# ping 192.168.0.1PING 192.168.0.1 (192.168.0.1): 56 data bytes64 bytes from192.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 bytesfrom 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% packetlossround-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 intothe sensor and issuing the following command:

sensor# show interface

In the output, find the applicable section for the sensing interface(s) in-question and confirmthat the Link Status value is "Up". If so, note the value shown for the Total Packets Receivedcounter. After a few seconds, run the command again and compare the current value to theprevious. If the value has increased, the sensing interface(s) in-question is Up and receivingtraffic. 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 itis properly physically connected to a switchport or other network device. If so, verify thatthe switchport or other network device is configured properly and the remote interface (theswitchport 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 theconfiguration of the switchport or other network device that the sensing interface isconnected to. If the sensing interface is supposed to be the destination of a SPAN/monitorsession, verify the SPAN/monitor configuration on the switch the sensing interface isconnected 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 andis 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 thatat least one (1) sensing interface(s) is listed. Additionally, find the Total packets processedsince 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 beassigned), login to the sensor using an administrative account and issue the followingcommands (NOTE: In the example provided, the GigabitEthernet0/0 sensing interface isassigned to virtual-sensor vs0. Replace that particular configuration line accordingly withthe actual sensing interface you wish to assign to the virtual-sensor. If you need to assignmultiple sensing interfaces, repeat that line (one per sensing interface)):

sensor# conf tsensor(config)# service analysis-engine sensor(config-ana)# virtual-sensorvs0sensor(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 pairassigned to a virtual-sensor. Details can be found in the official product configuration guide'sConfiguring Interfaces section.

http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_interfaces.html#wp1046883



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 ManagerExpress), an error such as the following is encountered:

"errSystemError -ct-sensorApp.XXX not responding, please check system processes - Theconnect 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 Inspectionfeature enabled (On). A 'show tech' command output includes a sensorApp process corecontaining 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-2platform when a Global Correlation Update occurs. A fix for this is currently planned forinclusion in the next 7.0 release (7.0(6)).

In the interim, the only workaround to ensure that the sensor does not re-encounter thisdefect 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 sensormodule should restore it to service:

sensor# reset

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCti79423

cisco-ips

Documents

automatic updates

updates andhelp

update sensors

update feature

signature definition

management traffic onpage

cisco idsips sensor

verifying sensor operation