Tag: Patch

PCI, IIS7.5, BEAST Vulnerability… Done’n’dusted!

As mentioned in a previous article, I’ve recently been trying to lock down our IIS servers a little bit more, mainly for PCI compliance.

On these ventures something was noticed, the enabled RC4 protocols were not actually working!

We ummed, we arrred to no result. After checking over Microsoft documentation, the problem became a little clearer.

It seems on Server 2008R2/IIS 7.5, simply setting the registry values for the ciphers to 1 wasn’t enough. They HAVE to be set to 0xfffffff or 4294967295 ;P

Something which was also noted was that TLS 1.1 and 1.2 hadn’t been activated, these also needed an extra registry key (Yep…)

So without much more jibberish, here’s the update Powershell functions/scripts to help aid you with making your IIS7.5 servers PCI compliant.

Now, that’s the ciphers and security protocols set up.

The last step to make your servers BEAST immune is to change the SSL cipher priority.

This is done by creating a GPO!

  1. At a command prompt, enter gpedit.msc. The Group Policy Object Editor appears.
  2. Expand Computer ConfigurationAdministrative TemplatesNetwork, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, click the SSL Cipher Suite Order setting.
  4. In the SSL Cipher Suite Order pane, scroll to the bottom of the pane.
  5. Follow the instructions labeled How to modify this setting.

It is necessary to restart the computer after modifying this setting for the changes to take effect.

The list of cipher suites is limited to 1023 characters.

See http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx for more indepth instructions.

The one thing to note for this is that the RC4 ciphers NEED to be at the top of this list as they are immune to the BEAST attack.

A great write-up of this by Steve Dispensa can be found over here http://www.phonefactor.com/blog/slaying-beast-mitigating-the-latest-ssltls-vulnerability.php

He even includes an example string for the cipher priorities!

But that’s that.. for now. If only we could move onto TLS1.2!

Automating Software Deployment With Ninite!

So, as in a previous post you’ve seen, I was using PDQDeploy to push software out across our network.

Now, I’ve got to the point where I’m fed up of having to set up new tasks, packages, hacking .MSI’s, creating transforms for each deployment… So I came back to Ninite.

When I was first looking for a solution to our software patching woes I’d originally looked at Ninite, something like deploying a Ninite installer with a silent switch, this was quickly shelved… it seemed pretty unsupported and wasn’t the most robust of sounding strategies. Saying that, this was over a year ago so recently I decided to check them out again. In that time they’ve now released a very cheap PRO version which can now mimic the functionality of Linux’s apt-get -somewhat-.

This got me thinking about a few possibilities, so I set out to set up an automated software patcher using it by using a little batch script and some PowerShell to pull machines to deploy to.

The Plan

  • Automate software deployment
  • Generate a list of target machines to patch
  • Use PowerShell to generate this list from AD
  • Create a batch file and attach to scheduled task with some logging.

Pulling the data from AD

Now I went down a few routes for this, the first was using some of PowerQuest’s AD CMDlets but I was sure there was another method. My chosen one was to use ADSI.

So without further babble from me here’s the PowerShell script I used to generate a list of machines for Ninite to use to target

$NiniteADSearch=new-object System.DirectoryServices.DirectorySearcher([ADSI]‘LDAP://OU=The,OU=Computer,OU=Group,DC=My,DC=Domain,DC=Name’,’objectCategory=Computer’)

$NiniteADSearch.FindAll()|%{$_.Properties.name} | Out-File NiniteTargets.txt -Encoding Default

This lil script when run will pull a list of Machines from the OU you’ve set it to, and all the sub OU’s. As in my domain, all Desktops and Servers are in completely different OU’s, this wasn’t an issue.

The script will also output the result into a file called NiniteTargets.txt in the directory you ran it from using ANSI encoding (Ninite will bomb out without this encoding, and yes it took a while to find that out)

Plugging the results into a batch file

So you’ve managed to generate your list of machines, time to feed these into the Ninite Pro program.

This was simply done using the cmd line switches which are documented here.

My batch file looked something like the following;

set NiniteScript=D:NiniteNiniteMachineGenerate.ps1

set NiniteTargets=D:NiniteNiniteTargets.txt

set NiniteCache=D:NiniteNiniteCache

set NiniteLog=D:Ninitelog.txt

powershell.exe -command %NiniteScript%

NiniteOne.exe /updateonly /remote file:%NiniteTargets% /disableshortcuts /disableautoupdate /cachepath %NiniteCache% /silent %NiniteLog%


So what does this batch file do?

  1. Will only update currently installed apps
  2. Will generate and feed list of target machines in from the NiniteTargets.txt file generated by PowerShell script
  3. Will disable shortcuts and auto updates
  4. Will cache the installer/patch files to selected directory
  5. Will install updates silently and log the results to selected log file
And that’s about it, the result of this is an automated patching system when you set the batch file to be run as a scheduled task.
A word to the wise though, you may want to try playing around with NiniteOne.exe manually before just doing this, it’s still relatively new and you don’t want to be screwing up a big deployment now do you ;)?
I hope this helps some admin out there, especially those with a pretty tight budget.