Sophos Firewall Spoof Protection und DoS Settings prüfen

Spoof Protection und DoS Settings gehören zu den klassischen Hardening-Funktionen einer Sophos Firewall. Die Funktionen reduzieren einfache, laute oder offensichtlich falsche Pakete, bevor daraus unnötiges Rauschen in Logs, Regeln oder veröffentlichten Diensten entsteht. Gleichzeitig sind diese Einstellungen kein magischer Schutz gegen jede Art von Angriff.

Der Artikel ordnet die Funktionen als vorsichtige Basishärtung ein: erst Netzdesign und Rückwege verstehen, dann aktivieren, testen und die Logs prüfen. Besonders wichtig ist die Abgrenzung: Diese Funktionen ergänzen saubere Firewall-Regeln, IPS, Threat Feeds, WAF und Logging. Ein Ersatz für diese Bausteine sind sie nicht.

Kurz erklärt

Spoof Protection prüft, ob Pakete mit einer plausiblen Quelladresse auf dem erwarteten Interface ankommen. Wenn zum Beispiel ein Paket mit interner Quelladresse aus Richtung Internet erscheint, ist das in den meisten Designs verdächtig. DoS Settings reagieren dagegen auf bestimmte Flooding- oder Verbindungsangriffsmuster, zum Beispiel auffällige Mengen an SYN-, UDP- oder ICMP-Traffic.

In SFOS 22 lautet der WebAdmin-Pfad:

Intrusion prevention > DoS & spoof protection

Die Einstellungen auf dieser Seite greifen in den Paketfluss ein. Vor Apply beziehungsweise Save deshalb die bisherigen Werte erfassen und einen Rückweg festlegen.

Was die Funktionen leisten

• Spoof Protection: verwirft Pakete mit unplausibler Source-IP, reduziert einfache Spoofing-Versuche und macht falsch geroutete Pakete sichtbarer. Die Funktion ersetzt aber keine saubere Zonen-, Interface- und Routingplanung.
• DoS Settings: begrenzen einfache Flooding-Muster und machen laute Angriffe oder Fehlkonfigurationen früher auffällig. Die Funktion ersetzt aber keinen Provider-DDoS-Schutz, keine WAF und kein sauber dimensioniertes Upstream-Design.

In der Praxis sind diese Funktionen vor allem als Basishärtung interessant. Der Nutzen liegt darin, offensichtlichen Unsinn zu reduzieren. Bei echten volumetrischen DDoS-Angriffen ist die Internetleitung oft schon ausgelastet, bevor die Firewall sinnvoll reagieren kann. Dann braucht es Schutz beim Provider, ein vorgelagertes Scrubbing oder eine andere Architektur.

Schutzarten nicht vermischen

In derselben Maske liegen mehrere Mechanismen, die im Betrieb unterschiedliche Fragen beantworten.

• Enable spoof prevention: aktiviert Spoof Prevention für ausgewählte Zonen. Falsch verstandene Zonen oder Rückwege können legitimen Traffic treffen.
• Trusted MAC und IP-MAC-Paare: bekannte MAC-Adressen oder IP-MAC-Kombinationen werden als vertrauenswürdig behandelt. Bei mobilen Geräten, DHCP-Wechseln oder Virtualisierung kann daraus Pflegeaufwand entstehen.
• DoS settings: setzen Schwellenwerte und Flags für SYN-, UDP-, TCP- oder ICMP/ICMPv6-Flooding. Zu strenge Werte stören legitime Lastspitzen, Scans, Monitoring oder VoIP.
• DoS bypass rule: nimmt bestimmten Traffic von den DoS Settings im WebAdmin aus. Breite Ausnahmen schwächen diesen Schutz. Für das Zusammenspiel mit CLI-Policies gilt die Versionsqualifikation im CLI-Abschnitt.

Diese Trennung ist wichtig, weil ein Fehler nach der Aktivierung nicht automatisch ein Firewall-Regelproblem ist. Manchmal ist die DoS-Schwelle zu aggressiv, manchmal passt eine IP-MAC-Bindung nicht mehr, und manchmal zeigt Spoof Protection auf ein echtes Routing- oder VLAN-Problem.

Wann Spoof Protection sinnvoll ist

Spoof Protection passt besonders gut zu klar segmentierten Netzen, bei denen Source-Netze, Interfaces und Routen sauber geplant sind. Je eindeutiger die Netzstruktur, desto einfacher lässt sich beurteilen, ob eine Quelladresse auf einem Interface plausibel ist.

