YunoHost Firewall Hardening & Secure Network Operations – Projektdokumentation
Diese Projektdokumentation beschreibt die Konzeption, Implementierung und betriebliche Absicherung
eines mehrschichtigen Firewall- und Sicherheitsmodells für eine produktive YunoHost-Umgebung auf
Debian 12. Im Mittelpunkt stehen die Provider-Firewall von Netcup, die lokale YunoHost-Firewall,
SSH Hardening, Fail2ban, sichere Rollout-Verfahren, Validierung, Recovery sowie der langfristige
Betrieb eines internetexponierten Web-, Mail- und Cloud-Servers.
Scope & Zielbild
Zielbild: Aufbau eines robusten, nachvollziehbaren und betriebssicheren
Firewall-Konzepts für eine produktive Serverumgebung mit minimaler Angriffsfläche,
klar definierten Freigaben und reproduzierbaren Recovery-Pfaden.
- Außenkante absichern: Unerwünschten Verkehr bereits vor dem Server filtern.
- Dienste gezielt veröffentlichen: Nur notwendige Ports für Web, Mail und Administration offenhalten.
- Zugriffe härten: SSH ausschließlich kontrolliert und möglichst schlüsselbasiert betreiben.
- Angriffe aktiv erkennen: Wiederholte Authentifizierungsfehler automatisiert blockieren.
- Betrieb stabil halten: Jede Änderung validierbar, dokumentiert und rollbackfähig umsetzen.
Projektziel: Die Umgebung soll nicht nur „funktionieren“, sondern auf Enterprise-Niveau
nachvollziehbar abgesichert werden. Dazu gehört eine technische Trennung der Sicherheitslayer,
eine definierte Reihenfolge für Änderungen und ein klarer Notfallpfad ohne Lockout-Risiko.
Abgrenzung: Diese Dokumentation ist bewusst als Projektdokumentation aufgebaut.
Sie beschreibt Architektur, Zielzustand, Umsetzung, Betrieb und Risiken. Das operative
Schritt-für-Schritt-Handeln verbleibt im zugehörigen Runbook.
System- und Sicherheitsarchitektur
Architekturprinzip: außen filtern • lokal kontrollieren • aktiv überwachen
| Layer | Komponente | Funktion |
|---|---|---|
| Provider Edge | Netcup Firewall | Vorfilterung eingehender Verbindungen vor Erreichen des Servers |
| Host Firewall | YunoHost Firewall | Zentrale lokale Portfreigaben für veröffentlichte Dienste |
| Access Layer | SSH Hardening | Absicherung administrativer Zugänge gegen Missbrauch und Fehlkonfiguration |
| Abuse Protection | Fail2ban | Erkennung und temporäre Sperre wiederholter Fehlversuche |
| Applications | nginx, Nextcloud, SOGo, Postfix, Dovecot | Produktive Web-, Mail- und Groupware-Dienste |
| Operations | Monitoring, Logs, Rollback | Validierung, Fehleranalyse und Wiederherstellung |
Kernidee: Sicherheitsrelevante Verantwortung wird bewusst auf mehrere Ebenen verteilt.
Die Provider-Firewall reduziert den Verkehr an der Außenkante, die Host-Firewall bildet den
dienstorientierten Sollzustand ab und Fail2ban ergänzt die Architektur um eine dynamische
Reaktionsschicht gegen missbräuchliche Anmeldeversuche.
Internet │ ▼ Netcup Provider-Firewall │ ▼ Debian 12 / YunoHost Host-Firewall │ ├── SSH (Administration) ├── nginx / HTTPS (Web, Portal, Nextcloud, Groupware) ├── Postfix (SMTP / Submission) └── Dovecot (IMAPS) │ ▼ Fail2ban / Logging / Monitoring / Rollback
Firewall-Design & Sicherheitsprinzipien
Default Deny
Alles, was für den produktiven Betrieb nicht ausdrücklich benötigt wird, bleibt geschlossen.
Alles, was für den produktiven Betrieb nicht ausdrücklich benötigt wird, bleibt geschlossen.
Least Privilege
Ports, Protokolle und Verwaltungszugänge werden auf den kleinstmöglichen Bedarf begrenzt.
Ports, Protokolle und Verwaltungszugänge werden auf den kleinstmöglichen Bedarf begrenzt.
Safe Rollout
Änderungen erfolgen schrittweise, mit Baseline, Validierung und dokumentiertem Rückweg.
Änderungen erfolgen schrittweise, mit Baseline, Validierung und dokumentiertem Rückweg.
Entwurfsziele
- Keine konkurrierenden lokalen Firewall-Werkzeuge parallel zum YunoHost-Management.
- Klare Zuordnung, welche Ebene welchen Schutzbeitrag leistet.
- Minimierung der Bedienfehler bei produktiven Änderungen.
- Vermeidung unnötiger Sonderregeln, solange Standardmechanismen ausreichend sind.
- Dokumentierbarkeit aller Freigaben für spätere Audits und Reviews.
Wesentliches Projektrisiko: Die größte Gefahr besteht nicht im fehlenden Filter,
sondern in einer unkontrollierten Härtung. Eine zu früh verschärfte SSH-Regel kann den
Server administrativ unerreichbar machen. Deshalb war die Reihenfolge der Umsetzung ein
zentrales Designkriterium des Projekts.
Ergebnis des Designs: Ein kontrollierbares Sicherheitsmodell, das sowohl Schutzwirkung
als auch Betriebsstabilität berücksichtigt und den produktiven Mail- und Webbetrieb nicht gefährdet.
Port- und Dienstmatrix
| Port | Protokoll | Dienst | Notwendigkeit | Projektbewertung |
|---|---|---|---|---|
| 22 | TCP | SSH Administration | Erforderlich | Freigabe nur für Administration, perspektivisch weiter eingrenzbar |
| 80 | TCP | HTTP / ACME / Redirect | Erforderlich | Notwendig für Web und Zertifikatserneuerung |
| 443 | TCP | HTTPS | Erforderlich | Zentraler Port für Web-, Groupware- und Cloud-Zugriffe |
| 25 | TCP | SMTP | Erforderlich | Mailserver-Kommunikation zwischen Systemen |
| 587 | TCP | SMTP Submission | Erforderlich | Authentifizierter Mailversand für Clients |
| 993 | TCP | IMAPS | Erforderlich | Verschlüsselter Mailabruf für Benutzergeräte |
| 465 | TCP | SMTPS | Optional | Nur bei bewusstem Bedarf, nicht als Standardfreigabe |
| 4190 | TCP | ManageSieve | Optional | Nur freigeben, wenn serverseitige Sieve-Regeln aktiv genutzt werden |
Projektentscheidung: Das finale Standardbild konzentriert sich auf
22, 80, 443,
25, 587 und 993.
Zusätzliche Ports werden ausschließlich anlassbezogen und dokumentiert veröffentlicht.
Projektumsetzung
Projektphasen
| Phase | Inhalt | Ziel |
|---|---|---|
| Vorbereitung | SSH-Sessions, SCP-Zugriff, Baseline, Dienstsicht | Änderungen kontrollierbar machen |
| Ist-Zustand | Ports, Firewall-Regeln, Fail2ban-Status dokumentieren | Rollback und Vergleichsbasis schaffen |
| Provider-Layer | Netcup-Freigaben definieren | Außenkante härten |
| Host-Layer | YunoHost-Firewall angleichen | Lokalen Sollzustand herstellen |
| Access Hardening | SSH absichern | Administrativen Zugang schützen |
| Abwehrschicht | Fail2ban validieren und erweitern | Angriffe automatisiert begrenzen |
| Validierung | Web, Mail, SSH und Logs testen | Produktionsfähigkeit sicherstellen |
Technischer Ansatz
- Die Provider-Firewall wurde als erste äußere Kontrollinstanz positioniert.
- Die YunoHost-Firewall bildet die lokale Referenz für veröffentlichte Dienste.
- Der SSH-Dienst wurde bewusst erst nach erfolgreichem Key-Test weiter gehärtet.
- Fail2ban ergänzt die statischen Regeln um eine dynamische Reaktionsfähigkeit.
- Jede Phase wurde mit separater Validierung und offen gehaltener Rückfalloption geplant.
Projektmethodik: Nicht maximale Härte in einem Schritt, sondern stabile Sicherheit
in einer kontrollierten Abfolge. Diese Vorgehensweise war entscheidend, um produktive
Services wie Nextcloud, SOGo, Postfix und Dovecot durchgehend verfügbar zu halten.
SSH Hardening
Zielsetzung
- Reduktion des Risikos für unautorisierte administrative Zugriffe.
- Umstellung auf schlüsselbasierte Authentifizierung.
- Deaktivierung unnötiger oder unsicherer Standardpfade.
- Beibehaltung eines sicheren Notfallzugangs während der Umstellung.
| Maßnahme | Sicherheitsnutzen |
|---|---|
| PermitRootLogin no | Kein direkter Root-Zugang von außen |
| PasswordAuthentication no | Keine Passwort-Logins mehr möglich |
| PubkeyAuthentication yes | Schlüsselbasierte Anmeldung erzwingen |
| MaxAuthTries 3 | Begrenzung von Login-Versuchen |
| LoginGraceTime 30 | Reduktion langer offener Auth-Sessions |
Projektkritischer Punkt: SSH wurde nicht isoliert „hart geschaltet“, sondern nur
nach erfolgreicher Prüfung einer funktionierenden Key-Anmeldung und mit mindestens zwei
offenen Sessions. Diese Vorgehensweise war essenziell, um ein Lockout-Szenario auszuschließen.
# Beispiele der im Projekt berücksichtigten SSH-Härtung PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes ChallengeResponseAuthentication no KbdInteractiveAuthentication no MaxAuthTries 3 LoginGraceTime 30
Fail2ban & Angriffserkennung
Funktion im Projekt
Fail2ban wurde als dynamische Schutzschicht betrachtet. Während die Firewall nur die grundsätzliche Erreichbarkeit steuert, reagiert Fail2ban auf auffälliges Verhalten und schützt besonders exponierte Authentifizierungsdienste gegen wiederholte Missbrauchsversuche.
| Jail | Schutzzweck |
|---|---|
| sshd | Schutz gegen SSH-Bruteforce |
| nginx-http-auth | Schutz für HTTP-Authentifizierungen |
| postfix / sasl | Schutz gegen Missbrauch des Mailversands |
| dovecot | Schutz für Mailabruf und Login-Fehler |
| yunohost / yunohost-portal | Schutz für Portallogins und Verwaltungsoberflächen |
| recidive | Längere Sperren für Wiederholungstäter |
Mehrwert: Durch Fail2ban wurde die Architektur von einem rein statischen Filtermodell
zu einem adaptiven Sicherheitsmodell erweitert. Besonders bei SSH-, Mail- und Web-Logins
verbessert dies die Widerstandsfähigkeit der Umgebung erheblich.
sudo systemctl enable --now fail2ban sudo fail2ban-client status sudo fail2ban-client status sshd sudo fail2ban-client status postfix sudo fail2ban-client status dovecot
Validierung & Abnahmekriterien
| Prüfbereich | Prüfmethode | Abnahmekriterium |
|---|---|---|
| SSH Zugriff | Neue Session mit Key öffnen | Login stabil, keine Passwortabhängigkeit |
| Webzugriff | HTTPS per Browser und curl testen | Portale, Webseiten und Cloud-Dienste erreichbar |
| Mailbetrieb | SMTP / Submission / IMAPS prüfen | Versand und Abruf ohne Firewall-Konflikte |
| Firewall-Sollzustand | Regellisten und Listener vergleichen | Nur freigegebene Dienste sichtbar |
| Fail2ban | Jails und Status prüfen | Abwehrmechanismen aktiv und fehlerfrei |
| Logs | Journal- und Dienstlogs kontrollieren | Keine unerwarteten Fehler nach Umstellung |
sudo ss -tulpen sudo yunohost firewall list sudo fail2ban-client status sudo systemctl status ssh nginx postfix dovecot fail2ban --no-pager curl -I https://mayit.eu curl -I https://mitcloud.mayit.eu
Betrieb & Aufgabenmodell
Daily
- Prüfung von SSH-, Web- und Mail-Erreichbarkeit
- Kontrolle von Fail2ban und auffälligen Bans
- Sichtung aktueller Sicherheits- und Dienstlogs
- Plausibilisierung unerwarteter Fehlerbilder
Weekly
- Review der offenen Ports und Listener
- Prüfung, ob optionale Freigaben noch erforderlich sind
- Analyse wiederkehrender Angriffsquellen
- Kontrolle der Firewall-Dokumentation nach Änderungen
Monthly
- Review des SSH-Härtungsstands
- Überprüfung des Recovery-Pfads
- Abgleich von Baseline und aktuellem Zustand
- Strategischer Ausbau, z. B. VPN oder weitere Zugangseinschränkung
Betriebsprinzip: Firewall-Änderungen werden als kontrollierte Changes behandelt.
Das bedeutet: Baseline vorab sichern, Änderung klar begrenzen, sofort validieren,
Notfallpfad bereithalten und das Ergebnis dokumentieren.
Troubleshooting
Typische Fehlerbilder
- SSH-Zugang funktioniert in bestehender, aber nicht in neuer Session.
- Webdienste reagieren lokal, aber nicht aus dem Internet.
- Mailabruf oder Submission scheitern nach Regeländerungen.
- Fail2ban läuft, aber ein benötigter Jail ist nicht aktiv.
- Zusätzliche manuelle Regeln kollidieren mit dem YunoHost-Management.
Systematische Diagnose
- Provider-Firewall und Host-Firewall logisch getrennt prüfen.
- Listener mit dem gewünschten Portbild vergleichen.
- Journale von SSH, nginx, Postfix, Dovecot und Fail2ban auswerten.
- Zuletzt gesetzte Sonderregeln kritisch hinterfragen und bei Bedarf entfernen.
- Erst nach isolierter Fehlerursache weitere Härtungsschritte fortsetzen.
sudo ss -tulpen sudo yunohost firewall list sudo journalctl -u ssh --since "1 hour ago" --no-pager | tail -n 100 sudo journalctl -u nginx -u postfix -u dovecot --since "1 hour ago" --no-pager | tail -n 100 sudo journalctl -u fail2ban --since "1 hour ago" --no-pager | tail -n 100
Backup, Rollback & Recovery
Warum dieser Bereich projektkritisch ist
Sicherheitsänderungen an Firewall und SSH wirken direkt auf die Erreichbarkeit des Systems. Deshalb war ein belastbarer Rollback-Pfad kein optionaler Komfort, sondern fester Bestandteil des Projektdesigns.
- Vor Beginn wurde der Ist-Zustand von Regeln, Ports und Konfiguration gesichert.
- Konfigurationsänderungen wurden nur mit offener Rückfalloption umgesetzt.
- Bestehende SSH-Sessions blieben bis zur erfolgreichen Abnahme geöffnet.
- Problematische Sonderregeln mussten gezielt entfernbar bleiben.
Recovery-Bausteine
| Baustein | Zweck |
|---|---|
| SSH-Konfigurationsbackup | Rückkehr auf funktionierenden Zustand |
| iptables / nft Baseline | Vergleich und gezieltes Zurücksetzen |
| Netcup SCP Zugriff | Externe Korrektur am Provider-Layer |
| Offene Session | Administrative Rettung ohne Neuverbindung |
| YunoHost Reload | Lokale Regeln konsistent neu anwenden |
mkdir -p ~/firewall-baseline sudo yunohost firewall list > ~/firewall-baseline/yunohost-firewall-before.txt sudo ss -tulpen > ~/firewall-baseline/listening-ports-before.txt sudo iptables-save > ~/firewall-baseline/iptables-before.rules sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M)
Risiken & Lessons Learned
Wesentliche Projektrisiken
- Lockout durch zu frühe SSH-Verschärfung.
- Fehlannahmen über die tatsächlich benötigten Mail-Ports.
- Parallelbetrieb unterschiedlicher Firewall-Mechanismen.
- Unzureichende Trennung zwischen Provider- und Host-Layer bei der Fehlersuche.
Erkenntnisse aus dem Projekt
- Mehr Sicherheit entsteht durch saubere Architektur, nicht durch unkoordinierte Härte.
- Rollback-Fähigkeit ist Teil der Sicherheitsqualität.
- Port-Minimierung vereinfacht sowohl Schutz als auch Betrieb.
- Fail2ban ergänzt die Firewall sinnvoll, ersetzt sie aber nicht.
- Kontrollierte Changes reduzieren das reale Betriebsrisiko erheblich.
Anhang
| Bereich | Kernkommandos / Bezug |
|---|---|
| Listener | ss -tulpen |
| YunoHost Firewall | sudo yunohost firewall list • sudo yunohost firewall reload |
| SSH | /etc/ssh/sshd_config • sudo sshd -t |
| Fail2ban | sudo fail2ban-client status • sudo journalctl -u fail2ban |
| iptables | sudo iptables -L -n -v –line-numbers • sudo iptables-save |
| Web / Mail Logs | sudo journalctl -u nginx -u postfix -u dovecot |
| Diagnose | sudo yunohost diagnosis show –issues –human-readable |
Autor: MayIT – Projektdokumentation YunoHost Firewall Hardening