Hoe om Cloudflare se "Under Attack" Modus te gebruik tydens 'n DDoS-aanval op jou webwerf?

Cloudflare se Under Attack-modus is ’n noodverdediging-instelling wat besoekers ’n vinnige sekuriteitskontrole wys om botverkeer uit te filter tydens ’n DDoS-aanval op jou webwerf. Deur jou webwerf in die Cloudflare-paneel te kies en die Under Attack Mode onder die Sekuriteitsinstellings te aktiveer, kan jy binne ’n paar minute die oorweldigende HTTP/HTTPS-versoeke vertraag, regte gebruikers toegang tot jou webwerf bewaar en die las op jou bediener verminder. Hierdie modus is egter nie ’n permanente oplossing nie; dit moet saam met die regte DNS-proxy-instellings, WAF-reëls, tariefbeperkings, kaskonfigurasies en die sekuriteit van jou oorspronklike bediener gebruik word.

In hierdie gids gaan ons stap-vir-stap deur hoe om Cloudflare se Under Attack-modus te aktiveer, wanneer dit gebruik moet word, watter instellings dit moet ondersteun, en hoe om veilig terug te keer na normale bedryf nadat die aanval verby is. Die doel is om ’n toepaslike kontrolelys te bied wat jy tydens ’n krisis kan gebruik en om jou webwerf se beskikbaarheid so vinnig moontlik te herstel.

Wat is Cloudflare se Under Attack-modus?

Under Attack-modus is ’n noodsekuriteitsvlak wat deur Cloudflare aangebied word. Wanneer dit aktief is, dwing Cloudflare besoekers om ’n kort verifikasiestap op hul blaaier te voltooi. Hierdie verifikasie neem gewoonlik ’n paar sekondes en maak dit moeilik vir outomatiese bots, eenvoudige HTTP-flood-instrumente of kwaadwillige nie-blaaier kliënte om jou webwerf direk te oorlaai.

Die hoofdoel van hierdie modus is om laag 7-aanvalle (aansoeklaag) te verlig. Byvoorbeeld, as jou tuisblad duisende GET-versoeke per sekonde ontvang, of jou WordPress-aanmeldbladsy word getref deur intensiewe POST-versoeke, of jou soek- of winkelmandjiebladsy word met vals verkeer oorlaai, bied Under Attack-modus ’n vinnige eerste reaksie.

Belangrik om te verstaan is dat Under Attack-modus webversoeke filter; as jou bediener se IP-adres egter direk geteiken word, of ander dienste buite die Cloudflare-proxy oop is, of die aanval op laag 3 of 4 plaasvind, is ekstra maatreëls nodig. Daarom is dit krities dat jou DNS-rekords deur Cloudflare geproxied word, jou oorspronklike IP-adres weggesteek word, en dat jy sekuriteitsmaatreëls aan jou gasheerkant toepas. Vir ’n veiliger infrastruktuur kan jy kyk na Veilige webhosting dienste en SSL sertifika installasie artikels.

Watter tekens dui op ’n DDoS-aanval? Wat moet jy nagaan voordat jy Under Attack-modus aktiveer?

Nie alle stadiger laaitye is te wyte aan ’n DDoS-aanval nie. Soms kan ’n foutiewe inprop, databasisblokkasie, ’n cron-taak wat baie CPU gebruik, of ’n verkeerde kaskonfigurasie soortgelyke simptome veroorsaak. Dit is dus nuttig om ’n vinnige diagnose te doen voordat jy Under Attack-modus aanskakel. Maar as jou bediener traag reageer, gebruikers 502, 503, of 504-foute kry, en daar is ’n abnormale toename in versoeke in jou logboeke, behoort jy nie te huiwer om die noodmodus te aktiveer nie.

Tipiese DDoS-tekens

• Verkeer wat binne ’n kort tydperk 5, 10 of selfs 50 keer hoër is as normaal.
• Honderde versoeke per sekonde na ’n enkele bladsy of eindpunt.
• Verkeer van verskillende lande met soortgelyke gebruikersagent-waardes.
• Rigte op administrasie-, aanmeld-, soek- of winkelmandjie-URL’s in WordPress, WooCommerce, OpenCart, of eie sagteware.
• Bediener se CPU, RAM, PHP-FPM werkers of MySQL-verbindinge wat hul limiete bereik.
• Skielike styging in 4xx en 5xx foute in Cloudflare se analitiese paneel.
• Regte gebruikers het af en toe toegang, maar bots stuur voortdurend versoeke.

