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 Air-Gap-Installationen dokumentiert Sophos eine Ausnahme: IPS- und Anwendungssignaturen werden auch bei ausgeschaltetem IPS aktualisiert.

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. Lokale Reports stehen auf XGS 87/87w und XGS 88/88w nicht zur Verfügung; auf diesen Modellen die Log- und Verbindungskontrollen verwenden.

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. Der Proxy-Ablauf beweist keine gleichwertige Facebook-Video-Sperre über DPI; einen separaten DPI-Aufbau vor dem Einsatz mit Sophos Support und Client-Tests validieren. 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.

Auswahl und Beispielkonfiguration vollständig prüfen

Katalog, Templates und konkrete Sperren

Im Katalog öffnet man Filter neben dem jeweiligen Feld; ausser bei Name wählt man einen Wert aus der Liste. Smart Filter durchsucht Name und Beschreibung. Als Template kann jede vorhandene Application Filter Policy dienen, auch eine eigene. Vor dem Kopieren prüft man daher deren Regeln und Zeitpläne.

Die Kategorien beschreiben unterschiedliche Aufgaben, nicht automatisch eine Sicherheitsbewertung:

• File transfer: Dateiübertragung und Uploads; Download applications: Downloads, File Sharing, Storage und Beschleuniger; Storage and backup: Dateispeicher, Zusammenarbeit und Passwortspeicher.
• Gaming: Spiele und Wettbewerbe; Streaming media: Audio, Video und Live-Übertragung; Social networking: soziale Netzwerke; E-commerce: Handelsanwendungen.
• Instant messenger: Chat; VoIP: IP-Telefonie; Conferencing: virtuelle Meetings; Web mail: Browser-Mail; Desktop mail: Mailprogramme.
• General internet: unter anderem Nachrichten, Suche, Browser, Shopping und Workspaces; General business: unter anderem Hosting, Zusammenarbeit, Buchhaltung und Backup; Mobile applications: Apps mobiler Betriebssysteme; Software update: System- und Anwendungsupdates.
• Infrastructure: etwa DNS, DHCP, SMTP, MySQL, QUIC und TLS auf anderen Ports; Network services: etwa Routing, Boot, QoS und FTPS; P2P: Peer-to-Peer-Dateiaustausch; Proxy and tunnel: Proxies und VPN; Remote access: Fernzugriff und Remote Desktop; Industrial control system: Gebäude-, Fernwirk- und Prozesskommunikation.
• SyncAppCtl discovered: über SAC entdeckte unbekannte Anwendungen; Sophos applications: durch SAC zugeordnete Sophos-Anwendungen; System applications: durch SAC zugeordnete Systemdienste, etwa von Windows oder Linux; Generative AI: KI-Anwendungen und -Dienste.

Allow All erlaubt und Deny All verwirft alle Anwendungen. Block filter avoidance apps sperrt Tunnel, Proxies und Anwendungen zur Umgehung von Policies; Block generally unwanted apps umfasst unter anderem File Transfer, Proxy/Tunnel, riskante und P2P-Anwendungen. P2P kann Schadsoftware verbreiten; eine Sperre ist sinnvoll, sofern kein freigegebener Geschäftsbedarf besteht. Die High-Risk-Templates betreffen Risk Level 4/5 beziehungsweise nur 5.

Für eine einzelne Sperre kann man Facebook Games unter Select Individual Application > Name filtern, auswählen und mit Action: Deny, Schedule: All the time speichern. Dasselbe Verfahren eignet sich für WhatsApp, Skype, LinkedIn oder Internet Download Manager. Für Gruppen verwendet man Category: Generative AI oder Category: P2P. Das UltraVPN-Beispiel verwendet Category: Proxy and Tunnel und PPTP Protocol; dies ist keine Zusage, jeden VPN-Tunnel zu erkennen.

