Sophos Firewall Application Control einrichten und testen

Application Control erkennt Anwendungsverkehr, der sich über Ports allein nicht sinnvoll unterscheiden lässt. So kann eine Sophos Firewall beispielsweise Remote-Control-Tools, Tunneling-Anwendungen, Streaming oder Cloud Storage gezielt erlauben oder sperren. Protokolliert wird der Treffer über die zugehörige Firewall-Regel; ein Application Filter besitzt keine eigene Aktion Log.

Der Kernablauf ist kurz: Unter Applications > Application filter erstellt man den Filter, weist ihn unter Rules and policies > Firewall rules der tatsächlich getroffenen Regel zu und prüft danach Rule ID, Anwendung und Aktion mit einem echten Client. Eine gespeicherte Filter Policy allein verändert keinen Traffic.

Voraussetzungen und Ziel festlegen

Application Control gehört zur Web Protection Subscription. Den Lizenzstatus prüft man unter Administration > Licensing. Vor der Konfiguration sollten ausserdem feststehen:

• der betroffene Benutzer- oder Netzbereich und seine IPv4-/IPv6-Pfade;
• die Anwendung oder Gruppe, die zunächst beobachtet oder gesperrt werden soll;
• die Firewall-Regel, die diesen Traffic aktuell verarbeitet;
• ein Testclient, ein reproduzierbarer Testaufruf und das erwartete Ergebnis;
• der aktuell zugewiesene Application Filter, die Regelposition und die bestehende NAT-Zuordnung als Ausgangszustand für den Rückbau.

Unter Backup & firmware > Pattern updates kontrolliert man die Signaturupdates. Sie laufen standardmässig automatisch; Update pattern now aktualisiert bei Bedarf alle Pattern-Definitionen ausser den Firmware-Patterns für AP und RED. Die Statuswerte Ready to install, Downloading, Success und Failed helfen bei der Eingrenzung. Application-Signaturen bleiben auch ohne aktive IPS-Lizenz verfügbar, während IPS-Signaturen eine passende Lizenz und aktiviertes IPS benötigen.

Für die Testregel wird Log firewall traffic eingeschaltet. Das Logging steuert die Firewall-Regel, nicht der Application Filter. Wer nur beobachten möchte, verwendet deshalb einen erlaubenden Filter und wertet den erkannten Traffic aus, bevor einzelne Anwendungen auf Deny gesetzt werden.

Wenn Priorisierung oder Bandbreitenbegrenzung das eigentliche Ziel ist, ergänzt Application Traffic Shaping auf Sophos Firewall konfigurieren den Filter. Für anwendungsbasierte SD-WAN-Routen wird dagegen ein Application Object verwendet; den Ablauf zeigt Sophos Firewall SD-WAN Route mit Gateway-Failover einrichten.

Application Filter planen und erstellen

Unter Applications > Application list sieht man, ob Sophos eine eigene Signatur führt und welcher Kategorie beziehungsweise welchem Risiko sie aktuell zugeordnet ist. Beim Filter Name stehen contains, is, is not und does not contain zur Verfügung. Ein Katalogtreffer beweist noch nicht, dass die Anwendung im eigenen Netz erkannt wird; dafür folgt später der Clienttest.

Eine feste Auswahl einzelner Anwendungen ist gut vorhersehbar. Kriterien wie Risk, Category oder die nur für Cloud-Anwendungen verfügbare Classification bleiben dagegen dynamisch: Neue oder neu klassifizierte Signaturen können künftig ebenfalls matchen. Solche Regeln brauchen einen dokumentierten Owner und einen Review nach Pattern- oder Klassifizierungsänderungen.

Der vollständige Pfad für eine Policy und ihre Regel lautet:

Applications > Application filter > Add
Applications > Application filter > Edit policy > Add

1. Unter Add einen eindeutigen Namen vergeben, zum Beispiel Block_File_Transfer_Pilot.
2. Ein Template wählen. Für eine gezielte Sperre ist Allow All ein nachvollziehbarer Ausgangspunkt; man sollte nicht voraussetzen, dass jede leere neue Policy automatisch so arbeitet.
3. Policy speichern, erneut öffnen und mit Add eine Filterregel anlegen.
4. Entweder Select Individual Application verwenden oder mit Select All die Treffer über Application, Category, Risk, Characteristics, Technology, Classification oder Smart Filter eingrenzen.
5. Action auf Allow oder Deny setzen.
6. Unter Schedule beispielsweise All the time wählen oder einen passenden Zeitplan zuweisen.
7. Zuerst die Filterregel und danach die Policy speichern.

SFOS liefert unter anderem die Templates Allow All, Deny All, Block filter avoidance apps, Block generally unwanted apps, Block high risk (Risk Level 4 and 5) apps, Block peer to peer (P2P) networking apps und Block very high risk (Risk Level 5) apps. Ein Template ist ein Startpunkt, kein fertiger Standard. Besonders Risk- und Category-Regeln werden vor der breiten Zuweisung mit den im eigenen Netz benötigten Anwendungen verglichen.

Zeitabhängige Regeln benötigen einen passenden Schedule. Wie man ihn erstellt und gegen Firewall-Zeit und Fallback-Regeln prüft, beschreibt Sophos Firewall Zeitpläne für Regeln und Policies einrichten.

Beispiel: Browserbasierte File-Transfers sperren

Das offizielle Beispiel lässt andere File-Transfer-Anwendungen unberührt und grenzt nur browserbasierte Übertragungen ein:

1. Policy Block_File_Transfer_Pilot aus Allow All erstellen und erneut öffnen.
2. Mit Add > Select All eine Regel anlegen.
3. Category: File Transfer, Characteristics: Transfer files und Technology: Browser Based wählen.
4. Action: Deny und Schedule: All the time setzen.
5. Filterregel und Policy speichern.

Auch diese Auswahl kann legitime Upload-, Collaboration- oder Backup-Abläufe treffen. Der Pilotclient sollte deshalb sowohl einen zu sperrenden Transfer als auch einen ausdrücklich erlaubten Geschäftsdienst aus demselben Geltungsbereich testen.

Filter der richtigen Firewall-Regel zuweisen

Application Control wirkt erst in einer Firewall-Regel. Für eine neue Regel lautet der aktuelle Pfad:

Rules and policies > Firewall rules
> IPv4 oder IPv6
> Add firewall rule
> New firewall rule
> Other security features
> Identify and control applications (App control)

Bei einer bestehenden Regel öffnet man direkt Other security features und wählt dort den vorbereiteten Application Filter. Log firewall traffic bleibt für Pilot und Abnahme aktiv.

Die Regel muss Source Zone, Source Network, Destination Zone, Destination Network, Services und gegebenenfalls Match known users des Testclients wirklich treffen. Firewall-Regeln werden von oben nach unten ausgewertet; der erste Treffer beendet die Suche. Eine allgemeinere Regel weiter oben ist deshalb eine häufigere Ursache als der Application Filter selbst.

Bei einer neuen Internetregel muss auch der NAT-Pfad stimmen. Sophos-Beispiele können mit Create linked NAT rule eine MASQ-Regel erzeugen. In einer bestehenden Umgebung wird keine zweite NAT-Regel auf Verdacht angelegt; stattdessen prüft man die bereits wirksame SNAT-/MASQ-Regel und notiert ihre NAT Rule ID.

IPv4 und IPv6 haben eigene Regelpfade. Nutzt der Client beide Protokolle, werden beide getestet oder der Pilot wird bewusst auf eines begrenzt. Die Regelgrundlagen erklärt Sophos Firewall-Regeln verstehen und sicher konfigurieren.

Wirkung mit Live Connections und Log Viewer nachweisen

Ein belastbarer Test beantwortet drei getrennte Fragen: Welche Regel verarbeitet den Flow, welche Anwendung erkennt SFOS und welche Aktion wird ausgeführt?

1. Testclient, Quell-IP, Benutzer, Uhrzeit und Ziel notieren.
2. Optional in den Optionen der Pilotregel Reset data transfer count ausführen, damit neue Bytes leichter zugeordnet werden können.
3. Den Testaufruf starten und die noch offene Verbindung unter Current activities > Live connections prüfen.
4. Dort Application, Source IP, Username, Interfaces, Quell-/Zielports, Firewall Rule ID und NAT Rule ID mit dem geplanten Pfad vergleichen.
5. Den Log viewer oben rechts im WebAdmin öffnen und nach Quell-IP, Benutzer, Ziel, Rule ID und Anwendung filtern.
6. Einen erwarteten Block und einen erlaubten Kontrollaufruf aus demselben Scope ausführen.

Ein verweigerter Application-Filter-Treffer erscheint als Content Filtering > Application > Denied. Erlaubter, erkannter Traffic steht im Firewall-Log unter Firewall > Firewall Rule > Allowed. Für die Abnahme werden mindestens Firewall Rule ID, Application Filter, Anwendung, Kategorie, Risiko, Aktion, Benutzer, Quelle und Ziel dokumentiert.

Firewall-Sessions erscheinen häufig erst beim Connection Destroy event, wenn SFOS die Verbindung schliesst. Eine noch offene Browser- oder Streaming-Session kann deshalb bereits unter Live connections sichtbar sein, obwohl ihr abschliessender Firewall-Logeintrag fehlt. SSL/TLS-Verbindungen werden nach abgeschlossenem Handshake und beim Schliessen protokolliert.

Unter Reports > Dashboards > Traffic dashboard > Allowed policies lassen sich die übertragenen Daten der erlaubenden Regeln zusätzlich kontrollieren. Der Bericht ersetzt den konkreten Rule-ID- und Anwendungstest jedoch nicht.

Bei Syslog oder SIEM unterscheiden sich die Feldnamen je nach Ausgabeformat. Das Central Reporting Format verwendet unter anderem fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier und status. Im Device Standard Format (Legacy) heissen entsprechende Felder beispielsweise application_filter_policy, application_name, application_category, application_risk und appresolvedby. app_resolved_by beziehungsweise appresolvedby unterscheidet unter anderem Signature, Proxy und Synchronized Application Control (EAC).

Technische Application-Filter- und DPI-Ereignisse landen in ips.log; sig_upgrade.log und sigmigration.log helfen bei Signaturupdates. Die Logzuordnung beschreibt Sophos Firewall Troubleshooting: Services und Logs. Packet Capture kann IPs, Ports, Interface und Paketweg bestätigen, ist aber kein Beweis für die Anwendungsklassifizierung. Den kombinierten Diagnoseweg zeigt Sophos Firewall Regel testen mit Log Viewer, Policy Test und Packet Capture.

HTTPS, QUIC und Web-Ausnahmen einordnen

Viele signaturbasierte Anwendungen erkennt SFOS auch ohne vollständige Entschlüsselung. URL-basierte Micro Apps wie Dateiübertragungen in Dropbox oder Gmail benötigen in verschlüsseltem Traffic jedoch die entschlüsselte URL. Im DPI-Pfad braucht es dafür eine passende Regel unter Rules and policies > SSL/TLS inspection rules. Scan HTTP and decrypted HTTPS aktiviert Malware-Scanning für bereits entschlüsseltes HTTPS, schaltet die Entschlüsselung aber nicht selbst ein.

Im Web-Proxy-Pfad übernimmt Decrypt HTTPS during web proxy filtering die Entschlüsselung. Eine vorhandene Web Policy beweist weder, dass HTTPS entschlüsselt wird, noch dass dieselbe DPI-Regel greift. Der kontrollierte Rollout steht in Sophos Firewall TLS Inspection richtig einführen.

Block QUIC protocol verwirft im Geltungsbereich der Firewall-Regel ausgehende UDP-Pakete zu Port 80 und 443, damit Clients auf einen prüfbaren TCP-Pfad zurückfallen. SFOS wählt die Option standardmässig aus, sobald eine Web Policy gewählt oder Scan HTTP and decrypted HTTPS aktiviert wird. QUIC kann vom Webfilter nicht gescannt werden; daraus folgt aber nicht, dass jede andere Firewall-Kontrolle umgangen wird. Sophos Firewall QUIC und HTTP/3 richtig blockieren beschreibt den Positiv- und Negativtest.

Bei unerwarteter Erkennung werden auch Web > Exceptions geprüft. Eine Web Exception kann Decryption, Malware-/Content-Scanning und Policy Checks überspringen und gilt je nach Auswahl im DPI- sowie im Proxy-Pfad. Eine breite Ausnahme kann daher den erwarteten Anwendungskontext entfernen.

Ein Firewall-Log mit Allowed beweist bei Web-Proxy-Traffic nicht automatisch einen erlaubten Benutzerzugriff: Die Firewall kann die Verbindung zunächst an den Proxy übergeben, während der Web Filter sie anschliessend als Blocked protokolliert. Für solche Fälle werden Firewall- und Web-Log gemeinsam gelesen.

Cloud-Anwendungen klassifizieren

Unter Applications > Cloud applications zeigt SFOS nur erlaubten Traffic und nur Anwendungen, für die Traffic vorhanden ist. Die Ansicht kann nach Datum, Classification, Category und übertragenen Bytes gefiltert werden; Expand öffnet Details. Ein fehlender Eintrag schliesst deshalb einen blockierten Versuch nicht aus.

Neue Cloud-Anwendungen tragen zunächst die Classification new. Über Classify weist man nach Prüfung sanctioned, unsanctioned oder tolerated zu. Die neue Classification gilt für neuen Traffic und erlaubt oder sperrt für sich allein nichts. Erst ein Application Filter, der dieses Kriterium verwendet und einer zutreffenden Firewall-Regel zugewiesen ist, setzt die gewünschte Aktion um.

Grundlegende Nutzungs- und Byte-Daten benötigen Firewall-Logging. Upload-/Download-Zähler und Dateitypdetails setzen HTTPS-Decryption voraus; eine Web Policy ungleich None verbessert nach Sophos-Angaben zusätzlich Genauigkeit und Detailtiefe. Manche Anwendungen verwenden eigene Übertragungsmechanismen, sodass einzelne Detailfelder trotzdem leer bleiben können.

Über Traffic shaping lässt sich einer erkannten Cloud-Anwendung eine vorbereitete Bandbreiten-Policy zuweisen. Diese Zuweisung ersetzt weder den Application Filter noch die Firewall-Regel.

Sonderfälle: Online-Speicher und Facebook-Videos

Das offizielle Google-Drive-Beispiel kombiniert den Application Filter Block_GoogleDrive mit der Web Policy BlockPersonalStorage. Der Filter entsteht aus Allow All, sucht mit Smart Filter nach google drive und setzt die ausgewählten Anwendungen auf Deny und All the time. In Web > Policies wählt man für die enge Storage-Regel All web traffic ab, sucht über Add new item > Web category nach personal und setzt die passenden Kategorien auf Block HTTP und Block HTTPS. Beide Policies müssen derselben tatsächlich getroffenen Firewall-Regel zugewiesen sein. Web Protection auf Sophos Firewall einrichten erklärt die Policy-Mechanik.

Beim Facebook-Video-Beispiel wählt man im Application Filter über Select Individual Application die Treffer für Facebook videos. Zusätzlich nennt Sophos für eine benutzerdefinierte Kategorie derzeit facebook.com/watch, facebook.com/reel, gateway.facebook.com, facebook.com/ajax und facebook.com/stories sowie die Keywords watch, reel, gateway, ajax und videos. Diese Werte sind ein versionsbezogener Ausgangspunkt und werden vor dem Einsatz kontrolliert, weil breite Keywords auch andere Pfade treffen können. Die Kategorie muss in einer Web-Policy-Regel mit einer blockierenden Aktion liegen; das aktuelle Facebook-Verfahren benennt diese Aktion nicht so ausdrücklich wie das Storage-Beispiel.

Das Sophos-Beispiel verwendet den Web Proxy, entschlüsselt HTTPS und sperrt QUIC. Dafür müssen die Clients der Sophos Firewall CA vertrauen. Eine bestehende DPI-Umgebung wird nicht allein für diesen Sonderfall umgestellt; dort verwendet man eine passende SSL/TLS Inspection Rule. Den Weg für eigene Kategorien zeigt Web-Kategorien auf Sophos Firewall erstellen, die CA-Verteilung Sophos Firewall CA-Zertifikat für HTTPS-Scanning verteilen.