Byvoorbeeld, ’n e-handelswerf wat normaalweg 2 000 versoeke per minuut kry, maar binne 10 minute op 80 000 versoeke per minuut styg, waarvan 70% na die winkelmandjie of soekbladsy gaan, dui dit op ’n duidelike laag 7-aanval. In so ’n geval moet jy Under Attack-modus binne 5 minute aktiveer en dan spesifieke WAF- en tariefbeperkingsreëls vir die geteikende URL’s byvoeg.

Wanneer moet jy Cloudflare se Under Attack-modus gebruik?

Under Attack-modus is nie ’n standaard sekuriteitsinstelling wat permanent aangeskakel moet wees nie, omdat dit ’n kort wagskerm aan regte gebruikers wys. Dit kan veral ’n negatiewe invloed hê op bladsye wat op omskakeling fokus, betalingsprosesse of API-gebruikers. Die beste praktyk is om dit tydelik te gebruik tydens ’n aanval, en dit uit te skakel wanneer die verkeer weer normaal is.

Geskikte situasies om te gebruik

• As jou webwerf ’n abnormale hoog volume van HTTP/HTTPS versoeke ontvang.
• Bedienerhulpbronne vinnig uitgeput word en 502/503-foute toeneem.
• Cloudflare WAF nog nie met spesifieke reëls gekonfigureer is nie en ’n vinnige beskerming benodig word.
• Botverkeer oortref duidelik die ware gebruikersverkeer.
• Webblaaie, vorms, aanmeldskerms of soek-eindpunte word geteiken.

Situasies waar versigtigheid nodig is

• As mobiele toepassings, betalingsverskaffers, webhooks of API-verkeer intensief gebruik word.
• As soekenjin-bots kritiese bladsye deurkruis.
• As korporatiewe gebruikers ou blaaiers of beperkte netwerktoegang het.
• As daar subdomeine is wat nie deur Cloudflare se proxy beskerm word nie.

In gevalle waar API-verkeer betrokke is, kan die toepassing van Under Attack-modus op die hele domein sekere integrasies laat misluk. Daarom is dit beter om vir API-subdomeine spesifieke WAF-reëls, ’n witlys, of ’n ander sekuriteitsvlak te gebruik. Vir ’n diepgaande gids oor API-sekuriteit en tariefbeperking, sien Gids vir API-sekuriteit en koersbeperking.

Hoe om Cloudflare se Under Attack-modus te aktiveer: ’n stap-vir-stap gids

Hierdie stappe is ’n praktiese kontrolelys om vinnig op te tree tydens ’n aanval. Die Cloudflare-koppelvlak kan oor tyd effens verander, maar die beginsel bly dieselfde: kies jou domein, verhoog die sekuriteitsvlak, en laat Cloudflare die inkomende verkeer verifieer.

1. Meld aan by jou Cloudflare-rekening

Begin deur aan te meld by jou Cloudflare-rekening en kies die domein wat onder aanval is. As jy meerdere domeine bestuur, maak seker jy werk op die korrekte zone. Om Under Attack-modus op die verkeerde domein te aktiveer, mors tyd en laat die werklike aanval voortgaan.

2. Kontroleer dat DNS-rekords geproxied is

Vir Under Attack-modus om effektief te wees, moet webverkeer deur Cloudflare geproxied word. Maak seker dat jou A-, AAAA- en CNAME-rekords ’n oranje wolk-ikoon het (wat beteken dat hulle geproxied is). DNS-rekords met ’n grys wolk (DNS only) gaan nie deur Cloudflare se sekuriteitslaag nie. Veral jou www-domein, hoofdomein en subdomeine moet nagegaan word.

As jou oorspronklike IP-adres aanlyn sigbaar is, kan ’n aanvaller Cloudflare omseil en direk jou bediener aanval. Daarom is dit ’n sterk sekuriteitsmaatreël om jou bedienersekuriteitsmure slegs verkeer van Cloudflare se IP-reeks toe te laat. Jy kan ondersteuning van jou hostingverskaffer kry of kyk na die gids Hoe om Cloudflare DNS instellings te maak.

3. Aktiveer Under Attack Mode in die Sekuriteitsafdeling

Maak jou domein oop in die Cloudflare-paneel en gaan na die Security of Overview bladsy. Soek die opsie “Under Attack Mode” en skakel dit aan. In sommige koppelvlakke kan dit ook as “I am Under Attack” onder Security Level verskyn.

