Retours sur le 1er #FRPSUG

Le 1er RDV gratuit et 100% virtuel du French PowerShell User Group (#FRPSUG) a bien eu lieu et a été un franc succès 🙂

Si vous l’avez râté, vous pouvez revoir l’enregistrement sur cette page https://frpsug.github.io/2016/09/20/FrPSUG01-Enregistrement, vous y trouverez également la présentation et le code présentés.

Comment rejoindre la communauté?

Get the TLS ciphers suite order

Last year, Microsoft published an advisory about a vulnerability in Schannel where weak/insecure ciphers were used in TLS sessions. More recently Microsoft also published an Update to add new cipher suites to Internet Explorer and Microsoft Edge in Windows.

In the above advisory, they introduced a GPO setting where you can set a new ciphers suite order. Nice, I love it.
But wait, without that GPO setting,…

  • How do I know what is the order of ciphers being used?

The question was answered on this stackoverflow.com forum page
Unfortunately it doesn’t work with PowerShell 2.0 (default version) on Windows 7 and I get the following error
inptrsize-operator

  • What about newer systems?

The code proposed on the stackoverflow.com forum page works in Windows 8.1 and PowerShell 4.0. There’s also a module called TLS but it doesn’t have the Get-TlsCipherSuite cmdlet 😦
tls-module-on-windows81

On Window 10, you’ve got more in the TLS module and the Get- TlsCipherSuite is available 🙂

On Windows 10 to get the order of ciphers, you simply do

(Get-TlsCipherSuite).Name
  • How can I get the order of ciphers whatever the operating system and its version of PowerShell?

I’ve slightly changed the code proposed on the stackoverflow.com forum page : line 49 replaced by 48 😎

Additional links
Documented ciphers suites per OS
Update to enable TLS 1.1 and TLS 1.2 as a default secure protocols in WinHTTP in Windows
BCryptEnumContextFunctions function
CRYPT_CONTEXT_FUNCTIONS structure
BCryptFreeBuffer function

Testing WSUS server operational status

During the summer, someone asked the following questionwsus-monitoring-question on the WSUS patchmanagement.org mailing list.

I replied and immediately thought that Pester would do the job and quickly showed how he could test if he can connect to the console.

I’ve actually more than a WSUS server to manage. So, I started separating the environmental configuration data from the pester tests code almost the same way Mike F. Robbins did in his recent post where he goes far beyond to what I did.

I think it’s a great idea and here’s what I did in my case to monitor my WSUS server operational status.

To get started, I copied the Pester module on my WSUS server, imported the module and did in the ISE:

# helper to create the required files and folder if not present
New-Fixture -Path  ~/Documents/Pester -Name Test-WSUS
# Put the config data into that file:
psEdit ~/Documents/Pester/Test-WSUS.ps1
# Put the pester code into that file:
psEdit ~/Documents/Pester/Test-WSUS.Tests.ps1

After the first 3 commands, here’s what the ISE console looked liked
pester-new-fixture-wsus-tests

The first file Test-WSUS.ps1 looks like this by default.
It will be used to store my configuration data.
pester-wsus-tests-01

The second file Test-WSUS.Tests.ps1 is where I’ll write the pester tests code
pester-wsus-tests-02

After editing the 1rst file Test-WSUS.ps1 like this:
pester-test-wsus-file (fake data in this case)

…and the 2nd file Test-WSUS.Tests.ps1 like this:

…I’m actually ready to assess the operational readiness of my WSUS configuration by using the following cmdlet:

Invoke-Pester -Script ~/Documents/Pester/Test-WSUS.Tests.ps1

wsus-server-config-invoke-pester

I still feel like a Pester newbie but no doubt that Pester rocks 😎