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)
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?
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 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?
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 isnt, 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.
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...