Sinnvolle Einsatzfälle:

• Internet-WAN, auf dem keine internen RFC1918-Quellen auftauchen sollten.
• DMZ- oder Serverzonen mit klaren Quell- und Zielnetzen.
• Client-, Gast- oder IoT-Zonen, in denen keine fremden internen Netze als Source auftreten sollen.
• Standorte, bei denen Routing, VLANs und Zonen sauber dokumentiert sind.
• Umgebungen, in denen Paketdrops später mit Packet Capture und Logs nachvollziehbar sein müssen.

Schwieriger wird es bei asymmetrischem Routing, komplexen Transitnetzen, temporären Migrationspfaden, falsch dokumentierten VLANs oder mehreren Firewalls im selben Datenpfad. Dort kann ein legitimer Datenstrom wie Spoofing aussehen, obwohl eigentlich das Routingdesign oder der Rückweg unsauber ist.

Vor der Aktivierung prüfen

Spoof Protection und DoS Settings sollten nicht blind in einer produktiven Umgebung aktiviert werden. Vorher sollte klar sein, welche Netze und Dienste betroffen sind.

Wichtige Prüfpunkte:

1. Zonen, Interfaces, VLANs, Bridges und LAGs dokumentieren.
2. Statische Routen, SD-WAN Routes, VPN-Routen und asymmetrische Pfade prüfen.
3. Veröffentlichte Dienste über DNAT oder WAF identifizieren.
4. Kritische Dienste wie VoIP, Monitoring, Backup, Scans, VPN und Standortverbindungen notieren.
5. Logging und zentrale Auswertung vorbereiten, falls Ereignisse später nachvollziehbar sein müssen.
6. Wartungsfenster oder Pilotbereich für die erste Aktivierung festlegen.
7. Vorhandene DoS bypass rules, Trusted-MAC-Einträge und IP-MAC-Bindungen prüfen.
8. Den Ist-Zustand festhalten: ausgewählte Spoof-Prüfung und Zonen, Restrict unknown IP on trusted MAC, alle Apply-Flags, Packet- und Burst-Raten sowie vorhandene Ausnahmen und Bindungen. Diese Werte werden für den Rückbau benötigt.

Wenn schon normale Firewall-Regeln schwer nachvollziehbar sind, sollte zuerst der Regel- und Routingzustand bereinigt werden. Für einzelne Testverbindungen ist Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture der bessere Einstieg.

Spoof Protection vorsichtig aktivieren

Für Spoof Protection ist ein schrittweiser Ansatz sinnvoll. Zuerst sollte man die eindeutigsten Bereiche absichern, nicht sofort jede Sonderzone.

Praktischer Ablauf:

1. Aktuelle Konfiguration sichern oder mindestens die betroffenen Einstellungen dokumentieren.
2. Unter Intrusion prevention > DoS & spoof protection Enable spoof prevention wählen, die gewünschte Prüfart und zunächst nur eindeutig dokumentierte Zonen auswählen.
3. Mit Apply aktivieren.
4. Geplante Testverbindungen ausführen: Internetzugriff, VPN, veröffentlichte Dienste, zentrale Server, Monitoring.
5. Log Viewer und Packet Capture auf unerwartete Drops prüfen.
6. Auffällige legitime Drops nicht sofort mit breiten Ausnahmen umgehen, sondern zuerst Routing, Source-IP und Interface prüfen.

Ein häufiger Fehler ist, Spoof Protection als reinen Sicherheits-Haken zu behandeln. In Wirklichkeit prüft die Funktion eine Annahme über das Netzdesign. Wenn diese Annahme nicht stimmt, muss nicht zwingend Spoof Protection falsch sein. Häufig ist dann ein Interface, eine Route, ein VLAN oder ein Rückweg nicht so gebaut, wie man es erwartet.

IP, MAC und IP-MAC-Paare richtig verstehen

Sophos unterscheidet mehrere Prüfarten. IP spoofing verwirft Traffic, wenn die Source-IP nicht zur Routingtabelle oder zu einem direkt verbundenen Subnetz passt. MAC filter arbeitet mit vertrauenswürdigen MAC-Adressen; dafür muss mindestens eine Trusted MAC Address gepflegt sein. Der MAC-Filter wird nicht auf DHCP-Pakete angewendet. IP-MAC pair filter prüft, ob die eingehende Kombination aus IP-Adresse und MAC-Adresse zu einem bekannten Paar passt.

