Over the decades we’ve seen PI Systems used in many creative and valuable ways. Sharing tips and tricks discovered along the way is kind of fun. So welcome to PI Square and let the fun begin!
One of the ‘geekier’ (is that a word?) use cases involve mining system log data. OT systems have become more complex than ever. Monitoring the associated performance indicators and log events can provide an edge for operational mission assurance.
Like process data, system logs come in a variety of formats and access methods. There are some generally applicable tips and tricks for handling log data. This post explores the Windows firewall as representative of nuances related to logging based on clear text flat files. A PI System with at least one UFL interface node is a classic approach for processing file based data sources.
First we notice that although the Windows firewall is enabled by default, logging is disabled by default. Right or wrong, having to enable ‘extra’ or ‘verbose’ logging is actually fairly common for all kinds of systems. In this case, logging is enabled with a few clicks of the mouse; here are the equivalent console commands:
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable
The default setting creates two files in the %systemroot%\system32\logfiles\firewall folder: ‘pfirewall.log’ and ‘pfirewall.old’. Current events are appended to the log file. The log file overwrites to the old file based on reaching a size limit (4MB default).
You might have guessed a fairly common ‘monkey wrench’ with this pattern. Windows firewall keeps the current log open which blocks UFL from processing the file. Getting the events from the old log is viable but adds significant delay waiting for the current log to fill.
A small script can generate files for UFL. The trick is to copy the current log so it’s easy to measure of the number of lines in the file. The script selects only the lines that were appended (including checking for a roll over) and outputs to a unique file for processing by UFL. Extending the script to copy logs from remote systems is left to a future post.
The Measure-Object -line and Select-Object –last Powershell cmdlets made this script kind of fun. The biggest trick was Out-File –encoding “Default”. Without specifying “Default” the file will be UNICODE which isn’t compatible with UFL.
Firewall log entries have a simple space delimited structure as shown in the file header:
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
The action field notation is “ALLOW or “DROP” and the path field notation is “SEND” or “RECEIVE”. Four corresponding UFL message filters are as follows:
UFL message filters provide a natural way to store data in different PI points depending on the type of event (i.e. protocol, source IP address, source port, destination port and size in points named for inbound dropped traffic).
PI points are configured as follows: Ports and size as INT32 points; IP addresses and protocol are STRING points; optionally, protocols may be setup as a digital state set (eg. use IANA codes per %systemroot%\system32\drivers\etc\protocol).
It’s especially handy to monitor dropped traffic both for troubleshooting and even as an attempted security breach indicator. Even with the limitations in this example, one typically discovers there is more activity affecting a system than is immediately obvious.
In summary, monitoring the host firewall on a mission critical system makes sense but we are only getting started – there is more fun to come!
TL;DR System logs come in many sizes and shapes. There can be subtle nuances in mining events from file based logging systems. This post introduced a general pattern for copying from open log files and processing with UFL. A future post in this series extends the script used in this pattern to gather log files from remote systems.