Firewall-Migration von portbasiert zu applikationsbasiert: Palo Alto Networks Next Generation Firewalls

Was eine portbasierte Firewall tatsächlich sieht

Eine klassische Firewall entscheidet anhand von Quell-IP, Ziel-IP, Protokoll und Port. Das war sinnvoll, solange ein Port eine Anwendung bedeutete: 25 war Mail, 21 war FTP, 80 war Web.

Diese Zuordnung gilt seit Jahren nicht mehr. Eine Firewall-Migration ist deshalb heute vor allem ein Umbau des Regelwerks und nicht nur ein Hardware-Tausch.

Heute läuft fast alles über HTTPS. Fernwartungs-Software wechselt automatisch auf Port 443, wenn ihr Standardport blockiert ist. DNS-over-HTTPS läuft ebenfalls über Port 443. SSH lässt sich problemlos auf 443 betreiben. Und Malware nutzt für ihre Kommunikation nach draußen genau die Ports, die in jeder Firewall offen sind.

In nahezu jedem Legacy-Regelwerk, das wir übernehmen, finden wir eine Regel wie diese:

Quelle: LAN, Ziel: any, Service: TCP 80, 443, 8080, Aktion: allow, Kommentar: „Internet“

Die Protokollierung dieser Firewall zeigt, dass Verbindungen auf Port 443 erlaubt wurden. Welche Anwendungen dahinterstehen, zeigt sie nicht.

Dazu kommt die Historie. Ein über zehn Jahre gewachsenes KMU-Regelwerk hat schnell 150 bis 400 Regeln, von denen in unseren Assessments regelmäßig ein Viertel keinen einzigen Treffer mehr hat. Warum Port 8443 zu einer bestimmten IP-Adresse offen ist, kann oft niemand mehr beantworten, weil der Administrator, der die Regel angelegt hat, nicht mehr im Unternehmen ist.

Applikationsbasierte Firewall: was App-ID, User-ID und Content-ID leisten

Die Palo Alto Networks NGFW entscheidet auf Basis der identifizierten Anwendung. Der Port ist nur noch ein zusätzliches Kriterium.

App-ID klassifiziert jede Session über Applikations-Signaturen, Protokoll-Decoding und Heuristik. Regeln werden auf Applikationen geschrieben: ms-teams, ms-onedrive, ssh, datev. Mit application-default wird SSH auf Port 443 nicht mehr von der Web-Regel erlaubt, sondern blockiert und protokolliert.

Mit User-ID ersetzt „Die Buchhaltung darf DATEV nutzen“ die Regel „10.10.20.0/24 darf auf TCP 443“. Die Benutzerinformationen liest die Firewall aus Active Directory, aus GlobalProtect oder aus einem Captive Portal aus. Wechselt ein Mitarbeiter die Abteilung, ändert sich seine Berechtigung mit der AD-Gruppe, ohne Änderung am Firewall-Regelwerk.

Content-ID umfasst Threat Prevention gegen Exploits und Malware, Advanced URL Filtering, WildFire und DNS Security gegen C2-Domains und DNS-Tunneling. Diese Funktionen sind als Subscriptions separat lizenziert, dazu unten mehr.

Für den Betrieb bedeutet das: Regeln beschreiben, welche Benutzergruppe welche Anwendung nutzen darf. Jede Freigabe ist damit fachlich begründbar und lässt sich bei einem Audit einer Abteilung und einem Zweck zuordnen.

Visibilität: der eigentliche Gewinn der Migration

NGFW-Projekte werden meist mit dem Sicherheitsgewinn begründet. In der Praxis ist es aber die Transparenz über den Datenverkehr, die unsere Kunden in den ersten Wochen nach der Umstellung am meisten überrascht.

Welche Anwendungen im Netz tatsächlich laufen

Schon wenn die alten Portregeln noch unverändert übernommen sind, klassifiziert die Palo Alto Networks NGFW jede Session per App-ID. Im Application Command Center (ACC) ist das ab dem ersten Tag sichtbar, einschließlich der Datenmenge pro Applikation.

Was wir in den ersten 14 Tagen typischerweise finden:

• Fernwartungs-Tools wie TeamViewer oder AnyDesk, die niemand freigegeben hat, teilweise von Dienstleistern auf Maschinen im Produktionsnetz installiert.
• Private Cloud-Speicher und Filesharing-Dienste, über die Firmendaten das Unternehmen verlassen.
• Veraltete Protokolle wie SMBv1, Telnet oder unverschlüsseltes FTP, die intern noch aktiv sind.
• Verkehr, den die Firewall als unknown-tcp oder unknown-udp einstuft. Das sind meist proprietäre Industrie- oder Branchenanwendungen, gelegentlich aber auch nicht autorisierte Software oder Tunnel-Verbindungen.

Auch in Umgebungen, in denen laut IT ausschließlich freigegebene Standard-Software läuft, zeigt die erste Auswertung im ACC in aller Regel mehrere dieser Funde.

Vom Port zur Anwendung: Policy Optimizer

Für die Migration selbst ist der Policy Optimizer zentral. Aus „TCP 443 erlaubt“ wird eine konkrete Liste, zum Beispiel ms-office365, zoom, web-browsing, ssl und drei Applikationen, die in keinem Freigabeprozess auftauchen.

Diese Liste ist die Grundlage, um Regel für Regel in eine App-ID-Regel zu überführen, ohne dass eine legitime Anwendung ausfällt.

Visibilität bei der Aufklärung von Sicherheitsvorfällen

Den größten Nutzen hat die Transparenz über den Datenverkehr nach einem Sicherheitsvorfall. Mit einer portbasierten Firewall lautet die Aussage: „Von 10.0.30.17 gingen gestern Abend 4 GB über Port 443 an eine IP-Adresse in Osteuropa.“ Mit einer NGFW lautet sie: „Benutzer m.mueller hat gestern um 22:14 Uhr 4 GB über einen Filesharing-Dienst hochgeladen, die URL-Kategorie war als riskant eingestuft, DNS Security hatte die Zieldomain bereits als verdächtig markiert.“

Mit der ersten Aussage beginnt die Forensik erst. Die zweite beantwortet die Frage, die Geschäftsführung, Versicherung und gegebenenfalls Datenschutzbehörde als Erstes stellen: welche Daten, wer, wohin.

Auswertung der Firewall-Logs im Betrieb

Die Logs der Firewall sind nur dann nützlich, wenn sie ausgewertet werden. Wir leiten Traffic-, Threat- und System-Logs an eine zentrale SIEM- oder XDR-Plattform weiter, zum Beispiel Graylog, Palo Alto Networks Cortex XDR, Palo Alto Networks Cortex XSIAM oder andere. Dort werden sie mit Events aus Endpoints, Active Directory und weiteren Systemen korreliert und länger vorgehalten, als es der lokale Speicher kleinerer Appliances zulässt. Welche Plattform passt, hängt davon ab, wie viel Auswertung im eigenen Team bleiben soll und wie weit die Automatisierung bei der Reaktion auf Vorfälle gehen soll.

Die CheckMK-Überwachung erfasst Session-Auslastung, HA-Status, Lizenzlaufzeiten und Content-Update-Stand und alarmiert bei Abweichungen. In Grafana-Dashboards werten wir die Kapazität aus, damit ein Sizing-Engpass erkennbar wird, bevor er den Betrieb beeinträchtigt.

Grenzen der Visibilität bei verschlüsseltem Verkehr

Auch ohne Entschlüsselung erkennt App-ID sehr viele Anwendungen anhand von TLS-Handshake, Server Name Indication und Zertifikat. In den Inhalt einer verschlüsselten Session schauen Threat Prevention und WildFire aber nur, wenn SSL/TLS-Decryption für diesen Verkehr aktiv ist.

Decryption reduziert den Durchsatz der Firewall, erfordert ein auf allen Clients verteiltes Zertifikat der internen CA und braucht klare Ausnahmen für Online-Banking, Gesundheitsportale und Anwendungen mit Certificate Pinning. In Deutschland kommt ein Punkt dazu, den viele Projektpläne nicht vorsehen: Sobald die Firewall Verkehr benutzerbezogen auswertet oder entschlüsselt, ist das in aller Regel ein Thema für Betriebsrat (§ 87 Abs. 1 Nr. 6 BetrVG) und Datenschutzbeauftragten. Die Betriebsvereinbarung sollte deshalb vor Projektbeginn abgestimmt sein, weil sie festlegt, welche Auswertungen und Entschlüsselungen überhaupt zulässig sind.

So läuft die Migration auf Palo Alto Networks NGFW in der Praxis ab

Die meisten Störungen bei einer Firewall-Migration im KMU entstehen, wenn Hardware-Tausch und Umbau des Regelwerks im selben Wartungsfenster stattfinden. Wir trennen beide Schritte deshalb strikt.

Phase 1: Bestandsaufnahme und Bereinigung