Das ist in statischen, klar kontrollierten Netzen nützlich, kann in dynamischen Umgebungen aber schnell Pflegeaufwand erzeugen. DHCP, WLAN-Roaming, virtuelle Maschinen, Hypervisor, Cluster, NAC, Dockingstationen oder Gerätewechsel können legitime MAC-/IP-Wechsel erzeugen. Für solche Netze sollte man zuerst beobachten und nur dort binden, wo die Betriebsrealität stabil genug ist.

Wie man die lokale Neighbor-Tabelle prüft und eine statische IP-, MAC- und Interface-Bindung bewusst anlegt, erklärt ARP- und NDP-Neighbor-Cache prüfen.

Wichtig ist die Erwartungshaltung: Wenn keine Trusted MAC konfiguriert ist, lässt der aktivierte IP-MAC pair filter sämtlichen Traffic durch diese Prüfung zu. Eine leere Trusted-MAC-Liste ist aber nicht dasselbe wie ein Paket, das von einer konfigurierten IP-MAC-Bindung abweicht. Bei vorhandenen Einträgen hängt die Filterwirkung von den Bindungen und der Option Restrict unknown IP on trusted MAC ab; ein fehlendes passendes Paar bedeutet nicht unabhängig von dieser Option immer eine Blockierung. Der Schutz entsteht durch gepflegte und getestete Bindungen.

Die Option Restrict unknown IP on trusted MAC ist besonders streng: Pakete von einer Trusted MAC ohne passende IP-Bindung können verworfen werden, wenn die IP aus Sicht der Firewall unbekannt ist. Das ist ein Sicherheitsgewinn in kontrollierten Netzen, aber ein Stolperstein bei DHCP, Migrationen und temporären IP-Wechseln.

Einen einzelnen Trusted-MAC-Eintrag legt man unter Intrusion prevention > DoS & spoof protection im Bereich Spoof protection trusted MAC mit Add an. Nach der MAC-Adresse wählt man Static und trägt eine oder mehrere kommagetrennte IPv4- oder IPv6-Adressen ein, oder DHCP, damit die Firewall geleaste Adressen automatisch bindet. Nach Save sollten ein passender und ein absichtlich abweichender IP-MAC-Fall geprüft werden; der sichtbare Eintrag allein bestätigt die Filterwirkung noch nicht.

Für SFOS 23 ist die Suche beziehungsweise Filterung der Trusted-MAC-Liste dokumentiert, um einen MAC-Eintrag für die Pflege zu finden. Diese Listenansicht ändert nicht die Paketfilterung; daraus folgt auch nicht, dass SFOS 22 keine solchen Bedienelemente hat.

Trusted MACs kontrolliert importieren

Mehrere Trusted MACs lassen sich unter Intrusion prevention > DoS & spoof protection als .csv- oder .txt-Datei importieren. Die erste Zeile muss exakt MAC Address,IP Association,IP Address enthalten. Als IP Association sind Static, DHCP, DHCPv6 und None zulässig. Bei Static können pro MAC höchstens 16 IP-Adressen kommagetrennt angegeben werden; bei den anderen drei Zuordnungen bleibt das IP-Feld leer.

Ungültige MAC-Adressen, Zuordnungen oder IP-Adressen verwirft die Firewall beim Import. Das gilt auch für IP-Werte, die trotz DHCP, DHCPv6 oder None eingetragen wurden. Deshalb erst wenige Pilotzeilen importieren, danach die sichtbaren Bindungen prüfen und einen erlaubten sowie einen absichtlich falschen IP-MAC-Fall testen. Ein erfolgreicher Upload beweist noch nicht, dass die gewünschte Filterlogik greift.

DoS Settings planen

DoS Settings sollten zur Umgebung passen. Es ist selten sinnvoll, ungeprüft Werte aus einem fremden Beispiel zu übernehmen. Ein Standort mit wenigen Benutzern, VoIP und einem kleinen WAN verhält sich anders als ein Rechenzentrum, ein Schulnetz oder ein Standort mit regelmässigen Scans und Monitoring.

Vor der Anpassung sollte man diese Fragen beantworten:

• Welche öffentlichen Dienste sind exponiert?
• Gibt es legitime Lastspitzen, Scans, Monitoring oder Health Checks?
• Werden VoIP, VPN, WAF, DNAT oder grosse Dateiübertragungen genutzt?
• Für welche Protokolle soll das Apply-Flag gesetzt werden, sodass die Firewall Überschreitungen tatsächlich verwirft und protokolliert?
• Wer prüft nach der Aktivierung die Logs?

