Sophos Firewall: Best Practices für moderne Netzwerksicherheit

Firewalls waren lange der Ort, an dem man Angriffe abwehrt. Heute sind sie selbst eines der attraktivsten Ziele. Das ist logisch: Eine Firewall sitzt an einer privilegierten Position zwischen Internet, Standortnetzwerken, Cloud-Diensten, VPN-Zugängen und internen Anwendungen. Wer hier eine Schwachstelle, ein schwaches Passwort oder eine Fehlkonfiguration findet, steht nicht mehr vor der Tür, sondern oft schon mitten im Gebäude.

Genau deshalb reicht es nicht mehr, eine Firewall nur als Policy-Engine für Allow- und Deny-Regeln zu betrachten. Moderne Netzwerksicherheit braucht drei Säulen: Härtung, Schutz sowie Erkennung und Reaktion. Man muss die Angriffsfläche vor einem Angriff reduzieren, während eines Angriffs sauber blockieren und danach schnell erkennen, was passiert ist.

Ich betreue seit vielen Jahren Sophos-Firewall-Umgebungen in sehr unterschiedlichen Grössen und Branchen. Die folgenden Empfehlungen sind deshalb nicht als theoretische Feature-Liste gemeint, sondern als das, was sich in echten Kundenumgebungen, Migrationen, Audits und Supportfällen immer wieder bewährt.

Warum Firewalls so stark im Fokus stehen

Eine Firewall ist für Angreifer ein lohnendes Ziel, weil sie exponiert, privilegiert und oft geschäftskritisch ist. Dazu kommt: Viele Umgebungen betreiben Firewalls, VPN-Portale oder Remote-Management-Zugänge über Jahre hinweg. Nicht jede Umgebung ist sauber gepatcht, nicht jede Managementfläche ist wirklich abgeschottet und nicht jede Anmeldung ist durch Multi-Faktor-Authentifizierung abgesichert.

In der Praxis zeigen sich vor allem drei wiederkehrende Ursachen für erfolgreiche Angriffe:

• Schwachstellen in Firewalls und Edge-Systemen, besonders wenn Patches verspätet oder gar nicht eingespielt werden.
• Kompromittierte Zugangsdaten und Identitätsangriffe, häufig ohne MFA oder mit schwacher MFA-Konfiguration. Der Sophos Active Adversary Report 2026 nennt identitätsbezogene Ursachen als Root Cause in 67.32 % der untersuchten Fälle.
• Exponierte Systeme, etwa RDP, VPN-Portale, User-Portale oder Admin-Oberflächen, die direkt aus dem Internet erreichbar sind.

Der wichtigste Gedanke dahinter: Viele Angriffe sind heute kein spektakuläres “Einbrechen” mehr. Sehr oft loggen sich Angreifer einfach ein. Wenn ein Benutzerkonto, ein Admin-Passwort oder ein VPN-Zugang kompromittiert ist, sieht der erste Schritt für die Firewall zunächst wie legitime Nutzung aus.

Die drei Säulen moderner Netzwerksicherheit

Sophos beschreibt die Absicherung moderner Netzwerke als Spektrum von proaktiv bis reaktiv:

1. Hardening: Angriffsfläche reduzieren, veraltete Systeme entfernen, sichere Produkte einsetzen, Konfigurationen prüfen, Zugriff einschränken.
2. Protection: Angriffe blockieren, verschlüsselten Traffic kontrollieren, Web-, IPS-, Zero-Day- und Application-Control-Funktionen sinnvoll nutzen.
3. Detection and Response: Auffälligkeiten erkennen, kompromittierte Geräte isolieren, Bedrohungsdaten korrelieren und automatisiert reagieren.

Viele Firewalls sind traditionell stark in der zweiten Säule. Diese Systeme blockieren Traffic, prüfen Pakete, erkennen bekannte Muster und setzen Policies durch. Das ist wichtig, aber nicht mehr ausreichend. Wenn die Firewall selbst falsch konfiguriert ist, wenn Remote Access ohne MFA läuft oder wenn ein ungepatchtes System weiter produktiv ist, hat man ein strukturelles Problem, das keine einzelne IPS-Regel sauber lösen kann.

Meine Erfahrung zeigt: Die besten Resultate entstehen nicht durch eine einzelne magische Funktion, sondern durch saubere Grundkonfiguration, regelmässige Reviews und eine Firewall, die in den restlichen Security-Prozess eingebunden ist.

Säule 1: Hardening vor dem Angriff

