Firewall-Regeln nach Anwendung statt nach Server: Destination-Based richtig gedacht

9. September 2026 · 11 min Lesezeit · von Jan Weis

Ein Ticket kommt selten so herein: „Server 14 antwortet auf Port 1433 nicht." Es kommt so herein: „Die Lagerverwaltung geht nicht."

Genau da fängt das Problem an. Wenn das Firewall-Regelwerk pro Server sortiert ist, muss ich beim Troubleshooting erst herausfinden, welche Server zu dieser Anwendung gehören, und dann in zwanzig Regeln nachsehen, welche davon greift. Diese Übersetzungsarbeit fällt bei jeder Störung neu an, und sie fällt immer der Person zu, die gerade Rufbereitschaft hat.

Dieser Artikel beschreibt die Methode, mit der ich Firewall-Regeln stattdessen nach Anwendung aufbaue: eine feste Fragenreihenfolge, eine Entscheidungsmatrix für den Fall „ein Eintrag oder zwei", und drei ehrliche Grenzen des Modells.

Kurz gefasst#

• Destination-Based heißt: die Firewall am Standort stellt nur Erreichbarkeit her, der Dienst wird an der Firewall vor dem Server entschieden.
• Application-Based heißt: die Regeln im Rechenzentrum sind nach Anwendung und Rolle gruppiert, nicht pro Server. Ein neuer Server derselben Anwendung braucht dann keine neue Regel.
• Zwei Dienste dürfen nur dann in eine Regel, wenn derselbe Nutzerkreis sie braucht und sie auf denselben Servern laufen.

Inhalt#

1. Ein Regelwerk, das anders sortiert ist als das Ticket
2. Was destination-based wirklich bedeutet
3. Least Privilege und Struktur sind zwei Achsen
4. Jede Firewall-Regel in 5 Fragen herleiten
5. Ein Eintrag oder zwei: mehrere Ports in einer Regel
6. Die Quelle bestimmt das Exposure
7. Beispiel aus der Praxis: Lagerverwaltung
8. Grenzen des Modells
9. Aus der Konvention einen Standard machen
10. Fragen und Antworten

Ein Regelwerk, das anders sortiert ist als das Ticket#

Klassisch entsteht ein Firewall-Regelwerk so: Es wird ein Server in Betrieb genommen, jemand braucht Zugriff, und es wird eine Regel auf diesen Server gebaut. Bei 40 Servern und drei Diensten pro Server stehen irgendwann 200 Regeln im Regelwerk. Jede einzelne davon ist für sich betrachtet korrekt und sogar spezifisch.

Trotzdem ist das Regelwerk unbrauchbar, sobald etwas nicht funktioniert. Der Grund ist ein Modellbruch: Die Struktur des Regelwerks entspricht nicht der Struktur, in der gearbeitet und gemeldet wird. Gemeldet wird nach Anwendung, sortiert ist nach Maschine.

Dazu kommt ein zweites Problem, das erst später sichtbar wird. Jeder neue Clusterknoten bedeutet in diesem Modell einen Regelklon. Und Regelklone werden beim Rückbau vergessen. Wer schon einmal ein gewachsenes Regelwerk auditiert hat, kennt die Karteileichen mit Zielobjekten, die es seit drei Jahren nicht mehr gibt.

Was destination-based wirklich bedeutet#

Der übliche Aufbau in verteilten Umgebungen mit Außenstandorten sieht so aus: Am Standort steht eine grobe Regel Richtung Rechenzentrum, die eigentliche Dienstfreigabe steht an der Firewall vor dem Server.

Die verbreitete Begründung dafür lautet „dann müssen wir nicht beide Seiten anfassen". Das klingt in einer Besprechung nach Bequemlichkeit und ist angreifbar, denn jemand wird berechtigt fragen, warum man auf eine Prüfebene verzichtet.

Die belastbare Begründung ist eine andere. Die beiden Regelebenen ändern sich aus verschiedenen Gründen:

