UFW wie ein Profi: Rate-Limiting für SSH & Postfix mit sinnvollen Defaults

UFW Rate Limiting Ubuntu

Inhaltsverzeichnis

Dieser kurze Guide hilft Administratoren i, einen server schnell zu härten. Die Anleitung zeigt klare steps für sichere configuration, transparente logging und gezielte Freischaltung von services.

Die Uncomplicated Firewall ist auf vielen Systemen vorinstalliert, aber oft deaktiviert. Sie arbeitet mit einer Default-Deny-Policy für eingehende Verbindungen und erlaubt ausgehendes traffic standardmäßig.

Wichtige Befehle (Bash):

sudo ufw enable
sudo ufw status numbered
sudo ufw allow 80/tcp
sudo ufw limit 22/tcp

Beachte Provider-Eigenheiten: Network-Level-Firewalls und gesperrte Mail-Ports (25/465/587) können vor der eigenen Firewall greifen. IPv6 aktivierst du in /etc/default/ufw (IPV6=yes).

Ziel ist eine starke Baseline-security. Diese intro führt zu detaillierten Schritten für SSH-Härtung, Postfix-Absicherung und Backup der rules.

Warum UFW auf Ubuntu: Ziel, Nutzen und Sicherheitsgewinn

Für Administratoren ist eine einfache Firewall-Oberfläche oft der schnellste Weg zu mehr Server-Security. Die uncomplicated firewall stellt eine leicht verständliche Schicht über Netfilter/iptables bereit und reduziert Komplexität bei Regeln.

Der praktische Nutzen liegt in einer Default-deny-Policy für eingehende Verbindungen. So sind nur definierte Dienste erreichbar und die policy verhindert ungewollten Zugriff. Status- und verbose-Ausgaben geben klare Transparenz zu Regeln, Logging und Defaults.

Ressourcenverbrauch bleibt gering, die Syntax ist kurz (z. B. sudo ufw allow 80/tcp) und App-Profile vereinfachen Freigaben für Dienste wie mysql. Im Network-Stack filtert die Lösung traffic effizient und erlaubt granulare access-Kontrollen ohne tiefes iptables-Wissen.

Das Tool eignet sich für kleine bis mittlere Infrastrukturen sowie Produktiv- und Entwicklungsserver. Es ergänzt Provider-Firewalls und trägt zur Defense-in-Depth bei, ersetzt sie aber nicht. IPv4- und IPv6-Unterstützung macht Setups zukunftssicher.

Voraussetzungen und Systemcheck für dieses How-To

Starten Sie mit einem schnellen Systemcheck, damit keine Remote-Verbindung verloren geht.

Stellen Sie sicher, dass Sie sudo-Rechte haben, ein erreichbarer server läuft und Basisdienste wie SSH aktiv sind. Prüfen Sie Paketaktualität und Uhrzeit (NTP), damit Logs korrekt bleiben.

Kontrollieren Sie, ob ufw installiert ist mit dem Befehl sudo ufw version. Falls nicht vorhanden, installieren Sie es via sudo apt install ufw.

Aktivieren und prüfen Sie den Dienst sicher mit dem following command: sudo ufw enable und anschließend sudo ufw status oder sudo ufw status verbose. Legen Sie vor dem Aktivieren eine Regel für SSH an, sonst droht ein Lockout (example: sudo ufw allow ssh).

Identifizieren Sie laufende applications und benötigte Ports (Web, DB, Mail) und notieren Sie vorhandene App-Profile per sudo ufw app list. Prüfen Sie zudem die Netzwerk-configuration, besonders bei Cloud-Providern mit zusätzlichen Filtern.

UFW aktivieren und saubere Defaults setzen

Der erste Schritt zur harten Baseline ist das Aktivieren der Firewall mit sauberen Default-Policies. So verhindern Sie unnötigen Zugriff und behalten Kontrolle über den eingehenden Traffic.

enable ufw, Status prüfen und Neustart-Verhalten

Legen Sie vor dem Aktivieren unbedingt eine SSH-Regel an, sonst verlieren Sie Remote-Zugriff. Nutzen Sie das command sudo ufw enable; die Firewall startet künftig automatisch mit dem system.

Siehe auch  SSH-Keys einrichten auf Ubuntu – technische Anleitung

Prüfen Sie den aktuellen status mit sudo ufw status oder ausführlicher mit sudo ufw status verbose. Die Ausgaben zeigen aktive Regeln, Logging-Level und die gesetzten Defaults.

Default-Policy: deny incoming, allow outgoing

