Hvordan konfigureres Cloudflare til DDoS-beskyttelse af et websted?

Question

IT Interview Practice · Accepted Answer

**Cloudflare beskytter bedst, når anmodninger passerer tjenesten, og applikationen kan klare den resterende trafik.** Én aktiveret indstilling beskytter ikke alle veje til serveren.

Forestil dig en webshop. Angribere kan oversvømme produktbilleder, gentage en dyr søgning eller kontakte serveren direkte. Det bruger forskellige ressourcer, så opsætningen skal have flere lag.

## 1. Placér Cloudflare i anmodningens vej

Aktivér proxied for websitets understøttede DNS-poster. Besøgende når så Cloudflare før origin, serveren som faktisk kører websitet. En DNS-only-post oversætter navnet, men sender ikke HTTP-trafikken gennem denne beskyttelse.

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

Det er fundamentet: filtrering hos Cloudflare hjælper kun for trafik, der når dertil. Kontrollér alle offentlige værtsnavne, også API-navnet, frem for blot hoveddomænet.

## 2. Luk den direkte vej til origin

Hvis angribere stadig kan kontakte origin direkte, kan de omgå filtreringen. Begræns offentlig indgående webtrafik til relevante Cloudflare-IP-områder, og hold dem opdateret. Overvej alternativt Cloudflare Tunnel, som forbinder udad og kan fjerne behovet for offentlige indgående webporte.

Hold administration på en separat beskyttet vej og databaser væk fra det offentlige internet. Test normal adgang gennem Cloudflare og afvisning af direkte adgang. Det er ikke nok blot at skjule IP-adressen. Se [origin-beskyttelse](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/).

## 3. Filtrér angreb, men bevar rigtige kunder

Gennemgå administreret DDoS-beskyttelse og mulighederne i dit abonnement. Tilføj passende WAF-regler: en WAF undersøger HTTP-anmodninger for mistænkelige mønstre før videresendelse. DDoS-beskyttelse og WAF løser overlappende, men forskellige problemer; ingen af dem beviser, at en accepteret anmodning er billig for applikationen.

Start med forklarlige regler, undersøg den berørte trafik, og justér snævert ved blokering af legitime kunder. Mange blokerede anmodninger er ikke alene et succesmål. Cloudflare beskriver [DDoS-opsætning og justering](https://developers.cloudflare.com/ddos-protection/get-started/).

## 4. Beskyt dyre operationer separat

Et cachet billede er normalt langt billigere for origin end en søgning gennem mange databaseposter. Begræns frekvensen på dyre endpoints efter normal brug og kapaciteten bag dem.

- Ved login og OTP skal edge-grænser kombineres med applikationsgrænser pr. konto eller destination. Én IP kan repræsentere mange rigtige brugere.
- Ved søgning og rapporter skal arbejdet pr. anmodning begrænses; et rent antal-loft kan stadig tillade farligt dyre anmodninger.
- Ved autentificerede API'er bør kunde eller API key indgå sammen med netværkssignaler. Distribuerede angribere kan have mange IP'er.

Der findes ingen universel sikker tærskel. Observer legitime spidsbelastninger, indfør grænser forsigtigt, og mål både backend-aflastning og afviste gyldige anmodninger.

## 5. Brug cache, hvor deling er sikker

Cache offentlige billeder og statiske filer, så gentagne anmodninger kan besvares uden origin. I webshoppen sparer det gentagen servering af samme produktbillede.

Personlige kurve og kontosider kræver andre regler, fordi brugere ikke må modtage andres data. Kontrollér cachenøgler og bypass-betingelser før dynamisk caching. Cache reducerer gentaget arbejde, men gør ikke automatisk login og checkout sikre under belastning.

## 6. Brug nødudfordringer med en genopretningsplan

Under Attack-tilstand kan indføre en browserkontrol under et angreb. Vurdér den for berørte browserruter, og fjern den midlertidige foranstaltning, når det er passende. Maskinklienter og betalingswebhooks kan muligvis ikke gennemføre browserkontroller, så deres ruter behøver egnet autentificering og målrettede regler.

Bekræft til sidst, at rigtige kunder kan gennemse varer og betale, mens du måler origin-latens, CPU, databasepres og fejl. Hvis et direkte netværksangreb fylder origins forbindelse, så koordinér upstream-beskyttelse med hostingudbyderen. Målet er fortsat nyttig service, ikke et løfte om, at intet angreb kan skabe forstyrrelser.

1. Placér Cloudflare i anmodningens vej

2. Luk den direkte vej til origin

3. Filtrér angreb, men bevar rigtige kunder

4. Beskyt dyre operationer separat

5. Brug cache, hvor deling er sikker

6. Brug nødudfordringer med en genopretningsplan

Relaterede spørgsmål