SCHANNEL Einstellungen des Azure Windows Marketplace image geändert

Vor ein paar Wochen habe ich bemerkt, dass das Azure Marketplace Image für Windows 2016 Server zusätzliche Registry Einstellungen erhalten hat. Diese Einstellungen unterscheiden sich von einem manuell installierten und aktualisierten Windows 2016 Server!

Diese neuen Registryschlüssel deaktivieren die folgenden Ciphers und Protokolle:

Ciphers
- RC4 128/128
- RC4 40/128
- RC4 56/128
Protokolle
- SSL 2.0 Client
- SSL 3.0 Client/Server

Vorab: Diese neuen Einstellung betreffen veraltete Cipher Suites und Protkolle und sollten in jeder gehärteten Umgebung schon seit Jahren deaktiviert sein. Ein Teil der Einstellungen ist sogar obsolet, da Sie nur die Standardeinstellungen von Windows 2016 abbilden.

Mit der Veröffentlichung von Windows Server 2016 hat Microsoft alle Änderungen an SCHANNEL in folgendem Artikel dokumentiert „TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016„. Hier wird z.B. darauf hingewiesen das NULL, MD5, DES und export Cipher deaktiviert wurden.

Außerdem beschreibt der Artikel das SSL 2.0 komplett entfernt und SSL 3.0 im Standard für Client- und Serververbindungen deaktiviert wurde. Die Registry Einstellung für die Protokolle sind somit überflüssig und wurde wahrscheinlich nur für ein schlecht konfiguriertes Audit Tool oder zum besseren Verständnis hinzugefügt.

2013 wurde von Microsoft das „Security Advisory 2868725“ veröffentlich, in dem darauf hingewiesen wird, das RC4 cipher deaktiviert werden sollten. Nach ~ 5 – 6 Jahren hat Microsoft diese Best Practice nun auch für neue VMs auf Azure umgesetzt. Leider wurde es nirgends dokumentiert.

Zu beachten ist außerdem, dass diese Änderung nicht Windows Server 2016 Installationen von einem ISO betreffen, selbst wenn alle Sicherheitspatches installiert wurden. RC4 wird auf diesen Maschinen, ohne manuell Eingriff oder dem Einsatz von SCH_USE_STRONG_CRYPTO, weiterhin aktiviert sein. Mehr zu den TLS Cipher Suites in Windows 2016 findet man hier.

Report des Log Analytics Workspace für alle Azure VMs

Manchmal möchte man nur wissen, an welchen Log Analytics Workspace (OMS für die älteren Leute da draußen) eine VM ihre Log Daten sendet. Oder sogar alle von euren Azure VMs auf einmal?

Mit dem folgenden Skript ist diese Aufgabe kinderleicht. Und dank RamblingCookieMonster und seinem PSExcel Modul kannst du das Ergebnis direkt an alle Excelliebhaber versenden.

Azure Log Analytics – RegEx Groß-Kleinschreibung ignorieren

Bei der Suche in Log Analytics kann matches regex sehr hilfreich sein. Im Standard ist die Regular Expression Case Sensitive. Um dies zu ändern muss der Paramter i übergeben werden.

Hier eine Beispielabfrage, mit der die IIS Logs nach Logs von einem bestimmten Computer durchsucht werden.

W3CIISLog
| where ( Computer matches regex "(?i)MyCoMpUtEr" )
// (?i) = Case insensitive

W3CIISLog

| where ( Computer matches regex "(?i)MyCoMpUtEr" )

// (?i) = Case insensitive

AzureRM.Network 0.9 macht Probleme mit Azure Automation

Solltet Ihr Azure Automation nutzen und das Modul AzureRM.Network in einer der Versionen von 0.9.0 bis min. 0.10.0 nutzen, kann es zu Problemen bei der Ausführung von Azure Automation Runbooks kommen.

Sollten die verwendeten Runbooks insgesamt etwas aufwändiger sein, kann es durch diese Version zu hoher Memory Auslastung kommen. Sollten über 400 MB RAM verwendet werden, endet das Runbook nach drei Versuchen im Status „Suspended“.

The runbook job was attempted 3 times, but it failed each time. Common reasons that runbook jobs fail can be found here:
https://docs.Microsoft.com/en-us/Azure/automation/automation-troubleshooting-automation-errors

Ein Downgrade auf Version 6.8.0 ist erforderlich. Am einfachsten natürlich mit PowerShell.

$ModuleName = "AzureRM.Network"
$MaxVersion = "6.8.0"

# Gather information
$AffectedAutomationAccounts = Get-AzureRmAutomationAccount | Get-AzureRmAutomationModule -Name AzureRM.Network | Where-Object {$_.Version -gt $MaxVersion }

# Review
$AffectedAutomationAccounts | Select-Object ResourceGroupName, AutomationAccountName, Name, Version

