Our Cisco IDS 4200 appliances have been converted from 4.1(x) to 5.1(3) with latest signature S252. I'm going through fine-tuning and enabling countermeasures step-by-step. One thing I noticed is that even though a never-block-host for our /19 CIDR is configured the IPS is still blocking IP's within that range. Am I correct in understanding the behavior of never-block-network with IPS 5.1(3) meaning never ever block, right? I'll try breaking it down into /24 since maybe it doesn't like /19.
We've just been through the same thing with some of our devices-- apparently 5.x does not support true CIDR for the never-block lists. It will silently pass these along when you upgrade from 4.x (a bug!), but they don't work. We have a TAC case opened on the issue. For now, we've had to convert all of our never-block lists to use /8, /16, or /24. Event subnets like /27 won't work, a serious security gap! I personally consider this to be a major failing in the upgrade process and in the product in general.
Thank you for the feedback and confirming my suspicion.
I think I made the safe decision by upgrading each appliance one at a time, erasing the config then performing the upgrade to 5.1(x) so there's no config conversion issues and taking small steps to understand the behavior of the new IPS software. The CIDR issue could've been a major production killer if not paying attention to the shun list.
Something else you may want to consider as a workaround.
Instead of solely relying on the NeverBlock list, you can also create event-action-filters in 5.1(3) that can remove the "request-block-host" and "request-block-connection" event actions.
In 4.1 the filters would remove the entire alert and all actions for the alert.
So if you tried to use filters to prevent the Blocks it would also keep you from seeing the alert in your alert viewer.
But in 5.0/5.1 you can now independantly remove actions from the event.
So you can create a filter for all signatures where the attacker address is the addresses you never want blocked, and remove the request-block-host and request-block-connection actions.
This way when the sensorApp/AnalysisEngine service triggers an event for the attack it will not even send the block request to the network access controller service, but will still go ahead and do the rest of the event actions that were configured on the signature.
There is also no a specific action in order to get an event to actually create an alert for viewing. This is event-action is "produce-alert".
So if the "produce-alert" and "request-block-host" event actions were both configured on the signature, then the filter can remove the "request-block-host" event action and still allow the "produce-alert" event action to happen.
That is an option but a hack at best. One other 'feature' we noticed when upgrading from 4.x -> 5.x is that the netmasks were stripped from filters. So for example, a source of 10.0.0.0/8 converted to a 10.0.0.0 (/32 effective). Doh!
The issue you just described about the filters not being converted properly is CSCsf15670, and was addressed in the 5.0(1e) major upgrade file.
Unfortunately those who upgraded with any of the earlier 5.0(1) repackages would need to manually change the filters themselves.
As for the NeverBlock bug not taking all netmasks. The filter method is a workaround until the bug gets addressed in a ftuure version. But even after the fix is in place, the filter method is still recommended to be used in combination with the NeverBlock configuration. The filter method will reduce the number of messages being logged to the eventstore (prevents the block request from ever being generated), and helps to reduce the amount of processing being done by both the AnalysisEnging (fewer messages being passed between processes) and the network access controller (because it doesn't spend time filtering out the requests it should Never Block).
Yeah, we tried 5.0(1e), it failed miserably. Wouldn't ever work on several sensors we tried to upgrade from 4.1 to 5.x. We tried several times, all failed. In fact, that completely hung the upgrade and we had to kill it and go back to pushing 5.0(1). I believe that we have a TAC case open on this.
Re: your earlier comment about using filters, while that does seem to be a viable solution, why wasn't that promoted and never-block deprecated from the beginning? If the plan is to have everybody use filters, why not just remove the never-block stuff entirely and re-write you docs? Finding out about the broken functionality of the never-block list in mid-upgrade for large customers is just not fun. (We run >120 Cisco IDS devices worldwide, if you're wondering.) Even if you intend to maintain the never-block functionality, at least get the upgrade process from 4.x right...
One more gripe, if you're going to use IP ranges instead of CIDR, be consistent. Use them everywhere.
Please excuse my rant, my team and I have been through too much pain with this product lately.
I agree with your statement! We have >70 sensors and had the same issues. I wrote Cisco several times about this bug and they don't seem to care to fix it... I have had many very angry customers because of their public IPs getting blocked because a classless mask was used.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :