To monitor logs from the on-board firewall on your Windows clients/servers and analyze suspicious or unusual activity, the best approach is to send logs to a central security log monitoring solution. In our test lab we show you one way to do this, which involves sending Windows Firewall logs from a Windows 10 client to Graylog.

To set up a separate Graylog instance, you can refer to the instructions from the relevant manufacturer. For the test lab, we installed a current CentOS on a VM and installed a current version of Graylog. We chose NXLog Community Edition as the log shipper on the Windows client.

Activate Windows Firewall logs

You may (or may not) be surprised that logging of the on-board firewall is not activated on Windows clients and servers by default. That means you have to activate in order to collect log data.

Windows Firewall logging can be activated by going to Windows Defender Firewall with Advanced Security -> Properties -> [Domain/Private/Public] Profile tab -> Logging Customize.

Then change the value No (Default) for the items Log dropped packets and Log successful connections to Yes. It is also a good idea to change the size limit of the log file to at least 16384 KB.

You can also achieve the same result with the following group policies:

Configure NXLog

Once you have installed NXlog on the Windows system following the manufacturer’s instructions, you will also need to configure it. Since the recipient will be a Graylog instance, the Firewall logs should be sent using the Graylog Extended Log Format (GELF) via UDP.

The relevant settings are found in the NXLog configuration file located in its installation directory (default path):

C:\Program Files (x86)\nxlog\conf\nxlog.conf

The following changes are made in nxlog.conf. The default configuration file serves as the starting point.

1. Activate GELF

1. The default log format is syslog, but you can comment out this line using the # symbol
2. The GELF module is added on a new line
3. The name of the extension is changed from _syslog to _gelf

<Extension _gelf>
   Module	xm_gelf
   #Module	xm_syslog
</Extension>

2. Configure log input

1. The im_vistalog module was replaced by im_file to allow reading from a file log
2. Then the path of the log file is defined, in our case here: File "C:\Windows\system32\LogFiles\Firewall\pfirewall.log"
3. An exec statement is also required here. This reads the timestamp of a log line using regex and writes it in the designated field in GELF so that Graylog can then write the correct timestamp of the log line in the dedicated field. Without this exec statement, Graylog would receive and display an incorrect timestamp, thus preventing the adequate analysis of the log files. There may be other, more efficient ways to do this, but for the purposes of the test lab we thought this solution was acceptable.
4. The name of the <input> is changed to WinFirewallLog

<Input WinFirewallLog>
   Module	im_file
   File		"C:\Windows\system32\LogFiles\Firewall\pfirewall.log"
   Exec		if $raw_event =~ /(\d\d\d\d\-\d\d-\d\d \d\d:\d\d:\d\d)/ {$EventTime = strptime($1, '%Y-%m-%d%t%H:%M:%S');}
   # For windows 2003 and earlier use the following:
   # Module	im_mseventlog
</Input>

3. Configure Graylog as recipient

1. The om_tcp module was replaced by om_udp
2. The IP address of the Graylog server is entered as host
3. An available listener port of the Graylog server is entered as the port
4. The existing exec statement is commented out with # characters to disable it
5. The Exec $ShortMessage = $raw_event; statement is added. This ensures that the entire log line is sent in the Message field. Without this statement, the message would be truncated to 64 characters.
6. The OutputType is defined as GELF in a separate line
7. The name of the output is left as the default value out

<Output out>
   Module	om_udp
   Host		192.168.1.10
   Port		12202
   Exec 	$ShortMessage = $raw_event;
   #Exec        to_syslog_snare();
   OutputType	GELF
</Output>

4. Restart NXLog Service to apply the new configuration

If you are already sending Windows event logs via NXLog or would like to do so, make sure to define a separate <input>, <output> and <route> for each log item in the NXLog configuration. This could look as follows:

1. Each <input> is defined with a corresponding name – here they are <Input WinEventLog> and <Input WinFirewallLog>
2. Two separate <Output>, each defined with a different port. This means that in Graylog you can define a specific input for each port for the different log items and analyze them separately. Here they are <Output out1> and <Output out2>.
3. Now you need two <Route> definitions with the format Input ⇒ Output. So one <Route> is defined with Path WinEventLog => out1 and one with Path WinFirewallLog => out2.

<Input WinEventLog>
   Module      im_msvistalog
</Input>

