Problem with Sig ID 2156:Nachi Worm ICMP Echo Request?

[jballay]

We're experiencing a problem with Sig ID 2156, the Nachi Worm ICMP Echo Request signature. The problem we're seeing is once the signature fires, the destination IP address in the alarm is actually the machine that's infected with Nachi and the source addresses are the machines it's trying to infect. At the same time, we're also getting alarms that show the infected machine as the source address.

Has anyone else reported this to Cisco? If there really is a problem with the signature, is Cisco working on a fix?

[DSmirnov]

Saw exactly the same - almost got a heart attack after few hundrends alerts initiated from our environment :)

Disabled sig. 2156 immediately. Yep, Cisco probably has to fix the signature - look like 2156 reacts on the same payload in ICMP port unreachable or something like this...

[garyprice]

better yet. when capturing packets and snooping network traffic in relation to this virus the icmp traffic is backwards. The infected system sends out and echo-reply (8) and the target system sends (0). It is my understanding that normall network pings are 0 to 8 (icmp type) not 8 to 0....it appears in sig 2100 Net sweep echo.... that is what I used to help locate infect machines.....gp

[anthall]

This signature will be noisy for a 3.1 environment. This is due to a couple of limitations with the 3.1 code, 4.0 will not suffer from these problems:

SummaryKey: Without the summary key feature of 4.1 it isn't possible to summerize all of the alarms from one nachi host. Each and every time an ICMP is sent an alarm fires (that is a lot of alarms).

IcmpType(ServicePorts parameter): 4.1 allows for a specific ICMP type (by using the ServicePorts parameter) for the STRING.ICMP engine. Setting this to a value of 8 prevents getting alarms from the machines that respond to the nachi ping.

In short, 4.1 removes these problems if ServicePorts is tuned to 8 for signature 2156 (this will be done in S55).