Linux-Server-Lab

Praxisleitfaden für Umschüler

Debian 13.7.0 | VirtualBox | SSH | UFW | Nginx | HTTPS | Samba | Webmin/Cockpit

Lernprinzip: verstehen → konfigurieren → testen → Fehler erzeugen → Fehler beheben → dokumentieren

0. So arbeitet ihr mit diesem Guide

Dieser Leitfaden ist als gemeinsames Praxis-Lab gedacht. Er startet bei der Virtualisierung und endet bei einem kleinen, abgesicherten Linux-Server mit Webdienst, TLS, Dateifreigabe und Administrationsoberfläche. Die Übungen sind bewusst so aufgebaut, dass Fehler sichtbar werden und anschließend systematisch behoben werden.

Wichtig: Die Firewall-Sperrübung wird ausschließlich in der lokalen VirtualBox-VM durchgeführt. Vorher einen Snapshot erstellen und die VirtualBox-Konsole geöffnet lassen. Nicht auf einem produktiven oder entfernten Server ausprobieren.

Lernziele

• VirtualBox installieren und eine geeignete Debian-Server-VM anlegen.
• Bridged, NAT und Host-only-Netz unterscheiden und sinnvoll einsetzen.
• Debian 13 ohne Desktop installieren und administrieren.
• Linux-Dateisystem, Benutzer, Gruppen, Rechte, Dienste, Ports und Logs verstehen.
• SSH vom Windows-PC aus nutzen und optional auf SSH-Schlüssel umstellen.
• UFW korrekt aktivieren und einen selbst verursachten SSH-Lockout beheben.
• Nginx installieren, eine eigene Webseite bereitstellen und per HTTP testen.
• TLS mit einem lokalen Zertifikat konfigurieren und Port 443 testen.
• Eine Samba-Freigabe bereitstellen und in Windows als Netzlaufwerk verbinden.
• Webmin und Cockpit als GUI-Verwaltung kennenlernen und kritisch vergleichen.
• Fehler mit systemctl, journalctl, ss, curl, ping und Logs eingrenzen.

Empfohlener Ablauf

1. Downloads und Vorbereitung

Bestätigt am 29.09.2026: Debian bietet Debian 13 "trixie" als amd64-netinst in Version 13.7.0 an. Oracle stellt VirtualBox 7.2.20 für Windows bereit. Für dieses Lab werden keine Guest Additions benötigt.

1.1 Debian 13.7.0 netinst

Direktlink ISO: debian-13.7.0-amd64-netinst.iso

Offizielle Downloadseite: https://www.debian.org/download

Optional: Prüft die ISO-Prüfsumme anhand der offiziellen SHA256SUMS/SHA512SUMS-Dateien. Das ist ein guter Einstieg in das Thema Integrität von Installationsmedien.

Windows PowerShell - Beispiel für SHA256:

Get-FileHash .\debian-13.7.0-amd64-netinst.iso -Algorithm SHA256

1.2 Oracle VirtualBox

Offizielle Downloadseite: https://www.virtualbox.org/wiki/Downloads

Windows-Installer 7.2.20 (Stand 29.09.2026): VirtualBox-7.2.20-175154-Win.exe

Hinweis: Das Extension Pack ist für die Übungen nicht erforderlich. Dadurch bleibt das Lab einfacher und ihr vermeidet unnötige Zusatzkomponenten.

1.3 Voraussetzungen am Windows-PC

• Hardware-Virtualisierung (Intel VT-x/AMD-V) im BIOS/UEFI aktiviert.

• Mindestens 4 GB freier RAM für die VM; komfortabler sind 8 GB oder mehr auf dem Host.

• Mindestens 30 GB freier Speicherplatz für die virtuelle Festplatte und Snapshots.

• Lokale Administratorrechte für VirtualBox-Installation und Host-only-Netzwerkadapter.

• Windows PowerShell oder Windows Terminal für SSH- und Porttests.

2. VirtualBox installieren und Lab-Netz aufbauen

2.1 VirtualBox unter Windows installieren

1. VirtualBox-Installer als Administrator starten.

2. Standardkomponenten können für dieses Lab beibehalten werden.

3. Die Warnung zur kurzzeitigen Netzwerkunterbrechung bestätigen. VirtualBox installiert virtuelle Netzwerkadapter.

