Så här använder du Cloudflare "Under Attack" läget på en webbplats som utsätts för DDoS-attacker

Cloudflare Under Attack-läget är en akut säkerhetsinställning som filtrerar bort bottrafik genom att visa besökare en kort säkerhetsverifiering. Genom att välja din webbplats i Cloudflare-panelen och aktivera Under Attack Mode under säkerhetsavsnittet kan du på några minuter bromsa överbelastande HTTP/HTTPS-förfrågningar, skydda verkliga användare från att nå webbplatsen och minska belastningen på din server. Men detta läge är inte en permanent lösning; det bör användas i kombination med korrekt DNS-proxyinställning, WAF-regler, hastighetsbegränsning, cache-konfiguration och säkerhet på origin-servern.

I den här guiden kommer vi steg för steg att gå igenom hur man aktiverar Cloudflare Under Attack-läget, när det bör användas, vilka inställningar som bör stödja det och hur man säkert återgår till det normala efter att attacken har upphört. Målet är att erbjuda en handlingsplan som kan tillämpas i paniksituationer och säkerställa att din webbplats är tillgänglig så snabbt som möjligt.

Vad är Cloudflare Under Attack-läget?

Cloudflare Under Attack-läget är en nödsäkerhetsnivå som erbjuds av Cloudflare. När läget aktiveras, kontrollerar Cloudflare besökarnas webbläsare med en kort verifiering. Denna verifiering tar vanligtvis bara några sekunder och gör det svårare för automatiska botar, enkla HTTP-floodverktyg eller illvilliga klienter utan webbläsare att överbelasta webbplatsen direkt.

Det primära syftet med detta läge är att mildra attacker på applikationslagret, det vill säga på Layer 7-nivån. Om exempelvis hemsidan får tusentals GET-förfrågningar per sekund, intensiva POST-försök på inloggningssidan, kostsamma förfrågningar på söksidan eller falsk trafik på kundvagnssidan, ger Under Attack-läget en snabb första åtgärd.

Det är viktigt att notera följande: Under Attack-läget filtrerar webbförfrågningar; men om din servers IP-adress är direkt riktad, om dina tjänster utanför Cloudflare-proxy är exponerade, eller om attacken sker på Layer 3/4-nivån, behövs ytterligare åtgärder. Därför är det avgörande att DNS-posterna är proxied via Cloudflare, att origin IP-adressen är dold, och att rätt säkerhetsåtgärder tillämpas på hosting-sidan. För att säkerställa en säker infrastruktur kan du referera till Tjänster för säker webbhosting och installation av SSL-certifikat.

Tecken på DDoS-attacker: Vad bör kontrolleras innan Under Attack-läget aktiveras?

Inte varje fördröjning innebär en DDoS-attack. Ibland kan ett felaktigt tillägg, en låst databas, en CPU-intensiv cron-uppgift eller felaktig cache-konfiguration leda till liknande resultat. Därför är det fördelaktigt att göra en snabb diagnos innan Under Attack-läget aktiveras. Om servern fortfarande har problem med att svara, om användarna får 502, 503, 504-felmeddelanden, och om loggarna visar en onormal förfrågningsökning, bör det akuta läget inte fördröjas.

Typiska tecken på DDoS-attacker

• En trafikökning som är 5, 10 eller 50 gånger mer än det normala på kort tid.
• Hundratals förfrågningar per sekund till en enda sida eller endpoint.
• Trafikflöde från olika länder men med liknande user-agent-värden.
• Mål för kostsamma URL:er som admin, login, search, cart i WordPress, WooCommerce, OpenCart eller skräddarsydd programvara.
• Serverns CPU, RAM, PHP-FPM-arbetare eller MySQL-anslutningars gränser är fyllda.
• En plötslig ökning av 4xx- och 5xx-fel på Cloudflare Analytics-skärmen.
• Verkliga användare kan nå webbplatsen sporadiskt, men bottrafiken skickar ständigt förfrågningar.

