Hoe configureer je Cloudflare om een website tegen DDoS te beschermen?

Question

IT Interview Practice · Accepted Answer

**Cloudflare beschermt een website het best als verzoeken erdoorheen gaan en de applicatie het resterende verkeer aankan.** Eén instelling inschakelen beschermt niet iedere route naar je server.

Stel je een webwinkel voor. Aanvallers kunnen productafbeeldingen overspoelen, herhaaldelijk een duur zoekendpoint aanroepen of rechtstreeks de server benaderen. Dit belast verschillende middelen, dus de inrichting vereist meerdere lagen.

## 1. Plaats Cloudflare in het verzoekpad

Schakel proxied in voor ondersteunde DNS-records van de website. Bezoekers bereiken dan Cloudflare vóór de origin: de server die de website daadwerkelijk draait. Een DNS-only-record verzorgt naamomzetting; het stuurt HTTP-verkeer niet door deze beschermingsroute.

```text
Browser -> Cloudflare -> Origin -> Database
```

Dit is de basis: filtering bij Cloudflare helpt alleen voor verzoeken die daar aankomen. Controleer elke publieke hostnaam van de winkel, inclusief de API-hostnaam, niet alleen het hoofddomein.

## 2. Sluit de rechtstreekse route naar de origin

Als aanvallers de origin nog rechtstreeks bereiken, kunnen ze de filters omzeilen. Beperk publieke inkomende webverbindingen tot de juiste Cloudflare-IP-bereiken en houd deze actueel. Beoordeel als alternatief Cloudflare Tunnel: die maakt een uitgaande verbinding en kan publieke inkomende webpoorten overbodig maken.

Houd beheertoegang op een aparte beveiligde route en databases van het publieke internet. Test normale toegang via Cloudflare én weigering van directe toegang. Alleen een IP-adres verbergen is onvoldoende. Zie [originbescherming](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/).

## 3. Filter aanvallen zonder echte klanten te verliezen

Bekijk beheerde DDoS-bescherming en de mogelijkheden van je abonnement. Voeg passende WAF-regels toe: een WAF controleert HTTP-verzoeken op verdachte patronen voordat ze worden doorgestuurd. DDoS-bescherming en WAF-regels behandelen overlappende maar verschillende problemen; geen van beide bewijst dat elk geaccepteerd verzoek goedkoop is voor je applicatie.

Begin met uitlegbare regels, inspecteer getroffen verkeer en pas gericht aan als legitieme klanten worden geblokkeerd. Veel geblokkeerde verzoeken vormen op zichzelf geen succesmaatstaf. Cloudflare beschrijft de [DDoS-inrichting en afstemming](https://developers.cloudflare.com/ddos-protection/get-started/).

## 4. Bescherm dure bewerkingen afzonderlijk

Een gecachte afbeelding opvragen is meestal veel goedkoper voor de origin dan een zoekopdracht die veel databaserecords scant. Stel snelheidslimieten in voor dure endpoints op basis van normaal gebruik en de capaciteit van de achterliggende dienst.

- Combineer bij login of OTP-verzending randlimieten met applicatielimieten per account of bestemming. Eén IP kan veel echte gebruikers vertegenwoordigen.
- Begrens bij zoeken of rapportgeneratie het werk dat één verzoek kan starten; alleen aantallen beperken kan dure verzoeken gevaarlijk laten blijven.
- Kijk bij geauthenticeerde API’s naast netwerksignalen ook naar klant of API-sleutel. Verspreide aanvallers kunnen veel IP-adressen gebruiken.

Er is geen universeel veilige drempel. Observeer legitieme pieken, voer limieten voorzichtig in en meet zowel backendontlasting als geweigerde geldige verzoeken.

## 5. Cache waar delen veilig is

Cache publieke afbeeldingen en statische bestanden zodat herhaalde verzoeken zonder de origin worden afgehandeld. Voor onze winkel vermindert dit het herhaald versturen van dezelfde productafbeelding.

Persoonlijke winkelwagens en accountpagina’s vragen andere regels: gebruikers mogen nooit gegevens van iemand anders krijgen. Controleer cachesleutels en bypassvoorwaarden voordat je dynamische antwoorden cachet. Caching vermindert herhaling; het maakt login of checkout niet automatisch veilig onder belasting.

## 6. Gebruik noodchallenges met een herstelplan

Under Attack mode kan tijdens een incident een browserchallenge invoeren. Beoordeel dit voor getroffen browserroutes en verwijder de tijdelijke maatregel zodra dat passend is. Machineclients en betaalwebhooks kunnen browserchallenges mogelijk niet voltooien; hun routes vragen geschikte authenticatie en gerichte controles.

Controleer tot slot of echte klanten kunnen browsen en afrekenen terwijl je originlatentie, CPU, databasedruk en fouten bewaakt. Verzadigt een directe netwerkaanval de originverbinding, stem dan upstreambescherming af met de hostingprovider. Het doel is bruikbare dienstverlening voortzetten, niet beloven dat geen enkele aanval verstoring kan veroorzaken.

1. Plaats Cloudflare in het verzoekpad

2. Sluit de rechtstreekse route naar de origin

3. Filter aanvallen zonder echte klanten te verliezen

4. Bescherm dure bewerkingen afzonderlijk

5. Cache waar delen veilig is

6. Gebruik noodchallenges met een herstelplan

Gerelateerde vragen