Abschlussprojekt – Die Jedi-Prüfung

Du hast navigiert. Du hast Dateien bearbeitet, Benutzer verwaltet, Rechte gesetzt, Prozesse kontrolliert, Software installiert und eine Firewall konfiguriert. Vier Phasen. Acht Module. Die Kraft fließt.

Jetzt beginnt die Jedi-Prüfung.

Im Tempel auf Coruscant musste jeder Padawan vor dem Rat beweisen, dass er kein Schüler mehr ist. Nicht durch Theorie. Nicht durch Wiederholung. Sondern durch eine echte Aufgabe in einer echten Situation – allein, unter Zeitdruck, mit Verantwortung für das Ergebnis.

Deine Aufgabe: Einen nackten RHEL 9-Server in einen produktionsbereiten, gehärteten und auditierten Webserver verwandeln. Das System läuft in einem regulierten Umfeld – Versicherungswesen, BaFin, DORA. Es muss nicht nur funktionieren. Es muss compliant sein.

„Die Prüfung zeigt dir nicht, was du kannst. Sie zeigt dir, was du bist.“

– Meister Windu, vor dem Jedi-Rat · und sinngemäß vor dem Abnahme-Gespräch

<note warning> DORA · BaFin · DSGVO – diese Regeln sind nicht verhandelbar

Die Nutzung von KI-Assistenten für Recherche und Syntaxerklärungen ist ausdrücklich erwünscht. Der Einsatz unterliegt jedoch zwingend den folgenden Regeln:

• Keine Echtdaten in KI-Prompts: Keine echten IP-Adressen, internen Hostnamen, Passwörter, Hashes oder Benutzernamen. Nutze Platzhalter wie <SERVER-IP> oder user123.
• Keine personenbezogenen Daten: Das Eintippen von Mitarbeiterdaten in externe KI-Systeme ist ein DSGVO-Verstoß – auch wenn es sich um Testdaten handelt.
• Kein blindes Copy-Paste: Du musst jede Code-Zeile im Fachgespräch erklären können. Wer das nicht kann, hat nicht gelernt – er hat kopiert. Das wird sichtbar.

KI ist dein Mentor für Syntax, nicht dein Ghostwriter. Meister Yoda hat auch nicht für Luke Skywalker trainiert. </note>

Deine Aufgaben:

1. Generiere in deinem SSH-Client ein modernes ed25519-Schlüsselpaar und richte den zertifikatsbasierten Login ein.
2. Deaktiviere den Root-Login und die passwortbasierte Authentifizierung in der SSH-Konfiguration.
3. Lege einen System-Benutzer dokuwiki an, der keine Login-Shell besitzt (/sbin/nologin). Unter diesem Account läuft später die Applikation.

# Schlüsselgenerierung (clientseitig)
ssh-keygen -t ed25519 -C "azubi-admin"
 
# SSH-Härtung – relevante Parameter in /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
 
# Service-User ohne Login anlegen
useradd --system --shell /sbin/nologin dokuwiki

<note tip> Warum ed25519? Nicht weil es der neue Hype ist – sondern weil es mathematisch nachweisbar sicherer und performanter als RSA-2048 ist, bei gleichzeitig kürzeren Schlüsseln. RSA-4096 ist regulatorisch noch akzeptabel, aber ed25519 ist der aktuelle Branchenstandard. Das wirst du im Fachgespräch begründen müssen. </note>

Deine Aufgaben:

1. Installiere httpd (Apache) und php-fpm aus den RHEL-Standard-Repositories (nur BaseOS/AppStream – keine externen Quellen).
2. Lade das aktuelle DokuWiki-Release herunter und entpacke es nach /var/www/dokuwiki.
3. Dateiberechtigungen: Der Webserver (dokuwiki-User) darf nur in data/ und conf/ schreiben. Alle anderen Dateien gehören root und sind nur lesbar.
4. Firewall: Port 80 in firewalld freigeben – permanent.
5. SELinux: SELinux bleibt im Enforcing-Modus. Konfiguriere die Kontexte (httpd_sys_rw_content_t) so, dass Apache in die DokuWiki-Datenordner schreiben darf – persistent via semanage, nicht temporär via chcon.