Setzen Sie klare Standardrichtlinien mit:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Denn deny incoming connections und allow outgoing connections sind bewährte Startpunkte. Definieren Sie zuerst die policy, dann erlauben Sie gezielt benötigte Dienste.

Beachten Sie Cloud-Provider-Filter und dokumentieren Sie Änderungen. UFW bleibt in der Regel persistent über Reboots; prüfen Sie aktive Sessions vorsichtig und passen Sie später das Logging an.

UFW Rate Limiting Ubuntu

Eine gezielte Begrenzung von Verbindungsversuchen schützt Server effektiv vor automatisierten Angriffen.

Mit dem Befehl sudo ufw limit PORT/PROTO drosselt die Firewall Verbindungsversuche pro Quell-IP. Die Standardschwelle liegt typischerweise bei etwa sechs Versuchen in 30 Sekunden für SSH.

Das wirkt ergänzend zu Passwort- und Schlüssel-Authentifizierung. Ein solches rule-Set erschwert Brute-Force-Attacken und reduziert unnötigen Log-Lärm.

Praktisch lässt sich die Funktion für beliebige Dienste einsetzen, meist jedoch für SSH oder Submission-Ports. Beachten Sie die Reihenfolge Ihrer firewall rules, damit präzise Regeln Vorrang haben und False Positives sinken.

Limitierung beeinflusst regulären traffic kaum, schützt aber anfällige Dienste. Ergänzen Sie diese Maßnahme mit starken Passwörtern, Schlüssel-Auth und gezielten network-Policies.

Dokumentieren Sie die settings und prüfen Sie die Logs, um zu erkennen, wann Limits greifen. So bleibt die security transparent und wartbar.

SSH absichern: Port, Allow-Regel und Rate-Limit gegen Brute-Force

Bevor der Server produktiv läuft, sollten Sie den SSH-Zugang gezielt härten. Setzen Sie eine klare allow-Regel für den ssh port und kombinieren Sie sie mit Sperrmechanismen für wiederholte Versuche.

SSH öffnen und Basisregel

Öffnen Sie den Dienst mit dem bekannten command: sudo ufw allow 22/tcp oder einfacher sudo ufw allow ssh. Legen Sie diese Regel an, bevor Sie die Firewall endgültig aktivieren, um ein Aussperren zu verhindern.

Schutz gegen Brute-Force

Aktivieren Sie die Limit-Funktion per sudo ufw limit 22/tcp, damit pro IP nur etwa sechs Versuche in 30 Sekunden möglich sind. Das reduziert automatisierte Angriffe auf ssh connections deutlich.

Nur vertrauenswürdige Adressen zulassen

Für Admins empfiehlt sich address-Whitelisting: sudo ufw allow from 203.0.113.10 to any port 22. Platzieren Sie spezifische Allow-from-Regeln vor generischen Regeln und prüfen Sie den Status mit sudo ufw status numbered.

Passen Sie das Logging an (sudo ufw logging medium), um verdächtige incoming traffic schnell zu erkennen. Schlüsselbasierte Authentifizierung und das Deaktivieren von Passwort-Login ergänzen diese rule sinnvoll. Weitere Hinweise zur Portfreigabe finden Sie in diesem Guide: Ports freigeben.

Postfix/SMTP absichern: Sinnvolle Ports, Limits und Provider-Policies

Gute Mail-Security beginnt mit gezielten Port-Freigaben und sensiblen Access-Regeln. Öffnen Sie nur die Ports, die Ihr Mail-Workflow wirklich braucht. Dokumentation und konsistente firewall rules halten den Betrieb transparent und auditfähig.

Öffnen der relevanten Ports

Für einen Mailserver sind drei ports relevant: 25 (MTA), 465 (SMTPS) und 587 (Submission).

Beispiele zum Freischalten: sudo ufw allow 25/tcp, sudo ufw allow 465/tcp, sudo ufw allow 587/tcp. Öffnen Sie nur die benötigten services und platzieren Regeln sauber.

Wann Rate-Limiting für SMTP sinnvoll ist

Ein Limit ist meist nur für Submission-Ports (587/465) sinnvoll, um missbräuchliche Logins zu dämpfen. Für Port 25, der MTA-zu-MTA-Verkehr empfängt, sollte kein striktes Limit angewendet werden.

Provider-Policies und Netzwerk-Einschränkungen

Viele Cloud-Provider sperren 25/465/587 standardmäßig. Manche erlauben nur ausgehenden Versand nach Freischaltung.

Prüfen Sie outgoing traffic-Restriktionen und stimmen Sie Ihre network-Level-Policies mit dem Provider ab. Kontaktieren Sie den Support, wenn Ports netzseitig blockiert sind.