Synchronized Application Control gezielt nutzen

Synchronized Application Control ergänzt die Netzwerkerkennung um Daten verwalteter Sophos Endpoints. Zusätzlich zur Web Protection Subscription benötigt es Security Heartbeat, eine Network Protection Subscription, einen Sophos-Fusion-Account (früher Sophos Central) und einen verwalteten Endpoint mit Test- oder Volllizenz.

Die Registrierung erfolgt unter:

System > Sophos Central > Sophos Central registration > Register

Nach erfolgreicher Registrierung aktiviert SFOS Security Heartbeat und Synchronized Application Control automatisch. Wird Security Heartbeat ausgeschaltet, ist auch Synchronized Application Control aus; das ist deshalb kein enger Rollback für eine einzelne Anwendung.

Für die erste Nutzung prüft man nach der Registrierung in Sophos Fusion (früher Sophos Central), dass Synchronized Application Control eingeschaltet ist, und aktiviert es bei Bedarf. Die auf der Firewall angelegte Domain muss mit der auf dem Endpoint ausgewählten Domain übereinstimmen.

Unter Applications > Synchronized Application Control sucht man nach Name, Pfad, Kategorie oder Endpoint und erweitert den Eintrag für die Vorkommen. Sophos unterstützt bis zu 15'000 Anwendungen. Seit SFOS 20.0 MR1 speichert SFOS nur die fünf neuesten Vorkommen jeder Anwendung pro Endpoint.

Bei einer Migration auf SFOS 21.0 oder neuer aktiviert SFOS die automatische Bereinigung nur, wenn Synchronized Application Control (SAC) eingeschaltet ist. Der Standardzeitraum beträgt zwölf Monate. War zuvor ein eigener Zeitraum konfiguriert, bleibt dieser erhalten. Ist SAC ausgeschaltet, bleiben sowohl SAC als auch die automatische Bereinigung ausgeschaltet. Individuell hinzugefügte Anwendungen entfernt die Bereinigung auch aus Application Filtern. Bei einer Migration auf SFOS 20.0 MR1 oder neuer löscht SFOS ältere Vorkommen; scheitert die automatische Bereinigung wegen zu wenig Speicher, verweist Sophos an den Support.

New kennzeichnet neue Einträge, Mapped automatisch zugeordnete Anwendungen und Customized manuell angepasste Einträge. Unter Manage > More options stehen folgende Aktionen bereit:

• Customize: verständlichen Namen und passende Kategorie vergeben, dann Apply;
• Acknowledge: Label von New auf Customized ändern, ohne Name oder Kategorie anzupassen;
• Hide und Show: Eintrag ausblenden oder wieder anzeigen;
• Delete: Anwendung löschen und zugleich aus verwendenden Application Filtern entfernen.

Nach Customize oder Acknowledge wird die geprüfte Anwendung einem neuen oder bestehenden Application Filter hinzugefügt. Dieser Filter wird der tatsächlich angewendeten Firewall-Regel zugewiesen. Anschliessend wird ein reproduzierbarer Testflow gestartet und im Log Viewer geprüft, ob die erwartete Rule ID, der Anwendungsname und die Aktion angezeigt werden. Erst nach diesem Pilotbetrieb wird aus der Erkennung eine produktive Allow- oder Deny-Regel.

Ein gelöschter Eintrag erscheint wieder, wenn ein Endpoint ihn erneut meldet. Vor Delete werden deshalb die verwendenden Filter geprüft; danach folgen ein neuer Testflow und die Kontrolle der erwarteten Rule ID. Für generative KI zeigt Generative AI mit Sophos Firewall erkennen und kontrollieren einen eigenen Pilotablauf.

Fehler nach Symptom eingrenzen