Hardening ist der Teil der Sicherheitsarbeit, der selten Applaus bekommt, aber im Ernstfall den Unterschied macht. Es geht um weniger Angriffsfläche, weniger Altlasten, weniger offene Managementwege und weniger Abhängigkeit von manuellen Reaktionen.

Infrastruktur reduzieren und alte Systeme entfernen

Der einfachste Weg, eine Angriffsfläche zu verkleinern, ist manchmal der unbequemste: Dinge abschalten. Jede alte Appliance, jeder vergessene VPN-Dienst, jedes Managementportal und jeder nicht mehr unterstützte Server ist ein zusätzlicher Angriffspunkt. Besonders kritisch sind Systeme, die am Netzwerkrand stehen oder indirekt privilegierten Zugriff auf interne Netze ermöglichen.

Für Sophos Firewall Admins heisst das konkret:

• Regelmässig prüfen, welche Firewalls, REDs, VPN-Gateways, WLAN-Controller, Reverse Proxies und Remote-Access-Komponenten noch produktiv sind.
• End-of-Life- oder End-of-Support-Systeme aus privilegierten Positionen entfernen.
• Funktionen konsolidieren, wenn dadurch Komplexität sinkt: Firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, Reporting und Central Management gehören möglichst sauber aufeinander abgestimmt.
• Dokumentieren, welche Dienste wirklich aus dem Internet erreichbar sein müssen.

Das Ziel ist nicht, möglichst viel in ein Produkt zu stopfen. Das Ziel ist, blinde Altlasten zu vermeiden. Eine kleine, aktuelle und gut kontrollierte Infrastruktur ist fast immer sicherer als eine grosse, historisch gewachsene Umgebung mit vielen “das war schon immer so”-Ausnahmen.

Managementzugriff konsequent absichern

Eine der wichtigsten Best Practices ist simpel: Die Web Admin Console und das User Portal sollten nicht unnötig aus dem WAN erreichbar sein. Wenn Remote-Administration notwendig ist, sollte sie über Sophos Central, ein dediziertes Managementnetz, ZTNA oder einen anderen kontrollierten Weg erfolgen.

Ich sehe in Kundenumgebungen immer wieder, dass nicht die komplizierteste Angriffstechnik das Problem ist, sondern ein alter Admin-Zugang, ein historisch gewachsenes Portal oder eine “temporäre” Ausnahme, die nie wieder entfernt wurde. Genau solche Stellen gehören in ein regelmässiges Firewall-Review.

Folgende Punkte sollten in jeder Sophos-Firewall-Umgebung geprüft werden:

• MFA für Administratoren aktivieren, besonders für den Standard-Admin und alle Konten mit weitreichenden Rechten.
• MFA für VPN- und Portal-Anmeldungen erzwingen, wenn solche Zugänge noch genutzt werden.
• WAN-Zugriff auf Admin Console und User Portal vermeiden oder stark auf dedizierte Quellnetze einschränken.
• Starke Passwortregeln für Benutzer und Administratoren konfigurieren.
• SSH absichern, idealerweise mit Public-Key-Authentifizierung und ohne breite WAN-Erreichbarkeit.
• Zentrale Backups aktivieren und Backup-Zugriff schützen, da Konfigurationsbackups sensible Informationen enthalten können.
• Benachrichtigungen und Logging aktivieren, damit sicherheitsrelevante Ereignisse nicht im Betrieb untergehen.

Der Punkt mit den Backups wird oft unterschätzt. Ein Firewall-Backup enthält nicht nur harmlose Einstellungen, sondern Informationen über Netze, Regeln, Zertifikate, VPNs und interne Strukturen. Deshalb müssen Backups verschlüsselt, kontrolliert abgelegt und regelmässig getestet werden.

Device Access und Local Service ACL bewusst setzen

Wenn man über WAN-Zugriff spricht, muss man bei der Sophos Firewall konkret über Device Access und Local Service ACL sprechen. In der Device-Access-Matrix wird zonenweise festgelegt, welche lokalen Firewall-Dienste erreichbar sind: HTTPS-Admin, User Portal, SSH, Ping, DNS, Captive Portal, VPN-Portale und weitere Dienste.

Best Practice ist hier sehr einfach, aber wirkungsvoll: Aus der WAN-Zone sollte nur erreichbar sein, was wirklich benötigt wird. Admin-Zugriff, SSH und User Portal gehören nicht breit ins Internet. Wenn Ausnahmen nötig sind, sollten sie über Local Service ACL Exception Rules auf konkrete Quell-IP-Adressen oder Managementnetze begrenzt werden.

Länderregeln als Mindestschutz

Wenn feste Quell-IP-Adressen nicht realistisch sind, empfehle ich mindestens mit Länderregeln zu arbeiten. Zugriff nur aus wenigen relevanten Ländern ist immer noch deutlich besser als weltweite Erreichbarkeit. Alternativ kann man Länder blockieren, mit denen das Unternehmen keinen Bezug hat und in denen auch keine Mitarbeitenden oder Admins typischerweise unterwegs sind. Das ist kein Ersatz für MFA, starke Rollen und saubere ACLs, reduziert aber unnötiges Rauschen und viele automatisierte Zugriffsversuche.

Aus meiner Sicht ist das einer der ersten Punkte in jedem Firewall-Review. Viele riskante Konfigurationen entstehen nicht durch böse Absicht, sondern weil ein Dienst für eine Migration, einen Supportfall oder einen Test kurz geöffnet und später nie wieder geschlossen wurde. Genau solche Details unterscheiden eine Firewall, die einfach läuft, von einer Firewall, die wirklich sauber betrieben wird.

Login Security und Admin-Rollen prüfen

MFA ist wichtig, aber der Login-Layer besteht aus mehr als einem zweiten Faktor. Administratoren sollten eigene, nachvollziehbare Konten verwenden und nicht dauerhaft mit einem gemeinsamen Volladmin arbeiten. Rollenbasierte Rechte helfen, Support-, Reporting- oder Helpdesk-Zugriffe vom eigentlichen Firewall-Admin zu trennen.

Zusätzlich sollten fehlgeschlagene Login-Versuche begrenzt, Sessions sauber beendet und Admin-Zugriffe auf definierte Netze eingeschränkt werden. Ein Login-Disclaimer kann in bestimmten Umgebungen rechtlich sinnvoll sein, ist aber kein Ersatz für echte technische Kontrollen. Wichtiger sind starke Passwortrichtlinien, kurze inaktive Sessions, Brute-Force-Schutz und Least Privilege.

Patch-Fatigue vermeiden: Hotfixes müssen schnell wirken

Patching ist eines der Themen, bei denen Theorie und Praxis weit auseinanderliegen. Natürlich weiss jeder Admin, dass Firmware-Updates wichtig sind. In der Realität bedeuten sie aber Wartungsfenster, Risikoabwägung, HA-Planung, Kommunikation mit Fachabteilungen und manchmal auch Downtime. Das führt zu Patch-Fatigue: Updates werden verschoben, weil sie aufwendig sind.

Genau hier ist die Zeitkomponente gefährlich. Identitätsangriffe sind inzwischen der dominierende Root Cause, aber Schwachstellenausnutzung bleibt ein realer Vektor, besonders bei Edge-Systemen wie Firewalls, VPNs und anderen internetnahen Diensten. Der Sophos Active Adversary Report 2026 nennt als Beispiel CVE-2024-40766 in SonicOS, die in einem grossen Teil der bestätigten Exploit-Fälle im Datensatz sichtbar war. Gleichzeitig lag die mediane Zeit zwischen Hersteller-Advisory bzw. Patch und beobachteter Ausnutzung bei 322 Tagen. Das ist ein ziemlich klares Signal: Patch-Fatigue ist kein abstraktes Betriebsproblem, sondern ein Angriffsfenster.

Sophos Firewall geht hier einen wichtigen Schritt: Automated Hotfixes ermöglichen sicherheitsrelevante Live-Patches ohne klassisches Wartungsfenster. Für Admins ist das enorm wertvoll, weil die kritische Schutzwirkung nicht erst dann eintritt, wenn das nächste freie Wartungsfenster kommt.

Trotzdem gilt: Hotfixes ersetzen keine saubere Update-Strategie. Hotfixes schliessen die gefährliche Lücke zwischen entdeckter Schwachstelle und regulärem Firmware-Upgrade. Die Best Practice lautet daher:

• Hotfixes aktiviert lassen.
• Firmwarestände regelmässig prüfen und die Firmware-Update-Vorbereitung dokumentieren.
• Upgradepfade und Kompatibilität vorab lesen.
• Backups und Rollback-Plan vorbereiten.
• HA-Cluster und Remote-Standorte separat planen.

VPN nicht als Vertrauensbeweis behandeln

