Help with BackOrifice 2000 UDP Alarms, Sig ID #4055

[bbenton]

Need help with IDS sensor Alarm for BackOrifice 2000 UDP.

We have 4 users at a remote office using VPN to connect to corporate 3000 Concentrator. They are using VPN Client 3.6.1 using IPSEC tunneling over UDP on port 4500. Starting 10/1/02 our 4210 IDS sensor is alarming on their traffic targeting the concentrator IP address. It is flagging signature ID 4055, BackOrifice 2000 UDP, on port 4500, several hundred times a day. How exactly is the sensor identifing this traffic? We are trying to find out if this is a false positive. We have AV scanned the machines and BO doesn't show on any of them.

Anyone have any ideas how I can find out exactly what's going on. The sensor has no details of the signature, at least not that I can find.

Sensor 4210, v3.1(1)S22.

I've opened a TAC case too.

[mcerha]

From your message, it looks like to the 4210 is inspecting the encrypted tunnel traffic going to/from the VPN3000. The BO2K signature is a little unusual in that will inspect UDP connections on all ports looking for the BO2K-encrypted packets. This signature has been known to false postive on traffic that resembles the BO2K-encrypted traffic. This may be the case with VPN-encrypted traffic. I would recommend that a RecordOfExcludedPattern be used to filter out these alarms. I will also make sure that the NSDB get updated to list this as a potential false positive. BTW, the S22 NSDB entry for signature 4055 does refer you to the description of signature 3992 for more information.

[bbenton]

Thanks. Will do.

[routerhand99]

I can verify that my VPN concentrator connections to other concentrators trigger the same 4055 BO2K alarm. I have applied both simple source and destination filters (concentrator's ip) on the sig and all subsigs; I continue to get alarms;

e.g. Subject: IDS Alarm 4055

Sensor reports source: w.x.y.z destination: a.b.c.d @2003/02/11

opened TAC case but can't seem to resolve.

[jakasper]

Problem identified and fixed in the new 3.1(4) sensor code. There was a case

where it was looking into the packets for the special signature pattern, but

it should have not been allowed to get to this level. I put in a couple more

descriminators that will prevent this situation.

I tested with the "false positive" traffic trace we have with traffic on

ports 4500.

This will be included in the 3.1(4) service pack, due out in April.

Until then, you may want to try reversing the src and dst addresses in the

RecordOfExcludedPattern filters because the filter may be confused with

the address. (Even though it shows as SRC A, DST B in the alert, the

packet that causes the alarm is actually SRC B, DST A, so that may be

the point of filter confusion.)

[routerhand99]

I am getting the same alarms with the same configuration. Glad I saw your post.