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 och SFOS 23 ä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: kasserar paket med en orimlig Source-IP, minskar enkla spoofingförsök och gör felaktigt routade paket mer synliga. Funktionen ersätter dock inte en genomtänkt planering av zoner, interface och routing.
• DoS Settings: begränsar enkla floodingmönster och gör omfattande attacker eller felkonfigurationer märkbara tidigare. Funktionen ersätter dock inte DDoS-skydd hos leverantören, en WAF eller en korrekt dimensionerad upstreamdesign.

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. Se versionsförbehållet i CLI-avsnittet för samspelet med CLI-policies.

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 andra interna nät inte ska förekomma som Source.
• 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. Dokumentera zoner, interface, VLAN, bryggor och LAG.
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 vanliga brandväggsregler redan är svåra att följa bör man först reda ut regelverket och routingkonfigurationen. 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äntat kasserade paket.
6. Kringgå inte omedelbart oväntad kassering av legitim trafik med breda undantag, utan kontrollera först routing, Source-IP och Interface.

Ett vanligt misstag är att behandla Spoof Protection som en ren säkerhetskryssruta. I själva verket kontrollerar funktionen ett antagande om nätverksdesignen. Om antagandet inte stämmer behöver det inte vara Spoof Protection som är fel. Ofta är då ett interface, en route, ett VLAN eller en returväg inte utformad som förväntat.

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

Sophos skiljer mellan flera kontrolltyper. IP spoofing kasserar trafik om Source-IP inte stämmer överens med routingtabellen eller om paketet inte kommer från ett direktanslutet subnät. MAC filter kasserar paket vars MAC-adress inte är registrerad som Trusted MAC; för detta måste minst en Trusted MAC Address vara registrerad. MAC-filtret 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.

Exempel med en coreswitch: Switchen hanterar inter-VLAN-routing och använder Sophos Firewall som Default Gateway. En klient i VLAN 1 med 10.10.10.5 skickar en internetförfrågan som kommer in på brandväggens LAN-interface. Att switchen känner till VLAN:en innebär inte att deras subnät är direktanslutna till brandväggen. Kontrollera routen för 10.10.10.5 och de direktanslutna subnäten på brandväggen före aktivering. Om de dokumenterade IP-spoofingvillkoren inte är uppfyllda kan förfrågan kasseras trots en legitim klientadress. Ett test av WAN-åtkomst ersätter inte denna kontroll av den interna vägen.

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

Skilj på situationerna: om ingen Trusted MAC är konfigurerad tillåter ett aktiverat IP-MAC pair filter all trafik genom denna kontroll. En tom Trusted MAC-lista är inte samma sak som ett paket som avviker från en konfigurerad IP-MAC-bindning. När poster finns beror filtreringen på bindningarna och Restrict unknown IP on trusted MAC; ett saknat matchande par innebär inte alltid blockering oavsett detta alternativ. Skyddet kräver underhållna och testade bindningar.

Alternativet Restrict unknown IP on trusted MAC är särskilt strikt: När IP-MAC pair filter är aktiverat i de valda zonerna och alternativet är markerat beskriver Sophos att paket från en Trusted MAC utan IP-bindning kasseras om IP-adressen är okänd. «Okänd» betyder här att det inte finns någon matchande post i routingtabellen eller att paketet inte kommer från ett direktanslutet subnät. Detta ger ökad säkerhet i kontrollerade nät, men kan orsaka problem vid DHCP, migreringar och tillfälliga IP-byten.

När alternativet inte är markerat beskriver den allmänna hjälpen för SFOS 22 och SFOS 23 att en Trusted MAC med valfri IP samt en Trusted MAC utan IP-bindning tillåts. Den separata Add-anvisningen anger däremot generellt att endast ett matchande IP-MAC-par accepteras när en bindning finns. Dessa uppgifter får inte kombineras till en ovillkorlig garanti för blockering. Kontrollera kontrolltyp, zon, bindning och kryssruta tillsammans och testa de tillåtna och avvikande fall som behövs i den installerade builden; klargör oklar funktion med Sophos Support före användning i produktion.

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.