Remote Access VPN war jahrelang der Standard. Das Problem: Klassisches VPN denkt oft in Netzwerken, nicht in Anwendungen. Wer erfolgreich verbunden ist, befindet sich aus Sicht vieler Umgebungen bereits in einem vertrauenswürdigen Bereich. Wenn das Endgerät kompromittiert ist oder Zugangsdaten gestohlen wurden, kann sich ein Angreifer von dort weiterbewegen.

Zero Trust Network Access (ZTNA) löst dieses Problem nicht durch Magie, aber durch ein besseres Prinzip: Trust nothing, verify everything. Zugriff wird nicht pauschal auf ein Netzwerk gewährt, sondern pro Benutzer, Gerät, Zustand und Anwendung bewertet. Ein Gerät muss gesund und compliant sein, die Identität muss verifiziert werden und die Policy entscheidet granular, welche Anwendung erreichbar ist.

ZTNA ist kein automatischer Sophos-Entscheid

Wichtig ist dabei: ZTNA ist keine Entscheidung, die automatisch für Sophos ZTNA sprechen muss. Je nach Umgebung können spezialisierte ZTNA-, SSE- oder SASE-Anbieter funktional weiter sein, bessere Integrationen bieten oder organisatorisch besser passen. Entscheidend ist nicht der Herstellername, sondern ob Identität, Gerätezustand, Applikationszugriff, Logging und Betrieb sauber zusammenspielen.

Das ist auch meine grundsätzliche Haltung in Sophos-Projekten: Ich setze nicht bei jedem Thema automatisch auf Sophos. Wenn eine Drittanbieter-Lösung bei ZTNA, SSE, Threat Intelligence, SIEM oder NDR fachlich besser passt, ist genau das die bessere Empfehlung. Eine gute Security-Architektur entsteht nicht durch maximale Herstellerbindung, sondern durch sauber integrierte Komponenten mit klarer Verantwortung.

Für reine Sophos-Umgebungen kann die Integration trotzdem interessant sein, weil ZTNA, Endpoint, Firewall und Sophos Central gemeinsam genutzt werden können. Ein kompromittiertes oder nicht konformes Gerät kann den Zugriff verlieren, ohne dass ein Admin zuerst manuell Firewall-Regeln umbauen muss. Dazu lohnt sich auch der Blick auf das ZTNA Gateway auf der Sophos Firewall. Bei gemischten oder grösseren Umgebungen sollte man aber bewusst vergleichen und nicht automatisch den bestehenden Firewall-Hersteller als ZTNA-Plattform setzen.

Wer heute noch stark auf SSL VPN oder IPsec Remote Access setzt, sollte mindestens diese Punkte prüfen:

• MFA für jeden Remote-Access-Zugang erzwingen.
• Alte oder ungenutzte VPN-Benutzer entfernen.
• Gruppenimport aus AD oder Entra ID kontrollieren, damit Remote Access nicht ungewollt aktiviert wird.
• Split-Tunnel, erlaubte Netze und Berechtigungen auf das Minimum reduzieren.
• Schrittweise Migration zu einer passenden ZTNA-, SSE- oder SASE-Lösung planen, besonders für interne Web-Apps, RDP, SSH, Administrationsportale und Business-Anwendungen.

Segmentierung gegen Lateral Movement

Wenn Angreifer mit gültigen Zugangsdaten oder über einen exponierten Dienst hineinkommen, entscheidet die interne Segmentierung darüber, wie weit sie sich bewegen können. Eine Firewall darf deshalb nicht nur Perimeter-Gateway sein, sondern sollte interne Zonen sauber trennen: Benutzer, Server, Management, IoT, Gastnetz, Produktion, Backup und besonders kritische Systeme gehören nicht blind in dasselbe Vertrauensmodell.

Praktisch heisst das: VLANs und Zonen nicht nur aus Ordnungsliebe bauen, sondern mit echten Firewall-Regeln absichern. Zwischen Benutzer- und Servernetzen sollten nur die benötigten Anwendungen erlaubt sein. Managementzugriffe gehören in dedizierte Admin-Netze. IoT- und Drucker-Netze sollten nicht frei mit Servern sprechen dürfen. Backups und Domain Controller verdienen besonders restriktive Regeln und gutes Logging.

Genau hier schliesst sich der Kreis zur Aussage “Angreifer loggen sich ein”. Wenn ein kompromittierter Account zwar Zugang zu einer Anwendung, aber nicht zum ganzen Netzwerk bekommt, wird aus einem Incident nicht automatisch eine Vollkompromittierung.

