Leitfaden zur Sicherheit: Wie Sie Ihre Infrastruktur vor einfachen Angreifern schützen können

16. September 2026

Ihre Infrastruktur in einer sicheren Konfiguration zu betreiben, ist selbst für Sicherheitsfachleute eine gewaltige Aufgabe. Dieser Leitfaden bietet praktische Ratschläge, um Techniker dabei zu unterstützen, eine Infrastruktur nach den Sicherheits-Best Practices aufzubauen, damit sie ihre Dienste sicher im öffentlichen Internet bereitstellen und das Risiko einer Kompromittierung senken können. Dieser Leitfaden richtet sich speziell an Linux-basierte Systeme. Die Best Practices gelten jedoch für alle Computersysteme.

Ihre Infrastruktur in einer sicheren Konfiguration zu betreiben, ist selbst für Sicherheitsfachleute eine gewaltige Aufgabe. Dieser Leitfaden bietet praktische Ratschläge, um Techniker dabei zu unterstützen, eine Infrastruktur nach den Sicherheits-Best Practices aufzubauen, damit sie ihre Dienste sicher im öffentlichen Internet bereitstellen und das Risiko einer Kompromittierung senken können. Dieser Leitfaden richtet sich speziell an Linux-basierte Systeme. Die Best Practices gelten jedoch für alle Computersysteme.

Ein Teil des sicheren Betriebs einer Infrastruktur besteht darin, zu verstehen, wovor und vor wem Sie Ihre Infrastruktur schützen. Dieser Leitfaden wird letztendlich drei Versionen umfassen: Basic, Intermediate und Advanced. Jede Version konzentriert sich darauf, Ihre Infrastruktur vor einer anderen Art von Angreifern zu schützen.

Sie lesen die Basic-Version, die vor automatisierten Angriffen und Script-Kiddies schützen soll, die eher Exploitation-Tools als Exploitation-Techniken verstehen. Diese Art von Angreifer agiert eher opportunistisch als gezielt und wendet sich schnell leichteren Zielen zu. Wenn Sie ein Nebenprojekt betreiben oder ein Unternehmen gründen, ist dies der beste Ausgangspunkt und hilft Ihnen beim Aufbau einer soliden Grundlage.

Berücksichtigen Sie beim Lesen dieses Leitfadens, vor welcher Art von Angreifern und Angriffen Sie sich schützen möchten. Die Best Practices, die Sie befolgen oder nicht befolgen, hängen davon ab, was Sie schützen möchten und vor wem Sie sich verteidigen wollen.

Dieser Leitfaden folgt in seiner Erörterung der Softwaresicherheit den folgenden Leitprinzipien:

• Verteidigen, erkennen und reagieren. Das bedeutet, dass Sie gute Sicherheitspraktiken anwenden, um Ihre Infrastruktur zu verteidigen. Protokollieren Sie jedoch jedes verdächtige Verhalten und stellen Sie im Falle einer Kompromittierung einen sicheren Zustand wieder her.
• Jede Software kann kompromittiert werden. Jede nicht triviale Software weist Schwachstellen auf, die es Angreifern mit ausreichender Motivation ermöglichen, diese auszunutzen.
• Einfachheit bedeutet Sicherheit. Übermäßig komplexe Systeme sind für das Entwicklungsteam schwerer zu durchschauen und für Angreifer leichter auszunutzen. Einfachere Systeme, die leichter nachvollziehbar sind, sind oft sicherer. Führen Sie keine Sicherheitslösung ein, die Sie nicht verstehen.
• Verschleierung ist keine Sicherheit. Verlassen Sie sich auf die Sicherheit der Protokolle, die Sie zum Schutz Ihrer Infrastruktur verwenden, und nicht auf verborgene Ports und andere Tricks, um unsichere Protokolle zu verbergen.
• Betrachten Sie alle Eingaben von Nutzern als potenziell feindlich. Betrachten Sie alle Eingaben von Nutzern als potenziell feindlich und überprüfen Sie streng, was Sie zulassen.
• Prinzip der geringsten Privilegien. Gewähren Sie nur die minimalen Privilegien, die für die Ausführung eines Vorgangs erforderlich sind. Wenn ein Prozess oder System kompromittiert wird, sollten Angreifer nicht mehr Zugriff erhalten, als minimal erforderlich ist.

Das strikte Anwenden von Sicherheitsupdates für Software, die Sie nicht selbst geschrieben haben, mag als unzureichende Methode zum Schutz Ihrer Infrastruktur erscheinen und vielleicht sogar sinnlos wirken. Aus Sicherheitsperspektive ist es jedoch eine der besten Zeitinvestitionen, die Sie tätigen können. Im Folgenden finden Sie zwei Beispiele für aktuelle Sicherheitsprobleme, die auch weniger versierte Angreifer mit automatisierten Tools ausnutzen können, wenn Sie Ihre Server nicht mit den neuesten Sicherheitspatches aktualisiert haben:

• Heartbleed: ermöglicht es Angreifern, Ihre privaten Zertifikate zu stehlen und verschlüsselten Datenverkehr zu entschlüsseln
• Shellshock: ermöglicht es Angreifern, aus der Ferne beliebigen Code auf Ihren Servern auszuführen

Allein diese beiden Probleme würden Angreifern die vollständige Kontrolle über Ihre gesamte Infrastruktur geben. Glücklicherweise ist die Behebung dieser Fehler nicht schwierig.

Installieren Sie konsequent Sicherheitsupdates, die vom Anbieter Ihres Betriebssystems bereitgestellt werden. Die meisten Anbieter verfügen über eine automatisierte Methode. Für Debian-basierte Systeme können Sie beispielsweise Unattended Upgrades, und für Red Hat-basierte Systeme können Sie  AutoUpdates.

Automatisiertes Patching ist hervorragend, hat jedoch einen potenziellen Nachteil (für Ihr Unternehmen), wenn Sie Ihre Software nicht testen, bevor Sie Patches auf Produktionsservern anwenden: Dinge können unerwartet kaputtgehen. So sehr Paket-Maintainer auch versuchen sicherzustellen, dass Sicherheitsupdates keine Breaking Changes enthalten, können sie vor der Veröffentlichung nicht jede Kombination testen, die irgendwo ausgeführt wird. Deshalb ist es wichtig, entweder über ein Staging-System für Continuous Integration/Continuous Deployment (CI/CD) zu verfügen oder Sicherheitsupdates manuell zu testen, bevor sie auf Produktionsservern bereitgestellt werden.

Das reine Anwenden dieser Sicherheitsupdates reicht jedoch nicht aus. Wenn sich das Problem in einer Shared Library befindet, verwenden Sie weiterhin die alte Version der Bibliothek und sind anfällig für Exploits, bis Sie den damit verknüpften Prozess neu starten. Um zu überprüfen, ob Sie Binärdateien haben, die neu gestartet werden müssen, können Sie checkrestart für Debian-basierte Systeme und needs-restarting für Red Hat-basierte Systeme verwenden.

• DO: Patchen Sie Ihre Server gegen die neuesten Sicherheitslücken.
• DO: Verwenden Sie nach Möglichkeit automatische Updates von Ihrem Betriebssystem-Anbieter.
• DO: Starten Sie alle Dienste neu, die auf aktualisierten Shared Libraries basieren.
• DON’T: Stellen Sie keine Updates auf einem Server bereit, ohne vorher Tests durchzuführen.