4. VirtualBox starten und unter Datei → Werkzeuge → Netzwerk den Network Manager öffnen.

2.2 Warum zwei Netzwerkadapter?

Für eure Umgebung verwenden wir Adapter 1 im Bridged-Modus. Dadurch hängt die VM wie ein eigener Rechner am realen LAN und nutzt dessen Router/DHCP für Internetzugang, DNS und Default-Gateway. Adapter 2 bleibt Host-only und liefert die feste Lab-Adresse 192.168.56.10 für alle Übungen vom Windows-PC aus.

Einordnung: Bridged ist nicht grundsätzlich erforderlich, damit VirtualBox-VMs Internet bekommen: NAT kann normalerweise ebenfalls Internet bereitstellen. In diesem Lab wird Bridged genutzt, weil es in eurer Umgebung für den Netzzugang vorgesehen ist und die VM zugleich als eigener Rechner im LAN sichtbar wird.

Sicherheit bei Bridged: Bridged bindet die Debian-VM direkt in das reale LAN ein. Bis UFW konfiguriert ist, können installierte Dienste dort auch über die Bridged-IP erreichbar sein. Nutzt dafür nur ein vertrauenswürdiges Schul-/Lab-Netz und verwendet für die Übungen weiterhin die Host-only-IP 192.168.56.10.

Lab-Adressplan: Windows-Host: 192.168.56.1/24 | Debian-Server Host-only: 192.168.56.10/24 | Auf Host-only kein Gateway. Default-Gateway und DNS kommen über den Bridged-Adapter aus dem realen LAN.

2.3 Bridged-Adapter vorbereiten

1. VM ausgeschaltet lassen bzw. später vor der Änderung sauber herunterfahren.

2. VirtualBox → VM → Einstellungen → Netzwerk → Adapter 1 aktivieren.

3. Bei "Angeschlossen an" den Eintrag "Netzwerkbrücke / Bridged Adapter" wählen.

4. Unter "Name" den physischen Windows-Netzwerkadapter auswählen, der tatsächlich Internet hat, z. B. Ethernet oder WLAN.

5. Die Option "Kabel verbunden" aktiv lassen. Promiscuous Mode kann für dieses Lab auf "Deny" bleiben.

Prüfpunkt: Nach der Debian-Installation muss die Bridged-Schnittstelle eine Adresse aus eurem realen LAN besitzen und eine Default-Route haben. Prüft später mit ip -br addr und ip route. Falls das Schulnetz zusätzliche Geräte/MAC-Adressen blockiert, kann Bridged trotz korrekter VirtualBox-Einstellung keinen Zugang erhalten.

2.4 Host-only-Netz anlegen

1. VirtualBox → Datei → Werkzeuge → Netzwerk.

2. Host-only-Netz anlegen bzw. vorhandenes Host-only-Netz auswählen.

3. IPv4-Adresse des Host-Adapters auf 192.168.56.1 mit Maske 255.255.255.0 setzen.

4. Für diesen Guide den DHCP-Server des Host-only-Netzes deaktivieren. Die Debian-Lab-IP wird später statisch gesetzt.

Falls 192.168.56.0/24 kollidiert: Nutzt ein anderes privates /24-Netz, z. B. 192.168.77.0/24, und ersetzt die Adressen im gesamten Guide entsprechend.

3. Debian-VM erstellen

3.1 Empfohlene VM-Werte

3.2 Netzwerkadapter der VM

1. VM ausschalten, falls sie bereits läuft.

2. Einstellungen → Netzwerk → Adapter 1: Aktiviert, Angeschlossen an Netzwerkbrücke / Bridged Adapter. Als Name den physischen Windows-Adapter mit Internetzugang auswählen.

3. Adapter 2: Aktiviert, Angeschlossen an Host-only Network. Das zuvor angelegte Netz auswählen.

4. Bei beiden Adaptern "Kabel verbunden" aktiv lassen.

Wichtig bei Bridged: Adapter 1 ist Teil des realen LANs und dient in diesem Lab für Internetzugang, DNS und Default-Gateway. Adapter 2 bleibt das kontrollierte Übungsnetz. SSH, Webserver, Samba und Web-GUIs testet ihr vom Windows-Host über 192.168.56.10, nicht über die Bridged-IP.