Für Block_High_Risk_Apps wählt man nach dem Speichern und erneuten Öffnen Add > Select All > Risk, dann High und Very High, bestätigt mit OK und setzt Deny sowie All the time. Regel und Policy speichern und der Firewall-Regel Block_High_Risk_Apps_Rule zuweisen. Neue passende Signaturen werden nach Pattern-Updates ebenfalls erfasst. Ältere Beispiele nennen eine erlaubende leere Policy und den Abschnitt Advanced; für SFOS 22/23 verwendet man explizit Allow All und prüft die Zuweisung unter Other security features, statt diese alten Angaben ungeprüft zu übertragen.

Gemeinsame Firewall- und Web-Einstellungen

Die File-Transfer- und Storage-Beispiele verwenden eine Accept-Firewall-Regel von LAN nach WAN, Log firewall traffic, Rule group: None, During scheduled time: All the time und Rule position: Top. Quellnetze, Zielnetze und Services sind dort Any; das High-Risk-Beispiel verwendet sogar Any für beide Zonen. Diese breiten Beispielwerte sind keine Pilotempfehlung: Quellbereich auf den Testclient begrenzen, Zonen und Services an den tatsächlichen Pfad anpassen und die Position oberhalb der sonst passenden Regel bewusst wählen. Ohne Match known users gilt die Regel für den passenden Netzverkehr unabhängig vom Benutzer; mit dieser Option wählt man unter User or groups > Add new item etwa Marketing für Storage oder Open Group für File Transfer. Diese Gruppennamen werden durch die eigene freigegebene Gruppe ersetzt; die Benutzerzuordnung muss im Testlog stimmen.

Bei Bedarf erzeugt Create linked NAT rule eine Regel mit Translated source (SNAT): MASQ; im Beispiel liegt auch sie auf Top. Erst NAT-Regel, dann Firewall-Regel speichern. In vorhandenen Netzen bleibt die zuvor geprüfte NAT-Zuordnung massgeblich.

Für Storage wird die Web-Regel nach Block HTTP/Block HTTPS unter Status eingeschaltet und gespeichert. Im Proxy-Pfad zusätzlich QUIC sperren, Scan HTTP and decrypted HTTPS und Decrypt HTTPS during web proxy filtering aktivieren und die CA vor dem Test verteilen.

Für Facebook unter Web > Categories > Add die eigene Kategorie mit Classification: Unproductive, den oben genannten Domain- und Keyword-Werten speichern. Unter Web > Policies > Add policy > Add rule bei Activities All web traffic entfernen, die Kategorie über Add new item > Web category auswählen, Apply selected items, die blockierenden HTTP-/HTTPS-Aktionen und den aktiven Status prüfen, dann Save und gegebenenfalls Skip this step. Im Application Filter alle Treffer für Facebook videos mit Deny und All the time speichern. Das vollständige Proxy-Beispiel aktiviert zusätzlich Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, Scan FTP for malware, Decrypt HTTPS during web proxy filtering und Block QUIC protocol. FTP-Scanning ist eine zusätzliche Schutzoption, kein Beweis für die Video-Sperre. Der DPI-Pfad ist nicht allein durch eine ähnlich benannte Option als gleichwertig getestet; bei ausbleibender Sperre gilt der oben beschriebene Prüf- und Supportweg.

Cloud- und SAC-Bedienung abschliessen

Nach Classify die Auswahl mit Apply bestätigen; nach Traffic shaping eine vorhandene Policy auswählen und mit Save speichern. Beispielsweise lassen sich unsanctioned-Social-Networking-Anwendungen für einen bestimmten Zeitraum prüfen oder Video-Streaming begrenzen.

Unbekannte SAC-Anwendungen landen zunächst in SyncAppCtl discovered; bekannte werden automatisch kategorisiert. Der Suchbereich lässt sich etwa auf System applications begrenzen. Nach Hide findet man Einträge nur in Hidden applications und bringt sie mit Show zurück. Customize bleibt auch später möglich und setzt das Label auf Customized.

