Sig 2100 trouble

milan.kulik · ‎02-05-2004

Hi,

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:

Destination1:

Address:a.b.c.5 Port:0 Locality:OUT

Destination2:

Address:a.b.c.6 Port:0 Locality:OUT

Destination3:

Address:x.y.1.192 Port:0 Locality:USER-ADDRS2

Destination4:

Address:x.y.25.8 Port:0 Locality:IN

Destination5:

Address:x.y.1.86 Port:0 Locality:OUT

Destination6:

Address:a.b.c.7 Port:0 Locality:OUT

Destination7:

Address:a.b.c.8 Port:0 Locality:OUT

Destination8:

Address:a.b.c.9 Port:0 Locality:OUT

Destination9:

Address:x.y.99.35 Port:0 Locality:IN

Destination10:

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.

Regards,

Milan

jakasper · ‎02-05-2004

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.

-JK

milan.kulik · ‎02-06-2004

Hi James, thanks for your quick reply.

You are correct, the addresses displayed came from a real traffic.

BUT:

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?

Regards,

Milan

mjuckett · ‎02-06-2004

Hi Milan,

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 211.57.216.195. 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.

Thanks,

Megan

milan.kulik · ‎02-06-2004

Hi Megan,

I'm receiving no alarms with source address 211.57.216.195.

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.

Regards,

Milan

rgloria · ‎02-06-2004

Milan,

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

originator:

hostId: qsensor-57

appName: sensorApp

appInstanceId: 1202

time: 2004/02/07 06:50:05 2004/02/07 06:50:05 UTC

interfaceGroup: 0

vlan: 0

signature: sigId=2100 sigName=Net Sweep-Echo subSigId=0 version=2.1.1

participants:

attack:

attacker:

addr: locality=OUT 10.20.12.2

port: 8

victim:

addr: locality=OUT 10.20.2.3

port: 0

victim:

addr: locality=OUT 10.20.3.3

port: 0

victim:

addr: locality=OUT 10.20.4.3

port: 0

victim:

addr: locality=OUT 10.20.5.3

port: 0

victim:

addr: locality=OUT 10.20.6.3

port: 0

victim:

addr: locality=OUT 10.20.7.3

port: 0

victim:

addr: locality=OUT 10.20.8.3

port: 0

victim:

addr: locality=OUT 10.20.9.3

port: 0

victim:

addr: locality=OUT 10.20.10.3

port: 0

victim:

addr: locality=OUT 10.20.11.3

port: 0

alertDetails: Traffic Source: int0 ;

Regards,

Robert

milan.kulik · ‎02-09-2004

Hi Robert, thanks for your fast response.

Have you tried to ping from two devices to different IP ranges during your test?

In details:

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.

Regards,

Milan

jakasper · ‎02-09-2004

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.

Regards,

-JK

milan.kulik · ‎02-10-2004

Thank you, James.

I'm glad this bug will be fixed soon. It made me really frustrated.

I'll open a TAC case.

Regards,

Milan