Hoe gebruik je de Cloudflare "Under Attack" modus op een site die onder DDoS-aanval staat?

De Cloudflare Under Attack modus is een noodinstelling die botverkeer kan filteren door bezoekers een korte beveiligingsverificatie te tonen op een site die onder DDoS-aanval staat. Door je website te selecteren in het Cloudflare-dashboard en de functie Under Attack Mode in de sectie Beveiliging in te schakelen, kun je binnen enkele minuten de hoeveelheid intensieve verzoeken op HTTP/HTTPS-niveau vertragen, de toegang voor echte gebruikers behouden en de belasting op je server verminderen. Deze modus is echter geen permanente oplossing; het moet worden gebruikt in combinatie met de juiste DNS-proxy-instellingen, WAF-regels, rate limiting, cache-configuratie en beveiliging van de origin server.

In deze gids behandelen we stapsgewijs hoe je de Cloudflare Under Attack modus inschakelt, wanneer deze moet worden gebruikt, met welke instellingen deze moet worden ondersteund en hoe je na de aanval veilig naar de normale situatie terugkeert. Het doel is om een handige checklist aan te bieden die toepasbaar is in noodsituaties om de toegankelijkheid van jouw website zo snel mogelijk te herstellen.

Wat is de Cloudflare Under Attack Modus?

De Cloudflare Under Attack modus is een veiligheidsniveau voor noodsituaties dat door Cloudflare wordt aangeboden. Wanneer deze modus is ingeschakeld, laat Cloudflare de bezoekers van de site een korte verificatie door hun browser uitvoeren. Deze verificatie duurt meestal een paar seconden en maakt het moeilijker voor automatische bots, eenvoudige HTTP-floodtools of kwaadaardige niet-browserclients om directe belasting op de site te veroorzaken.

Het hoofddoel van deze modus is het verlichten van aanvallen op de applicatielaag, oftewel Layer 7. Bijvoorbeeld, als er duizenden GET-verzoeken per seconde naar de homepage gaan, of er zijn veelvuldige POST-pogingen op de inlogpagina van WordPress, of als er dure zoekopdrachten naar de zoekpagina of neptrafiek naar de winkelwagentjes wordt gestuurd, biedt de Under Attack modus een snelle eerste reactie.

Een belangrijke nuance is dat de Under Attack modus webverzoeken filtert; maar als het IP-adres van jouw server direct doelwit is, als jouw services buiten Cloudflare om toegankelijk zijn, of de aanval plaatsvindt op Layer 3/4, dan zijn er extra maatregelen nodig. Daarom is het cruciaal dat de DNS-records via Cloudflare zijn geproxiëerd, dat het origin IP-adres is verborgen, en dat de juiste beveiligingsmaatregelen op de hostingzijde worden toegepast. Voor veilige infrastructuurkeuzes kan worden doorverwezen naar Veilige webhostingdiensten en installatie van SSL certificaat.

Symptomen van een DDoS-aanval: Wat moet worden gecontroleerd voordat je de Under Attack Modus inschakelt?

Niet elke vertraging is een DDoS-aanval. Soms kan een defecte plugin, een vergrendeling van de database, een cron-taak die veel CPU gebruikt, of een verkeerde cache-instelling soortgelijke resultaten opleveren. Daarom is het nuttig om snel een diagnose te stellen voordat je de Under Attack modus inschakelt. Als de server echter moeite heeft om te reageren, gebruikers een 502, 503, of 504-fout krijgen, en er een ongewoon aantal verzoeken in de logboeken staat, moet de noodmodus onmiddellijk worden ingeschakeld.

Typische DDoS-indicatoren

