Kategoriearchive: Windows Server/Client

IIS, Apache, Nginx: SSL Hardening angelehnt an FIPS 140-2

SSL Lock

Changelog

  • 13. Jan 2015 – Apache DH Parameter werden in SSLCertificateFile definiert

Abgesehen von der stetigen Implementierung von Sicherheitspatches in das System, gibt es immer wieder Kleinigkeiten zu beachten.
Ich entscheide mich zugegeben relativ spät für einen Artikel zum Thema SSL Hardening, der Aufschrei verklang in den letzten Wochen ja zunehmend, dennoch…
 
 

Handshakes mit SSL nach FIPS 140-2 mit Nginx
Abbildung 1: Handshakes mit SSL nach FIPS 140-2 mit Nginx
Ich richte mich bei der Konfiguration nach FIPS 140-2, so schließe ich etwa SSL bis einschließlich v3 und diverse Cipher wie RC4 aus. Kompatibilität bietet anstatt RC4 der Cipher CBC.
Trotzdem besteht eine Kompatibilität zu beinahe allen Browsern, die noch Verwendung finden. Der Ausreißer aus Abbildung 1 ist keine wirkliche Überraschung…
Für Linux gilt, dass OpenSSL zu diesem Zeitpunkt mindestens in Version 1.0.1c vorliegt (zu überprüfen mit „openssl version“).
Nginx sollte in jedem Repository bereits eine Version höher 1.0.6 erreicht haben („nginx -v“).
Ein Apache Web-Server muss ab Version 2.4.7 installiert sein („apache2 -v“).

Nginx

Zuerst für den Diffie Hellman Schlüsselaustausch über 2048bit folgende Datei erstellen:

Anschließend die Site-Konfiguration ändern:

Mit obiger Konfiguration überlässt der Besucher Nginx die Auswahl des Ciphers, die Auswahl erfolgt von stärkster Methode an absteigend. Timeout und Cache werden auf 10m reduziert.

IIS

Nach langem Zögern und Hadern entscheide ich mich für die GUI-Methode, werde dafür aber etwas genauer. Ich finde es schade, dass das kleine Tool in meiner Umgebung relativ lange verborgen blieb:

IIS Crypto, SSL Hardening
Abbildung 2: IIS Crypto
Für den IIS ab Windows Server 2003 (-2012 R2) empfehle ich das Tool IIS Crypto. Aber Vorsicht: Benutzer des Windows Servers in Version 2003, müssen sich vorab eines Patches bedienen, um überhaupt AES als Cipher verwenden zu könnnen. Weiterhin unterliegen sie der Einschränkung, die Cipher nicht manuell anordnen zu können.

Einigen dürfte der über die „Local Security Policy“ einstellbare Wert „System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing“ ein Begriff sein.
Die Funktion triggert den DWORD32 Eintrag „Enabled“ in „HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy“ auf 1. Eine hilfreiche Funktion, wenn wirklich das ganze Betriebssystem von der FIPS-Richtlinie profitieren soll. Allerdings ist der Modus sehr weitreichend und wird selbst von Microsoft nur bedingt empfohlen, da es zu einigen Einschränkungen kommt.

Der IIS Crypto liegt ebenso in einer Command Line Version vor, in beiden Fällen in .Net 2.0 sowie 4.0. Änderungen, die hiermit erzielt werden, können mit Software wie regshot eingefangen- und zu einem PowerShell-Script umgeschrieben werden. Das erwähnt, dürften auch die Scripter zufriedengestellt sein.

Apache2

Benutzer des Apache Web-Servers in Version 2, haben es je nach Konfiguration etwas schwieriger. Der vorhandene Schalter „SSLFIPS“ wird nur funktionieren, wenn Apache2 unter Verwendung einer FIPS SSL-Bibliothek gebaut wurde. Darauf verzichte ich jedoch und biete eine Konfiguration an, die ähnlich den obigen ist.
Zuerst für den Diffie Hellman Schlüsselaustausch über 2048bit folgende Datei erstellen:

Der Inhalt der Datei „/etc/apache2/dhparam.pem“ wird an das Ende des SSL-Zertifikates angehangen. Etwa:

Apache 2.4 extrahiert DH-Parameter wie auch alle Informationen zur Zertifikatskette aus einer Datei.

In der Datei „/etc/apache2/mods-enabled/ssl.conf“ (Ubuntu/Debian) ändere oder füge ich Folgendes hinzu:

Anmerkungen

Ein Hinweis zum Zertifikat der Certification Authority (CA): Einige Benutzer neigen dazu, die Zertifikate zu vereinen. Etwa das öffentliche Zertifikat der CA und das privat ausgestellte Zertifikat, wie auch in meiner eigenen Konfiguration.
SSL Test-Anwendungen wie „ssllabs.com“ weisen auf den untypischen Zustand hin, einen Einfluss auf die Sicherheit hat es jedoch nicht. Es ensteht unwesentlich mehr Netzwerkverkehr, wohl etwa 1kB.

Abschließend lässt sich noch sagen, dass es sich bei den Empfehlungen – wenn man es denn so nennen kann -, die ich in diesem Artikel beschreibe, nicht um absolut FIPS 140-2 konforme Einstellungen handelt. Aber wer würde sich bei sowas auch auf einen Blog verlassen…
Jedoch resultiert eine sichere Konfiguration, die weit enfernt von paranoid und somit hoch-kompatibel bleibt.