Till exempel, om en e-handelswebbplats normalt får 2 000 förfrågningar per minut, och detta ökar till 80 000 förfrågningar per minut på 10 minuter, och 70 % av förfrågningarna går till kundvagnen eller söksidan, är detta en tydlig indikation på en Layer 7-attack. I detta scenario bör Under Attack-läget aktiveras inom de första 5 minuterna, och specialanpassade WAF- och hastighetsbegränsningsregler bör läggas till för de specifika målsidorna.

När bör Cloudflare Under Attack-läget användas?

Cloudflare Under Attack-läget är inte en standard säkerhetsinställning som bör hållas aktiv hela tiden. Det visar också en kort vänteskärm för verkliga besökare. Detta kan påverka användarupplevelsen, särskilt på konverteringsfokuserade sidor, vid betalningssteg eller i strukturer som använder API. Den mest korrekta användningen är att tillfälligt aktivera det under en attack och sedan justera säkerhetsnivån när trafiken återgår till det normala.

Situationer där det är lämpligt att använda

• Om det kommer en stor mängd anormal HTTP/HTTPS-förfrågningar till webbplatsen.
• Om serverresurserna snabbt tar slut och 502/503-fel ökar.
• Om Cloudflare WAF ännu inte har konfigurerats med specialregler och en snabb skyddsåtgärd behövs.
• Om bottrafiken är betydligt högre än verklig användartrafik.
• Om attackmålen är webbsidor, formulär, inloggningsskärmar eller sök-API:er.

Situationer där det bör användas med försiktighet

• Om mobilapplikationer, betalningstjänster, webhook eller API-trafik används intensivt.
• Om det är en period där sökmotorbotar utför kritisk genomsökning.
• Om dina företagskunder får tillgång via äldre webbläsare eller begränsade nätverksmiljöer.
• Om det finns underdomäner på din webbplats som inte är bakom Cloudflare-proxy.

Om Under Attack-läget tillämpas på hela domänen på webbplatser med API-trafik kan vissa integrationer misslyckas. Därför bör det planeras för specialanpassade WAF-regler, tillåtelistor eller olika säkerhetsnivåer för API-underdomäner om möjligt. För en detaljerad guide om API-säkerhet kan Guide till API-säkerhet och hastighetsbegränsning rekommenderas.

Hur aktiverar man Cloudflare Under Attack-läget? Steg för steg tillämpning

Nedan följer steg som utgör en praktisk kontrollista för att snabbt agera under en attack. Cloudflare-gränssnittet kan visa små förändringar över tid, men logiken förblir densamma: du väljer din domän, höjer säkerhetsnivån och validerar den inkommande trafiken via Cloudflare.

1. Logga in på ditt Cloudflare-konto

Börja med att logga in på ditt Cloudflare-konto och välj den domän som är under attack. Om du hanterar flera domäner, se till att du arbetar på rätt zon. Att aktivera Under Attack-läget på fel domän kan leda till onödig fördröjning medan den verkliga attacken fortsätter.

2. Kontrollera att DNS-posterna är proxied

För att Under Attack-läget ska vara effektivt måste webbtrafiken passera genom Cloudflare. Se till att A-, AAAA- och CNAME-posterna i DNS-delen är i proxied-läge, det vill säga den orangea molnikonen. DNS-poster som är i grått läge (endast DNS) passerar inte Cloudflares säkerhetslager. Speciellt www, rot-domänen och de använda underdomänerna bör kontrolleras.

Om din origin IP-adress är synlig på internet kan angripare kringgå Cloudflare och attackera servern direkt. Därför är det en stark åtgärd att endast tillåta HTTP/HTTPS-trafik från Cloudflare IP-områden i serverns brandvägg. Du kan få stöd från din hosting-leverantör om detta, eller hänvisa till Hur man ställer in Cloudflare DNS.

3. Aktivera Under Attack-läget i säkerhetsavsnittet

Efter att ha öppnat den relevanta domänen i Cloudflare-panelen, hitta alternativet Under Attack Mode i Security eller Overview-skärmen. När du aktiverar detta alternativ börjar Cloudflare att visa en kort verifieringssida för besökare som kommer till webbplatsen. I vissa paneler kan denna inställning också synas som I am Under Attack under Security Level.