• Een verkeersstijging van 5, 10 of 50 keer normaal in een kort tijdsbestek.
• Honderden verzoeken per seconde naar één enkele pagina of endpoint.
• Trafiek afkomstig uit verschillende landen met vergelijkbare user-agentwaarden.
• Doelgericht verkeer naar dure URL's zoals admin, login, search, cart in WordPress, WooCommerce of OpenCart.
• Volle CPU-, RAM-, PHP-FPM-werknemer of MySQL-verbindinglimieten op de server.
• Een plotselinge stijging van 4xx en 5xx fouten in het Cloudflare Analytics-scherm.
• Echte gebruikers hebben sporadische toegang tot de site, maar botverkeer blijft continu verzoeken sturen.

Bijvoorbeeld, als een e-commerce website normaal gesproken 2.000 verzoeken per minuut ontvangt en dat aantal stijgt naar 80.000 in 10 minuten, en 70% van die verzoeken gaat naar de winkelwagentjes of zoekpagina's, dan is dit een duidelijk teken van een Layer 7-aanval. In dit scenario moet de Under Attack modus binnen de eerste 5 minuten worden ingeschakeld, gevolgd door specifieke WAF- en rate limiting-regels voor de doel-URL's.

Wanneer moet de Cloudflare Under Attack Modus worden ingeschakeld?

De Cloudflare Under Attack modus is geen standaard beveiligingsinstelling die voortdurend aan moet staan. Dit komt omdat het echte bezoekers ook een korte wachtscherm toont. Dit kan de gebruikerservaring negatief beïnvloeden, vooral op conversiegerichte pagina's, bij betaalprocessen of in API-gebaseerde structuren. Het meest juiste gebruik is om het tijdelijk in te schakelen tijdens een aanval en de beveiligingsinstellingen opnieuw aan te passen zodra het verkeer weer normaal is.

Situaties waarin het gebruik geschikt is

• Als de site intensieve en ongewone HTTP/HTTPS-verzoeken ontvangt.
• Als de serverbronnen snel opraken en het aantal 502/503-fouten stijgt.
• Als de Cloudflare WAF nog niet is geconfigureerd met specifieke regels en er snel een afscherming nodig is.
• Als botverkeer duidelijk de echte gebruikersverkeers overstijgt.
• Als de aanvallen gericht zijn op webpagina's, formulieren, inlogschermen of zoek-endpoints.

Situaties waar voorzichtigheid geboden is

• Als er veel gebruik wordt gemaakt van mobiele applicaties, betalingsproviders, webhooks of API-verkeer.
• Als je in een periode bent waarin zoekmachine-bots cruciale crawls uitvoeren.
• Als je zakelijke gebruikers via verouderde browsers of beperkte netwerkomgevingen toegang geeft.
• Als je subdomeinen hebt die niet achter de Cloudflare proxy staan.

Als de Under Attack modus wordt toegepast op websites met API-verkeer, kunnen sommige integraties mislukken. Daarom moet, waar mogelijk, er een speciale WAF-regel, allowlist of een ander beveiligingsniveau worden gepland voor API-subdomeinen. Voor een gedetailleerde gids over API-beveiliging kan Gids voor API Beveiliging en Rate Limiting worden aanbevolen.

Hoe schakel je de Cloudflare Under Attack Modus in? Stapsgewijze toepassing

De onderstaande stappen vormen een praktische checklist die is voorbereid voor snelle actie tijdens een aanval. De Cloudflare-interface kan in de loop van de tijd lichte wijzigingen ondergaan; de logica blijft echter hetzelfde: kies je domeinnaam, verhoog het beveiligingsniveau en valideer het inkomende verkeer via Cloudflare.

1. Log in op je Cloudflare-account

Log eerst in op je Cloudflare-account en kies de domeinnaam die onder aanval staat. Als je meerdere domeinnamen beheert, zorg er dan voor dat je de juiste zone behandelt. Het inschakelen van de Under Attack modus op het verkeerde domein verspilt tijd terwijl de daadwerkelijke aanval doorgaat.

2. Controleer of de DNS-records geproxiërd zijn

