This document answers the most Frequently Asked Questions (FAQs) related to Cisco Secure Intrusion Detection System (IDS) 4.0, Advanced Inspection and Prevention Security Services Module (AIP SSM), and Cisco Intrusion Prevention System (IPS) 5.0 and later.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
A. The easiest way to perform this is to bring up your new VMS server, and then discover the Sensors with this new box.
Note: When you add the Sensor, do not add it manually. Check the discover settings box.
Once the Sensor is discovered, import it into SecMon. All the configurations are saved on the Sensor. The signature settings, filters, and so forth should come across after you build your new server. Make sure you update IDS MC to the latest signatures.
A. This is a manufacturing issue. Some customers received IDS-4215s with a bad base image (4.0). Complete these steps.
- Download the recovery partition image ( registered customers only) .
- Apply the recovery partition image upgrade through the CLI:
sensor#configure terminal sensor(config)#upgrade METHOD://USERNAME@SERVER/PATH/ IDS-4215-K9-r-1.1-a-4.1-1-S47.tar.pkg- Once the recovery partition image is applied, the 4215 is restored to a normal running 4.1(1) 4215 base.
sensor(config)#recover application-partition
Note: Cisco VMS and CLI customers do not experience this issue.
The cause of the problem is the sorting logic that is used when the filename is parsed. It is an alphanumeric sort when it should be numeric. The workaround is to use CLI (or VMS) to upgrade to 3-digit sig level packages, such as S100 or later. Once this is completed, the auto-update begins to function again. Refer to Cisco bug ID CSCef07999 ( registered customers only) for more information.
A. In order to solve this issue, use default password (cisco) two times and then change the password from the config mode. The IDS requires the default password to be entered twice.
For example:
login:cisco Password:cisco Enter current password:cisco Enter new password: *** Re-enter new password: ***
A. The module should be removed only after you disable the power. Complete these steps:
- From the sensor CLI, issue the reset powerdown command.
- Once the sensor completes shutdown, from the switch CLI, issue either the no power enable module (module_number) command for Cisco IOS or the set module power down (module_number) command for CatOS.
- Press the shutdown button on the blade.
- Physically power down the chassis. When the status light displays a longer green, you can remove the module safely.
A. Block host blocks all packets from that source address. Block connection only blocks the one connection based on source and destination IP/port. The PIX works in a slightly different manner. For automatic shuns, the Sensor sends the source IP, destination IP, source port, and destination port. The PIX blocks all packets that originate from that IP address. The additional information is used by the PIX to remove that one connection from its connection tables. If the connection has not been removed from the connection table, then it is theoretically possible that if the shun is removed shortly after it is applied, then the original connection might not have timed out yet. This allows the attacker to continue the attack on the original connection. The removal of the connection from the table ensures that the original connection cannot be used to continue the attack after the shun is removed. The Sensor cannot shun a single connection on the PIX because the PIX does not support the use of the shun command in order to shun a single connection. The PIX shun command always shuns the source address regardless of whether or not the additional connection information is provided.
A. This error means that your default gateway is incorrect or a generic error message that means that either the IP, netmask, or default gateway are incorrect. The Fatal part of the message means that after the first failure, the previous configuration was applied and also failed. The Sensor issues ifconfig and route commands and one or both of them fails.
A. This issue might be the auto update feature, which does not work, because it is set to download at an even hour. Try to set the auto update to a random time; even a small offset of eight or night minutes can fix this problem.
In general, the issue is resolved and the Error: http error response: 500 error message is be seen if you change the retrieval time to a non-hourly boundary.
Note: IPS fails the auto-update of signatures and returns with this error message:
AutoUpdate exception: HTTP connection failed [1,110] name=errSystemError
Verify these items in order to resolve this issue:
Verify if a firewall is preventing the sensor from reaching Cisco.com.
Verify if routing becomes an issue.
Verify if NATing is properly configured on the gateway device for the downstream device.
Verify if the user credentials are correct.
Change the update start time to odd hours.
A. In order to resolve this issue, try to reload the sensor or reimage the sensor.
A. Complete these tasks in order to resolve this issue:
Disable global correlation.
Add the proxy/dns configuration.
A. IPS is unable to get to internet because of a port issue, for example, a firewall in a path that does not have the right ports open for the Internet access or it can be a NAT issue.
For global correlation to function completely, the sensor first contacts through https update-manifests.ironport.com in order to authenticate the user and then an HTTP connection to download GC updates. The files that the sensor downloads from the HTTP (updates.ironport.com) are the reputation data that global correlation uses. The https update-manifests.ironport.com should always resolve to the X.X.82.127 address, but the http updates.ironport.com IP address can change, which depends on the Internet you access. So you must check the IP address. If URL filtering is enabled, add an exception for the IPS management interface IP in the URL filter, so that IPS can connect to the Internet.
This error occurs when there is corruption in a previous GC update:
collaborationApp[459] rep/E A global correlation update failed: Failed download of ibrs/1.1/drop/default/1296529950 : URI does not contain a valid ip address
This issue can usually be corrected by turning off the GC service and then turning it back on. In IDM, choose Configuration > Policies > Global Correlation > Inspection/Reputation, set Global Correlation Inspection (and Reputation Filtering if On) to Off, apply the changes, wait for 10 minutes, turn the features on, and monitor.
A. Verify these items:
You must have a valid IPS license in order to allow global correlation features to function.
You must have an HTTP proxy server or a DNS server configured in order to allow global correlation features to function.
Because global correlation updates occur through the sensor management interface, firewalls must allow tcp 443/80 and udp 53 traffic.
Make sure your sensor supports the global correlation features. If you do not want this, disable the global collaboration feature from IDM:
Go to Configuration > Policies > Global Correlation > Inspection/Reputation, and set Global Correlation Inspection (and Reputation Filtering if On) to Off.
A. If you use global correlation (GC) then make sure that name resolution works, for example, DNS is reachable. Also check if there is a firewall blocked port 53. Otherwise, you can turn off the GC feature if you wish to get rid of this message.
A. This issue usually occurs when customer attempt to run IME on unsupported operating systems, such as Windows 7.
A. Clear the browser cache in order to resolve this issue.
A. In version 6.0, Asymmetric mode on IPS that is configurable using CLI only and not available on GUI. But, in version 6.1 this feature is also available in GUI.
A. In order to resolve this issue, enable the asymmetric mode processing in order to allow the sensor to synchronize state with the flow and maintain inspection for those engines that do not require both directions. Use this configuration:
IPS_Sensor#configure terminal IPS_Sensor(config)#service analysis-engine IPS_Sensor(config-ana)#virtual-sensor vs0 IPS_Sensor(config-ana-vir)#inline-TCP-evasion-protection-mode asymmetricThe latency issue occurs when the deny action inline and deny packet are enabled for every signature in VS0. Enabling all the signatures will result in latency as IPS inspects every single packet passing through. It is good to enable only the specific signature required as per the network traffic flow in order to resolve the latency issue.
A. The PIX/ASA is not able to block the skype traffic. Skype has the capacity to negotiate dynamic ports, and to use encrypted traffic. With encrypted traffic, it is virtually impossible to detect it as there are no patterns to look for.
You could eventually use a Cisco IPS (Intrusion Prevention System)/AIP-SSM. It has some signatures that are able to detect a Windows Skype Client that connects to the Skype server to synchronize its version. This is usually done when the client is initiated the connection. When the sensor picks up the initial Skype connection, you can be able to find the person who use the service, and block all connections initiated from their IP address.
A. During a signature update and reconfigurations, sensorApp stops to process packets as it processes the new signatures in the update. The network driver detects that sensorApp has stopped and pulls any new packets from the buffer. So the network driver does different things, which depends on the configuration and sensor model:
Promiscuous Interface—It brings the link down on the interfaces, and brings the link back up once sensorApp starts to monitor again.
Inline Interface or Inline Vlan Pair—It depends on the Bypass setting:
Bypass Auto—The driver keeps the link up and begins to pass packets through without analysis. It then reverts back to sending the packets through sensorApp once sensorApp starts to monitor again.
Bypass Off—The driver brings the link down on the interfaces, which is the same as in promiscuous mode, and brings them back up once sensorApp starts to monitor again.
So, if sensor app does not pull packets from the buffer, which possibly occurs because there is no interface configured to process packets, then the driver can put the interface in a down state.
These logs are seen when the sensing interface flaps:
28Jun2011 09:03:09.483 6050.885 interface[409] Cid/W errWarning Inline databypass has started. 28Jun2011 09:03:13.639 4.156 interface[409] Cid/W errWarning Inline databypass has stopped. 28Jun2011 09:19:23.922 970.283 interface[409] Cid/W errWarning Inline databypass has started. 28Jun2011 09:19:27.486 3.564 interface[409] Cid/W errWarning Inline databypass has stopped.
A. No, the sensor does not maintain a password history. Passwords are not viewable at any time.
A. No.
A. The local event of the sensor stores only 30 MB and begins to overwrite itself once the 30 MB limit is reached. This limit is non-configurable.
A. Use the STRING.TCP in order to write a signature that detects the attachment. Look for something similar to this:
Engine STRING.TCP Enabled True Severity informational AlarmThrottle Summarize CapturePacket False Direction ToService MinHits 1 Protocol =TCP RegexString [Ff][Ii][Ll][Ee][Nn][Aa][Mm][Ee][=]["][Ff][Oo] [Tt][Oo][a-zA-Z][.][Zz][Ii][Pp]["] ResetAfterIdle 15 ServicePorts 25 StorageKey =STREAM
A. Issue these commands:
configure terminal service host networkParams ftpTimeout 300 <timeout is in seconds>
A. This output is a decimal representation of the current time since UNIX epoc. Use a UNIX epoc calculator such as the one located at the UNIX Date/Time Calculator site. Enter the first 10 digits because this calculator is granular to only seconds, and the IDS stores nanoseconds. This means the last nine digits are stripped off. From the Start time in this output, 1084798479 = Mon May 17 12:54:39 2004 (GMT) is what you receive.
From the CLI, enter iplog-status in order to receive this output:
" Log ID: 138343946 IP Address: xxx.xxx.xxx.xxx Group: 0 Status: completed Start Time: 1084798479512524000 End Time: 1084798510136582000 Bytes Captured: 2833 Packets Captured: 14 "
A. In order to solve this error message, login into the AIP-SSM and issue the tls generate-key command in privileged EXEC mode as shown in this example:
sensor#tls generate-keyNote: This resolution of using the command tls generate-key also resolves the issue of AIP-SSM not being able to connect to the IME.
A. In order to solve this error message, choose Control Panel > Admin Tools > Services and restart IME services.
A. This indicates broken communication between the IME and the IPS sensor. Make sure that there is no software that blocks the SDEE.
A. In order to solve this error message, verify that correct IP address is used when you add IPS in IME and also check any software firewall that is running on IME computer, which can block the connection.
A. The IDS sensor does not have the ability to send email alerts on its own. Security Monitor when used with IDS has the ability to send email notifications when an Event Rule is triggered by the sensor.
Refer to Configure E-mail Notifications for more information on how to configure email notifications with Security Monitor.
Cisco IPS Manager Express (IME) can be configured to send the email notification message (alerts) when Event Rules are triggered by Cisco IPS Sensors. Refer to IPS 6.X and later: Email Notifications using IME Configuration Example for more information.
A. Reboot the sensor in order to resolve this issue.
A. Retire the signatures that are not in use in order to resolve this issue and also the number of customer signatures with regexes should be reduced. Also, it is not recommended to use * and + metacharacters in regexes.
A. The latency issue can occur due to the assymetric routing. Try to disable the signature 1330 in order to resolve this issue.
A. Right now it is not possible to disable SSHv1 and leave only SSHv2 enabled. Both SSHv1 and SSHv2 are enabled together and cannot be disabled individually.
A. This error message occurs due to insufficient memory in the sensor.
Complete these tasks in order to resolve this issue:
- Log into service account and become root
- Remove the following directories as shown below:
# rm -rf /usr/cids/idsRoot/var/updates/files/S69 # rm -rf /usr/cids/idsRoot/var/updates/files/common # rm /usr/cids/idsRoot/var/virtualSensor/* # rm /usr/cids/idsRoot/var/.tmp/*- Now try to upgrade the sensor. Refer to Cisco bug ID CSCsb81288 ( registered customers only) for more information.
A. The mainApp[396] cplane/E Error - accept() call returned -1 error message indicates that Web server cannot read the file, and accept() program failed, which yields file descriptors when TLS connections exist. But this file is not needed for normal behavior. It is harmless.
A. This error message indicates that the certificate is no longer valid on the module. Complete these steps in order to resolve the issue:
Regenerate the certificate from the CLI:
Log in to the sensor command line.
Issue the tls generate command, and press enter. Note the fingerprints that are displayed.
Pull the new certificate in to IME:
Open the IME and locate the sensor name in the list on the Home page.
Right-click the sensor, and click Edit.
When you reach the Edit Device screen, click OK. Bypass any warning about not being able to retrieve the sensor time.
You will be prompted with the new security certificate (the one that you just generated). Check to make sure the fingerprints match, and click Yes.
After several seconds, the sensor should show "Connected" in the Event Status again.
A. In order to resolve this error, use the reset command in order to reboot the IPS.
A. In order to resolve this issue, use the NTP server to synchronize the time on the Cisco Adaptive Security Appliance(ASA) and AIP-SSM.
Refer to Configuring NTP on IPS sensors for more information.
A. Virtual sensors on AIP-SSM cannot be applied per interface because the AIP-SSM has only one interface. When you create multiple virtual sensors, you must assign this interface to only one virtual sensor. You do not need to designate an interface for the other virtual sensors.
After you create virtual sensors, you must map them to a security context on the Adaptive Security Appliance (ASA) using the allocate-ips command. You can map many security contexts to many virtual sensors. Refer to the Assigning Virtual Sensors to Adaptive Security Appliance Contexts section of Configuring AIP-SSM for more information.
A. A maximum number of four virtual sensors can be supported.
A. It is not possible with a TACACS+ server but RADIUS is supported from the IPS 7.0.(4)E4 release. Refer to the New and Changed Information and Restrictions and Limitations sections of the Release Notes for Cisco Intrusion Prevention System 7.0(4)E4 for more information. Also, refer to IPS 7.X: User Login Authentication using ACS 5.X as Radius Server Configuration Example for a sample configuration.
A. The only impact an expired license has on the sensor is that it halts the signature updates.
A. No. The IPS signature updates do not have an impact on the services or the network connectivity.
A. The link required to allow the IPS module to update automatically with the latest signature is: https://198.133.219.25/cgi-bin/front.x/ida/locator/locator.pl.
You must use your Cisco user ID and password to complete the update of the IPS module.
Note: In the 6.x train of code, automatic updates from Cisco.com are not supported. You must manually download the signature files and apply them to the sensor. There is an auto-update function in the 6.x code; however, this is possible only from a local file server in which the signature files must be manually downloaded as well.
A. No. It is not vulnerable for these reasons:
The sensor does not have X11 libraries. Therefore there are no sessions to hijack.
X11 port forwarding is not enabled in the SSH configuration.
IPv6 is not compiled into the sensor kernel. This is required in order to exploit the vulnerability.
A. This happens because when the ASA blocks something, it is not passed to the IPS for duplicate inspection. Therefore, you cannot see duplicate logs on the ASA and IPS.
A. This is the complete error message:
evError: eventId=1284051856322985135 vendor=Cisco severity=warning originator: hostId: vbintestids03 appName: sensorApp appInstanceId: 700 time: offset=-240 timeZone=GMT-05:00 1286305251136551000 errorMessage: name=errWarning invalidValue:Editing string-xl-tcp sig 21619 has NO effectThis issue comes up because the string-xl-tcp or string-tcp-xl engine is not supported on the hardware. For more details, refer to the IPS Engine E4 Release Notes.
A. This output shows the complete error message:
autoUpgradeServerCheck: uri: https://XX.XX.XX.XX//cgi-bin/front.x/ida/locator/locator.pl packageFileName: result: No installable auto update package found on server status=trueThis error has been generated and the signatures do not automatically update because the Signature definition updates after S479 require the E4 engine. In order to resolve this, you need to manually upgrade the Sensor to 7.0(2)E4.
Note: The Sensor is not able to automatically upgrade itself to E4 because it requires 7.0(2) and a reboot of the Sensor.
A. This output shows the complete error message:
autoUpgradeServerCheck: uri: ftp://hfcu-inet01@192.168.1.12//ips-update/ packageFileName: result: No installable auto update package found on server status=trueThis issue occurs because of an improper directory listing style with the FTP server. In order to resolve this, switch to UNIX-style directory listings from the existing MS-DOS style directory listings.
In order to modify the directory listing settings, select Start > Program Files > Administrative Tools in order to open the Internet Services Manager. Then go to the Home Directory tab and change the directory listing style from MS-DOS to UNIX.
A. This issue is due to the failure of the analysis engine and is addressed in Cisco bug ID CSCtb39179 ( registered customers only) . Upgrade the sensor to version 7.0(4)E4 in order to fix this issue.
A. This issue occurs when the license file received is invalid. To obtain a valid license file, log in to Cisco.com as a registered user, and download the appropriate license file. Once you obtain the valid license file, install it on your sensor.
If you install the new license file and you still receive an error, there might be an issue with the existing invalid license file. In order to resolve this issue, complete these steps to delete the existing invalid license file:
Log in to the service account by typing your service account user name.
If you do not have a service account, open the IPS command line, enter configuration mode, and enter this command
username name privilege service password password
ciscoasa# session 1 Opening command session with slot 1. Connected to slot 1. Escape character sequence is 'CTRL-^X'. login: Password: IPS# IPS#conf t IPS(config)# username name privilege service password passwordOnce you log in to your service account, enter the su command in order to go to root (using the same password as the service account).
Delete the files in the /usr/cids/idsRoot/shared/ directory.
Note: Do not delete the host.conf file.
Enter the cd /usr/cids/idsRoot/shared/ command in order to go to the shared directory.
Enter the ls command in order to view the files in the directory.
Enter the rm file_name command in order to remove the files.
Note: Do not delete the host.conf file.
Enter the /etc/init.d/cids restart command to restart the sensor.
Install the new license.
A Cisco bug has been filed to address this behaviour. For more information, refer to CSCtg76339 ( registered customers only) .
A. This error is caused by an excessive amount of packets on IP logging. Disable the IP logging feature in order to resolve this issue. IP logging is meant for troubleshooting only; Cisco recommends that you do not enable it for all the signatures.
A. Modification of signature 23899.0 causes this issue. Refer to Cisco bug ID CSCtn84552 ( registered customers only) for more information.
A. Check if there is URL filtering, content filtering, or a proxy server present that is blocking the autoUpdate from happening. Make sure that autoUpdate is not being blocked and also verify that the user credentials provided are correct.
A. This behavior has been addressed by Cisco bug ID CSCsq50873 ( registered customers only) . This is a cosmetic issue and does not create any operational overhead except the excessive amount of logs being received. A temporary workaround is to remove the NTP related configuration on the sensor. For a permanent solution, upgrade to a version in which this bug is fixed.
A. IME functions as two Windows services and the GUI client. When the client is closed, the two Windows services (Cisco IPS Manager Express and MySQL-IME) continue to run and collect events from the managed sensors and store them in the local MySQL database; this allows for historical reporting to occur.
The IME client should open a single SDEE subscription to the managed sensor, and re-use this subscription for subsequent event retrieval activity. The constant connectivity from the IME workstation to the managed sensors is expected behavior.
A. No. The AIP-SSM module cannot be used as a SPAN target as it is used only to monitor the traffic flowing through the ASA interface.
A. With E3 engine updates, the IPS uses a different algorithm for managing its idle time and spends more time polling for packets to reduce latency. This increased checking causes a corresponding increase in the CPU usage. The correct way to measure the CPU in E3 is not by CPU usage, but by the Packet load percentage which shows the correct CPU utilization.
A. This could happen because of an incorrect certificate on the remote maanagement station, running software such as CS-MARS, CSM, IEV, VMS-IDS/IPSMC, etc. In order to resolve this issue, complete these steps:
Apply the sensor's TLS certificate on the remote management station.
Configure a valid DNS server.
A. Configuring the sensor to work in asymmetric mode will resolve the issue. In order to put the sensor in asymmetric mode protection, complete these steps:
Go to Configuration > Policies > IPS policies.
Double-click virtual sensor.
Go to advance options.
Under normalize mode, select Asymmetric mode protection.
Click OK.
Reboot the unit in order for the changes to take effect.