Die verandering tree gewoonlik vinnig in werking. Hou Cloudflare Analytics, Security Events en jou bediener se hulpbronverbruik in die oog gedurende die eerste paar minute. As CPU- en verbindingstellings begin afneem, werk die modus soos beplan. As foute steeds gebeur, moet jy addisionele reëls opstel.

4. Toets die gebruikerservaring

Na aktivering, toets die webwerf vanaf verskillende netwerke soos mobiele data, kantoor- of ’n ander plek indien moontlik. Kontroleer hoofblad, produkbladsye, aanmeldblad en betalingsproses. Sodra gebruikers die verifikasieskerm deurkom en by die webwerf uitkom, werk alles korrek. As gebruikers vasgevang raak in ’n eindelose verifikasie-lus, ondersoek koekie-instellings, blaaierkompatibiliteit of konflik met Cloudflare se sekuriteitsreëls.

5. Identifiseer die geteikende URL’s

Onder Attack-modus bied ’n algemene beskerming, maar die beste resultate word bereik deur spesifieke reëls vir geteikende URL’s te skep. Gebruik Cloudflare Security Events, Web Analytics, jou hosting toeganglogs en toepassingslogs om die mees geteikende roetes te bepaal, byvoorbeeld /wp-login.php, /xmlrpc.php, /search, /cart, /api/login of /checkout.

Wanneer die geteikende URL’s geïdentifiseer is, kan jy met WAF Custom Rules aksies stel op grond van land, gebruikersagent, versoekmetode, URI-pad of bot-telling. Byvoorbeeld, ’n IP wat te veel versoeke na ’n aanmeldpunt stuur, kan ’n “managed challenge” kry. Vir WordPress-webwerwe is WordPress Veiligheidsmaatreëls ’n natuurlike interne verwysing.

Verskille tussen Under Attack Mode en ander Cloudflare sekuriteitsopsies

Cloudflare bied ’n reeks sekuriteitsinstrumente vir verskillende doelwitte. Under Attack Mode is ’n vinnige en algemene noodfilter, terwyl WAF en Rate Limiting meer gefokusde, volhoubare en gebruikersvriendelike oplossings is.

Die praktiese verdedigingsbenadering werk so: Begin met Under Attack-modus om noodsaaklike druk te verminder, ontleed dan die aanvalspatrone, voeg WAF- en tariefbeperkingsreëls by, en versterk uiteindelik jou infrastruktuur met kas- en oorspronklike firewall-instellings.

Aanvullende Cloudflare-instellings om tydens ’n aanval te gebruik

Hoewel Under Attack-modus met ’n enkele klik geaktiveer kan word, hang die sukses van ’n DDoS-verdediging af van ondersteunende instellings. Die volgende wenke werk goed in praktyk.

Skep gefokusde beskerming met WAF-reëls

Met Cloudflare se WAF kan jy aksies neem op spesifieke toestande. Byvoorbeeld, slegs POST-versoeke na /wp-login.php van sekere lande kan ’n uitdaging kry. Dit is ’n manier om die aanval se fokusgebied te isoleer sonder om jou hele webwerf te vertraag.

• Maak administrasie- en aanmeldbladsye slegs toeganklik vir sekere lande of IP-reeks.
• Blokkeer onnodige eindpunte soos XML-RPC as jy dit nie gebruik nie.
• Pas beheerde uitdagings toe op verdagte gebruikersagent-waardes.
• Beperk kliënte wat te gereeld versoeke na sekere URI-paaie stuur met tariefbeperking.

Stel kasvlak korrek in

As jou oorspronklike bediener elke versoek moet hanteer, word hulpbronne vinnig uitgeput tydens ’n aanval. Statiese lêers soos beelde, CSS, JavaScript en kaskonfigurasies vir bladsye moet via Cloudflare se rand-bedieners bedien word. Vir dinamiese platforms soos WordPress kan jy bladsykaskoppelvlakke, Cloudflare se kasreëls en toepaslike kasbeheer-koppe saam gebruik.

Byvoorbeeld, ’n nuus- of blogwerf kan anonieme besoekers se bladsye vir 5 tot 30 minute kas. Dit verlaag selfs buite aanvalstye die tyd tot die eerste grepe (TTFB) en laat jou gasheer ontspan. Vir meer oor prestasie kan webwerf versnelling gids geraadpleeg word.

