Interpretation eines Sicherheitsreports für Ihren Server

Sicherheitsscans für Ihre Anwendung sind ein hervorragendes Mittel, um die Sicherheit der extern erreichbaren Elemente Ihrer Applikation zu überprüfen und zu verbessern. Oftmals führen diese Sicherheitsscans auch grundlegende Prüfungen der Infrastruktur durch, die regelmässig eine hohe Anzahl falsch positiver Ergebnisse und irreführender Informationen produzieren.

Dieser Artikel soll die häufigsten "Sicherheitsprobleme", die uns gemeldet werden, zusammenfassen und Ihnen die Informationen liefern, die Sie benötigen, um den erhaltenen Bericht zu analysieren.

Einleitend zu dieser Zusammenfassung möchten wir Sie auf unseren Artikel über Sicherheitsempfehlungen für Ihren Managed Server. hinweisen.

Ubuntu Software-Versionen und Patching-Philosophie

Nine verwendet Ubuntu LTS-Versionen (Long Term Support), welche im Abstand von zwei Jahre veröffentlich werden.

Canonical legt vor der Veröffentlichung einer neuen LTS-Version für jedes Paket eine "Major" Version fest, die sich über die Supportdauer der Ubuntu LTS-Version nicht verändert. Um sicherzustellen, dass keine kritischen Sicherheitslücken in diesen Paketen bestehen, portiert Canonical Sicherheitsaktualisierungen aktiv zurück.

Daher sind diese Versionen, auch wenn sie auf den ersten Blick veraltet und potenziell angreifbar zu sein scheinen, absolut sicher in der Anwendung und Sicherheitsprobleme wurden durch die Rückportierung von Patches aus neueren Versionen behoben.

Ein Paradebeispiel hierfür ist OpenSSH. Unter Ubuntu Focal scheint bei Überprüfung von aussen die OpenSSH-Version 8.2p1 zu sein, wenn eine Verbindung hergestellt wird:

Remote protocol version 2.0, remote software version OpenSSH_8.2p1

Zum Zeitpunkt der Verfassung dieses Artikels (Juli 2024) ist folgende Version installiert:

apt-cache policy openssh-server
openssh-server:
  Installed: 1:8.2p1-4ubuntu0.11

Die installierte Version 8.2p1-4ubuntu0.11 spiegelt den Patch-Level (0.11) des OpenSSH-Serverpakets wider und verdeutlicht die Philosphie, mit welcher Canonical Sicherheitsaktualisierungen zurück portiert. Der Patch-Level wird in der obigen Verbindungsinformation bewusst nicht angezeigt.

SSH

OpenSSH ist der Standard für den Aufbau von Remote-Shell-Verbindungen zu Servern. Dies macht OpenSSH zu einem potentiellen Ziel für Angriffe und erfordert einen strikten Sicherheitsansatz in der Entwicklung. Der Sicherheitsaspekt steht bei der Entwicklung des Dienstes daher seit jeher im Vordergrund.

OpenSSH is one of the most secure software in the world. Its defense-in-depth design and code are a model and an inspiration, and we thank OpenSSH's developers for their exemplary work.

Dies sind die Worte der Experten von Qualys, einem im Umfeld der IT-Sicherheit bekannten Dienstleister, der im Laufe der Jahre hunderte von Sicherheitsproblemen in verschiedenen Softwareprojekten finden konnte.

Dennoch ist natürlich keine Software frei von Fehlern.

Kritische Sicherheitsprobleme in OpenSSH sind extrem selten. Zudem haben die Entwickler wiederholt unter Beweis gestellt, gemeldete Lücken schnell zu behoben.

Die folgende Übersicht enthält behobene oder behandelte Probleme, die wir regelmässig in Sicherheitsreporten sehen.

CVE	Betroffene OpenSSH version	Betroffene Ubuntu versions	Note
CVE-2016-20012	< 8.7	Alle vor Jammy	Umstrittener Fehler, von den Entwicklern ignoriert. Weitere Informationen finden Sie in der Github Diskussion.
CVE-2020-14145	< 8.4	Alle vor Jammy	Betrifft lediglich die Client-Integration. Eine Behebung würde wahrscheinlich RFCs verletzen. Von den Entwicklern ignoriert.
CVE-2020-15778	< 8.3	Alle vor Jammy	Betrifft ausschliesslich authentifizierte Benutzer, mehr Informationen finden Sie hier.
CVE-2021-28041	< 8.2	Focal	Falsch positiv, behoben in 8.2p1-4ubuntu0.2
CVE-2021-36368	< 8.9	Alle vor Jammy	Umstrittener Fehler, von den Entwicklern ignoriert. Betrifft ausschliesslich den FIDO Authentifikationsmechanismus (wird von Nine nicht verwendet).
CVE-2023-38408	< 9.3p2	Alle	Falsch positiv, behoben in: Xenial: 7.2p2-4ubuntu2.10+esm3 Bionic: 7.6p1-4ubuntu0.7+esm1 Focal: 8.2p1-4ubuntu0.8 Jammy: 8.9p1-3ubuntu0.3 Noble: 9.3p1-1ubuntu2
CVE-2023-48795	< 9.6	Alle	Falsch positiv, behoben in: Xenial: 7.2p2-4ubuntu2.10+esm Bionic: 7.6p1-4ubuntu0.7+esm3 Focal: 8.2p1-4ubuntu0.10 Jammy: 8.9p1-3ubuntu0.5 Noble: 9.6p1-3ubuntu1
CVE-2023-51384	8.9 - 9.6	Jammy, Noble	Betrifft nur den ssh-agent
CVE-2023-51385	< 9.6	Alle	Falsch positiv, behoben in: Xenial: 7.2p2-4ubuntu2.10+esm5 Bionic: 7.6p1-4ubuntu0.7+esm3 Focal: 8.2p1-4ubuntu0.11 Jammy: 8.9p1-3ubuntu0.6 Noble: 9.6p1-3ubuntu1
CVE-2024-6387	8.5 - 9.6	Jammy, Noble	Falsch positiv, behoben in: Jammy: 8.9p1-3ubuntu0.10 Noble: 9.6p1-3ubuntu13.3

