You are likely hitting a new bug CSCtz29196.  It was just written up today, and may not be available on the external Cisco.com page yet. The bug is "Unable to upgrade signature package to S639 or S640 when 3255/0 is tuned". Signature 3255/0 was modified in S639 in a way which may not be compatible with previous edits made to this signature. This will be corrected in the next Signature Update. I have not looked at your show tech output, but there may still be other issues on your sensor that Sawan is referring to. Sawan is likely looking at errors in the main.log portion of your show tech output. ... View more

Neither of these configurations on their own will send packets to the IPS module for analysis. The configuration must include a policy where a class of traffic is directed for to the IPS module for monitoring using either the "ips inline ..."  or "ips promiscous ..."  commands. Here is a config example written for an earlier ASA version, that will demonstrate how to create the policy. http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807335ca.shtml ... View more

You have access-lists applied to your GigabitEthernet0/3/0.1. Do you have traffic to/from the sensor's 192.168.200.99 address permited in these access lists? ... View more

The 0.0.0.0 address appears in Summary Alerts. Multiple signature triggerings have been Summarized into a single Alert.  Instead of listing every address from the individual triggerings the Summary alert will put 0.0.0.0 in for either the source address, destination address, or both addresses depending on the type of Summarization being done. You can tune the signature itself to disable Summarization if you really need to see the individual addresses. Keep in mind, however, that Summarization is used to keep the sensor from flooding your monitoring station with alerts for every triggering. ... View more