Stel realistiese tariefbeperking-drempels

Tariefbeperking werk veral goed op duur eindpunte, maar drempels moet realisties wees om regte gebruikers nie te belemmer nie. Byvoorbeeld, ’n produksoekbladsy kan ’n normale gebruiker toelaat om 5-15 soektogte per minuut te doen; 100 vrae per minuut is abnormaal. Op ’n aanmeldbladsy is 10 mislukte pogings in 5 minute verdag.

’n Praktiese voorbeeld: vir /wp-login.php kan ’n IP wat meer as 10 versoeke per minuut stuur ’n beheerde uitdaging kry, en ’n IP wat meer as 50 versoeke in 5 minute stuur kan tydelik geblokkeer word. Vir API-endpunte word meer sensitiewe drempels op gebruikersessies, IP’s, tokens en metodes aanbeveel.

Steek oorspronklike IP-adres weg en beperk firewall-toegang

’n Algemene fout by die gebruik van Cloudflare is om die oorspronklike IP-adres sigbaar te hou. Ou DNS-rekords, subdomeine wat direk na die IP wys, e-posdienste wat met webdienste gemeng is, of foutiewe konfigurasies kan veroorsaak dat ’n aanvaller om Cloudflare se beskerming kom en direk jou bediener aanval.

Op jou bediener moet poorte 80 en 443 slegs verkeer van Cloudflare se IP-reekse toelaat. Ander dienste soos SSH, beheerpanele, databasis en administrasie moet nie aan die internet blootgestel wees nie; gebruik IP-beperkings, sterk wagwoorde, 2FA en waar moontlik ’n VPN. Vir meer inligting oor hosting-sekuriteit, sien cPanel sekuriteitsinstellings en VPS firewall konfigurasie.

Spesiale oorwegings vir WordPress, WooCommerce en korporatiewe webwerwe

Nie alle webwerwe is dieselfde nie. ’n Blog, ’n WooCommerce-winkel en ’n SaaS-paneel kan verskillende effekte van Under Attack-modus hê. Dit is dus belangrik om kritiese roetes volgens jou webwerf-tipe te identifiseer.

WordPress-webwerwe

Die mees geteikende lêers is dikwels /wp-login.php en /xmlrpc.php. As jy nie XML-RPC gebruik nie, is dit veilig om dit te blokkeer. Jy kan lands- of IP-beperkings op jou adminpaneel toepas. Maak seker jou sekuriteitsinproppe en Cloudflare-reëls werk saam, anders kan gebruikers in ’n eindelose verifikasie-lus vasval.

WooCommerce-winkels

WooCommerce se mandjie-, betalings- en rekeningbladsye benodig besondere sorg. Omdat hierdie bladsye dinamies is, moet jy nie aggressiewe kasfunksies daarop toepas nie. Maak ook seker betalingsverskaffer se callback- of webhook-URL’s werk tydens Under Attack-modus. Indien nodig, voeg hul IP-reekse by ’n witlys of skep spesifieke reëls vir daardie eindpunte.

Korporatiewe en API-gebruikerswebwerwe

Korporatiewe portale, CRM-integrasies en mobiele API’s kan probleme hê met die JavaScript-verifikasie wat Under Attack-modus gebruik. In sulke gevalle is dit beter om die API-subdomein apart te bestuur met token-gebaseerde sekuriteit, tariefbeperking en witlyste. Byvoorbeeld, www.jouwdomein.com kan Under Attack wees, terwyl api.jouwdomein.com met ’n ander sekuriteitsvlak bestuur word.

Watter metrieke moet jy monitor nadat Under Attack-modus geaktiveer is?

Om te bepaal of ’n sekuriteitsmaatreël werk, moet jy data monitor. Dit is nie genoeg dat die webwerf laai nie; jy moet foute, bedienerlas en gebruikersgedrag saam oorweeg.

• Cloudflare Security Events: Wys hoeveel versoeke uitgedaag of geblokkeer is.
• HTTP-statuskodes: Monitor veranderings in 403, 429, 502, 503 en 504 foute.
• Bediener se CPU- en RAM-gebruik: ’n Afname word verwag na aktivering.
• PHP-FPM en MySQL-verbindinge: Wys verbetering in toepassingslaagprestasie.
• Bandwydte en versoekgetalle: Vergelyk totale verkeer met gefiltreerde versoeke.
• Werklike gebruikers se omskakelings: Toets vorms, bestellings, aanmelds en betalings.

