Sophos Firewall Spoof Protection en DoS Settings controleren

Spoof Protection en DoS Settings behoren tot de klassieke verhardingsfuncties van een Sophos Firewall. De functies verminderen eenvoudige, luidruchtige of duidelijk onjuiste pakketten voordat ze onnodige ruis worden in logs, regels of gepubliceerde services. Tegelijkertijd bieden deze instellingen geen magische bescherming tegen elke vorm van aanval.

Het artikel classificeert de functies als zorgvuldige basisverharding: begrijp eerst het netwerkontwerp en de retourpaden, activeer, test en controleer vervolgens de logbestanden. Het onderscheid is bijzonder belangrijk: deze functies vormen een aanvulling op goed ingerichte firewallregels, IPS, Threat Feeds, WAF en loggen. Ze zijn geen vervanging voor deze bouwstenen.

Kort uitgelegd

Spoof Protection controleert of pakketten met een plausibel bronadres op de verwachte interface aankomen. Als er bijvoorbeeld een pakketje met een intern bronadres uit de richting van internet verschijnt, is dit bij de meeste ontwerpen verdacht. DoS Settings reageert daarentegen op bepaalde flooding- of verbindingsaanvalpatronen, bijvoorbeeld merkbare hoeveelheden SYN-, UDP- of ICMP-verkeer.

In SFOS 22 en SFOS 23 is het WebAdmin-pad:

Intrusion prevention > DoS & spoof protection

De instellingen op deze pagina grijpen in op de pakketverwerking. Leg daarom vóór Apply of Save de bestaande waarden en de terugweg vast.

Wat de functies doen

• Spoof Protection: verwerpt pakketten met een onwaarschijnlijk Source-IP, vermindert eenvoudige spoofingpogingen en maakt verkeerd gerouteerde pakketten beter zichtbaar. De functie vervangt echter geen gedegen planning van zones, interfaces en routing.
• DoS Settings: beperken eenvoudige floodingpatronen en maken opvallende aanvallen of verkeerde configuraties eerder zichtbaar. De functie vervangt echter geen DDoS-bescherming door de provider, geen WAF en geen goed gedimensioneerd upstreamontwerp.

In de praktijk zijn deze functies bijzonder interessant als basisverharding. Het voordeel is dat voor de hand liggende onzin wordt verminderd. Bij echte volumetrische DDoS-aanvallen is de internetverbinding vaak al vol voordat de firewall zinvol kan reageren. Dan heb je bescherming nodig van de provider, upstream scrubbing of een andere architectuur.

Beschermingstypen niet door elkaar halen

In hetzelfde scherm staan verschillende mechanismen die in de praktijk elk een andere vraag beantwoorden.

• Enable spoof prevention: activeert Spoof Prevention voor geselecteerde zones. Verkeerd begrepen zones of retourpaden kunnen legitiem verkeer raken.
• Trusted MAC en IP-MAC-paren: bekende MAC-adressen of IP-MAC-combinaties worden als vertrouwd behandeld. Bij mobiele apparaten, DHCP-wijzigingen of virtualisatie kan dit extra beheer vereisen.
• DoS settings: stellen drempelwaarden en flags in voor SYN-, UDP-, TCP- of ICMP/ICMPv6-flooding. Te strenge waarden verstoren legitieme belastingpieken, scans, monitoring of VoIP.
• DoS bypass rule: sluit bepaald verkeer uit van de DoS Settings in WebAdmin. Brede uitzonderingen verzwakken deze bescherming. Zie voor de wisselwerking met CLI-policies de versieafbakening in het CLI-gedeelte.

Dit onderscheid is belangrijk, omdat een fout na activering niet automatisch een probleem met een firewallregel is. Soms is de DoS-drempel te agressief, soms klopt een IP-MAC-binding niet meer en soms wijst Spoof Protection op een echt routing- of VLAN-probleem.

Wanneer Spoof Protection zinvol is

Spoof Protection past bijzonder goed bij duidelijk gesegmenteerde netwerken waarin bronnetwerken, interfaces en routes duidelijk gepland zijn. Hoe duidelijker de netwerkstructuur, hoe gemakkelijker het is om te beoordelen of een bronadres op een interface plausibel is.

Nuttige toepassingen:

• Internet WAN waarop geen interne RFC1918-bronnen mogen verschijnen.
• DMZ of serverzones met duidelijke bron- en bestemmingsnetwerken.
• Client-, gast- of IoT-zones waarin geen andere interne netwerken als Source mogen voorkomen.
• Locaties waar routing, VLANs en zones duidelijk gedocumenteerd zijn.
• Omgevingen waarin pakketdroppingen later traceerbaar moeten zijn met Packet Capture en logboeken.

Het wordt moeilijker met asymmetrische routing, complexe transitnetwerken, tijdelijke migratiepaden, onjuist gedocumenteerde VLANs of meerdere firewalls in hetzelfde datapad. Een legitieme datastroom kan op spoofing lijken, ook al is het routeringsontwerp of het retourpad feitelijk onrein.

Controleer vóór activering

Spoof Protection en DoS Settings mogen niet blindelings worden geactiveerd in een productieomgeving. Het moet vooraf duidelijk zijn om welke netwerken en diensten het gaat.

Belangrijke controlepunten:

