Linux-Tutorial / Einen Linux-Server mit Firewalls, Benutzerkonten und Updates schützen
Der Schutz eines Linux-Servers kombiniert eingeschränkte Konten und exponierte Ports, kontrollierte Administrationsrechte, zeitgerechte Sicherheitsupdates und Wiederherstellungszugänge. Bevor die Richtlinie für den Fernzugriff verschärft wird, behalten Sie die aktuelle Sitzung und den Konsolenzugang bei und testen Sie nach jeder Änderung eine neue Verbindung.
Bevor Regeln aus der Ferne geändert werden, bestätigen Sie den SSH-Zugang und die Konsolen-Wiederherstellung. Überprüfen Sie eine neue Verbindung, bevor die ursprüngliche Sitzung geschlossen wird.
Systemkonfigurationsübungen verwenden eine herkömmliche Ubuntu 26.04 LTS oder Rocky Linux 9 VM als Referenzumgebung. Container, WSL und andere Versionen können sich in Dienst- und Paketkonfiguration unterscheiden. Bereiten Sie die Konsolenwiederherstellung vor und zeichnen Sie Ihre Versionen mit der virtuellen Maschinen-Einrichtungslektion auf.
Inventarisieren Sie die Exposition und bewahren Sie den Wiederherstellungszugang
id getent group sudo getent group wheel sudo ss -lntup systemctl --failed
Ubuntu delegiert Verwaltung üblicherweise über sudo und Rocky Linux über wheel, abhängig von der tatsächlichen sudoers-Richtlinie. Stimmen Sie die abhörenden Ports auf installierte Dienste und legitime Verwendungen ab. Nach Überprüfung der Abhängigkeiten stoppen oder deaktivieren Sie unnötige Dienste und erlauben nur den erforderlichen Datenverkehr. Cloud-Sicherheitsgruppen und die Host-Firewall sind getrennte Ebenen.
Überprüfen Sie einen echten Wiederherstellungskanal, der unabhängig von SSH ist, wie beispielsweise eine VM-Konsole. Dokumentieren Sie den Firewall-Zustand, die SSH-Konfiguration und die Benutzerkontenrichtlinie und sichern Sie Konfigurationsdateien. Eine vorhandene Sitzung, die noch offen ist, beweist nicht, dass neue Anmeldungen weiterhin erlaubt sind.
Überprüfen Sie den Schlüsselzugang, bevor Sie die SSH-Richtlinie ändern
Testen Sie die Schlüssel-Authentifizierung und sudo mit einer frischen Sitzung unter einem normalen Administratorkonto. Bevor Sie Passwörter einschränken, prüfen Sie Include-Dateien, Match-Blöcke und Bereitstellungseinstellungen. Wiederholtes Anhängen von Direktiven kann dazu führen, dass das wirksame Verhalten von dem abweicht, was Sie beabsichtigt haben.
sudo /usr/sbin/sshd -t sudo /usr/sbin/sshd -T | grep -E "^(port|permitrootlogin|passwordauthentication|pubkeyauthentication) "
sshd -t überprüft die Konfiguration und die Gültigkeit der Schlüssel, während -T die wirksamen Einstellungen anzeigt. Bei Match-Bedingungen evaluieren Sie die relevante Verbindung auch mit -C. Laden Sie den richtigen Dienst erst nach der Validierung neu und testen Sie dann eine neue Anmeldung. Wenn sie fehlschlägt, stellen Sie die Sicherung über die beibehaltene Sitzung oder Konsole wieder her und validieren Sie erneut.
Erlauben Sie den geprüften Verwaltungspfad, bevor Sie UFW aktivieren.
Dieses Beispiel geht davon aus, dass der Laborserver tatsächlich TCP-Port 22 für SSH verwendet; ersetzen Sie ihn konsequent, wenn der Port abweicht. Eine Einschränkung der Verwaltung nach Quelle kann sinnvoll sein, aber eine falsche NAT- oder VPN-Ausgangsadresse kann den Zugriff blockieren. Überprüfen Sie den Zustand und fügen Sie die erforderliche Zulassungsregel hinzu, bevor Sie die Firewall aktivieren.
sudo ufw status verbose sudo ufw --dry-run allow 22/tcp sudo ufw allow 22/tcp sudo ufw enable sudo ufw status numbered
Diese Regel erlaubt 22/tcp von allen Quellen und ist keine vollständige, auf das Internet ausgerichtete Zugriffspolitik. Testen Sie eine neue Verbindung, fügen Sie jede engere Quellregel hinzu und testen Sie diese, und entfernen Sie eine breitere Regel erst, wenn die Ersatzregel funktioniert. Verwenden Sie die aktuelle nummerierte Liste und den aufgezeichneten Originalzustand, um genau die beabsichtigte Regel zu entfernen.
Unterscheiden Sie zwischen firewalld-Zonen, Laufzeit und Persistenz
sudo firewall-cmd --state sudo firewall-cmd --get-active-zones sudo firewall-cmd --get-default-zone
Identifizieren Sie die Zone, die der aktuellen Schnittstelle zugewiesen ist. Ersetzen Sie unten REPLACE_WITH_ACTIVE_ZONE und prüfen Sie --info-service=ssh, um zu bestätigen, dass sie mit dem SSH-Port übereinstimmt. Testen Sie zuerst die Laufzeitänderung und speichern Sie dann nur diese beabsichtigte Regel dauerhaft.
zone=REPLACE_WITH_ACTIVE_ZONE sudo firewall-cmd --info-service=ssh sudo firewall-cmd --zone="$zone" --add-service=ssh sudo firewall-cmd --zone="$zone" --list-all sudo firewall-cmd --permanent --zone="$zone" --add-service=ssh sudo firewall-cmd --permanent --zone="$zone" --list-all
Runtime- und permanente Zustände unterscheiden sich: Ein Neuladen kann nicht gespeicherte Laufzeitänderungen verwerfen. Das Kopieren des gesamten Laufzeitzustands in den permanenten Zustand kann temporäre Zugaben unbeabsichtigt beibehalten. Rollen Sie nur die Regeln zurück, die in dieser Übung neu hinzugefügt wurden, in beiden Zuständen, wo zutreffend, und erhalten Sie den Verwaltungszugang, bis eine Alternative überprüft wurde.
Führen Sie Updates durch, ohne SELinux zu umgehen
sudo apt update apt list --upgradable
sudo dnf check-update getenforce
Verwenden Sie den ersten Block auf Ubuntu und den zweiten auf Rocky Linux. Ein dnf check-update-Status von 100 kann bedeuten, dass Updates verfügbar sind, anstatt eines generischen Fehlers. Wenden Sie Updates nach Überprüfung von Backups, Dienstbeeinträchtigungen und Neustartanforderungen an und überprüfen Sie dann die tatsächlichen Serviceantworten und das Verhalten nach dem Neustart.
Unter Rocky Linux steuert SELinux den Zugriff durch Labels und Prozessrichtlinien. Wenn ein Webdienst eine Datei nicht lesen kann, überprüfen Sie Berechtigungen, Labels und Audit-Daten, anstatt die Durchsetzung zu deaktivieren. Nicht standardmäßige Pfade benötigen möglicherweise dauerhafte Kennzeichnungsregeln und restorecon. SELinux- und Firewall-Filterung lösen unterschiedliche Probleme.
