cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
524
Views
0
Helpful
2
Replies

tuning Flood Engine sigs

npham
Level 1
Level 1

Looking to shed some light into the behavior of the Flood Engine.

According to Cisco documentation:

The Flood engine defines signatures that watch for any host or network sending multiple packets to a single host or network. For example, you can create a signature that fires when 150 or more packets per second (of the specific type) are found going to the victim host.

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00804cf506.html#wp1040058

As an example, lets examine the default parameters of sig 4002 UDP Host Flood.

Engine: Flood Host

Rate: 100

Protocol: UDP

Event Count: 1

Event Count Key: Attacker Address

Specify Alert Interval: No

Is it correct to say that an alert is generated if the sensor sees that source A has exceeded 100 UDP packets per second? 100+ pps could have been to 1 host, or a bunch of hosts, as long as the total packet count from source A is greater then 100. The alert however, will show the victim address and port of the triggering packet (the 101st packet in that second). Am I correct so far?

My first problem, is the NSDB signature description says "This triggers when a large number of UDP packets are directed at a host." To me, for this to happen, the Event Count Key should be set to Victim Address.

My other problem, is that no matter what tuning I try on various Flood Engine signatures, alerts are generated that are not in line with what the parameters specify.

For example, lets retune sig 4002 so that it alerts on distinct host pairs (1 to 1 relationship). So we change Event Count Key to Attacker and Victim Addresses. Now if source A sends out 101 pps to multiple hosts, I should expect to see no alerts. The only time I expect to see alerts, is if source A sent 101 pps to dest B, and another alert if source A sent 101 pps to dest C, etc. But, after extensive testing, it doesn't work that way.

Anyone care to enlighten?

2 Replies 2

wsulym
Cisco Employee
Cisco Employee

There's a little catch to the flood-host engine, and that's that there is an underlying storage key of xxBx in the engine itself, so the engine is doing some summarization.. which is going to lead to odd results if you try to use the summary key in the signature itself. Back in 4.x, this was a by design thing in the flood engines and from my digging yesterday, I believe that its carried thru into 5.x as well even though the multiple flood engines were consolidated.

Summary on the attacker Axxx works just fine, but not on the victim xxBx.

I'll update this thread once I get together with the engine developer and hash this out, but I'm pretty sure that this is by design.

Take a look at signature 4003, this was firing for me while I was fooling with 4002. Or even making a custom sig using the atomic-ip engine to identify a host to host flood using a count over an interval.

I'll update this when we hash out the details about summarization.

Thank you for looking into the matter. IMHO, event summarization for flood signatures is more desirable then outright filters. And as indicated in other sig tuning threads, filters are not a good option if event summarization is happening.

Perhaps like you mention, it may make more sense to re-implement some flood signatures using the atomic-ip engine.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card