DoS Settings können helfen, einfache Flooding-Muster zu begrenzen. Zu strenge Schwellenwerte können aber auch legitimen Traffic treffen. Besonders vorsichtig sollte man bei VoIP, Monitoring-Systemen, Backup-Jobs, Schwachstellenscans und stark genutzten veröffentlichten Diensten sein.

In der Maske sind nicht nur klassische Floods relevant. Zusätzlich gibt es Flags wie Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet und ARP hardening. Diese Optionen sind sinnvolle Basishärtung, weil sie Manipulationen an Routing- oder ARP-Verhalten reduzieren können. Trotzdem sollte man sie nach der Aktivierung testen, besonders in Netzen mit Downstream-Routern, älteren Segmenten oder ungewöhnlichen Layer-2-Designs.

Bei den Schwellenwerten im WebAdmin sind zwei Begriffe wichtig:

• Packet rate: Anzahl Pakete, die ein Host pro Minute senden oder empfangen darf, bevor Traffic verworfen wird.
• Burst rate: Anzahl Pakete, die zunächst ohne Prüfung der Packet Rate zugelassen wird. Danach können gelegentliche kurze Spitzen über der Packet Rate toleriert werden, nicht aber häufige oder anhaltende Überschreitungen.

Das Apply-Flag entscheidet, ob der konfigurierte Grenzwert für das jeweilige Protokoll tatsächlich angewendet wird. Wenn die Werte zu hoch sind, bringen sie wenig. Wenn sie zu tief sind, blockieren sie legitime Lastspitzen. Deshalb sollte man die Werte am eigenen Traffic, an veröffentlichten Diensten und an bekannten Wartungsfenstern ausrichten.

Für eine belastbare Baseline zuerst normale Spitzenzeiten und geplante Sonderlasten erfassen. Danach pro Protokoll einen Wert wählen, der die gemessene legitime Spitze und die Kapazität des geschützten Dienstes berücksichtigt. Sophos veröffentlicht keinen universellen Produktionswert. Nach jeder Änderung nur eine klar definierte Lastprobe durchführen und Traffic dropped vergleichen; dieser Zähler ist seit dem letzten Neustart kumuliert und muss deshalb zusammen mit Testzeit und Ausgangswert notiert werden.

DoS-Status richtig lesen

Unter Intrusion prevention > DoS attacks zeigt SFOS in Echtzeit, für welche Source oder Destination ein Grenzwert greift und wie viele Pakete verworfen wurden. Nach einer Erkennung gilt die Begrenzung zunächst zehn Sekunden. Dauert der Angriff an, setzt die Firewall diesen Zähler rollierend alle zehn Sekunden zurück und begrenzt weiter. Endet der Angriff, verschwinden die Daten nach 30 Sekunden. Ein leerer Status beweist daher nicht, dass zuvor kein DoS-Ereignis stattgefunden hat; für die Rückschau werden die protokollierten Ereignisse benötigt.

DDoS-Signaturen nur auf unterstützten Modellen

Sophos bietet DDoS-Signaturen nur auf XGS 5500 und leistungsfähigeren Firewalls an. Auf einem unterstützten Modell ist der Ablauf:

1. Unter Intrusion prevention > IPS policies > Add eine eigene IPS Policy mit einem frei gewählten eindeutigen Namen erstellen und mit Save speichern.
2. Bei dieser gespeicherten Policy Edit wählen, dann Add und einen eindeutigen Regelnamen eingeben.
3. Select all wählen, im Smart filter ddos eingeben und mit Enter anwenden. Die Aktion Action bewusst auf Drop packet setzen.
4. Mit Save zuerst die Regel und danach mit dem zweiten Save die umschliessende Policy speichern.
5. Unter Rules and policies > Firewall rules die Policy der Firewall-Regel zuweisen, die den vorgesehenen Traffic tatsächlich verarbeitet; die Zuweisung und Schutzwirkung wie im IPS-Pilotablauf getrennt prüfen. Ohne diese Zuweisung hat die Policy keine Wirkung.

Diese Signaturen ergänzen die lokalen DoS-Grenzwerte, ersetzen aber keinen DDoS-Schutz beim Provider. Ist die Internetleitung bereits ausgelastet, kann die Firewall den Engpass hinter dem WAN-Anschluss nicht beheben. Modell, Lizenz, Regelmatch und ein kontrollierter Test müssen deshalb getrennt geprüft werden.