An der Stelle sei erwähnt, dass Sicherheitsaudits ein "Ratespiel" hinsichtlich OpenSSH spielen. OpenSSH sieht vor, beim Verbindungsaufbau eine Versionsinformation auszugeben. Diese Information wird von Clients benötigt, um im weiteren Verlauf des Verbindungsaufbaus wichtige Parameter zwischen Client und Server auszuhandeln.

Die im Verbindungsaufbau angezeigte Version lässt keinen Rückschluss auf das Patch-Level des Dienstes zu.

Seien Sie versichert, dass Nine sicherheitsrelevante Probleme aktiv überwacht und umgehend behebt.

TLS

Ciphers

TLS-Ciphers legen die kryptographischen Algorithmen fest, die für den Aufbau einer TLS-Verbindung verwendet werden. Client und Server einigen sich während eines "Handshakes" auf ein gemeinsames kryptographisches Verfahren. Wenn Client und Server keine gemeinsamen Ciphers unterstützen, ist ein Verbindungsaufbau nicht möglich.

Um eine Vielzahl an Clients zu unterstützen, ohne dabei wichtige Sicherheitsaspekte zu vernachlässigen, unterstützt Nine eine Reihe an Ciphers, die von der Mozilla Foundation für Rückwärtskompatibilität empfohlen werden. Diese Ciphers stellen einen Kompromiss zwischen Sicherheit und Kompatibilität dar, stets mit dem Ziel, weiterhin eine gute Bewertung im bekannten Qualys SSL Check zu erreichen.

Wenn Sie ausschliesslich die modernsten Ciphers unterstützen möchten und eine breite Client-Kompatibilität für Sie keine Rolle spielt, passen wir die verwendeten Ciphers gerne auf Ihren Bedarf an.

Default Vhost und Server Name Indication (SNI)

Alle Nine Managed Umgebungen, auf denen ein Webserver betrieben wird, kommen mit einem vorkonfiguriertem "Default Vhost". Dieser Vhost wird angesprochen, wenn ein Aufruf keinem Vhost zugeordnet werden kann, beispielsweise wenn die IP-Adresse des Servers im Browser aufgerufen wird. In diesem Fall wird eine einfache "Keine Webseite konfiguriert" Nachricht ausgegeben.

Dadurch wird sichergestellt, dass Suchmaschinen nicht versehentlich Kundeninhalte unter einer von Nine kontrollierten URL indizieren.

Der "Default Vhost" wird ebenfalls ausgeliefert, wenn ein Client SNI nicht unterstützt. Andernfalls würde der erste (in alphabetischer Abfolge) Kunden-Vhost angesprochen werden, was aller Wahrscheinlichkeit nach zur Auslieferung von unerwünschten Inhalten führen würde.

Selbstsignierte TLS-Zertifikate

Der "Default Vhost" ist über https erreichbar. Zu diesem Zweck erstellt Nine ein selbst signiertes TLS-Zertifikat. Hier verfolgen wir die selben Ziele, wie vorhergehend im Abschnitt "Default Vhost" beschrieben.

Für den Fall dass ein Kunden-Vhost bislang kein TLS-Zertifikat einsetzt, die Umgebung aber per https aufgerufen wird, so wird ebenfalls der "Default Vhost" ausgeliefert.

Dies kann durch die Erstellung eines Let's Encrypt-Zertifikates für diesen Vhost vermieden werden. Um ein Let's Encrypt-Zertifikat auszustellen, folgen Sie bitte der Dokumentation von nine-manage-vhosts.

Für den Fall, dass Sie den Managed Service FTPAdmin verwenden, werden Sie im Sicherheitsreport möglicherweise einen Hinweis auf die Verwendung eines selbst signierten Zertifikates für den FTP-Dienst finden. Dies ist zur Verwendung mit FTP(E)S-Verbindungen vorgesehen.

Bei Bedarf kann für den FTP-Dienst ein Zertifikat einer anerkannten Zertifizierungsstelle eingebunden werden.

FTP

Häufig wird das Vorhandensein eines FTP-Dienstes in einem Sicherheitsreport als Sicherheitsrisiko moniert, und wir können dem nur zustimmen! Das FTP-Protokoll stamm aus dem Jahr 1972, und wurde mit einem "modernerem" RFC im Jahr 1985 abgelöst.

Wenn Ihre Applikation oder Ihr Anwendungsfall nicht strikt auf die Verwendung von FTP angewiesen ist, empfehlen wir dringend, ausschliesslich SFTP zu verwenden, welches die allermeisten Anwendungsfälle von FTP problemlos ersetzen kann.

Sehr gerne deaktivieren wir das FTP-Protokoll für Sie. Die Deaktivierung hat keinen Einfluss auf die SFTP-Integration von FTPAdmin.

HTTP Header

Gelegentlich weisen Sicherheitsreporte auf fehlende HTTP-Header hin. Bestimmte HTTP-Header ermöglichen einen Sicherheitszugewinn. Wir raten dazu, diese Header im Kontext der Applikation zu setzen. Hierzu bietet sich neben einer .htaccess auch das Setzen über die Applikation / den Quellcode selbst an.

In unserem Artikel zu Sicherheitsempfehlungen für Ihren Managed Server werden einige Header behandelt, die in diesem Kontext relevant sein können.