Default Deny mit UFW: die 15-Minuten-Basis

Wenn ich einen neuen Server übernehme, stelle ich mir zuerst eine einfache Frage. Welche Ports sind wirklich nötig, damit das System seinen Zweck erfüllt?

Alles andere bleibt zu.

Genau das ist für mich der Kern von Default Deny. Nicht aus Paranoia, sondern aus Klarheit.

Die Stadt mit nur einem offenen Tor

In der Stadtmetapher würde niemand jede Mauer mit offenen Türen bauen und dann hoffen, dass schon nichts passiert. Eine Stadt funktioniert, weil klar ist, welche Tore offen sind, wann und für wen.

Ein Server ist nicht anders. Jeder offene Port ist ein Eingangspunkt. Wenn ich nicht weiß, warum er offen ist, ist er für mich ein Risiko.

Warum Default Allow im Alltag teuer wird

Viele Systeme starten faktisch mit Default Allow. Ein Dienst wird installiert, ein Port lauscht, später kommt ein zweiter Dienst dazu, dann ein dritter. Nach ein paar Monaten weiß niemand mehr genau, was wirklich gebraucht wird.

Das Ergebnis sehe ich in Audits immer wieder:

Unnötige Angriffsfläche,
unklare Zuständigkeiten,
hektische Firewall-Änderungen im Incident,
Unsicherheit bei Deployments.

Default Deny dreht die Logik um. Nicht alles ist offen, bis es jemand schließt. Alles ist zu, bis es einen klaren Grund gibt, es zu öffnen.

Meine 15-Minuten-Basis mit UFW

Auf Ubuntu oder Debian nutze ich dafür meist UFW. Das Setup ist klein, aber wirksam.

1) Standardregeln setzen

sudo ufw default deny incoming
sudo ufw default allow outgoing

Damit ist eingehender Traffic grundsätzlich blockiert. Ausgehender Traffic bleibt zunächst erlaubt, damit Updates und externe Abfragen weiter funktionieren.

2) Lebenswichtigen Zugang erlauben

Bevor ich die Firewall aktiviere, erlaube ich SSH.

sudo ufw allow OpenSSH

Alternativ explizit für Port 22:

sudo ufw allow 22/tcp

3) Nur benötigte Dienste freigeben

Für Webserver zum Beispiel:

sudo ufw allow http
sudo ufw allow https

Wenn ich keinen Webserver betreibe, öffne ich diese Ports nicht.

4) Firewall aktivieren und prüfen

sudo ufw enable
sudo ufw status verbose

Ab hier ist die Baseline aktiv.

Drei Fehler, die ich konsequent vermeide

1) Aktivieren, bevor SSH erlaubt ist

Das ist der Klassiker. Wer zuerst ufw enable ausführt und SSH erst danach freigibt, sperrt sich schnell selbst aus.

2) Zu breite Freigaben

Regeln wie allow from anywhere to any lösen kurzfristig Probleme, machen die Sicherheitslage langfristig aber unkontrollierbar.

3) Einmal einrichten und nie wieder prüfen

Firewall-Regeln sind kein einmaliges To-do. Sie gehören in die Betriebsroutine, inklusive regelmäßiger Reviews und klarer Verantwortlichkeit.

Was ich im Betrieb ergänze

Default Deny ist die Basis, nicht das Ende. Im nächsten Schritt ergänze ich in der Regel:

Logging und Monitoring für auffälligen Traffic,
sauberes Rollenmodell für Admin-Zugänge,
MFA für kritische Systeme,
regelmäßige Security-Reviews.

So entsteht aus einer kleinen Maßnahme ein belastbarer Sicherheitsprozess.

Was das für E-Commerce-Verantwortung bedeutet

Wenn unnötige Ports offen bleiben, wird aus einem kleinen Konfigurationsfehler schnell ein Geschäftsrisiko, gerade in Peak-Phasen oder während laufender Kampagnen.

Für mich ist Default Deny deshalb keine rein technische Übung, sondern ein klarer Beitrag zu stabilem Betrieb und planbaren Releases.

Fazit

Default Deny mit UFW ist kein großes Projekt. Es ist eine disziplinierte Grundentscheidung, die sofort Wirkung zeigt.

Ich reduziere die Angriffsfläche, schaffe Klarheit im Betrieb und mache Sicherheit planbarer. Und genau deshalb ist diese 15-Minuten-Basis für mich einer der ersten Schritte auf jedem neuen Server.

Wenn du magst, nutze unseren Projekt-Check, um Architektur, Testreife, Sicherheitspraktiken und Betriebsfähigkeit systematisch zu bewerten.