Kontrollera Spoof Protection och DoS Settings i Sophos Firewall

Spoof Protection och DoS Settings är bland de klassiska härdningsfunktionerna hos en Sophos Firewall. Funktionerna reducerar enkla, bullriga eller uppenbart felaktiga paket innan de blir onödigt brus i loggar, regler eller publicerade tjänster. Samtidigt är dessa inställningar inte ett magiskt skydd mot alla slags attacker.

Artikeln klassificerar funktionerna som noggrann grundhärdning: först förstå nätverksdesignen och returvägarna, aktivera, testa och kontrollera sedan loggarna. Skillnaden är särskilt viktig: Dessa funktioner kompletterar rena brandväggsregler, IPS, Threat Feeds, WAF och loggning. De är inte en ersättning för dessa byggstenar.

Kort förklarat

Spoof Protection kontrollerar om paket med en rimlig källadress kommer till det förväntade gränssnittet. Till exempel, om ett paket med en intern källadress dyker upp från Internet, är detta misstänkt i de flesta konstruktioner. DoS Settings, å andra sidan, reagerar på vissa översvämnings- eller anslutningsattackmönster, till exempel märkbara mängder SYN-, UDP eller ICMP-trafik.

I SFOS 22 är sökvägen i WebAdmin:

Intrusion prevention > DoS & spoof protection

Inställningarna på den här sidan påverkar paketbehandlingen. Dokumentera därför befintliga värden och ange en återställningsväg innan du väljer Apply eller Save.

Vad funktionerna gör

• Spoof Protection: Kassera paket med osannolik käll-IP, minska enkla försök till spoofing, gör felaktigt dirigerade paket synliga. ersätter inte ren zon, gränssnitt och ruttplanering.
• DoS Settings: Begränsa enkla översvämningsmönster och upptäck högljudda attacker eller felkonfigurationer tidigare. ersätter inte leverantörens DDoS-skydd, WAF och uppströmsdesign av ren storlek.

I praktiken är dessa funktioner särskilt intressanta som grundhärdning. Fördelen är att minska uppenbart nonsens. I verkliga volymetriska DDoS-attacker är Internetanslutningen ofta redan vid kapacitet innan brandväggen kan svara meningsfullt. Då behöver du skydd från leverantören, uppströmsskrubbning eller annan arkitektur.

Blanda inte skyddstyper

I samma vy finns flera mekanismer som i driften svarar på olika frågor.

• Enable spoof prevention: aktiverar Spoof Prevention för valda zoner. Felaktigt tolkade zoner eller returvägar kan påverka legitim trafik.
• Trusted MAC och IP-MAC-par: kända MAC-adresser eller IP-MAC-kombinationer behandlas som betrodda. Mobila enheter, DHCP-ändringar eller virtualisering kan medföra extra underhåll.
• DoS settings: anger tröskelvärden och flaggor för SYN-, UDP-, TCP- eller ICMP/ICMPv6-flooding. För strikta värden stör legitima belastningstoppar, skanningar, monitoring eller VoIP.
• DoS bypass rule: undantar viss trafik från DoS Settings i WebAdmin. Breda undantag försvagar detta skydd; föregående CLI-policies kringgås inte automatiskt.

Denna åtskillnad är viktig eftersom ett fel efter aktiveringen inte automatiskt är ett problem med en brandväggsregel. Ibland är DoS-tröskeln för aggressiv, ibland stämmer inte längre en IP-MAC-bindning och ibland pekar Spoof Protection på ett verkligt routing- eller VLAN-problem.

När Spoof Protection är vettigt

Spoof Protection passar särskilt bra med tydligt segmenterade nätverk där källnätverk, gränssnitt och rutter är tydligt planerade. Ju tydligare nätverksstrukturen är, desto lättare är det att bedöma om en källadress på ett gränssnitt är rimlig.

Användbara applikationer:

• Internet WAN där inga interna RFC1918-källor ska visas.
• DMZ eller serverzoner med tydliga käll- och destinationsnätverk.
• Klient-, gäst- eller IoT-zoner där inga externa interna nätverk ska visas som källor.
• Platser där routing, VLANs och zoner är tydligt dokumenterade.
• Miljöer där paketsläpp senare måste kunna spåras med Packet Capture och loggar.

Saker och ting blir svårare med asymmetrisk routing, komplexa transitnätverk, tillfälliga migreringsvägar, felaktigt dokumenterade VLANs eller flera brandväggar i samma dataväg. En legitim dataström kan se ut som spoofing, även om routingdesignen eller returvägen faktiskt är oren.

