Apache: SSL höhere Verschlüsselungssicherheit

Apache: SSL höhere Verschlüsselungssicherheit

Wer die Verschlüsselungssicherheit erhöhren möchte und dabei auf Kompatibilität mit alten Anwendungen verzichten möchte, der kann die folgende Konfiguration vornehmen:

Aktivieren des Apache2 Moduls Headers mit (in einer Shell mit root-rechten oder mit sudo):

sudo a2enmod headers 

Danach die ssl.conf (z.B. unter Debian unter /etc/apache2/mods-aviable) anpassen um die folgenden Zeilen bzw. existierende entsprechend anpassen:

SSLCipherSuite  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256:EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
SSLSessionTickets Off

Anschließend mit root-rechten die Konfiguration prüfen:

apachectl -t

Und dann Apache neustarten:

apachectl restart

Anschließend könnt ihr mit SSL Testingsites (z.b. https://www.ssllabs.com/ssltest/) die Konfiguration prüfen.

Weitere Links:

Tipp: Mit dem Editor Nano können sie über eine SSH Shell Copy & Paste nuzten.

Windows Server könnt ihr mit dem Tool IISCrypto.exe sichern – zu finden hier: https://www.nartac.com/Products/IISCrypto


Windows/IIS: TLS absichern

Bei der Prüfung eines alten Windows 2008 R2 Servers mit Greenbone Security Assistent wurden mir mehrere Probleme ausgegeben, da der Windows Server 2008 R2 einige Optionen nutzt, die als nicht mehr sicher gelten.

Diese kann man per Registry de- bzw. aktivieren, was jedoch sehr unkomfortabel ist. Einfacher geht es mit dem IIS Crypto Tool 2.0 – dies bietet alle Optionen an und dies sogar noch mit komfortablen Templates.

Die Sicherheit kann man anschließend mit dem SSL Lab Test verifizieren.

Benötigt man ein Offline Tool, da der Server nicht von extern erreichbar ist, kann man ein Tool von Github nutzen, welches auch für Windows existiert.

Anschließend noch SMTP mit TLS testen.

In größeren Umgebungen (hier in dem Beispiel zwei Exchange Server die über Windows Clusterdienste NLB für CAS und Hubtransport zur Verfügung stellen) sollte man behutsam umgehen, ich bin wie folgt vorgegangen:

  • Entfernen EXCHANGE1 aus dem NLB (ca. 5 Sekunden unterbrechung, evtl. kommt kurz bei Clients das Anmeldefenster – wenn zuvor auf dem EXCHANGE1 verbunden gewesen)
  • Warten bis die Warteschlange geleert wurde und kontrollieren, das diese nicht mehr füllt
  • Erstellen Snapshot, falls was schief laufen sollte
  • Erstellen Security-Übersicht
  • Anpassen der Security
  • Kontrolle der Security-Einstellungen
  • Einbinden wieder in den NLB
  • Anpassen der Security-Einstellungen wie auf EXCHANGE1 auf dem EXCHANGE2
  • Testen von Extern mit ausgiebigem Sicherheits-Bericht
  • Besprechen ob Einstellungen anwendbar
  • Testen mit Penetrationstool
  • Wenn alles sauber funktioniert, bereinigen der Snapshots

Quellen:

 


Exchange: TLS Testen

Ein Exchangeserver verwendet wenn möglich TLS (muss auf dem Sende- und Empfangsconnector eingerichtet sein).

Möchte man gerne die Verbindungen kontrollieren, dann kann man OpenSSL installieren und mit dem folgenden Befehl die Verbindung kontrollieren:

openssl s_client -connect remote.leibling.de:25 -starttls smtp

outlook.com bzw. Office365 Server whitelisten

Ich hatte das Problem bei einem Kunden, das dieser keine Emails von Empfängern erhalten konnten, die outlook.com bzw. Office 365 nutzten.

Laut mxtoolbox.com war jedoch alles ok.

In den Logs der Sophos fand ich jedoch folgende Zeilen:

2015:08:12-22:37:59 gateway exim-in[16769]: 2015-08-12 22:37:59 TLS error on connection from mail-db3on0121.outbound.protection.outlook.com (emea01-db3-obe.outbound.protection.outlook.com) [157.55.234.121]:2048 (SSL_accept): error:00000000:lib(0):func(0):reason(0)
2015:08:12-22:37:59 gateway exim-in[16769]: 2015-08-12 22:37:59 TLS client disconnected cleanly (rejected our certificate?)
2015:08:12-22:37:59 gateway exim-in[16769]: 2015-08-12 22:37:59 SMTP connection from mail-db3on0121.outbound.protection.outlook.com (emea01-db3-obe.outbound.protection.outlook.com) [157.55.234.121]:2048 closed by EOF

Nachdem ich das TLS Zertifikat der Firewall noch mal ausgetauscht hatte, funktionierte die Kommunikation einwandfrei:

2015:08:14-13:27:03 gateway exim-out[23820]: 2015-08-14 13:27:03 1ZQD8W-0006C6-Ip => absender@url.com P=<empfaenger@ulr.org> R=dnslookup T=remote_smtp H=xxxx.mail.protection.outlook.com [213.199.04.0]:25 X=TLSv1.2:ECDHE-RSA-AES256-SHA384:256 C="250 2.6.0 <9101E7B53B7D6E40AF7D0311DBxxxxxxxx@server> [InternalId=126186139xxxx"
2015:08:14-13:27:03 gateway exim-out[23820]: 2015-08-14 13:27:03 1ZQD8W-0006C6-Ip Completed

Dennoch habe ich die Mailserver von Outlook.com whitegelistet (zumindest bezüglich der Kommunikation, nicht in der inhaltlichen Prüfung bezüglich Spam oder Viren).

Die Adressen findet man hier: https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx

 


Exchange 2010/SBS 2011: Relay über TLS/SSL (z.B. 1und1)

Da viele Mailserver nur noch per TLS/SSL Mails entgegenehmen, muss man dies im Exchange Verwaltungsconsole im Sendeconnector einstellen (Exchange > Microsoft Exchange lokal > Organisationskofniguration > Sendekonnektor > Sendekonnektor doppelklick > Register Netzwerk > Email über Smarthost senden > Ändern > Hacken bei Standardauthentifizierung über TLS senden).

Weiterhin muss man dann in der Verwaltungsshell noch folgenden Befehl eingeben:

Set-SendConnector –Identity “Windows SBS Internet Send SERVERNAME” -Port 587