Om de effectiviteit van de Under Attack modus te waarborgen, moet het webverkeer via Cloudflare lopen. Controleer in de DNS-sectie of de A-, AAAA- en CNAME-records de oranje wolk weergeven, wat betekent dat ze geproxiërd zijn. Grijze wolkstatus van DNS-only records stelt ze niet in staat om door de Cloudflare-beveiligingslaag te komen. Zorg ervoor dat je de www-, root domeinnaam en gebruikte subdomeinen controleert.

Als je origin IP-adres zichtbaar is op het internet, kunnen aanvallers Cloudflare omzeilen en direct de server aanvallen. Het is daarom een sterke extra maatregel om alleen HTTP/HTTPS-verkeer van Cloudflare IP-ranges toe te staan in de firewall van de server. Je kunt ondersteuning vragen aan je hostingprovider of een verwijzing maken naar de Hoe Cloudflare DNS-instellingen te maken gids.

3. Schakel de Under Attack Mode in via de Beveiliging sectie

Nadat je de relevante domeinnaam in het Cloudflare-dashboard hebt geopend, vind je de optie Under Attack Mode in het beveiligings- of overzichtscherm. Zodra je deze optie inschakelt, begint Cloudflare een korte verificatiepagina te tonen aan de bezoekers van de site. In sommige panelen kan deze instelling ook worden weergegeven als I am Under Attack onder Beveiligingsniveau.

Na activatie worden de wijzigingen meestal binnen korte tijd doorgevoerd. In de eerste minuten moeten Cloudflare Analytics, Beveiligingsgebeurtenissen en het serverresourceverbruik gezamenlijk worden gecontroleerd. Als het CPU- en connectie-aantal begint te dalen, betekent dit dat de modus werkt. Als het foutpercentage echter aanhoudt, moeten er extra regels worden geschreven.

4. Test de ervaring van echte gebruikers

Test de site na het inschakelen van de modus vanaf verschillende netwerken. Probeer de homepage, productpagina, inlogpagina en betalingsstroom vanuit mobiel internet, het kantoor netwerk en, indien mogelijk, vanuit een andere locatie. De verwachte uitkomst is dat het mogelijk is om de site te bereiken na de gebruikersverificatieschermen. Als gebruikers echter in een eindeloze bevestigingscyclus terechtkomen, moeten instellingen die cookies blokkeren, browsercompatibiliteit of conflicten met Cloudflare-beveiligingsregels worden nagekeken.

5. Bepaal de door de aanval doelgerichte URL's

De Under Attack modus biedt een algemene bescherming; maar echte effectiviteit komt voort uit specifieke regels voor de doelwitten. Vind de URL's die de meeste verzoeken ontvangen via Cloudflare Security Events, Web Analytics, hostingtoeganglogs en applicatielogs. Bijvoorbeeld URL's zoals /wp-login.php, /xmlrpc.php, /search, /cart, /api/login of /checkout kunnen onder aanval staan.

Eenmaal vastgesteld kan een actie worden ondernomen met WAF Custom Rules op basis van criteria zoals land, user-agent, verzoekmethode, URI-pad, of bot-score. Voor een specifieke login endpoint kan bijvoorbeeld een managed challenge worden toegepast op IP's die meer dan een acceptabel aantal verzoeken per minuut sturen. Voor WordPress-sites is WordPress Beveiligingsmaatregelen een natuurlijke interne link mogelijkheid.

De verschillen tussen de Under Attack Modus en andere Cloudflare Beveiligingsopties

De beveiligingshulpmiddelen van Cloudflare dienen verschillende doelen. De Under Attack modus is een snelle en algemene noodfilter; terwijl WAF en Rate Limiting meer gerichte, duurzame en gebruiksvriendelijke oplossingen bieden.

In de praktijk gaat een goede verdediging als volgt: Eerst wordt de druk met de Under Attack modus snel verminderd, vervolgens wordt het aanvalspatroon geanalyseerd, worden WAF- en rate limiting-regels toegevoegd, en tot slot wordt de permanente structuur versterkt met cache- en origin firewall-instellingen.

Aanbevolen extra Cloudflare-instellingen tijdens de aanval