Ändringar trädde vanligtvis i kraft snabbt efter aktivering. Under de första minuterna bör Cloudflare Analytics, Security Events och serverresursanvändningen övervakas tillsammans. Om CPU och anslutningsantalet börjar sjunka, betyder det att läget fungerar. Men om felprocenten fortsätter att vara hög, bör ytterligare regler skrivas.

4. Testa den verkliga användarupplevelsen

Efter att ha aktiverat läget, testa webbplatsen från olika nätverk. Mobilinternet, kontorsnätverk och om möjligt från en annan plats, bör testas på hemsidan, produktsidan, inloggningssidan och betalningsflödet. Om du kan nå webbplatsen efter verifieringsskärmen, är det det förväntade beteendet. Om användare hamnar i en oändlig verifieringscykel bör inställningar som cookie-blockering, webbläsarkompatibilitet eller konflikter med Cloudflare-säkerhetsregler kontrolleras.

5. Identifiera de URL:er som attacken riktar sig mot

Under Attack-läget ger ett allmänt skydd, men den verkliga effektiviteten uppnås med mål-specifika regler. Hitta de mest begärda vägarna genom Cloudflare Security Events, Web Analytics, hostingåtkomstloggar och applikationsloggar. Exempelvis kan /wp-login.php, /xmlrpc.php, /search, /cart, /api/login eller /checkout vara under attack.

När mål-URL:en har identifierats kan åtgärder vidtas med hjälp av WAF Custom Rules baserat på kriterier som land, user-agent, begärningsmetod, URI-sökväg eller bot-poäng. Till exempel kan IP-adresser som skickar över ett rimligt antal förfrågningar per minut till en viss inloggningsendpoint få en hanterad utmaning tillämpad. För WordPress-sajter är Säkerhetsåtgärder för WordPress ett naturligt inlänkningsmöjlighet.

Skillnader mellan Under Attack-läget och andra Cloudflare-säkerhetsalternativ

Cloudflares säkerhetsverktyg tjänar olika syften. Under Attack-läget är ett snabbt och generellt nödsäkerhetsfilter; WAF och hastighetsbegränsning erbjuder mer riktade, hållbara och användarvänliga lösningar.

I praktiken följer en bra försvarsstrategi denna väg: Först dämpas akuttrycket med Under Attack-läget, sedan analyseras attackmönstret, WAF och hastighetsbegränsningsregler läggs till, och slutligen förstärks den permanenta strukturen med cache- och origin-brandväggsinställningar.

Rekommenderade ytterligare Cloudflare-inställningar under attack

Även om Under Attack-läget kan aktiveras med en knapptryckning, beror framgången för DDoS-försvar på stödjande inställningar. Nedan följer förslag som ofta visar sig vara användbara i verkliga operationer.

Skapa riktat skydd med WAF-regler

Cloudflare WAF gör det möjligt för dig att vidta åtgärder baserat på specifika villkor. Till exempel kan du tillämpa en utmaning på POST-förfrågningar som kommer till sidan /wp-login.php från specifika länder. På så sätt isolerar du attackens mål utan att tynga hela webbplatsen.

• Öppna admin- och inloggningssidor endast för specifika länder eller IP-områden.
• Blockera oanvända endpoint:er som XML-RPC.
• Tillämpa hanterade utmaningar för misstänkta user-agent-värden.
• Begränsa klienter som gör för många förfrågningar på vissa URI-sökvägar med hastighetsbegränsning.

Ställ in cache-nivån korrekt

Om origin-servern måste svara på varje begäran under DDoS kan resurser snabbt ta slut. Statiska filer, bilder, CSS, JavaScript och cachebara sidor bör levereras via Cloudflare-edge. I dynamiska system som WordPress kan en sidcache-plugin, Cloudflare cache-regler och lämpliga cache-control-headerar användas tillsammans.

Exempelvis kan sidor som visas för anonyma besökare på en nyhets- eller bloggsida cachas i 5 till 30 minuter. Denna enkla inställning minskar TTFB-värden även under perioder utan attacker och avlastar hostingsresurserna. För prestandasidan kan Guide till webbplatsaccelerering övervägas.

Ställ in hastighetsbegränsningsgränser realistiskt

