HMAILER auf SSL umstellen – Port 587

HMAILER Kommunikation verschlüsseln

In diesem Dokument beschreibe ich Step by Step die Umstellung des HMAILERS auf SSL/TLS.

Das Zertifikat (Keypair) trennen wir. Wir brauchen einmal den Public-Key sowie den Private-Key. Am besten mit openSSL.

HMAILER SSL Zertifikat

Exportieren den Private-Key:
openssl pkcs12 -in hmailer.pfx -nocerts -out key.pem

Exportieren den Public-Key:
openssl pkcs12 -in hmailer.pfx -clcerts -nokeys -out hmailer.pem

Entfernen das Passwort vom Private-Key:
openssl rsa -in key.pem -out hmailer_no_pw.key

Kopieren die beiden Schlüssel in das Installationsverzeichnis und setzen die Konfiguration wie folgt um.

hMailer auf SSL umstellen

HMAILER Outlook TLS

HMAILER auf SSL umstellen – Port 587

Remote Desktop Verbindung RDP mit Zertifikat Identitätsprüfung


Active Directory Backdoor – Man-in-the-Middle

Ein Hintertürchen einbauen

Man kann heute nicht vorsichtig genug sein. Zu allererst möchte ich sagen, dass man die Anzahl an Domain-Admins bzw. privilegierten Konten so gering halten sollte wie nur möglich. Auch die delegierten Berechtigungen sollte man immer im Blick haben.

In diesem Beispiel haben wir einen Mitarbeiter namens ADBackdoor alias Max Musterdumm. Aktuell ist er noch Domänen-Admin. Aufgrund eines Vorfalls, werden ihm in Kürze alle Privilegien entzogen und das weiß er auch.

Weil er ein schlechter Mensch ist, das kann jetzt jeder interpretieren wie er will, baut er sich ein Hintertürchen ein.

Hiding in the shadows at Members attribute

Active Directory Backdoor – Man-in-the-Middle

Protected Users Group


Protected Users

Protected Users Group

Sicherheitsgruppe “Geschützte Benutzer”

Die Gruppe „Protected Users“ oder „Geschützte Benutzer“ hat ihre Zweckmäßigkeit seit Windows Server 2016 darin gefunden, enthaltene Benutzer zu schützen.

Und zwar werden die Konten, die dieser Gruppe angehören dahingehend eingeschränkt, das folgende Merkmale nicht mehr zur Verfügung stehen oder angepasst werden:

  • Verwenden von zwischengespeicherten Anmeldungen, also keine Langzeitschlüssel mehr. Es folgt ab jetzt pro Anforderung ein Authentifizierungsvorgang
  •  Verwendung von NTLM, Digest-Auth und CredSSP
  •  Verwenden schwacher *Verschlüsselungsalgorithmen wie DES und RC4 für die Kerberos Pre-Authentication
  •  Verwendung von Kerberos Constrained und Unconstrained Delegation
  •  Gültigkeit des Kerberos Ticket Granting Ticket (TGT) nicht länger als 240 Minuten

Für die ersten 3 Punkte haben die meisten bereits Gruppenrichtlinien im Einsatz, um die Merkmale einzuschränken. Gehört in jedes Hardening.

Gerne würde ich die Einschränkung zu Punkt 5 noch etwas besser darstellen wollen.

Protected Users Group

Active Directory Backdoor – Man-in-the-Middle


Export-PFXCertificate -ProtectTo

Alle Zertifikate einer Maschine exportieren und schützen

Wir haben beim Exportieren von Zertifikaten die Möglichkeit diese mit einem Schutz zu versehen. Ich spreche nicht von der Eingabe eins Kennworts, sondern durch den Hash eines Benutzers oder Systems.

Der Parameter nennet sich -ProtectTo

Für das Exportieren und dem automatischen Import setzen wir die PowerShell ein.

Mit diesem Skript erstelle ich ein Backup der Zertifikate aus dem lokalen Speicher und als Kernwortschutz nutze ich den Hashwert der Maschine. Die gesicherten Zertifikate lassen sich jetzt nur noch über den Maschinenkontext importieren.