Clean up application database benötigt die Registrierung bei Sophos Fusion/Sophos Central. Nach einer täglichen Prüfung löscht SFOS alte Anwendungen in Batches von 100 alle fünf Minuten und entfernt individuell hinzugefügte Einträge auch aus Policies. Vor einer Änderung des Zeitraums deshalb deren Verwendung prüfen; ein bloss kürzerer Zeitraum ist kein risikofreier Speicher-Fix. Ohne gültige Web Protection Subscription lässt sich SAC konfigurieren, aber nicht nutzen.

Application Control über die XML API automatisieren

Die XML-Referenzen für SFOS 22/23 beschreiben verschiedene Objekte mit ähnlich klingenden Namen. Eine Cloud-Klassifizierung ist weder eine Filterregel noch der globale Device-Console-Schalter. Vor einem schreibenden Aufruf werden der bestehende Zustand und die verwendenden Policies gesichert. Zugang, Antwortauswertung und sichere Wiederholungen erklärt Sophos Firewall XML API-Zugriff absichern. Die folgenden Strukturen erklären die Objektbeziehungen; sie sind keine sendefertige Anfrage.

Einzelne und mehrere Cloud-Klassifizierungen

ApplicationClassificationAssignment aktualisiert genau eine Zuordnung: Die beiden Pflichtfelder Application und Classification sind Strings. Das Referenzbeispiel nennt Facebook Website und New. Das ist kein vollständiger Katalog zulässiger Klassifizierungen; UI-Werte und Gross-/Kleinschreibung werden nicht automatisch zu API-Enum-Werten erklärt.

ApplicationClassificationBatchAssignment verwendet dagegen ClassAssignmentList mit wiederholten ClassAssignment-Objekten. In jedem Objekt stehen die kleingeschriebenen Felder app und class, nicht Application und Classification. Der dokumentierte Aufbau sieht beispielsweise so aus:

<ApplicationClassificationBatchAssignment>
  <ClassAssignmentList>
    <ClassAssignment>
      <app>iCloud</app>
      <class>New</class>
    </ClassAssignment>
    <ClassAssignment>
      <app>iPlay Website</app>
      <class>New</class>
    </ClassAssignment>
  </ClassAssignmentList>
</ApplicationClassificationBatchAssignment>

Die Namen sind Referenzbeispiele und werden durch tatsächlich vorhandene Anwendungen ersetzt. Die Parametertabelle beschreibt ClassAssignmentList als optionales Array von Objekten mit mehreren Werten. Daraus folgt weder eine sinnvolle leere Batch-Operation noch eine Zusage für atomare Verarbeitung, Rollback oder einen Status pro Eintrag. Nach einer Änderung jede angeforderte Zuordnung separat nachlesen und erst mit neuem Traffic die Wirkung eines Classification-Filters prüfen. Beim Batch nennt die Referenz 200 mit Operation Successful. und 500 mit Operation Fail.; bei der Einzeloperation stehen 200 und 500 mit den nicht aufgelösten Symbolen Message.AppClassificationUpdateSuccess beziehungsweise Message.AppClassificationUpdateFail.

Filter-Policy: Template oder eigene Regeln

Bei ApplicationFilterPolicy hat Template Vorrang: Wird es mitgegeben, ignoriert der dokumentierte Vertrag DefaultAction und RuleList. Ein Request mit Template und eigener Deny-Regel ist deshalb keine verlässliche Kombination beider Varianten. Ohne Template beschreibt die Referenz DefaultAction mit Allow oder Deny und RuleList/Rule für eigene Regeln. Ihre zugleich genannte Maximallänge von einem Zeichen widerspricht diesen Wörtern; daraus wird kein verkürzter Ein-Zeichen-Wert abgeleitet. Das XML-Beispiel schreibt AllowAll, während die UI Allow All anzeigt. Den UI-Text nicht ungeprüft als API-Token übernehmen.

