I have many incidents lately on windows boxes that are tripping this signature. It can't be a Lokid server all sending info to one ip address: 220.127.116.11. I thought only unix boxes run Lokid server so our security team looked up the ip address (a multi-media research co. in Oregon) and Loki on Google. It points to a spyware called Attune by Aveo.com. Currently, truste.org is after them for privacy violation. (http://www.truste.org/news/padvisories/users_aveo_seal.html)
Are there anyone experiencing this on their Cisco NIDS? or Am I running off on a tangent?
I've tried looking for this software and could not find it. The company website (www.aveo.com) is "under construction". If anyone seeing this alarm is willing to share a traffic trace, we'd be happy to look at it. You can send the trace(s) to firstname.lastname@example.org. Also, a possible workaround is to use a RecordOfExcludedPatterm for the Loki alarm with the offending IP as the source.
So you may want to check your systems and see if it was loaded as part of another software program.
It could also be some other program and not attune that is generating these packets.
If you can verify that the ips in your network have attune loaded, and if you turn off attune the alarm stops firing then you are likely correct that it is attune.
You'll have to decide then on your own whether or not to disable or even de-install attune.
If you leave it enabled you would need to Exclude the loki signature where aveo.com's ip address is the source of the alarm, and possibly a second Exclude where aveo.com is the destination of the alarm since the address may be the source in one firing and a dest in another firing.
A sniffer trace of the icmp packets in a libpcap format as mcerha requested would be very helpful.
If you don't have a sniffer that generates libpcap formatted files (like tcpdump) , then you can:
1) set the action for loki to iplog, and set it to iplog for at least 5 minutes (the default of 15 is also fine)
2) let the alarm fire.
3) wait for the time of the iplog
4) set the action for loki back to what ever you had it before (likely none)
5) send mcerha the iplog file(s) from the /usr/nr/var/iplog/new directory for the ip address that fired the loki alarm. (there may be several)
(If the files are large then you can use a program like ethereal or tcpdump to read in the file and only write out the icmp packets from the file. You can then compress it if you like.)
Upon looking at the traffic from several people, I found that the spyware in question sends a normal looking ping to the IP address 18.104.22.168. The strange part is it responds with two or three ICMP echo responses. Our Modified Loki signature looks
for an imbalance in ICMP echo requests to replies. The current threshold is set to 3 replies to a
echo to fire the alarm. This threshold is currently not customer tuneable. One possible cause for the
numerous ICMP echo replies could be if the IP is the frontend for a load balancer of some kind. We have seen this before. I will update our NSDB
documentation to reflect this benign trigger. You can safely eliminate the alarm by using a RecordOfExcludedPattern for 6302 with 22.214.171.124 as a source address.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :