Nachi ICMPs and PIX Performance

[jason.scott]

Hi all,

Unfortunately we still have a few clients left over from the Nachi virus still broadcasting icmps to random addresses. When the outbreak first began we noticed a dramatic drop in internet performance which appeared to be caused by the PIX being overwhelmed with these ICMP requests but denying them because the networks did not exist.

To alliviate this I put in place access lists on our internal routers to filter icmps out of the subnet which our PIX resides on. This has worked, but caused a few problems with applications that require ICMPs to be enabled.

Is there any configuration that can be used on the PIX to increase performance and have it better deal with mass ICMP requests to unknown networks?

Regards,

[mostiguy]

Are you sure the problem wasn't just that the volume of icmp echo and echo reply traffic was consuming all of the bandwidth, rather than just overloading the hardware of the pix? If you can throw up access-lists on routers, you can log the icmp traffic, and hunt down and patch machines.

[jason.scott]

Not positive but almost sure it wasn't down to bandwidth. We have some other boxes on this subnet that aren't affected (Cat4006, IDS).

I tried placing the access list on the PIX itself rather than the upstream router and it managed to log around 100,000+ hits on the icmp denial statement in just under 1 minute. I'm really surprised though because my captures from the pix logs which I use to feed machine info to our support team only seems to indicate about 20max clients left infected (we have about about 2500 clients).

[nkhawaja]

Hi,

Another option you have is to enable ip verify unicast reversepath on the inside interface. It will deny/drop all the spoofed packets.

Thanks

Nadeem