Ein Regelwerk nach Änderungsanlass zu schneiden, ist saubere Entkopplung. Dass dabei weniger Pflegeaufwand entsteht, ist die Folge und nicht der Zweck.

Wichtig ist die Einschränkung: Das betrifft nur den Dienst. Quelle und Ziel setze ich auf beiden Firewalls als echte Adressobjekte, nie als all. Offen bleibt am Standort ausschließlich das Service-Feld. Das ist die einzige Stelle im ganzen Regelwerk, an der ein Wildcard steht.

Damit ist aber erst geklärt, wo der Dienst entschieden wird. Die interessantere Frage ist, wonach die Regeln im Rechenzentrum gruppiert werden. Und da lautet die Antwort nicht „nach Server", sondern „nach Anwendung". Destination-Based wird damit zu Application-Based.

Least Privilege und Struktur sind zwei Achsen#

In fast jeder Best-Practice-Liste zu Firewall-Regeln steht der Rat, Regeln so spezifisch wie möglich zu bauen: konkrete Quelle, konkretes Ziel, konkreter Dienst statt ANY. Das ist richtig, und es ist der Grund, warum viele bei einer Regel pro Server landen. Spezifisch fühlt sich nach sicher an.

Der Punkt, der dabei untergeht: Spezifität und Struktur sind zwei unabhängige Achsen. Eine Regel kann exakt so eng gefasst sein wie vorher und trotzdem nach Anwendung sortiert sein. Es geht nicht darum, weniger genau zu werden, sondern darum, die gleiche Genauigkeit anders zu ordnen.

Least Privilege bleibt vollständig erhalten. Was sich ändert, ist die Auffindbarkeit im Störungsfall und der Aufwand beim Serverzuwachs.

Jede Firewall-Regel in 5 Fragen herleiten#

Ich habe lange versucht, das als Prinzip zu erklären. Das funktioniert nicht, schon gar nicht bei Auszubildenden. Was funktioniert, ist eine feste Fragenreihenfolge, bei der jede Antwort genau ein Feld der Regel füllt:

Die Reihenfolge ist der eigentliche Inhalt. Wer bei Frage 3 einsteigt, also beim Server, landet automatisch wieder bei einer Regel pro Maschine. Genau das soll die Reihenfolge verhindern.

Beachtenswert ist Frage 5. Mein erster Versuch war, die Rollen einer Anwendung vorzugeben: Weboberfläche, Datenbank, Dateiablage. Das ist ein Zirkelschluss, weil es voraussetzt, was der Kollege gerade herausfinden soll. Richtig herum wird ein Schuh daraus: Die Rolle ist kein Ausgangspunkt, sondern ein Ergebnis. Was in Frage 5 zusammenfällt, ist eine Rolle.

Ein Eintrag oder zwei: mehrere Ports in einer Regel#

Das ist die Frage, an der es in der Praxis hängt. Manche Anwendungen brauchen mehrere Ports und gehören trotzdem in eine Regel. Andere Ports derselben Anwendung sind getrennte Zugriffswege und dürfen nie zusammen in eine Regel.

Zwei Dienste kommen nur dann in eine Regel, wenn beide Bedingungen gelten: derselbe Nutzerkreis braucht sie, und sie laufen auf denselben Servern.

Nur ein Feld erlaubt das Zusammenlegen, und die beiden Bedingungen scheitern aus verschiedenen Gründen.

Andere Server. Eine Firewall-Regel erlaubt jede Kombination aus Ziel und Service, sie liest die Felder nicht paarweise. Lege ich eine Weboberfläche auf 443 und eine Dateiablage auf 445 in eine Regel, weil dieselben Clients beides nutzen, werden aus zwei gewollten Freigaben vier. Der Webserver bekommt SMB, den er nie angeboten hat. Das ist ein Aufbaufehler.

Anderer Nutzerkreis. Die getrennten Zugriffswege fallen zusammen, und der kleinere Kreis erbt den Zugriff des größeren. Das ist ein Exposure-Fehler.

Vier Fälle aus dem Alltag:

• Verzeichnisdienst mit vielen Ports, gleiche Nutzer, gleiche Server: eine Regel mit einer Servicegruppe.
• Weboberfläche und Etikettenablage, gleiche Nutzer, andere Server: zwei Regeln.
• Weboberfläche und Admin-Oberfläche auf demselben Server, andere Nutzer: zwei Regeln.
• Weboberfläche und Datenbank, andere Nutzer, andere Server: zwei Regeln.

Der dritte Fall ist der, bei dem am häufigsten falsch zusammengefasst wird. Gleiche Maschine, gleicher Dienst-Typ, und trotzdem zwei Regeln, weil der Nutzerkreis sich unterscheidet.

Die Quelle bestimmt das Exposure#

Ich habe eine Zeit lang formuliert, Ziel und Service seien an die Rolle gekoppelt und die Quelle sei frei kombinierbar. Das ist gefährlich formuliert. Frei ist die Quelle nur von Kombinationsnebenwirkungen: Wer eine Zeile in eine Quellgruppe legt, erzeugt keine neue Ziel-Port-Kombination.

Was er erzeugt, ist Exposure. Das Paar aus Quelle und Port ist die eigentliche Sicherheitsentscheidung. Die Anwendung liefert nur die Zusammenfassung des Ziels, also Objektbildung, Benennung und Lebenszyklus. Das ist ein Ordnungs- und Dokumentationsgewinn, kein Sicherheitsargument.

Praktisch arbeite ich mit einer kleinen Matrix aus Nutzerkreisen und Diensten:

So wird sie gelesen:

• Jede Spalte ist eine Regel. Der Dienst liefert Ziel und Service.
• Die Häkchen einer Spalte sind die Quellgruppe genau dieser Regel.
• Identische Zeilen, also gleich in jeder Spalte, werden zu einer Quellgruppe zusammengefasst. Das ist die Zusammenfassung, die tatsächlich Regeln spart.
• Zeilen, die in einer einzigen Spalte abweichen, bleiben getrennt.

Zeilen darf man zusammenlegen, Spalten nicht. Diese Asymmetrie ist kein Zufall: Innerhalb eines Feldes sind die Mitglieder Alternativen, über Felder hinweg entsteht ein Kreuzprodukt.

Beispiel aus der Praxis: Lagerverwaltung#

Eine Lagerverwaltung mit drei Diensten: Weboberfläche auf zwei Webservern, Datenbank auf einem SQL-Cluster, Etikettenablage auf einem Fileserver. Aus der Matrix oben fallen die Regeln direkt heraus:

Der Client erreicht die Datenbank nicht, obwohl der SQL-Server zur selben Anwendung gehört. In der Datenbankspalte steht bei ihm kein Häkchen. Daran sieht man: Die Gruppierung nach Anwendung macht nichts gröber, sie sortiert nur anders.

Und was passiert bei Änderungen?

Der letzte Punkt setzt eine Disziplin voraus: Eine Objektgruppe gehört zu genau einer Anwendung. Server, die zwei Anwendungen tragen, kommen in zwei Gruppen. Doppelte Mitgliedschaft ist harmlos, geteilte Gruppen sind es nicht, weil man beim Abbau der einen Anwendung die andere mit abreißt.

Grenzen des Modells#

Drei Einschränkungen, die man in der Vorstellungsrunde besser selbst nennt, bevor sie jemand anders stellt.

Die Segmentierung überholt man nicht. Wenn 40 Server in einem flachen Servernetz stehen, sieht die Firewall den Verkehr zwischen ihnen nie. Die anwendungsbezogene Regel filtert dann nur, was von außen hereinkommt. Wer einmal auf einem dieser Server ist, erreicht alle anderen. Die Granularität der Regel kann die Granularität der Segmentierung nicht überbieten. In diesem Fall gewinnt man Übersicht und schnelleres Troubleshooting, und das sollte man dann auch so nennen und nicht als Sicherheitsgewinn verkaufen.