Hoewel de Under Attack modus met één druk op de knop kan worden ingeschakeld, hangt het succes van DDoS-bescherming af van ondersteunende instellingen. De onderstaande aanbevelingen zijn in de praktijk het meest succesvol.

Creëer gerichte bescherming met WAF-regels

Cloudflare WAF stelt je in staat om acties te ondernemen op basis van specifieke voorwaarden. Je kunt bijvoorbeeld een challenge toepassen op POST-verzoeken die slechts naar de /wp-login.php pagina komen en afkomstig zijn uit bepaalde landen. Op deze manier isolement van het doelwit creëer je zonder de hele site te verzwaren.

• Open de admin- en inlogpagina's alleen voor bepaalde landen of IP-ranges.
• Blokkeer ongebruikte endpoints zoals XML-RPC.
• Pas een managed challenge toe voor verdachte user-agentwaarden.
• Beperk clients die zeer frequente verzoeken indienen op specifieke URI-paden via rate limiting.

Stel het cache-niveau correct in

Als de origin server op elke verzoek moet reageren tijdens een DDoS-aanval, raken de bronnen snel op. Statische bestanden, afbeeldingen, CSS, JavaScript, en cachebare pagina's moeten vanaf de Cloudflare edge worden geleverd. In dynamische structuren zoals WordPress kunnen page caching-plugins, Cloudflare-cacheregels en geschikte cache-control headers samen worden gebruikt.

Bijvoorbeeld, op een nieuwssite of blog kunnen pagina's die aan anonieme bezoekers worden getoond, 5 tot 30 minuten worden gecached. Deze eenvoudige instelling vermindert zelfs de TTFB-waarden en verlicht de hostingbronnen, zelfs buiten aanvalstijden. Voor prestatieverbeteringen kan gids voor websiteversnelling worden bekeken.

Stel realistische rate limiting-drempels in

Rate limiting is vooral effectief bij kostbare endpoints. Maar als de drempels willekeurig zijn ingesteld, kunnen echte gebruikers worden geblokkeerd. Bijvoorbeeld, een normale gebruiker kan 5-15 zoekopdrachten per minuut op een productzoekpagina doen; 100 zoekopdrachten per minuut zijn ongewoon. Op de inlogpagina zijn 10 mislukte pogingen binnen 5 minuten meestal verdacht.

Een voorbeeldbenadering: Voor /wp-login.php kan een managed challenge worden toegepast op IP's die meer dan 10 verzoeken per minuut indienen, en op IP's die meer dan 50 verzoeken in 5 minuten indienen kan een tijdelijke blokkade worden toegepast. Voor API-endpoints moeten delicate limieten op basis van gebruikerssessies, IP, token en methoden worden gekozen.

Verberg het origin IP-adres en beperk met de firewall

Een van de meest kritieke fouten die bij het gebruik van Cloudflare wordt gemaakt, is het blootstellen van het origin IP-adres. Oude DNS-records, subdomeinen die direct met IP werken, webservices die met mailrecords worden verward, of gelekte configuraties kunnen aanvallers in staat stellen om buiten Cloudflare om toegang te krijgen tot de server.

Het openen van poorten 80 en 443 op de server alleen voor Cloudflare IP-ranges biedt sterke bescherming. Bovendien moeten SSH, panelen, databases en beheerporten niet openbaar toegankelijk zijn; IP-beperkingen, sterke wachtwoorden, 2FA en indien mogelijk VPN moeten worden gebruikt. Voor hostingbeveiliging kunnen cPanel Beveiligingsinstellingen en VPS firewall configuratie worden geraadpleegd.

Bijzondere aandachtspunten voor WordPress, WooCommerce en zakelijke sites

Niet elke website heeft dezelfde verkeersstructuur. Een blogsite, WooCommerce-winkel en SaaS-dashboard kunnen verschillende resultaten opleveren met de Cloudflare Under Attack modus. Daarom moeten cruciale paden worden bepaald op basis van het type site.

WordPress-sites