3.3 Snapshots als Lern-Rückfallebene

1. VM in einen sauberen Zustand bringen und wichtige Schreibvorgänge beenden.

2. In VirtualBox die VM auswählen und den Bereich Snapshots öffnen.

3. Snapshot mit sprechendem Namen anlegen, z. B. 00-clean oder 01-before-firewall.

4. Vor riskanten Übungen einen neuen Snapshot setzen. Bei Bedarf kann der vorherige Zustand wiederhergestellt werden.

Wichtig: Snapshots sind sehr praktisch für ein Lern-Lab, aber kein unabhängiges Backup. Sie liegen zusammen mit der VM und schützen nicht vor Verlust der gesamten VM-Dateien.

4. Debian 13 installieren

4.1 Installer

1. VM starten und "Graphical install" oder "Install" wählen.

2. Sprache, Standort und Tastaturbelegung auswählen.

3. Als Hostname z. B. srv01 setzen.

4. Als Lab-Domain lab.test verwenden. Die TLD .test ist für Tests vorgesehen und kollidiert nicht mit einer echten öffentlichen Domain.

5. Beim Root-Passwort beide Felder leer lassen. Debian deaktiviert dann den direkten Root-Login und richtet sudo für den ersten Benutzer ein.

6. Ersten Benutzer anlegen, z. B. admin oder den eigenen Vornamen.

7. Geführte Partitionierung → gesamte virtuelle Festplatte → alle Dateien auf eine Partition. Für das Einstiegslab reicht das.

8. Wenn der Installer nach der primären Netzwerkschnittstelle fragt, die Bridged-Schnittstelle wählen. Sie soll per DHCP eine Adresse aus dem realen LAN beziehen und während der Installation Internetzugang liefern.

9. Debian-Spiegelserver auswählen und Installation fortsetzen.

4.2 Softwareauswahl

Bei tasksel sollt ihr bewusst einen schlanken Server bauen:

• Debian desktop environment: AUS
• GNOME/KDE/Xfce usw.: AUS
• Web server: AUS (Nginx wird später bewusst manuell installiert)
• SSH server: EIN
• standard system utilities: EIN

Bestätigt: Die Debian-Installationsanleitung empfiehlt die Standard-Systemwerkzeuge beizubehalten; die SSH-Server-Aufgabe installiert OpenSSH. Wenn kein Root-Passwort gesetzt wird, erhält der erste Benutzer sudo-Rechte.

4.3 Nach dem ersten Boot

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y curl wget vim nano tree htop lsof dnsutils net-tools openssl rsync tcpdump ufw
sudo reboot

Snapshot 00-clean: Nach dem Update die VM sauber herunterfahren und in VirtualBox einen Snapshot "00-clean" erstellen. Dieser Snapshot ist eure Rückfallebene.

5. Netzwerk verstehen und Host-only-IP festlegen

5.1 Interfaces und Routen prüfen

ip -br link
ip -br addr
ip route
hostname -I

Typisch sind zwei Interfaces, z. B. enp0s3 (Bridged) und enp0s8 (Host-only). Die Namen können abweichen. Die Bridged-Schnittstelle erhält normalerweise per DHCP eine Adresse aus dem realen LAN; die Host-only-Schnittstelle bekommt gleich die feste Lab-IP. Niemals Interface-Namen aus dem Guide blind übernehmen.

5.2 Statische Adresse für Host-only

Bei einer typischen minimalen Debian-Installation wird ifupdown über /etc/network/interfaces verwendet. Prüft zuerst den vorhandenen Inhalt:

cat /etc/network/interfaces

Ergänzt nur die Host-only-Schnittstelle. Beispiel, wenn sie enp0s8 heißt:

sudo nano /etc/network/interfaces

# vorhandene Eintraege nicht unnoetig loeschen
auto enp0s8
iface enp0s8 inet static
    address 192.168.56.10/24

Kein Gateway: Auf enp0s8 wird absichtlich kein Gateway gesetzt. Sonst könnten zwei konkurrierende Default-Routen entstehen. Der Internetweg, DNS und das Default-Gateway bleiben über den Bridged-Adapter.

Danach am besten über die VirtualBox-Konsole neu starten:

sudo reboot

Nach dem Boot:

ip -br addr
ip route
ping -c 3 192.168.56.1
ping -c 3 debian.org

6. Linux-Grundlagen: die Werkzeuge, die ihr ständig braucht

6.1 Mini-Übung: Dateien und Rechte

mkdir -p ~/linuxlab/test
cd ~/linuxlab/test
echo "Hallo Linux" > hallo.txt
ls -l
cat hallo.txt
cp hallo.txt kopie.txt
mv kopie.txt umbenannt.txt
ls -lah

Prüft anschließend mit stat hallo.txt, wem die Datei gehört und welche Rechte gesetzt sind.

7. SSH vom Windows-PC

7.1 Server prüfen

sudo systemctl status ssh --no-pager
sudo ss -tlnp | grep :22

7.2 Windows-Test

PowerShell:

Test-NetConnection 192.168.56.10 -Port 22
ssh admin@192.168.56.10

Beim ersten Verbindungsaufbau wird der Host-Key-Fingerprint angezeigt. Das ist kein Fehler. In echten Umgebungen sollte dieser Fingerprint über einen zweiten vertrauenswürdigen Kanal geprüft werden.

7.3 Optional: SSH-Schlüssel

Windows PowerShell:

ssh-keygen -t ed25519

Den Inhalt der öffentlichen Datei id_ed25519.pub anzeigen und auf den Debian-Server in ~/.ssh/authorized_keys übernehmen:

Debian:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Regel: Passwort-Login erst dann abschalten, wenn ein zweites Terminal den Schlüssel-Login erfolgreich getestet hat.

7.4 Optionales SSH-Hardening

sudo nano /etc/ssh/sshd_config.d/10-lab-hardening.conf
PermitRootLogin no
PasswordAuthentication no
sudo sshd -t
sudo systemctl reload ssh

Ein geänderter SSH-Port ersetzt keine echte Absicherung. Schlüssel, Rechte, Firewall, Updates und Logs sind wichtiger.

8. UFW-Firewall: erst planen, dann einschalten

Debian nutzt nftables als modernes Firewall-Framework. UFW ist in Debian 13 verfügbar und bietet eine einfachere Oberfläche für typische Host-Firewall-Regeln. Im Lab verwenden wir UFW, um das Verhalten von Ports gut sichtbar zu machen.

Snapshot 01-before-firewall: Vor der Lockout-Übung Snapshot erstellen und die VirtualBox-Konsole offen lassen.

8.1 Sichere Grundkonfiguration

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.56.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Von Windows erneut prüfen:

Test-NetConnection 192.168.56.10 -Port 22
ssh admin@192.168.56.10

8.2 Geplanter Fehler: Port 22 vergessen

Nur im Lab: Die folgenden Schritte an der VirtualBox-Konsole ausführen, nicht über SSH. Ziel ist zu sehen, wie leicht man sich selbst aussperrt.

1. Snapshot vorhanden und VirtualBox-Konsole geöffnet? Erst dann weiter.

2. UFW zurücksetzen und eingehenden Verkehr standardmäßig blockieren.

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

3. In einem NEUEN Windows-Terminal eine SSH-Verbindung versuchen. Sie sollte scheitern bzw. timeouten.

Test-NetConnection 192.168.56.10 -Port 22
ssh admin@192.168.56.10

4. An der VirtualBox-Konsole den Fehler beheben:

sudo ufw allow from 192.168.56.0/24 to any port 22 proto tcp
sudo ufw status numbered

5. Erneut von Windows testen. SSH muss wieder funktionieren.

Lerneffekt: Eine bestehende SSH-Sitzung kann je nach Zustand der Verbindung weiter funktionieren. Für den Lockout-Test deshalb immer eine neue Verbindung öffnen. Auf echten Remote-Servern benötigt man vor Firewall-Änderungen einen Rückfallweg, z. B. Provider-Konsole, iDRAC/iLO/IPMI oder lokale Konsole.

8.3 Regeln bearbeiten

sudo ufw status numbered
sudo ufw delete 3
sudo ufw status verbose

9. Nginx-Webserver: HTTP auf Port 80

9.1 Installation und Dienst

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx
systemctl status nginx --no-pager
sudo ss -tlnp | grep :80