1. Zones, interfaces, VLANs, bridges en LAGs documenteren.
2. Controleer statische routes, SD-WAN routes, VPN-routes en asymmetrische paden.
3. Identificeer gepubliceerde services via DNAT of WAF.
4. Let op kritische services zoals VoIP, monitoring, back-up, scans, VPN en siteverbindingen.
5. Registratie en centrale evaluatie voorbereiden als gebeurtenissen later traceerbaar moeten zijn.
6. Onderhoudsvenster of pilotgebied instellen voor eerste activering.
7. Controleer bestaande DoS bypass rules, Trusted MAC-items en IP-MAC-bindings.
8. Leg het huidige spoof-inspectietype en de zones vast, evenals Restrict unknown IP on trusted MAC, alle Apply-flags, Packet Rate, Burst Rate, uitzonderingen en bindings. Deze waarden zijn nodig om de wijziging terug te draaien.

Als normale firewallregels moeilijk te begrijpen zijn, moeten de regel- en routeringsstatus eerst worden opgeschoond. Voor individuele testverbindingen is Test firewallregel met Log Viewer, Policy Test en Packet Capture een beter begin.

Spoof Protection voorzichtig activeren

Een stapsgewijze aanpak is zinvol voor Spoof Protection. U moet eerst de duidelijkste gebieden beveiligen, en niet onmiddellijk elke speciale zone.

Praktisch proces:

1. Sla de huidige configuratie op of documenteer in ieder geval de betreffende instellingen.
2. Selecteer onder Intrusion prevention > DoS & spoof protection Enable spoof prevention, het benodigde inspectietype en aanvankelijk alleen goed gedocumenteerde zones.
3. Selecteer Apply.
4. Voer geplande testverbindingen uit: internettoegang, VPN, gepubliceerde services, centrale servers, monitoring.
5. Log Viewer en Packet Capture controleren op onverwacht verworpen pakketten.
6. Opvallende gevallen waarin legitieme pakketten worden verworpen niet direct met brede uitzonderingen omzeilen, maar eerst routing, Source-IP en Interface controleren.

Een veelgemaakte fout is om Spoof Protection als slechts een selectievakje voor beveiliging te beschouwen. In werkelijkheid controleert de functie een aanname over het netwerkontwerp. Als die aanname niet klopt, betekent dat niet noodzakelijk dat Spoof Protection onjuist werkt. Vaak is dan een interface, een route, een VLAN of een retourpad niet ingericht zoals verwacht.

IP, MAC en IP-MAC-paren goed begrijpen

Sophos onderscheidt meerdere controlemethoden. IP spoofing verwerpt verkeer als het Source-IP niet bij de routingtabel past of het pakket niet afkomstig is uit een direct verbonden subnet. MAC filter verwerpt pakketten waarvan het MAC-adres niet als Trusted MAC is geregistreerd; hiervoor moet ten minste één Trusted MAC Address zijn vastgelegd. Het MAC-filter wordt niet toegepast op DHCP-pakketten. IP-MAC pair filter controleert of de binnenkomende combinatie van IP-adres en MAC-adres overeenkomt met een bekend paar.

Dat is nuttig in statische, duidelijk gecontroleerde netwerken, maar kan in dynamische omgevingen snel onderhoudswerk opleveren. DHCP, Wi-Fi roaming, virtuele machines, hypervisors, clusters, NAC, dockingstations of apparaatwissels kunnen legitieme MAC/IP-wijzigingen veroorzaken. Voor zulke netwerken is het beter eerst te observeren en alleen te binden waar de operationele werkelijkheid stabiel genoeg is.

Voorbeeld met een core switch: de switch verzorgt de inter-VLAN-routing en gebruikt de Sophos Firewall als Default Gateway. Een client in VLAN 1 met 10.10.10.5 verstuurt een internetverzoek dat op de LAN-interface van de firewall aankomt. Dat de switch de VLANs kent, maakt hun subnetten voor de firewall nog niet direct verbonden. Controleer vóór activering de route voor 10.10.10.5 en de direct aangesloten subnetten op de firewall. Als niet aan de gedocumenteerde IP-spoofingvoorwaarden is voldaan, kan het verzoek ondanks het legitieme clientadres worden verworpen. Alleen een WAN-toegangstest vervangt deze controle van het interne pad niet.

Hoe men de lokale neighbortabel controleert en bewust een statische koppeling tussen IP, MAC en interface maakt, staat in De ARP- en NDP-neighbor-cache controleren.

Maak onderscheid tussen de situaties: als er geen Trusted MAC is geconfigureerd, laat het ingeschakelde IP-MAC pair filter al het verkeer door deze controle. Een lege Trusted MAC-lijst is niet hetzelfde als een pakket dat afwijkt van een geconfigureerde IP-MAC-binding. Bij aanwezige vermeldingen hangt de filtering af van de bindings en Restrict unknown IP on trusted MAC; een ontbrekend passend paar betekent niet altijd een blokkering ongeacht deze optie. Bescherming vereist onderhouden en geteste bindings.

De optie Restrict unknown IP on trusted MAC is bijzonder strikt: als IP-MAC pair filter in de geselecteerde zones is ingeschakeld, beschrijft Sophos voor de aangevinkte optie dat pakketten van een Trusted MAC zonder IP-binding worden verworpen als het IP-adres onbekend is. «Onbekend» betekent hier: geen passende vermelding in de routingtabel of niet afkomstig uit een direct verbonden subnet. Dit levert beveiligingswinst op in gecontroleerde netwerken, maar kan een struikelblok zijn bij DHCP, migraties en tijdelijke IP-wijzigingen.

Voor de niet-aangevinkte optie beschrijft de algemene help voor SFOS 22 en SFOS 23 dat een Trusted MAC met een willekeurig IP-adres en een Trusted MAC zonder IP-binding worden toegestaan. De afzonderlijke Add-instructie stelt daarentegen in algemene bewoordingen dat bij een binding alleen een passend IP-MAC-paar wordt geaccepteerd. Deze uitspraken mogen niet worden samengevoegd tot een onvoorwaardelijke garantie dat verkeer wordt geblokkeerd. Controleer de controlemethode, zone, binding en het selectievakje in samenhang en controleer de benodigde toegestane en afwijkende gevallen in de geïnstalleerde build; stem bij een onduidelijk effect vóór gebruik in productie af met Sophos Support.