Hastighetsbegränsning är mycket effektiv, särskilt vid kostsamma endpoint:er. Men om trösklarna sätts slumpmässigt kan verkliga användare blockeras. Till exempel kan en normal användare på en produkt-söksida göra 5-15 sökningar per minut; 100 sökningar per minut är onormalt. På inloggningssidan är 10 misslyckade försök inom 5 minuter misstänkt i de flesta scenarier.

Ett exempel på tillvägagångssätt: En IP-adress som skickar mer än 10 förfrågningar per minut till /wp-login.php kan få en hanterad utmaning, och en IP-adress som skickar mer än 50 förfrågningar inom 5 minuter kan blockeras tillfälligt. På API-endpoint:er bör mer precisa begränsningar baseras på användarsessioner, IP, token och metod föredras.

Dölja origin IP-adressen och begränsa med brandvägg

En av de mest kritiska misstagen när man använder Cloudflare är att lämna origin IP-adressen öppen. Gamla DNS-poster, underdomäner som arbetar direkt med IP, webbtjänster som blandas med e-postposter eller läckta konfigurationer kan tillåta angripare att nå servern utanför Cloudflare.

Att öppna portar 80 och 443 endast för Cloudflare IP-områden på serversidan ger ett starkt skydd. Dessutom bör SSH, panel, databas och administrationsportar inte lämnas öppna för internet; IP-begränsning, starka lösenord, 2FA och om möjligt VPN bör användas. För säkerheten på hosting-sidan kan cPanel säkerhetsinställningar och konfiguration av VPS-brandvägg länkas.

Specifika punkter att beakta för WordPress, WooCommerce och företagswebbplatser

Varje webbplats har inte samma trafikstruktur. En blogg, en WooCommerce-butik och ett SaaS-panel kan ge olika resultat med Cloudflare Under Attack-läget. Därför bör kritiska vägar bestämmas beroende på webbplatstyp.

WordPress-webbplatser

De mest frekvent målade filerna i WordPress är /wp-login.php och /xmlrpc.php. Om du inte använder XML-RPC är det oftast säkert att blockera det. För adminpanelen kan land- eller IP-begränsningar tillämpas. Dessutom bör säkerhetstillägg inte krocka med Cloudflare-regler; för många utmaningsmekanismer samtidigt kan leda till att användaren hamnar i en verifieringscykel.

WooCommerce-butiker

I WooCommerce kräver kundvagn, betalning och kontosidor särskild uppmärksamhet. Eftersom dessa sidor är dynamiska bör aggressiv caching undvikas. Se till att betalningstjänstens callback eller webhook-URL:er fungerar när Under Attack-läget är aktivt. Om nödvändigt bör betalningstjänstens IP-områden läggas till tillåtelistan eller en särskild regel skrivas för den specifika endpointen.

Företags- och API-användande webbplatser

Företagsportaler, CRM-integrationer och mobilapp-API:er kanske inte kan hantera JavaScript-utmaningsskärmen. I sådana strukturer kan det vara mer korrekt att hantera API-underdomänen separat istället för att tillämpa Under Attack-läget på hela domänen. Till exempel kan Under Attack-läget aktiveras för www.example.com medan tokenbaserad säkerhet, hastighetsbegränsning och tillåtelistor kan tillämpas för api.example.com.

Metriker att följa efter att Under Attack-läget har aktiverats

För att förstå om en säkerhetsåtgärd fungerar eller inte krävs numerisk övervakning. Det är inte tillräckligt att webbplatsen bara öppnas; felprocent, serverbelastning och verkligt användarbeteende måste utvärderas tillsammans.

• Cloudflare Security Events: Visar hur många förfrågningar som har utmanats eller blockerats av vilka regler.
• HTTP-statuskoder: Förändringar i 403, 429, 502, 503 och 504-fel bör övervakas.
• Serverns CPU och RAM-användning: En minskning förväntas efter Under Attack.
• PHP-FPM och MySQL-anslutningar: Visar lättnaden på applikationslagret.
• Bredband och antal förfrågningar: Trafikvolymen bör jämföras med andelen filtrerade förfrågningar.
• Verkliga användarkonversioner: Formulärinlämningar, beställningar, inloggningar och betalningssteg bör testas.