Byvoorbeeld, as totale versoeke dieselfde bly, maar versoeke wat jou oorspronklike bediener bereik met 60% daal, beteken dit Cloudflare neem ’n groot las op. As MySQL-CPU steeds hoog bly, kan dit wees dat ’n spesifieke dinamiese navraag steeds ’n probleem veroorsaak. Ondersoek jou toepassingslogs in so ’n geval.

Hoe om Under Attack-modus veilig uit te skakel nadat die aanval verby is

Dit word nie aanbeveel om Under Attack-modus permanent aan te hou nie, want dit kan die gebruikerservaring benadeel en jou SEO beïnvloed. Die afskakelproses moet net so versigtig hanteer word soos die aktivering.

Stappe om veilig terug te keer na normale bedryf

• Wag ten minste 30-60 minute totdat die verkeer weer normaal is.
• Bevestig in Cloudflare Security Events dat die aantal uitdagings en blokkades afgeneem het.
• Maak seker dat WAF- en tariefbeperkingsreëls aktief is voordat jy Under Attack uitskakel.
• Stel jou sekuriteitsvlak terug na ’n meer gebalanseerde vlak soos High of Medium.
• Toets jou webwerf vanaf verskillende toestelle en hou 5xx-foute dop.
• Volg logboeke vir 24 uur om seker te maak die aanval is nie weer aan die gang nie.

Dit is ’n goeie praktyk om na ’n aanval ’n insidentverslag op te stel met die begin- en eindtyd van die aanval, geteikende URL’s, top versoekgetalle, toegepaste maatreëls, werkende reëls en permanente verbeterings. Hierdie dokument help om die reaksietyd by ’n toekomstige aanval te versnel.

Algemene foute om te vermy

In ’n stresvolle DDoS-situasie moet vinnige besluite geneem word, maar sommige foute kom dikwels voor:

• Dink dat Under Attack-modus beskerming bied sonder dat DNS-rekords geproxied is.
• Behou oorspronklike IP-adresse oop sonder firewall-beperkings tot Cloudflare IP’s.
• Pas Under Attack toe op die hele domein sonder om API’s, webhooks of betalingscallback-adresse te toets.
• Skryf te breë WAF-blokreëls wat regte kliënte blokkeer.
• Kas aggressief bladsye wat nie gekas moet word nie, soos mandjie-, betaling- of gebruikerspaneelbladsye.
• Los Under Attack-modus vir weke aan die gang nadat die aanval verby is.
• Baseer besluite net op Cloudflare-paneel sonder om bedienerlogboeke na te gaan.

Spesifiek vir e-handelswebwerwe kan die blokkering van betalingscallback-verkeer groot inkomsteverlies veroorsaak. Daarom is dit veiliger om eers ’n logmodus of beheerde uitdaging te gebruik voordat jy ’n blokkering toepas. Sodra jy die effek van ’n reël kan meet, kan jy strenger maatreëls instel.

Hoe om ’n sterker verdediging op Hostragons se infrastruktuur te bou

Cloudflare bied ’n sterk voorkomlaag, maar ’n suksesvolle DDoS-verdediging stop nie daar nie. Jou hosting-infrastruktuur, sagtewareoptimalisering, SSL-konfigurasie, DNS-bestuur en rugsteunstrategieë moet saamwerk. Op Hostragons word ’n ideale benadering soos volg beveel: Cloudflare filter die verkeer, jou hosting bedien slegs skoon verkeer, en jou toepassing is geoptimaliseer om onnodige databasislas te vermy.

Voordat ’n nuwe projek geloods word, maak seker jou domein word korrek bestuur met die regte DNS-rekords, jou SSL-sertifikaat is foutloos geïnstalleer, en jou webbediener se hulpbronne pas by jou verkeersprofiel. Vir hulp kan jy kyk na Domein navraag en domeinnaam registrasie, Web hosting pakkette, korporatiewe hostingoplossings, en Gratis SSL sertifika.

Vir projekte met hoë verkeer of ’n hoë aanvalrisiko word dit aanbeveel om eerder ’n VPS of bestuurde bediener as standaard gedeelde hosting te gebruik. Dit gee jou meer beheer oor firewall, webbediener, PHP-FPM, Redis, objekkas en databasisinstellings. Ongeag watter infrastruktuur jy kies, moet jy Cloudflare se Under Attack-modus slegs as ’n noodgeval-instrument beskou en jou permanente sekuriteitsargitektuur met WAF, loganalise en gereelde opdaterings versterk.