The difference between 7.0(5) and 7.0(5a) is just which Signature Update is included. 7.0(5) included S558 7.0(5a) included S549 The reason for including a lower signature update in 7.0(5a) is because of an issue that happened in the S550 Signature Update. There was a change to default signatures which could cause issues in configuration. The Signature Update installations could handle the problem and allow users to correct the issue. The Service Pack installation, however, is not able to detect the problem and could lead to a larger problem. So in order to prevent a Service Pack from encountering the issue we re-issued the 7.0(5) Service Pack as a 7.0(5a) Service Pack and put in a Signature level prior to the one that could cause the situation. Both 7.0(5) and 7.0(5a) have all of the same other files on the sensor. And if you upgrade 7.0(5) and 7.0(5a) to S567 or higher, then both versions are fully equivalent. The only difference between the 2 was in the Sig level, and so by applying S567 they are now at the same Sig Level. The issue with the Signature Update will only affect a few rare customers. There is a specific signature that if tuned could cause a configuration issue.  (You can look in the Readme to see which signature it was, I can't remember right now). If you did NOT configure this signature, then both 7.0(5) and 7.0(5a) work just fine. If you've loaded 7.0(5) and it is working, then you don't have to worry about needing to install 7.0(5a), you won't have the issue. If you have not installed 70(5), then go ahead and use 7.0(5a) so you won't hit the issue. ... View more

The cisco account can not be renamed or removed. However, it can be locked by removing the password "no password cisco". This should only be done if you have created another account with administrator privilege. ... View more

As for the action field. When Summary Alerts, or Global Summary Alerts are generated the action fields are always blank. The sensor does not track to see what actions took place on every individual alert being counted in the Summary Alert. The actions took place on the individual alerts, and not on the Summary alert so no actions are marked in the Summary Alert. In order to track what actions are being done you would need to ensure the sensor is generating the individual alerts. For those signatures that are configured to start out in Summary Mode, you may want to recnfigure them to start out in FireAll mode, and then have them upgrade to Summary Mode. This way you can see the actions on individual alerts before too many happen and it upgrades to Summary Mode. NOTE: There is no option to get the actions shown in Summary Alerts. ... View more

There are 2 levels of summarization. There is the first level of summarization which will usually summarize by either Attacker IP or Victim IP. (NOTE: Other methods of Summarization also exist, like by Attacker IP and Attacker Port, but these other methods are rarely used) Each signature is specifically configured to summarized using a specific method as is designated by the "Summary Key". Select the signature in IDM (or IME) and select Edit. In the Edit window that comes up you can find the Summary Key configuration and see what the signature has been set to Summarize on. If is set to Summarize by Attacker IP, then the Attacker IP will be seen, but the Victim IP will be set to 0.0.0.0. If the Summary Key is Victim IP, then the Attacker IP will be 0.0.0.0, and the Victim IP will be seen in the alert. NOTE: Even in Summary Mode, the very first alert of a Summary Interval is generally created with both IPs filled in. Many signatures are configured for FireAll as the Summary Mode, but are configured to upgrade into Summary Mode if too many alerts are seen. Other signatures are known to fire often when seen, and are configured to start out in Summary Mode. The next level of Summarization is Global Summary. Very few alerts are configured to start off in Global Summary mode. Instead most alerts are configured to automatically upgrade from Summary Mode into Global Summary Mode when even too many Summary alerts are being generated. In Global Summary Mode both the Attacker IP and Victim IP will be set to 0.0.0.0 So when you see 0.0.0.0 in an alert, then check the alert details. It is almost always a Summary Alert when either the Attacker IP or Victim IP are 0.0.0.0. And is almost always a Global Summary Alert when both the Attacker IP and Victim IP are 0.0.0.0. ... View more

Network Interfaces do not support fixed configuration of speed and duplex on one device and auto negotiate on the other device. The device set to auto negotiate will send out negotiation queries to the other device, but because the other device is fixed it will not respond to the queries. The devices with the fixed speed and duplex does Not respond with the fixed speed and duplex, and instead just simply does not respond at all to the auto negotiation queries. So the device with auto negotiation is not able to determine the settings for the other device, and will set it's own speed and duplex to the default settings for that NIC. On most 10/100 and 10/100/1000 copper interfaces the default will be 100 Half Duplex. So for auto negotiation to work properly you Must set Both devices to auto negotions. If you will fix speed and duplex on one device, then you must also fix speed and duplex on the other device. The other thing to keep in mind is the type of cable connecting the 2 devices. For 10/100 interfaces you have to be very carefull of the type of cable being used. When connecting the sensor to a switch it must be a standard cable. BUT when connecting the sensor to a Firewall, Router, or PC, then it likely needs to be a CrossOver cable. (The switch has built in the equivalent of crossover directly within its ports, but firewalls, routers, etc... generally do not) If you are using 10/100/1000 interfaces on both devices, and have both devices set to auto negotiate; then in most cases the type of cable will not matter. When auto negotiate begins they will determine the cable type and one of the 2 will automatically do a sort of internal crossover if needed, and will then auto negotiate to 1000 Full. HOWEVER, if you fix the speed and duplex then just like with 10/100 interfaces you have to be very carefull that you are using the right type of cable. There will not be any negotiation and so your cable choice must be very specific. In most instances you will need to use a crossover cable when connecting the sensor to a Firewall or Router, but use a standard cable when connecting to a switch. So be sure to set speed and duplex the same on both devices. Either both devices with fixed speed and duplex, or both devices with auto negotiated speed and duplex. And be sure you are suing the right type of cable for your particular connections. ... View more

So the Critical status for Event Retrieval is doing exactly what it was designed for. It is letting you know that CS MARS hasn't pulled any events from the sensor since it was last rebooted. Any number of things could be the problem. You will need to begin trying to determine why CS MARS is not pulling events. Here are some suggestion to help get you started: 1) Check MARS configuration. Make sure MARS has had the sensor add to the list of devices it should connect to for pulling events. Make sure the username and password are correct. 2) Check MARS for any error messages. I don't know very much about MARS but I assume ther must be an Error log of some kind. It may be generating errors that could help explain why it may not be pulling events from the sensor. 3) Check the sensor configuration. Make sure that the MARS box's IP Address is included in the access-list of the sensor (otherwise MARS won't be able to connect). Login with the same username and password that was configured in MARS to ensure the password is properly set.. 4) Check that alerts are being generated on the sensor. Execute "show event alert" on the CLI and watch it for some time to ensure that new alerts are being generated by the sensor. (If no alerts are being generated by the sensor, then there may be other sensor configuration problems that would need to be solved first.) 5) Check the statistics of the web server and sdee-server. Execute "show statistics web-server" several times over a few minutes and see if any web server connection are being made to the sensor from your MARS box (MARS pulls the events through a web-server connection). If no web-server connections are being made, then there may be connectivity issues. If there are web-server connections being made, then run "show statistics sdee-server". If everything was working right there would be at least 1 subscription open for CS MARS. If you have 5 subscriptions open, then you might be running into a problem of too many open subscriptions. (if you do have 5 open subscriptions, then you may have to clear subscriptions for MARS to open a new one. The easiest way to do this is to reboot the sensor. There are, however, other methods as well. If you have this situation and don't want to reboot the sensor, then let me know and I can give you those other steps.) 6) Another common problem is with SSL certificates. The certificate may have expired (they expire every couple of years), or your sensor certificate may have changed recently. Try running "show version" on the sensor CLI. The more recent versions have a line at the bottom of the output to tell you when the certificate will expire. If your certificate has expired then you will need to create a new one using the "tls generate-key" command. Any time a certificate is changed you will also have to tell MARS about the new sensor certificate. If you use the "Test Connectivity" or "Discover" buttons in MARS it will prompt you to accept the new certificateif it has changed. 7) One other thing to check is just basic network connectivity. Is there any firewall or router with an access-list that may be preventing MARS from reaching the sensor? ... View more

Here is the basic explanation from the IDM User Guide: Event Retrieval-Lets you set a threshold for when the last event was retrieved and whether this metric is applied to the overall sensor health rating. Note The event retrieval metric keeps track of when the last event was retrieved by an external monitoring application such as IME. Disable Event Retrieval if you are not doing external event monitoring. http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/idm/idm_sensor_management.html#wpxref98287 There are 3 primary methods by which events are monitored: Subscription, Query, and Traps A Subscription is used by external Monitoring Tools. The typical Cisco tools for Monitoring are IME (Intrusion Prevention Manager Express) and CS MARS. If you don't already own CS MARS, then IME is recommended. If you have a service contract for your sensor (which you need for upgrading signatures), then as part of that contract you can download and use IME at no extra cost. IME maintains a Subscription with the sensor. Think of it similar to a magazine Subscription where you keep on getting next months magazine unless you cancel your subscription. IME sends an open message to the sensor to start the Subscription, and then just keeps asking for new data as part of that Subscription. Other 3rd party tools are capable of using Subscriptions as well. If you are using a 3rd part management tool for monitoring then contact that company to see if their tool uses a Subscription. This specific health statistic for event retrieval is to let you know if your subscriptions are up to date. In your case it doesn't like you have any tool that has even started a subscription so your sensor health is red. If you don't plan on using a Monitoring tool that does Subscriptions, then disable the Event Retrieval Statistic from your sensor health. This way Event Retrieval is ignored by the sensor when determining the Health of the sensor. The second method for monitoring events is through a Query. Using the magazine example, a Query is more like walking down to the local store and buying the new magazines one at a time. You don't automatically get next months magazine sent to you. The IDM (Intrusion Detection Device Manager) has Event Monitoring screens, but these screens do one time Queries. If you want more data from the sensor you have to hit a button and it will grab one more set of data from the sensor. But it has to specifically ask each time. The "show event" command from the sensor CLI is ALSO treated as a Query. Some 3rd part monitoring tools also have coded to pull events using a Query instead of a Subscription. The Event Retrieval statistic does NOT track Queries. So if you use IDM, CLI, or a 3rd party tool using Queries; then it has no affect on the Event Retrieval status. You either need to switch to using a tool like IME that does do Subscriptions, or disable Event Retrieval as a statistic for sensor health. The 3rd method is to use SNMP Traps. SNMP Traps are done over UDP and not guaranteed to arrive at the monitoring tool. So similar to Queries, the sending of SNMP Traps does not affect the Event Retrieval status. If you are using SNMP Traps for monitoring, then you can disable the Event Retrival as a statustic for sensor health. Hope this has made more sense out of what you are seeing. ... View more