Om antalet totala förfrågningar kvarstår detsamma efter att Under Attack-läget har aktiverats, men förfrågningarna som når origin minskar med 60 %, betyder det att Cloudflare-lagret absorberar en betydande belastning. Om MySQL-CPU-användningen fortfarande är hög kan attacken ha aktiverat en specifik dynamisk fråga; i så fall bör applikationsloggarna granskas.

Hur stänger man Under Attack-läget efter att attacken har upphört?

När attacktrafiken återgår till det normala rekommenderas det inte att hålla Under Attack-läget aktivt permanent för de flesta webbplatser. Eftersom en extra verifiering för varje besökare kan påverka konverteringsgraden, crawlers effektivitet och användarnöjdhet. Avstängningsprocessen bör också göras kontrollerat.

Säkra steg för att återgå till det normala

• Vänta minst 30-60 minuter för trafiknivån att återgå till det normala.
• Verifiera på Cloudflare Security Events-skärmen att antalet utmaningar och blockeringar har minskat.
• Innan Under Attack-läget stängs av, se till att riktade WAF- och hastighetsbegränsningsregler är aktiva.
• Justera säkerhetsnivån till en mer balanserad nivå som High eller Medium.
• Testa webbplatsen från olika enheter och övervaka 5xx-felprocenten.
• Följ loggarna under 24 timmar för att kontrollera om attacken börjar igen.

Som en god praxis bör en händelserapport skapas efter attacken. Denna rapport ska innehålla attackens starttid, mål-URL:er, det högsta antalet förfrågningar, vidtagna åtgärder, effektiva regler och varaktiga förbättringar. Detta dokument kommer att avsevärt förkorta svarstiden vid nästa incident.

Vanliga misstag och saker att undvika

Under en DDoS-attack måste snabba beslut fattas; men felaktiga inställningar kan blockera verkliga användare. Följande misstag är särskilt vanliga under intensiv stress.

• Tro att Under Attack-läget kommer att ge skydd utan att DNS-posterna är proxied.
• Lämna origin IP-adressen öppen och inte blockera åtkomst utanför Cloudflare IP med brandväggen.
• Tillämpa en utmaning på hela domänen utan att testa API, webhook och betalningscallback-adresser.
• Skapa alltför breda WAF-blockeringsregler som blockerar riktiga kunder.
• Aggressiv caching av sidor som inte bör cachelagras, såsom kundvagn, betalningar eller användarpaneler.
• Att låta läget vara aktivt i veckor efter att attacken har upphört.
• Enbart förlita sig på Cloudflare-skärmen för beslut utan att granska serverloggarna.

Speciellt på e-handelswebbplatser kan blockering av betalningscallback:er orsaka allvarliga intäktsförluster. Därför är det säkrare att testa säkerhetsregler med logg eller hanterad utmaning istället för blockering. När effekten av regeln bekräftas kan mer strikta åtgärder vidtas.

Hur man planerar en mer motståndskraftig försvarsinfrastruktur på Hostragons

Cloudflare erbjuder ett starkt skyddslager, men framgångsrikt DDoS-försvar handlar inte bara om CDN-sidan. Hosting-infrastrukturen, programvaruoptimering, SSL-konfiguration, DNS-hantering och backupstrategier måste beaktas tillsammans. Den grundläggande strategin för en webbplats som hostas på Hostragons bör vara: Cloudflare filtrerar trafiken, hostinglagret hanterar endast ren trafik, och applikationen optimeras för att inte producera onödig databasbelastning.

Innan ett nytt projekt lanseras är det viktigt att domänen hanteras med korrekta DNS-poster, SSL-certifikatet installeras utan problem, och att resurserna på webbservern väljs baserat på din trafikprofil. Vid denna punkt kan Domänsökning och registrering av domännamn, Web hosting paket, lösningar för företags hosting och Gratis SSL-certifikat hjälpa användaren.

För projekt med hög trafik eller hög risk för attacker bör mer kontrollerade VPS- eller hanterade serveralternativ övervägas istället för standard delad hosting. På så sätt kan brandvägg, webbserver, PHP-FPM, Redis, objektcache och databasinställningar konfigureras på ett mer flexibelt sätt. Men oavsett vilken infrastruktur som väljs, bör Cloudflare Under Attack-läget endast ses som ett akutverktyg; den permanenta säkerhetsarkitekturen bör stödjas med WAF, logganalys och regelbundna uppdateringar.

