PowerShell Syntax Highlighting with SquareSpace

SquareSpace has been my blogging platform of choice since 2011. My biggest complaint with the platform has always been syntax highlighting. SquareSpace comes with some simple highlighting, but it only supports a few languages, certainly not PowerShell. Over the years I've tried everything from simply using bold and italic text, to using custom HTML and even embedded Pastebin and GitHub Gists. No matter what I tried, I was never happy with the result.

I'd looked and failed to find something that worked. While I was preparing for my post Managing Windows Speculation Control Protections with PowerShell DSC, I decided to take one more look. Stephen Gurnett had written a post about highlighting support for Swift with SquareSpace using Highlight.js. I took a quick look and realised this would work for PowerShell.

Highlight.js provides syntax highlighting for 176 languages with 79 different styles. It features automatic language detection, supports multiple languages per page and works with any markup or js framework. The best part is it's dead simple, even on a SaaS blog like SquareSpace. You don’t need to host the code anywhere as it's available via CloudFlare's CDN.

Getting Started with Highlight.js

The first step is including the code on our site. From the SquareSpace configuration/management screen, navigate to Settings > Advanced (Under Website) > Code Injection. You'll see 4 sections, Header, Footer, Lock Page and Order Confirmation Page. In the header section, add this HTML:

<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/vs2015.min.css">
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/languages/powershell.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>

What does this all mean?

The first line tells a visitor’s browser to load another CSS stylesheet. In this example, the Visual Studio 2015 theme. Don’t worry, your existing styles can safely live together with the Highlight.js stylesheet.

The next line loads the Highlight.js JavaScript. This is the code that will make syntax highlighting work on your blog. We're loading it from CloudFlare’s JavaScript CDN.

The third line is important. By default, the Highlight.js that's available from CDN only supports a set of common languages: CSS, JavaScript, C#, Bash, INI, SQL, Markdown, JSON, HTML, etc. Sadly, PowerShell isn’t one of the common languages. To support PowerShell, we need this line to load the support for it.

The last line causes the magic to happen. This line triggers the Highlight.js to go and highlight any code blocks that it finds.

Using Highlight.js

For Highlight.js to work on SquareSpace, you'll need to use the markdown content block and then use the code block syntax. Your Markdown block would look something like:

```
Write-Host 'This is some PowerShell!'
```

That block would result in the this:

Write-Host 'This is some PowerShell!'

Highlight.js will attempt to detect what language is used within the content block, though you can specify the language. I opt to specify the language. You can specify blocks like this:

```json
[
  {
    "title": "apples",
    "count": [12000, 20000],
    "description": {"text": "...", "sensitive": false}
  },
  {
    "title": "oranges",
    "count": [17500, null],
    "description": {"text": "...", "sensitive": false}
  }
]
```

Which results in:

[
  {
    "title": "apples",
    "count": [12000, 20000],
    "description": {"text": "...", "sensitive": false}
  },
  {
    "title": "oranges",
    "count": [17500, null],
    "description": {"text": "...", "sensitive": false}
  }
]

If you don’t want to use markdown for all your content, you can always mix text and markdown blocks.

Issues

So Highlight.js isn’t perfect, especially its PowerShell support. Highlight.js doesn’t properly highlight all PowerShell syntax, for instance, it will only highlight CMDLets that it knows about. Support for things like DSC or Pester isn’t present. While annoying, these aren't show stopping issues.

Conclusion

I hope this helps you work with PowerShell in SquareSpace. Happy Blogging!

Kieran Jacobsen

Managing Windows Speculation Control Protections with PowerShell DSC

As part of their response to the Speculative Execution vulnerabilities, Spectre and Meltdown, Microsoft released updates for all supported systems. Microsoft made the decision to not enable these protections in Windows Server by default. It's up to you as the administrator to enable the protections.

Microsoft’s used the reg command to make the registry changes. This tool is great on a single machine, but it doesn’t scale. You need to use a configuration management tool like PowerShell DSC to make the changes at scale.

These changes could be made using the registry DSC resource, but I wanted a more simplified configuration using a custom DSC resource. I looked, and couldn’t find a resource, so I created cSpeculationControlFixes.

Managing the Protections

With the cSpeculationControlFix resource, administrators can enable or disable the protections. You'll need to restart the system for the changes to take effect, cSpeculationControlFix will notify the LCM if a reboot is required.

Configuration EnableSpeculationControl
{
    Import-DscResource -Module cSpeculationControlFixes
    cSpeculationControlFix enableSpeculationControlFix
    {
        Status = 'Enabled'
    }
}

Spectre Variant 2

Microsoft now provides a mechanism for enabling and disabling the Spectre Variant 2 protections separately from the other protections. With the cSpectreVariant2 resource, an administrator can enable or disable just the Spectre Variant 2 protections. For this resource to work, you need to have the updates described in this knowledge base article. Once again, cSpectreVariant2 will notify the LCM if a reboot is required.

Configuration EnableSpectreVariant2
{
    Import-DscResource -Module cSpeculationControlFixes
    cSpectreVariant2 enableSpectreVariant2Fix
    {
        Status = 'Enabled'
    }
}

Configuration DisableSpectreVariant2
{
    Import-DscResource -Module cSpeculationControlFixes
    cSpectreVariant2 enableSpectreVariant2Fix
    {
        Status = 'Disabled'
    }
}