Kontrollera före aktivering

Spoof Protection och DoS Settings ska inte aktiveras blint i en produktionsmiljö. Det bör vara klart i förväg vilka nät och tjänster som berörs.

Viktiga kontrollpunkter:

1. Dokumentzoner, gränssnitt, VLANs, bryggor och LAGs.
2. Kontrollera statiska rutter, SD-WAN-rutter, VPN-rutter och asymmetriska vägar.
3. Identifiera publicerade tjänster via DNAT eller WAF.
4. Notera viktiga tjänster som VoIP, övervakning, säkerhetskopiering, skanningar, VPN och platsanslutningar.
5. Förbered loggning och central analys om händelser behöver kunna spåras i efterhand.
6. Ställ in underhållsfönster eller pilotområde för första aktivering.
7. Kontrollera befintliga DoS bypass rules, Trusted MAC-poster och IP-MAC-bindningar.
8. Dokumentera aktuell spoof-kontrolltyp och valda zoner, Restrict unknown IP on trusted MAC, alla Apply-flaggor, Packet Rate, Burst Rate, undantag och bindningar. Dessa värden behövs för återställning.

Om normala brandväggsregler är svåra att förstå, bör regeln och routingstatus rengöras först. För individuella testanslutningar är Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture en bättre start.

Aktivera Spoof Protection försiktigt

En steg-för-steg-strategi är vettig för Spoof Protection. Du bör säkra de tydligaste områdena först, inte varje specialzon omedelbart.

Praktisk process:

1. Spara den aktuella konfigurationen eller åtminstone dokumentera de berörda inställningarna.
2. Under Intrusion prevention > DoS & spoof protection väljer du Enable spoof prevention, önskad kontrolltyp och till en början endast väldokumenterade zoner.
3. Välj Apply.
4. Kör planerade testanslutningar: Internetåtkomst, VPN, publicerade tjänster, centrala servrar, övervakning.
5. Kontrollera Log Viewer och Packet Capture för oväntade fall.
6. Hantera inte omedelbart iögonfallande legitima droppar med breda undantag, utan kontrollera först routing, käll-IP och gränssnitt.

Ett vanligt misstag är att behandla Spoof Protection som en ren säkerhetskrok. I verkligheten testar funktionen ett antagande om nätverksdesignen. Om detta antagande inte är korrekt, behöver Spoof Protection inte nödvändigtvis vara fel. Ofta byggs inte ett gränssnitt, en rutt, en VLAN eller en returrutt som förväntat.

Förstå IP, MAC och IP-MAC-par korrekt

Sophos skiljer mellan flera kontrolltyper. IP spoofing kasserar trafik när käll-IP inte passar routingtabellen eller ett direkt anslutet subnet. MAC filter arbetar med betrodda MAC-adresser; minst en Trusted MAC Address måste vara underhållen. MAC filter tillämpas inte på DHCP-paket. IP-MAC pair filter kontrollerar om den inkommande kombinationen av IP-adress och MAC-adress matchar ett känt par.

Detta är användbart i statiska, tydligt kontrollerade nät, men kan snabbt skapa underhållsarbete i dynamiska miljöer. DHCP, Wi-Fi-roaming, virtuella maskiner, hypervisors, kluster, NAC, dockningsstationer eller enhetsbyten kan skapa legitima MAC/IP-ändringar. I sådana nät bör man först observera och endast binda där den operativa verkligheten är tillräckligt stabil.

Hur den lokala granntabellen kontrolleras och en statisk bindning mellan IP, MAC och gränssnitt skapas medvetet beskrivs i Kontrollera ARP- och NDP-granncachen.

Förväntningen är viktig: ett aktiverat IP-MAC pair filter utan underhållna Trusted MAC- eller IP-MAC-poster skyddar inte automatiskt. Om inga matchande poster finns blockeras inte trafik, utan tillåts. Skyddet uppstår först genom underhållna och testade bindningar.

Alternativet Restrict unknown IP on trusted MAC är särskilt strikt: paket från en Trusted MAC utan matchande IP-bindning kan kasseras om IP-adressen är okänd ur brandväggens perspektiv. Det är en säkerhetsvinst i kontrollerade nät, men en fallgrop vid DHCP, migreringar och tillfälliga IP-ändringar.

