I'm receiving plenty of Sig 2100 (NetSweepEcho) alarms in my network.
I'm running IDS-4235 with software ver. 4.1(3)S68.
I tuned the Sig 2100 by increasing the Unigue parameter to 10 (default 5) and also enabling Packet Capture. Everything else left default.
But when I look at the Attack Details window, I see incorrect IP addresses as Destinations.
I made a test:
I prepared a script pinging to 15 different IP addresses (a.b.c.1 - a.b.c.15) from my PC.
The script triggered the 2100 alarm correctly. The captured packet was the eleventh one with correct destination.
But looking to the Attack Details window, I saw:
Address:a.b.c.5 Port:0 Locality:OUT
Address:a.b.c.6 Port:0 Locality:OUT
Address:x.y.1.192 Port:0 Locality:USER-ADDRS2
Address:x.y.25.8 Port:0 Locality:IN
Address:x.y.1.86 Port:0 Locality:OUT
Address:a.b.c.7 Port:0 Locality:OUT
Address:a.b.c.8 Port:0 Locality:OUT
Address:a.b.c.9 Port:0 Locality:OUT
Address:x.y.99.35 Port:0 Locality:IN
Address:a.b.c.10 Port:0 Locality:OUT
Where x.y. is my private IP addressing range.
So I've got a feeling there is a bug in Sig2100 Alarm Details output.
Has anybody elso notice this problem?
I'm trying to investigate why are PCs in my network pinging so much, but I can't go further if I can't rely on the ping targets detected by my IDS.
Is it possible that the other addresses listed in the participants block are real pings that were sent to the other segment? Perhaps your "attacker" box is Nachi infected.
There are no known defects in the details formatter.
Given the incrementing nature of the a.b.c targets, and
the interleaved x.y addresses, this may be real traffic.
Can you run the test again and see if you get similar results with interleaved x.y addresses. Also, maybe you can tune down the Unique to 3 and and run it without your script and see if you get x.y addresses reported.
Also, Enable sig 2000 and 2004 for testing while your script is running and you can see the raw pings detected by the sensor. If you see a.b.c.1->x.y.?.?,
then those pings are live on the network.
Hi James, thanks for your quick reply.
You are correct, the addresses displayed came from a real traffic.
There is no virus on my machine. I was capturing all the traffic by a sniffer and the only pings from/to the machine were a.b.c.1-.15.
I set the Unique to 3, enabled Sig 2000 and 2004 and tuned them to FireAll, Capture packet and StorageKey AxBx. So I've got the maximal information, I think.
Finally I realized:
Th 2100 alarm was triggered correcly by a ICMP Echo Request to a.b.c.5, e.g.
I noticed it was the third Ping form my machine, the captured packed was correct.
BUT the destination address field in the alarm line displayed by Realtime Dashboard was incorrect!! It was derived from the fourth previous ICMP Echo Request packet, which was issued by another device (i.e. the source address was different)!!!
When I opened the Show Attack Details window the destination addresses were completely wrong - the first one was the same as the alarm line field (incorrect), the other two were derived form two previous ICMP Echo Reply packets (but these replies were again to another sources!).
I've noticed the same behaviour several times so I'm positive there is a bug in Sig 2100. The alarm is triggered correctly but the info displayed in Attack Details is incorrect - it doesn't show correct destinations to the particular source of the attack.
Or there might be something wrong in my IDS connection to the network. I'm RSPANning one VLAN from a trunk line connecting my "router on the stick" plus one line connecting two my switches to one IDS port - so one L3 packet can be seen up to three times by the IDS. Could this topology make my IDS confused?
Thank you for clarifying on your testing and results. That signature has started generating over 40,000+ alerts an hour for us. I did have a question for you. 98% of our alerts are seen coming from 188.8.131.52. Are you seeing this in addition to all of the other "attacker" addresses? I was just curious as to whether or not this one IP address may be correct and part of the rest of them be a bug.
I'm receiving no alarms with source address 184.108.40.206.
But my IDS is connected behind the firewall, so I'm seeing only attacks which passed through our firewall into the internal network.
So if the attack comes from the Internet, the only packet allowed to go through are these which are targeted to our DMZ.
I also increased the Unique paramater for Sig2100 to 10, so the number of alarms decreased to approximately 4000 a day.
Most of the source addresses (90 percent, I'd say) are our internal PCs. I'm trying to investigate why our PCs are pinging so much, but I can't rely on the destination addresses reported by IDS - so I can't go further.
If you have any doubts about the real alarm source, try to follow the James tests - enable Sig 2000 and 2004 temporarily and Capture the ICMP packets. You will be able to observe the captured packets by Ethereal and you'll see the real source and destination addresses.
BTW, I think the source addresses are correct, the problem is with the destination addresses reported.
I tested sigID 2100 in our lab using "unique 10" also. However, I was unable to replicate your results. It seems that 2100 is performing properly here:
evAlert: eventId=1076141258673960123 severity=low
time: 2004/02/07 06:50:05 2004/02/07 06:50:05 UTC
signature: sigId=2100 sigName=Net Sweep-Echo subSigId=0 version=2.1.1
addr: locality=OUT 10.20.12.2
addr: locality=OUT 10.20.2.3
addr: locality=OUT 10.20.3.3
addr: locality=OUT 10.20.4.3
addr: locality=OUT 10.20.5.3
addr: locality=OUT 10.20.6.3
addr: locality=OUT 10.20.7.3
addr: locality=OUT 10.20.8.3
addr: locality=OUT 10.20.9.3
addr: locality=OUT 10.20.10.3
addr: locality=OUT 10.20.11.3
alertDetails: Traffic Source: int0 ;
Hi Robert, thanks for your fast response.
Have you tried to ping from two devices to different IP ranges during your test?
PC1 to ping to 10.20.2-15.3 and PC2 to ping to 10.20.22-35.3 at the same time, e.g.?
I bet you would see mixed target ranges in the Alarm Details window.
My feeling is Sig2100 doesn't pair attack source-destination correctly, it just displayes last 10 (if Unique = 10) destinations pinged from any source.
Hi Milan, It is a bug. Robert was able to tweak his
test some and reproduce this defect now. I have instrumented the code and see the problem, and am working on a fix.
We will submit a DDTS (bugid) for tracking purposes. I will suggest that we include this fix in our next patch release, which will be soon.
You may want to open a TAC case so the issue can be tracked, and you can have a TAC engineer walk you through the patch delivery and installation when it is available.