För SFOS 23 dokumenteras sök- och filteralternativ i Trusted MAC-listan för att hitta en post som ska underhållas. Listvyn ändrar inte paketfiltreringen och innebär inte heller att SFOS 22 saknar sådana kontroller.

Importera Trusted MACs kontrollerat

Flera Trusted MACs kan importeras som en .csv- eller .txt-fil under Intrusion prevention > DoS & spoof protection. Välj Import i avsnittet Spoof protection trusted MAC, välj filen med Browse och ladda upp den med Upload file. MAC-adress och IP Association måste anges på varje rad. 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 IP-adresser anges per MAC, separerade med kommatecken; för de övriga tre kopplingarna lämnas IP-fältet tomt.

Följande formatexempel visar statiska IPv4- och IPv6-bindningar samt de tre kopplingarna utan IP-fält:

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

MAC- och IP-adresserna är fiktiva platshållare, inte enheter som ska tillåtas. Ersätt varje rad med enhetens faktiska MAC-adress och en medvetet vald koppling. Static passar för kända fasta adresser, DHCP respektive DHCPv6 för automatisk lease-bindning; None innehåller ingen IP-bindning och ersätter därför inte en statisk parkontroll.

Brandväggen kasserar hela posten vid import om den innehåller en ogiltig MAC-adress, en ogiltig IP Association eller en ogiltig IP-adress. Detta ska skiljas från IP-värden som angetts trots DHCP, DHCPv6 eller None: dessa IP-värden kasseras; det innebär inte automatiskt att hela MAC-posten tas bort. Importera därför först ett fåtal pilotrader, kontrollera sedan de synliga bindningarna och testa ett tillåtet samt ett avsiktligt felaktigt IP-MAC-fall. En lyckad uppladdning bevisar inte att den avsedda filterlogiken tillämpas.

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. Ett kontor med få användare, VoIP och en mindre WAN-anslutning beter sig annorlunda än ett datacenter, ett skolnät eller en anläggning 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.

Flood-typerna ger olika typer av belastning: SYN flood skapar många halvöppna TCP-anslutningar; servern svarar med SYN-ACK men får inget avslutande svar. TCP flood avser en hög TCP-pakettakt generellt. UDP flood kan belasta målvärden med portkontroller och ICMP-svar för oanvända portar. ICMP/ICMPv6 flood innebär många Echo Requests och kan förbruka bandbredd. Vid DDoS kommer belastningen från flera enheter; ett enskilt Source-gränsvärde besvarar därför inte samma fråga som ett Destination-gränsvärde.

I formuläret är även dessa flaggor relevanta:

• Dropped source routed packets: kasserar paket vars route anges av avsändaren. På så sätt begränsas denna möjlighet att manipulera routing.
• Disable ICMP/ICMPv6 redirect packet: accepterar inte ICMP- respektive ICMPv6-redirects. Downstreamroutrar kan även skicka sådana meddelanden legitimt för en bättre eller aktiv route; alternativet ändrar därför ett routingantagande och inte bara attackdetekteringen.
• ARP hardening: tillåter endast ARP Replies om Source-IP och Destination-IP ligger i samma subnät. Sophos beskriver detta som skydd mot ARP Flood och ARP Poisoning.