9.2 Firewall für HTTP

sudo ufw allow from 192.168.56.0/24 to any port 80 proto tcp
sudo ufw status numbered

9.3 Eigene Seite erstellen

sudo mkdir -p /var/www/labsite
sudo nano /var/www/labsite/index.html
<!doctype html>
<html lang="de">
<head><meta charset="utf-8"><title>Linux Lab</title></head>
<body>
  <h1>srv01 ist online</h1>
  <p>Debian + Nginx funktionieren.</p>
</body>
</html>

9.4 Server Block

sudo nano /etc/nginx/sites-available/labsite
server {
    listen 80;
    listen [::]:80;
    server_name srv01.lab.test 192.168.56.10;
    root /var/www/labsite;
    index index.html;
    access_log /var/log/nginx/labsite_access.log;
    error_log  /var/log/nginx/labsite_error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}
sudo ln -s /etc/nginx/sites-available/labsite /etc/nginx/sites-enabled/labsite
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

9.5 Namensauflösung auf Windows

Die Datei C:\Windows\System32\drivers\etc\hosts als Administrator bearbeiten und ergänzen:

192.168.56.10    srv01.lab.test

Tests:

Windows PowerShell:

Test-NetConnection srv01.lab.test -Port 80
curl.exe http://srv01.lab.test/

Checkpoint: Im Browser muss http://srv01.lab.test die selbst erstellte Seite anzeigen. Erst danach mit HTTPS weitermachen.

10. HTTPS/TLS auf Port 443

Let's Encrypt unterstützt seit 2026 auch öffentlich validierbare IP-Adress-Zertifikate, diese sind jedoch kurzlebig und erfordern eine ACME-Validierung der IP. Eine private RFC1918-Adresse wie 192.168.56.10 im isolierten Host-only-Netz ist dafür nicht öffentlich validierbar. Deshalb erzeugen wir im lokalen Lab ein selbst signiertes Zertifikat. Die Verbindung ist verschlüsselt, der Browser vertraut der ausstellenden Stelle aber nicht - die Warnung ist im Lab erwartbar.

10.1 Zertifikat erzeugen

sudo mkdir -p /etc/nginx/tls
sudo openssl req -x509 -nodes -newkey rsa:2048 -days 365 \
  -keyout /etc/nginx/tls/lab.key \
  -out /etc/nginx/tls/lab.crt \
  -subj "/C=DE/O=Linux-Lab/CN=srv01.lab.test" \
  -addext "subjectAltName=DNS:srv01.lab.test,IP:192.168.56.10"
sudo chmod 600 /etc/nginx/tls/lab.key

10.2 Nginx auf HTTPS umstellen

sudo nano /etc/nginx/sites-available/labsite
server {
    listen 80;
    listen [::]:80;
    server_name srv01.lab.test 192.168.56.10;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name srv01.lab.test 192.168.56.10;
    root /var/www/labsite;
    index index.html;
    ssl_certificate     /etc/nginx/tls/lab.crt;
    ssl_certificate_key /etc/nginx/tls/lab.key;
    access_log /var/log/nginx/labsite_access.log;
    error_log  /var/log/nginx/labsite_error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}
sudo nginx -t
sudo systemctl reload nginx
sudo ufw allow from 192.168.56.0/24 to any port 443 proto tcp
sudo ss -tlnp | grep -E ":80|:443"

10.3 HTTPS testen

Windows PowerShell:

Test-NetConnection srv01.lab.test -Port 443
curl.exe -kI https://srv01.lab.test/

Debian:

openssl s_client -connect 192.168.56.10:443 -servername srv01.lab.test </dev/null

Browserwarnung: Ein selbst signiertes Zertifikat ist nicht automatisch vertrauenswürdig. Die Warnung bedeutet nicht, dass Port 443 oder TLS kaputt sind. Im Lab sollt ihr den Unterschied zwischen Verschlüsselung und Vertrauen bewusst sehen.

10.4 Optional: echtes Let's-Encrypt-Zertifikat