Wir exportieren das bestehende Regelwerk, werten die Hit-Counts aus und bereinigen, bevor migriert wird: Regeln ohne Treffer, doppelte Objekte, verwaiste NAT-Regeln. Parallel gleichen wir Netze, VLANs und Zonen mit NetBox ab, unserer Source-of-Truth für IP-Adressverwaltung und Netzdokumentation. Was dort nicht dokumentiert ist, wird es spätestens jetzt.

Phase 2: Zonenmodell und Sizing

Das Zonenmodell entscheidet über die Qualität des späteren Regelwerks. Mindestens Clients, Server, Management, Gäste, DMZ und, wo vorhanden, das Produktionsnetz sollten eigene Zonen sein.

Beim Sizing zählt nicht der Firewall-Durchsatz im Datenblatt, sondern der Threat-Prevention-Durchsatz mit aktivierter Decryption. Palo Alto Networks bietet dafür verschiedene Modelle an, von kompakten Appliances für kleine Standorte bis zu Plattformen mit deutlich mehr Leistungsreserve. Welches Modell passt, leiten wir aus dem realen Verkehrsaufkommen des Kunden, der geplanten Decryption-Quote, der Zahl der Standorte und dem erwarteten Wachstum ab, nicht aus einer Standardempfehlung. In aller Regel planen wir ein HA-Paar, weil ein einzelnes Gerät ein Single Point of Failure für das gesamte Unternehmen ist.

Phase 3: Funktionsgleiche Übernahme und Cutover

Im ersten Schritt übernehmen wir die bereinigten Portregeln funktional unverändert auf die neue Plattform. Die Konvertierung erfolgt manuell, Regel für Regel. Wo sich Muster wiederholen, etwa bei großen Mengen an Adress- und Service-Objekten oder gleichförmigen NAT-Regeln, setzen wir eigene Skripte ein. Der manuelle Weg kostet etwas mehr Zeit, stellt aber sicher, dass jede Regel geprüft ist, bevor sie produktiv geht. Dabei fallen Regeln auf, die eine automatische Konvertierung unbemerkt übernehmen würde: Freigaben für längst abgeschaltete Server, überbreite Any-Regeln und Ausnahmen, die für ein abgeschlossenes Projekt angelegt wurden.

Der Cutover findet im Wartungsfenster statt, mit dokumentiertem Rückweg auf die bisherige Firewall. Am Tag danach verhält sich das Netz exakt wie vorher. Der einzige Unterschied: Die Firewall klassifiziert und protokolliert jetzt jede Session per App-ID. Weil sich das Verhalten des Regelwerks nicht ändert, verläuft der Cutover für die Anwender geräuschlos.

Phase 4: Lernphase und Umbau auf App-ID

Jetzt kommt der Policy Optimizer zum Einsatz, über einen Zeitraum von mindestens vier Wochen. Auch Palo Alto Networks empfiehlt, den Großteil der Regeln erst nach 30 Tagen Beobachtung umzustellen. Danach bauen wir Regel für Regel um: Applikationen explizit eintragen, Service auf application-default setzen, nicht freigegebene Anwendungen mit dem Fachbereich klären.

Was dabei regelmäßig unterschätzt wird: Anwendungen, die nur zum Monatsabschluss, zur Lohnabrechnung oder einmal im Quartal laufen. Wird die Lernphase nach zwei Wochen beendet, fehlen diese Anwendungen in den App-ID-Regeln und werden am ersten Werktag des nächsten Monats blockiert.

Phase 5: Härtung

Erst wenn das Regelwerk vollständig applikationsbasiert ist, aktivieren wir die Security Profiles durchgängig, führen Decryption stufenweise ein und entfernen die letzten Any-Regeln. Remote-Mitarbeiter binden wir über GlobalProtect an, damit für Notebooks außerhalb des Büros dieselben App-ID- und User-ID-Regeln gelten wie im LAN.

Kosten und Aufwand einer applikationsbasierten Firewall

Die Migration auf eine applikationsbasierte Firewall verursacht neben der Hardware laufende Kosten und internen Aufwand. Drei Punkte gehören in jede Entscheidungsvorlage.

Laufende Lizenzkosten. Die Schutzfunktionen hängen an jährlichen Subscriptions. Ohne Threat Prevention, URL Filtering und DNS Security steht von der NGFW im Wesentlichen App-ID zur Verfügung. Das bietet bereits deutlich mehr Kontrolle als eine portbasierte Firewall, nutzt die Schutzfunktionen der Plattform aber nur teilweise.

