For about 5 years, I've been using NXLog to forward Windows logs from all of my Windows servers into a Graylog server. Recently, one of the servers developed an issue where there will be event ID 5156 ("The Windows Filtering Platform has permitted a connection") triggered when NXLog sends logs to the Graylog server, which triggers another event ID 5156, which triggers another and another and another and so on. So, logging from that one server goes from an average of 50,000/hr to as much as 10 million/hr. I don't see anything in the Windows event logs that seems to trigger the issue but all I have to do is restart the NXLog service to break the loop and resume normal log forwarding for a couple of days. I've uninstalled/re-installed NXLog and upgraded to 'nxlog-ce-2.10.2150'. The server is essentially just a file server. It has Checkpoint Endpoint installed but so do all of my other Windows servers.

Does anyone have any suggestions as to what causes this and how I can resolve the issue? I don't want to disable the events from the Windows Filtering Platform in total but I wouldn't mind if I never saw one triggered by NXLog making network connections. Below is the same NXLog config I've used for all of the Windows servers, even the server I'm having the issue on. Any help you can give is greatly appreciated.

#define ROOT C:\Program Files (x86)\nxlog
define ROOT C:\Program Files (x86)\nxlog

Moduledir %ROOT%\\modules
CacheDir %ROOT%\\data
Pidfile %ROOT%\\data\\nxlog.pid
SpoolDir %ROOT%\\data
LogFile %ROOT%\\data\\nxlog.log

<Extension gelf>
Module xm_gelf

<Input in>
# Use 'im_mseventlog' for Windows XP, 2000 and 2003
Module im_msvistalog
# Uncomment the following to collect specific event logs only
Query <QueryList>\
<Query Id="0">\
<Select Path="Application">*</Select>\
<Select Path="System">*</Select>\
<Select Path="Security">*</Select>\

<Output out>
Module om_udp
Host 172.xx.xx.xxx {<-- redacted for this post}
Port 12201
OutputType GELF

<Route 1>
Path in => out

AskedOctober 10, 2019 - 5:28pm

Answer (1)

You could either discard the event to make sure it is not forwarded:

if ($EventID == 5156 and $Channel == 'Security') drop();

However the best approach would be to disable the audit policy so that these connections are not logged into the Windows EventLog at all. See e.g. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772749(v=ws.10)?redirectedfrom=MSDN

Comments (7)

  • CityofRome's picture

    Thank you for your response. As I mentioned, I don't want to completely disable those event IDs because some of them are valid. I would really like to find out why this is happening and what I can do to resolve it.

  • Zhengshi's picture

    This seems to be a function of the event being logged itself, and a common annoyance from a quick google search.

    The solution in these three articles is to disable logging of success events for firewall and only log failures.

    auditpol /set /subcategory:”Filtering Platform Connection” /success:disable /failure:enable


    As far as I can tell, there is no way to white-list a process for firewall communication exclusion like you are asking, so logging failures only seems like the best solution.

  • CityofRome's picture

    Thank you for responding. I don't want to disable all successful filtering events because I want to capture the legitimate connections (successes & failures). I want events of any network connections made to this particular server.

    NXLog has been on this server for a couple of years and I've had no issues. Even now, the problem seems to begin at random and continues until I restart the NXLog service. It seems to take a couple of days before it begins its runaway activity again. Any other suggestions are appreciated.

  • b0ti's picture

    Event 5156 should have a few other fields like $Application, $DestAddress and $DestPort that you can add to the drop() statement to exclude nxlog->graylog connection logs and prevent self-excitation.

  • CityofRome's picture

    This morning, I finally had time to take another look at this server to see if I could resolve the NXLog issue. While looking in the event logs, I found this server developed some type of hard drive issue (even though it's a virtual server) on 06/12/19. That's about the time the server began having the NXLog problem. I'm pretty sure the hard drive issues are what caused the NXLog problem because the timing seems too coincidental not to be related. Either way, I've got to rebuild this server.

    I haven't been doing any log filtering. But, because of your suggestion about how to resolve the problem I was having, I'm going to start filtering some of the nuisance logs so your help and attention will not be in vain. Thanks to all of you for your help.