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.

Der typische Menüpfad liegt je nach SFOS-Version im Bereich:

Intrusion prevention > DoS & spoof protection

In älteren Oberflächen oder Navigationsansichten kann der Bereich zusätzlich unter Protect einsortiert sein. Wenn die Oberfläche leicht anders beschriftet ist, sollte man nach DoS, spoof protection oder intrusion prevention suchen. Entscheidend ist nicht der exakte Klickpfad, sondern dass die Funktion bewusst geplant, getestet und später geloggt wird.

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 der DoS-Prüfung aus. Breite Ausnahmen schwächen den eigentlichen Schutz.

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.

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. Mit einer klaren Zone oder einem klaren Interface starten, zum Beispiel WAN oder einer sauber getrennten Clientzone.
3. Aktivierung speichern.
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.

Wichtig ist die Erwartungshaltung: Ein aktivierter IP-MAC-Pair-Filter ohne gepflegte Trusted-MAC- oder IP-MAC-Einträge schützt nicht automatisch. Wenn keine passenden Einträge vorhanden sind, wird Traffic nicht blockiert, sondern zugelassen. Der Schutz entsteht erst 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.

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?
• Welche Ereignisse sollen nur geloggt und welche wirklich blockiert werden?
• 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 sind zwei Begriffe wichtig:

• Packet rate: Anzahl Pakete, die ein Host pro Minute senden oder empfangen darf, bevor Traffic verworfen wird.
• Burst rate: kurzfristiger Spike oberhalb der Packet Rate, der erlaubt wird, ohne sofort dauerhaft als Flood zu gelten.

Die 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öffentlichen Diensten und an bekannten Wartungsfenstern ausrichten.

Eine Besonderheit: IP-Flood-Konfiguration ist laut Sophos nicht in der Weboberfläche verfügbar, sondern nur per CLI. Solche Einstellungen sollten nicht nebenbei gesetzt werden, sondern mit Change, Dokumentation und Rückfallplan.

DoS bypass rules nur eng verwenden

DoS bypass rules sind nützlich, wenn ein klar bekannter Datenstrom sonst zuverlässig 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.

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

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 Sophos-Central-Betrieb prüfen, ob Central Firewall Reporting die gewünschten Ereignisse sichtbar macht.

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 NAT fallen auf: Die DoS-Schwelle zählt den Verkehr aus Sicht einer gemeinsamen 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.

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: Bypass wird vor DoS Protection geprüft und kann die Prüfung vollständig umgehen. Source, Destination, Protokoll und Ports eng setzen.
• 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