Bei neuen Projekten plane ich Segmentierung deshalb möglichst früh mit ein. Nachträglich ist sie zwar immer noch möglich, aber deutlich mühsamer, weil Anwendungen, Ausnahmen und historische Abhängigkeiten dann erst entwirrt werden müssen.

Fehlkonfigurationen sichtbar machen

Eine Firewall kann technisch sehr leistungsfähig sein und trotzdem durch falsche Konfiguration gefährlich werden. Zu breite Regeln, “Any”-Objekte, schwache Authentisierung, fehlende IPS-Policies, deaktivierte Pattern-Updates oder offene Portale sind typische Beispiele. Das Schwierige daran: In gewachsenen Umgebungen sieht man solche Risiken nicht immer sofort.

Der Sophos Firewall Health Check adressiert genau dieses Problem. Er prüft Dutzende Einstellungen gegen Best Practices und Benchmarks und zeigt im Control Center, wo Konfigurationen riskant sind oder von empfohlenen Standards abweichen. Die Ergebnisse sind nach Risiko priorisiert, führen per Klick zu den betroffenen Einstellungen und können je nach Situation behoben oder bewusst übersteuert werden.

Besonders hilfreich ist der Health Check für wiederkehrende Betriebsprozesse:

• nach einem neuen Firewall-Rollout,
• nach grösseren Regeländerungen,
• vor und nach Firmware-Upgrades,
• vor Audits,
• nach Migrationen von alter Hardware,
• als regelmässiger Quartalscheck.

Wichtig ist aber auch: Ein Health Check nimmt Admins nicht das Denken ab. Nicht jede Empfehlung passt zu jeder Umgebung. Manche Punkte haben Compliance- oder Betriebsgründe, andere sind klare Sicherheitslücken. Entscheidend ist, Abweichungen bewusst zu bewerten und nicht unbemerkt wachsen zu lassen.

Aus meiner Sicht ist der Health Check vor allem als laufendes Betriebswerkzeug stark. Er ist nicht nur etwas für den ersten Go-Live, sondern ein guter Einstiegspunkt für Quartalsreviews, Audit-Vorbereitung und die Bereinigung alter Regelwerke.

Secure by Design: Die Firewall selbst härten

Aus meiner Sicht braucht es nicht nur Security-Produkte, sondern sichere Security-Produkte. Das ist ein wichtiger Unterschied. Eine Firewall darf nicht nur Angriffe auf andere Systeme blockieren, sondern muss selbst gegen Angriffe gehärtet sein.

Bei Sophos Firewall gehören dazu mehrere Ebenen:

• Gehärteter Kernel und modernisierte Architektur: Die neuere Xstream-Architektur setzt stärker auf Isolation, Modularisierung, Containerisierung und Privilegientrennung. Dadurch werden bestimmte Schwachstellenklassen reduziert und Auswirkungen durch bessere Isolation begrenzt. Dazu kommen Mitigations gegen Side-Channel- und CPU-Schwachstellen. Das macht die Plattform robuster, aber nicht immun gegen Schwachstellen.
• Automated Hotfixes: Sicherheitskorrekturen können sehr schnell und ohne klassisches Wartungsfenster verteilt werden.
• Remote Integrity Monitoring: Der integrierte Sophos XDR Linux Sensor kann Systemintegrität in Echtzeit überwachen, etwa unerlaubte Konfigurationsänderungen, Rule Exports, verdächtige Programmausführung oder File Tampering. Wertvoll ist das aber nur, wenn die Funktion aktiviert, lizenziert, angebunden und im Betrieb auch überwacht wird.
• Sichere Central-Verwaltung: Administration kann über Sophos Central erfolgen, ohne Managementports breit ins Internet zu öffnen.
• Health Check: Riskante Konfigurationen werden direkt sichtbar.
• Verschlüsselte Backups: Konfigurationsdaten werden geschützt übertragen und gespeichert.

Zusätzlich setzt Sophos auf die proaktive Überwachung der installierten Firewall-Basis. Telemetrie aus Firewalls kann helfen, Hinweise auf Angriffe oder Manipulationen früher zu erkennen. Wenn ein Muster sichtbar wird, kann Sophos Kunden oder Partner gezielt unterstützen und Hotfixes sehr schnell breit ausrollen.