CLI-Regeln mit system dos-config

Über die Device Console lassen sich eigene DoS-Policies und passende Regeln anlegen. Das ist unter anderem für IP Flood nötig, weil dieser Typ im WebAdmin nicht konfiguriert werden kann. Die Einheiten unterscheiden sich: Der WebAdmin verwendet Pakete pro Minute, system dos-config dagegen Pakete pro Sekunde (pps).

Nach dem SSH-Login wählt man im Hauptmenü 4. Device Console. Die Befehle gehören an den Prompt console>, nicht in die Advanced Shell.

Zuerst wird die Policy mit Angriffstyp, Grenzwert und Zählweise erstellt. Danach legt die Regel fest, für welchen Traffic sie gilt. Das dokumentierte SYN-Beispiel sieht die Policy TestSYN und die Regel TestRuleSYN für Source 198.51.100.50 mit 1000 pps pro Source vor.

Vor dem Anlegen die Hilfe der Zielversion prüfen: Die veröffentlichte SFOS-22- und SFOS-23-Hilfe verwendet im Syntax- und Optionsblock für add dos-rule den Token rule_name, in den Beispielen dagegen rule-name. Ob die Schreibweisen austauschbar sind, ist nicht bestätigt. Zuerst in der Device Console der eingesetzten Version die Hilfe für system dos-config aufrufen und den akzeptierten Add-Token sowie die Parameter prüfen. Bleibt das unklar, keine Regel anlegen und mit Sophos Support klären. Der vollständige Add-Regelbefehl wird hier bewusst nicht als Kopiervorlage gezeigt. Auch die folgende Policy erst nach dieser Vorprüfung anlegen; sie allein bindet den Beispieltraffic noch nicht. Das Beispiel ist nicht als funktionierend getestet ausgewiesen.

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src

1000 pps ist ein Syntaxbeispiel und keine Empfehlung für ein produktives Netz. Für eine eigene Regel müssen mindestens folgende Teile bewusst angepasst werden:

• SYN-Flood: alternativ UDP-Flood, ICMP-Flood oder das nur hier verfügbare IP-Flood
• per-src: Grenzwert pro Source; alternativ per-dst pro Destination oder global für den gesamten passenden Traffic
• die tatsächlich benötigten Bedingungen für Source, Destination, Zone, Interface und Protokoll
• Grenzwert anhand einer gemessenen Baseline und der Kapazität des geschützten Dienstes

Die Zählweise global gilt nicht für die Zähler unter Intrusion prevention > DoS attacks. Diese UI-Zähler sind deshalb kein Nachweis einer global aggregierten CLI-Grenze. Die Konfiguration mit show prüfen und die Wirkung separat mit einem zeitlich und fachlich abgegrenzten Testflow und den zugehörigen Logs beurteilen.

Die CLI-Grenzwerte und Match-Felder sind enger definiert, als die kurze Beispielregel erkennen lässt:

system dos-config flush dos-rules entfernt alle CLI-DoS-Regeln und ist kein Rollback für einen einzelnen Test. Vor einem solchen globalen Eingriff werden die vorhandenen Regeln einzeln mit show dokumentiert und die Konfiguration gesichert. Für einen normalen Rückbau wird gezielt die benannte Regel gelöscht. Die veröffentlichte Hilfe beschreibt flush für Regeln, nicht als Löschung der zugehörigen Policies.

Nach dem Anlegen sollte zuerst kontrolliert werden, ob Namen, Typ, Grenzwert und Regelbedingung stimmen:

system dos-config show dos-policies policy-name TestSYN
system dos-config show dos-rules rule-name TestRuleSYN

Für den Rückbau zuerst die Regel und danach die nicht mehr verwendete Policy löschen:

system dos-config delete dos-rule rule-name TestRuleSYN
system dos-config delete dos-policy policy-name TestSYN

Die CLI-Syntax ist in der Sophos Firewall Command Line Help dokumentiert. Sie sollte trotzdem zuerst mit einem kontrollierten Testfluss eingesetzt werden. CLI-DoS-Regeln unterstützen nur IPv4. Bei einer aktiven IP-Flood-Policy zeigt die Spalte Applied unter Intrusion prevention > DoS attacks weiterhin No; Sophos beschreibt das als erwartetes Verhalten.