Snabb kontrollista: De första 15 minuterna under en DDoS-attack

Tiden är kritisk under en attack. Nedan följer en lista som sammanfattar vad den tekniska personalen eller webbplatsägarna kan göra under de första 15 minuterna.

• Logga in på Cloudflare-panelen och välj rätt domän.
• Kontrollera att DNS-posterna är proxied, det vill säga har den orangea molnikonen.
• Aktivera Under Attack-läget.
• Testa hemsidan, inloggning, kundvagn, betalning och API-endpoint:er.
• Identifiera målsidor via Cloudflare Security Events-skärmen.
• Lägg till specialanpassade WAF- eller hastighetsbegränsningsregler för de mest utsatta vägarna.
• Kontrollera serverns CPU, RAM, PHP-FPM och MySQL-status.
• Testa direkt åtkomst till origin IP.
• Kontrollera om det behövs tillåtelistor för betalningstjänster, webhookar och kritiska integrationer.
• Notera alla åtgärder med tidsstämplar.

Om denna lista övas regelbundet minskar paniken under en verklig attack och kvaliteten på åtgärderna ökar. På större webbplatser rekommenderas det att denna process dokumenteras som en händelsehanteringsplan.

Vanliga frågor

Skyddar Cloudflare Under Attack-läget webbplatsen helt?

Nej. Cloudflare Under Attack-läget är särskilt effektivt för att minska bot- och floodtrafik på HTTP/HTTPS-nivå; men det ger inte fullständigt skydd på egen hand. DNS-poster måste vara proxied, origin IP måste döljas, och det bör användas tillsammans med WAF-regler, hastighetsbegränsning, cache och brandväggsinställningar.

Skadar Under Attack-läget SEO?

Kortvarig användning orsakar vanligtvis inte allvarlig SEO-skada. Men om läget är aktivt under en längre tid kan det påverka sökmotorernas genomsöknings effektivitet och användarupplevelsen. Därför är det bättre att stänga av läget efter attacken och fortsätta med riktade säkerhetsregler.

Hur länge bör Cloudflare Under Attack-läget vara aktivt?

Det kan hållas aktivt tills attackens intensitet minskar; i praktiken rekommenderas det att övervaka i minst 30-60 minuter efter att trafiken har återgått till det normala, och sedan stänga av det gradvis. Innan läget stängs av bör WAF och hastighetsbegränsning vara klara.

Påverkar Under Attack-läget API eller betalningssystem?

Ja, det kan påverka. Eftersom vissa API-klienter, webhook-tjänster och betalningscallback-system kanske inte kan slutföra webbläsarbaserad säkerhetsverifiering. Därför bör kritiska endpoint:er testas, och tillåtelistor eller specifika Cloudflare-regler definieras vid behov.

Måste man ta ytterligare åtgärder på hosting-sidan när man använder Cloudflare?

Ja. Cloudflare erbjuder ett starkt skyddslager, men origin-serverns IP-adress måste döljas, brandväggen bör endast tillåta nödvändig trafik, programvaran bör hållas uppdaterad och cache-konfigurationen måste göras korrekt. En säker hosting-infrastruktur är en viktig del av DDoS-motståndskraften.

Slutsats

Cloudflare Under Attack-läget är ett effektivt akutverktyg som ger snabba lättnader för en webbplats som utsätts för DDoS-attacker. När det aktiveras med rätt DNS-proxyinställning minskar det bottrafiken, minskar serverbelastningen och ökar chansen för verkliga användare att nå webbplatsen. För bästa resultat bör detta läge stödjas med WAF-regler, hastighetsbegränsning, cacheoptimering och säkerhet på origin-brandväggen.

Om du vill att din webbplats ska fungera mer motståndskraftigt mot attacker, bör du regelbundet granska din infrastruktur, DNS-hantering och SSL-konfiguration. Genom att utforska Hostragons hosting-, domän- och SSL-lösningar kan du skapa en mer säker och hållbar grund för din webbplats.