Konfigurieren von RHEL 8 für Compliance mit kryptografischen Richtlinien (Crypto-Policies) in Bezug auf Cipher Block Chaining

In diesem Beitrag gehen wir anhand eines Beispiels durch, wie die kryptografische Richtlinie (Crypto-Policy) von Red Hat Enterprise Linux (RHEL) 8 konfiguriert werden kann, um CBC (Cipher Block Chaining) zu entfernen. Beginnen wir jedoch mit ein wenig Hintergrundwissen über CBC und die standardmäßige kryptografische Richtlinie in RHEL 8.

Auf operativer Ebene haben die meisten von uns bereits Situationen erlebt, in denen eine komplexe Konfiguration in einem Systems vorhanden war und es entweder zu viel oder zu wenig Informationen gab, um alles zu verstehen. 

Sind Sie beispielsweise schon einmal auf eine Aussage wie „Ihr Server unterstützt CBC-Chiffren, die nicht mehr empfohlen werden und anfällig sind“ gestoßen und wurden dann gefragt, ob Sie vor einer neuen Schwachstelle geschützt sind, zusammen mit der Aufforderung, diese so schnell wie möglich zu melden und ggf. Fehlerbehebungen vorzunehmen, falls Systeme in Ihrem Unternehmen betroffen sind? 

Welche Tools verwenden Sie? Welche Prüfungen werden Sie durchführen? Wurde das System ordnungsgemäß konfiguriert? Sind Ihre Server frei von bekannten Schwachstellen?

Diese Fragen können zum Glück mit den in RHEL 8 verfügbaren Technologien beantwortet werden, um die operative Effizienz zu steigern und das Vertrauen und Verständnis von Tools für kryptografische Richtlinien zu verbessern. 

Problemanalyse

Sehen wir uns das vorliegende Problem anhand dieses Wikipedia-Eintrags an. 

Demzufolge ist CBC einer der vielen Modi zur Verwendung einer Blockchiffre, bei der der aktuelle Chiffretextblock mit dem vorherigen per XOR verknüpft wird, bevor er verschlüsselt wird. Außerdem wird er als „der am häufigsten verwendete Betriebsmodus“ und „einer der beiden von Niels Ferguson und Bruce Schneier empfohlenen Blockchiffrierungsmodi“ bezeichnet. 

Weiterhin wird angegeben, dass es 1976 erfunden wurde, was darauf hindeuten könnte, dass es veraltet und nicht mehr sicher ist. Alt bedeutet jedoch nicht automatisch, dass sie unsicher sind. Der Diffie-Hellman-Schlüsselaustausch stammt ebenfalls aus dem Jahr 1976, ist jedoch immer noch weit verbreitet und gilt nicht als unsicher.

All diese Informationen helfen nicht wirklich dabei, die Situation zu verstehen. Es ist sehr wahrscheinlich, dass diese Untersuchung aufgrund einer Warnung eines automatisierten Schwachstellenscanners begann, in der festgestellt wurde, dass der OpenSSH-Server bereit ist, CBC-Verschlüsselungsmodi zu verwenden, und zwar mit CVE-2008-5161 als Ursache. Vielleicht wurde auch auf dieses oder ein anderes ebenso kryptisches Dokument verwiesen. Sätze wie „Es ist daher sehr unwahrscheinlich, dass eine interaktive Session unter Verwendung dieser Protokollschwäche erfolgreich angegriffen wird: Ein Angreifer würde etwa 11356 Verbindungs-Störversuche benötigen, bevor diese Erfolg haben können“ mögen beruhigend sein, aber bedeutet das auch, dass dieses Jahrzehnte alte Sicherheitsproblem in RHEL nicht behoben wurde?

Glücklicherweise arbeitet Red Hat proaktiv daran, die Schwachstellen in seinen Produkten zu überwachen und zu beheben. Auf der oben genannten NIST-Seite für CVE-2008-5161 wird eine Anbieteranweisung von Red Hat angezeigt, wonach das Problem in RHEL 5 behoben wurde. Red Hat hat außerdem einen Workaround bereitgestellt, um die CBC-Chiffren in der sshd-Konfiguration zu deaktivieren.

In diesem Artikel wird auch klargestellt, dass es sich bei den fraglichen Maßnahmen um die Anwendung von Upstream-Patches handelte, was die Wahrscheinlichkeit eines erfolgreichen Angriffs noch weiter senkt. Ein Schwachstellenscanner kennt solche Informationen nicht. Er überprüft das Vorhandensein der spezifischen Paketversionen, gleicht sie mit bekannten betroffenen Versionen ab und meldet das Ergebnis. Diese Tools sind nicht perfekt und können keine solchen Risikominderungen erkennen. 

Wenn Zweifel an der Sicherheit eines bestimmten Algorithmus bestehen, warum gehen Sie nicht den nächsten Schritt und deaktivieren ihn ganz? Diese Änderungen sollten unter Einbeziehung von Kompatibilitätsbedenken abgewogen werden. 

