Regex and CONTENT field

[CharlesBeierle]

My correlated alert uses a NOT LIKE comparison against the [CONTENT] variable of a message to take out messages during maintenance windows. This worked fine until a couple of weeks ago. I am not certain but it was about the time I put SP2 (before it was pulled) and the September ESU on my box. Maybe I have just gone nuts but if I have a NOT LIKE with .*/20..19|20|21|22):.* against the [CONTENT] variable envision should toss anything with a timestamp within the message like 10/15/2009:20:11:32 right?

[RSAAdmin]

Yes, you're right.  I don't doubt it worked like that before, but I question what changes they may have made in SP2. 

From my experience, using the NOT LIKE (or LIKE) comparison against [CONTENT] used to be (before v4.0) a good way to do partial string / sub-string matches, but RSA fixed that (read: took the capability away while fixing something else) in v4.0 so now anything in a LIKE or NOT LIKE [CONTENT] is going to have to match the entire [CONTENT].  I know, I know, it defies all the rules of sanity, but it is what it is.  I suspect maybe that's what's happening in your case.

You may have already tried this, but in the corelation alert build a filter statement that uses REGEX comparison against the exact field you're after, or perhaps [content] if it will let you, and use something along the lines of

../../20..19|20|21|22):..:..

I didn't test that pattern, but you get the general idea.

It could be that the pattern you're specifying now, in the NOT LIKE, is attepting to filter as a literal sring of text .*/20..19|20|21|22):.* against the entire [CONTENT], and because the entire [CONTENT] doesn't look like .*/20..19|20|21|22):.* your alerts are not getting filtered like you want. 

I'm probably wrong... no more than do i learn how it works, some SP comes along and makes undocumented changes to the logic of how the product works and I'm forever questioning myself.

[CharlesBeierle]

I went back to my old notes. The reason this is borken is that my variables used to parse...they stopped. Parsing is occurring correctly in the query but the Statement filter is not showing anything but [Content]. No XML changes were made. Any troubleshooting tips are appreciated.

Message Edited by cbeierle on10-15-200911:49 AM

Well a restart of the Alerter and Web Server brought the variable list back but the filters were all set to [CONTENT]. I manually repaired them - pain.

Message Edited by cbeierle on10-15-200912:05 PM

[RSAAdmin]

Yeah that sounds frustrating.   I'm unsure of what's causing that, can't really offer any sugestions but can confirm that I have seen that before just once, with one of my corelated alerts. It was specific to Checkpoint Firewall logs, and the same thing happened... wen't in there one day and the filter statement had lost the list of all field names, and only displayed [CONTENT].   Backed out one page and removed the specific event ID (specified on the previous page) and re added it and the values reappeard like you described.   Weird.

[RSAAdmin]

I had this problem on all of my correlated alerts when I tried to use Device Groups.  It turned out to be related to the upgrade to 4.0.  You have to make sure you read through the notes and do some of the steps in there...I will try to look up my notes later as to exactly what I did to fix this.

[CharlesBeierle]

Just to update everyone on this issue: the disappearing variables is a known issue with no known fix, but support is working on it. There is a fix if you are running SP2 but not SP3 because the fix was recompiled into the webserver service and not part of SP3. I am waiting on a delivery date but it appears that the NOT LIKE is working just fine not sure what was going on when I originally posted.