Anti-Virus Compatibility Flag

A massive issue with these updates is that Windows Update won't offer to install these updates unless your anti-virus product as created the appropriate compatibility flag. This issue is, what about those computers, mainly servers, that don’t have an anti-virus product installed? The truth is, these update, nor any further security updates will be available.

To combat this, the cSpeculationControlAVCompatibility resource allows and administrator to enable this flag on systems that don’t have an anti-virus installed.

Configuration EnablecSpeculationControlAVCompatibility
{
    Import-DscResource -Module cSpeculationControlFixes

    cSpeculationControlAVCompatibility enablecSpeculationControlAVCompatibility
    {
        Status = 'Enabled'
    }
}

Getting the Module

The easiest way to get cSpeculationControlFixes is using the PowerShell Gallery, or from GitHub.

Installing the module from the gallery is as easy as:

PS> Install-Module -Name cSpeculationControlFixes

If you discover any issues, please report then via GitHub Issues.

Kieran Jacobsen

Using Intune and AAD to protect against Spectre and Meltdown

I’m a big fan of Intune’s device compliance policies and Azure Active Directory’s (AAD) conditional access rules. They're one piece of the puzzle in moving to a Beyond Corp model, that I believe is the future of enterprise networks.

Compliance policies allow us to define what it takes for a device (typically a client) to be considered secure. The rules could include the use of a password, encryption, OS version or even if a device has been jail-broken or rooted. In Intune we can define policies for Windows 8.1 and 10, Windows Phone, macOS, iOS and Android.

One critical thing to highlight is that compliance policies don’t enforce settings and don’t make changes to a device. They're simply a decision-making tool that allows Intune (and AAD) to determine the status of the device. If we want to make changes to a device, we need to use Intune configuration policies. It's up to the admin or the user to make a non-compliant device compliant.

A common misconception with compliance policies are that the verification process occurs in real-time, that is, when a user tries to login the device's compliance status is checked. The check occurs on an hourly basis, though users and admins can trigger off a check manually.

The next piece of the puzzle are conditional access policies. These are policies that allow us to target different sign-in experiences for different applications, devices and user accounts. A user on a compliant device may receive a different sign-in experience to someone using a web browser on some random unknown device.

How compliance policies and conditional access work together

To understand how Compliance Policies and Conditional Access works, let’s look at a user story.

Fred works in the Accounting department at Capital Systems. Fred has a work PC issued by Capital’s IT Team, and a home PC that he bought from a local computer store.

The IT team has defined two Conditional Access policies:

  • For Office 365: a user can connect from a compliant device, or needs to pass an MFA check.
  • For the finance system: the user can only connect from a compliant device and must pass an MFA check.

How does this work in practice?

When Fred tries to access his email from his work device, perhaps through a browser, AAD will check his device’s compliance status during login. As Fred’s work PC is compliant, it will allow access to his email.

Fred now goes home, on the train he remembers he forgot to reply to an important email. When Fred gets home, he starts his home PC and navigates to the Office 365 portal. This time, AAD doesn’t know the device, so it will treat the device as non-compliant. This time, Fred will be prompted to complete MFA before he can access his email.

Things are different for Fred when he tries to access Capital’s finance system. Fred will be able to access this system from his work PC as its complaint, assuming he completes an MFA request. Fred won't be able to access this finance system from his home PC as his device isn’t compliant.

These rules allow Capital System’s IT team to govern who can access an application, from what devices they can access it from, and if they need to complete MFA.

Ensuring Spectre and Meltdown Patches are installed

We can use compliance policies to check if a device’s OS version contains the Spectre and Meltdown patches. When Intune checks the devices compliance, if isn't running with expected patch level, it will be marked as non-compliant.

What does this mean for the user? In Fred’s case, if his work PC lacks those updates, he may receive extra MFA prompts and loose access to the finance system, until he installs the right patches.

The Intune portal and PowerBI can be used to generate reports on device compliance and identify devices that need attention. You can also configure Intune to email a user when their device becomes non-compliant. This email can be customised, I recommend that you include a link to a remediation guide or to your support system.

Configuring Intune Compliance Policies

Compliance policies can be created and modified in the Azure Portal via the Intune panel. Simply navigate to the Device Compliance and then Policies. You'll need to create a separate policy for each OS that you want to manage compliance.

Within a compliance policy, we specify an OS version using a “major.minor.build” formatted string.

The major versions numbers are:

  • Windows 10 - 10.0 Note that the .0 is important*
  • Windows 8.1 - 3
  • macOS - 10

We can express things like Windows 10 Fall Creators, or macOS High Sierra using the minor version number.

  • Windows 10 Fall Creators Update - 10.0.16299
  • macOS High Sierra - 10.13

Finally, we can narrow down to a specific release or patch by using the build version number. For instance, the January updates for each platform are:

  • Windows 10 Fall Creators Update - 10.0.16299.192
  • macOS High Sierra - 10.13.2

You can specify the minimum and maximum OS version by navigating to Properties, Settings and then Device Properties.

Setting the minimum Windows 10 version in a compliance policy.

Setting the minimum Windows 10 version in a compliance policy.

Setting the minimum macOS version in a compliance policy.

Setting the minimum macOS version in a compliance policy.

Once you have made this change, devices that don't meet the minimum version will be marked as non-compliant during their next compliance evaluation.

Kieran Jacobsen

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