Tag: Powershell

Disabling SSL2.0 & Others for IIS7.5 for PCI! /w Powershell

=========================================================

Just to note, this has since been revised. You can see the changes @ http://justfen.com/post/22121613280/pci-iis7-5-beast-vulnerability-donendusted

=========================================================

So, recently been touching up some of our setups for PCI compliance, one of the things we failed on was the fact SSL2.0 and other Protocols were enabled on our IIS7.5 sites.

This had to be implemented into our Web Server deployment scripts and was done with the following;

function Set-IISSecProtocols {

$protopath = “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols”

& reg.exe add “$protopathPCT 1.0Server” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$protopathSSL 2.0Server” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$protopathSSL 3.0Server” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$protopathTLS 1.0Server” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$protopathTLS 1.1Server” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$protopathTLS 1.2Server” /v Enabled /t REG_DWORD /d 00000001 /f

}

And for the Ciphers;

function Set-IISCiphers {

$cipherpath = “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers”

& reg.exe add “$cipherpathNULL” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathDES 56/56” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC2 40/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC2 56/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC2 128/128” /v Enabled /t REG_DWORD /d 00000000 /f 

& reg.exe add “$cipherpathRC4 40/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC4 56/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC4 64/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC4 128/128” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$cipherpathTriple DES 168/168” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$cipherpathAES 128/128” /v Enabled /t REG_DWORD /d 00000001 /f 

& reg.exe add “$cipherpathAES 256/256” /v Enabled /t REG_DWORD /d 00000001 /f

}

To have these changes you must remember to restart the machine, yes REALLY. I actually fell for the trap, so thought I’d share!

And yes, it’s a little dirty but it works!


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%

ECHO

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.

Using PortQry to Test Firewall Rules

Firstly, what is PortQry?

Well, it’s a little program which can be used via command line or through a GUI to test specific ports on an IP.

You can obtain it here.

Now how can it be useful?

Sure, you can use Telnet [Port#] to the same effect (Kind of) but this little program can be scripted to allow you to test rules on both software and hardware firewalls.

I originally used it to module test rules on our Cisco ASA5510, since then I’ve moved on to a more advanced script which I’ll share.

So a little explanation, this script will allow you to enter a server name or IP to test again, you then specify the port and it’ll test that port against the specified IP with some TCP traffic.

Again, this can be built on but there is a more robust Powershell script which I’ll post at a later date for this purpose.

Either way, a cool little program.


Scripting AVG 2012 Removal

So, we’re recently upgrading to Kaspersky from AVG in our environment and came across a stumbling block of where Kaspersky wasn’t removing AVG clients from machines that we deployed to.

After fiddling around with deploying the AVG removal tool I decided to put together this little Powershell/Batch script to remove from selected machines remotely.

This will remove AVG without user interaction and won’t reboot the machine. I’ve found this pretty handy considering the AVG Admin Console appears to lack the uninstall feature.

So simply fire up a Powershell/CMD prompt hammer that in and away you go.