Diese Punkte sind im Alltag weniger spektakulär als eine neue Firewall-Regel oder ein blockierter Angriff im Log. Langfristig sind sie aber entscheidend. Ein gehärtetes Produkt reduziert die Wahrscheinlichkeit, dass die Firewall selbst zum Einstiegspunkt wird. Es ersetzt aber keinen sauberen Patch-Prozess, kein Monitoring und keine regelmässige Konfigurationsprüfung.

Worauf man beim Firewall-Hersteller achten sollte

Secure by Design ist nicht nur eine Produkteigenschaft, sondern auch eine Herstellerfrage. Kunden sollten von Herstellern erwarten, dass sie Schwachstellen transparent behandeln, Lifecycle-Informationen klar kommunizieren, Sicherheitsfixes schnell ausrollen und ihre Produkte so bauen, dass Fehlkonfigurationen und kompromittierte Komponenten möglichst früh auffallen.

Die Verantwortung ist dabei geteilt. Hersteller müssen sichere Produkte liefern und transparent reagieren. Kunden müssen Updates einspielen, EOL-Systeme ersetzen, MFA nutzen und den Betrieb regelmässig prüfen. Beides gehört zusammen.

Säule 2: Protection während des Angriffs

Hardening ist die Basis. Danach muss die Firewall weiterhin das tun, wofür sie eingesetzt wird: Traffic kontrollieren und Angriffe blockieren. Bei Sophos Firewall gehören dazu unter anderem IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection und Threat Intelligence Feeds.

Sophos setzt dafür stark auf die Xstream-Architektur. Vertrauenswürdiger Traffic kann effizienter verarbeitet werden, rechenintensive Aufgaben wie Crypto-Operationen laufen über optimierte Pfade, und für Traffic mit höherem Risiko bleibt mehr Performance-Reserve für Deep Packet Inspection, TLS Inspection und Zero-Day Protection.

Gerade TLS Inspection ist ein gutes Beispiel für die Balance zwischen Sicherheit und Betrieb. Ohne Entschlüsselung bleibt ein grosser Teil des modernen Traffics unsichtbar. Mit schlecht geplanten TLS-Regeln erzeugt man aber Supportfälle, Zertifikatsprobleme oder Performance-Engpässe. Best Practice ist deshalb nicht “alles blind entschlüsseln”, sondern sauber klassifizieren:

• kritische Benutzergruppen und Server zuerst,
• Banking, Health, Privacy und bekannte problematische Kategorien sauber ausnehmen,
• Block- und Warnseiten testen,
• Zertifikatsverteilung dokumentieren,
• Logs aktiv auswerten.

Meine Empfehlung ist, TLS Inspection nicht als Alles-oder-nichts-Projekt zu starten. Besser ist ein sauberer Rollout mit klaren Benutzergruppen, Ausnahmen, Testfenstern und Log-Auswertung. So steigt die Sichtbarkeit, ohne dass der Helpdesk am ersten Tag überrollt wird.

Auch Threat Feeds gehören in diesen Schutzbereich. Solche Feeds helfen, bekannte bösartige IPs, Domains oder URLs direkt an der Netzwerkgrenze zu blockieren. In neueren Sophos-Firewall-Versionen sind sie deutlich stärker in Active Threat Response und Schutzmechanismen integriert.

Besonders interessant werden Threat Feeds, wenn nicht nur generische Listen genutzt werden, sondern kuratierte Drittanbieter-Feeds mit aktuellem Kontext. Ein Beispiel dafür ist Cybora.io, wo bösartige IPs und Domains aus verschiedenen Quellen und Firewall-Telemetrie zu nutzbaren Feeds zusammengeführt werden. Wie solche Feeds auf Firewalls eingesetzt werden können, habe ich im Beitrag Threat Intelligence Feeds für die Firewall ausführlicher beschrieben.

Auch hier gilt: Threat Feeds müssen getestet und beobachtet werden. Zu aggressive Feeds, fehlende Allowlist-Prozesse oder unklare Zuständigkeiten können legitimen Traffic blockieren und im Betrieb mehr Schaden als Nutzen erzeugen. Gute Feeds sind kein Ersatz für ein Regelreview, sondern ein zusätzlicher Baustein mit eigenem Tuning.

Zusätzlich sollte man die klassischen SFOS-Härtungen nicht vergessen: Spoof Protection, passende DoS-Einstellungen und Geo-IP-Blocking können einfache, laute oder offensichtlich unerwünschte Zugriffe reduzieren. Das ersetzt keine saubere Policy, aber es nimmt der Firewall unnötiges Rauschen und blockiert Angriffspfade, die in vielen Umgebungen gar keinen legitimen Zweck haben.