Vinnige kontrolelys: Wat om te doen in die eerste 15 minute van ’n DDoS-aanval

Tyd is kritiek tydens ’n aanval. Hierdie lys vat saam wat tegniese personeel of webwerf-eienaars binne die eerste 15 minute kan doen:

• Meld aan by Cloudflare en kies die regte domein.
• Kontroleer dat DNS-rekords die oranje wolk (proxied) het.
• Aktiveer Under Attack-modus.
• Toets hoofblad, aanmelding, mandjie, betaling en API-endpunte.
• Gebruik Cloudflare Security Events om geteikende URL’s te identifiseer.
• Voeg WAF- of tariefbeperkingsreëls by vir die mees geteikende roetes.
• Monitor bediener se CPU, RAM, PHP-FPM en MySQL-status.
• Toets of die oorspronklike IP direk toeganklik is.
• Kyk of betalingsverskaffers, webhooks en ander kritieke integrasies ’n witlys benodig.
• Neem tydstempels van al jou aksies.

Deur hierdie lys gereeld te oefen, sal paniek tydens ’n regte aanval verminder en jou reaksie verbeter. Vir groter webwerwe word dit aanbeveel om hierdie proses as deel van ’n formele insidentreaksieplan te dokumenteer.

Gereelde vrae

Beskermer Cloudflare se Under Attack-modus jou webwerf volledig?

Nee. Under Attack-modus is veral effektief om HTTP/HTTPS-bot- en vloedverkeer te verminder, maar dit bied nie volledige beskerming alleen nie. Dit moet saam met geproxiede DNS-rekords, ’n verskuilde oorspronklike IP, WAF-reëls, tariefbeperking, kas en bediener-firewall gebruik word.

Beïnvloed Under Attack-modus SEO?

Korttermyn gebruik veroorsaak gewoonlik nie ernstige SEO-probleme nie. As die modus egter lank geaktiveer bly, kan dit soekenjin-kruipers se toegang beperk en gebruikerservaring negatief beïnvloed. Daarom is dit beter om dit na ’n aanval af te skakel en eerder gefokusde sekuriteitsreëls te gebruik.

Hoe lank moet Under Attack-modus geaktiveer bly?

Hou dit aan totdat die aanval se intensiteit afneem; in praktyk moet jy minstens 30-60 minute na normalisering monitor voordat jy dit stelselmatig afskakel. Maak seker permanente reëls soos WAF en tariefbeperking is ingestel voordat jy die modus uitskakel.

Beïnvloed Under Attack-modus API’s of betalingsisteme?

Ja, dit kan ’n invloed hê, want sommige API-kliente, webhooks en betalingscallback-stelsels kan nie die blaaiergebaseerde sekuriteitsverifikasie voltooi nie. Dit beteken jy moet kritieke eindpunte toets en indien nodig witlyste of spesifieke Cloudflare-reëls opstel.

Is addisionele sekuriteitsmaatreëls by hosting nodig wanneer ek Cloudflare gebruik?

Ja. Cloudflare bied ’n sterk voorkomslaag, maar jou oorspronklike bediener se IP moet versteek wees, die firewall moet slegs nodige verkeer toelaat, sagteware moet op datum gehou word en kas moet korrek ingestel wees. Veilige hostinginfrastruktuur is ’n belangrike deel van jou DDoS-verdediging.

Gevolgtrekking

Cloudflare se Under Attack-modus is ’n effektiewe noodgeweer wat tydelike asemruimte bied tydens ’n DDoS-aanval op jou webwerf. Dit verminder botverkeer, verlig die las op jou bediener, en verhoog die kans dat regte gebruikers jou webwerf kan bereik wanneer dit korrek geaktiveer word met die regte DNS-proxy-instellings. Vir die beste resultate moet hierdie modus ondersteun word deur WAF-reëls, tariefbeperking, kasoptimalisering en oorspronklike firewall-sekuriteit.

As jy wil hê jou webwerf moet meer bestand wees teen aanvalle, maak seker jou infrastruktuur, DNS-bestuur en SSL-konfigurasie word gereeld nagegaan. Kies Hostragons se hosting, domein en SSL-oplossings om ’n veiliger en volhoubare basis vir jou projek te bou.