Innerhalb von Rule liegen SelectAllRule, Auswahlcontainer sowie Action und Schedule. Die Container sind CategoryList/Category, RiskList/Risk, CharacteristicsList/Characteristics, TechnologyList/Technology, ClassificationList/Classification und ApplicationList/Application. SelectAllRule verwendet im Beispiel Enable/Disable; dies ist ein Schalter und nicht der Listenwert für eine Kategorie. Die ersten fünf Listen zeigen SelectALL, die Anwendungsliste dagegen SelectAll. Die Beispielkommentare sagen, dass eine Alles-Auswahl weitere Einträge derselben Liste ignoriert. Schreibweisen weder normalisieren noch daraus einen undokumentierten Vorrang zwischen verschiedenen Kriterien ableiten. Die Parametertabelle führt zusätzlich Search als Suchstring; diesen nicht mit dem SmartFilter eines Application Object verwechseln.

Der Policy-Name ist verpflichtend, erlaubt UTF-8, aber keine Kommas und höchstens 60 Zeichen; Description erlaubt höchstens 1000 Zeichen. MicroAppSupport nennt True und False, beweist aber keine eingeschaltete HTTPS-Entschlüsselung. Die Tabelle führt Action und Schedule als Arrays, deren Duplikate nicht ignoriert werden, während das XML-Beispiel sie je Regel zeigt. Die Listen deshalb nicht eigenmächtig deduplizieren oder umsortieren. Nach dem Speichern Default-Aktion, Reihenfolge, Auswahl und Schedule nachlesen; erst die Zuweisung an die passende Firewall-Regel und der Clienttest bestätigen die gewünschte Sperre.

Kategorie-QoS und SD-WAN-Objekte auseinanderhalten

ApplicationFilterCategory identifiziert die bestehende Kategorie über das verpflichtende Name; dieser Kategoriename kann nicht geändert werden. Das verpflichtende QoSPolicy auf Kategorieebene ist von ApplicationSettings/Application/QoSPolicy zu unterscheiden: Letzteres gehört zur Anwendung, deren Name im jeweiligen Unterobjekt steht. Das Beispiel zeigt zusätzlich BandwidthUsageType mit Individual/Shared. Damit ist der Kontext der Bandbreitenteilung sichtbar, aber keine vollständige Vorrangregel zwischen Kategorie- und Anwendungszuweisung bewiesen. Bestehende QoS-Zuweisungen und die gewünschte gemeinsame oder individuelle Nutzung vor der Änderung prüfen; den Betriebsablauf erläutert Application Traffic Shaping.

ApplicationObject stellt eine Anwendungsauswahl für anwendungsbasierte SD-WAN-Routen bereit, keine ApplicationFilterPolicy mit Allow-/Deny-Regeln. Seine Pflichtfelder sind Name und SelectAllRule (Enable oder Disable); der Name erlaubt UTF-8, keine Kommas und höchstens 80 Zeichen. Das XML-Beispiel verwendet dieselben sechs Auswahlcontainer wie oben und zusätzlich SmartFilter als Suchstring. Auch hier zeigt es SelectALL für Kriterien und SelectAll für Anwendungen. Die sichtbare Anwendungsauswahl ist nicht die Identität des benannten Objekts: Bei einem Update das gemeinte Objekt nachlesen; für Delete ist diese Add-/Edit-Seite kein Beleg des Identitätsvertrags.

Für Application object add und Application object edit ordnet die Referenz jeweils dieselben Codes zu:

Diese Symbole sind keine ausformulierten Fehlermeldungen und die Codes keine automatisch gleichbedeutenden HTTP-Statuscodes. Operation, Code und tatsächliche Antwort gemeinsam festhalten. Vor einem Retry den wirklich gespeicherten Objektnamen und die Auswahl nachlesen; ein unklarer Fehler darf nicht zu einem zweiten oder breiteren Objekt führen. Für Policy-Edit nennt die Referenz ausserdem 502 mit Message.AFPRecordExists neben 200/Message.AFPUpdateSuccess und 500/Message.AFPUpdateFail. Auch hier bleibt die Bedeutung des nicht aufgelösten Meldungstexts offen; ein Erfolgscode ersetzt weder die Zustandskontrolle noch den Traffic-Test.

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