Ist diese IP Adresse Teil des Office 365 Adressbereiches?

Bei der Analyse von Firewall Logs in Office 365 Projekten kommt es immer wieder zu der Fragestellung: Ist diese geblockte IP Adresse Teil des Office 365 Adressbereichs?

Dank PowerShell und der von Microsoft veröffentlichten Information im JSON Format ist die Antwort nur ein paar Zeilen Code entfernt.

Damit ihr das Rad nicht neu erfinden müsst teile ich hier mein Skript „Test-IsO365IpAddress.ps1“. Dem Skript wird einfach die fragliche IP Adresse und optional der TCP/UDP Port übergeben. Es lädt die aktuelle Liste der Adressbereiche von Microsoft und prüft ob die IP Adresse Teil eines der dort enthaltenen IP Netze ist. Ist dies der Fall werden alle Service die dieses Netz nutzen ausgegeben.

Wurde ein Port mit angegeben wird dies bei der Ausgabe der Service berücksichtigt.

Neben dem Service Namen (z.B. „Exchange Online“) wird auch die Kategorie (Optimize, Allow oder Default), die benötigten Ports, das Subnetz und die etwas veraltete Eingruppierung „Required“ ausgegeben.

Mit diesen Daten ausgestattet sollte der Besuch beim Firewall Team erfolgreich sein.

Vielen Dank auch Luben Kirov dessen Netzwerkfunktionen ich für die schnelle Analyse der IP Netze nutzen durfte und Siva Padisetty dessen Funktion checkSubnet ich als Insperation für meine Implementierung genutzt habe.

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.

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.

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 →

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 →