Für ein öffentlich vertrauenswürdiges Zertifikat benötigt ihr eine von Let's Encrypt validierbare öffentliche Identität: typischerweise einen Domainnamen oder seit 2026 auch eine öffentliche IPv4/IPv6-Adresse. IP-Zertifikate von Let's Encrypt sind kurzlebig. Das lokale Host-only-Lab mit 192.168.56.10 bleibt absichtlich nicht öffentlich erreichbar. Wenn ihr später auf einem echten Test-VPS arbeitet, verwendet die jeweils aktuellen Certbot- und Let's-Encrypt-Anweisungen.

Aktuelle Certbot-Anleitung: https://certbot.eff.org/instructions

11. Samba: Linux-Freigabe in Windows verbinden

11.1 Installation

sudo apt update
sudo apt install -y samba smbclient
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

11.2 Benutzer, Gruppe und Verzeichnis

sudo groupadd -f sambateam
sudo adduser labuser
sudo usermod -aG sambateam labuser
sudo install -d -m 2770 -o root -g sambateam /srv/samba/team
sudo smbpasswd -a labuser

Das Setgid-Bit (2 in 2770) sorgt dafür, dass neu angelegte Dateien/Ordner die Gruppe des Verzeichnisses erben. Das ist ein guter Anlass, Unix-Rechte praktisch zu besprechen.

11.3 Share konfigurieren

sudo nano /etc/samba/smb.conf

# am Dateiende ergaenzen
[team]
    path = /srv/samba/team
    browseable = yes
    read only = no
    valid users = @sambateam
    force group = sambateam
    create mask = 0660
    directory mask = 2770
sudo testparm
sudo systemctl restart smbd
systemctl status smbd --no-pager
sudo ss -tlnp | grep -E ":445|:139"

11.4 Firewall nur fürs Lab-Netz

sudo ufw allow from 192.168.56.0/24 to any port 445 proto tcp
sudo ufw status numbered

Für die direkte moderne SMB-Verbindung über \\Server\Freigabe reicht im Lab TCP 445. Zusätzliche NetBIOS-Ports sind für diese direkte Verbindung nicht notwendig.

11.5 Windows verbinden

PowerShell:

Test-NetConnection 192.168.56.10 -Port 445

Im Explorer in die Adresszeile:

\\192.168.56.10\team

Oder als Laufwerk Z: verbinden:

cmd.exe:

net use Z: \\192.168.56.10\team /user:labuser *

Trennen:

net use Z: /delete

Übung: Eine Datei unter Windows im Netzlaufwerk anlegen. Auf Debian mit ls -l /srv/samba/team prüfen, welchem Benutzer und welcher Gruppe sie gehört.

12. Web-GUIs: Webmin und Cockpit vergleichen

Eine Web-GUI kann Administration vereinfachen, ist aber kein Ersatz für das Verständnis der darunterliegenden Linux-Konfiguration. Jede zusätzliche Verwaltungsoberfläche vergrößert außerdem die Angriffsfläche.

12.1 Webmin installieren

Webmin wird über das offizielle Webmin-Repository angeboten. Der Hersteller empfiehlt die Repository-Einrichtung und anschließend die Paketinstallation. Im Unterricht sollte ein heruntergeladenes Setup-Skript nicht blind als root ausgeführt werden: erst speichern und ansehen.

cd /tmp
wget https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
less webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt update
sudo apt install -y webmin --install-recommends
sudo ufw allow from 192.168.56.0/24 to any port 10000 proto tcp
sudo ss -tlnp | grep :10000

Aufruf im Browser: https://192.168.56.10:10000

Webmin beobachten: Schaut euch Benutzer, Dienste, Festplatten, Netzwerk und Logs an. Ändert nicht wahllos Einstellungen. Prüft bei jeder GUI-Änderung anschließend die zugrunde liegende Konfigurationsdatei oder den systemd-Status.

12.2 Cockpit als Alternative aus Debian

Cockpit ist direkt als Debian-13-Paket verfügbar. Für einen möglichst schlanken Vergleich installieren wir zunächst ohne empfohlene Zusatzmodule. So vermeiden wir, dass für dieses Lab unnötig weitere Verwaltungs- oder Netzwerkkomponenten nachgezogen werden. Vorher einen Snapshot erstellen.

sudo apt install -y --no-install-recommends cockpit
sudo systemctl enable --now cockpit.socket
sudo ufw allow from 192.168.56.0/24 to any port 9090 proto tcp
sudo ss -tlnp | grep :9090