En enskild Trusted MAC-post skapas under Intrusion prevention > DoS & spoof protection i avsnittet Spoof protection trusted MAC med Add. Efter att MAC-adressen har angetts väljs Static och en eller flera kommaseparerade IPv4- eller IPv6-adresser anges, eller DHCP för att automatiskt koppla tilldelade adresser. Efter Save bör ett matchande och ett avsiktligt avvikande IP-MAC-fall testas; en synlig post bekräftar inte i sig att filtret tillämpas.

Importera Trusted MACs kontrollerat

Flera Trusted MACs kan importeras under Intrusion prevention > DoS & spoof protection från en .csv- eller .txt-fil. Den första raden måste innehålla exakt MAC Address,IP Association,IP Address. Tillåtna värden för IP Association är Static, DHCP, DHCPv6 och None. Med Static kan högst 16 kommaseparerade IP-adresser anges per MAC; för de övriga tre kopplingarna lämnas IP-fältet tomt.

Brandväggen kasserar ogiltiga MAC-adresser, kopplingar eller IP-adresser vid importen. Den kasserar även IP-värden som angetts med DHCP, DHCPv6 eller None. Importera därför först några pilotrader, kontrollera sedan de synliga bindningarna och testa ett tillåtet samt ett avsiktligt felaktigt IP-MAC-fall. En lyckad uppladdning bevisar ännu inte att den avsedda filterlogiken fungerar.

Planera DoS Settings

DoS Settings bör passa miljön. Det är sällan meningsfullt att anta värden från ett annat exempel utan att kontrollera. En webbplats med ett fåtal användare, VoIP och en liten WAN beter sig annorlunda än ett datacenter, ett skolnätverk eller en webbplats med regelbundna skanningar och övervakning.

Innan du anpassar bör du svara på dessa frågor:

• Vilka offentliga tjänster är utsatta?
• Finns det legitima belastningstoppar, skanningar, övervakning eller hälsokontroller?
• Används VoIP, VPN, WAF, DNAT eller stora filöverföringar?
• För vilka protokoll ska Apply-flaggan aktiveras, så att brandväggen faktiskt kasserar och loggar trafik som överskrider gränsen?
• Vem kontrollerar loggarna efter aktivering?

DoS Settings kan hjälpa till att begränsa enkla översvämningsmönster. Men trösklar som är för strikta kan också påverka legitim trafik. Särskild försiktighet bör iakttas med VoIP, övervakningssystem, säkerhetskopieringsjobb, sårbarhetssökningar och flitigt använda publicerade tjänster.

På sidan handlar det inte bara om klassiska floods. Det finns också flaggor som Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet och ARP hardening. Dessa alternativ är användbar grundhärdning eftersom de kan minska manipulation av routing- eller ARP-beteende. Testa dem ändå efter aktivering, särskilt i nät med downstream-routrar, äldre segment eller ovanliga Layer 2-designer.

För tröskelvärdena i WebAdmin är två begrepp viktiga:

• Packet rate: antal paket som en host får skicka eller ta emot per minut innan trafik kasseras.
• Burst rate: antal paket som först tillåts utan kontroll av Packet Rate. Därefter kan enstaka korta toppar över Packet Rate tolereras, men inte frekventa eller ihållande överskridanden.

Apply flag avgör om den konfigurerade gränsen faktiskt tillämpas för respektive protokoll. För höga värden gör lite nytta. För låga värden blockerar legitima toppar. Anpassa därför värdena till egen trafik, publicerade tjänster och kända underhållsfönster.

För en tillförlitlig referensnivå ska du först registrera normala toppar och planerad specialbelastning. Välj sedan värdet för varje protokoll utifrån den uppmätta legitima toppen och den skyddade tjänstens kapacitet; Sophos anger inget universellt produktionsvärde. Kör ett definierat belastningstest efter varje ändring och jämför Traffic dropped. Räknaren ackumuleras sedan brandväggens senaste omstart, så notera även testtid och startvärde.

Läs DoS-status korrekt

Under Intrusion prevention > DoS attacks visar SFOS i realtid för vilken Source eller Destination en gräns gäller och hur många paket som har kasserats. Efter detektering gäller begränsningen först i tio sekunder. Om attacken fortsätter nollställer brandväggen räknaren rullande var tionde sekund och fortsätter begränsa trafiken. När attacken upphör försvinner uppgifterna efter 30 sekunder. En tom status bevisar därför inte att ingen DoS-händelse inträffade tidigare; för efterhandsanalys behövs de loggade händelserna.

Använd DDoS-signaturer endast på modeller som stöds

