[Updated Module] Posh-SYSLOG v4.1.5 has been released

A new version of the Posh-SYSLOG module has been released.

The purpose of this update is to provide better support when running on PowerShell Core. This module removes the dependencies on Get-CIMInstance that isn't available on PS Core (at least on MacOS and Linux).

This code will not work correctly on PSCore 6 on WSL at this stage due to an issue in the underlying .Net Core version.

I have also switched to YAML builds and added additional test cases. I need to write a few more test cases for the new functionality.

Getting the Module

If you have never used the module before, the easiest way to get Posh-SYSLOG is through the PowerShell Gallery:

PS> Install-Module -Name Posh-SYSLOG

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name Posh-SYSLOG

You can also download the release from the module’s GitHub Releases page.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

Posh-SYSLOG version 4 is now available

The Posh-SYSLOG PowerShell module continues to surprise me. I originally developed the module in early 2012, making it available on GitHub in 2013. Since then I've continued to maintain the module, even though I don’t directly use the module.

Early this year, usage of the module skyrocketed. Growing from a few hundred downloads a year to an average of 10 thousand downloads each month. I don’t know what’s driven this growth, but it's been incredible.

Today is another milestone for Posh-SYSLOG. I'm happy to announce that version 4.0 has been released. This release adds support for sending SYSLOG messages over TLS. Sending messages over TLS

Switching to TLS is super easy!

With previous versions, the Transport parameter allowed you to specify UDP and TCP transport options, in version 4.0, we now have the TCPwithTLS option. To send a message with TLS:

PS> Send-SyslogMessage -Server ‘myserver.local’ -Message ‘My Message’ -Severity Alert -Facility kern -Transport TCPwithTLS

Default behaviours

There are some default behaviours that you should be aware of:

1. TLS 1.2 is used by default when connecting to the server. If your server doesn’t support this, you can use the SslProtocols parameter to change the behaviour. This parameter uses the type System.Security.Authentication.SSLProtocols, and supports specifying TLS 1.0, TLS 1.1, SSL 2 and SSL 3.
2. By default, the value specified for the Server parameter is validated against the server’s certificate. This means that the certificate will need to contain this value for validation to be successful. Currently, you can't change this logic, but I'll look at including this in version 4.1.
3. Sometimes we can’t validate the server’s certificate, we can ignore any validation errors by including the DoNotValidateTLSCertificate parameter. If this parameter is used, a warning will be displayed to the user.

Any potential breaking issues?

I don’t believe there are any breaking changes, but there's a minor change to one of the parameter types.

Before the Transport parameter was a string, this has been changed to an enum, Syslog_Protocol. PowerShell should be able to cast between the strings TCP and UDP to the enum without any issues. If this assumption turns out to cause any significant issues, I'll revert this change.

What else is fixed?

This release also fixes more issues caused on older PowerShell versions due to the use of OutputType([null])]. These have now been fully removed. I want to thank athelu for reporting the issue.

Getting the Module

If you have never used the module before, the easiest way to get Posh-SYSLOG is through the PowerShell Gallery:

PS> Install-Module -Name Posh-SYSLOG

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name Posh-SYSLOG

You can also download the release from the module’s GitHub Releases page.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

Posh-SYSLOG 3.3 has been released

Several days ago, Jared (powershellshock) raised a Pull Request for Posh-SYSLOG to correct an issue with the module’s manifest. It seems that in version 3.0 of Posh-SYSLOG, I used the PowerShellHostVersion attribute of the module manifest and not PowerShellVersion to specify the minimum Powershell version. This wouldn't have created issues within a normal PowerShell session, but would have prevented the module from loading in VS Code (as Jared reported) or the ISE.

To understand the difference of these attributes, I suggest reading: PowerShellHostVersion – WTF?, by Jeffrey Snover.

This is by far my most popular module and it's become even more popular this year. Since January there's been almost 20 000 downloads of the module, compared to 1600 for the previous 2 years combined! I'm amazed that this simple little module has gained such popularity!

Getting the Module

If you have never used the module before, the easiest way to get Posh-SYSLOG is through the PowerShell Gallery:

PS> Install-Module -Name Posh-SYSLOG

If you already have the module installed, you can update the module from the PowerShell Gallery with:

PS> Update-Module -Name Posh-SYSLOG

You can also find the module on GitHub.

Found an issue? Then raise any bugs or feature requests via GitHub Issues.

Posh-SYSLOG 3.2.1 has been released

In early January, Ben Claussen reported that there was a date formatting issue in Posh-SYSLOG, I've released Posh-SYSLOG 3.2.1 to address these issues.

When I initially developed Posh-SYSLOG, I didn’t correctly follow RFC 3164. The timestamps sent had a leading zero for dates less than 10, but the RFC states this should be a leading space. I don’t know how much this impacted some users, and apologise for any issues.

I want to thank Ben for putting together such a great issue, he included some recommended fixes and tested an updated version before its release.

As it stands, there are no outstanding issues, and only one feature request for Posh-SYSLOG. If you find any issues or want to make a feature request, please do so via a GitHub Issue.

You can get the new version from GitHub or from the PowerShell Gallery.

Kieran Jacobsen

Posh-SYSLOG 3.2 has been released

Over the Christmas break, I had a few hours to spare and tackled a few issues in some of my PowerShell modules. I’ve released Posh-SYSLOG 3.2 as a resolve of this.

This version removes the need to call Get-NetAdapter that's contained in the NetTCPIP module. The reason why I wanted to remove this dependency is to allow Posh-SYSLOG to run on PowerShell 6 (at least on Windows to start with).

An issue has been reported on GitHub, Ben Claussen has identified an issue with the timestamp for RFC3164 messages. The fix appears to be simple, but I'll want to do some more through testing. I'm hoping to have this fix out in the next week as version 3.2.1.

You can get the updated version from GitHub, or better yet, the PowerShell Gallery.

Kieran Jacobsen

Posh-SYSLOG version 3.1.1 has been released

Just a quick note to announce that I've released an update for my Posh-SYSLOG module, version 3.1.1.

The module fixes issues with PowerShell 4.0 support as reported by Cristiano Guadagnino (@Cris70) and Brian Napolitano (@bnapolitano). As always, a huge round of thanks goes out to the pair for discovering the issue, pointing me in the right direction to fixing the issue and testing the fixes.

Cristiano created an issue stating that the latest version (3.0.1) didn’t correctly load on PowerShell 4.0. Brian quickly pointed out that some of the changes made for the declaration of the enums was probably the cause of the issue.

I must apologise for the oversight on my part, mea culpa, I haven't been thoroughly testing my modules on older versions of PowerShell. I made two changes to resolve the issue:

1. I've switched back to the original enum syntax as it's supported PowerShell 3 through to 6.
2. I've removed the OutputType definition, as that appears to cause issues as well, and is a documentation only attribute.

Cristiano also pointed out that a few people use the Releases section of a GitHub project to source the PowerShell modules. I will ensure to keep these updated going forward.

You can get the updated version from GitHub, or better yet, the PowerShell Gallery.

Kieran Jacobsen

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