Workaround für Event ID: 41029 – Es besteht keine Verbindung mit Lync Web App

Changelog

  • 11. Juli 2014 – Falscher Port, gefixt.

Das Problem, das sich hier aufzeigt, ist Folgendes:
Auf jedem konfigurierten Lync Front-End 2013 Server, wird der Data MCU alle 30 Minuten versuchen, die „Lync Web App Reach URL“ der externen Web-Dienste zu triggern.
Die Verwendung des FQDN steht hierbei im Widerspruch zum hinterlegten externen Zertifikat des Dienstes.
Außer der Methode, den FQDN dem externen Zertifikat hinzuzufügen, beschreibe ich daher folgendes Workaround via Aufgabenplanung und PowerShell Script.

Das Script triggert den Aufruf der URL, ignoriert hierbei den – logischerweise – fehlenden Namen im Zertifikat und startet den Dienst erfolgreich.
Einmal gestartet, bleibt der Dienst aktiv, weshalb der Aufruf des Scripts nach dem Bootvorgang ausreichend ist.

Fehlerbeschreibung aus eventvwr.msc: Event ID 41029, LS Data MCU:

Es besteht keine Verbindung mit Lync Web App. Betroffene Webbrowserclients können die Webkonferenzmodalität nicht verwenden.

FQDN des Servercomputers: fqdn-frontend.domain.local, Port: 8061
Servertyp: External-WebApp-Edge [HTTP side error:Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden..]
Wenn das Problem fortbesteht, wird dieses Ereignis nach 20 Minuten erneut protokolliert
Ursache: Möglicherweise ist der Dienst nicht verfügbar, oder die Netzwerkkonnektivität wurde unterbrochen.

Nach Ausführung des Scripts:

Die Verbindung mit Lync Web App wurde erfolgreich hergestellt.

FQDN des Servercomputers: fqdn-frontend.domain.local, Port: 8061
Servertyp: External-WebApp-Edge

Das Script

Selbstverständlich ist der Servername noch abzuändern.

Der Aufruf in der Aufgabenplanung, wobei das Script in „c:\lync_scripts“ unter dem Namen „trigger_reach.ps1“ abgelegt ist:

PowerShell: Script mit administrativen Rechten ausführen

PowerShell Icon (c)

PowerShell bietet seinen Benutzern keine Funktion, eine Privilegienerweiterung durchzuführen.
Als Workaround dient eine Routine, welche als Kopfzeile eingebunden, das gesamte darauf folgende Script in einer neuen PowerShell Instanz mit administrativen Rechten ausführt:

Sind die gewünschten Rechte bereits gegeben, öffnet sich keine neue Instanz.

Powershell: 7-Zip installieren und Dateizuordnungen setzen

PowerShell Icon (c)

Das Script beginnt mit einer Funktion, die – falls nicht gegeben – administrative Rechte einfordert, um die Software korrekt installieren zu können und ebenso die Dateizuordnungen einzurichten.

Abzuspeichern etwa als „7zip.ps1“ an beliebigem Ort.

Zur Ausführung genügt ein Rechtsklick auf die Datei mit anschließender Auswahl „Mit PowerShell ausühren“ bzw. „Run with PowerShell“:

Windows Domäne: Offline-Join mit DirectAccess Policy

Üblicherweise baue ich eine SSTP-Verbindung von einem Windows-Client zu einem Windows-Server auf, um anschließend der Domäne beizutreten. Das ist aber gerade im Bezug auf DirectAccess nicht die schönste Möglichkeit und erfordert weiterhin nach dem Beitritt in die Domäne, dass nach einem Neustart mit dem lokalen Administrator wieder das VPN aufgebaut- und anschließend der Benutzer gewechselt wird, um die erste Anmeldung durchzuführen.
Schöner und eigentlich auch sehr einfach ist es, den Client offline in die Domäne beitreten zu lassen. Ein einfacher Befehl auf dem Domänen-Controller ist hierfür ausreichend. Die Gruppenrichtlinie für DirectAccess unterscheidet sich im Namen je nach Installationssprache des Servers.

Zwei Parameter des Befehls sind zu ändern:
– „domain.local“ muss dem Domänennamen entsprechen
– „computername“ entspricht dem Computernamen des Clients

Der Computername des Clients wird vorab entsprechend der eigenen Richtlinien zur Benennung geändert.

Nun der Befehl, welcher auf dem Windows-Server ausgeführt wird.

Für die englische Windows-Server Installation:

Für die deutsche Windows-Server Installation:

Wie im Befehl zu sehen, wird eine Datei „c:\outjoin.txt“ erstellt, die nun auf den Windows-Client kopiert wird. Für den Transport der Datei auf den Client, wähle ich die FTP-Übertragung. Jede Übertragung ist denkbar.

Ist die Datei auf dem Client angekommen, gilt folgender Befehl unabhängig von der Sprache der Installation.
Im seltensten Fall wird „C:\Windows“ als Windows-Pfad anzupassen sein.
Auch hier gehe ich davon aus, dass die Datei via „c:\outjoin.txt“ auf dem Client zu finden ist:

der Befehl wird in einer Konsole („cmd“) als Administrator ausgeführt.

Nach einem Neustart des Clients, erfolgt die Anmeldung als gültiger Benutzer mit Rechten zum DirectAccess-Gebrauch.