Sophos erbjuder DDoS-signaturer endast på XGS 5500 och brandväggar med högre kapacitet. På en modell som stöds skapas en egen IPS Policy, ddos filtreras med Smart filter, åtgärden sätts medvetet till Drop packet och policyn tilldelas sedan den brandväggsregel som faktiskt behandlar trafiken. Utan denna tilldelning får policyn ingen effekt.

Signaturerna kompletterar de lokala DoS-gränserna, men ersätter inte DDoS-skydd hos operatören. Om internetförbindelsen redan är mättad kan brandväggen inte åtgärda flaskhalsen före WAN-anslutningen. Modell, licens, regelmatchning och ett kontrollerat test måste därför kontrolleras separat.

CLI-regler med system dos-config

Via Device Console kan egna DoS-policies och motsvarande regler skapas. Detta behövs bland annat för IP Flood, eftersom denna typ inte kan konfigureras i WebAdmin. Enheterna skiljer sig åt: WebAdmin använder paket per minut, medan system dos-config använder paket per sekund (pps).

Efter SSH-inloggning väljer man 4. Device Console i huvudmenyn. Kommandona anges vid prompten console>, inte i Advanced Shell.

Först skapas policyn med attacktyp, tröskelvärde och räknemetod. Därefter fastställer regeln vilken trafik den gäller. Detta exempel, som dokumenterats av Sophos, begränsar SYN-trafik från exempeladressen 198.51.100.50 till 1000 pps per Source:

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src
system dos-config add dos-rule rule-name TestRuleSYN srcip 198.51.100.50 dos-policy TestSYN

1000 pps är ett syntaxexempel och ingen rekommendation för ett produktionsnät. För en egen regel måste åtminstone följande delar anpassas medvetet:

• SYN-Flood: alternativt UDP-Flood, ICMP-Flood eller IP-Flood, som bara är tillgänglig här
• per-src: tröskelvärde per Source; alternativt per-dst per Destination eller global för all matchande trafik
• de villkor som faktiskt behövs för Source, Destination, Zone, Interface och protokoll
• tröskelvärdet baserat på en uppmätt baseline och den skyddade tjänstens kapacitet

CLI-gränserna och matchningsfälten är mer exakt definierade än den korta exempelregeln antyder:

system dos-config flush dos-rules tar bort alla CLI-DoS-regler och är inte en återställning för ett enskilt test. Före en sådan global åtgärd dokumenteras befintliga regler var för sig med show och konfigurationen säkras. Vid en normal återställning tas den namngivna regeln bort specifikt. Den publicerade hjälpen beskriver flush för regler, inte som borttagning av tillhörande policies.

Efter att de har skapats bör man först kontrollera att namn, typ, tröskelvärde och regelvillkor stämmer:

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

För återställning ska först regeln och därefter den policy som inte längre används tas bort:

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

CLI-syntaxen dokumenteras i Sophos Firewall Command Line Help. Den bör ändå först användas med ett kontrollerat testflöde. CLI-DoS-regler stöder endast IPv4. Med en aktiv IP-Flood-policy visar kolumnen Applied under Intrusion prevention > DoS attacks fortfarande No; Sophos beskriver detta som förväntat beteende.

CLI-regler och -policies utvärderas före DoS- och spoof-inställningarna i WebAdmin. Inom WebAdmin-inställningarna kontrollerar brandväggen först DoS bypass rules och därefter återstående DoS Settings. En bypassregel i WebAdmin åsidosätter därför inte automatiskt en matchande CLI-policy.

Använd DoS bypass rules endast snävt

DoS bypass rules är användbara när ett välkänt dataflöde annars konsekvent felaktigt blockeras av DoS Settings i WebAdmin. Typiska exempel är monitoring, Health Checks eller en snävt definierad tjänst mellan kända IP-adresser. Undantaget bör då vara så exakt som möjligt: specifik källa, specifik destination, passande protokoll och smalt portintervall.

Breda bypassregler med stora nät, any-logik eller generella portintervall är farliga. Sådana undantag gör DoS-kontrollen blind just där den senare kan behövas. Om ett brett undantag verkar nödvändigt bör man först kontrollera om tröskelvärdena, arkitekturen eller testfallet har bedömts felaktigt.

För WebAdmin-inställningarna är ordningen viktig: Sophos Firewall kontrollerar först om en DoS bypass rule matchar och tillämpar sedan DoS Settings där på den återstående trafiken. En för bred bypassregel kan därför göra detta skydd verkningslöst. För bypassregler bör Source, Destination, protokoll, Source Port och Destination Port anges medvetet i stället för att använda * av bekvämlighet.

