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