Sophos Firewall Spoof Protection och DoS Settings kontrollera

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.

Beroende på SFOS-versionen ligger den typiska menysökvägen inom intervallet:

Intrusion prevention > DoS & spoof protection

Om gränssnittet är märkt något annorlunda i en nyare version bör du leta efter DoS, spoof-skydd eller intrångsskydd. Det som är viktigt är inte den exakta klickvägen, utan snarare att funktionen planeras, testas och senare loggas medvetet.

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. Check static routes, SD-WAN routes, VPN routes and asymmetric paths.
3. Identifiera publicerade tjänster via DNAT eller WAF.
4. Notera viktiga tjänster som VoIP, övervakning, säkerhetskopiering, skanningar, VPN och platsanslutningar.
5. Prepare logging and central evaluation if events need to be traceable later.
6. Ställ in underhållsfönster eller pilotområde för första aktivering.

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.

Spoof Protection aktivera 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. Börja med en tydlig zon eller gränssnitt, till exempel WAN eller en rent separerad klientzon.
3. Spara aktivering.
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.

DoS Settings plan

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?
• Vilka händelser ska bara loggas och vilka ska egentligen blockeras?
• 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.

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

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.

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. För Sophos Central-drift, 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.

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.

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