#region Redeploy
Write-Verbose "Generate RootTemplate.json in `"devopsgallerystorage.blob.core.windows.net`""
$uri = "https://www.powershellgallery.com/packages/$ModuleName/$MaxVersion/DeployItemToAzureAutomation?itemType=PSModule&amp;requireLicenseAcceptance=False"
# This only generates the RootTemplate.json for the specified version. It simulates the Button "Deploy to Azure Automation" on the Gallery
Invoke-WebRequest $uri | Out-Null

# Download JSON 
$uri = "https://devopsgallerystorage.blob.core.windows.net/armtemplates/$ModuleName/$MaxVersion/RootTemplate.json"
$templateFileName = ".\RootTemplate.$ModuleName.$ModuleVersion.json"
Invoke-WebRequest -Uri $uri -OutFile $templateFileName | Out-Null

$AffectedAutomationAccounts | ForEach-Object {
    $AutomationAccountLocation = Get-AzureRmAutomationAccount -ResourceGroupName $_.ResourceGroupName -Name $_.AutomationAccountName | Select-Object -ExpandProperty Location
    $parameters = @{
        "Automation Account Name"            = $_.AutomationAccountName
        "Automation Account Location"        = "$AutomationAccountLocation"
        "New or existing Automation account" = "Existing"
    }
    $params = @{
        "ResourceGroupName"       = $_.ResourceGroupName
        "TemplateFile"            = $templateFileName 
        "TemplateParameterObject" = $parameters
        "Mode"                    = 'Incremental'
    }
    New-AzureRmResourceGroupDeployment @params
}
#endregion

$ModuleName = "AzureRM.Network"

$MaxVersion = "6.8.0"

# Gather information

$AffectedAutomationAccounts = Get-AzureRmAutomationAccount | Get-AzureRmAutomationModule -Name AzureRM.Network | Where-Object {$_.Version -gt $MaxVersion }

# Review

$AffectedAutomationAccounts | Select-Object ResourceGroupName, AutomationAccountName, Name, Version

#region Redeploy

Write-Verbose "Generate RootTemplate.json in `"devopsgallerystorage.blob.core.windows.net`""

$uri = "https://www.powershellgallery.com/packages/$ModuleName/$MaxVersion/DeployItemToAzureAutomation?itemType=PSModule&requireLicenseAcceptance=False"

# This only generates the RootTemplate.json for the specified version. It simulates the Button "Deploy to Azure Automation" on the Gallery

Invoke-WebRequest $uri | Out-Null

# Download JSON

$uri = "https://devopsgallerystorage.blob.core.windows.net/armtemplates/$ModuleName/$MaxVersion/RootTemplate.json"

$templateFileName = ".\RootTemplate.$ModuleName.$ModuleVersion.json"

Invoke-WebRequest -Uri $uri -OutFile $templateFileName | Out-Null

$AffectedAutomationAccounts | ForEach-Object {

$AutomationAccountLocation = Get-AzureRmAutomationAccount -ResourceGroupName $_.ResourceGroupName -Name $_.AutomationAccountName | Select-Object -ExpandProperty Location

$parameters = @{

"Automation Account Name" = $_.AutomationAccountName

"Automation Account Location" = "$AutomationAccountLocation"

"New or existing Automation account" = "Existing"

}

$params = @{

"ResourceGroupName" = $_.ResourceGroupName

"TemplateFile" = $templateFileName

"TemplateParameterObject" = $parameters

"Mode" = 'Incremental'

}

New-AzureRmResourceGroupDeployment @params

}

#endregion

Eine freie IP Adresse in Azure finden

Ob bei automatisiertem Deployment oder beim Erstellen eines Load Balancer in Azure. Eine freie IP Adresse zu finden ist leider mit den vorhandenen Cmdlets nicht ohne weiteres möglich.

Weiterlesen →

PowerShell Modul Entwicklung: Pester Tests

Mittels Pester Tests lässt sich bei der PowerShell Modul Entwicklung ein Grad an Qualität sicherstellen, die man sonst nur sehr aufwändig manuell erreichen würde. Dabei gilt es zwei wichtige Faktoren zu prüfen. Modul- und Funktions-Integrität.

Weiterlesen →

AzureSimpleREST Module

Obwohl Microsoft einen tollen Job mit ihrem AzureRM Modul macht, gibt es immer wieder Gründe diese Cmdlets nicht zu nutzen. In den meisten Fällen weil Sie langsamer sind als direkte Anfragen gegen die Azure REST API sind. In anderen Fällen weil bestimme Funktionalitäten noch nicht implementiert wurden.

In diese Lücke positioniert sich das von mir geschriebene Modul AzureSimpleREST

Weiterlesen →

Azure Availability Sets vNet Abhängigkeit

Um eine hohe Verfügbarkeit eines Service auf Azure zu garantieren, sind Availability Sets eine beliebte Möglichkeit. Doch welche Anforderung hat diese Konfiguration an das zugrunde liegende virtuelle Netzwerk?

Weiterlesen →

Proxy, Proxy an der Wand…

…wer nervt am meisten im ganzen Land.

Proxy Server sind in vielen Enterprise Umgebungen immer noch ein gern genutztes Mittel um den eingehenden Webtraffic zu kanalisieren, scannen und Gefahren abzuwehren.
Leider setzen die wenigsten Unternehmen auf transparente Proxy Lösungen und zwingen einen dazu den Proxyserver in der jeweiligen Applikation zu hinterlegen.

Da die Konfiguration des Proxys für jede Applikation unterschiedlich ist, habe ich ein Gist erstellt in dem ich diese sammle. Auf bestimmte Konfigurationen gehe ich diesem Blogeintrag weiter ein.

Weiterlesen →

„Reverse engineering“ der Azure REST API

Die Azure REST API ist grundsätzlich gut dokumentiert und dank des REST API Browsers lässt sich auch auf die schnelle etwas ausprobieren. Jedoch gibt es Momente im Azure Portal die zu verwunderten Gesichtern führen und in diesen Fällen helfen die „Developer tools“ von Chrome um Licht ins Dunkel zu bringen.

Weiterlesen →

Cloud Brothers

Work and live with IT

SCHANNEL Einstellungen des Azure Windows Marketplace image geändert

Report des Log Analytics Workspace für alle Azure VMs

Azure Log Analytics – RegEx Groß-Kleinschreibung ignorieren

AzureRM.Network 0.9 macht Probleme mit Azure Automation

Eine freie IP Adresse in Azure finden

PowerShell Modul Entwicklung: Pester Tests

AzureSimpleREST Module

Azure Availability Sets vNet Abhängigkeit

Proxy, Proxy an der Wand…

„Reverse engineering“ der Azure REST API