Diese CBC-Chiffren könnten die einzige gemeinsame Sprache sein, wenn es um Interoperabilität mit älteren SSH-Clients und -Servern geht, und das Gleichgewicht zwischen sichereren Standardeinstellungen und Kompatibilität liegt in der Verantwortung der Distributionsentwicklungsteams. 

Fedora 33 deaktiviert beispielsweise CBC-Chiffren für die Verwendung mit SSH, wie auf dieser Merge-Anforderung upstream zu sehen ist. Bei RHEL 8, einer Unternehmensdistribution, die ein Jahr zuvor veröffentlicht wurde, wurde sie standardmäßig aktiviert gelassen, wobei sowohl Abhilfemaßnahmen als auch Kompatibilitätsgründe angeführt werden, wie in diesem Bugzilla zu sehen ist: 1818103 – SSH Server CBC Mode Ciphers Enabled in RHCOS.

Ausgewogene Standardeinstellungen sind wichtig, aber Standardeinstellungen sind veränderbar. Die Situationen der Nutzenden sind unterschiedlich, und es liegt an ihnen, eigene Entscheidungen zu treffen, die sie für richtig halten. Um diese Anforderung zu erfüllen, wurde RHEL 8 auf einen neuen, zentralisierten Mechanismus zum Deaktivieren/Aktivieren der Verwendung kryptografischer Algorithmen (Crypto-Policies) umgestellt. Sehen wir uns an, wie diese verwendet werden können, um CBC-Chiffren zu deaktivieren.

Features und Konfiguration für die kryptografische Richtlinie in RHEL 8

Ein Blick auf die Standardrichtlinie in RHEL 8 vermittelt ein besseres Verständnis der Situation:

sudo less /usr/share/crypto-policies/policies/DEFAULT.pol 
# A reasonable default for today's standards. It should provide 
# 112-bit security with the exception of SHA1 signatures needed for DNSSec 
# and other still prevalent legacy use of SHA1 signatures.

In RHEL 8 können weitere Richtlinien festgelegt werden, um zusätzliche Sicherheitsanforderungen in Bezug auf kryptografische Richtlinien zu erfüllen: 

• FIPS.pol: Eine Richtlinie, die nur den genehmigten FIPS-Algorithmus verwendet.

• FUTURE.pol: Eine Ebene, die Sicherheit auf einem konservativen Niveau bietet, von der angenommen wird, dass es jeglichen kurzfristigen, zukünftigen Angriffen standhält. 

• LEGACY.pol: Bietet Einstellungen für maximale Kompatibilität mit Altsystemen.

Sie können diese Richtlinien sogar flexibel ändern, indem Sie Unterrichtlinien erstellen oder Ihre eigene Richtlinie von Grund auf neu erstellen. Wir haben bereits einen Beitrag im Red Hat Blog veröffentlicht, in dem das Tool „update-crypto-policies“, seine Funktionen und eine Erklärung zu dessen Verwendung vorgestellt werden.

Zu diesem Thema gibt es eine zusätzliche wichtige Dokumentation für RHEL 8: „Using system-wide cryptographic policies Red Hat Enterprise Linux 8“.

Konfigurieren der kryptografischen Richtlinie von RHEL 8 zum Entfernen von CBC

Um auf unser ursprüngliches Problem zurückzukommen, der Auditor bietet zusätzliche, unterstützende Fakten, das Tool zur Schwachstellenbewertung meldet das Problem: Vulnerability Name: SSH CBC Mode Ciphers Enabled, Description: CBC Mode Ciphers are enabled on the SSH Server.

Wie die Online-Kommentare zeigen, sind viele in der Lage, ihr System so zu konfigurieren, dass das Problem nach dem erfolgreichen Schwachstellenscan vermeintlich behoben wird. In der Praxis konfigurieren sie den sshd-Prozess so, dass die CBC-bezogenen Chiffren nicht verwendet werden. So wird verhindert, dass sshd diese Chiffren verwendet. Es gibt sogar einige Anweisungen zur Anwendung dieses Workarounds. 

Dies gilt nur für den sshd-Prozess und nicht für den gesamten Server. Das ist ein Agieren auf Prozessebene und nicht auf Systemebene. Mit anderen Worten: Während die Prüfung für den SSH-CBC-Modus erfolgreich abgeschlossen wird, verbleiben einige CBC-Chiffren weiterhin auf dem Server. Es empfiehlt sich, die Änderung auf Systemebene vorzunehmen. Dies ist genau die Aufgabe des Tools „update-crypto-policies“.

Zuerst können wir die derzeit auf dem RHEL 8-Server verwendete kryptografische Richtlinie anzeigen:

update-crypto-policies --show 
DEFAULT