• Die erwartete Rule ID fehlt: Regelreihenfolge, Source/Destination, Service, Benutzer-Match und IPv4-/IPv6-Pfad prüfen. Der Application Filter ist noch nicht die Ursache, solange der Flow eine andere Regel trifft.
• Kein abschliessender Firewall-Logeintrag: Die offene Session zuerst unter Current activities > Live connections suchen und kontrolliert beenden. Logging und Filterzeitraum im Log Viewer prüfen.
• Die Anwendung bleibt unknown oder generisch: Pattern-Status, Application list, HTTPS-Decryption, QUIC und Web Exceptions prüfen. Packet Capture dient nur zur Bestätigung des Netzwerkpfads.
• Der Block trifft zu viele Dienste: Risk-, Category-, Classification- oder Smart-Filter-Regel auf einzelne Anwendungen beziehungsweise eine kleinere Gruppe verengen. Danach Block- und Kontrollaufruf wiederholen.
• Nach einem Pattern-Update wird mehr blockiert: Prüfen, welche neue Signatur ein dynamisches Kriterium erfüllt. Eine benötigte Anwendung eng ausnehmen, statt den gesamten Filter abzuschalten.
• Der Log Viewer zeigt Firewall Allowed, der Browser aber eine Blockseite: Bei Proxy-Verarbeitung zusätzlich das Web-Log lesen.
• Cloud-App-Details fehlen: Firewall-Logging, HTTPS-Decryption und Web Policy getrennt prüfen. Nicht jedes Übertragungsverfahren liefert alle Detailfelder.
• Facebook-Videos bleiben trotz vollständigem Pfad erreichbar: Rule ID, Application Filter, Web Policy, aktuelle Kategorieeinträge, QUIC, Decryption, Client-CA und Web Exceptions prüfen. Bleibt der Test reproduzierbar, nennt Sophos Support als nächsten Eskalationspunkt.

Rollback und Betrieb

Vor dem Pilotbetrieb werden Application Filter, Web Policy, Regelstatus, Regelposition, NAT-Zuordnung, TLS-Pfad und Ausnahmen festgehalten. Der Rückweg erfolgt in dieser Reihenfolge:

1. Eine separate Pilotregel deaktivieren oder in der bestehenden Regel den vorherigen Application Filter beziehungsweise None wieder auswählen.
2. Die dokumentierte Regelposition und nur die eindeutig zur Pilotkonfiguration gehörende NAT-Zuordnung wiederherstellen.
3. Neue Verbindungen mit dem Kontrollclient auf die frühere Rule ID und das erwartete Verhalten prüfen.
4. Erst danach nicht mehr benötigte Pilotfilter oder Objekte entfernen. Gemeinsam verwendete Filter, NAT-Regeln und Synchronized-Application-Control-Einträge werden nicht ungeprüft gelöscht.

Im Betrieb dokumentiert man Zweck, zugewiesene Firewall-Regeln, dynamische Kriterien, erlaubte Ausnahmen, Owner, letzte Änderung und Review-Datum. Für zentrale Auswertung passen Central Firewall Reporting aktivieren und Sophos Firewall Syslog und SIEM einrichten.

Globale Klassifizierung nur mit Sophos Support ändern

Der Application Filter einer Firewall-Regel ist nicht die globale Application Classification der Device Console. Sophos warnt davor, diese Schalter ohne Anweisung des Supports zu ändern. Zuerst wird der Zustand nur gelesen:

system application_classification show
system application_classification microapp-discovery show

Die globale Klassifizierung ist standardmässig on, microapp-discovery standardmässig off. Wenn Sophos Support eine Änderung vorgibt, werden Vorzustand und Ticket festgehalten. Die dokumentierten Schalter lauten:

system application_classification on
system application_classification off
system application_classification microapp-discovery on
system application_classification microapp-discovery off

Das Einschalten von microapp-discovery startet Dienste neu und unterbricht Traffic. Nach einer autorisierten Änderung prüft man beide show-Ausgaben, einen echten Anwendungsflow und die Logs. Der Rollback stellt den exakten Vorzustand wieder her: Ein früheres on wird mit on, ein früheres off mit off gesetzt und danach erneut mit show kontrolliert. Bei Domain-IoCs betrifft die globale Klassifizierung auch den Kontext von Third-Party Threat Feeds.

Häufige Fragen