Dessa alternativ är lämpliga för grundläggande härdning eftersom de kan minska manipulation av routing- eller ARP-beteende. De bör ändå testas efter aktivering, särskilt i nät med downstreamroutrar, ä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 ett gränsvärde tillämpas och hur många paket som har kasserats. Klicka på attacktypen för att öppna detaljerna; statuslänken från DoS & spoof protection leder också till denna vy. Efter detektering gäller begränsningen inledningsvis i tio sekunder. Om attacken då har upphört tas begränsningen bort. Om den fortsätter återställer brandväggen denna räknare löpande var tionde sekund och fortsätter att begränsa. En ny attack från samma Source eller mot samma Destination återställer räknaren igen och aktiverar begränsningen på nytt. När attacken upphör försvinner uppgifterna efter 30 sekunder. En tom status bevisar därför inte att ingen DoS-händelse har inträffat tidigare; för efterhandsgranskning behövs de loggade händelserna.

Gränsvärdena i WebAdmin gäller per Source eller Destination, inte som en generell totalsumma för alla värdar. Ett rent förklarande exempel med Burst rate 100: De första 100 paketen tillåts inledningsvis utan kontroll av Packet rate; därefter jämförs takten. Under den konfigurerade takten accepteras trafik, över den kan trafik kasseras. 100 är inget rekommenderat produktionsvärde.

Likställ inte exempelförloppet med statustimern: Den allmänna hjälpen för SFOS 22 och SFOS 23 kallar detta förlopp ett ARP-Flood-försök och beskriver ytterligare kasserade paket och loggposter om nästa paket från samma Source kommer inom 30 sekunder. Den beskriver att trafik tillåts om det föregående paketet ligger längre tillbaka i tiden, men uttryckligen ingen automatisk inkludering i Allow List enbart på grund av 30 sekunder utan trafik. Den separata hjälpen för DoS-status beskriver däremot den löpande tiosekundersbegränsning som förklarats ovan. Detta är inte tillförlitliga universella tider för att tillåta trafik eller vänta för varje Flood-typ. Dra inte slutsatsen att trafik tillåts enbart utifrån en timer: bedöm attacktyp, livestatus, loggar och ett tydligt avgränsat legitimt testflöde tillsammans; klargör oförklarat beteende med Sophos Support.

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 är processen följande:

1. Skapa en egen IPS Policy med ett valfritt unikt namn under Intrusion prevention > IPS policies > Add och spara med Save.
2. Välj Edit för denna sparade policy, välj sedan Add och ange ett unikt regelnamn.
3. Välj Select all, ange ddos i Smart filter och tryck på Enter för att tillämpa filtret. Sätt medvetet åtgärden Action till Drop packet.
4. Spara först regeln med Save och därefter den omslutande policyn med det andra Save.
5. Tilldela policyn under Rules and policies > Firewall rules till den brandväggsregel som faktiskt behandlar den avsedda trafiken; kontrollera tilldelningen och skyddseffekten separat enligt IPS-pilotprocessen. 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. Det dokumenterade SYN-exemplet avser policyn TestSYN och regeln TestRuleSYN för Source 198.51.100.50, med 1000 pps per Source.

Kontrollera målversionens hjälp innan objekt skapas: den publicerade hjälpen för SFOS 22 och SFOS 23 använder rule_name för add dos-rule i syntax- och alternativblocken, men rule-name i exemplen. Det är inte bekräftat att skrivsätten är utbytbara. Öppna först hjälpen för system dos-config i Device Console på den installerade versionen och kontrollera vilken add-token och vilka parametrar som accepteras. Om detta förblir oklart, skapa ingen regel utan be Sophos Support om ett klargörande. Det fullständiga kommandot för att lägga till regeln visas avsiktligt inte som kopieringsmall här. Skapa även policyn nedan först efter denna kontroll; en policy ensam kopplar ännu inte exempeltrafiken. Exemplet presenteras inte som framgångsrikt testat.

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

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

Räknemetoden global gäller inte räknarna under Intrusion prevention > DoS attacks. Dessa UI-räknare bevisar därför inte en globalt aggregerad CLI-gräns. Kontrollera konfigurationen med show och bedöm skyddets tillämpning separat med ett tydligt avgränsat testflöde, en bestämd testperiod och tillhörande loggar.

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.

