Bereitstellung und Disaster Recovery von Webservern

Der Betrieb eines Webservers umfasst mehr als das Ausliefern einer Seite: Du musst sein Listener-Verhalten steuern, den Verwaltungszugang absichern, Datenverkehr untersuchen und die Wiederherstellbarkeit wichtiger Daten nachweisen. Dieses Challenge-Projekt verbindet diese Aufgaben in vier Linux-Szenarien mit überprüftem Endzustand.

Du stellst Nginx auf einem eigenen Port bereit, installierst einen öffentlichen SSH-Schlüssel, prüfst lauschende Sockets, ermittelst aus einem Zugriffslog den aktivsten Client und führst einen destruktiven Wiederherstellungstest aus einem komprimierten Archiv durch. Anforderungen und Hinweise sind vorgegeben, Befehle und Prüfablauf wählst du selbst.

Was du lernen wirst

• Nginx installieren, den Standard-Listener auf Port 8080 ändern, vorgegebenen Seiteninhalt bereitstellen und den Dienst neu starten
• Ein RSA-SSH-Schlüsselpaar erzeugen, den öffentlichen Schlüssel autorisieren und die SSH-Pfade mit 700 und 600 absichern
• Lauschende TCP-Sockets numerisch auflisten und bestätigen, dass SSH-Port 22 erreichbar ist
• Eine Shell-Textpipeline erstellen, die Anfragen nach Quell-IP zählt und den aktivsten Client extrahiert
• /var/www/html und /var/log/nginx gemeinsam in ein gzip-komprimiertes tar-Archiv aufnehmen und dessen Inhalt prüfen
• Den Verlust des Web-Roots simulieren, das Archiv unter / extrahieren und die Rückkehr des kritischen Inhalts bestätigen

Für wen dieser Kurs geeignet ist

Dieses Projekt richtet sich an Linux- und DevOps-Lernende, die Webdienst-, SSH-, Logverarbeitungs- und Sicherungskenntnisse ohne schrittweise Befehle anwenden möchten.

Voraussetzungen: Vertrautheit mit Paket- und Dienstverwaltung, Textbearbeitung, Shell-Pipelines, SSH-Dateien, Rechten, Socket-Prüfung und tar; dies ist ein Prüfprojekt.

Lernumgebung: Ein browserbasierter Ubuntu-Host mit sudo, APT, Nginx, OpenSSH-Werkzeugen, Zsh, GNU/Linux-Standardprogrammen und vorbereiteten Web- und Logdaten; Cloud-Konto und entfernter Server sind nicht nötig.

Häufig gestellte Fragen

Deaktiviert die SSH-Challenge die Passwortanmeldung vollständig?

Nein. Sie erzeugt /home/labex/.ssh/id_rsa, hängt den öffentlichen Schlüssel an authorized_keys an und korrigiert die Rechte. sshd_config wird nicht verändert, Passwörter werden nicht deaktiviert und ein Remote-Login wird nicht getestet.

Schließe ich unerwartete Netzwerkports?

Nein. Du listest mit ss oder netstat lauschende TCP-Ports numerisch auf und bestätigst Port 22; Firewall-Änderungen und Dienststopps gehören nicht zur Aufgabe.

Wie wird der aktivste Client ermittelt?

Du analysierst das erste Feld von /var/log/nginx/access.log, gruppierst und zählst gleiche IPs, sortierst nach Häufigkeit und speicherst nur 203.0.113.42 in /home/labex/attacker_ip.txt.

Was wird im Wiederherstellungstest tatsächlich gelöscht und restauriert?

Das Archiv enthält Web-Root und Nginx-Logs, aber die Simulation löscht /var/www/html. Du extrahierst es im Dateisystem-Root und prüfst, dass index.html mit Critical Web Content wieder vorhanden ist.