IOS IPS - Sig 4050 UDP Bomb apparent false alarms?

[kurtpatzer]

Hi,

I'm trying the IOS IPS solution out in a lab environment and I seem to be getting lots of false alarms on sig 4050 - UDP bomb. Looking at the signature description via go/mysdn, and looking at it's configuration on the router via SDM, I can see it is simply looking for small UDP packets. But I don't know what size (The parameter is named ShortUDPLength and it's set to True).

All NTP traffic kicks of this signature. Using Ethereal to capture the NTP exchange, I see that the communication in each direction is a single packet. The layer 2 frame lenght is 90 bytes. The UDP data length is 56 bytes. All of this seems fine. The NTP server is a Cisco router. The NTP client is running on a Windows 2000 workstation.

Also, any TFTP to/from the router with IPS enabled also triggers the alert. Specifically it is the Ack's from the TFTP server that trigger the alert. They are indeed small packets - the UDP data size is only 12 bytes.

Note, this same traffic does not cause alerts from a 5.0 IPS sensor. Looking at the signature definition on the sensor, it doesn't have a parameter named SnortUDPLength. Instead it has a parameter named udp-length-mismatch which is set to true. This doesn't seem to be keying off of a particular data size, but instead conflicting reports in the UDP header compared to the actual packet size.

Any information that anyone could provide to shed light on this subject would be appreciated. Such as:

1) Do you find that IOS IPS sig 4050 false alarms are common?

2) What is the UDP data length that triggers the alert? It has to be bigger than 90 bytes!

3) Does Cisco have any recommendations on what to do with this built in signature?

Thanks,

KEP

[wsulym]

On the sensor appliance side, the udp-length-mismatch checks for discrepancies between the ip header length and udp length of the packet. You were dead on, the signature triggers when the UDP length specified is less than the IP length specified. I'm not positive of exactly what the IOS ShortUDPLength parameter is.

You provided some valuable information in that the same traffic doesn't trigger the alerts on the appliance, so we know that this is not the signature, but rather the implementation of it in IOS.

I'm taking a bit of a leap here not knowing what IOS version you are running, but I'm guessing you may be running into CSCeh32935. The title states multicast, but the bug is not limited to just multicast traffic. This affectes some 12.3T releases and early 12.4. Looks like 12.4(2)T or higher has fixes implemented.

Since you're in a lab environment, I'd go ahead and upgrade the IOS on the router and see if that doesn't resolve the issue. If it's still there, open up a TAC case, and they'll be able to recreate the issue and file a new bug if neccessary.