Diese IPv4-Grenze gilt für die CLI-DoS-Regeln, nicht für die nativen DoS settings unter Intrusion prevention > DoS & spoof protection im WebAdmin: Die dortigen DoS-Einstellungen schützen sowohl IPv4- als auch IPv6-Traffic, wenn die passenden Protokoll-Flags und Grenzwerte konfiguriert sind.

Für SFOS 22 ist dokumentiert, dass CLI-Regeln und -Policies vor den DoS- und Spoof-Einstellungen des WebAdmin ausgewertet werden; eine WebAdmin-Bypass-Regel hebt dabei eine passende CLI-Policy nicht automatisch auf. Die geprüfte SFOS-23-CLI-Hilfe legt diese übergreifende Reihenfolge nicht fest. Das belegt keine Änderung des Laufzeitverhaltens: Bevor man sich auf das Zusammenspiel von CLI und WebAdmin verlässt, muss es für die eingesetzte Version bestätigt sein. Innerhalb der WebAdmin-Einstellungen ist für beide Versionen weiterhin dokumentiert: zuerst DoS bypass rules, danach DoS Settings für den verbleibenden Traffic.

DoS bypass rules nur eng verwenden

DoS bypass rules sind nützlich, wenn ein klar bekannter Datenstrom sonst zuverlässig von den WebAdmin-DoS-Settings falsch getroffen wird. Typische Beispiele sind Monitoring, Health Checks oder ein eng definierter Dienst zwischen bekannten IP-Adressen. Die Ausnahme sollte dann so präzise wie möglich sein: konkrete Source, konkrete Destination, passendes Protokoll und enger Portbereich.

Breite Bypass-Regeln mit grossen Netzen, any-Logik oder pauschalen Portbereichen sind gefährlich. Solche Ausnahmen machen die DoS-Prüfung genau dort blind, wo sie später gebraucht wird. Wenn eine breite Ausnahme nötig wirkt, sollte zuerst geprüft werden, ob die Schwellenwerte, die Architektur oder der Testfall falsch bewertet wurden.

Für die WebAdmin-Einstellungen ist die Reihenfolge wichtig: Sophos Firewall prüft zuerst, ob eine DoS bypass rule passt, und wendet die dortigen DoS Settings erst auf den übrigen Traffic an. Eine zu breite Bypass-Regel kann diesen Schutz deshalb wirkungslos machen. Für Bypass-Regeln sollte man Source, Destination, Protokoll, Source Port und Destination Port bewusst setzen und nicht aus Bequemlichkeit mit * arbeiten.

Eine Ausnahme wird unter Intrusion prevention > DoS & spoof protection im Bereich DoS bypass rule mit Add erstellt. SFOS 22 verlangt IP version, Source- und Destination-IP, Protocol, Source Port und Destination Port; * steht für eine beliebige Adresse oder einen beliebigen Port. Bei einem HTTPS-Health-Check von 198.51.100.20 zu 203.0.113.10 wäre eine passende Konfiguration: Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * und Destination Port 443. Beide Dokumentationsadressen müssen durch die realen Endpunkte ersetzt werden. Der Source Port bleibt nur deshalb variabel, weil Clients üblicherweise einen dynamischen Quellport verwenden. Nach Save genau diesen Flow und einen anderen Flow testen; nur der definierte Health-Check darf den WebAdmin-DoS-Schutz umgehen.

HA: Änderung und Failover gemeinsam prüfen

In einem HA-Cluster synchronisiert das Primary-Gerät laut Sophos die Firewall-Konfiguration einschliesslich Regeln, Policies, Settings und CLI-Kommandos zum Auxiliary-Gerät. Die DoS- und Spoof-Konfiguration deshalb am aktuellen Primary ändern. Danach unter System services > High availability einen gesunden HA-Zustand prüfen und die angelegten WebAdmin-Einträge sowie CLI-Regeln nochmals kontrollieren. Bei Active-active muss die Lastprobe beide Verarbeitungspfade berücksichtigen; bei Active-passive gehört ein kontrollierter Failover-Test in das Wartungsfenster, sofern der Betriebsprozess ihn erlaubt. Nicht mit einer zweiten, abweichenden Konfiguration am Auxiliary „nachhelfen“.

Hinweis für SFOS 22.0 MR2

Die Release Notes zu SFOS 22.0 MR2 Build 546 nennen den behobenen Fehler NC-180226: Beim Hinzufügen einer doppelten MAC-Adresse unter Spoof protection trusted MAC zeigte der WebAdmin zuvor keine Fehlermeldung. Auf älteren 22.0-Builds darf ein fehlender Fehlerdialog daher nicht als Beweis für einen eindeutigen Eintrag gelten. Liste und tatsächliche Bindung kontrollieren oder auf einen korrigierten Build aktualisieren.