# Installation
dnf install -y httpd php-fpm wget tar
 
# Least Privilege Dateirechte
chown -R root:dokuwiki /var/www/dokuwiki
find /var/www/dokuwiki -type d -exec chmod 750 {} \;
find /var/www/dokuwiki -type f -exec chmod 640 {} \;
chown -R dokuwiki:dokuwiki /var/www/dokuwiki/{data,conf,lib/plugins}
 
# Firewall
firewall-cmd --permanent --add-service=http && firewall-cmd --reload
 
# SELinux – persistent (überlebt restorecon und System-Relabeling)
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/dokuwiki/data(/.*)?"
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/dokuwiki/conf(/.*)?"
restorecon -Rv /var/www/dokuwiki

<note warning> chcon vs. semanage – das ist ein Prüfungsthema:
chcon setzt den SELinux-Kontext temporär. Nach einem restorecon oder System-Relabeling ist er weg. semanage fcontext schreibt die Regel dauerhaft in die Policy. Nur semanage ist die korrekte Produktionslösung. </note>

Deine Aufgaben:

1. Audit-Skript audit.sh: Lese /etc/passwd mit awk aus und prüfe, ob ein anderer Benutzer als root die UID 0 besitzt. Alarm bei Fund.
2. Backup-Skript backup.sh: Archiviere /var/www/dokuwiki und /etc/ssh mit tar und erstelle per sha256sum einen Integritäts-Hash.
3. Systemd-Timer (kein Cron!): Führe das Backup täglich um 02:00 Uhr aus. Zwei Dateien erforderlich: .service und .timer.

# audit.sh – UID-0-Prüfung mit awk
BAD=$(awk -F: '$3 == 0 && $1 != "root" {print $1}' /etc/passwd)
[ -n "$BAD" ] && echo "ALARM: Illegale Root-Accounts: $BAD" && exit 1
echo "Audit OK." && exit 0
 
# Systemd-Timer – zwei Dateien in /etc/systemd/system/
# backup.service → Type=oneshot, ExecStart=/usr/local/bin/backup.sh
# backup.timer   → OnCalendar=*-*-* 02:00:00, Persistent=true
 
# Aktivieren:
systemctl daemon-reload
systemctl enable --now backup.timer
systemctl list-timers | grep backup

<note tip> Warum Systemd-Timer statt Cron? Weil systemd-Timer im journalctl sichtbar sind, exakt steuerbar, in den Start-Abhängigkeitsgraph integriert und auf RHEL 9 der Standard sind. Cron funktioniert – aber wer in einer DORA-Umgebung Cronjobs einrichtet, wenn Systemd-Timer verfügbar sind, muss das sehr gut begründen können. </note>

15 Minuten Präsentation (als Folien oder als Seite in deinem neuen DokuWiki):

1. Architektur: Wie sieht der Datenfluss vom SSH-Client bis zum PHP-Prozess auf dem Server aus?
2. Security Design: Warum ed25519? Wie schützt uns SELinux in diesem Setup, wenn das Wiki kompromittiert wird?
3. Troubleshooting: Was war dein größter Fehler – und wie hast du ihn anhand von journalctl oder Apache-Logs gefunden?
4. Live-Demo: Lauffähiges Wiki + manueller Start des Systemd-Timers

15 Minuten Fachgespräch – der Ausbilder stellt Rückfragen zu jedem Aspekt deiner Umsetzung. Typische Fragen:

• Erkläre den Unterschied zwischen chcon und semanage fcontext.
• Warum darf der Apache-Prozess nicht als root laufen?
• Was passiert, wenn jemand PasswordAuthentication yes wieder aktiviert?
• Wie erkennst du im Journal, dass der Backup-Timer nicht ausgeführt wurde?

← Phase IV – Paketverwaltung und Netzwerk
↑ Übersicht – Der Weg zur Macht