Eingehender vs. ausgehender Traffic: präzise Regeln für Services

Klar definierte Eingangs- und Ausgangsregeln reduzieren die Angriffsfläche Ihres Servers deutlich. Legen Sie eine klare policy als Basis fest: default deny für eingehend und default allow für ausgehend ist ein bewährter Startpunkt.

Siehe auch  Nischen-Distros: Linux-Varianten für spezifische Bedürfnisse

Incoming gezielt erlauben

Allow incoming nur für wirklich notwendige services und ports. Typische Beispiele sind Web-Ports:

sudo ufw allow 80/tcp und sudo ufw allow 443/tcp.

Datenbank- oder DNS-Ports öffnen Sie nur bei echtem Bedarf und dann IP-restricted.

Outgoing: Standard erlauben, Ausnahmen definieren

Allow outgoing connections sind oft standardmäßig aktiv. Bei Compliance oder strengem Betrieb schränken Sie ausgehenden Traffic ein.

Erstellen Sie gezielte rules für erlaubte Ziele, etwa firmeninterne Proxys oder API-Endpunkte. Dokumentieren Sie geöffnete ports und prüfen Sie rules regelmäßig.

Kurzfazit: Halten Sie Regeln granular, dokumentiert und zeitnah gepflegt. So bleibt die Konfiguration sicher und wartbar.

Regeln für specific ports und Portbereiche effektiv definieren

Präzise Portfreigaben sind ein einfacher, aber wirkungsvoller Schritt zur Härtung eines Servers.

specific ports

Einzelports sinnvoll öffnen

Öffnen Sie nur die wirklich benötigten ports. Beispielbefehle:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 3306/tcp

http und HTTPS sind typische example-Anwendungsfälle für web-Services. Datenbank-Ports wie 3306 sollten nur mit IP-Restriktion freigegeben werden.

Port‑Ranges mit Vorsicht einsetzen

Portbereiche sind praktisch für Entwicklungsumgebungen, bergen aber Risiken in Produktion.

Beispiel: sudo ufw allow 8000:9000/tcp öffnet inklusive Grenzen. Auf Produktivsystemen besser selektiv erlauben. Entwicklungsserver verwenden manchmal 3000-8999, doch in Live-Setups gilt: enger fassen.

Wahren Sie rule- und rules-Konsistenz, dokumentieren Sie Dienste pro Port und prüfen Sie nach Änderungen stets den Status. Weitere Hinweise zum Ports freigeben finden Sie hier: Ports freigeben.

Regelverwaltung in der Praxis: Status, Nummerierung und Löschen

Eine klare Übersicht über aktive rules erleichtert das tägliche Management und reduziert Fehler. Kurzbefehle liefern schnellen Einblick und erlauben gezieltes Eingreifen.

Statusabfragen verstehen

Prüfen Sie den Status mit dem command sudo ufw status. Für mehr Details nutzen Sie sudo ufw status verbose, das Defaults und das Logging-Level zeigt.

Nummerierte Anzeige und gezieltes Löschen

Eine nummerierte Liste erhalten Sie mit sudo ufw status numbered. Die Nummer macht das Entfernen einer rule sicher und präzise.

Zum Löschen verwenden Sie sudo ufw delete [Nummer]. Prüfen Sie vorher die Wirkung auf das system, bevor Sie Regeln entfernen.

Pflegehinweise

Zeigen Sie benutzerdefinierte Einträge mit sudo ufw show user-rules an. Änderungen sind sofort aktiv; ein Reload ist nur nach manueller Datei-Änderung nötig.

Dokumentieren Sie jeden command in Tickets oder Runbooks, räumen Sie rules regelmäßig auf und prüfen Sie nach Löschungen erneut den status, um den Endzustand zu verifizieren.

Logging und Transparenz: Levels und gezielte Protokollierung

Saubere Protokollierung macht Vorfälle sichtbar und vereinfacht das Tuning der Serverkonfiguration.

Wählen Sie ein Logging-Level passend zur Betriebsphase. Mittlere Einstellungen liefern genug Signal ohne zu viel Rauschen.

Logging-Level: off, low, medium, high, full

Setzen Sie das Level per sudo ufw logging LEVEL (off, low, medium, high, full). Low protokolliert blockierte Pakete und markierte Regeln.

Medium ergänzt erlaubte Verbindungen und ist ein guter Startpunkt für produktive Systeme. High und full geben mehr Details, sollten aber nur temporär aktiv sein.

Loggen spezifischer Regeln zur Analyse

Regel-spezifisches Logging aktivieren Sie mit dem log-Parameter in einzelnen rules, um kritische Pfade sichtbar zu machen.