De meest aangevallen besturen in WordPress zijn de paden /wp-login.php en /xmlrpc.php. Als je XML-RPC niet gebruikt, is het meestal veilig om het te blokkeren. Voor het beheerderspaneel kan een land- of IP-beperking worden toegepast. Zorg er ook voor dat beveiligingsplug-ins niet in conflict komen met Cloudflare-regels; te veel challenge-mechanismen kunnen gebruikers in een verificatiecyclus brengen.

WooCommerce-winkels

De winkelwagentje-, betalings- en accountpagina's van WooCommerce vereisen zorgvuldigheid. Omdat deze pagina's dynamisch zijn, moet er geen agressieve cache worden toegepast. Zorg ervoor dat tijdens de actieve Under Attack modus de callback- of webhook-URL's van de betalingsprovider goed functioneren. Indien nodig moeten de IP-ranges van de betalingsprovider op de allowlist worden geplaatst of moet er een speciale regel voor het betreffende endpoint worden geschreven.

Zakelijke en API-gebaseerde sites

Zakelijke portalen, CRM-integraties en mobiele applicatie-API's kunnen de JavaScript challenge-pagina mogelijk niet verwerken. In dergelijke gevallen is het beter om de Under Attack modus niet voor het volledige domein in te schakelen, maar het API-subdomein afzonderlijk te beheren. Bijvoorbeeld, terwijl Under Attack wordt ingeschakeld voor www.example.com, kan token-gebaseerde beveiliging, rate limiting en allowlisting worden toegepast voor api.example.com.

Metrieken om te volgen na het inschakelen van de Under Attack Modus

Om te begrijpen of een beveiligingsmaatregel effectief is, zijn numerieke monitoring en analyse nodig. Het alleen openen van de site is niet voldoende; foutpercentages, serverbelasting en het gedrag van echte gebruikers moeten gezamenlijk worden beoordeeld.

• Cloudflare Security Events: Toont hoeveel verzoeken door welke regels zijn uitgedaagd of geblokkeerd.
• HTTP-statuscodes: Veranderingen in de 403, 429, 502, 503, en 504 fouten moeten worden gevolgd.
• CPU- en RAM-gebruik van de server: Je moet een daling na Under Attack verwachten.
• PHP-FPM en MySQL-verbindingen: Dit toont de verlichting op de applicatielaag.
• Breedte en aantal verzoeken: Het verkeersvolume moet worden vergeleken met de gefilterde verzoekratio.
• Echte gebruikersconversies: Formulierrapportages, bestellingen, login- en betalingsstappen moeten worden getest.

Bijvoorbeeld, zelfs als het totale aantal verzoeken gelijk blijft na het inschakelen van de Under Attack modus, als het aantal verzoeken die de origin bereiken met 60% is afgenomen, betekent dit dat de Cloudflare-laag een significant deel van de belasting heeft geabsorbeerd. Maar als het CPU-gebruik van MySQL hoog blijft, kan de aanval een specifieke dynamische query activeren; in dat geval moeten de applicatielogs worden gecontroleerd.

Hoe de Under Attack Modus uit te schakelen na de aanval?

Het blijft niet aanbevolen voor de meeste sites om de Under Attack modus permanent ingeschakeld te houden zodra de aanval is gestopt. Dit kan namelijk de conversieratio, de efficiëntie van crawlen door zoekmachines en de gebruikerservaring negatief beïnvloeden. Het uitschakelen moet ook net zo zorgvuldig gebeuren als het inschakelen.

Stappen voor het veilig terugkeren naar normaliteit

• Wacht minstens 30-60 minuten tot de verkeersniveaus weer normaal zijn.
• Verifieer dat de aantallen van uitdagingen en blokkades op het Cloudflare Security Events-scherm zijn afgenomen.
• Voordat je de Under Attack modus uitschakelt, moet je er zeker van zijn dat doelgerichte WAF- en rate limiting-regels actief zijn.
• Verlaag het beveiligingsniveau naar een meer gebalanceerd niveau zoals Hoog of Medium.
• Test de site vanaf verschillende apparaten en monitor het aantal 5xx-fouten.
• Volg de logs gedurende 24 uur om te controleren of de aanval weer opstart.

