I have an IPS 4255 running 6.0(5)E2. The device is not running inline, it is functioning pretty much as an IDS. It has devices with which it can request blocks via ACLs on an interface. My problem is that the IPS seems to be blocking traffic without any reason. We've had 5 customer IP addresses be blocked, and when we go into IEV or even the CLI (using 'show events'), we can find no reason for the IP to be blocked. When we use the 'show events' command, we see the events for the block request, but no signature triggered at all! This is a serious problem as it has blocked several customers and we've had to temporarily disable the IPS system. We have a TAC open, they don't seem to know why it's happening either...any ideas on how I can see why these blocks are being requested? Perhaps someone else has seen this or can think of something TAC isn't?
Re: IPS blocking traffic without a signature trigger!
Here is some information that may help:
There are 2 types of Block requests:
1) Automated where the Block is requested as an action for a signature triggering. An Automated Block will create an evShunRequest event in the EventStore. The network access controller has a subscription looking for these types of events, and adds the Block when it sees these evShunRequests coming from the analysis engine. So if the Block was from a signature, then there must be one of these evShunRequests in the eventstore, and you would need to search through the eventstore to find it.
Once you've found the evShunRequest then you can look closely for a field for the eventId of the alert that caused the evShunRequest (The evShunRequest itself has an eventId, but there should also be another field pointing to an eventId for the corresponding alert). You can then once again search through the eventstore to look for that eventId which should be for an alert where you can then determine the signature trigger.
IF, however, there is NOT a corresponding eventId, then there is not a corresponding alert. The alert was not generated for one of several
a) The alert actions were not on the signature.
b) A filter may have removed the alert actions, but not removed the Block actions (You might want to ensure that all filters removing alert actions are ALSO removing Block actions)
c) The individual triggering of the signature may have been summarized.
2) The other type of Block Request is a Manual Block Request. This
happens when a user goes through either IDM, IME, or CLI and manually
enters an IP Address to be Blocked. There is a Control Transaction
that gets sent to the network access controller to request the
Shun/Block. No signature is involved in this type of request. But
there should be an evStatus event showing the Add Shun control
transaction which should be seen in the Event Store around the same type
as the event. SO if you can't find an
evShunRequest for an automatic block, then look for an evStatus request
to see if a user requested the Block. The evStatus request for the
manual block should at least have a username so you can see which user
So if you see a status for a Block being added, then there should also be either an evShunRequest, or an ev Status showing the manual block reques. If it is an evShunRequest there may be a corresponding alert eventId.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...