Aufwand der Lernphase. Die Umstellung auf App-ID kostet Zeit, beim Dienstleister und beim Kunden. Für jede neu erkannte Anwendung muss intern jemand entscheiden, ob sie freigegeben wird, in der Regel die IT-Leitung gemeinsam mit dem jeweiligen Fachbereich.

Content-Updates brauchen einen Prozess. Eine neue App-ID-Signatur kann Verkehr, der bisher unter ssl lief, einer eigenen Applikation zuordnen, die in keiner Regel steht. Das lässt sich steuern, etwa mit verzögerter Installation und einer Prüfung der neuen App-IDs vor der Aktivierung. Dieser Prozess muss aber eingerichtet und gepflegt werden.

Ob sich der Aufwand rechnet, hängt davon ab, was ein Ausfall kostet. Fünf bis acht Beratertage für eine vollständige Lernphase fallen kaum ins Gewicht, wenn ein Ransomware-Vorfall einen Fertiger eine Woche lang stilllegen kann. Der Umsatzausfall dieser Woche entsteht, bevor Wiederherstellung und Forensik überhaupt beginnen.

Was bei der Firewall-Migration oft übersehen wird

• „Temporäre“ Portregeln. Jede Regel, die bei der Umstellung „erst einmal“ portbasiert bleibt, braucht ein Enddatum im Ticket. Ohne Enddatum ist sie in fünf Jahren meist noch aktiv.
• Applikations-Abhängigkeiten. Viele Applikationen setzen andere voraus, etwa ssl oder web-browsing. PAN-OS zeigt diese Abhängigkeiten an. Werden sie nicht in die Regel übernommen, fällt die Anwendung nicht zwingend vollständig aus. Möglich ist auch eine Funktionseinschränkung: Die Anmeldung gelingt, aber Dateiupload, Videofunktion oder Synchronisation funktionieren nicht. Weil die Anwendung grundsätzlich erreichbar ist, wird die fehlende Abhängigkeit als Ursache oft erst spät erkannt.
• Log-Retention. Die lokale Speicherkapazität kleiner Appliances reicht für wenige Tage bis Wochen. Für Incident Response werden Protokolldaten über Monate benötigt, also gehört die Log-Weiterleitung an die zentrale SIEM- oder XDR-Plattform ins Projekt und nicht in eine spätere Ausbaustufe.
• Wissen im eigenen Team. Neue Anwendungen und auffällige Benutzer fallen im ACC nur dann rechtzeitig auf, wenn intern jemand die Auswertungen regelmäßig prüft. Eine kurze Einweisung der internen Administratoren gehört zum Projektumfang.

Netzwerk-Spezialist oder Systemhaus: wer sollte die Migration begleiten?

Eine Palo Alto Networks NGFW installieren, Regeln konvertieren und in Betrieb nehmen kann jedes Systemhaus. Entscheidend sind die Wochen danach: welche App-ID eine proprietäre Maschinensteuerung braucht, warum eine Branchensoftware nach dem Content-Update plötzlich als neue Applikation auftaucht und wie viel Decryption die gewählte Appliance tatsächlich verkraftet.

Diese Wochen begleiten wir. Wir machen Netzwerk und Cyber-Security, keine Server, kein Storage, keine Arbeitsplatz-Rollouts, und Palo Alto Networks gehört zu unseren Kernherstellern. Bei der Entscheidungsfindung bewerten wir das bestehende Regelwerk des Kunden, rechnen Sizing und Lizenzbedarf auf Basis seines realen Verkehrs und liefern eine Entscheidungsvorlage mit Kosten, die auch nach dem dritten Lizenzjahr noch stimmen. In der Umsetzung begleiten wir Migration, Lernphase und Härtung bis zum fertigen App-ID-Regelwerk und binden die Firewall in die CheckMK-Überwachung und in die zentrale SIEM- oder XDR-Plattform des Kunden ein, ob Graylog, Cortex XDR, Cortex XSIAM oder andere.

Wie viel Betrieb nach Projektabschluss beim eigenen Team bleibt und was wir übernehmen, legen wir mit dem Kunden vor dem Go-live fest.

Fazit

Ob sich die Migration von einer portbasierten auf eine applikationsbasierte Firewall lohnt, hängt davon ab, wie genau ein Unternehmen heute weiß, was in seinem Netz läuft. Bei gewachsenen Regelwerken mit offenen Web-Ports, unklaren Ausnahmen und ohne benutzerbezogene Protokollierung ist der Nutzen in aller Regel hoch: Die Transparenz über den Datenverkehr ist die Voraussetzung für Segmentierung, für Freigaben nach Benutzergruppen und für eine belastbare Aufklärung von Sicherheitsvorfällen.

