Log4j Zugriffe (Exploits) zuverlässig mit IIS ARR (reverse Proxy) filtern

Über eine kritische Sicherheitslücke namens „Log4Shell“ in der weitverbreiteten Java-Logging-Bibliothek „Log4j“ können Angreifer beliebigen Code ausführen lassen.

Seit Kurzem steht ein Quellcode-Update des Log4j Apache-Projekts bereit; Entwickler und Admins sollten dringend aktiv werden.

Ein Angreifer kann die Sicherheitslücke ausnutzen, indem er manipulierte Anfragen an einen verwundbaren Server oder eine angreifbare Anwendung schickt. Das geschieht in der Regel (z.B. Tomcat) via USER_AGENT logging. ein Internet-Nutzer kann also Code hinterlegen, den der Server dann ausführt. Die log4j-Lücke greift aber nicht nur beim USER_AGENT, sondern bei *allem* was im Log landen kann. Je nach Applikation muss man hier also genauer hinschauen, das Vorgehen im IIS URLrewrite ist aber immer das selbe und funktioniert dafür sehr gut.

Den Versuch dazu kann man in ISS via ARR aber schnell filtern. Hier die Anleitung um mittels Reverse Proxy das Exploit abzufangen bevor es interne Systeme erreicht.

Lösung

Am besten auf höchster Ebene (link auf dem Serverknoten) das Modul „URL rewrite“ öffnen. Die dort erstelle Regel greift auf allen Sites.

An dieser Stelle eine leere Regel einfügen, die die folgenden Einstellungen hat:

  • Übereinstimmung mi URL: .*
  • Groß/Kleinschreibung ignorieren: Angehakt
  • Bedingungen
    • Übereistimmung mit allen Elementen > hinzufügen
    • Bedingungseingabe: {HTTP_USER_AGENT}
    • Muster: .*jndi:ldap*
  • Aktion (hier ist etwas kreative Freiheit möglich)
    • URL Umleiten: http://endless.horse/
    • Dauerhaft (301)

Fritz!Box Kennwort auslesen und entschlüsseln (ohne PHP)

Für AVM Fritz!Boxen gibt es wieder einen klaren Fall von „Notiz an uns selbst“. Ab und zu geht ja schonmal das DSL-Zugangskennwort für das Internet verlorern. Soll der Internet-Roter ausgetauscht werden, fängt man an zu suchen.

Der schnelle Admin kann hier natürlich einfach ein Backup der Konfiguration erstellen (System > Sicherung > Sichern), aber selbiges ist unleserlich verschlüsselt. Und selbst wenn man die *.export Datei entschlüsselt hat, stehen da die Kennwörter noch immer verschlüsselt drin. Grundsätzlich ist das natürlich eine gute Sache, für den Admin aber manchmal hinderlich.

Glücklicherweise kann man *.export Dateien ohne weitere Software direkt online entschlüsseln lassen:

https://fbedit.com

Microsoft 365 Kennwort sofort ablaufen lassen (Änderung des Kennwortes erzwingen)

Manchmal möchte man ein bestimmtes Office 365 Konto schnell geändert wissen. Möglicherweise weil das Kennwort auf einem Zettel unter der Tastatur aufgetaucht ist oder ein Gerät verschwunden ist. Es wäre toll, wenn man den Benutzer schnell zur Änderung zwingen könnte.

Leider gibt Microsoft dem Administrator dafür kein GUI-Werkzeug in die Hand. Man kann in der Oberfläche das Kennwort zwar gewaltsam „zurücksetzen“, aber leider nicht als „abgelaufen“ markieren. Eine Kennwortablaufrichtline gibt es nur Unternehmensweis und nur in Tagen.

Lösung

An der PowerShell ist das natürlich möglich. Man muss dazu das MSOnline Modul in seiner PowerShell aktive haben (import-module MSOnline) und mit dem Microsoft-Tenant verbunden sein (Connect-MsolService).

Erzwingt die sofortige Änderung

Set-MsolUserPassword -UserPrincipalName "[email protected]" -ForceChangePassword $true -ForceChangePasswordOnly $true

⚠ Die Dokumentation des Commandlets „Set-MsolUserPassword“ ist leider unvollständig.

  • ForceChangePassword $true erzwingt das der Benutzer bei der nächsten Anmeldung sein Kennwort ändert
  • ForceChangePasswordOnly $true sorgt dafür, das kein neues Kennwort automatisch vergeben wird

Man kann natürlich auch an der Kommandozeile ein neues Kennwort vorgeben:

Set-MsolUserPassword -UserPrincipalName "[email protected]" -NewPassword "GEHE1MK3NNW0RT"

Oder von der Powershell ein neues Kennwort generieren und setzen lassen:

Set-MsolUserPassword -UserPrincipalName "[email protected]" -ForceChangePassword

Erzwingt die Änderung des Kennwortes nach Datum

Man kann in Set-MsolUserPassword auch beliebige Selektionen hinein-pipen. Das vereinfacht beispielweise die Vorgabe nach einem bestimmten Datum (hier der 24. Juli 2021) oder nach Alter.

Get-MsolUser | where LastPasswordChangeTimestamp -lt (Get-Date 24.07.2021) | Set-MsolUserPassword -ForceChangePassword $true -ForceChangePasswordOnly $true

Hinweis: „Sonderfall“ Outlook

Nachdem man für den nächsten Login eine Passwortänderung „erzwungen“ hat, funktioniert nun allerdings noch das bestehende Passwort und vor Allem Outlook kann wunderbar mit einem bestehenden Session-Token weiterarbeiten (auch mehrere Wochen lang).

