☰

So beheben Sie die „Logjam“-Sicherheitslücke in Apache (httpd)

tag-icon • tag-icon apache-2.2 ssl apache-2.4 httpd vulnerability
So beheben Sie die „Logjam“-Sicherheitslücke in Apache (httpd)

Kürzlich wurde eine neue Schwachstelle in Diffie-Hellman, informell als "Logjam" bezeichnet, veröffentlicht, für diediese Seitewurde zusammengestellt, wie dieser Schwachstelle begegnet werden kann:

Für die korrekte Bereitstellung von Diffie-Hellman für TLS haben wir drei Empfehlungen:

  1. Deaktivieren Sie den Export von Cipher Suites.Obwohl moderne Browser Export-Suiten nicht mehr unterstützen, können Man-in-the-Middle-Angreifer mit den FREAK- und Logjam-Angriffen Browser dazu bringen, Kryptografie auf Exportniveau zu verwenden, woraufhin die TLS-Verbindung entschlüsselt werden kann. Export-Chiffren sind ein Überbleibsel einer Richtlinie aus den 1990er-Jahren, die den Export starker kryptografischer Protokolle aus den USA verhinderte. Kein moderner Client ist auf Export-Suiten angewiesen und es gibt kaum Nachteile, sie zu deaktivieren.
  2. Setzen Sie (flüchtiges) Elliptic-Curve Diffie-Hellman (ECDHE) ein.Der Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch (ECDH) vermeidet alle bekannten möglichen kryptanalytischen Angriffe, und moderne Webbrowser bevorzugen mittlerweile ECDHE gegenüber dem ursprünglichen, endlichen Feld Diffie-Hellman. Die diskreten Log-Algorithmen, die wir zum Angriff auf Standard-Diffie-Hellman-Gruppen verwendet haben, profitieren nicht so stark von der Vorabberechnung, und einzelne Server müssen keine einzigartigen elliptischen Kurven generieren.
  3. Generieren Sie eine starke, einzigartige Diffie-Hellman-Gruppe. Einige feste Gruppen werden von Millionen von Servern verwendet, was sie zu einem optimalen Ziel für Vorabberechnungen und potenzielles Abhören macht. Administratoren sollten für jede Website oder jeden Server einzigartige Diffie-Hellman-Gruppen mit 2048 Bit oder mehr generieren, indem sie „sichere“ Primzahlen verwenden.

Welche Best-Practice-Schritte sollte ich unternehmen, um meinen Server gemäß den oben genannten Empfehlungen zu sichern?

Antwort1

Von demArtikel, den Sie verlinkt habenEs gibt drei empfohlene Schritte, um sich vor dieser Sicherheitslücke zu schützen. Im Prinzip gelten diese Schritte für jede Software, die Sie mit SSL/TLS verwenden, aber hier werden wir uns mit den spezifischen Schritten befassen, die für die Anwendung auf Apache (httpd) gelten, da dies die betreffende Software ist.

  1. Deaktivieren des Exportierens von Cipher Suites

Dies wird in den Konfigurationsänderungen behandelt, die wir weiter unten unter 2. vornehmen werden ( !EXPORTgegen Ende der SSLCipherSuiteZeile wird beschrieben, wie wir die Export-Chiffre-Suiten deaktivieren werden).

  1. Bereitstellung des (flüchtigen) Elliptic-Curve-Diffie-Hellman-Verfahrens (ECDHE)

Dazu müssen Sie einige Einstellungen in Ihren Apache-Konfigurationsdateien bearbeiten SSLProtocol, SSLCipherSuiteum SSLHonorCipherOrdereine „Best Practices“-Konfiguration zu erhalten. So etwas wie das Folgende reicht aus:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Hinweis: Die SSLCipherSuitezu verwendende Einstellung ändert sich ständig. Es empfiehlt sich, Ressourcen wieDieses hierum nach der neuesten empfohlenen Konfiguration zu suchen.

3. Generieren Sie eine starke, einzigartige Diffie-Hellman-Gruppe

Dazu können Sie

openssl dhparam -out dhparams.pem 2048.

Beachten Sie, dass dadurch der Server stark belastet wird, während die Parameter generiert werden. Sie können dieses potenzielle Problem jederzeit umgehen, indem Sie die Parameter auf einem anderen Computer generieren und scpsie dann mit oder auf ähnliche Weise auf den betreffenden Server übertragen, um sie dort verwenden zu können.