Een afzonderlijke Trusted MAC-vermelding wordt onder Intrusion prevention > DoS & spoof protection in de sectie Spoof protection trusted MAC met Add aangemaakt. Na het invoeren van het MAC-adres wordt Static geselecteerd en worden een of meer kommagescheiden IPv4- of IPv6-adressen opgegeven, of wordt DHCP geselecteerd om geleasete adressen automatisch te koppelen. Test na Save één overeenkomende en één bewust afwijkende IP-MAC-combinatie; alleen een zichtbare vermelding bevestigt nog niet dat het filter wordt toegepast.

Voor SFOS 23 zijn zoek- en filteropties in de Trusted MAC-lijst gedocumenteerd om een vermelding voor onderhoud te vinden. Deze lijstweergave verandert de pakketfiltering niet en betekent ook niet dat SFOS 22 zulke bedieningselementen mist.

Trusted MACs gecontroleerd importeren

Meerdere Trusted MACs kunnen onder Intrusion prevention > DoS & spoof protection als .csv- of .txt-bestand worden geïmporteerd. Kies in het gedeelte Spoof protection trusted MAC voor Import, selecteer het bestand met Browse en upload het met Upload file. Het MAC-adres en IP Association moeten per regel worden opgegeven. De eerste regel moet exact MAC Address,IP Association,IP Address bevatten. Als IP Association zijn Static, DHCP, DHCPv6 en None toegestaan. Bij Static kunnen per MAC maximaal 16 IP-adressen worden opgegeven, gescheiden door komma’s; bij de andere drie toewijzingen blijft het IP-veld leeg.

Het volgende formaatvoorbeeld toont statische IPv4- en IPv6-bindingen en de drie toewijzingen zonder IP-veld:

MAC Address,IP Association,IP Address
02:00:00:00:00:01,Static,192.0.2.10,192.0.2.11
02:00:00:00:00:02,Static,2001:db8::10,2001:db8::11
02:00:00:00:00:03,DHCP
02:00:00:00:00:04,DHCPv6
02:00:00:00:00:05,None

De MAC- en IP-adressen zijn fictieve plaatsaanduidingen, geen apparaten die moeten worden toegestaan. Vervang elke regel door het werkelijke MAC-adres van het apparaat en de bewust gekozen toewijzing. Static past bij bekende vaste adressen, DHCP respectievelijk DHCPv6 bij de automatische leasebinding; None bevat geen IP-binding en is daarom geen vervanging voor een statische paarcontrole.

De firewall verwerpt tijdens de import de volledige vermelding als deze een ongeldig MAC-adres, een ongeldige IP Association of een ongeldig IP-adres bevat. Daarvan moeten IP-waarden worden onderscheiden die ondanks DHCP, DHCPv6 of None zijn ingevuld: deze IP-waarden worden verworpen; hieruit volgt niet automatisch dat de volledige MAC-vermelding wordt verwijderd. Importeer daarom eerst enkele pilotregels, controleer daarna de zichtbare bindingen en test een toegestaan en een bewust onjuist IP-MAC-geval. Een geslaagde upload bewijst nog niet dat de gewenste filterlogica wordt toegepast.

DoS Settings plannen

DoS Settings moet bij de omgeving passen. Het heeft zelden zin om zonder controle waarden uit een ander voorbeeld over te nemen. Een site met een paar gebruikers, VoIP en een kleine WAN gedraagt ​​zich anders dan een datacenter, een schoolnetwerk of een site met regelmatige scans en monitoring.

Beantwoord deze vragen voordat u de instellingen aanpast:

• Welke openbare diensten zijn zichtbaar?
• Zijn er legitieme belastingpieken, scans, monitoring of gezondheidscontroles?
• Worden VoIP, VPN, WAF, DNAT of grote bestandsoverdrachten gebruikt?
• Voor welke protocollen moet de Apply-flag worden ingeschakeld, zodat de firewall overschrijdingen daadwerkelijk verwerpt en logt?
• Wie controleert de logs na activatie?

DoS Settings kan eenvoudige overstromingspatronen helpen beperken. Te strenge drempels kunnen echter ook van invloed zijn op legitiem verkeer. Er moet bijzondere aandacht worden besteed aan VoIP, monitoringsystemen, back-uptaken, kwetsbaarheidsscans en intensief gebruikte gepubliceerde services.

De floodtypen veroorzaken verschillende belastingen: SYN flood genereert veel halfopen TCP-verbindingen; de server antwoordt met SYN-ACK, maar ontvangt geen afsluitend antwoord. TCP flood duidt in het algemeen op een hoge TCP-pakketsnelheid. UDP flood kan de doelhost belasten met poortcontroles en ICMP-antwoorden voor niet-gebruikte poorten. ICMP/ICMPv6 flood betreft veel Echo Requests en kan bandbreedte verbruiken. Bij DDoS is de belasting verspreid over meerdere apparaten afkomstig; één Source-grenswaarde beantwoordt daarom niet dezelfde vraag als een Destination-grenswaarde.

In het scherm zijn daarnaast deze flags relevant:

• Dropped source routed packets: verwerpt pakketten waarvan de route door de afzender wordt bepaald. Zo wordt deze mogelijkheid tot routingmanipulatie beperkt.
• Disable ICMP/ICMPv6 redirect packet: accepteert geen ICMP- respectievelijk ICMPv6-redirects. Downstreamrouters kunnen dergelijke berichten ook legitiem verzenden voor een betere of actieve route; de optie verandert daarom een routingaanname en niet alleen de aanvalsdetectie.
• ARP hardening: staat ARP Replies alleen toe als Source-IP en Destination-IP in hetzelfde subnet liggen. Sophos beschrijft dit als bescherming tegen ARP Flood en ARP Poisoning.

Deze opties zijn zinvolle basishardening, omdat ze manipulatie van routing- of ARP-gedrag kunnen verminderen. Toch moeten ze na activering worden getest, vooral in netwerken met downstreamrouters, oudere segmenten of ongebruikelijke Layer-2-ontwerpen.

Bij de drempelwaarden in WebAdmin zijn twee begrippen belangrijk:

• Packet rate: aantal pakketten dat een host per minuut mag verzenden of ontvangen voordat verkeer wordt verworpen.
• Burst rate: aantal pakketten dat aanvankelijk wordt toegelaten zonder de Packet Rate te controleren. Daarna kunnen incidentele korte pieken boven de Packet Rate worden getolereerd, maar geen frequente of aanhoudende overschrijdingen.

De Apply flag bepaalt of de geconfigureerde limiet daadwerkelijk op het betreffende protocol wordt toegepast. Te hoge waarden doen weinig. Te lage waarden blokkeren legitieme pieken. Stem de waarden daarom af op eigen verkeer, gepubliceerde services en bekende onderhoudsvensters.

Leg voor een betrouwbare uitgangssituatie eerst normale pieken en geplande uitzonderlijke belasting vast. Kies daarna per protocol een waarde op basis van de gemeten legitieme piek en de capaciteit van de beschermde dienst; Sophos geeft geen universele productiewaarde. Voer na elke wijziging één vastgelegde belastingtest uit en vergelijk Traffic dropped. Deze teller loopt op sinds de laatste herstart van de firewall, dus noteer ook het testtijdstip en de beginwaarde.

De DoS-status correct lezen

Onder Intrusion prevention > DoS attacks toont SFOS in realtime voor welke Source of Destination een grenswaarde wordt toegepast en hoeveel pakketten zijn verworpen. Klik op het aanvalstype om de details te openen; vanuit DoS & spoof protection leidt ook de statuslink naar deze weergave. Na een detectie geldt de beperking aanvankelijk tien seconden. Als de aanval dan is beëindigd, wordt de beperking opgeheven. Als de aanval voortduurt, stelt de firewall deze teller doorlopend elke tien seconden opnieuw in en blijft de beperking gelden. Een nieuwe aanval vanaf dezelfde Source of naar dezelfde Destination stelt de teller opnieuw in en activeert de beperking opnieuw. Als de aanval eindigt, verdwijnen de gegevens na 30 seconden. Een lege status bewijst daarom niet dat er eerder geen DoS-gebeurtenis heeft plaatsgevonden; om terug te kijken zijn de gelogde gebeurtenissen nodig.

De WebAdmin-grenzen gelden per Source of Destination, niet als een algemeen totaal voor alle hosts. Een voorbeeld dat uitsluitend ter toelichting dient met Burst rate 100: de eerste 100 pakketten worden aanvankelijk toegestaan zonder controle van de Packet rate; daarna wordt de snelheid vergeleken. Onder de geconfigureerde snelheid wordt verkeer geaccepteerd, erboven kan het worden verworpen. 100 is geen aanbevolen productiewaarde.

Stel het voorbeeldverloop niet gelijk aan de statustimer: de algemene help voor SFOS 22 en SFOS 23 noemt dit verloop een ARP-Flood-poging en beschrijft dat meer pakketten worden verworpen en logs worden aangemaakt als het volgende pakket van dezelfde Source binnen 30 seconden aankomt. De help beschrijft dat verkeer wordt toegestaan als het vorige pakket langer geleden is ontvangen, maar uitdrukkelijk niet dat een vermelding automatisch in de Allow List wordt opgenomen na alleen 30 seconden zonder verkeer. De afzonderlijke DoS-statushelp beschrijft daarentegen de hierboven toegelichte doorlopende beperking van tien seconden. Dit zijn geen betrouwbare universele vrijgave- of wachttijden voor elk floodtype. Concludeer niet uitsluitend op basis van een timer dat verkeer wordt toegestaan: beoordeel het aanvalstype, de livestatus, de logs en een duidelijk afgebakende legitieme testflow in samenhang; stem onverklaard gedrag af met Sophos Support.

DDoS-signatures alleen op ondersteunde modellen gebruiken

Sophos biedt DDoS-signatures alleen op XGS 5500 en krachtigere firewalls. Op een ondersteund model verloopt de procedure als volgt:

1. Maak onder Intrusion prevention > IPS policies > Add een eigen IPS Policy met een vrij gekozen unieke naam en sla deze op met Save.
2. Selecteer bij deze opgeslagen Policy Edit, vervolgens Add en voer een unieke regelnaam in.
3. Selecteer Select all, voer in Smart filter ddos in en druk op Enter om het filter toe te passen. Stel de actie Action bewust in op Drop packet.
4. Sla eerst de regel op met Save en daarna het overkoepelende beleid met de tweede Save.
5. Wijs onder Rules and policies > Firewall rules de Policy toe aan de firewallregel die het beoogde verkeer daadwerkelijk verwerkt; controleer de toewijzing en de beschermende werking afzonderlijk, zoals in de IPS-pilotprocedure. Zonder die toewijzing heeft de Policy geen effect.

Deze signatures vullen de lokale DoS-drempels aan, maar vervangen geen DDoS-bescherming bij de provider. Als de internetverbinding al verzadigd is, kan de firewall het knelpunt vóór de WAN-aansluiting niet oplossen. Controleer daarom model, licentie, regelmatch en een gecontroleerde test afzonderlijk.

