Die globalen Einstellungen betreffen die Admin-Oberfläche. Wir haben hier zuvor manuelle Parameter gesetzt für die TLS-Mindeststandards, wechseln nun jedoch auf den Strong-Crypto-Befehl. Das Verbot von RSA-Chiffren ist zwar implizit durch die anderen Parameter gegeben, wurde jedoch bei einem Audit als wünschenswert festgelegt und wird daher beibehalten. Ebenfalls werden mehrere Hash-Verfahren deaktiviert, um das unsichere AES-128-CBC abzuschalten. Wie in einem Technical Tip beschrieben, kann AES-128-CBC nicht selbst deaktiviert werden, weshalb ein Workaround über die Hash-Verfahren genutzt werden kann. Einen exklusiven Umstieg auf TLS 1.3, welches die unsicheren Chiffren nicht mehr unterstützt, haben wir auch diskutiert, jedoch noch nicht ins Auge gefasst.

config system global
    set strong-crypto enable
    set ssl-static-key-ciphers disable
    set admin-https-ssl-banned-cipher RSA SHA1 SHA256 SHA384
    set dh-params 8192
end

Wenn die starke Verschlüsselung (Strong-Crypto) aktiviert ist, sind nur noch TLS 1.2 und TLS 1.3 zulässig. Der Strong-Crypto-Befehl hat jedoch keine Auswirkung auf die SSL-VPN-Verschlüsselungsstufe oder -Chiffren. Für die SSL-VPN-Einstellungen setzen wir daher TLS 1.2 als Mindeststandard und verbieten die gleichen Chiffren wie zuvor. Über den Algorith-High-Befehl werden ebenfalls ältere und unsichere Chiffren verboten.

config vpn ssl setting
    set algorithm high
    set ssl-min-proto-ver tls1-2
    set banned-cipher RSA SHA1 SHA256 SHA384
end

Abschließend kontrollieren wir mithilfe von Qualys den neuen Status und führen einen erneuten Scan durch. Es ergibt sich nun eine Bewertung mit A+ mit voller Bewertung in drei Kategorien.

Quellen

• Technical Tip: Disable AES CBC ciphers for SSL VPN and Admin GUI (HTTPS) Access
• Technical Tip: Cipher suites offered by FortiGate
• Hardening | FortiGate / FortiOS 7.4.0 | Fortinet Document Library
• FortiGate encryption algorithm cipher suites | FortiGate / FortiOS 7.4.2 | Fortinet Document Library
• BSI-TR-02102.pdf (bund.de)

Der Beitrag Fortinet – Chiffren für SSL VPN und Admin GUI härten erschien zuerst auf Maximilian Krieg.

Monitoring-Schwellwerte

Dem Monitoring-Team stellen wir folgende Schwellwerte als Empfehlung für sämtliche LetsEncrypt-Zertifikate des Kunden, unabhängig davon welches System sie präsentiert oder verlängert, zur Verfügung:

• Warnung – Ab 28 bis 30 Tagen
• Fehler – Ab 5 bis 7 Tagen

Erst bei Eintreten des Fehlerzustands im Monitoring-System sollte ein Ticket erzeugt werden. 5 bis 7 Tage sollten genug Zeit sein den Prozess manuell zu starten oder in die Fehleranalyse zu gehen, warum der Automated Certificate Management Environment (ACME)-Client das Zertifikat nicht korrekt innerhalb des Standard-Intervalls erneuert hat. Standardmäßig hat ein LetsEncrypt-Zertifikat eine Laufzeit von 90 Tagen und erst ab 60 Tagen ist es eigentlich zum Renewal vorgesehen. Mehr Informationen hierzu findet man in der ACME Renewal Information (ARI).

Die oben genannte Werte sind bereits individuell angepasst auf die Konfiguration der Kunden-spezifischen Umgebung. Ebenfalls denkbar wären folgende, allgemeinen Schellwerte, wenn nur einmal am Tag eine Prüfung der Laufzeiten erfolgt:

• Warnung – Ab 30 Tagen
• Fehler – Ab 28 Tagen

Renewal-Prozess

Die FortiGate-Firewalls sehen im Standard vor, dass ein Zertifikat 30 Tage vor Ablauf den Renewal-Prozess initiieren.

config vpn certificate local
    edit <ACME_certificate_name>
        set acme-renew-window 30
    end

Über folgende Befehle kann man dann ein Zertifikat manuell, auch vor den 30 Tagen, erneuern.

ACME-Status prüfen:

get system acme status
get system acme acc-details

Zertifikate erneuern:

diagnose sys acme regenerate-client-config
diagnose sys acme restart

2-3 Minuten warten, danach neue Laufzeiten je Zertifikat kontrollieren:

get vpn certificate local details <Local certificate name>
diagnose sys acme status-full <Certificate’s CN domain>

Quellen

• Improving Resiliency and Reliability for Let’s Encrypt with ARI – Let’s Encrypt (letsencrypt.org)
• Troubleshooting Tip: Let’s Encrypt certificate did… – Fortinet Community
• draft-ietf-acme-ari-02 – Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension

Der Beitrag Fortinet – LetsEncrypt-Zertifikate manuell erneuern erschien zuerst auf Maximilian Krieg.

Symptom

Der SSL Server Test hat eine mittelmäßige Bewertung ergeben und weist darauf hin, dass mein Server noch die schwache RC4-Stromchiffre unterstützt und keine Unterstützung von Forward Secrecy für bestimmte Browser leistet (vgl. Abb. 1).

Die genauere Betrachtung der Auswertung wird hier nicht diskutiert. Viele der Einstellungen können jedoch zu ernsthaften Problemen im Zusammenhang mit neuartigen Angriffen führen.

Problem

Die Konfiguration des Webservers ist nicht auf dem aktuellen Stand.

Lösungsstrategie

Für meine Anpassungen habe ich mich an dem Artikel Stong SSL Security on lighttpd von Raymii.org (Link) orientiert. In diesem wird beschrieben, wie man zahlreiche Sicherheitseinstellungen korrigiert, um eine gute Bewertung zu erhalten.

Chiffren

Zunächst werden die Einstellungen in der Datei 10-ssl.conf angepasst.

# sudo vi /etc/lighttpd/conf-enabled/10-ssl.conf

In dieser Datei ergänze ich die folgenden Zeilen.

ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"

Forward Secrecy

Wir wechseln in das folgende Verzeichnis und generieren dort stärkere Diffie-Hellman-Parameter, d. h. eine ausreichend große Primzahl (Link).

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

Dann fügen wir in der Datei 10-ssl.conf weiterhin die folgenden Zeilen ein.

ssl.dh-file = "/etc/ssl/certs/dhparam.pem"
ssl.ec-curve = "secp384r1"

Bezüglich der Kurveneinstellung war ich zunächst etwas verwirrt, was es mit dieser Zeichenkette auf sich hat. Es handelt sich laut Bundesamtes für Sicherheit in der Informationstechnik (BSI) dabei um den Parameter einer Elliptischen Kurve, der als sicher bis zum Jahre 2021 gilt (Link).

Nachdem ich die Einstellungen gespeichert und den Server neugestartet habe, erhalte ich nun folgende Bewertung.

Mein Server ist somit vorerst wieder auf einem aktuellen Stand bezüglich seiner SSL-Konfiguration. Eine ausführliche Beschreibung aller Maßnahmen und Angriffe kann in dem Artikel auf Raymii.org nachgelesen werden.

Der Beitrag Starke SSL-Verschlüsselung mit Lighttpd erschien zuerst auf Maximilian Krieg.