Was diese Einstellungen nicht lösen

Spoof Protection und DoS Settings sind wichtige Bausteine, aber sie lösen nicht jedes Sicherheitsproblem.

• Server wird über erlaubte HTTP-Anfragen angegriffen: WAF-Regel und Webserver Protection prüfen.
• Bekannt bösartige Quell-IP greift an: Threat Feeds oder Länder-/IP-Blocking prüfen.
• Exploit-Versuch gegen einen Dienst: IPS-Policy passend zur Regel aktivieren.
• Internetleitung ist durch DDoS voll: Provider, Scrubbing oder vorgelagerten DDoS-Schutz einbeziehen.
• Firewall-Regel erlaubt zu viel: Regelwerk, NAT und Objektmodell bereinigen.
• Drops sind nicht nachvollziehbar: Logging, Packet Capture, Syslog oder Central Reporting verbessern.

Für öffentlich erreichbare Server ist auch der Artikel Server mit DNAT auf Sophos Firewall veröffentlichen relevant. Dort geht es um NAT, Firewall-Regeln und typische Veröffentlichungsfehler.

Logs und Nachkontrolle

Nach der Aktivierung sollte man nicht nur prüfen, ob der normale Internetzugang noch funktioniert. Wichtig ist, ob die Firewall erwartete und unerwartete Ereignisse nachvollziehbar zeigt.

Prüfen:

1. Log Viewer nach Firewall- und relevanten Security-Ereignissen filtern.
2. Testtraffic mit klarer Source-IP, Destination-IP und Service auslösen.
3. Bei unklaren Drops Packet Capture verwenden.
4. Bei längerer Aufbewahrung Syslog an SIEM oder Logserver einplanen.
5. Bei Betrieb mit Sophos Fusion (ehemals Sophos Central) prüfen, ob Central Firewall Reporting die gewünschten Ereignisse sichtbar macht.

SFOS protokolliert den durch diese Schutzfunktionen verworfenen Traffic. Für eine DoS-Prüfung zuerst Uhrzeit, Source, Destination, Protokoll und die Zählerstände vor dem Test notieren. Während des Tests zeigt Intrusion prevention > DoS attacks Source beziehungsweise Destination und verworfene Daten in Echtzeit. Weil der Status 30 Sekunden nach Ende des Angriffs verschwindet und Traffic dropped seit dem letzten Neustart kumuliert, ist nur ein zeitlich abgegrenzter Vorher-/Nachher-Vergleich aussagekräftig. Die CLI-Zählweise global wird nicht auf diese UI-Zähler angewendet; auch ein solcher Vergleich validiert daher keine globale Aggregation. Für eine globale CLI-Policy die show-Konfigurationsprüfung von der Prüfung des definierten Testflows und seiner Drops/Logs trennen. Packet Capture beantwortet zusätzlich, auf welchem Interface und mit welchen Adressen der Flow ankam; ein Capture allein beweist aber nicht, welcher Schutzmechanismus verworfen hat.

Wenn ein Paket verworfen wird, aber der Grund nicht klar ist, hilft die systematische Drop-Analyse in Sophos Firewall verwirft Pakete: Ursachen prüfen. Dort ist auch beschrieben, warum Log Viewer und Packet Capture unterschiedliche Fragen beantworten.

Fehlersuche nach der Aktivierung

Nach einer Änderung sollte man Symptome nicht vorschnell als Angriff interpretieren. Die schnellste Analyse ist meistens eine kleine Tabelle mit Erwartung, Beobachtung und nächstem Test.

• Ein einzelnes Netz verliert Zugriff: Das Source-Netz kommt möglicherweise auf einem anderen Interface an als erwartet. Route, VLAN, SD-WAN Route und Packet Capture vergleichen.
• Viele Clients hinter vorgeschaltetem NAT fallen auf: Wurde der Traffic bereits vor der Sophos Firewall genattet, sieht sie mehrere Clients als gemeinsame Source. Schwellenwert, NAT-Pfad und legitime Lastspitze prüfen.
• VoIP, Monitoring oder Scanner erzeugt Drops: Regelmässige Paketraten wirken möglicherweise wie Flooding. Engen Testzeitraum, Log Viewer und falls nötig eine präzise Bypass-Regel prüfen.
• Nach DHCP-Änderung funktionieren Geräte nicht mehr: IP-MAC-Bindung oder Trusted-MAC-Logik passt möglicherweise nicht mehr. Lease, MAC-Adresse und Bindung kontrollieren.
• Nur Rücktraffic fehlt: Ein asymmetrischer Pfad oder falsches Gateway ist wahrscheinlich. Hin- und Rückweg getrennt mit Packet Capture prüfen.
• ARP- oder ICMP-Änderung erzeugt Seiteneffekte: ARP hardening, source-routed packets oder ICMP redirect können auf ungewöhnliche Netzdesigns treffen. Downstream-Router, Layer-2-Segmente und Routingpfad prüfen.