CLI-regels met system dos-config

Via de Device Console kunnen eigen DoS-policies en bijbehorende regels worden aangemaakt. Dit is onder andere nodig voor IP Flood, omdat dit type niet in WebAdmin kan worden geconfigureerd. De eenheden verschillen: WebAdmin gebruikt pakketten per minuut, terwijl system dos-config pakketten per seconde (pps) gebruikt.

Kies na de SSH-aanmelding in het hoofdmenu 4. Device Console. Voer de opdrachten in bij de prompt console>, niet in de Advanced Shell.

Eerst wordt de policy met aanvalstype, drempelwaarde en telmethode aangemaakt. Daarna bepaalt de regel voor welk verkeer deze geldt. Het gedocumenteerde SYN-voorbeeld voorziet in policy TestSYN en regel TestRuleSYN voor Source 198.51.100.50 met 1000 pps per Source.

Controleer vóór het aanmaken de help van de doelversie: de gepubliceerde SFOS 22- en SFOS 23-help gebruikt voor add dos-rule het token rule_name in de syntax- en optieblokken, maar rule-name in de voorbeelden. Het is niet bevestigd dat deze schrijfwijzen uitwisselbaar zijn. Open eerst de help voor system dos-config in de Device Console van de geïnstalleerde versie en controleer het geaccepteerde add-token en de parameters. Blijft dit onduidelijk, maak dan geen regel aan en vraag Sophos Support om opheldering. De volledige opdracht voor het toevoegen van de regel wordt hier bewust niet als kopieervoorbeeld getoond. Maak ook de onderstaande policy pas na deze controle aan; die alleen koppelt het voorbeeldverkeer nog niet. Dit voorbeeld wordt niet als succesvol getest gepresenteerd.

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

1000 pps is een syntaxvoorbeeld en geen aanbeveling voor een productienetwerk. Voor een eigen regel moeten ten minste de volgende onderdelen bewust worden aangepast:

• SYN-Flood: als alternatief UDP-Flood, ICMP-Flood of het alleen hier beschikbare IP-Flood
• per-src: drempelwaarde per Source; als alternatief per-dst per Destination of global voor al het overeenkomende verkeer
• de werkelijk vereiste voorwaarden voor Source, Destination, Zone, Interface en protocol
• de drempelwaarde op basis van een gemeten baseline en de capaciteit van de beschermde service

De telmethode global geldt niet voor de tellers onder Intrusion prevention > DoS attacks. Deze UI-tellers bewijzen dus geen globaal geaggregeerde CLI-limiet. Controleer de configuratie met show en beoordeel de beschermende werking afzonderlijk met een duidelijk afgebakende testflow, een vast testtijdvak en de bijbehorende logs.

De CLI-limieten en matchvelden zijn nauwkeuriger gedefinieerd dan de korte voorbeeldregel doet vermoeden:

system dos-config flush dos-rules verwijdert alle CLI-DoS-regels en is geen rollback voor één test. Leg vóór zo’n globale actie de bestaande regels afzonderlijk vast met show en maak een configuratieback-up. Voor een normale rollback wordt de genoemde regel gericht verwijderd. De gepubliceerde help beschrijft flush voor regels, niet als verwijdering van de bijbehorende policies.

Na het aanmaken moet eerst worden gecontroleerd of namen, type, drempelwaarde en regelvoorwaarde kloppen:

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

Voor het terugdraaien eerst de regel en daarna de niet meer gebruikte policy verwijderen:

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

De CLI-syntax is gedocumenteerd in de Sophos Firewall Command Line Help. Ze moet desondanks eerst met een gecontroleerde teststroom worden toegepast. CLI-DoS-regels ondersteunen alleen IPv4. Bij een actieve IP-Flood-policy blijft de kolom Applied onder Intrusion prevention > DoS attacks No tonen; Sophos beschrijft dit als verwacht gedrag.

Deze IPv4-beperking geldt voor de CLI-DoS-regels, niet voor de ingebouwde DoS settings onder Intrusion prevention > DoS & spoof protection in WebAdmin: de DoS-instellingen daar beschermen zowel IPv4- als IPv6-verkeer wanneer de passende protocolflags en grenswaarden zijn geconfigureerd.

Voor SFOS 22 is gedocumenteerd dat CLI-regels en -policies vóór de DoS- en spoof-instellingen van WebAdmin worden geëvalueerd; bij die volgorde heft een WebAdmin-bypassregel een overeenkomende CLI-policy niet automatisch op. De onderzochte SFOS 23-CLI-help legt deze volgorde tussen de lagen niet vast. Dat bewijst geen gewijzigd gedrag: bevestig de wisselwerking voor de geïnstalleerde versie voordat u daarop vertrouwt. Binnen WebAdmin documenteren beide versies nog steeds eerst de DoS bypass rules en daarna de DoS Settings voor het resterende verkeer.

DoS bypass rules alleen nauwkeurig gebruiken

DoS bypass rules zijn nuttig wanneer een bekende datastroom anders steeds ten onrechte door de DoS Settings van WebAdmin wordt geblokkeerd. Typische voorbeelden zijn monitoring, Health Checks of een nauwkeurig afgebakende service tussen bekende IP-adressen. De uitzondering moet dan zo precies mogelijk zijn: specifieke bron, specifieke bestemming, passend protocol en smal poortbereik.

Brede bypassregels met grote netwerken, any-logica of algemene poortbereiken zijn gevaarlijk. Zulke uitzonderingen maken de DoS-controle blind precies waar die later nodig is. Als een brede uitzondering nodig lijkt, moet eerst worden gecontroleerd of de drempelwaarden, de architectuur of de testcase verkeerd zijn beoordeeld.

