IPS blocking traffic without a signature trigger!

oatinetworksupport · ‎09-15-2008

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?

suschoud · ‎09-16-2008

could you post the " sh events " output concerning the block.

marcabal · ‎09-16-2008

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

reasons:

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

requested it.

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.