Um diese neu generierten dhparamsin Apache zu verwenden, aus demApache-Dokumentation:

Um benutzerdefinierte DH-Parameter zu generieren, verwenden Sie den Befehl openssl dhparam. Alternativ können Siefüge das Folgende anStandard-1024-Bit-DH-Parameter aus RFC 2409, Abschnitt 6.2zur jeweiligen SSLCertificateFile Datei:

(Hervorhebung von mir)

Darauf folgt dann ein standardmäßiger 1024-Bit-DH-Parameter. Daraus können wir schließen, dass die benutzerdefinierten DH-Parameter einfach an die betreffenden Parameter angehängt werden können SSLCertificateFile.

Führen Sie dazu einen Befehl wie den folgenden aus:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Alternativ gemäß derApache-Unterabschnittdes Artikels, auf den Sie ursprünglich verlinkt haben, können Sie auch die benutzerdefinierte dhparams-Datei angeben, die Sie erstellt haben, wenn Sie die Zertifikatsdatei selbst nicht ändern möchten, und zwar folgendermaßen:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

in den Apache-Konfigurationen, die für Ihre spezielle SSL/TLS-Implementierung relevant sind – im Allgemeinen in conf.d/ssl.confoder, conf.d/vhosts.confaber dies hängt davon ab, wie Sie Apache konfiguriert haben.

Es ist erwähnenswert, dass gemäßdieser Link,

Vor Apache 2.4.7 ist der DH-Parameter immer auf 1024 Bit eingestellt und nicht benutzerkonfigurierbar. Dies wurde in mod_ssl 2.4.7 behoben, das Red Hat in seine RHEL 6 Apache 2.2-Distribution mit httpd-2.2.15-32.el6 zurückportiert hat.

Aktualisieren Sie Apache2 unter Debian Wheezy auf 2.2.22-13+deb7u4 oder höher und OpenSSL auf 1.0.1e-2+deb7u17. Die obige SSLCipherSuite funktioniert nicht perfekt. Verwenden Sie stattdessen Folgendes gemäßdieser Blog:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Sie sollten überprüfen, ob Ihre Apache-Version je nach Ihrer Distribution neuer als diese Versionsnummern ist und wenn nicht, sie wenn möglich aktualisieren.

Nachdem Sie die oben genannten Schritte zur Aktualisierung Ihrer Konfiguration ausgeführt und den Apache-Dienst neu gestartet haben, um die Änderungen anzuwenden, sollten Sie überprüfen, ob die Konfiguration wie gewünscht ist, indem Sie die Tests ausführen aufSSLLabsund weiterder Artikelim Zusammenhang mit dieser speziellen Sicherheitslücke.

Antwort2

Basierend auf einem Patch von Winni Neessen habe ich einen Fix für Apache/2.2.22 (Debian Wheezy, möglicherweise auch unter Ubuntu verwendbar) veröffentlicht:https://flo.sh/debian-wheezy-apache2-logjam-fix/– Danke für Ihr Feedback.

Antwort3

Anstatt den komplexen Weg der oben genannten "Hacks" zu gehen, sollten SieUmstellung auf Nginxals Ihre Haupt-Webserver-Software (nicht nur Caching oder Proxy). Es scheint in puncto Sicherheit offensichtlich den aktuellen Standards zu entsprechen als die alten Apache-Engines. Durch die Verwendung des Nginx-Repository erhalten Sie eine viel aktuellere und stabilere Webserver-Engine als Apache.

Ich bin komplett umgestiegen. Das hat mir viel zeitaufwändige Problemlösungsarbeit in Bezug auf TLS erspart und – für unsere Konfigurationen – gleichzeitig viel RAM freigegeben. Tatsächlich fand ich die Verwendung von nginx erfrischend einfach und unkompliziert, verglichen mit den unzähligen Konfigurationskomplikationen von httpd/apache, an die ich mich gewöhnt hatte. Könnte Geschmackssache sein, ich war vor dem Wechsel ziemlich versiert in httpd/apache-Umschreiben/Konfiguration/Wartung, und es war einfacher, als ich befürchtet hatte. Es gibt entsprechende aktuelle Informationen zur nginx-Konfiguration online und die Benutzerbasis ist riesig, sehr aktiv und supportfreundlich. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png

verwandte Informationen