Sicher zurückbauen

Wenn legitimer Traffic betroffen ist und die Ursache im Wartungsfenster nicht eindeutig geklärt werden kann, nicht mit einer breiten Ausnahme improvisieren. Die zuvor dokumentierten Packet- und Burst-Raten, Apply-Flags, Spoof-Prüfart, Zonen und Restrict unknown IP on trusted MAC wiederherstellen; neu angelegte Bypass- oder Trusted-MAC-Einträge gezielt entfernen. Danach Apply beziehungsweise Save verwenden und denselben Testflow erneut prüfen. Für eine CLI-Policy gilt der oben gezeigte Rückbau: zuerst nur die benannte Regel löschen, danach die nur für sie angelegte, nicht mehr verwendete Policy. flush dos-rules gehört nicht in diesen Rückbau.

Typische Fehler

• Spoof Protection ohne Routingverständnis aktivieren: Legitimer Traffic kann blockiert werden. Zonen, Interfaces, Routen und Rückwege vorher prüfen.
• DoS-Schwellen ungeprüft übernehmen: VoIP, Monitoring, Scans oder veröffentlichte Dienste können gestört werden. Baseline und Testphase einplanen.
• Packet Rate und Burst Rate verwechseln: Dauerhafte Paketrate und kurzfristiger Spike sind unterschiedliche Stellschrauben. Beide müssen zum Dienst passen.
• Jede Auffälligkeit mit breiter Ausnahme lösen: Härtung wird wirkungslos und unübersichtlich. Ursache eingrenzen und Ausnahmen eng dokumentieren.
• DoS bypass rule zu breit setzen: Im WebAdmin wird der Bypass vor den dortigen DoS Settings geprüft und kann diese Kontrolle vollständig umgehen. Source, Destination, Protokoll und Ports eng setzen; separate CLI-Policies zusätzlich prüfen.
• IP-MAC-Pair-Filter leer lassen: Ohne gepflegte Einträge entsteht keine wirksame Bindung. Nach der Aktivierung immer mit einem bekannten Testclient prüfen.
• DoS Settings als DDoS-Schutz verkaufen: Bei Bandbreitenangriffen entsteht eine falsche Erwartung. Provider- und Upstream-Schutz separat planen.
• Keine Logs prüfen: Fehlblockaden oder Angriffe bleiben unsichtbar. Log Viewer, Central Reporting oder Syslog als Betriebspunkt definieren.
• Spoofing-Drops als reinen Angriff interpretieren: Routing- oder VLAN-Fehler werden übersehen. Source-IP, Interface, Route und Packet Capture vergleichen.

Betriebscheckliste

Vor der Aktivierung:

• Zonen, Interfaces und Routing verstanden.
• Kritische Dienste und Testfälle definiert.
• Packet Rate, Burst Rate und aktivierte Flags fachlich bewertet.
• Backup oder Change-Dokumentation vorhanden.
• Logging und Auswertung vorbereitet.
• Pilotbereich oder Wartungsfenster festgelegt.

Nach der Aktivierung:

• Internet, VPN, WAF, DNAT, VoIP und Monitoring getestet.
• Log Viewer auf unerwartete Drops geprüft.
• Packet Capture für mindestens einen klaren Testfall verwendet, wenn Drops auftreten.
• Ausnahmen nur eng und mit Begründung gesetzt.
• DoS bypass rules auf Source, Destination, Protokoll und Ports geprüft.
• Ergebnis in der Betriebsdokumentation festgehalten.

Regelmässig:

• DoS- und Spoof-Ereignisse prüfen.
• Ausnahmen auf Notwendigkeit kontrollieren.
• Nach Netzumbauten, VPN-Änderungen oder neuen VLANs erneut testen.
• Logs mit IPS-, Threat-Feed-, WAF- und Firewall-Regelereignissen korrelieren.

FAQ