Ich empfehle hier pragmatisch vorzugehen: erst die grossen Risiken sauber kontrollieren, dann die Schutzfunktionen schrittweise schärfen und mit Logs belegen, was wirklich wirkt. Eine überladene Policy, die niemand mehr versteht, ist langfristig kein Sicherheitsgewinn.

Säule 3: Detection and Response nach dem ersten Signal

Der spannendste Teil moderner Netzwerksicherheit ist die Reaktion. Eine Firewall sollte nicht isoliert arbeiten, sondern Signale aus Endpoint, Server, NDR, MDR, XDR und Threat Intelligence nutzen. Sophos kann hier Ökosystem-Vorteile ausspielen, aber nur dann, wenn diese Integrationen auch wirklich zur Umgebung passen.

Ökosysteme helfen nur, wenn sie passen

Synchronized Security und Security Heartbeat sind gute Ideen: Die Firewall kann den Zustand von Endpoints berücksichtigen und bei kompromittierten Geräten Kommunikation einschränken oder blockieren. In der Realität nutzen aber immer mehr Unternehmen Microsoft Defender oder andere Endpoint-Lösungen. Dann funktioniert dieser Teil des Sophos-Ökosystems nur eingeschränkt oder gar nicht. Genau deshalb sollte man nicht automatisch alles vom selben Hersteller nehmen, nur weil es als integriertes Ökosystem angeboten wird.

Meine Empfehlung ist hier klar: Entscheidend ist, was zum Unternehmen passt und sauber implementiert werden kann. Wenn Microsoft Defender, ein anderes EDR, ein Drittanbieter-NDR oder ein externes SIEM die bessere Basis ist, dann sollte die Firewall sauber in diese Architektur eingebunden werden. Wichtiger als Cross-Selling ist, dass Logs an der richtigen Stelle landen, Alarme verstanden werden und jemand regelmässig prüft, was die Systeme melden. Ohne Log-Analyse, Tuning und Incident-Prozess hilft auch die beste Integration wenig.

Mit Active Threat Response lassen sich erkannte Bedrohungen automatisch in Netzwerkentscheidungen übersetzen. Und mit NDR Essentials erhält die Firewall zusätzliche Sicht auf verdächtigen Netzwerkverkehr, auch dort, wo kein klassischer Endpoint-Agent installiert ist.

Automatisierung braucht Runbooks

Automatisierung braucht aber Leitplanken. Es sollte klar sein, welche Signale automatisch blockieren dürfen, wer eine Isolierung wieder aufhebt, wie False Positives behandelt werden und wie solche Abläufe getestet werden. Ohne Runbooks, Zuständigkeiten und regelmässige Übungen weiss im Ernstfall sonst niemand, ob ein Block gewollt, korrekt oder zu aggressiv war.

Was passiert im Ernstfall? Ein kompromittiertes Gerät kann isoliert werden, C2-Kommunikation wird unterbrochen, Exfiltration kann blockiert werden und ein MDR- oder XDR-Analyst kann eine Active Threat Response auslösen, ohne zuerst manuell in der Firewall eine Regel zu bauen. Das ist besonders wertvoll, wenn ein Angriff ausserhalb normaler Betriebszeiten erkannt wird.

Für Admins ist daran vor allem eines wichtig: Die Reaktion muss schnell genug sein. Wenn ein MDR- oder XDR-Analyst zuerst anrufen, ein Ticket schreiben und ein lokaler Admin dann am Freitagabend manuell eine Regel bauen muss, ist die Reaktionszeit zu lang. Automatisierte Reaktion bedeutet nicht, dass Menschen ersetzt werden. Gemeint ist, dass die erste Eindämmung sofort passiert und das Team danach sauber untersuchen kann.

Gerade in kleineren IT-Teams ist diese Automatisierung wertvoll. Nicht jedes Unternehmen hat rund um die Uhr einen Firewall-Spezialisten verfügbar. Wenn Endpoint, Firewall, NDR, MDR und SIEM herstellerübergreifend sinnvoll zusammenspielen, gewinnt man Zeit, und Zeit ist bei aktiven Angriffen oft der wichtigste Faktor.

Praktische Checkliste für Sophos Firewall Admins

Wer seine Sophos Firewall heute härten möchte, kann mit dieser Liste beginnen:

Sofort prüfen

