Die erste Stunde: eine kleinere Angriffsfläche.

Zugang prüfen und erhalten

Bestätigen Sie die Serveridentität über einen vertrauenswürdigen Kanal und fügen Sie Ihren öffentlichen SSH-Schlüssel hinzu. Erstellen Sie einen benannten administrativen Benutzer. Lassen Sie die ursprüngliche Sitzung geöffnet, während Sie die neue testen, und dokumentieren Sie die Wiederherstellungsmethode, bevor Sie die Authentifizierung ändern.

Patchen und Exposition reduzieren

Installieren Sie unterstützte Sicherheitsupdates und starten Sie bei Bedarf neu. Prüfen Sie lauschende Dienste und erlauben Sie in der Firewall nur die notwendigen Ports, einschließlich IPv6. Entfernen Sie ungenutzte Daemons und vermeiden Sie es, eine Datenbank nur zur einfacheren Einrichtung öffentlich zu öffnen.

Benutzer und Geheimnisse trennen

Führen Sie Anwendungen unter eigenen Konten aus. Legen Sie private Konfiguration außerhalb des öffentlichen Webverzeichnisses ab und schließen Sie sie aus der Versionskontrolle aus. Verwenden Sie enge Datenbankberechtigungen und getrennte Anmeldedaten für Produktion und Experimente.

Halten Sie einen funktionierenden Wiederherstellungspfad bereit

Richten Sie Protokollrotation, Datenträgerwarnungen und eine separate Sicherung ein. Starten Sie einmal neu, um zu prüfen, ob die Anwendung korrekt startet. Dokumentieren Sie die Änderungen, damit die Konfiguration auf einem sauberen Image neu aufgebaut werden kann.

Prüfen Sie vor dem Schließen der Sitzung

Öffnen Sie eine zweite Verbindung mit dem neuen Konto, prüfen Sie die administrative Erhöhung und testen Sie die Firewall von einem anderen Client. Bestätigen Sie, dass der Dienst nach einem Neustart wieder verfügbar ist. Dokumentieren Sie den Wiederherstellungsweg des Anbieters, damit eine fehlerhafte Netzwerkregel keine improvisierte Wiederherstellung erfordert.

Eine Verifizierungsliste für den ersten Tag

Prüfen Sie offene Sockets, aktuelle Authentifizierungsereignisse, Update-Status, Backup-Alter und Datenträgernutzung. Stellen Sie sicher, dass private Konfiguration und Versionskontroll-Metadaten nicht über HTTP abrufbar sind. Verwenden Sie die kleinste Gruppe installierter Werkzeuge, die die tatsächliche Arbeitslast unterstützt.

ss -lntup
df -h
free -h
systemctl --failed

Zugriffsänderungen in umkehrbarer Reihenfolge vornehmen

Bestätigen Sie zunächst den Konsolen- oder Rettungsweg und verifizieren Sie den Hostschlüssel von SSH über einen vertrauenswürdigen Anbieterkanal. Installieren Sie den öffentlichen Schlüssel für einen benannten Administrator, öffnen Sie dann eine zweite Verbindung und testen Sie die Rechteerhöhung. Validieren Sie die Syntax der SSH-Konfiguration, bevor Sie den Dienst neu laden. Übernehmen Sie Firewall-Änderungen erst, nachdem die beabsichtigte SSH-Route erlaubt ist. Deaktivieren Sie eine alte Authentifizierungsmethode erst, nachdem die Ersatzmethode aus einer frischen Sitzung funktioniert, einschließlich eines erforderlichen Zwei-Faktor-Ablaufs.

• Prüfen Sie die effektive Konfiguration und eingebundene Snippets; eine Einstellung in einer Datei ist möglicherweise nicht die endgültige Richtlinie.
• Prüfen Sie bei der Planung einer schlüsselbasierten Anmeldung sowohl die Passwortauthentifizierung als auch die keyboard-interactive-Richtlinie.
• Ein nicht standardmäßiger SSH-Port kann Hintergrundrauschen reduzieren, ersetzt jedoch keine verifizierten Schlüssel, Zugriffsbeschränkungen oder Aktualisierungen.
• Verwenden Sie den Dienstnamen und das Neuladeverfahren für Ihre Distribution. Behalten Sie die ursprüngliche Sitzung bei, bis die neue Richtlinie nachgewiesen ist.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Offizielle Dokumentation: OpenSSH: Handbuch zur Serverkonfiguration

Beweisen Sie die Firewall von außerhalb des Hosts

Betrachten Sie die Firewall des Anbieternetzes und die Gast-Firewall als getrennte Kontrollen. Testen Sie den vorgesehenen Dienst über IPv4 und IPv6 von einem anderen autorisierten Rechner aus. Eine lokale Verbindung beweist nur, dass ein Prozess lauscht. Blockieren Sie nicht blind jedes ICMP-Paket: Der normale Netzwerkbetrieb benötigt auch geeigneten Kontrollverkehr. Prüfen Sie veröffentlichte Container-Ports gegen die tatsächlichen Regeln, denn die Anwendungsexposition entspricht möglicherweise nicht der Richtlinie, von der Sie annahmen, dass eine Firewall-Frontend sie anwendet.

• Wenn SSH fehlschlägt, prüfen Sie Quelladress-Beschränkungen, die lauschende Schnittstelle und die Provider-Firewall, bevor Sie wiederholt Schlüssel ändern.
• Wenn HTTPS fehlschlägt, prüfen Sie in dieser Reihenfolge DNS, den Prozess-Listener und die lokale/Proxy-Firewall.
• Prüfen Sie vor dem ersten Produktionsdatensatz den Aktualisierungsstatus, einen sauberen Neustart, Datenträgerwarnungen und eine unabhängig wiederherstellbare Sicherung.
• Legen Sie eine dokumentierte Zeitzone fest und prüfen Sie die Zeitsynchronisation. Fügen Sie keine willkürlichen Swap- oder Logging-Einstellungen hinzu, ohne den Speicher- und Aufbewahrungsbedarf der Workload zu prüfen.

Offizielle Dokumentation: Ubuntu Server: Firewall-Verwaltung