Ad Widget

Collapse

eventlog (windows) RegEx problem...

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • djmuk
    Junior Member
    • Dec 2017
    • 20

    #1

    eventlog (windows) RegEx problem...

    I am collecting window security logs to audit file accesses.
    This works..
    I am collecting from security Log, eventid 4663 and post processing to extract the values of interest (User, filename, access)

    However I am getting lot of 'noise' of directory attribute reads etc so I want to filter the log extraction to only collect log entries that include a filename.

    As I understand it - I SHOULD be able to add a regex parameter to the eventlog item that should only collect log entries that match the regex.
    I cannot get this to work...

    I want to match a filename - therefore I want to match a '.' followed by at least one non-space character (there is a single '.' ending a sentence elsewhere in the file but this is at the end of a line)
    Yes I know I will miss files without an extension but this is acceptable.

    I have tried many regex which either match everything (so no filtering) or match nothing (so no logs collected).

    eventlog[Security,"\..{3}",,,4663,,] - Matches everything even without a full filename

    I have even created a global regex and tested it against the log text and confirmed it works but still no luck - matches nothing
    eventlog[Security,@filename,,,4663,,]
    filename
    1 ยป (\..+)\n
    I have tried \R \n for the line terminator, . \S for the character matches, +, {3} for the quantifier....
    In theory I should be able to match against \.. as . doesn't match a newline but that doesn't work...

    Any suggestions - should the regex be in "" or not - it accepts it either way...

    thanks
    David

    Example of desired log entry - undesired ones only have directory path with no file name - this shows as multiple lines in the history window...

    Code:
     An attempt was made to access an object.    Subject:   Security ID: S-1-5-21-xxxxxxxxxxxxxx   Account Name: xxx Account Domain: xxxx   Logon ID: xxxx  Object:   Object Server: Security   Object Type: File   Object Name: E:\ServerFolders\Company\Documents\directory\GENERAL INFO\plot.log   Handle ID: 0x2ac   Resource Attributes: S:AI    Process Information:   Process ID: 0x5408   Process Name: C:\Windows\System32\notepad.exe    Access Request Information:   Accesses: ReadData (or ListDirectory)     Access Mask: 0x1
    Last edited by djmuk; 02-04-2020, 12:19.
  • djmuk
    Junior Member
    • Dec 2017
    • 20

    #2
    Duh.... PEBCAK..

    Firstly zabbix agent was v 3.0.x with frontend on 3.4.4 so the AGENT needed POSIX syntax and not PCRE syntax. It was failing every time I tried to use a PCRE shortcut like \w or \R and not returning any results. But this isn't highlighted anywhere in the documentation, I only found it due to the debate in the bugtracker about using PCRE on the agent...

    Secondly
    There is a filename towards the end of the log entry (the Process Name) that I had completely not seen... So every time I got the syntax right to match a file extension it matched ALL the log entries...

    So I had to add the 'Object name' string to the Regex to identify the section to match.

    HINT
    I added the 'filtering' regexp as a capture group on pre-processing and then used it as an output so I could see what was actually being matched...

    Comment

    • tim.mooney
      Senior Member
      • Dec 2012
      • 1427

      #3
      Nice catch and thanks for following up with what the resolution was. That will certainly help someone in the future.

      Comment

      • djmuk
        Junior Member
        • Dec 2017
        • 20

        #4
        What might be more helpful is to highlight the fact that (some versions of) the agent (and backend I believe) uses POSIX syntax - perhaps it should be in the 'Regex' section of the manual..

        "Be aware that Agent versions prior to X.X.X and backend versions prior to X.X.X use POSIX syntax and not PCRE as used by the frontend. This may impact on Regex syntax used in Item definitions (EG Log filtering) and other places where the regex is processed by the Agent or Backend"

        Perhaps the Devs can confirm the versions when the change was and also examples of where it may impact?

        David

        Comment

        Working...