Voor de WebAdmin-instellingen is de volgorde belangrijk: Sophos Firewall controleert eerst of een DoS bypass rule matcht en past de DoS Settings daar pas op het resterende verkeer toe. Een te brede bypassregel kan deze bescherming daardoor ineffectief maken. Stel voor bypassregels Source, Destination, protocol, Source Port en Destination Port bewust in en gebruik niet uit gemak *.

Een uitzondering wordt onder Intrusion prevention > DoS & spoof protection in het gedeelte DoS bypass rule aangemaakt met Add. SFOS 22 en SFOS 23 vereisen IP version, Source- en Destination-IP, Protocol, Source Port en Destination Port; * staat voor een willekeurig adres of een willekeurige poort. Voor een HTTPS-healthcheck van 198.51.100.20 naar 203.0.113.10 zou een passende configuratie zijn: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * en Destination Port 443. Beide documentatieadressen moeten worden vervangen door de werkelijke eindpunten. De Source Port blijft alleen variabel omdat clients doorgaans een dynamische bronpoort gebruiken. Test na Save precies deze flow en een andere flow; alleen de gedefinieerde healthcheck mag de WebAdmin-DoS-bescherming omzeilen.

Wijziging en failover in HA controleren

In een HA-cluster synchroniseert de Primary de firewallconfiguratie, inclusief regels, policies, settings en CLI-opdrachten, naar de Auxiliary. Voer DoS- en spoofwijzigingen op de huidige Primary uit. Controleer daarna de HA-status onder System services > High availability en controleer WebAdmin-items en CLI-regels opnieuw. Neem bij Active-active beide verwerkingspaden mee in de belastingtest. Neem bij Active-passive een gecontroleerde failover op in het onderhoudsvenster als de beheerprocedure dit toestaat. Maak geen tweede, afwijkende configuratie op de Auxiliary.

Opmerking voor SFOS 22.0 MR2

De Release Notes voor SFOS 22.0 MR2 Build 546 vermelden dat NC-180226 is opgelost: WebAdmin gaf eerder geen fout bij het toevoegen van een dubbel MAC-adres onder Spoof protection trusted MAC. Op oudere 22.0-builds bewijst het ontbreken van een foutmelding dus niet dat een item uniek is. Controleer de lijst en werkelijke binding of werk bij naar een gecorrigeerde build.

XML-automatisering: identiteit en bovenliggende velden behouden

Controleer vóór automatisering de opgeslagen configuratie en de objectspecifieke API help van de geïnstalleerde build. De onderstaande koppelingen verklaren de SFOS 22/SFOS 23-referentie; het zijn geen geteste requestsjablonen. De XML API veilig gebruiken behandelt expliciete schrijfoperaties, toegangsbeveiliging en afzonderlijke controles van transport, XML-antwoord en opgeslagen object.

Bypassregel: oude en nieuwe match, geen naam

DoSBypassRules heeft geen gedocumenteerde Name-identiteit. De match bestaat uit IPFamily (IPv4 of IPv6), SourceIPNetmask, DestinationIPNetmask en Protocol (TCP, UDP, ICMP of AllProtocol), voor TCP/UDP aangevuld met SourcePort en DestinationPort. Poorten zijn afzonderlijke waarden van 1 tot 65535 of *; deze referentie bevestigt geen payload voor een poortbereik. Voor toevoegen/bewerken noemt de tabel * voor beide adressen en TCP voor het protocol als defaults. Neem deze brede defaults niet over als gewenste uitzondering, maar leg de volledige match bewust vast.

Bij een update bevat DoSBypassRules/OldConfiguration de eerdere combinatie van dezelfde velden; de directe kinderen van DoSBypassRules bevatten de gewenste nieuwe match. OldConfiguration hoort bij de update-identiteit, niet bij aanmaken of verwijderen. De delete-referentie noemt de matchvelden, geen naam. Identificeer daarom vóór verwijderen de werkelijk opgeslagen combinatie. Het Add/Edit-voorbeeld markeert poorten uitdrukkelijk als uitsluitend voor TCP/UDP, terwijl de parameterlijsten, ook bij Delete, beide poorten zonder voorbehoud verplicht noemen. Daaruit volgt geen betrouwbaar uitvoerbare delete-payload voor ICMP/AllProtocol: verduidelijk objectspecifieke help en build, en verstuur geen verzonnen poortwaarden.

Trusted MAC: MAC-sleutel en afzonderlijke adresfamilies

Bij TrustedMAC is MACAddress de identiteit; bij een update bewaart TrustedMAC/OldConfiguration/MACAddress de oude sleutel, terwijl TrustedMAC/MACAddress het gewenste MAC-adres bevat. Delete noemt alleen MACAddress, niet Name of OldConfiguration. Leg vóór Update of Delete het concrete item en zijn bindings vast en controleer daarna de lijst opnieuw.

TrustedMAC/IPV4Association en TrustedMAC/IPV6Association zijn onafhankelijke koppelingen met Static, DHCP of None; de API-tabel noemt voor beide Static als default. De bijbehorende CSV-adresvelden heten exact IPV4Address en IPV6Address. Bestandsimport gebruikt ook DHCPv6: neem die waarde niet zonder controle over in IPV6Association. Voor AssociateIP spreken voorbeeldwaarde en beschrijving elkaar tegen; hieruit wordt geen toegestane schrijfwaarde afgeleid. De eerdere kwalificatie van de werkelijke IP-MAC-filterwerking blijft ook nodig voor API-beheerde items.