Aufruf: https://192.168.56.10:9090

12.3 Diskussionsfragen

• Was ist schneller: GUI oder CLI? Was ist nachvollziehbarer?

• Welche zusätzlichen Ports und Dienste entstehen durch eine Web-GUI?

• Welche Oberfläche würdet ihr in einer minimalen Produktionsumgebung wirklich benötigen?

• Wie würdet ihr den Zugriff einschränken: Firewall, VPN, Management-Netz, MFA/SSO?

13. Benutzer, Gruppen und Dateirechte

id
getent group sambateam
ls -ld /srv/samba/team
namei -l /srv/samba/team

13.1 Kleine Rechte-Challenge

1. Benutzer alice und bob anlegen.

2. Gruppe projekt anlegen und beide Benutzer hinzufügen.

3. /srv/projekt so konfigurieren, dass nur Mitglieder der Gruppe lesen und schreiben dürfen.

4. Neue Dateien sollen automatisch die Gruppe projekt erben.

5. Mit sudo -u alice und sudo -u bob testen.

sudo adduser alice
sudo adduser bob
sudo groupadd projekt
sudo usermod -aG projekt alice
sudo usermod -aG projekt bob
sudo install -d -m 2770 -o root -g projekt /srv/projekt
sudo -u alice touch /srv/projekt/alice.txt
sudo -u bob touch /srv/projekt/bob.txt
ls -l /srv/projekt

14. Troubleshooting: systematisch statt raten

Bei einem nicht erreichbaren Dienst immer von unten nach oben prüfen. Die Reihenfolge spart Zeit:

14.1 Nützliche Befehle

systemctl --failed
systemctl status nginx --no-pager
journalctl -u nginx --since "15 minutes ago" --no-pager
journalctl -u ssh --since "15 minutes ago" --no-pager
sudo tail -n 50 /var/log/nginx/labsite_error.log
sudo ss -tulpn
sudo ufw status numbered
ip -br a
ip route

14.2 Netzwerkverkehr sichtbar machen

tcpdump macht die Verbindungsebene sichtbar. Ermittelt zuerst den Host-only-Interfacenamen und beobachtet dann z. B. SSH oder HTTPS:

ip -br link
sudo tcpdump -ni enp0s8 port 22
sudo tcpdump -ni enp0s8 port 443

Frage: Was seht ihr bei einem Firewall-Block? Kommen Pakete an? Gibt es Antworten? Verändert sich das Bild, wenn der Dienst gestoppt ist statt die Firewall zu blockieren?

15. Backup und Wiederherstellung im Kleinen

Ein Server ist erst dann gut administriert, wenn Änderungen rückgängig gemacht und Daten wiederhergestellt werden können. Im Lab kombinieren wir VM-Snapshots für Systemzustände mit klassischen Dateibackups.

15.1 Konfiguration sichern

sudo mkdir -p /root/lab-backup
sudo tar -czf /root/lab-backup/etc-lab-$(date +%F).tar.gz \
  /etc/nginx /etc/samba /etc/ufw

15.2 Daten mit rsync sichern

sudo mkdir -p /srv/backup/team
sudo rsync -aH --delete /srv/samba/team/ /srv/backup/team/

Diskussion: Warum ist ein Snapshot kein vollwertiger Ersatz für ein unabhängiges Backup? Was passiert, wenn die virtuelle Festplatte selbst beschädigt oder gelöscht wird?

16. Weitere sinnvolle Lab-Ideen

Wenn die Grundlagen sitzen, könnt ihr denselben Server schrittweise erweitern. Die folgenden Themen bauen fachlich gut aufeinander auf:

17. Abschlussprojekt: "Server aus dem Nichts"

Jede Gruppe erhält eine frische VM oder setzt auf Snapshot 00-clean zurück. Danach soll der Server ohne Schritt-für-Schritt-Vorgabe aufgebaut werden. Dokumentiert jede Entscheidung.