Als goede praktijk moet er een gebeurtenisrapport na de aanval worden opgesteld. Dit rapport moet de begintijd van de aanval, doel-URL's, het maximum aantal verzoeken, genomen acties, effectiviteit van de regels en blijvende verbeteringen documenteren. Dit document kan de responstijd bij een volgende gebeurtenis aanzienlijk verkorten.

Veelvoorkomende fouten en dingen om te vermijden

Het is belangrijk om snel beslissingen te nemen tijdens een DDoS-aanval; echter, verkeerde instellingen kunnen ook echte gebruikers blokkeren. Hieronder staan enkele fouten die vooral onder hoge druk vaak voorkomen.

• Denken dat de Under Attack modus bescherming zal bieden zonder de DNS-records te proxieden.
• Het origin IP-adres blootstellen en de toegang van IP's buiten Cloudflare niet in de firewall blokkeren.
• Challenge toepassen op alle domeinen zonder te testen op API, webhook en betalingscallback-adressen.
• Te brede WAF-blokregels schrijven en daardoor echte klanten blokkeren.
• Agressief cachen van pagina's zoals winkelwagentjes, betalingen, of gebruikerspanelen waarbij caching niet is toegestaan.
• De modus weken open laten staan na de aanval.
• Beslissingen nemen enkel op basis van Cloudflare-schermen zonder serverlogs te bekijken.

Vooral in e-commerce kunnen blokkades van betalingscallbacks leiden tot aanzienlijke inkomstenverlies. Daarom is het veiliger om bij het schrijven van beveiligingsregels eerst een log- of managed challenge-actie te testen in plaats van meteen te blokkeren. Nadat het effect van de regel is vastgesteld, kan er overgegaan worden op strengere acties.

Hoe een robuuste verdediging opbouwen met Hostragons infrastructuur?

Cloudflare biedt een krachtige laag; echter, succesvolle DDoS-bescherming eindigt niet alleen bij de CDN. Hostinginfrastructuur, softwareoptimalisatie, SSL-configuratie, DNS-beheer en back-upstrategieën moeten gezamenlijk worden overwogen. De basisbenadering voor een site die op Hostragons is gehost, moet zijn: Cloudflare filtert het verkeer, de hostinglaag ontvangt alleen schoon verkeer, en de applicatie wordt geoptimaliseerd zodat deze geen onnodige belasting op de database produceert.

Voordat een nieuw project live wordt gezet, is het belangrijk dat de domeinnaam correct wordt beheerd met de juiste DNS-records, dat het SSL-certificaat probleemloos is geïnstalleerd, en dat de bronnen van de webserver zijn afgestemd op je verkeersprofiel. Op dit punt kunnen links naar Domeinsopzoeking en domeinregistratie, Web hosting pakketten, zakelijke hostingoplossingen en Gratis SSL certificaat nuttig zijn voor de gebruiker.

Voor projecten met veel verkeer of een hoog risico op aanvallen, kunnen meer gecontroleerde VPS- of beheerde serveropties in plaats van standaard gedeelde hosting worden overwogen. Dit maakt een flexibele configuratie van firewall, webserver, PHP-FPM, Redis, object cache, en database-instellingen mogelijk. Hoe dan ook, de Cloudflare Under Attack modus moet alleen worden geplaatst als noodhulpmiddel; de permanente beveiligingsarchitectuur moet worden ondersteund door WAF, loganalyse en regelmatige updates.

Snelle checklist: Eerste 15 minuten tijdens DDoS-aanval

Tijd is cruciaal tijdens een aanval. De onderstaande lijst schetst wat een technisch team of site-eigenaar in de eerste 15 minuten kan doen.