Bestandsimport is een aparte operatie Upload_TrustedMAC met Upload_TrustedMAC/TrustedMACListFile voor .csv of .txt. Het voorbeeld noemt de naam van het via multipart verstuurde bestand, maar bevestigt noch een concrete multipart-partnaam, noch de koppeling daarvan aan dit XML-veld. Leid er geen gebruiksklaar uploadrequest uit af; verduidelijk eerst het buildspecifieke uploadcontract en controleer daarna de geïmporteerde bindings.

Spoof Prevention en DoS Settings niet plat maken

De dubbele naam is in het voorbeeld bewust gebruikt: SpoofPrevention is de root en SpoofPrevention/SpoofPrevention de schakelaar. SpoofPrevention/RestrictUnknownIPOnTrustedMAC is een aparte schakelaar. De drie controlemethoden hebben afzonderlijke zonelijsten: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone en SpoofPrevention/IPMACFilter/EnableOnZone/Zone. Het voorbeeld toont Enable/Disable, de parametertabel daarentegen on/off, en de disable-notitie is dubbelzinnig. Noch deze vermeldingen, noch weggelaten of lege zonelijsten bevestigen een syntax voor wissen of uitschakelen. Verduidelijk waarden en rollback op de geïnstalleerde build voordat u schrijft.

Onder DoSSettings hebben SYNFlood, UDPFlood, TCPFlood en ICMPFlood elk hun eigen bovenliggende Source en Destination. Onder Source staan PacketRatePerSource, BurstRatePerSource en ApplyFlag; onder Destination staan PacketRatePerDestination, BurstRatePerDestination en ApplyFlag. Zo hoort DoSSettings/UDPFlood/Destination/ApplyFlag alleen bij de UDP-bestemmingslimiet. De tabel staat packet rates van 1–600000 en burst rates van 1–10000 toe; de tabeldefault 1 en de voorbeeldgetallen zijn geen productiebaseline. De extra flags staan onder DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag en DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Voeg herhaalde tabellabels niet samen tot één globale PacketRate, BurstRate of ApplyFlag; behoud opgeslagen waarden met hun bovenliggende pad.

Antwoordcodes lezen met operatie en opgeslagen toestand

De referentie noemt deze operatiespecifieke codes, geen universele HTTP-resultaten:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. Verwissel vooral add-409 en edit-404 niet.
• Configure Spoof Prevention en Configuration DOS Settings: elk 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule en Delete Trusted MAC: op deze pagina’s alleen 200, 500.
• Add Trusted MAC en Update Trusted MAC: elk 200 met Operation Successful. en 500 met Operation Fail..

Voor de overige genoemde operaties blijven de meldingen in de volledige bronnen JavaScript-symbolen, geen opgeloste antwoordteksten:

Vergelijk na elke wijziging het antwoord met de werkelijk opgeslagen zones, rates, bindings of bypasscombinatie. Lees bij een fout of onduidelijk antwoord de actuele toestand opnieuw vóór een retry; maak een item niet blind opnieuw aan en leid filterwerking niet alleen uit 200 af. Controleer daarna een passende en een niet-passende testflow afzonderlijk zoals hierboven beschreven.

Wat deze instellingen niet oplossen

Spoof Protection en DoS Settings zijn belangrijke bouwstenen, maar ze lossen niet elk beveiligingsprobleem op.

• Server wordt via toegestane HTTP-verzoeken aangevallen: WAF-regel en Webserver Protection controleren.
• Bekend kwaadaardig bron-IP-adres valt aan: Threat Feeds of blokkering op land/IP controleren.
• Exploitpoging tegen een dienst: IPS-policy passend bij de regel activeren.
• Internetverbinding is verzadigd door DDoS: Provider, scrubbing of upstream DDoS-bescherming inschakelen.
• Firewallregel staat te veel toe: Regelset, NAT en objectmodel opschonen.
• Het verwerpen van pakketten is niet te verklaren: Logging, Packet Capture, Syslog of Central Reporting verbeteren.

Het artikel Publiceer server met DNAT op Sophos Firewall is ook relevant voor publiek toegankelijke servers. Het gaat over NAT, firewallregels en typische publicatiefouten.

Logboeken en vervolgcontrole

Na activatie moet u niet alleen controleren of de normale internettoegang nog werkt. Belangrijk is of de firewall verwachte en onverwachte gebeurtenissen duidelijk weergeeft.

Controleer:

1. Log Viewer filteren op firewallgebeurtenissen en relevante beveiligingsgebeurtenissen.
2. Testverkeer genereren met een duidelijk Source-IP, Destination-IP en Service.
3. Packet Capture gebruiken bij onduidelijkheid over verworpen pakketten.
4. Voor langere opslag kunt u syslog naar SIEM of logserver plannen.
5. Controleer bij het uitvoeren van Sophos Fusion (voorheen Sophos Central) of Central Firewall Reporting de gewenste gebeurtenissen zichtbaar maakt.

Als een pakket wordt verwijderd maar de reden niet duidelijk is, kan de systematische uitvalanalyse in Sophos Firewall pakketten laten vallen: controleer de oorzaken helpen. Het beschrijft ook waarom Log Viewer en Packet Capture verschillende vragen beantwoorden.

SFOS logt verkeer dat door deze beschermingsfuncties wordt geweigerd. Noteer voor een DoS-test eerst tijdstip, Source, Destination, Protocol en tellers. Tijdens de test toont Intrusion prevention > DoS attacks Source of Destination en geweigerde gegevens in realtime. Omdat de status 30 seconden na het einde van de aanval verdwijnt en Traffic dropped sinds de laatste herstart oploopt, is alleen een begrensde voor/na-vergelijking zinvol. De CLI-telmethode global geldt niet voor deze UI-tellers; ook zo’n vergelijking valideert dus geen globale aggregatie. Houd bij een globale CLI-policy de configuratiecontrole met show gescheiden van de controle van de gedefinieerde testflow en de bijbehorende drops/logs. Packet Capture toont daarnaast ingress-interface en pakketadressen, maar bewijst op zichzelf niet welk mechanisme de flow heeft geweigerd.