Das Härten Ihrer Anwendung mithilfe von Funktionen auf Betriebssystemebene ist ein effektiver Ansatz, um das Schadensausmaß durch Angreifer zu begrenzen, nachdem diese eine Schwachstelle in Ihrer Anwendung ausgenutzt haben. Dieser Abschnitt konzentriert sich auf die Verwendung herkömmlicher Unix-Zugriffskontrollfunktionen, mit denen die meisten Nutzer vertraut sind, um Ihre Anwendung auf die minimalen Zugriffsrechte zu beschränken, die sie für den Betrieb benötigt. Diese Funktionen umfassen Berechtigungen für Dateien, die Nutzerkennung (UID) und den Root-Zugriff.

Das Ziel dieses Abschnitts ist es nicht, Ihre Anwendung so weit zu härten, dass Angreifer sie überhaupt nicht kompromittieren können. Das ist ein fast unmögliches Ziel. Das Ziel ist es, einzuschränken, was Angreifer tun können, sobald Ihre Anwendung kompromittiert wurde. Nachdem Angreifer Ihre Anwendung ausgenutzt haben, können sie Aktionen im Namen Ihrer Anwendung ausführen und möglicherweise sogar ihre Privilegien auf Root-Ebene ausweiten, was ihnen vollständigen Zugriff auf Ihr Betriebssystem ermöglicht. Das Ziel besteht stattdessen darin, die Aktionen, die Ihre Anwendung ausführen kann, auf das Nötigste zu beschränken, was wiederum die Angreifer einschränkt.

Sie sollten Ihre Anwendung so einschränken, dass Angreifer selbst dann, wenn sie Ihren Prozess ausgenutzt haben und Code über dieses Nutzerkonto ausführen können, nur über eingeschränkte Zugriffsrechte auf das Dateisystem verfügen. Dasselbe Konzept gilt für den Prozess, unter dem das Konto ausgeführt wird: Beschränken Sie die CPU-Zeit, den Arbeitsspeicher und die Anzahl der Dateideskriptoren, um DoS-ähnliche Angriffe abzuwehren, bei denen Angreifer Ihre Ressourcen erschöpfen. Das Ziel ist es, Angreifer dazu zu zwingen, einen Angriff zur Eskalation von Privilegien durchzuführen (einen anderen Teil Ihres Betriebssystems auszunutzen, um ihre Privilegien über die der laufenden Anwendung hinaus zu erweitern), um überhaupt etwas Bedeutungsvolles auf Ihrem System zu erreichen.

Um das Konto einzuschränken, über das Ihre Anwendung ausgeführt wird, befolgen Sie diese Richtlinien:

• Führen Sie Ihre Anwendung niemals als Root oder als Nutzer mit sudo-Rechten aus. Wird Ihre Anwendung ausgenutzt, bedeutet dies praktisch, dass Angreifer Root-Rechte erlangen können.
• Wenn Sie mehrere Anwendungen haben und jede auf unterschiedliche sensible Daten zugreift, sollten Sie in Betracht ziehen, jede unter ihrem eigenen Konto auszuführen und dann Dateisystem-Berechtigungen zu verwenden, um den Zugriff auf sensible Daten voneinander zu isolieren. Das bedeutet, dass sensible Anwendungsdaten niemals über Berechtigungen verfügen sollten, die es jedem ermöglichen, diese zu lesen und zu schreiben. Setzen Sie beispielsweise Berechtigungen niemals auf einen Wert wie 0777, sondern verwenden Sie einen Wert wie 0660.
• Stellen Sie sicher, dass sowohl der Anwendungsnutzer als auch die Gruppe über eingeschränkte Rechte verfügen. Das bedeutet, einen neuen eingeschränkten Nutzer und eine neue Gruppe für das Konto zu erstellen und diesem Nutzer keine Shell zuzuweisen. Angenommen, Sie haben eine App namens foo. Erstellen Sie einen Nutzer namens fooapp und legen Sie dessen Stammverzeichnis auf /var/appdata/fooapp fest: sudo useradd -r -s /bin/false --home /var/appdata/fooapp fooapp sudo mkdir /var/appdata/fooapp sudo chown fooapp:fooapp /var/appdata/fooapp
• Richten Sie Ihre Anwendung als Daemon ein, damit sie automatisch unter einem bestimmten Nutzer gestartet wird. Es gibt zwei allgemeine Ansätze, um dieses Problem zu lösen. Der erste besteht darin, Betriebssystemfunktionen (wie System V-Init-Skripte (Red Hat / Debian) oder systemd (Red Hat/ Debian) zum Starten und Stoppen Ihrer Anwendung zu verwenden und anschließend ein Prozessüberwachungstool (wie monit) einzusetzen, um Ihre Anwendung bei einem Absturz neu zu starten. Der andere Ansatz ist die Verwendung eines Prozessleitsystems (wie supervisord, skarnet s6, daemontools), die Ihre Anwendung als Child-Prozess starten und sie bei einem Absturz ebenfalls neu starten. Beide Ansätze sind absolut in Ordnung, und welcher für Sie am besten geeignet ist, hängt davon ab, was besser zu Ihrem Workflow passt.

Um den Prozess einzuschränken, der Ihre Anwendung ausführt, befolgen Sie diese Richtlinien:

• Weisen Sie pro Prozess Limits zu, indem Sie die Datei /etc/security/limits.conf verwenden. Wenn Sie beispielsweise die Anzahl der geöffneten Dateideskriptoren auf 10 und den Arbeitsspeicher auf 1 GB beschränken möchten, fügen Sie der Datei /etc/security/limits.conf die folgenden Zeilen hinzu:

fooapp hard nofile 10 # Limit von 10 offenen Dateideskriptoren fooapp hard as 1000000 # 1 GB Limit

• Binden Sie Ihre Anwendung nicht an einen niedrigen Port. Normalerweise müssen Sie Ihre Anwendung hierfür mit Administratorrechten ausführen. Binden Sie sie stattdessen an eine hohe Portnummer und verwenden Sie einen Reverse Proxy, um Ihre Anfragen an Ihre Anwendung weiterzuleiten. Verwenden Sie dann Linux-Capabilities, damit Ihr Reverse Proxy ohne weitere Privilegien an einen niedrigen Port gebunden werden kann. Wenn Sie beispielsweise einen Reverse Proxy in /opt/rproxy haben, können Sie seine Capabilities wie folgt festlegen:

setcap 'cap_net_bind_service=+ep' /opt/rproxy

• Ziehen Sie schließlich die Verwendung von chroot in Betracht. Beachten Sie jedoch, dass dies mit einem gewissen Wartungsaufwand verbunden ist. Mit chroot können Sie einschränken, was ein Prozess im Dateisystem sehen darf. Genauer gesagt ändert es Ihr Root-Verzeichnis in ein Verzeichnis Ihrer Wahl. Wenn Sie beispielsweise /var/chroot als Ihr neues Root-Verzeichnis definieren, sehen Prozesse die Dateien unter /var/chroot als /. Obwohl dies sicherer ist, bedeutet es, dass alle Shared Libraries, die Ihr Prozess verwenden könnte, kopiert werden und sich innerhalb von /var/chroot befinden müssen. Dies wiederum bedeutet, dass Sie bei jedem Anwenden von Sicherheitsupdates auch alle aktualisierten Shared Libraries neu kopieren müssen. Sie können diesen Wartungsaufwand durch Hard Links vermeiden, bieten dann aber einen Weg nach außen, den Angreifer potenziell ausnutzen können. Andere (Cgroup-basierte) Ansätze, mit denen Sie ähnliche Vorteile erzielen können, werden in der Intermediate-Version dieses Leitfadens behandelt.

• DO: Erstellen Sie ein eingeschränktes Konto zur Ausführung Ihrer Anwendung, was bedeutet, dass keine Shell und nur eingeschränkter Dateisystemzugriff vorhanden sind.
• DO: Binden Sie Ihre Anwendung an einen hohen Port, damit Sie sie als Nutzer ohne Privilegien ausführen können.
• DO: Verwenden Sie nach Möglichkeit Capabilities anstelle von Root.
• DON’T: Verwenden Sie kein chroot, es sei denn, Sie sind bereit, den Wartungsaufwand in Kauf zu nehmen.

Strenge Firewall-Regeln ermöglichen es Ihnen zu definieren, welche eingehende und ausgehende Kommunikation für Ihre Server zulässig ist. Wenn Sie mit einer Default-Deny-Richtlinie beginnen und nur bestimmten ein- und ausgehenden Datenverkehr zulassen, zwingt Sie dies dazu, sich über die minimalen Dienste Gedanken zu machen, die Sie freigeben möchten, was wiederum Ihr Angriffsrisiko senken kann. Ein fehlerhafter Prozess kann Ihre gesamte Infrastruktur nicht der Allgemeinheit zugänglich machen, es sei denn, Sie erlauben dies ausdrücklich.

Dieser Abschnitt konzentriert sich auf eingehende Firewall-Regeln und TCP/IP-Stack-Einstellungen. Obwohl ausgehende Firewall-Regeln sehr effektiv sind, um einzuschränken, wie weit Angreifer vordringen können, nachdem sie in Ihre Infrastruktur eingedrungen sind, wird sich die nächste Version dieses Leitfadens auf sie konzentrieren.

Gegenmaßnahmen

Zuerst die Firewall-Regeln. Verwenden Sie beim Erstellen eines Skripts für Firewall-Regeln die folgenden Leitprinzipien.

• Löschen Sie vorhandene Firewall-Regeln. Bei der Entwicklung von Firewall-Regeln benötigen Sie eine schlüssige Vorstellung davon, was Sie blockieren und was Sie zulassen. Alle vorhandenen Regeln zu verwerfen und von vorne zu beginnen, erfüllt diesen Zweck.
• Setzen Sie die Standardregel für eingehenden Datenverkehr auf DROP. Dies folgt dem Prinzip der geringsten Privilegien. Nachdem Sie die Standardrichtlinie auf DROP festgelegt haben, können Sie Ihr Netzwerk nach und nach öffnen.
• Gewähren Sie freien Zugriff auf das Loopback-Interface. Im Gegensatz zu externen Schnittstellen ist die Bindung Ihres Prozesses an Localhost in der Regel gut für die Sicherheit. Daher richtet eine Einschränkung des Zugriffs auf das Loopback-Interface mehr Schaden als Nutzen an. Dadurch bleiben Sie zwar anfällig für Angriffe durch lokale Nutzer, aber das ist ein Risiko, das Sie für sich selbst abwägen müssen.
• Beenden Sie keine etablierten Verbindungen. Sie möchten vermeiden, dass Ihre eigene SSH-Verbindung zu einem Server getrennt wird, und sicherstellen, dass alle laufenden Anfragen abgeschlossen werden können, bevor sie beendet werden.
• Schränken Sie nicht den gesamten Internet Control Message Protocol (ICMP)-Datenverkehr ein. Die Zulassung von ICMP ist entscheidend für das Funktionieren des Internets. Router und Hosts nutzen es, um wichtige Informationen wie die Verfügbarkeit von Diensten, Paketgrößen und die Existenz von Hosts zu übermitteln. Typ 3 und 4 (Destination Unreachable und Source Quench) sind von entscheidender Bedeutung. Ihre Einschränkung wird in Zukunft mehr Schaden als Nutzen anrichten. Wenn Sie Bedenken haben, dass Angreifer Ihr Netzwerk ausspionieren könnten, besteht ein vernünftiger Mittelweg darin, zunächst den gesamten ICMP-Datenverkehr durch Rate Limiting zu begrenzen und dann an Ihren Edge-Hosts eine bestimmte Untergruppe an ICMP-Datenverkehr zuzulassen, während die interne Host-to-Host-Kommunikation uneingeschränkt möglich bleibt.
• Führen Sie grundlegende Sicherheitsprüfungen durch. Mancher eingehende Datenverkehr erfüllt keinen legitimen Zweck. Schränken Sie diesen Datenverkehr ein. Wenn Sie häufig durch eine bestimmte Art von Datenverkehr angegriffen werden, kann es hilfreich sein, diesen in eine eigene Chain umzuwandeln, falls Sie diesem Abschnitt regelmäßig neue Regeln hinzufügen.
• Sofern Sie IPv6 nicht tatsächlich nutzen und planen, Firewall-Regeln für den IPv6-Datenverkehr zu erstellen, schränken Sie den gesamten eingehenden IPv6-Datenverkehr ein.

Im Folgenden finden Sie ein kommentiertes Skript, das all diese Ziele erreicht:

Nachfolgend finden Sie ein kleines Skript für IPv6-Datenverkehr:

Diese Regeln werden nun im Arbeitsspeicher ausgeführt. Sie müssen sicherstellen, dass sie beim nächsten Neustart Ihres Betriebssystems geladen werden. Für Debian-basierte Systeme bedeutet das, Ihre Firewall-Regeln entweder zu /etc/network/ip-pre-up.d/ hinzuzufügen oder einen pre-up-Befehl zu ergänzen in /etc/network/interfaces. Bei Red Hat-Systemen geschieht dies typischerweise durch die Verwendung des /sbin/service iptables save-Befehls.

Darüber hinaus wird die folgende Härtung/Optimierung des TCP/IP-Stacks empfohlen:

• Wenn Sie wie im vorhergehenden Beispiel zustandsbehaftete (stateful) Firewall-Regeln verwenden, sollten Sie unbedingt die maximale Anzahl der Verbindungen erhöhen, die Sie nachverfolgen können. Andernfalls können Angreifer einen Distributed Denial-of-Service (DDoS)-Angriff auf Sie verüben.
• Verwenden Sie SYN-Cookies, um SYN-Flood-DoS-Angriffe zu verhindern. Thomas Pornin bietet eine hervorragende Erklärung dazu, was SYN-Flood-Angriffe sind und wie SYN-Cookies diese Art von Angriff abschwächen.
• Protokollieren Sie alle Martian-Pakete , da jedes Paket, das von einer nicht routingfähigen Quell- oder Zieladresse stammt, höchstwahrscheinlich bösartig ist.

Sie können alle oben genannten Einstellungen mit dem folgenden Skript ausprobieren:

Damit diese Einstellungen auch nach einem Neustart erhalten bleiben, aktualisieren Sie /etc/sysctl.conf:

• DO: Lehnen Sie Datenverkehr standardmäßig ab. Lassen Sie ausdrücklich nur den Datenverkehr zu, von dem Sie wissen, dass er Ihr Netzwerk passieren muss.
• DON’T: Schränken Sie ICMP nicht einseitig ein.
• DO: Gewähren Sie freien Zugang zum Loopback-Interface.
• DO: Erzwingen Sie einige grundlegende Sicherheitsprüfungen.
• DO: Stellen Sie sicher, dass Ihre Regeln beim Neustart geladen werden.
• DO: Optimieren Sie Ihren TCP/IP-Stack, um die Anzahl der nachverfolgten Verbindungen zu erhöhen und sich vor SYN-Floods zu schützen.

Bei der Remote-Anmeldung sollten Sie nicht nur sicherstellen, dass die Kommunikation mit Ihren Servern verschlüsselt ist, sondern auch, dass nur autorisierte Nutzer Zugriff auf Ihre Server haben. Im Folgenden sind typische Ziele für die Absicherung der Remote-Anmeldung aufgeführt:

• Gewähren Sie Nutzern nur eingeschränkten Zugriff, damit die Kompromittierung eines einzigen Nutzerkontos nicht Ihre gesamte Infrastruktur gefährdet.
• Eine starke Kryptografie stellt sicher, dass Lauscher Ihre Kommunikation nicht mitlesen können.
• Angreifer können keine Brute-Force-Techniken verwenden, um sich an Ihren Servern anzumelden.
• Selbst wenn Ihr Schlüssel kompromittiert ist, können Angreifer keinen Zugriff auf Ihre Infrastruktur erlangen.
• Angreifer, die Brute-Force-Techniken einsetzen, können die Serverressourcen nicht erschöpfen.
• Nur autorisierte Nutzer haben Zugriff auf Ihre Server.
• Es gibt keine Anmeldung für allgemeine Administratorenkonten. Alle administrativen Aktionen werden über eine Form der Eskalation von Privilegien (sudo) durchgeführt, um die ausgeführten Aktionen zu protokollieren.

Das Verfehlen auch nur eines dieser Ziele kann ein Sicherheitsrisiko darstellen. Eine schwache (oder fehlende) Kryptografie kann es Angreifern ermöglichen, Ihre Kommunikation einzusehen. Eine schwache Authentifizierung kann unautorisierten Nutzern den Zugriff auf Ihre Systeme ermöglichen.

Glücklicherweise mindert Secure Shell (SSH) die meisten dieser Risiken. Mit ein paar kleinen Anpassungen an Ihren Systemen lassen sie sich sogar vollständig beseitigen.

Gegenmaßnahmen

Generieren Sie zunächst Ihren SSH-Schlüssel korrekt. Achten Sie dabei auf eine ausreichend große Schlüssellänge und darauf, dass Ihr Schlüssel durch eine Passphrase geschützt ist. Sie können dies mit ssh-keygen erledigen:

ssh-keygen -t rsa -b 4096 -C foo@example.com

Wenn Sie dazu aufgefordert werden, geben Sie eine Passphrase ein. Eine Passphrase stellt sicher, dass jemand, der Ihren Schlüssel stiehlt, diesen nicht verwenden kann, ohne auch Ihre Passphrase zu kennen.

OpenSSH verfügt über eine vernünftige Standardkonfiguration, die recht sicher ist. Einige Distributionen weichen diese Standards jedoch möglicherweise auf, um die Interoperabilität von OpenSSH mit älteren Servern zu gewährleisten. Die folgende Konfiguration stellt lediglich sicher, dass diese vernünftigen Standardwerte von Ihrer OpenSSH-Version angewendet werden. Weitere Informationen zur OpenSSH-Konfiguration finden Sie im Mozilla-Konfigurationsleitfaden für OpenSSH und auf der Seite Securing SSH für CentOS. Beides sind exzellente Ressourcen und wir werden in zukünftigen Versionen dieses Leitfadens auf diesen Konfigurationen aufbauen.

Stellen Sie auf dem Server sicher, dass die Datei /etc/ssh/sshd_config die folgenden Zeilen enthält:

Diese Konfiguration erreicht die folgenden Ziele:

• Protocol 2 stellt sicher, dass Sie eine sichere Version des SSH-Protokolls verwenden. Version 1 des Protokolls weist eine Reihe von Problemen auf und gilt als unsicher.
• PasswordAuthentication no und PubkeyAuthentication yes zwingen Sie dazu, Public-Key-Kryptografie anstelle von Passwörtern zu verwenden, um sich an Ihren Servern zu authentifizieren. Obwohl Sie ein sicheres Passwort haben können, wenn es sich um ein zufällig generiertes 2048-Bit-Passwort in ASCII-Codierung handelt, sind die meisten Passwörter unsicher und häufig verwendete Passwortlängen haben einen viel kleineren Suchraum als ein großer Schlüssel.
• PermitRootLogin no deaktiviert die Möglichkeit der Remote-Anmeldung als Root-Nutzer. Obwohl es sich hierbei nicht um eine direkt ausnutzbare Schwachstelle handelt, hilft Ihnen das Deaktivieren dieser Remote-Anmeldung, saubere Audit-Protokolle zu führen, um nachvollziehen zu können, was auf Ihren Servern passiert. Das Root-Konto fungiert als gemeinsam genutztes Administratorenkonto, was Ihre Möglichkeiten einschränkt, zu überprüfen, welcher Nutzer welche privilegierte Aktion ausführt. Wenn Sie alle Nutzer dazu zwingen, ihre eigenen Konten zu verwenden, erhalten Sie eine überprüfbare Aufzeichnung darüber, welcher Nutzer welche Aktion ausgeführt hat. Details zur Einrichtung der Audit-Protokollierung finden Sie in einem späteren Abschnitt.
• LogLevel VERBOSE protokolliert den Nutzer und den Fingerprint des Schlüssels, mit dem ein Authentifizierungsversuch unternommen wurde. Auch hier wehrt diese Einstellung einen Exploit nicht direkt ab, ist aber für Auditing-Zwecke sinnvoll.

Stellen Sie auf Client-Seite sicher, dass Ihre Datei /etc/ssh/ssh_config die folgenden Zeilen enthält:

Diese Konfiguration erreicht die folgenden Ziele:

• Protocol 2 stellt sicher, dass Sie eine sichere Version des SSH-Protokolls verwenden. Version 1 des Protokolls weist eine Reihe von Problemen auf und gilt als unsicher.
• HashKnownHosts yes hasht Hostnamen und Adressen in Ihrer Datei ~/.ssh/known_hosts . Selbst wenn Angreifer Ihre Known Hosts-Datei stehlen, können sie nicht einfach die Hosts auflisten, mit denen Sie sich über Ihren Schlüssel verbinden.
• StrictHostKeyChecking ask gleicht den Ihnen präsentierten Schlüssel mit dem in Ihrer Datei ~/.ssh/known_hosts ab und fragt Sie, falls er sich geändert hat (oder Sie diesen Host zum ersten Mal besuchen), ob Sie diesen Schlüssel akzeptieren möchten. Dies hilft dabei, Man-in-the-Middle-Angriffe abzuschwächen.

Gewähren Sie Nutzern zu guter Letzt nur eingeschränkten Zugriff auf Ihre Infrastruktur. Beispielsweise benötigen nicht alle Nutzer Zugang zu Ihren Backup-Servern. Gewähren Sie nur den Nutzern Zugang, die tatsächlich wissen, wie Backups wiederhergestellt werden. Dadurch wird sichergestellt, dass die Integrität Ihrer Backups selbst bei der Kompromittierung eines Nutzerkontos ohne Backup-Befugnisse nicht gefährdet ist.

Um dies zu erreichen, gibt es zwei gängige Ansätze:

1. Lokale Nutzerkonten. Bei diesem Ansatz erstellen Sie lokale Unix-Konten für Ihre Nutzer und richten diese Konten nur auf den Servern ein, auf die sie zugreifen müssen. Hierzu können Sie die Befehle newusers und userdel verwenden und dies mithilfe von Konfigurationsmanagement-Tools automatisieren/orchestrieren, wie etwa Chef oder Ansible.
2. Zentraler Authentifizierungsdienst wie LDAP. Bei diesem Ansatz werden die Server, auf die die jeweiligen Nutzer Zugriff haben, in der Konfiguration des LDAP-Servers definiert und gespeichert.

• DO: Schützen Sie Ihren Schlüssel durch eine Passphrase.
• DON’T: Verlassen Sie sich nicht darauf, dass Ihre Distribution über akzeptable Standardwerte verfügt. Definieren Sie stattdessen strikt, was für Ihre Infrastruktur wichtig ist.
• DO: Verwenden Sie zur Authentifizierung asymmetrische Verschlüsselung (Public Key) anstelle einer passwortbasierten Authentifizierung.
• DON’T: Gewähren Sie nicht allen Nutzern uneingeschränkten Zugriff, sondern beschränken Sie den Zugriff auf die benötigten Teile Ihrer Infrastruktur.

Trust Boundaries (Vertrauensgrenzen) sind ein häufiger Ort für das Auftreten von Sicherheitslücken. Die Grenze zwischen der Außenwelt und Ihrer internen Infrastruktur ist unverletzlich, und Sie sollten alles tun, um sie zu verteidigen und sicherzustellen, dass sie nur von autorisierten Nutzern überschritten werden kann.

Sie sollten sich um zwei primäre Vertrauensgrenzen Gedanken machen. Die erste ist die Grenze zwischen dem öffentlichen Internet und Ihrem API-Endpunkt. Dies ist die Grenze, die Ihre Kunden jeden Tag überqueren, wenn sie Ihren Dienst nutzen. Die zweite ist ein Zugangspunkt für Ihr Entwicklungs- und Systemadministrations-Team, der für die Bereitstellung und Wartung Ihrer Anwendung genutzt wird.

Bei der API-Vertrauensgrenze, die Ihre Kunden überschreiten, sollten Sie alle Eingaben von Nutzern als potenziell feindlich betrachten und davon ausgehen, dass jede gestellte Anfrage eigentlich ein Versuch ist, Ihre Infrastruktur zu kompromittieren. Wenn Sie Anfragen von Nutzern auf diese Weise betrachten, wird deutlich, dass Sie die Angriffsfläche minimieren müssen, die Sie Ihren Nutzern bieten, und den Schaden isolieren müssen, der entstehen kann, falls ein Nutzer Ihren Dienst doch einmal kompromittiert.

Was die Vertrauensgrenze betrifft, die Sie zur Wartung Ihrer Anwendungen überschreiten, sollten Sie alle Ihre Dienste so isolieren, dass sie nicht dem öffentlichen Internet ausgesetzt sind. Zwingen Sie dann Nutzer, die aus dem Internet darauf zugreifen, einen gut bewachten Zugangspunkt zu passieren, den Sie verteidigen können (nennen wir diesen Bastion Host). Sie können alle Ihre Ressourcen auf diesen einen Zugangspunkt konzentrieren und sich weniger darum kümmern, wie Ihre Dienste miteinander kommunizieren, solange sie sich innerhalb dieser Vertrauensgrenze befinden.

Gegenmaßnahmen

Um diese Probleme mit den Vertrauensgrenzen abzuschwächen, müssen Sie sich die verschiedenen Boxen vorstellen, in die Sie das öffentliche Internet und Ihre Infrastruktur einteilen können (siehe folgendes Diagramm). Sobald Sie das getan haben, können Sie darüber nachdenken, wie Sie Ihre Infrastruktur schützen können.

Die erste große Box ist das öffentliche Internet. Im öffentlichen Internet sollten Sie niemals irgendjemandem oder irgendetwas vertrauen. Tatsächlich sollten Sie alle Akteure im öffentlichen Internet als potenziell feindlich betrachten, selbst wenn es Ihre eigenen Angestellten sind, die sich per SSH auf Ihren Servern einloggen.

Die zweite große Box ist Ihre interne Infrastruktur. Dabei handelt es sich um Ihre vertrauenswürdigen Hosts. Dienste, die auf diesen Servern laufen, sollten nach Möglichkeit nur auf privaten Netzwerkschnittstellen lauschen und nicht direkt dem öffentlichen Internet ausgesetzt sein.

Die zwei Boxen, die sich über beide erstrecken, sind Ihr Jump Host und Ihre API-Hosts. Diese Hosts sollten sowohl auf das öffentliche Internet als auch auf Ihre interne Infrastruktur zugreifen können. Da sie direkt dem öffentlichen Internet ausgesetzt sind, sollten sie gehärtet werden und nur das absolute Minimum an Diensten ausführen, die zur Erfüllung ihrer Aufgaben erforderlich sind.

Obwohl wir nicht erwarten können, dass ein Dienst völlig fehlerfrei ist, können wir einschränken, in welchem Ausmaß Angreifer Ihre Infrastruktur kompromittieren können, falls sie Ihren Dienst ausnutzen. Daher empfehlen wir, Dienste, die eingehende Anfragen entgegennehmen, zu isolieren und auf eigenen dedizierten Servern auszuführen.

Dies erreichen Sie, indem Sie eingehende Anfragen in zwei Teile aufteilen: das Load Balancing und die Transport Layer Security (TLS)-Terminierung eingehender Anfragen sowie die eigentliche Verarbeitung der Anfrage durch Ihren Dienst. Beide sollten zumindest eigene Prozesse sein, wenn sie nicht gar auf verschiedenen Servern laufen, wobei das Load Balancing und die TLS-Terminierung an der Grenze zwischen nicht vertrauenswürdigen und vertrauenswürdigen Netzwerken erfolgen. Dieser Abschnitt konzentriert sich auf das Load Balancing und die Terminierung (die Anwendungshärtung wurde bereits in einem vorherigen Abschnitt behandelt).

Wenn Sie Load Balancing und TLS-Terminierung von Ihrer Anwendung trennen, verringern Sie die Wahrscheinlichkeit, dass ein Fehler in Ihrem Load Balancer oder Ihrer TLS-Software zur Kompromittierung der gesamten Anwendung führt, in deren Arbeitsspeicher in der Regel sensible Daten geladen sind. Dies bietet Ihnen auch einen Single Point of Maintenance (und Failure) für das Einspielen von Patches, falls eine Schwachstelle gefunden wird und Sie ein Upgrade Ihrer TLS-Bibliothek vornehmen müssen, was immer häufiger erforderlich wird.

Nehmen wir beispielsweise an, Angreifer finden in Ihrem HTTP-Server oder Ihrer TLS-Software einen Remote Code Execution (RCE)-Fehler wie GHOST oder einen Fehler zum Auslesen beliebiger Speicherbereiche (wie Heartbleed). Wenn sich Ihr HTTP-Server, die TLS-Terminierung und die Anwendungslogik im selben Prozess befinden, ermöglicht ein Fehler in einem dieser Bereiche den Angreifern den Zugriff auf sensible Informationen in den anderen Komponenten. Ein Fehler in OpenSSL kann Angreifern beispielsweise Zugang zu sensiblen Schlüsseln verschaffen, die Ihre Anwendung in den Arbeitsspeicher geladen hat. Umgekehrt kann ein Fehler in Ihrer Anwendung Angreifern möglicherweise Zugang zu Ihren SSL-Zertifikaten gewähren. Wenn Sie diese Komponenten jedoch voneinander trennen, bleibt der jeweils andere Bereich bei der Kompromittierung eines Teils unberührt und Sie verlieren nur einen Teil Ihrer sensiblen Daten.

Gängige Optionen für das Load Balancing sind NGINX, HAProxy und Apache. Die TLS-Terminierung erfolgt üblicherweise mit OpenSSL; es gibt jedoch Alternativen wie LibreSSL  genannt, und Mozilla NSS . Eine weitere Alternative ist die Verwendung von Tools wie vulcand, das als Load Balancer fungiert und die Go TLS-Bibliothek für die TLS-Terminierung verwendet.

Sie können Ihren Dienst-Endpunkt stärken, indem Sie den Zugriff auf Ihre Server aus dem öffentlichen Internet einschränken und erzwingen, dass die gesamte Authentifizierung über einen Jump Host abläuft. Diese Einschränkung wird üblicherweise dadurch erreicht, dass Sie Ihre Infrastruktur nicht direkt dem öffentlichen Internet aussetzen, sondern stattdessen ein internes Netzwerk aufbauen, auf das nur über den Bastion Host zugegriffen werden kann.

Es gibt viele Möglichkeiten zum Aufbau eines internen Netzwerks, und Ihr Ansatz wird größtenteils davon abhängen, wie Ihre Infrastruktur durch Ihren Anbieter konfiguriert ist sowie von Ihren persönlichen Einstellungen.

Nehmen wir beispielsweise an, Sie hosten Ihre Server bei Amazon Web Services (AWS). Dann können Sie mit einer Virtual Private Cloud (VPC) mit einem einzelnen öffentlichen Subnetz beginnen. Ihre Server sind so von anderen Servern auf AWS isoliert und befinden sich in ihrem eigenen 10.0.0.0/16 CIDR-Block. Sie haben jedoch weiterhin uneingeschränkten Zugang zum Internet. Um den Zugriff aus dem Internet einzuschränken, erstellen Sie  Security Groups, die sowohl die offenen Ports als auch die Server isolieren, die auf diese Ports zugreifen können. Beispielsweise würden Sie Ihre Worker Hosts so konfigurieren, dass sie Verbindungen auf den Ports 22 und 80 akzeptieren – jedoch nur von Ihrem Jump Host bzw. Ihrem Load Balancer. Ihr Jump Server hingegen würde Verbindungen auf Port 22 von jedem beliebigen Server im öffentlichen Internet akzeptieren.

Wenn Ihr Anbieter diese Tools nicht bereitstellt, können Sie dasselbe Ergebnis erzielen, solange dieser eine Art privates Netzwerk (entweder gemeinsam genutzt oder dediziert) anbietet, mit dem Sie öffentlichen und privaten Datenverkehr isolieren können. Diese Funktion wird in der Regel von den meisten Anbietern angeboten: Wie bereits erwähnt, nennt Amazon sie VPC, bei Rackspace heißt sie ServiceNet und bei Digital Ocean lautet der Name Private Networking. Alle bieten im Grunde dieselbe Möglichkeit: Wenn Sie Ihren virtuellen Server erstellen, können Sie ihn an die öffentliche Schnittstelle, die private Schnittstelle oder an beide binden. Wenn Ihr Anbieter bei der Erstellung nicht über diese Möglichkeit verfügt, können Sie diese Schnittstellen selbst aktivieren und deaktivieren: in der Datei /etc/network/interfaces auf einem Debian-basierten System und in der Datei /etc/sysconfig/network-scripts/ifcfg* auf einem Red Hat-basierten System.

Sobald Sie über Server mit öffentlichen und privaten Schnittstellen verfügen, verwenden Sie iptables, um eingehenden Datenverkehr auf öffentlich zugänglichen Schnittstellen auf die Server zu beschränken, die entweder als Jump Hosts fungieren oder die öffentlich zugängliche API ausführen. Auf Servern, die sämtliche interne Dienste wie Ihre Anwendung und Ihren Datenbankserver verarbeiten, wird jeglicher eingehende Datenverkehr auf öffentlichen Schnittstellen blockiert. Der eingehende Datenverkehr auf privaten Schnittstellen wird auf die vertrauenswürdige Gruppe von Servern beschränkt.

Sobald Sie dies umgesetzt haben, besteht die einzige Möglichkeit für Angreifer, Ihre Infrastruktur vom öffentlichen Internet aus zu kompromittieren, darin, über Ihren gehärteten Bastion Host einzudringen oder Ihre API auf irgendeine Weise auszunutzen.

Verwenden Sie schließlich für den Zugriff auf diese Server nicht ssh-agent, sondern greifen Sie auf ProxyCommand zurück. Obwohl ssh-agent seine Daseinsberechtigung hat, ist dieses Tool für diesen speziellen Anwendungsfall nicht gut geeignet. Falls Sie dies nutzen, könnte jede Person, die über einen Exploit für eine lokale Privilegien-Eskalation für Ihren Bastion-Server verfügt, auf jeden Server Ihrer Infrastruktur zugreifen. Dazu wird die Identität der Personen angenommen, deren Schlüssel derzeit durch ssh-agent in den Arbeitsspeicher geladen sind. Im Gegensatz dazu bleiben Ihre Schlüssel bei ProxyCommand nicht im Arbeitsspeicher, wo sie gestohlen werden könnten. Ihr privater Schlüssel verbleibt ausschließlich auf Ihrer lokalen Workstation; nur Ihr öffentlicher Schlüssel wird auf jeden Server kopiert, auf den Sie zugreifen müssen.

Um ProxyCommand zu nutzen, kopieren Sie Ihren öffentlichen Schlüssel in ~/.ssh/authorized_hosts auf allen Servern, auf die Sie zugreifen müssen. Aktualisieren Sie dann auf Ihrer Workstation Ihre ~/.ssh/config-Datei mit den folgenden Informationen:

Diese Konfiguration ermöglicht es Ihnen, von workstation.example.com via SSH auf die privaten Schnittstellen von server1.example.com und server2.example.com zuzugreifen, indem Sie über jump.example.com „springen“, da dieser Server sowohl auf öffentliche als auch auf private Schnittstellen Zugriff hat. Um eine Verbindung herzustellen, müssen Sie lediglich ssh server1.example.com oder ssh server2.example.com eingeben.

• DO: Verwenden Sie einen Load Balancer, um Ihren HTTP-Anwendungsserver von Ihrem öffentlich zugänglichen HTTP-Server zu trennen.
• DO: Terminieren Sie TLS am Load Balancer.
• DO: Verwenden Sie einen gehärteten Jump-Host, um den Zugriff auf Ihre Infrastruktur zu kontrollieren.
• DON’T: Verwenden Sie nach Möglichkeit keinen SSH-Agenten. Dadurch sind alle Ihre Schlüssel möglicherweise gefährdet, falls jemand über einen Exploit für eine lokale Privilegien-Eskalation verfügt.
• DO: Nutzen Sie die öffentlichen und privaten Schnittstellen, die Ihr Dienstanbieter bereitstellt, um Ihre internen Dienste vom öffentlichen Internet zu isolieren.

Jede Sicherheitsmaßnahme kann und wird irgendwann umgangen werden. Da keine praxistauglichen Sicherheitsmaßnahmen absolute Garantien bieten können, sind starke Monitoring- und Protokollierungsfunktionen wichtig. Diese helfen Ihnen zu verstehen, wo und wie Ihre Systeme kompromittiert wurden. Je besser Sie verstehen, wie und was auf Ihren Systemen läuft, desto besser können Sie anomales Verhalten erkennen. So wie eine Bank Überwachungskameras installiert, obwohl sie ihre Tresore sichert, sind gute Monitoring-Tools entscheidend, um raffinierte Hacker aufzuspüren, die Ihre Sicherheitsmaßnahmen überwunden haben.

Monitoring und Protokollierung nehmen zwei Formen an. Die erste ist das Live-Monitoring, mit dem Sie jederzeit sehen können, was in Ihrem System passiert. Dies umfasst alles von offenen Netzwerk-Sockets bis hin zu aktuell ausgeführten Prozessen. Die zweite Form sind die Protokolldaten bereits durchgeführter Aktionen. Dies deckt alles ab – von der Protokollierung der Anwendungslogik bis hin zu Systemprotokollen.

In diesem Abschnitt sehen wir uns Systemprotokolle direkt auf den einzelnen Servern an. In der fortgeschrittenen Version dieses Leitfadens sprechen wir über die Protokollaggregation und Alarmierung.

Gegenmaßnahmen

Die folgenden Tools sind in den meisten UNIX-basierten Betriebssystemen enthalten. Sie sind nützlich, wenn Sie einen Sicherheitsvorfall vermuten. Es ist jedoch auch im Vorfeld von entscheidender Bedeutung, sie zu nutzen, um ihre normale Ausgabe zu verstehen.

Live-Monitoring

Im Folgenden finden Sie einige Befehle und ihre erwartete Ausgabe unter normalen Betriebsbedingungen. Diese Beispiele veranschaulichen, wie die Ausgabe auf I

who – Zeigt Ihnen an, wer im Moment angemeldet ist.

last -a – Zeigt Ihnen eine Liste der letzten angemeldeten Nutzer. Gibt den Nutzernamen, die Anmeldezeit sowie die IP-Adressen aus, von denen aus die Anmeldung erfolgte.

netstat -plntu – Zeigt Prozessnamen und die Ports an, an denen sie auf Verbindungen warten.

netstat -ap – Zeigt einen Live-Stream aller Verbindungen einschließlich hergestellter ausgehender Verbindungen an.

find / -mtime -1 -ls | head -n 20 – Listet die Top 20 Dateien auf, die innerhalb der letzten 24 Stunden geändert wurden.

faillog -a, um eine Zusammenfassung fehlgeschlagener Anmeldungen zu sehen. Dies ist auch nützlich, um die maximale Anzahl fehlgeschlagener Anmeldungen zu begrenzen, die ein Nutzer haben darf.

tcpdump -i eth1 -s 0 -A tcp port http  – Gibt den gesamten HTTP-Traffic auf der Schnittstelle eth1 aus. Dies ist nützlich, falls Sie mit netstat etwas Verdächtiges gefunden haben und der Sache auf den Grund gehen möchten. Dieser Leitfaden kann Ihnen nicht alle Details von tcpdump vermitteln, aber es gibt eine Vielzahl von Ressourcen im Internet, die Ihnen helfen, tcpdump zu verstehen.

Protokoll-Monitoring

Im Folgenden finden Sie einige allgemeine Regeln für den Umgang mit der Anwendungsprotokollierung sowie Hinweise auf wichtige Systemprotokolle.

Führen Sie Ihre Anwendungsprotokolle an einem zentralen Ort zusammen, sei es in einer einzelnen Protokolldatei oder einem Verzeichnis. Der übliche Ansatz hierfür ist die Verwendung von syslog für diese Funktion. Die Verwendung von syslog erleichtert künftig die Übermittlung der Protokolle an einen zentralen Protokollierungsserver.

Bewahren Sie Ihre Protokolle so lange auf, wie es der Speicherplatz zulässt. Die Aufbewahrung von Protokollen für bis zu 90 Tage auf der Festplatte ist durchaus sinnvoll, falls Sie über den entsprechenden Speicherplatz verfügen.

Wie beim Live-Monitoring ist es eine gute Idee, die folgenden Systemprotokolldateien regelmäßig zu überprüfen, um einen soliden Ausgangswert der erwarteten Ausgabe zu entwickeln. Mit einem solchen Ausgangswert ist es in Zukunft viel einfacher, verdächtiges Verhalten zu erkennen. Nachfolgend finden Sie eine unvollständige Liste interessanter Systemprotokolle, die Sie beobachten sollten:

• /var/log/auth.log  – Protokolle der Systemauthentifizierung.
• /var/log/syslog  – Falls Sie keine Protokolle an eine bestimmte syslog-Einrichtung senden, werden sie hier gespeichert.
• /var/log/messages – Allgemeine Systemprotokollnachrichten.
• ~/.bash_history – Liste der Bash-Befehle, die vom Nutzer ausgeführt wurden. Dieses Protokoll kann von raffinierten Angreifern leicht manipuliert oder gelöscht werden.
• /var/log/utmp und /var/log/wtmp – Diese Protokolle enthalten die aktuell angemeldeten Nutzer sowie den Verlauf aller angemeldeten Nutzer. Verwenden Sie last -f , um diese Dateien anzuzeigen.

• Eignen Sie sich einige grundlegende Befehle an, die Ihnen dabei helfen, herauszufinden, was aktuell auf Ihren Servern passiert. Zu diesen Befehlen gehören who, last, lsof, netstat, faillog und find.
• Finden Sie heraus, was Sie protokollieren müssen. Protokolle sind nutzlos, falls sie keine sicherheitskritischen Ereignisse erfassen. Überwachen Sie mindestens die folgenden Dateien: /var/log/auth.log, /var/log/syslog und /var/log/messages.
• Beginnen Sie so früh wie möglich mit der Zentralisierung Ihrer Protokolle. Die Verwendung von syslog anstelle eines benutzerdefinierten Protokollierungs-Frameworks erleichtert in Zukunft die Übermittlung der Protokolle an einen zentralen Protokollierungsserver.

Kryptografie ist ein komplexes Thema, das gesondert behandelt werden sollte. Schon kleine Versehen oder Fehler können zur vollständigen Gefährdung der Sicherheit eines Produkts führen. Deshalb wird das Mantra „Entwickeln Sie nicht Ihre eigene Kryptografie“ so oft wiederholt. Zwei gute Quellen, die Sie lesen sollten, bevor Sie mit der Kryptografie beginnen, sind Crypto101 geschrieben von Laurens Van Houtven (lvh) und die Matasano Crypto Challenges.

Dennoch erfordert die Sicherheit Ihrer Infrastruktur den Einsatz von Kryptografie, und es gibt gängige Muster, die sicher verwendet werden können. Dieser Abschnitt behandelt eines dieser Muster: wie man sensible Daten im Quellcode (oder auf der Festplatte) speichert.

Gegenmaßnahmen

Wenn Sie Anmeldedaten speichern, sei es in der Quellcodeverwaltung oder auf der Festplatte, speichern Sie diese nicht unverschlüsselt. Sie denken vielleicht, dass Ihre Passwörter sicher sind, falls Sie ein privates GitHub-Repository verwenden, aber Sie sollten sich nicht auf GitHub verlassen, um Ihre gesamte Infrastruktur vor Angreifern zu schützen. Wenn Sie Ihre Anmeldedaten verschlüsseln, können Sie Ihre Sicherheit aufrechterhalten, selbst falls GitHub kompromittiert wird.

Wenn Sie nach einem Tool oder einer Bibliothek suchen, um kleine Datenmengen zu verschlüsseln, berücksichtigen Sie die folgenden Empfehlungen:

• Verwenden Sie eine moderne symmetrische Verschlüsselung. Zwei häufig empfohlene Kandidaten sind AES und Salsa20 (NaCl).
• Falls Ihre symmetrische Verschlüsselung verschiedene Modi unterstützt, wählen Sie den Modus sorgfältig aus. Beispielsweise ist CBC ein guter Modus für die Verwendung mit AES, ECB hingegen nicht.
• Verwenden Sie einen Message Authentication Code (MAC), um sicherzustellen, dass die verschlüsselten Daten nicht manipuliert wurden. HMAC-SHA-512 oder Poly1305 sind gute Kandidaten.
• Nutzen Sie eine hochwertige Zufallsquelle, was typischerweise bedeutet, /dev/urandom zu verwenden, um Zufallszahlen für Schlüssel, Salts und Nonces zu erhalten.
• Falls die Bibliothek oder das Tool mit Passphrasen arbeitet, stellen Sie sicher, dass eine KDF verwendet wird, um die Passphrase in einen Schlüssel umzuwandeln.

Sie können selbst ein Verschlüsselungs-Tool entwickeln, aber wie bereits erwähnt, kann dies knifflig sein und wird nicht empfohlen. Falls Sie jedoch darauf bestehen, eines zu entwickeln, verwenden Sie eine Bibliothek wie NaCl oder cryptography.io , die zumindest die Kryptografie korrekt für Sie umsetzt. Es ist jedoch noch besser, ein „Rezept“ zu verwenden, das jemand genau dafür entwickelt hat, wie etwa lemma oder Fernet die beide eine einfache API bereitstellen, mit der Sie Daten auf sichere Weise verschlüsseln und entschlüsseln können.

• DON’T: Wählen Sie den Modus für Ihre symmetrische Verschlüsselung nicht zufällig aus.
• DO: Verwenden Sie eine authentifizierte symmetrische Verschlüsselung mit einem MAC.
• DO: Verwenden Sie /dev/urandom zur Erzeugung von Zufallsmaterial.
• DO: Verwenden Sie ein „Rezept“ wie oder, falls Sie können.

Obwohl Backups scheinbar nicht in dieselbe Kategorie fallen wie die anderen in diesem Leitfaden diskutierten Themen, sind sie für die Infrastruktursicherheit genauso wichtig. Backups erfüllen zwei Hauptzwecke: die Wiederherstellung im Falle eines unbeabsichtigten Hardwareausfalls und die Wiederherstellung, falls ein Angreifer Ihre Infrastruktur kompromittiert. Denken Sie daran: Im Falle einer Kompromittierung ist es besser, Ihren Server zu löschen und neu aufzusetzen, als zu versuchen, Malware zu entfernen, was für unerfahrene Nutzer schwierig bis unmöglich sein kann. Aus diesem Grund sind Backups im Falle einer Kompromittierung von entscheidender Bedeutung, um Ihre Infrastruktur in einen vertrauenswürdigen Zustand zurückzuversetzen.

Gegenmaßnahmen

Die folgenden Ansätze sind eine gute allgemeine Strategie für die Arbeit mit Backups:

• Sichern Sie Ihre Backups nicht unzureichend ab, nur weil sie für Ihren Dienst nicht unternehmenskritisch erscheinen. Angreifer haben es oft genau aus diesem Grund auf Backup-Infrastrukturen abgesehen.
• Erstellen Sie so häufig Backups, wie es für Ihre geschäftlichen Anforderungen angemessen ist. Einmal pro Tag ist sinnvoll.
• Ihre Backup-Server sollten einen eingeschränkten Zugriff aufweisen, und die vorhandenen Konten sollten andere Authentifizierungs- und Autorisierungsmechanismen verwenden als jene, die für den Rest Ihrer Infrastruktur eingesetzt werden. Beispielsweise sollten Ihre Backup-Server einen anderen SSH-Schlüssel für die Anmeldung verwenden. Wenn Sie dies tun und Ihre Hauptumgebung kompromittiert wird, verfügen Sie weiterhin über vertrauenswürdige Backups, aus denen Sie wiederherstellen können.
• Falls Sie keine eigene Backup-Infrastruktur betreiben möchten, sichern Sie Ihre Daten in einem Datenspeicher eines Drittanbieters wie Amazon S3. Beachten Sie dabei: Wenn Sie den Dienst eines Drittanbieters nutzen, verschlüsseln Sie Ihre Backups, bevor Sie Ihre Daten dorthin senden. Gehen Sie davon aus, dass es sich bei Ihrem Datenspeicher um einen öffentlichen Datenspeicher handelt, und verwenden Sie Verschlüsselung, um Ihre Daten zu schützen. Mit dieser Herangehensweise sind Ihre Daten selbst bei einer Kompromittierung Ihres Hosts sicher.
• Falls Sie Amazon S3 oder Rackspace CloudFiles verwenden, nutzen Sie ein authentifiziertes Verschlüsselungsrezept wie lemma oder Fernet. Falls Sie sich keine Gedanken über die Kryptografie machen möchten, verwenden Sie einen Dienst, der Ihre Daten auf dem Client verschlüsselt und nur verschlüsselte Blobs an seinen Dienst sendet, wie Tarsnap.
• Sichern Sie Ihre Quellcode-Repositories, jegliche Drittanbieter-Software, die Ihre Anwendung verwendet, sowie Ihre Datenbank. Das jüngste Beispiel von FoundationDB verdeutlicht, wie wichtig es ist, ein Backup jeder von Ihnen verwendeten Software zu erstellen. Das Entwicklungsteam kann Software-Downloads jederzeit und aus beliebigem Grund zurückziehen.
• Obwohl verteilte Versionskontrollsysteme (DVCSs) wie Git eine gewisse Redundanz bieten, ersetzen sie keine echten Backups. Sie sollten sich nicht darauf verlassen müssen, dass sich ein bestimmter Branch auf der Workstation eines Teammitglieds befindet, um den Geschäftsbetrieb aufrechtzuerhalten.
• Führen Sie ein Backup Ihrer Datenbank mit der Methode durch, die von der Datenbank vorgegeben wird.
• Führen Sie ebenso häufig Wiederherstellungen aus Backups durch, wie Sie selbst Backups erstellen. Backups nützen nichts, falls sie nicht verwendbar sind. Im Idealfall können Sie einige Hilfsdienste, die nicht die aktuellsten Daten benötigen, über Ihre wiederhergestellten Backups laufen lassen. Auf diese Weise wissen Sie sofort Bescheid, falls etwas schiefgeht.
• Stellen Sie sicher, dass mehrere Personen in Ihrem Team in der Lage sind, Backups wiederherzustellen. Vielleicht finden Sie heraus, wie Sie Ihre Backups wiederherstellen, vielleicht aber auch nicht. Es könnte eine Stunde oder zehn Stunden dauern. Es ist besser, jedes Quartal ein paar Stunden damit zu verbringen, Ihre Backup-Infrastruktur gemeinsam mit einem Teammitglied zu überprüfen.

• DON’T: Verwenden Sie für Backups nicht dieselben Konten wie in Ihrer Hauptumgebung.
• DO: Sichern Sie Quellcode-Repositories, Drittanbieter-Software und Datenbanken.
• DO: Versuchen Sie ebenso häufig eine Wiederherstellung aus Backups durchzuführen, wie Sie das Backup-Verfahren ausführen.
• DO: Führen Sie Hilfsdienste auf Basis wiederhergestellter Backups aus, falls möglich.
• DON’T: Schaffen Sie keinen Single Point of Failure; stellen Sie sicher, dass mehrere Personen in Ihrem Team in der Lage sind, Backups wiederherzustellen.
• DO: Verwenden Sie für Ihre Backups eine authentifizierte Verschlüsselung. Verwenden Sie ein Tool wie lemma oder Fernet, oder eine gehostete Lösung wie Tarsnap.