• Support
  • Forums
  • Blogs

NXLog Domain Controller Logons


New Life Form
I set up NXLog to forward logs from my domain controller but the sheer amount of logon events is too much. There are different logon types, described here, for each logon ID. I really only want types 2 and 11, the main culprit for the massive amount of logins is auto network logins which are type 3. 

NXLog has the patterns.xml file which have patterns for each event ID, but each event ID can have multiple logon types. I want a way to filter out all types except for 2 and 11. Is this possible, and how can it be done?

Share post:


  • edited August 2017
    I just get a 403 error every time i try to reply with useful information. Can you use if statements or something similar to only match certain results from the translation result of a userdata field?
  • Could you just write a policy to keep the events you do not want from going into the SIEM or Logger? 
  • @zparker

    No, you cant filter on userdata fields in policies, only event IDs
  • i would honestly put that in as a feature request with support. we also did the same but it helps speed things along when theres multiple requests
  • edited August 2017

    I was thinking that you could define the userdata in the logical conditions of the policy. I'm wrong though, that only applies to the action. :/ 
  • @rdieth

    Thats what i was thinking too. Just wondering if there was a way before bugging support. What specifically did you put your request in for?
  • just that it would be very helpful to have the userdata fields as an option when creating a policy, it should be a no brainer but it helps for you to include a scenerio where that might come in handy.
  • I'm thinking that you can eliminate these messages in the rsyslog rule and the nxlog config. Hopefully i get some lab time today to test it out. 
  • @zparker

    I took a look and if there is a way I must have missed it. It looks like nxlog uses the pattern.xml file to find events, but I dont think you could use that to filter the logon types. I'm by no means an expert on that though so if you could find a way I would be very thankful!
  • @kspaeth if i understand correctly all the events be HIDS or nxlog are sent to /var/log/syslog.log then the rsyslog rules scans syslog.log for which lines to relocate. i think zparker means for you to add a line to the rsyslog rule to only pick the events you want. something like omit the event if it contains type 3.

    im not an expert so i dont know the exact statements you would need for that. another concern is would the edits you make still be there after an AV update. 
  • @rdieth 

    Ahh ok, that may be possible but that probably wouldnt be a best practice. Like you said updates usually remove custom configurations like that unless they're suppored by AV.
  • edited August 2017
    Before doing this I would completely review the risk of removing logon types. It could limit your ability to find root cause from the logon type, as well as delete events needed for security/compliance if applicable. . 

    step 1: vim /etc/rsyslog.d/nxlog.conf

    step 2: add the lines below to the nxlog.conf

    if $syslogtag contains "WIN-NXLOG" and $rawmsg contains ["Logon Type:   3","Logon Type:   4","Logon Type:   5","Logon Type:   6","Logon Type:   7","Logon Type:   8","Logon Type:   9", "Logon Type:   10"] then {

    step 3: service rsyslog restart

    step 4: verify your Logon type logs by #tailf /var/log/nxlog.log |grep 'Logon Type'

    step 5: verify you are getting the rest of the nxlogs #tailf /var/log/nxlog.log 

    step 6: If this is not what you want #rm /etc/rsyslog.d/nxlog.conf and then service rsyslog restart. 

    The rsyslog rules go in alphabetical order, so if the nxlog doesnt contain those $rawmsg's the syslog will continue on to the zzzzz_nxlog.conf rsyslog rule and parse the regular events properly. 

    Hopefully this helps @kspaeth, it tested good for me. 

    edited after finding a better method. 
  • @rdieth  once you enable the global nxlog plugin it automatically starts parsing traffic based on syslog tags to the proper nxlog.log location. As do all plugins in the /etc/rsyslog.d/ folder (As long as the device sending syslog has the proper tag) 

    If your device isn't listed in /etc/rsyslog.d/ I have found best practice to write your own rsyslog and logrotate rule to take advantage of the global plugin.
  • edited August 2017
    @rdieth @kspaeth here is a link to an AV forum post I wrote about writing your own global plugins. 

Sign In or Register to comment.