Den Aufwand bestimmen vor allem Lernphase, Lizenzen und Decryption. Ein Ablauf in getrennten Phasen hält das Betriebsrisiko gering.

Wir als Gigahertz begleiten Unternehmen bei Planung, Umsetzung und Betrieb dieser Migration und betreiben Palo Alto Networks NGFW täglich in Kundenumgebungen.

Häufige Fragen zur Firewall-Migration

Glossar

ACC (Application Command Center)

Auswertungsoberfläche der Palo Alto Networks NGFW. Zeigt Anwendungen, Benutzer, URL-Kategorien und erkannte Bedrohungen im Netz.

App-ID

Verfahren, mit dem die Firewall die Anwendung einer Session erkennt, unabhängig vom verwendeten Port.

application-default

Service-Einstellung in einer Regel. Erlaubt eine Anwendung nur auf den Ports, die für sie standardmäßig vorgesehen sind.

Certificate Pinning

Eine Anwendung akzeptiert nur ein bestimmtes Server-Zertifikat. Eine Entschlüsselung durch die Firewall lässt sie deshalb nicht zu.

Command-and-Control (C2)

Kommunikationskanal, über den Schadsoftware Befehle eines Angreifers empfängt und Daten ausleitet.

Content-ID

Prüfung der Inhalte innerhalb einer erlaubten Anwendung, etwa auf Exploits, Malware oder verdächtige Domains.

Content-Update

Regelmäßige Aktualisierung der Applikations- und Bedrohungssignaturen durch den Hersteller.

Cutover

Umschaltung von der bisherigen auf die neue Firewall im Wartungsfenster.

DNS-over-HTTPS (DoH)

Namensauflösung über verschlüsseltes HTTPS statt über klassisches DNS. Umgeht ohne Gegenmaßnahme den internen DNS-Server.

HA-Paar (High Availability)

Zwei Firewalls im Verbund. Fällt ein Gerät aus, übernimmt das zweite.

Hit-Count

Zähler, wie oft eine Firewall-Regel tatsächlich angewendet wurde.

Policy Optimizer

Funktion in PAN-OS, die für jede portbasierte Regel anzeigt, welche Anwendungen tatsächlich darüber gelaufen sind.

Security Profiles

Prüfprofile, die einer Regel zugewiesen werden, zum Beispiel Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering und WildFire.

SIEM (Security Information and Event Management)

Plattform, die Logs aus vielen Quellen sammelt, korreliert und für Auswertung und Alarmierung vorhält.

Single Point of Failure

Komponente, deren Ausfall den gesamten Dienst unterbricht.

Sizing

Dimensionierung der Firewall nach Durchsatz, Sessions und Funktionsumfang.

SSL/TLS-Decryption

Entschlüsselung verschlüsselter Verbindungen durch die Firewall, damit deren Inhalt geprüft werden kann.

User-ID

Zuordnung von IP-Adressen zu Benutzern und Gruppen, damit Regeln auf Benutzer statt auf Subnetze geschrieben werden können.

WildFire

Cloud-Analyse von Palo Alto Networks für unbekannte Dateien und Links.

XDR (Extended Detection and Response)

Plattform, die Ereignisse von Endpoints, Netzwerk und weiteren Quellen zusammenführt und die Reaktion auf Vorfälle unterstützt.

Quellen und fachliche Grundlage

Fachliche Prüfung: 17.10.2026. Die Aussagen beziehen sich auf PAN-OS 11.x und 12.x. Funktionsumfang und Lizenzierung können sich mit neuen Releases ändern und sind vor einer konkreten Umsetzung ggf. erneut zu prüfen.

• Palo Alto Networks: App-ID Overview
• Palo Alto Networks: Safely Enable Applications on Default Ports (application-default)
• Palo Alto Networks: User-ID Overview
• Palo Alto Networks: Migrate Port-Based to App-ID Based Security Policy Rules (Policy Optimizer)
• Palo Alto Networks: Best Practices, Rules to Begin Converting After 30 Days
• Palo Alto Networks: Predefined Decryption Exclusions (Certificate Pinning)
• BSI IT-Grundschutz: NET.3.2 Firewall (Edition 2023)
• Betriebsverfassungsgesetz: § 87 Mitbestimmungsrechte

Weiterführend

• Vom Virenscanner zu XDR: Migration auf Cortex XDR
• Netzwerk-Lösungen der Gigahertz GmbH
• Über uns: Warum wir nur Netzwerk machen

Titelbild: KI-generiert.