Um im Outlook einen neuen Login zu erzwingen, muss man das Session-Token revoken. Das geht ebenfalls per PowerShell, benötigt aber das AzureAD Modul (😑):

Get-AzureADUser -SearchString "[email protected]" | Revoke-AzureADUserAllRefreshToken

Oder für die selben Benutzer wie oben (nach letztem Änderungsdatum):

Get-MsolUser | where LastPasswordChangeTimestamp -lt (Get-Date 24.07.2021) | foreach {Get-AzureADUser -SearchString $_.UserPrincipalName} | Revoke-AzureADUserAllRefreshToken

Tastenkombinationen und Zugriffstasten wieder unterstreichen

Microsoft hat in Windows 11 die unterstrichenen Tastenkürzen für die Menüauswahl standartmäßig abgeschaltet. Das erschwert die Tastaturbedienung und macht diese schnelle Methode für direkte Zugriff für neue Admins leider praktisch unsichtbar.

Vorher – Nachher: Der Schnellzugriff fehlt

Lösung

Zum Glück ist die Anzeige der Unterstreichung nur eine Einstellungssache:

Windows Einstellungen -> Barrierefreiheit -> Tastatur -> „Tastenkombinationen Unterstreichen“

Alternativ: Klassische Systemsteuerung > Alle Systemsteuerungselemente > „Center für erleichterte Bedienung“ > „Bedienung der Tastatur erleichtern“ > „Tastenkombinationen und Zugriffstatsten unterstreichen“

WSUS Performance timeout abschalten, Datenbank-Reindexierung starten, Löschen und manuelles bearbeiten

Der WSUS unter Windows Server 2012/2012R2 und 2016 zeigt ab und zu gewisse Performance-Schwächen. Das äußert sich beispielsweise in dem berüchtigten „Serverknoten zurücksetzen“ Fehler oder dem „Fehler bei der Verbindung zur WSUS-Datenbank“ Anzeige.

Lösung

Der WSUS-Server ist tatsächlich ein Performance-Fresser. die Update-Datenbank ist riesig. Nicht immer ist hier die WID (Windows-Interne Datenbank) die richtie Lösung. Wartungsscripts und Neuindexierungsjob gibt es hier leider nicht.

Tipp 1 – WSUS-Datenbank defragmentieren und neuindexieren

  1. WSUSDBMaintenance Scripts herunterladen (nicht auf die Version achten – läuft auch unter WSUS 4)
  2. Microsoft® Command Line Utilities 11 for SQL Server herunterladen und installieren (oder alternativ das SMSS verwenden)
  3. Die Scripts ausführen:
    sqlcmd -E -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i WsusDBMaintenance.sql

Tipp 2 – Cleanup-Agent laufen lassen

Der WSUS „Assistent für die Serverbereinigung“ kann die Datenbank deutlich entschlacken (und für mehr Platz sorgen). Läuft der Assistent nicht durch, hilft oft dieser Artikel.

Tipp 3 – Mehr Leistung

Ein WSUS mit vier Kernen und 8Gb RAM kann etwa 5000 Clients gut und schnell bedienen. viele WSUS-Maschinen haben aber deutlich weniger Ressourcen; eine leichte Aufstockung kann hier wunder bewirken.

Tipp 4 – Abgelaufene oder ersetzte Updates löschen

Der Fehler in diesem Artikel kann auch die Ursache für Verbindungstimeouts des Konsolenclients sein.

Dieses SQL-Script löscht die Updates direkt in der Datenbank, ohne einen externen Binärassistenten. Alle diese Updates auf einmal, ohne manuelles suchen.

DECLARE @var1 INT 
DECLARE @msg nvarchar(100) 
CREATE TABLE #results (Col1 INT) INSERT INTO #results(Col1) 
EXEC spGetObsoleteUpdatesToCleanup 
DECLARE WC Cursor FOR SELECT Col1 FROM #results 
OPEN WC 
FETCH NEXT FROM WC INTO @var1 WHILE (@@FETCH_STATUS > -1) 
BEGIN SET @msg = 'Deleting ' + CONVERT(varchar(10), @var1) RAISERROR(@msg,0,1) WITH NOWAIT 
EXEC spDeleteUpdate @localUpdateID=@var1 
FETCH NEXT FROM WC INTO @var1 
END 
CLOSE WC 
DEALLOCATE WC 
DROP TABLE #results

Tipp 5 – SQL-Server Timeout für die WID/SUSDB hochsetzen/abschalten

Die meisten Konsolenaktionen laufen fehlerfrei durch, wenn man das SQL-Timout für querys entweder sehr hoch ansetzt, oder gleich ganz abschaltet. Achtung: Wenn man das Timeout abschaltet, laufen auch „tote“ Anfragen durch, bis sie fertig sind. Default sind 600 Sekunden.

USE SUSDB;  
GO  
EXEC sp_configure 'remote query timeout', 0 ;  
GO  
RECONFIGURE ;  
GO

Tipp 6 – IIS Prozess-Pool Timeout für die WSUS-Prozesse erhöhen

Ein sehr nerviger Fehler taucht im WSUS ab Windowss Server 2016 auf: „WSUS Verbindungsfehler – Serverknoten zurücksetzen

IIS (Internetinformationsdienste) Konsole öffnen > Anwendungspools > WsusPool > „Erweiterten Einstellungen“ des Anwendungspools öffnen -> „Limit für den privaten Speicher“ auf „0“ setzen und Server neustarten. Der Reboot ist notwendig, ein Nuestart der IIS alleine reicht nicht.