Export-PFXCertificate -ProtectTo

Zertifikate importieren und exportieren mit der Powershell


KDC_ERR_PREAUTH_REQUIRED Event-ID 3

KDC_ERR_PREAUTH_REQUIRED

Was bedeutet diese Fehlermeldung „KDC_ERR_PREAUTH_REQUIRED“?
Der KDC erwartet grundsätzlich das sich alle Konten vorauthentifizieren (Pre-Authentication oder Präauthentifizierung).

*Der Authentifizierungsserver setzt die Pre-Authentication ein, um sicherzustellen, dass der Principal (Benutzer oder System) der ist für den er sich ausgibt. Außerdem soll damit der Verschlüsselungstyp ausgelotet werden.

(Warum soll der AS die Tür öffnen, wenn sich jemand mit der Klingel vertan hat) 😉

Dieser Mechanismus dient als Schutz vor böswilligen Angreifern, wobei im Verlauf (AS-Request) der Zeitstempel mit dem Benutzer-Password-Hash (LTK) verschlüsselt wird. Der KDC empfängt den Request, entschlüsselt diesen mit Benutzer-Password-Hash, und prüft daraufhin zuerst den Zeitstempel. Ist der Zeitstempel valide verarbeitet er den aktuellen Request mit weiteren Prüfmechanismen (Authenticator/Replay-Attacken) und sendet erst jetzt das TGT.
(Erst gucken wer da ist, bevor man auf macht)

Im Active Directory ist diese Option auch standardmäßig auf allen Konten aktiviert, so dass eine Pre-Authentication stattfinden könnte/sollte.

Wenn auf der einen Seite etwas erwartet wird und auf der anderen Seite nicht geliefert wird/werden kann, so löst diese Aktion ein Event-ID 3 “KDC_ERR_PREAUTH_REQUIRED” 0x19 aus.

Bei Problemen kann sollte aber bitte nicht, die Pre-Authentication deaktiviert werden. Das erhöht zwar zum einen die Kompatibilität für diverse Authentifizierungsvorgänge (DES/3DES/AES) aber es wird auch kein Event mehr dazu geschrieben.

*Die Pre-Authentication läuft zwischen Schritt 1 und 2 des Diagramms.

KDC_ERR_PREAUTH_REQUIRED

KDC_ERR_PREAUTH_REQUIRED

Erweiterte Sicherheit beim Anmeldeprozess – Security Advisory 2871997


Windows Defender-Anwendungssteuerung

Virtual Secure Mode und Device Guard

Ihre Organisation hat diese App mithilfe der Windows Defender-Anwendungssteuerung blockiert.

Das jetzt nicht mehr neue Sicherheitskonzept von Microsoft namens Device Guard läuft ab Windows 10 Enterprise und Server 2016.

Mit dieser Technik können Hardware- und Softwarefeatures so eingesetzt, das z.B. nur vertrauenswürdige Anwendungen ausgeführt werden können.

Device Guard setzt isolierten Umgebungen (Container) ein, um Anwendungen auszuführen und voneinander zu trennen. Als Basis für die Umsetzung dient der Hypervisor von Microsoft.

Virtual Secure Mode und Device Guard

Hardwarevoraussetzungen:

  • UEFI ab v2.3.1 im einheitlichen Modus
  • Windows 64-Bit
  • Second Layer Address Translation SLAT
  • Virtualisierungserweiterung z.B. Intel VT oder AMD-V
  • Trusted Platform Modul TPM

Für die Nutzung von Device Guard muss zuerst der Virtual Secure Mode aktiviert werden. Der VSM ist eine Funktion der die Virtualisierungserweiterung des Prozessors einsetzt, um so die Sicherheit zu erhöhen. Geschützt werden dabei unteranderem die Daten im Speicher und es wird sichergestellt, dass jede Instanz nur auf die eigenen Daten zugreifen kann.

Auch der Credential Guard benötigt für die Ausführung den Virtual Secure Mode, aber der ist heute nicht mein Thema.

Virtual Secure Mode und Device Guard

Hyper-V Nested VMs

https://www.der-windows-papst.de/category/security/