Da wir festgelegt haben, dass RHEL 8 die kryptografische Richtlinie DEFAULT verwendet, können wir versuchen, die CBC-bezogenen Chiffren unter /usr/share/crypto-policies/policies/DEFAULT.pol zu finden.

tls_cipher = ... AES-256-CBC ...AES-128-CBC 
cipher = ... AES-256-CBC CAMELLIA-256-CBC AES-128-CBC CAMELLIA-128-CBC

(Die nicht zugehörigen Chiffren wurden zur besseren Übersicht entfernt.)

In der DEFAULT-Richtlinie werden 6 Chiffren im Zusammenhang mit CBC verwendet.

Dann wird es kompliziert. Zum Zeitpunkt der Erstellung dieses Dokuments gibt es keine Richtliniendateien, die Beispiele für die zusätzliche Crypto-Policy-Einstellung „ssh_cipher“ zeigen. Es wird auf der Manpage erwähnt: man crypto-policies (... ssh_cipher: Optional; Liste der zulässigen symmetrischen Verschlüsselungsalgorithmen (einschließlich der Modi) zur Verwendung mit dem SSH-Protokoll. Falls nicht vorhanden, wird der Wert von cipher...) abgeleitet. 

Diese ssh_cipher ist vorhanden, und obwohl sie in der Richtlinie DEFAULT nicht explizit sichtbar ist, muss sie in der Unterrichtlinie explizit ausgeschlossen werden, wenn wir alle CBC-bezogenen Verschlüsselungen effektiv entfernen möchten.

Wir können eine Unterrichtlinie erstellen, die die verwendete Richtlinie DEFAULT ändert. Dazu muss eine Unterrichtliniendatei erstellt werden

 /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod

Hinweis: Die Namenskonvention ist wichtig. Es müssen Großbuchstaben für den Namen der Unterrichtlinie und .pmod in Kleinbuchstaben für den Erweiterungsnamen verwendet werden.

Diese Datei muss die Änderungen enthalten, die wir in der DEFAULT-Richtlinie vornehmen möchten.

Um die CBC-Chiffren vom Server zu entfernen und das Profil DEFAULT zu ändern, müssen wir Folgendes hinzufügen:

tls_cipher = -AES-256-CBC -AES-128-CBC 
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC 
ssh_cipher = -AES-128-CBC -AES-256-CBC

So entfernen Sie den CBC-Algorithmus nur für sshd vom Server:

ssh_cipher = -AES-128-CBC -AES-256-CBC

Hinweis: Da es zu ssh_cipher keine Beispiele gibt, kann man annehmen, dass der Wert folgendermaßen aussehen könnte:

ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

Genau genommen geben wir diese -CAMELLIA nicht an, da sie anscheinend nicht von sshd beworben oder verwendet werden, wie man sieht: man sshd_config | grep -i cbc

                   3des-cbc                    
                   aes128-cbc                    
                   aes192-cbc                    
                   aes256-cbc )

3des-cbc wird auch auf dem RHEL 8.2-Server nicht beworben, wie mit ssh-vv und unter „Ihr Angebot“ zu sehen ist: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr).

Die Unterrichtlinie mit der Konfiguration, bei der CBC-Chiffren entfernt werden, muss festgelegt werden:

sudo update-crypto-policies --set DEFAULT:DISABLE-CBC

Wir können überprüfen, ob die Einstellung korrekt ist: 

sudo update-crypto-policies --show  
DEFAULT:DISABLE-CBC

Der Server muss anschließend neu gestartet werden, damit die Richtlinie und die Unterrichtlinie wirksam werden.

Zu diesem Zeitpunkt sollten keine CBC-Chiffren mehr vom Server verwendet werden. Eine Möglichkeit zur einfachen Überprüfung besteht darin, dies mit sshd zu prüfen, indem Sie diesen Befehl auf einem RHEL 8-Server ausführen

ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 

Es sollten Anmeldeinformationen angezeigt werden, und Nutzende sollten mit gültigen Zugangsdaten eine Verbindung herstellen können.

Sind die CBC-Chiffren für sshd nicht vorhanden, würde dies angezeigt werden:

Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. 

Der sshd-Prozess zeigt dann an, welche Chiffren von diesem Server angeboten werden, z. B.: „Ihr Angebot: aes256-gcm@openssh.com,chacha20-poli1305@openssh.com,aes256-ctr,aes128-gcm@openssh. com,aes128-ctr”

Zusammenfassung

In diesem Blog haben wir die Konfiguration eines RHEL 8-Servers besprochen, um eine bestimmte Anforderung an die kryptografischen Richtlinien zu erfüllen. Wir haben gezeigt, wie man CBC-bezogene Chiffren von einem Server entfernt, nachdem man die Sicherheitsbedenken validiert hat. Wir haben Tools wie „update-crypto-policies“ verwendet, um einige Sicherheits-Compliance-Anforderungen auf Serverebene zu erfüllen, anstatt uns auf der Ebene der einzelnen Komponenten darum kümmern zu müssen.