Skapa undantaget under Intrusion prevention > DoS & spoof protection, i DoS bypass rule, med Add. SFOS 22 kräver IP version, Source- och Destination-IP, Protocol, Source Port och Destination Port; * betyder valfri adress eller port. För en HTTPS Health Check från 198.51.100.20 till 203.0.113.10 använder du Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * och Destination Port 443. Ersätt båda dokumentationsadresserna med de verkliga ändpunkterna. Source Port är variabel endast eftersom klienter normalt använder en dynamisk källport. Testa efter Save både detta och ett annat flöde; endast den definierade Health Check-trafiken ska kringgå WebAdmin DoS-skydd.

Kontrollera ändringen och failover i HA

I ett HA-kluster synkroniserar Primary brandväggskonfigurationen, inklusive regler, policies, settings och CLI-kommandon, till Auxiliary. Gör DoS- och spoofändringar på aktuell Primary. Kontrollera sedan HA-status under System services > High availability och verifiera WebAdmin-poster och CLI-regler igen. I Active-active ska belastningstestet omfatta båda bearbetningsvägarna. I Active-passive bör ett kontrollerat failover-test ingå i underhållsfönstret om driftprocessen tillåter det. Skapa inte en avvikande konfiguration på Auxiliary.

Anmärkning för SFOS 22.0 MR2

Release Notes för SFOS 22.0 MR2 Build 546 anger att NC-180226 har åtgärdats: WebAdmin visade tidigare inget fel när en dubblett av en MAC-adress lades till under Spoof protection trusted MAC. På äldre 22.0-builds bevisar avsaknaden av felmeddelande därför inte att posten är unik. Kontrollera listan och den faktiska bindningen eller uppdatera till en korrigerad build.

Vad dessa inställningar inte löser

Spoof Protection och DoS Settings är viktiga byggstenar, men de löser inte alla säkerhetsproblem.

• Server attackeras via tillåtna HTTP-förfrågningar: Kontrollera WAF regel och webbserverskydd.
• Kända skadliga IP-attacker: Threat Feeds eller kontrollera land/IP-blockering.
• Försök till utnyttjande mot en tjänst: Aktivera IPS-Policy för att matcha regeln.
• Internetlinjen är full på grund av DDoS: Inkludera leverantörer, skrubbning eller uppströms DDoS-skydd.
• Brandväggsregeln tillåter för mycket: Rensa upp regler, NAT och objektmodell.
• Droppar är obegripliga: Förbättra loggning, Packet Capture, syslog eller central rapportering.

För allmänt tillgängliga servrar är artikeln Publicera server med DNAT på Sophos Firewall också relevant. Det handlar om NAT, brandväggsregler och typiska publiceringsfel.

Loggar och uppföljning

Efter aktivering bör du inte bara kontrollera om normal internetåtkomst fortfarande fungerar. Det viktiga är om brandväggen tydligt visar förväntade och oväntade händelser.

Kontrollera:

1. Filtrera Log Viewer för brandvägg och relevanta säkerhetshändelser.
2. Utlösa testtrafik med tydlig käll-IP, destinations-IP och tjänst.
3. Använd Packet Capture för oklara droppar.
4. För längre lagring, planera för syslog till SIEM eller loggserver.
5. Vid drift med Sophos Fusion (tidigare Sophos Central), kontrollera om Central Firewall Reporting gör de önskade händelserna synliga.

Om ett paket tappas men orsaken inte är klar, hjälper den systematiska droppanalysen i Sophos Firewall tappar paket: kontrollera orsaker. Den beskriver också varför Log Viewer och Packet Capture svarar på olika frågor.

SFOS loggar trafik som dessa skyddsfunktioner kasserar. Notera före ett DoS-test tid, Source, Destination, Protocol och räknare. Under testet visar Intrusion prevention > DoS attacks Source eller Destination och kasserade data i realtid. Eftersom statusen försvinner 30 sekunder efter att attacken upphör och Traffic dropped ackumuleras sedan senaste omstart är endast en tidsavgränsad före/efter-jämförelse meningsfull. Packet Capture visar dessutom inkommande interface och paketadresser, men bevisar inte ensamt vilken mekanism som kasserade flödet.

Felsökning efter aktivering

Efter en ändring bör symptom inte tolkas för snabbt som en attack. Den snabbaste analysen är oftast att jämföra förväntan, observation och nästa test.