Foutanalyse na activering

Na een wijziging mogen symptomen niet te snel als aanval worden geïnterpreteerd. De snelste analyse is meestal een vergelijking van verwachting, observatie en volgende test.

• Een enkel netwerk verliest toegang: het bronnetwerk komt mogelijk op een andere interface binnen dan verwacht. Route, VLAN, SD-WAN Route en Packet Capture vergelijken.
• Veel clients achter upstream NAT vallen op: als vóór de Sophos Firewall al NAT op het verkeer is toegepast, ziet de firewall meerdere clients als één gedeelde Source. Drempelwaarde, NAT-pad en legitieme piekbelasting controleren.
• VoIP, monitoring of scanner veroorzaakt drops: regelmatige pakketsnelheden kunnen op flooding lijken. Korte testperiode, Log Viewer en indien nodig een precieze bypass-regel controleren.
• Apparaten werken niet meer na DHCP-wijziging: IP-MAC-binding of Trusted MAC-logica past mogelijk niet meer. Lease, MAC-adres en binding controleren.
• Alleen retourverkeer ontbreekt: een asymmetrisch pad of verkeerde gateway is waarschijnlijk. Heen- en terugweg afzonderlijk met Packet Capture controleren.
• ARP- of ICMP-wijziging veroorzaakt neveneffecten: ARP hardening, source-routed packets of ICMP redirect kunnen ongebruikelijke netwerkontwerpen raken. Downstream routers, Layer 2-segmenten en routingpad controleren.

Veilig terugdraaien

Als legitiem verkeer wordt geraakt en de oorzaak binnen het onderhoudsvenster niet vaststaat, improviseer dan geen brede uitzondering. Herstel de eerder vastgelegde Packet Rate, Burst Rate, Apply-flags, spoof-inspectietype, zones en Restrict unknown IP on trusted MAC; verwijder alleen nieuw gemaakte bypass- of Trusted MAC-items. Gebruik Apply of Save en herhaal dezelfde testflow. Verwijder voor een CLI-policy eerst alleen de benoemde regel en daarna de ongebruikte, speciaal daarvoor gemaakte policy. flush dos-rules hoort niet bij deze rollback.

Typische fouten

• Spoof Protection activeren zonder inzicht in de routing: Legitiem verkeer kan worden geblokkeerd. Zones, interfaces, routes en retourpaden vooraf controleren.
• DoS-drempels zonder controle overnemen: VoIP, monitoring, scans of gepubliceerde diensten kunnen worden verstoord. Een baseline en testfase inplannen.
• Packet Rate en Burst Rate verwarren: De aanhoudende pakketsnelheid en een kortstondige piek zijn verschillende instelparameters. Beide moeten bij de dienst passen.
• Elke afwijking met een brede uitzondering oplossen: Beveiligingsverharding wordt ineffectief en onoverzichtelijk. De oorzaak afbakenen, uitzonderingen beperkt houden en nauwkeurig documenteren.
• DoS bypass rule te ruim instellen: In WebAdmin wordt de bypass vóór de daar aanwezige DoS Settings gecontroleerd en kan deze die controle volledig omzeilen. Source, Destination, protocol en poorten strikt beperken; afzonderlijke CLI-policies aanvullend controleren.
• IP-MAC-Pair-filter leeg laten: Zonder bijgehouden vermeldingen ontstaat geen effectieve binding. Na activering altijd met een bekende testclient controleren.
• DoS Settings als DDoS-bescherming verkopen: Bij bandbreedteaanvallen ontstaat een onjuiste verwachting. Provider- en upstreambescherming afzonderlijk plannen.
• Geen logs controleren: Onterechte blokkeringen of aanvallen blijven onzichtbaar. Log Viewer, Central Reporting of Syslog als vast onderdeel van het beheer vastleggen.
• Verworpen pakketten door spoofingdetectie uitsluitend als aanval interpreteren: Routing- of VLAN-fouten worden over het hoofd gezien. Source-IP, Interface, Route en Packet Capture vergelijken.

Operationele checklist

Vóór activering:

• Zones, interfaces en routing begrepen.
• Kritieke diensten en testgevallen gedefinieerd.
• Packet Rate, Burst Rate en ingeschakelde flags inhoudelijk beoordeeld.
• Back-up of wijzigingsdocumentatie aanwezig.
• Logging en analyse voorbereid.
• Pilotomgeving of onderhoudsvenster vastgesteld.

Na activering:

• Internet, VPN, WAF, DNAT, VoIP en monitoring getest.
• Log Viewer gecontroleerd op onverwacht verworpen pakketten.
• Packet Capture gebruikt voor ten minste één duidelijk testgeval als pakketten worden verworpen.
• Uitzonderingen alleen nauw afgebakend en met onderbouwing ingesteld.
• DoS bypass rules gecontroleerd op Source, Destination, protocol en poorten.
• Resultaat vastgelegd in de beheerdocumentatie.

Regelmatig:

• DoS- en spoofinggebeurtenissen controleren.
• Controleren of uitzonderingen nog nodig zijn.
• Na netwerkaanpassingen, VPN-wijzigingen of nieuwe VLANs opnieuw testen.
• Logs correleren met IPS-, Threat-Feed-, WAF- en firewallregelgebeurtenissen.

FAQ