%20am%20besten%3F%20.png)
Ich arbeite in einer Regierungsbehörde. Wir betreiben einen SFTP-Client und einen SFTP-Server auf einem DMZ-System, über das wir Dateien über das Internet empfangen und senden.
Unsere Umwelt:
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26. Januar 2017
Linux-Version 3.10.0-1160.102.1.el7.x86_64 ([email geschützt]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Montag, 25. September 2023, 05:00:52 EDT
Red_Hat_Enterprise_Linux-Release_Notes-7-en-US-7-2.el7.noarch
redhat-release-server-7.9-8.el7_9.x86_64
Intel(R) Xeon(R)
Unser Problem ist, dass einer unserer Partner die OpenSSH-Version aktualisieren möchte, wir aber nicht wissen, welche Version die stabilste und sicherste ist. Ich habe mir die OpenSSH-Site und andere angesehen, aber keine gute Antwort gefunden.
Unsere Frage: Welche OpenSSH-Version unter Linux empfehlen Sie im Hinblick auf Stabilität und Sicherheit (SFTP-Sicherheit)?
Grüße
Anders
Antwort1
Da Sie bereits REL verwenden, würde ich vorschlagen, dabei zu bleiben, obwohl Sie auf Version 8 oder 9 aktualisieren sollten. Wie @tink angemerkt hat, portiert REL Sicherheitspatches in seine Pakete zurück, ohne die Haupt-/Nebenversionsnummern zu ändern, sodass Sie dort sehr sicher sind.
Wenn möglich, sollten Sie FIPS 140-2 aktivieren, um eine Liste von NIST-genehmigten Chiffren und MACs durchzusetzen. Andernfalls können Sie sshd so konfigurieren, dass es einen eingeschränkten Satz von Chiffren verwendet, die als sicherer gelten.
Zum Schluss noch eine Frage: Wenn Ihr Partner die OpenSSH-Version wechseln möchte, welche Auswirkungen hat das auf den von Ihnen betriebenen Server?
Antwort2
Generell gilt: Versuchen Sie, auf dem neuesten Stand zu bleiben und alle Sicherheitspatches anzuwenden. Das Neueste ist also (normalerweise) am besten. Es gibt Schwachstellen aus dem Jahr 2017 bei OpenSSH vor 7.6. Wenn Sie also Sicherheitsbedenken haben, hätten Sie schon vor langer Zeit ein Upgrade durchführen sollen.
Was die Stabilität betrifft: Wenn Sie RedHat verwenden, erhalten Sie durch die Verwendung von SSH aus den RedHat-Repositorys eine stabile Version.
Sie können jederzeit die Versionshinweise lesen und nach den Sicherheitshinweisen suchen. Zitat:
- ssh(1), sshd(8) in OpenSSH vor Version 9.6. Schwäche beim initialen Schlüsselaustausch ("Terrapin Attack")
- ssh-agent(1) in OpenSSH zwischen 8.9 und 9.5 (einschließlich) Unvollständige Anwendung von Zielbeschränkungen auf Smartcard-Schlüssel.
- ssh-agent(1) in OpenSSH zwischen 5.5 und 9.3p1 (einschließlich) Remote-Code-Ausführung in Bezug auf PKCS#11-Anbieter
- ssh(1) in OpenSSH zwischen 6.5 und 9.1 (einschließlich). ssh(1) konnte die von libc zurückgegebenen DNS-Namen nicht auf ihre Gültigkeit überprüfen.
- sshd in OpenSSH zwischen 6.2 und 8.7 (einschließlich). sshd(8) konnte zusätzliche Gruppen bei der Ausführung eines AuthorizedKeysCommand oder AuthorizedPrincipalsCommand nicht korrekt initialisieren.
Ich würde sagen, alles unter 9,6 ist ein Sicherheitsproblem.
Im Ernst: Bei einer so alten Version zu bleiben, ist hinsichtlich Stabilität und Sicherheit ein größeres Problem, als ein vollständiges Upgrade auf die neueste Version durchzuführen.
Antwort3
Das hängt von Ihrem Servicelevel bei Redhat ab. 7 wird in zwei Monaten nicht mehr unterstützt.
Redhat wendet Sicherheitspatches normalerweise an/portiert sie zurück, ohne die Hauptversionsnummern der Basispakete zu ändern; das gilt sowohl für den Kernel als auch für Anwendungen. Ich habe derzeit keinen Zugriff auf Redhat- oder CentOS-Rechner und kann daher nicht überprüfen, wann Ihr Rechner das OpenSSH_7.4p1
letzte Mal aktualisiert wurde (versuchen Sie es mit etwas wie rpm -qa --last|grep ssh
, ich habe RHEL schon ewig nicht mehr verwendet).