• Ett enskilt nät tappar åtkomst: källnätet kan komma in på ett annat interface än väntat. Jämför route, VLAN, SD-WAN Route och Packet Capture.
• Många klienter bakom uppströms NAT sticker ut: om trafiken redan har NAT-översatts före Sophos Firewall ser brandväggen flera klienter som en gemensam Source. Kontrollera tröskel, NAT-väg och legitim belastningstopp.
• VoIP, monitoring eller scanner ger drops: regelbundna pakethastigheter kan se ut som flooding. Kontrollera smalt testfönster, Log Viewer och vid behov en precis bypass-regel.
• Enheter slutar fungera efter DHCP-ändring: IP-MAC-bindning eller Trusted MAC-logik passar kanske inte längre. Kontrollera lease, MAC-adress och bindning.
• Endast returtrafik saknas: asymmetrisk väg eller fel gateway är sannolikt. Kontrollera fram- och returväg separat med Packet Capture.
• ARP- eller ICMP-ändring ger bieffekter: ARP hardening, source-routed packets eller ICMP redirect kan påverka ovanliga nätverksdesigner. Kontrollera downstream-routrar, Layer 2-segment och routingväg.

Återställ säkert

Om legitim trafik påverkas och orsaken inte kan fastställas under underhållsfönstret ska du inte improvisera med ett brett undantag. Återställ tidigare dokumenterade Packet Rate, Burst Rate, Apply-flaggor, spoof-kontrolltyp, zoner och Restrict unknown IP on trusted MAC; ta endast bort nytillkomna bypass- eller Trusted MAC-poster. Använd Apply eller Save och upprepa samma testflöde. För en CLI-policy tar du först bort enbart den namngivna regeln och därefter dess nu oanvända dedikerade policy. flush dos-rules ingår inte i denna återställning.

Typiska misstag

• Spoof Protection aktiveras utan routingförståelse: legitim trafik kan blockeras. Kontrollera zoner, gränssnitt, rutter och returrutter i förväg.
• Anta DoS-trösklar utan att kontrollera: VoIP, övervakning, skanning eller publicerade tjänster kan störas. Planera baslinje och testfas.
• Blanda ihop Packet Rate och Burst Rate: varaktig pakethastighet och kort topp är olika reglage. Båda måste passa tjänsten.
• Lös alla anomalier med breda undantag: Härdning blir ineffektiv och förvirrande. Begränsa orsaken och noggrant dokumentera undantag.
• Sätta DoS bypass rule för brett: i WebAdmin kontrolleras bypass före DoS Settings där och kan helt kringgå denna kontroll. Håll Source, Destination, protokoll och portar snäva och kontrollera dessutom separata CLI-policies.
• Lämna IP-MAC pair filter tomt: utan underhållna poster finns ingen effektiv bindning. Testa alltid med en känd klient efter aktivering.
• Sälj DoS Settings som DDoS-skydd: falska förväntningar på bandbreddsattacker. Planera leverantör och uppströmsskydd separat.
• Kontrollera inte loggar: Felaktiga blockeringar eller attacker förblir osynliga. Definiera Log Viewer, Central Reporting eller Syslog som driftpunkt.
• Tolka spoofing droppar som rena attacker: Routing- eller VLAN-fel förbises. Jämför käll-IP, gränssnitt, rutt och Packet Capture.

Driftschecklista

Före aktivering:

• Förstå zoner, gränssnitt och routing.
• Kritiska tjänster och testfall definieras.
• Packet Rate, Burst Rate och aktiverade flaggor tekniskt bedömda.
• Säkerhetskopiering eller ändringsdokumentation tillgänglig.
• Loggning och utvärdering förberedd.
• Pilotområde eller underhållsfönsterset.

Efter aktivering:

• Internet, VPN, WAF, DNAT, VoIP och övervakning testade.
• Log Viewer kontrolleras för oväntade fall.
• Packet Capture används för minst ett tydligt testfall när fall inträffar.
• Undantag görs endast snävt och med motivering.
• DoS bypass rules kontrollerade för source, destination, protocol och portar.
• Resultatet registreras i driftdokumentationen.

Regelbundet:

• Kontrollera DoS och spoof-händelser.
• Kontrollera undantag för nödvändighet.
• Testa igen efter nätverksändringar, VPN-ändringar eller nya VLANs.
• Korrelera loggar med IPS, hotfeed, WAF och brandväggsregelhändelser.

FAQ