<Input WinFirewallLog>
   Module	im_file
   File		"C:\Windows\system32\LogFiles\Firewall\pfirewall.log"
   Exec		if $raw_event =~ /(\d\d\d\d\-\d\d-\d\d \d\d:\d\d:\d\d)/ {$EventTime = strptime($1, '%Y-%m-%d%t%H:%M:%S');}
</Input>

<Output out1>
   Module	om_udp
   Host		192.168.1.10
   Port		12201
   OutputType	GELF
</Output>

<Output out2>
   Module	om_udp
   Host		192.168.1.10
   Port		12202
   Exec		$ShortMessage = $raw_event;
   OutputType	GELF
</Output>

<Route 1>
   Path		WinEventLog => out1
</Route>

<Route 2>
   Path		WinFirewallLog => out2
</Route>

Configure Graylog

So that Graylog can now receive the logs, you need to define a corresponding input:

1. Log in to the Graylog web console
2. Open System -> Input in the top menu
3. On the input page, select UDP GELF in the dropdown and click on Launch new input
4. Enter the required data in the relevant window:
   1. Select current Graylog node
   2. Give the input a name, such as WindowsClient_FirewallLogs
   3. Enter the bind address of the Graylog server: 192.168.1.10 (from the <output> in nxlog.conf)
   4. Enter the corresponding port 12202 (from the <output> in nxlog.conf)
   5. For the test lab, we kept the default values for all other settings

Now Graylog is ready to receive the first logs. Because the test lab is using a CentOS for Graylog, it is also important to ensure that a corresponding port has been opened on the CentOS firewall.

Currently, the individual fields of the log line are displayed as a string in the Message field. However, this prevents Graylog from being used to analyze all fields. Graylog also comes with an extractor which can read the incoming logs, using GROK for instance, and write them to the corresponding fields in Graylog.

Graylog already offers a selection of GROK patterns. These need to be modified somewhat for the log lines of the Windows Firewall log, so that – is sent as a placeholder for unpopulated values. This means that the minus sign is added to the GROK pattern that is used for the firewall log extractor.

In the Graylog web console, you can manage GROK patterns under System->GROK Patterns. To map all fields of the Windows Firewall log line with a GROK pattern, the following new GROK patterns were created on the basis of existing patterns.

Now you should be able to create the extractor:

1. Under the previously created input, go to Manage Extractor -> Add Extractor -> Get Started
2. A submenu will appear with the button Load Message; here you can search incoming log messages, or call up a specific message by entering its ID. This allows you to test the extractor in the next steps.
3. After clicking the button, the message will appear, and you can configure an extractor for each field. In our case this needs to be done for the Message field using GROK Pattern.
4. The following GROK pattern can now be entered into the designated field: %{DATESTAMP:UNWANTED} %{WINFIREWALL_WORD:action} %{WINFIREWALL_WORD:protocol} %{WINFIREWALL_IP:src-ip} %{WINFIREWALL_IP:dst-ip} %{WINFIREWALL_INT:src-port} %{WINFIREWALL_INT:dst-port} %{WINFIREWALL_INT:size} %{WINFIREWALL_INT:tcpflags} %{WINFIREWALL_INT:tcpsyn} %{WINFIREWALL_INT:tcpack} %{WINFIREWALL_INT:tcpwin} %{WINFIREWALL_INT:icmptype} %{WINFIREWALL_INT:icmpcode} %{WINFIREWALL_WORD:info} %{WINFIREWALL_WORD:path}
5. The Try button lets you test whether the pattern works straight away
6. Finally, add the extractor
7. Now you can use Graylog functions to analyze all fields from the Windows Firewall log lines

To avoid a possible off-set in the Graylog Message Timestamps, the Graylog time zone needs to be changed accordingly. In our case to CET. The change needs to happen in a configuration file of Graylog, which can be found under /etc/graylog/server/server.conf.

root_timezone = CET

After a restart of the Graylog service one can use all features of Graylog to analyse the fields of Windows Firewall log-lines.

Conclusion

In the context of a lab set-up you can quickly and easily create and operate central security log monitoring through the firewall logs of your own Windows population – as soon as you have worked out how to process logs in a useful format in Graylog. There may well be simpler or more efficient methods for the format problems present in Windows Firewall logs, but for an initial test this approach is certainly adequate. If you are planning something similar in a production environment, don’t forget hardening for both Graylog itself and its host.

You can find more information on security logging in our articles.

About the Author

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)

Links

• https://centos.org/download/
• https://nxlog.co/products/nxlog-community-edition
• https://www.graylog.org