Sending SYSLOG messages to TCP hosts and POSH-SYSLOG V3.0

The Posh-SYSLOG module has been very popular since its first release in 2013. SYLOG provides a common integration point into enterprise monitoring, alerting and security systems and administrators and developers often need to push messages from their scripts and automation activities to a SYSLOG server.

There are two common pieces of feedback, TCP support and improving the performance. I am excited to announce a new version of POSH-SYSLOG, which introduces TCP support and a number of performance improvements.

Kudos must go to Jared Poeppelman (powershellshock) from Microsoft who provided the TCP logic, optimised performance, and added additional Pester cases. I took some time out to make some additional improvements on top of Jared’s work. Due to the significant changes and additional functionality, I am considering this to be version 3.0.

The easiest way to get the module is from the PowerShell Gallery using Install-Module -Name Posh-SYSLOG. You can also clone the GitHub repository.

The first big change by Jared, was to implement the Begin {} Process {} End {} structure for Send-SyslogMessage. With this structure, we can leverage the pipeline to send multiple messages. I have developed scripts where I needed to read application logs and then send them to a SIEM product using SYSLOG; access via the pipeline simplifies these scripts and hopefully improves their performance.

The logic around determining the correct value to be sent as the hostname has been cleaned up and refined. This piece was free of issues, however there were some small tweaks that potentially improved performance. The function is now called as part of the Begin {} block, improving performance for bulk message transmissions. The logic has been moved out to its own internal function, allowing for separate testing and better mocking opportunities in Pester.

Another source of performance improvement is the removal on the need to call Test-NetConnection. This is a dramatic source of improvement when Send-SyslogMessage is executed in a workgroup (that is, a non-domain joined) environment. Previously we called Test-NetConnection to determine the correct network interface that we are using to communicate with the SYSLOG server; now we simply ask the socket for the source IP address and then use Get-NetIPAddress to check if this is a statically assigned address.

All the network functionality and calls have been moved to internal functions. This helped with testing, I can now mock all the network activities which allows for better testing with Pester. The network tests are now much more reliable.

Finally, Jared and I have increased the number of Pester tests. I have tried to aim for over testing everything in the hope that all potential issues are flushed out. With a massive upgrade to the functionality, and such a refactoring have the potential to introducing issues. I am confident that things have been appropriately requested. If issues are found, please raise them via GitHub.

So what is the future now for Posh-SYSLOG? Well for now, I just want to ensure there are no bugs or issues, after that I want to look at implementing the other commonly asked feature; TLS support.

The PowerShell community has been amazing, I have been lucky to have such wonderful community contributions over the past few years. A massive thanks to Jared, Ronald, Xtrahost and Fredruk.

Kieran Jacobsen

SYSLOG, PowerShell, Pester and the PowerShell Gallery

Out of all of the content on this site, my posts about integrating SYSLOG and PowerShell are by far the most popular. Whilst this might seem peculiar to some, I can definitely see the value that this would bring to an enterprise environment.

I first wrote about my initial integration attempts back in 2014. In fact that post, Sending SYSLOG messages from PowerShell, had been the reigning champ as most popular until very recently, losing its title to my work on MS15-034 and my comments on Skype for Business.

In early 2015, a number of bugs were found in the formatting of the UDP messages it sent. I invested time and energy into resolving these issues, resulting in RFC 3164 and RFC 5424 compliant messages being sent. I discussed the process of resolving them in the post, Revisting SYSLOG in PowerShell.

Well, a few weeks ago, it came to my attention that I hadn’t quite ironed out all of the bugs. I spent some time, worked through some possible fixes and implemented them. The issue turned out that when selecting the hostname to send, there was a chance it would send either the wrong IP address, not a blank hostname. It didn’t take long to come up with some new logic (which I still believe could be better), but I wanted to shake the code and determine if there were any others hiding out.

Pester

The best way to repeatedly test PowerShell functions, CMDLets, modules and scripts is through the use of Pester. I will admit, that I hadn’t, until this point, taken a look at Pester and this seemed like a great opportunity.

I started with the low hanging fruit. How about we check the input validation is correct? This shook out some validation bugs, and whilst there I realized I could implement parameter sets to improve things.

Now came the hard part. How do I validate the format of the messages that I am sending?

Well, firstly we need to mock some of the CMDLets that are used, to ensure our output is predictable. Things like Get-Date need to be mocked so we can control the messages being sent. I would also modify some of the environment variables for that execution to ensure things like hostnames were predictable.

But the messages are still sent over UDP, how do we look inside them?

The easiest method I found, well it was a bit of a pain, but it produces repeatable and testable outcomes. I would start by setting up a job using New-Job that had a basic UDP listener. The code simply waits for a UDP packet to come in, and returns as output the contents of that packet. Once I have something listening, all I need to do is run my command, and then get the output (of the now completed job) which will contain the SYSLOG message sent.

It is messy, but it allowed me to shake out another logic issue, which has to be a good thing.

A New Name and a New Home

With all of this work, one last thing has always bugged me about the module, the Name! Whilst PowerShellSyslog is simple and descriptive, it has always felt a little bit crude. Now I suck at coming up with names, so I stuck with what seems to be a habit now and stuck Posh- in front of what it actually does. The module and the GitHub repository have now been renamed to Posh-SYSLOG.

I have been attempting, where possible to move my major GitHub repositories to the PoshSecurity banner. As such, I have moved the Posh-SYSLOG to here: https://github.com/poshsecurity/Posh-SYSLOG

GitHub creates redirects when you move or rename a repository, so all of your current links and working copies should continue to work.

It’s worth noting that if you are manually importing the module via “import-module PowerShellSyslog”, you will need to update this to reflect the new module name.

Easier Installation via the PowerShell Gallery

PowerShell 5 brings a bunch of improvements and new features. One feature that I am so excited about is the Package Management functionality, as it provides new deployment options for not only conventional installed applications but also for PowerShell modules and scripts. The PowerShell Gallery allows administrators and developers to download, install and share modules and scripts.

I have made Posh-SYSLOG available via the gallery here. I will be working to ensure that the gallery is kept up-to-date with the GitHub repo. If you want to install via the gallery, simply type “install-module –name Posh-SYSLOG”.

Future and Thanks

If you are using the module, and find an issue, please feel free to raise an issue on GitHub, I will respond as quickly as possible. I want to ensure this module is the community’s preferred module for connecting to SYSLOG and are happy for any questions, comments or feedback.

I want to thank all of those who have already provided feedback and have provided assistance in testing.

Kieran Jacobsen