• Host-only-IP konfigurieren und Verbindung vom Windows-Host nachweisen.
• SSH erreichbar machen und Benutzerzugang testen.
• UFW mit Default-Deny für eingehenden Verkehr aktivieren.
• Nur benötigte Ports für das Host-only-Netz freigeben.
• Nginx-Webseite unter srv01.lab.test bereitstellen.
• HTTP auf HTTPS umleiten und TLS auf 443 aktivieren.
• Samba-Freigabe mit Benutzeranmeldung bereitstellen.
• Windows-Netzlaufwerk verbinden und Schreibtest durchführen.
• Mindestens eine Web-Verwaltungsoberfläche installieren oder bewusst begründet darauf verzichten.
• Mit ss, systemctl, journalctl und ufw den Endzustand dokumentieren.
• Mindestens einen Fehler absichtlich erzeugen und mit Logs/Tests diagnostizieren.

17.1 Abnahmeprotokoll

18. Schnellreferenz

Netzwerk

ip -br a
ip route
ping -c 3 HOST
ss -tulpn
curl -I http://HOST
openssl s_client -connect HOST:443 -servername NAME

Dienste und Logs

systemctl status DIENST --no-pager
systemctl restart DIENST
systemctl reload DIENST
systemctl enable --now DIENST
journalctl -u DIENST -n 50 --no-pager
systemctl --failed

UFW

sudo ufw status verbose
sudo ufw status numbered
sudo ufw allow from 192.168.56.0/24 to any port 22 proto tcp
sudo ufw delete NUMMER
sudo ufw disable
sudo ufw enable

Nginx

sudo nginx -t
sudo systemctl reload nginx
sudo tail -f /var/log/nginx/labsite_access.log
sudo tail -f /var/log/nginx/labsite_error.log

Samba

sudo testparm
sudo smbpasswd -a BENUTZER
sudo systemctl restart smbd
smbclient -L //localhost -U BENUTZER

19. Quellen und Versionshinweise

Die folgenden offiziellen bzw. primären Quellen wurden für Versions- und Funktionsangaben geprüft.

Technikstand: 29.09.2026. Paketversionen, Downloadpfade und Installationsanweisungen können sich ändern. Kann Richtigkeit nicht garantieren - bitte vor produktivem Einsatz verifizieren.

Debian Download: Debian 13 trixie, amd64 netinst 13.7.0 - https://www.debian.org/download

Debian ISO-Verzeichnis: debian-13.7.0-amd64-netinst.iso und Prüfsummen - https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

Debian Installationshandbuch: Installation, Benutzer, tasksel, SSH und Standard-Systemwerkzeuge - https://www.debian.org/releases/trixie/installmanual.de.html

VirtualBox User Manual 7.2: Bridged, NAT, Host-only Networking und Network Manager - https://download.virtualbox.org/virtualbox/7.2.20/UserManual.pdf

VirtualBox 7.2.20 Downloads: Windows-Installer und Release-Dateien - https://download.virtualbox.org/virtualbox/7.2.20/

Debian UFW Paket: UFW ist in Debian 13/trixie verfügbar - https://packages.debian.org/trixie/ufw

Debian nftables Wiki: nftables als Standard-/empfohlenes Firewall-Framework in Debian - https://wiki.debian.org/nftables

Samba smb.conf Dokumentation: Standalone-Server und Konfigurationsparameter - https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

Debian Samba Paket: Samba-Paket in Debian 13/trixie - https://packages.debian.org/trixie/samba

Webmin Download/Install: Offizielle Repository- und Debian-Installationshinweise - https://webmin.com/download/

Debian Cockpit Paket: Cockpit-Webkonsole in Debian 13/trixie - https://packages.debian.org/trixie/cockpit

Let's Encrypt IP-Zertifikate: IP-Adress-Zertifikate seit 2026 allgemein verfügbar; kurzlebiges Profil - https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability

Certbot: Aktuelle ACME/Certbot-Anweisungen - https://certbot.eff.org/instructions

Didaktischer Hinweis: Die eigentlichen Übungen laufen über das feste Host-only-Lab. Der zusätzliche Bridged-Adapter verbindet die VM jedoch mit dem realen LAN und ist deshalb nicht isoliert. UFW-Regeln werden im Guide gezielt auf das Host-only-Netz begrenzt. Wer später mit echten Servern arbeitet, muss zusätzlich Themen wie Netzsegmentierung, Backups außerhalb des Systems, Patchmanagement, Geheimnisverwaltung, Monitoring, Incident Response und Zugriffsprotokollierung berücksichtigen.