Solche Daten zu traffic und connections helfen bei der Erkennung von Anomalien und bei Incident Response.

Führen Sie eine Logrotation/Retention ein, senden Sie Logs an zentrale Systeme (journal, syslog, SIEM) und verknüpfen die Strategie mit Incident-Playbooks.

Kommentieren Sie Regeln klar, achten Sie auf Datenschutz und dokumentieren Sie jede Änderung in der configuration und den settings. Dieser guide hilft Ihnen, Logging sinnvoll und nachhaltig einzurichten.

IPv6-Unterstützung in UFW korrekt aktivieren

Aktivieren Sie IPv6-Unterstützung in der Firewall, wenn Ihr network Dual-Stack betreibt.

Öffnen Sie die Datei /etc/default/ufw und setzen Sie die Variable IPV6=yes. Datei speichern und die configuration neu laden oder den Dienst aktivieren, damit die settings greifen.

Nach dem Neustart gelten die default-Policies für IPv4 und IPv6 gleichermaßen. Prüfen Sie den Status: Die Ausgabe zeigt Regeln getrennt mit (v6), so behalten Sie Transparenz für beide Stacks.

Siehe auch  Ubuntu gestalten: Wie Mac OS aussehen lassen

Ohne diese Änderung können IPv6-Pfade ungeschützt bleiben. Planen Sie Regeln in dual-stack-Umgebungen immer für beide Protokollfamilien.

Beachten Sie zudem, dass manche Netzbetreiber Funktionen wie Router Advertisements oder NDP außerhalb der Firewall verwalten. Prüfen Sie Logging auf IPv6-Ereignisse und aktualisieren Sie Ihre Dokumentation, damit das Betriebsteam Klarheit hat.

Applikationsprofile und Dienste-Namen nutzen statt Ports

Applikationsprofile machen Firewall-Regeln klarer und reduzieren Fehlerquellen im Alltag.

Bewährte Profile erlauben das gezielte Öffnen bekannter services ohne numerische Angaben. Ein Beispiel: sudo ufw allow mysql statt specific ports zu merken. Das reduziert Tippfehler und vereinfacht Reviews.

Liste verfügbare applications mit sudo ufw app list und prüfe, ob das gewünschte Profil vorhanden ist. Regeln bleiben flexibel: Du kannst eine rule weiterhin mit access‑Einschränkungen kombinieren, etwa from einer IP oder einem Subnetz.

Sprechende Profile und kurze Kommentare verbessern Auditierbarkeit und Team-Übergaben. Standarddienste wie OpenSSH, Nginx oder MySQL profitieren besonders.

Für exotische Dienste sind specific ports weiterhin nötig. Halte eine klare Trennung zwischen Applikations- und Infrastrukturebene und dokumentiere Profil-Änderungen im Betrieb.

Reset, Reload, Disable und Uninstall: sicher mit Änderungen umgehen

Vor tiefen Eingriffen an der Firewall sollten Sie einen klaren Plan haben. Das minimiert Ausfallrisiken, besonders bei Remote-Servern.

Regeln, die Sie per CLI setzen (z. B. sudo ufw allow), gelten sofort und brauchen keinen reload. Den Befehl sudo ufw reload verwenden Sie nur, wenn Sie Dateien manuell editiert haben und die Änderungen neu einlesen müssen.

Wann reset sinnvoll ist

Der Befehl reset ufw räumt alle rules und Policies auf und deaktiviert die Firewall. Ein gezieltes reset ufw default bringt die Einstellungen auf deny incoming / allow outgoing zurück.

Stoppen und entfernen

Zum Stoppen nutzen Sie systemctl stop ufw oder sudo ufw disable. Entfernen geht mit sudo apt remove –purge ufw, aber nur, wenn eine Alternative bereitsteht.

Wichtige Hinweise: Vor einem Reset immer lokalen Konsolen-Zugang sicherstellen. Dokumentieren Sie alle command-Abfolgen, definieren Sie einen Rollback-Plan und testen Änderungen in Wartungsfenstern, um unerwartete Verbindungsabbrüche zu vermeiden.

Backup und Restore von UFW-Regeln für reproduzierbare Setups

Eine reproduzierbare Regelbasis spart Zeit bei Neuinstallationen und Audits. Sichern Sie den aktuellen Zustand vor Änderungen, damit Sie im Notfall schnell zurückkehren können.

Konfiguration exportieren

Exportieren Sie die nummerierte Ausgabe mit dem following command:

sudo ufw status numbered > ufw-rules-backup.txt

