Autoren-Archiv: weed

Um neue VPN-Verbindungen auf mehrere Computer zu verteilen und in den Verbindungseigenschaften Optionen zu setzen gibt es ganz brauchbare PowerShell-Tools.

Die Parameter von Add-VPNConnection und Set-VPNConnection sind glücklicherweise auch praktisch identisch, so daß man entweder eine neue Verbindung erstellen oder eine vorhandene Verbindung bearbeiten kann.

Erstellt eine (SSTP-) VPN-Verbindung an der PowerShell:

Add-VpnConnection -Name "VPNNAME" -ServerAddress VPN.EXAMPLE.COM -RememberCredential:$false -SplitTunneling:$true -DnsSuffix EXAMPLE.LOCAL -AuthenticationMethod MsChapv2 -TunnelType SSTP -DestinationPrefix 10.42.42.0/24

Add-VpnConnection Parameter im einzelnen

• -Name "VPNNAME" Name der Verbindung
• -ServerAddress VPN.EXAMPLE.COM Adresse/URL des VPN-Servers
• -RememberCredential:$false Sollen die Anmeldeinformationen gespeichert werden? In diesem Fall wollen wir das verhindern, damit eine eingesetze 2FA-Lösung die die Eingabe eines OTP Codes bei jeder Einwahl erzwingt funktioniert.
• -SplitTunneling:$true Sollen VPN-Traffic und sonstiger Internet-Traffic getrennt werden? Spannend zum Beispiel für Netzwerkdrucker im HomeOffice.
• -DnsSuffix EXAMPLE.LOCAL Setzt den DNS-Suffix auf die remote-Domäne. Nicht notwendig wenn man ausschliesslich ordentliche FQDNs für interne Ressourcen nutzt.
• -AuthenticationMethod MsChapv2 setzt die Authentifizierungsmethode. Die meisten 2FA-Lösungen müssen den Benutzernamen „sehen“, was via EAP ausschliesst.
• -TunnelType SSTP Verbindungstyp des Tunnels, hier SSTP.
• -DestinationPrefix 10.42.42.0/24 Sorgt für weitere Routen zu erreichbaren Netzen, wenn SplitTunneling $true ist

Ü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)