• Log in op het Cloudflare-dashboard en kies de juiste domeinnaam.
• Controleer of de DNS-records als geproxiërd worden weergegeven door de oranje wolk.
• Schakel de Under Attack modus in.
• Test de homepage, login, winkelwagentje, betaling en API-endpoints.
• Bepaal de doel-URL's vanuit het Cloudflare Security Events-scherm.
• Voeg specifieke WAF- of rate limiting-regels toe voor de meest aangevallen paden.
• Controleer de status van de server CPU, RAM, PHP-FPM, en MySQL.
• Test of er directe toegang tot het origin IP is.
• Controleer of er voor betalingsproviders, webhooks en cruciale integraties een allowlist vereist is.
• Documenteer alle acties met tijdstempels.

Als deze lijst regelmatig wordt geoefend, vermindert de paniek tijdens een echte aanval en verbetert de kwaliteit van de respons. Bij grotere sites is het aan te bevelen dat dit proces als een incidentresponsplan wordt gedocumenteerd.

Veelgestelde vragen

Beschermt de Cloudflare Under Attack modus de site volledig?

Nee. De Cloudflare Under Attack modus is vooral effectief in het verminderen van bot- en floodverkeer op HTTP/HTTPS-niveau; maar biedt op zich geen volledige bescherming. Het is belangrijk om de DNS-records geproxiërd te hebben, het origin IP te verbergen, en het moet samengebruikt worden met WAF-regels, rate limiting, caching en serverfirewall-instellingen.

Schaadt de Under Attack modus de SEO?

Korte termijn gebruik leidt doorgaans niet tot ernstige SEO-schade. Maar als de modus langdurig actief blijft, kan dit de efficiëntie van zoekmachinecrawling en de gebruikerservaring negatief beïnvloeden. Daarom is het gezonder om na de aanval de modus uit te schakelen en verder te gaan met gerichte beveiligingsregels.

Hoe lang moet de Under Attack modus ingeschakeld blijven?

De modus kan ingeschakeld blijven totdat de aanval verzwakt; in de praktijk wordt het aanbevolen om minstens 30-60 minuten monitoring te doen nadat het verkeer is genormaliseerd, gevolgd door een geleidelijke uitschakeling. Voordat de modus wordt uitgeschakeld, moeten permanente regels voor WAF en rate limiting aanwezig zijn.

Beïnvloedt de Under Attack modus API's of betalingssysteem?

Ja, dat kan het doen. Omdat sommige API-clients, webhookdiensten en betalingscallback-systemen de browsergebaseerde beveiligingsverificatie mogelijk niet kunnen voltooien. Daarom moeten cruciale endpoints worden getest, en indien nodig moeten er allowlists of speciale Cloudflare-regels worden gedefinieerd.

Is het noodzakelijk om extra voorzorgsmaatregelen te nemen aan de hostingzijde tijdens het gebruik van Cloudflare?

Ja. Cloudflare biedt sterke bescherming op de voorgrond; maar het origin IP-adres moet worden verborgen, de firewall moet alleen noodzakelijk verkeer toestaan, de software moet up-to-date zijn, en de cache-configuratie moet correct worden uitgevoerd. Een veilige hostinginfrastructuur is een belangrijk onderdeel van DDoS-bestendigheid.

Conclusie

De Cloudflare Under Attack modus is een effectief noodhulpmiddel dat snel verlichting kan brengen voor een site die onder DDoS-aanval staat. Wanneer het correct wordt ingeschakeld met de juiste DNS-proxy-instellingen, vermindert het botverkeer, verlaagt het de serverbelasting en verhoogt het de kans dat echte gebruikers de site kunnen bereiken. Voor het beste resultaat moet deze modus worden ondersteund door WAF-regels, rate limiting, cache-optimalisatie en beveiliging van de origin firewall.

Als je wilt dat jouw website bestand is tegen aanvallen, moet je regelmatig jouw infrastructuur, DNS-beheer en SSL-configuratie evalueren. Door de hosting-, domein- en SSL-oplossingen van Hostragons te verkennen, kun je een veiligere en duurzamere basis voor jouw site creëren.