Denna IPv4-begränsning gäller CLI-DoS-reglerna, inte de inbyggda DoS settings under Intrusion prevention > DoS & spoof protection i WebAdmin: DoS-inställningarna där skyddar både IPv4- och IPv6-trafik när rätt protokollflaggor och tröskelvärden är konfigurerade.

För SFOS 22 dokumenteras att CLI-regler och -policies utvärderas före DoS- och spoof-inställningarna i WebAdmin; med denna ordning åsidosätter en WebAdmin-bypassregel inte automatiskt en matchande CLI-policy. Den granskade SFOS 23-CLI-hjälpen anger inte denna ordning mellan lagren. Det bevisar ingen beteendeförändring: bekräfta samspelet för den installerade versionen innan det används som grund för en åtgärd. Inom WebAdmin dokumenterar båda versionerna fortfarande först DoS bypass rules och därefter DoS Settings för återstående trafik.

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.

Ett undantag skapas under Intrusion prevention > DoS & spoof protection i avsnittet DoS bypass rule med Add. SFOS 22 och SFOS 23 kräver IP version, Source-IP och Destination-IP, Protocol, Source Port och Destination Port; * står för valfri adress eller port. För en HTTPS-hälsokontroll från 198.51.100.20 till 203.0.113.10 skulle en lämplig konfiguration vara: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * och Destination Port 443. Båda dokumentationsadresserna måste ersättas med de verkliga ändpunkterna. Source Port lämnas variabel enbart eftersom klienter vanligtvis använder en dynamisk källport. Efter Save ska just detta flöde och ett annat flöde testas; endast den definierade hälsokontrollen får kringgå WebAdmin-DoS-skyddet.

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.

XML-automatisering: bevara identitet och överordnade fält

Kontrollera den sparade konfigurationen och objektets API help i den installerade builden innan inställningarna automatiseras. Följande kopplingar förklarar SFOS 22/SFOS 23-referensen; de är inte testade requestmallar. Använd XML API säkert förklarar uttryckliga skrivoperationer, åtkomstskydd och separata kontroller av transport, XML-svar och sparat objekt.

Bypassregel: gammal och ny matchning, inte ett namn

DoSBypassRules har ingen dokumenterad Name-identitet. Matchningen består av IPFamily (IPv4 eller IPv6), SourceIPNetmask, DestinationIPNetmask och Protocol (TCP, UDP, ICMP eller AllProtocol), med SourcePort och DestinationPort dessutom för TCP/UDP. Portar är enskilda värden från 1 till 65535 eller *; referensen belägger ingen payload för portintervall här. För tillägg/redigering anger tabellen * för båda adresserna och TCP för protokollet som standardvärden. Använd inte dessa breda standardvärden som avsett undantag, utan ange hela matchningen medvetet.

Vid uppdatering innehåller DoSBypassRules/OldConfiguration den tidigare kombinationen av samma fält; de direkta barnen till DoSBypassRules innehåller den önskade nya matchningen. OldConfiguration hör till uppdateringsidentiteten, inte till skapande eller borttagning. Delete-referensen anger matchningsfälten, inte ett namn. Identifiera därför den faktiskt sparade kombinationen före borttagning. Add/Edit-exemplet markerar uttryckligen portarna som endast för TCP/UDP, medan parameterlistorna, även för Delete, anger båda portarna som obligatoriska utan förbehåll. Detta ger ingen tillförlitligt körbar delete-payload för ICMP/AllProtocol: klargör objektets hjälp och builden utan att skicka påhittade portvärden.

Trusted MAC: MAC-nyckel och separata adressfamiljer

För TrustedMAC är MACAddress identiteten; vid uppdatering håller TrustedMAC/OldConfiguration/MACAddress den gamla nyckeln, medan TrustedMAC/MACAddress innehåller önskad MAC-adress. Delete anger endast MACAddress, inte Name eller OldConfiguration. Spara den konkreta posten och dess bindningar före Update eller Delete och kontrollera sedan listan igen.