Die number‑basierte Liste erleichtert später das automatische Parsen und bewahrt Kommentierungen und Reihenfolge der rules.

Automatisiertes Restore per Skript

Für das Wiederherstellen empfiehlt sich ein kleines Skript, das jede Zeile liest, die rule extrahiert und mit sudo anlegt.

Vor dem Restore führen Sie ein reset ufw aus, um Altlasten zu vermeiden. Danach aktivieren Sie die Firewall erneut mit sudo ufw enable.

Machen Sie das Skript ausführbar:

sudo chmod +x restore_ufw_rules.sh und starten es mit sudo ./restore_ufw_rules.sh.

Wichtig: Lagern Sie Skripte sicher, testen den Restore in einer Test‑system‑Umgebung und dokumentieren configuration und settings versionskontrolliert.

Provider-Firewalls, gesperrte Ports und doppelte Regelwerke

Provider-seitige Filter können firewall-Verhalten verändern und sollten früh geprüft werden.

Viele Anbieter, etwa DigitalOcean oder Vultr, setzen network‑Level-Firewalls ein, die Traffic vor dem Host blocken. Das hat direkte Folgen für die Sichtbarkeit und Fehlersuche von Verbindungen.

Network‑Level Firewalls abstimmen

Prüfen Sie die Regeln im Provider‑Panel und gleichen Sie sie mit der Host‑Konfiguration ab. Doppelte oder widersprüchliche Einträge führen zu unerwarteten Blockaden.

Modellieren Sie access konsistent: Wenn ein Port auf Provider‑Ebene erlaubt ist, muss der Host ebenfalls Zugang gewähren, sonst bleiben connections aus.

Gesperrte E‑Mail‑Ports beantragen

Ports wie 25, 465 und 587 sind oft gesperrt, um Spam zu verhindern und IP‑Reputation zu schützen. Für Mail‑Server beantragen Sie eine Freischaltung beim Provider.

Belegen Sie legitime Nutzung und Anti‑Abuse‑Maßnahmen. Dokumentation, Monitoring beider Ebenen und koordinierte Änderungen minimieren Downtime und erhöhen die Sicherheit.

Häufige Fehlerbilder und schnelle Lösungen

Viele Probleme entstehen durch falsche Adressen oder fehlende allow incoming‑Regeln. Ein typisches example: Firewall aktiviert, aber kein ssh freigegeben — dann verlieren Sie Remote‑Zugriff.

Fix: Konsole oder Provider‑Panel nutzen und den command sudo ufw allow 22/tcp nachholen. Prüfen Sie den status mit sudo ufw status numbered, um rule‑Konflikte sichtbar zu machen.

Access-Probleme kommen oft von falscher address oder fehlerhafter Subnetzmaske. Testen Sie Verbindbarkeit mit Ping oder netcat, um connections gezielt zu prüfen.

Wenn HTTP nicht erreichbar ist, obwohl Port 80 erlaubt wurde, schauen Sie zuerst auf Dienstzustand und Bindings. Externe Blockaden ergeben sich auch durch Provider‑Firewall‑Regeln; Kontrolle im Panel klärt das schnell.

Erhöhen Sie temporär das Logging (sudo ufw logging medium), um Drop/Reject‑Events zu sehen. Nach Fixes end‑to‑end testen (Client → Server) und Änderungen dokumentieren, damit das example später nachvollziehbar bleibt.

Best Practices: Sicher, schlank und wartbar konfigurieren

Sichere Defaults und regelmäßige Prüfungen sind die Basis stabiler Server‑security.

Setzen Sie eine default‑Strategie: deny incoming connections und allow outgoing connections. Definieren Sie klare firewall rules und halten Sie die policy konsistent.

Erlauben Sie nur gezielt Dienste (z. B. web: http/HTTPS) und nutzen Sie Applikationsprofile statt roter Zahlen. Erhöhen Sie die Sicherheit durch Rate‑Schutz für SSH (sudo ufw limit 22/tcp), starke Authentifizierung und schlanke Freigaben.

Prüfen Sie regelmäßig mit sudo ufw status numbered, aktivieren Sie logging auf medium und denken Sie an IPv6 (IPV6=yes). Dokumentation, Backup/Restore und Review‑Zyklen verhindern Drift und halten die Konfiguration wartbar.

Über Christian 401 Artikel
34 Jahre alt, gebürtig aus Cuxhaven und bekennender Kaffeejunkie :-). Ich interessiere mich schon seit meiner Kindheit für Technik. Dieses Interesse übertrage ich in meinem beruflichen Leben sowie im Privaten. Viel Spaß beim Stöbern!