misleading "Nachi Worm ICMP Echo Request" triggers

darin.marais · ‎10-27-2005

I think that I am see large amounts of events from the signature Nachi Worm ICMP Echo Request (ID: 2156.0) signature that could be misleading in the process of identifying really infected devices. When I check the destination it is usually a landesk workstation or server.

The packets that have triggered the events look something like this.

xx:24:41.565502 workstation > landesk_server: icmp: echo request (ttl 123, id 56150, len 1052)

0x0000 4500 041c db56 0000 7b01 2800 9ea9 a527 E....V..{.(....'

0x0010 9ea6 5613 0800 de9f 0200 c20a aaaa aaaa ..V.............

0x0020 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................

0x0030 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................

snip lines

0x03e0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................

0x03f0 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................

0x0400 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................

0x0410 aaaa aaaa aaaa aaaa aaaa aaaa ............

I know that nachi pings are normally 92 bytes long so this is not one of them. Are others on this list seeing lots of events that could be related to network applications rather then the nachi worm itself?

Can someone tell me what the applications is that cause the event to trigger. Am I right in assuming that it is landesk.

I am aware the these events should be correlated with other events in order to determine infected devices but can the signature not be further tuned in order to reduce the amounts of false triggers received at the sec console?

a.arndt · ‎10-27-2005

Good day,

We've had false-positives involving systems on the protected network running software clients connecting to various servers that support Yahoo! Messenger (Please, no comments about IM, etc. I know...). It seems that the Yahoo! Messenger software always pings the server before it establishes a connection, and it must be using the 0xAA payload to pad the packet out to some desired length.

As seen with your example, ICMP echo request that are not 92 bytes long, but none-the-less are full of 0xAA, cause this signature to fire.

I can't say if LANdesk can or cannot be attributed as a probably cause for this, but it looks like you may have a case, IMHO.

I hope this helps,

Alex Arndt

estherloo · ‎10-31-2005

Hi there

I need help to filter traffic generated by the same signature. Everyday i'll received Nachi Worm ICMP Echo Request (ID: 2150 Sub 0) in one of my sensor. Source ID is from the unknown and Destination ID belongs to my public IP. How can i filter such traffic?

Thank you

darin.marais · ‎10-31-2005

If the sensor that is generating the events is located outside of your perimeter firewall then I would suggest that you just try to summaries the events. I would not filter the events completely as that would create a false negative situation. The events that you receive are real and therefore you should be collected so that you are able to report statistics if required. I am assuming that the sensor is outside of the firewall. If it isn’t, then you should really investigate why this type of icmp is entering the network. If it is entering, you should make plans for how you can block it.

5creedus · ‎10-31-2005

if you are not interested in stats and only want notification that your systems are trigger the sig you can create 2 rules and a system variable to define your IP network(s).

system variable to define your network(s) with host(s) or networks separated by a ,.

service alarm-channel-configuration virtualAlarm

tune-alarm-channel

systemVariables

USER-ADDRS1 a.b.c.d/24,a.b.c.d

Define the filter for the sig, in this case Nachi

service alarm-channel-configuration virtualAlarm

tune-alarm-channel

EventFilter

Filters DestAddrs * Exception True SIGID 2156 SourceAddrs $USER-ADDRS1 SubSig *

Filters DestAddrs * Exception False SIGID 2156 SourceAddrs * SubSig *

In version 4 the order makes no difference. In version 5 the order must be as shown above. So the first rule will trigger anytime an IP that is part of the defined variable USER-ADDRS1 as the source and the second rule says do not file at all. In effect triggering only when a host(s) in your network is suspected of generating the Nachi. I've used this with other virus an dworm related sigs as well, in particular sigid's 4701 and 4702 MSSQL, when they are seen by the sensor.

I got this from one of the Cisco folks in this forum. I put it in a tuning doc, but can't find the URL on this forum.