TrustedMAC/IPV4Association och TrustedMAC/IPV6Association är oberoende kopplingar med Static, DHCP eller None; API-tabellen anger Static som standard för båda. De tillhörande CSV-adressfälten heter exakt IPV4Address och IPV6Address. Filimport använder även DHCPv6: överför inte det värdet till IPV6Association utan kontroll. För AssociateIP motsäger exempelvärdet och beskrivningen varandra; inget tillåtet skrivvärde härleds här. Det tidigare förbehållet om faktisk IP-MAC-filtrering behövs även för API-hanterade poster.

Filimport är en separat operation Upload_TrustedMAC med Upload_TrustedMAC/TrustedMACListFile för .csv eller .txt. Exemplet anger namnet på filen som överförs via multipart men belägger varken ett specifikt multipart-partnamn eller dess koppling till XML-fältet. Härled därför ingen färdig uploadrequest från exemplet; klargör först buildens uploadkontrakt och kontrollera sedan de importerade bindningarna.

Platta inte ut Spoof Prevention eller DoS Settings

Det dubbla namnet är avsiktligt i exempelstrukturen: SpoofPrevention är roten och SpoofPrevention/SpoofPrevention strömbrytaren. SpoofPrevention/RestrictUnknownIPOnTrustedMAC är en separat strömbrytare. De tre kontrolltyperna har separata zonlistor: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone och SpoofPrevention/IPMACFilter/EnableOnZone/Zone. Exemplet visar Enable/Disable, parametertabellen däremot on/off, och avaktiveringsnoten är tvetydig. Varken dessa uppgifter eller utelämnade eller tomma zonlistor bekräftar syntax för rensning eller avaktivering. Klargör värden och återställning i den installerade builden före skrivning.

Under DoSSettings har SYNFlood, UDPFlood, TCPFlood och ICMPFlood var sina överordnade Source och Destination. Under Source finns PacketRatePerSource, BurstRatePerSource och ApplyFlag; under Destination finns PacketRatePerDestination, BurstRatePerDestination och ApplyFlag. Exempelvis hör DoSSettings/UDPFlood/Destination/ApplyFlag bara till UDP-destinationsgränsen. Tabellen tillåter pakettakter på 1–600000 och burstvärden på 1–10000; standardvärdet 1 och exempelsiffrorna är ingen produktionsbaseline. De extra flaggorna finns under DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag och DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Slå inte samman upprepade tabellrubriker till ett globalt PacketRate, BurstRate eller ApplyFlag; bevara sparade värden tillsammans med deras överordnade sökväg.

Läs svarskoder med operation och sparat tillstånd

Referensen anger följande operationsspecifika koder, inte universella HTTP-resultat:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. Blanda särskilt inte ihop Add-409 med Edit-404.
• Configure Spoof Prevention och Configuration DOS Settings: vardera 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule och Delete Trusted MAC: endast 200, 500 på dessa sidor.
• Add Trusted MAC och Update Trusted MAC: vardera 200 med Operation Successful. och 500 med Operation Fail..

För övriga nämnda operationer förblir meddelandena i de fullständiga källorna JavaScript-symboler, inte upplösta svarstexter:

Jämför efter varje ändring svaret med faktiskt sparade zoner, takter, bindningar eller bypasskombinationer. Vid fel eller oklart svar, läs det aktuella tillståndet igen före ett nytt försök; skapa inte posten blint på nytt och dra inte slutsatsen att filtret fungerar enbart av 200. Kontrollera därefter separat ett matchande och ett icke matchande testflöde enligt beskrivningen ovan.

Vad dessa inställningar inte löser

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

