Security, PowerShell Kieran Jacobsen Security, PowerShell 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

Read More
PowerShell Kieran Jacobsen PowerShell Kieran Jacobsen

Microsoft Releases PowerShell to Linux and OS X!

The Announcement

On Friday I woke to the remarkable news that PowerShell has been open sourced, and made available on Linux and Mac. You should read the PowerShell Team’s Announcement, and Jeffrey Snover’s announcement. There is an excellent video on Channel 9, PowerShell on Linux and Open Source.


I want to first start by congratulating everyone over at Microsoft, in particular the PowerShell Team and Jeffrey Snover.  I have been an avid user of PowerShell since the codename Monad days and it has been one of the few technology constants in my 10 years in the industry (the other being Active Directory).

It has been a long road since the original Monad Manifesto to reach this milestone, and it could not have been accomplished without Jeffrey’s amazing efforts. Don Jones posted up an excellent article on just why this is such an important accomplishment, you should also read the PowerShell Team's post: Windows PowerShell is now “PowerShell”: An Open Source Project with Linux support – How did we do it?.

This wasn’t an unexpected announcement, in fact, it was quite expected. I never doubted that this accouncement would never occur, to me it wasn't a matter of IF PowerShell would become open source, but WHEN.

Like almost everyone I was in the dark that this was happening, but I had a gut feeling things were close. There were plenty of clues and signs that this was about to happen: .Net Core, Nano Server, Bash on Windows and even the inclusion of Pester in Windows 10. Still, I wasn’t quite expecting to wake up on Friday to the news.

What Was Announced

Microsoft announced that from PowerShell would be run as an open source project, and that an intial alpha release would be made available. This release is version 6.0 and is currently available PowerShell Core, for Windows, Ubuntu, Centos and Mac OS X, with more platforms expected in the future.

So what is PowerShell Core? Core is a cut down version of PowerShell, designed to run on top of the .Net Framework Core edition. We have already seen PowerShell Core in releases of Windows Nano Server. Core edition does not support all of the functionality that the Desktop version will contain.

It is worth noting that this is an alpha release, and as such, you should treat it, and have suitable expectations. This isn’t a production ready release, and likely isn’t going to be for a while yet.

Changes to Remoting

One of the big items in the announcement is the changes to the PowerShell Remoting Protocol (MS-PSRP). Currently the MS-PSRP only supports WinRM, however with PowerShell 6.0, support for SSH will be introduced.

This isn't executing commands over SSH, what is actually occuring is that the objects forming our request are serialized into XML, transmitted over SSH, and then de-serialized. SSH is used as a transport layer for the remoting protocol, mush like WinRM is currently used. SSH is not replacing WinRM, just providing another option for administrators to use.

What this does mean is that you will start to be able to manage your Windows servers from your Macbook, and your Linux servers from your Windows 10 machine. 

I had a significant number of issues with WinRM. From its poor performance to its insecure defaults, and I am hoping that the inclusion of SSH support should start to make a difference. If nothing else, it provides a number of new and interesting ways to design and manage our environments.

What’s Missing?

This is a PowerShell Core release, it is based upon the .Net Core, and as such, some things are just simply not going to be there. It should also be obvious that things like WIM and CIM are not supported and will not be available. Get-EventLog isn't there either, as it doesn't fit with the Linux log file model.

Security Impacts!

Security teams should begin to familiarise themselves with not only PowerShell 6.0 and its remoting changes now, but also with Nano Server prior to their release. With a cross pollination of administration teams, that is, Windows and Linux administrators managing each other's eco systems, we are going to see changes in our network architecture and security requirements. SSH connections from a Windows system will begin to move from the abnormal to the normal.

PowerShell is already a highly desirable target for attackers, with more instances of attacks using PowerShell on a daily basis. With the move to include PowerShell on Linux systems, especially servers, the attraction of PowerShell to attacks is likely to increase. The ability to move from a Windows client to that lovely Red Hat farm makes PowerShell an awesome attacker and Red Team tool. Some in the security industry are already calling PowerShell the next Flash or Java for cross platform hacking.

I guess the other thing we need to consider is that a significant number of people are probably pouring over the PowerShell source code with the intention of finding vulnerabilities. Whilst the chances are probably small that someone might find a significant issue, there is still the possibility.

Other Investments to Watch

Looking through the known issues document, and also the PowerShell Teams announcement, two items stood out to me:

  • The ability to write CMDLets in Python and other languages
  • Unix-style wildcard expansion

Getting Started

The best place to start is the PowerShell Home Page, after that, the PowerShell GitHub repository is your next stop.

Windows

It is worth noting that installing PowerShell 6.0 will not replace your existing PowerShell version, it is installed side-by-side. It is also worth noting that this installs Core edition and not Desktop edition.

Simply grab the right MSI, and run the installer! 

Linux

There are official guides for Centos 7, Ubuntu 14.04 and Ubuntu 16.04. The Centos guide should also work for Red Hat.

There are also two great guides:

Mac OS X

You can find Microsoft's instructions for installing here, for more detail check out The IT Hollow's guide, Install PowerShell on Mac.

Other Install Options

There are a bunch of other ways you can get started with PowerShell 6.0:

Once you have PowerShell installed, take a look at some of the demos available.

If you are new to PowerShell and are coming from a Linux or Unix background, check out: A Unix Persons Guide to PowerShell.

Contributing

The great part of any open source project is that we can all play our own part and contribute. You don’t need to be a developer to contribute either, I often contribute to projects by helping out with documentation, or cleaning up simple default configuration files and example usage.

If you feel like contributing, start by reading the contribution guidelines. I also recommend you take a look at the governance process. The Governance process includes how to raise issues, make contributions, and participate in the design process via RFCs. The documents also provide information on the roles and responsibilities of everyone involved in the project.

I recently spent some time working on some issues with the documentation of the PSScriptAnalyzer. The contribution process is similar to that of PowerShell, and it was super simple and easy to create a pull request and work with the PowerShell Team. I would like to point out that if your pull request is large, you may need to sign the Contribution License Agreement, don’t worry, it isn’t difficult and only takes a few seconds to complete. The agreement just covers that the work you are completing is yours and not of anyone else.

Tool Updates

Update your development tools! Virtual Studio Code (and the PowerShell extension), PSScriptAnalyzer and the ISE Steroids have all been updated to include support for PowerShell 6.0.

More Information

With all of this you should be well on your way to working with PowerShell on Linux and Mac OS X! Good luck and don't forget to share your experiences!

Kieran Jacobsen

Read More
PowerShell Kieran Jacobsen PowerShell 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

Read More