• Sind Hotfixes aktiviert?
• Ist MFA für Administratoren aktiv?
• Sind Web Admin Console und User Portal aus dem WAN erreichbar?
• Sind SSL VPN oder IPsec Remote Access mit MFA geschützt?
• Gibt es noch ungenutzte lokale Admin-Konten?
• Sind Backups geplant, verschlüsselt und getestet?
• Sind Device Access und Local Service ACL auf das Minimum reduziert?
• Sind WAN-erreichbare Dienste mindestens auf relevante Länder oder bekannte Quellnetze begrenzt?
• Sind Pattern-Updates und Firmwarestände aktuell?

Innerhalb der nächsten Wochen

• Health Check ausführen und Findings priorisieren.
• Alte Firewall-Regeln mit “Any” bei Quelle, Ziel oder Service prüfen.
• Admin-Rollen, Login Security, Session-Timeouts und Brute-Force-Schutz prüfen.
• Exponierte Dienste wie RDP, SSH, Webserver, Portale und NAT-Regeln inventarisieren.
• Interne Zonen und VLAN-Regeln gegen Lateral Movement prüfen.
• ZTNA-, SSE- oder SASE-Optionen für typische Remote-Access-Anwendungen vergleichen.
• Threat Feeds und DNS Protection prüfen.
• Spoof Protection, DoS-Schutz und Geo-IP-Blocking nach Risiko aktivieren.
• TLS Inspection strukturiert testen und schrittweise ausrollen.

Strategisch planen

• End-of-Life-Systeme ersetzen.
• Firewall-, VPN-, DNS-, SD-WAN- und ZTNA-/SSE-Betrieb sinnvoll aufeinander abstimmen.
• Zentrales Management, Reporting und Alerting standardisieren, zum Beispiel über Sophos Central, SIEM oder bestehende Security-Plattformen.
• Syslog-/SIEM-Export und Log-Retention für forensische Auswertungen definieren.
• MDR/XDR/NDR-Signale in den Incident-Prozess integrieren.
• Wiederkehrende Firewall-Hardening-Reviews einführen.

Fazit

Network Security Best Practices sind kein einmaliges Projekt, sondern ein Betriebsmodell. Gerade weil Firewalls am Netzwerkrand so privilegiert sind, müssen sie regelmässig gehärtet, gepatcht, geprüft und in die Erkennung eingebunden werden.

Meine Empfehlung nach vielen Jahren mit Sophos Firewall ist deshalb klar: Eine moderne Firewall muss heute mehr sein als ein Schutzprodukt. Entscheidend sind ein sicheres Design, sichtbare Fehlkonfigurationen, schnelle Sicherheitskorrekturen und eine Reaktion, die im Ernstfall mit Endpoint, NDR, XDR und MDR zusammenspielt.

Oder ganz praktisch gesagt: Wenn eine Firewall so alt ist, dass sie eher ins Museum als ins Rack gehört, ist das nicht nur ein Betriebsrisiko. Es ist eine Angriffsfläche. Und genau diese Angriffsfläche halte ich so klein wie möglich.

Unterstützung durch Avanet

Wenn bei der Härtung einer Sophos Firewall Unterstützung benötigt wird, kann man sich gerne bei Avanet melden. Ich unterstütze als langjähriger Sophos-Spezialist bei Firewall-Audits, Health-Check-Reviews, Regelwerksbereinigung, Remote-Access- und ZTNA-/SSE-Planung, Update-Strategien und Schulungen für IT-Teams.

Gerade ein externer Blick auf Managementzugriffe, VPN-Konfiguration, alte Regeln, WAN-exponierte Dienste und Update-Status lohnt sich oft. Viele Risiken entstehen nicht durch eine einzelne falsche Einstellung, sondern durch gewachsene Ausnahmen, die im Alltag niemand mehr hinterfragt.

Bei Interesse reicht eine kurze Nachricht über das Kontaktformular. Danach lässt sich gemeinsam klären, ob ein kompaktes Firewall-Review, ein Audit oder eine Schulung für die jeweilige Umgebung am sinnvollsten ist.

FAQ

Weiterführende Links

• Avanet Blog: Sophos Firewall v22: Überblick und alle neuen Features
• Avanet Blog: Threat Intelligence Feeds für die Firewall
• Avanet Blog: Sophos ZTNA Gateway auf der Sophos Firewall
• Avanet Blog: Sophos NDR - Blinde Flecken im Netzwerk beseitigen
• Avanet KB: Sophos Firewall Firmware Update - Vorbereitung und Best Practices

Quellen

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report