• Servern angrips via tillåtna HTTP-förfrågningar: Kontrollera WAF-regel och Webserver Protection.
• En känt skadlig käll-IP angriper: Kontrollera Threat Feeds eller lands-/IP-blockering.
• Exploitförsök mot en tjänst: Aktivera en IPS-policy som passar regeln.
• Internetförbindelsen är mättad av DDoS: Involvera leverantören, scrubbing eller ett uppströms DDoS-skydd.
• Brandväggsregeln tillåter för mycket: Rensa upp i regelverket, NAT och objektmodellen.
• Det går inte att fastställa varför paket kasseras: Förbättra loggning, Packet Capture, Syslog eller Central Reporting.

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 på brandväggshändelser och relevanta säkerhetshändelser.
2. Generera testtrafik med tydlig Source-IP, Destination-IP och Service.
3. Använd Packet Capture när orsaken till kasserade paket är oklar.
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. CLI-räknemetoden global gäller inte dessa UI-räknare; inte heller en sådan jämförelse verifierar därför global aggregering. För en global CLI-policy ska konfigurationskontrollen med show skiljas från kontrollen av det definierade testflödet och tillhörande drops/loggar. 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

• Aktivera Spoof Protection utan förståelse för routing: Legitim trafik kan blockeras. Kontrollera zoner, gränssnitt, rutter och returvägar i förväg.
• Använda DoS-tröskelvärden utan kontroll: VoIP, övervakning, skanningar eller publicerade tjänster kan störas. Planera för en baslinje och en testfas.
• Förväxla Packet Rate och Burst Rate: Ihållande paketfrekvens och kortvariga toppar är olika inställningsparametrar. Båda måste passa tjänsten.
• Lösa varje avvikelse med ett brett undantag: Härdningen blir verkningslös och svåröverskådlig. Avgränsa orsaken och dokumentera snävt avgränsade undantag.
• Konfigurera DoS bypass rule för brett: I WebAdmin kontrolleras undantaget före de DoS Settings som finns där och kan helt kringgå denna kontroll. Avgränsa Source, Destination, protokoll och portar snävt; kontrollera även separata CLI-policyer.
• Lämna IP-MAC-Pair-filtret tomt: Utan underhållna poster skapas ingen effektiv bindning. Kontrollera alltid med en känd testklient efter aktiveringen.
• Presentera DoS Settings som DDoS-skydd: Vid bandbreddsangrepp skapar detta felaktiga förväntningar. Planera leverantörs- och uppströmsskydd separat.
• Inte kontrollera loggar: Felaktiga blockeringar eller angrepp förblir osynliga. Gör kontroll av Log Viewer, Central Reporting eller Syslog till en del av driftrutinen.
• Tolka paket som kasseras på grund av spoofing enbart som angrepp: Routing- eller VLAN-fel förbises. Jämför Source-IP, Interface, rutt och Packet Capture.

Driftschecklista

Före aktivering:

• Zoner, interface och routing är förstådda.
• Kritiska tjänster och testfall är definierade.
• Packet Rate, Burst Rate och aktiverade flaggor har bedömts tekniskt.
• Backup eller ändringsdokumentation finns.
• Loggning och analys är förberedda.
• Pilotområde eller underhållsfönster är fastställt.

Efter aktivering:

• Internet, VPN, WAF, DNAT, VoIP och övervakning har testats.
• Log Viewer har kontrollerats för oväntat kasserade paket.
• Packet Capture har använts för minst ett tydligt testfall om paket kasseras.
• Undantag har endast konfigurerats med snäv omfattning och motivering.
• DoS bypass rules har kontrollerats med avseende på Source, Destination, protokoll och portar.
• Resultatet har dokumenterats i driftdokumentationen.

Regelbundet:

• Kontrollera DoS- och Spoof-händelser.
• Kontrollera att undantagen fortfarande behövs.
• Testa på nytt efter nätverksombyggnader, VPN-ändringar eller nya VLAN.
• Korrelera loggar med IPS-, Threat-Feed-, WAF- och brandväggsregelhändelser.

FAQ