Cisco Support Community
Community Member

NetMeeting RDS (Sig 3453) False Positive Tuning

OK, my upgrade to the wonderful world of 3.0 is done except for rebuilding filters to cut out the false positives and noise. One signature that shows up repeatedly on every sensor is the MS NetMeeting detect. I was pretty sure it's false, but wanting a good audit trail I ran a report on the detects seen since I started up the sensors and the first thing I notice is the source ports of 1433 and 80 for my web servers. OK, so it's probably nulls in the reply packets. So to verify, I turn on IPlogs for the detect, and examine the packets in the integrated Ethereal (my favorite new feature of the 2.2.3/3.0 mix so far).

OK, it is web and SQL traffic that is getting detected incorrectly. So let's find those nulls. And as I start looking through the captures, I can find nothing on port 1720! But every trace file I've looked at has source ports for some session on 1710. Could the detect be looking at the wrong port?

I checked the tuning function (Director 2.2.3), but found 1720 correctly set as ServicePorts. So this brings up a few questions....

1 - If I turn on the TCPThreeWayHandShake token in packetd so it only looks at full TCP sessions, will this fix the erroneous detect on source ports by checking on ONLY the port used as the destination in the packet with the SYN flag - that is, the service port?

2 - If I turn on the TCPThreeWayHandShake token in packetd, what kind of performance hit will I take on my sensors? They are 4230's.

3 - When IPlogs are made, where does the triggering packet fit into the log. Does the log start with the trigger, dump all packets in buffer before the trigger, save X number packets before and after the trigger - which? This would help me find the exact packet that triggered the detect.

4 - I suppose I could just turn off the signature, but I don't like that approach. Besides, look at everything new and cool I'll learn when y'all answer all of these! Anyway, when I checked into the tuning parameters, the most likely suspect for filtering out false positives without introducing false negatives would be the MultipleHits parameter, but he MS FAQ seems vague about how many Nulls are necessary, I couldn't find an exploit for the attack to sniff the attack, and - much more disconcerting - with all the extra control and information you've given me, I still don't know what the RegEx string is that I'm referencing with the MultipleHits parameter, so even with all the info in the world about the expoit I'd still have a problem. Unless, of course, it's what y'all reference in the SigStringInfo, in which case I have to ask if the three dots trailing the second null are elipses indicating lots of nulls, or a part of the RegEx expression. In other words, could y'all help me know how to tune this signature?

Many thanks in advance....

Cisco Employee

Re: NetMeeting RDS (Sig 3453) False Positive Tuning

As usual you are very observant and are one step ahead of what we have fielded. You are exactly correct that the correct behavior for ToService should be to follow the SYN packet. This logic is unfortunately not currently in place. I do recommend that you turn on Three Way though as it has no negative impact on performance and will protect you from someone flooding you with spoofed attacks.

I'll now answer your questions as best I can. Pardon my being vague on timelines, but we are ready to give dates on 3.5 yet. The IPLog feature as it curretnly exists is triggered on the attack packet and logs all subsequent packets. There is a valid reason for this internally that we can not overcome until 3.5 is released. Starting with 3.5 the offending packet will also be logged. It is not possible for us to keep historical packets as that would either require us to write to disk (not a good thing for a near real-time sensor) or have a whole lot more physical memory than is currently in the appliance.

We will be defining the ToService and the FromService as you have mentioned, but once agian for internal structural reasons we can't do this until 3.5.

So now to try and solve your big problem. This signature is actually looking for 100 nulls one after the other in the same TCP Stream directed at port 1720. Are the false positives being generated primarily on IN to IN, IN to OUT, or OUT to IN traffic? My guess would be IN to OUT, but I will need to know for sure so that I can help construct an Exclusion clause to quiet things down for you.


Community Member

Re: NetMeeting RDS (Sig 3453) False Positive Tuning

I added the TCPThreeWayHandshake per the instructions that follow:

The TCPThreeWayHandshake token has the following format:


where is 0 (off) and 1 (on). The default is off.

And when I restarted the sensor, then went to the director, and fired up nrConfigure, it imported the new packetd.conf file, and gave the following error:

>Warning! nrConfigure could not parse the following line(s) in /org100/host101/cfg/version.9/packetd.conf:

Reason: unrecognized token.

TCPThreeWayHandshake 1

Did I mistype something?

Community Member

Re: NetMeeting RDS (Sig 3453) False Positive Tuning

The token is:


Notice the upper S on shake. Does your documentation show it lower? I need to make sure the documentation is correct for this. Sorry for the confusion.

Community Member

Re: NetMeeting RDS (Sig 3453) False Positive Tuning

OK, it's a documentation error. The copy I was using (Sensor 3.0 - Cisco Secure Intrusion Detection System Internal Architecture)for the token was at:

It shows a lowercase 'S'on html and PDF when looking at the details under packetd (page 22 on PDF).

Community Member

Re: NetMeeting RDS (Sig 3453) False Positive Tuning

Thanks for the information. I have notified the tech writer and there should be a corrected version on CCO soon.

CreatePlease to create content