Die Rückrichtung fehlt schnell. Das Modell beschreibt Client zu Server. Backup holt aber Daten, Agenten pushen, Monitoring fragt ab. Entweder gibt es eine bewusste Aussage dazu, oder es entstehen später Einzelregeln neben dem Standard, die niemand kennt.

Die Gruppenpflege wird zur kritischen Aufgabe. Bei 200 Server-Regeln sieht man Fehler in der Regel. Bei 30 Anwendungsregeln sieht man sie in der Gruppe, und dort schaut niemand hin. Wird ein neuer Server in der Zielgruppe vergessen, sieht die Regel völlig korrekt aus. Das ist schwerer zu finden als eine fehlende Regel.

Deshalb gehört zu diesem Modell ein regelmäßiger Abgleich zwischen Gruppenmitgliedschaft und tatsächlichem Serverbestand. Sonst verlagert man das Problem nur.

Aus der Konvention einen Standard machen#

Der letzte Punkt ist mir der wichtigste. Ein Modell, das nur in einer Arbeitsanweisung steht, hält keine zwei Personalwechsel durch. Die Sätze oben sind aber maschinell prüfbar, und über die APIs von FortiManager oder Sophos SFOS kommt man ohne großen Aufwand an das Regelwerk:

• keine Policy mit Quelle all
• an Standort-Regeln kein Service außer ALL
• jede Zielgruppe im Rechenzentrum gehört zu genau einer Anwendung
• kein Server in einer Zielgruppe, den es im Inventar nicht gibt

Das ist der Punkt, an dem aus einer Konvention ein durchsetzbarer Standard wird. Alles andere ist eine Absichtserklärung mit Verfallsdatum.

Wer sich ein bestehendes Regelwerk erst einmal ansehen will, bevor er es umbaut: dafür habe ich Policy Map gebaut, und für die Automatisierung auf Sophos-Seite die SophosFirewall-PowerShell-Module.

Fragen und Antworten#

Was bedeutet destination-based bei Firewall-Regeln?

Der Dienst wird an der Firewall entschieden, die vor dem Ziel steht. Vorgelagerte Firewalls, etwa am Außenstandort, stellen nur Erreichbarkeit zum Zielnetz her und pflegen keine Ports mit. Quelle und Ziel werden trotzdem auf beiden Firewalls als Objekte gesetzt.

Wann gehören mehrere Ports in eine Firewall-Regel?

Wenn derselbe Nutzerkreis alle diese Ports braucht und alle Ports auf denselben Zielservern laufen. Fehlt eine der beiden Bedingungen, sind es getrennte Regeln.

Ist eine Regel pro Server nicht sicherer?

Nein, nur unübersichtlicher. Die Genauigkeit einer Regel hängt an Quelle, Ziel und Service, nicht an der Sortierung des Regelwerks. Eine anwendungsbezogene Regel kann exakt so eng gefasst sein und muss beim Serverzuwachs nicht geklont werden.

Warum sollte die Quelle nie all sein?

Weil dann die gesamte Eingrenzung an einer einzigen Regel im Rechenzentrum hängt. Ist diese Regel zu weit gefasst, gibt es keine zweite Instanz, die den Zugriff noch begrenzt.

Wie viele Firewall-Regeln sind für eine Anwendung normal?

So viele, wie die Anwendung getrennte Zugriffswege hat. Bei einer dreischichtigen Anwendung sind das typischerweise drei bis vier, plus eine Grobregel pro Standort.

Fazit#

Aus dem Ganzen habe ich eine zweiseitige Arbeitsanweisung für das Team gemacht: vorne die fünf Fragen und die Entscheidungsmatrix, hinten ein durchgerechnetes Beispiel. Der Trick daran ist, dass niemand das Modell verstanden haben muss, um es richtig anzuwenden. Das Verständnis kommt beim Anwenden nach.

Für Auszubildende war das der entscheidende Unterschied. Eine Erklärung kann man missverstehen. Eine Reihenfolge kann man abarbeiten.

Tags: Firewall FortiGate Sophos Firewall-Regeln Regelwerk Netzwerksegmentierung Best Practice