Miten määrität Cloudflaren suojaamaan sivustoa DDoS-hyökkäyksiltä?

Question

IT Interview Practice · Accepted Answer

**Cloudflare suojaa parhaiten, kun pyynnöt kulkevat sen kautta ja sovellus kestää jäljelle jäävän kuorman.** Yksi asetus ei suojaa kaikkia reittejä palvelimeen.

Verkkokauppaan voidaan hyökätä tuotekuvilla, raskailla hauilla tai suoralla palvelinyhteydellä. Eri resurssit kuormittuvat, joten tarvitaan useita kerroksia.

## 1. Aseta Cloudflare pyyntöpolulle

Ota proxied käyttöön tuetuissa DNS-tietueissa. Vierailija saapuu ensin Cloudflareen ja sitten originiin eli varsinaiseen palvelimeen. DNS-only ratkaisee nimen, mutta ei ohjaa HTTP:tä tähän suojaan.

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

Tämä on perusta: vain Cloudflareen saapuva liikenne voidaan suodattaa siellä. Tarkista kaikki julkiset nimet, myös API, älä pelkkää päädomainia.

## 2. Sulje suora origin-reitti

Suoraan saavutettava origin ohittaa suodatuksen. Rajoita julkinen web-sisääntulo oikeisiin päivitettyihin Cloudflare-IP-alueisiin. Vaihtoehtoinen Tunnel muodostaa ulospäin yhteyden ja voi poistaa julkisten sisääntuloporttien tarpeen.

Pidä hallinta erikseen suojattuna ja tietokannat pois julkisesta verkosta. Testaa normaali Cloudflare-reitti ja suoran pääsyn torjunta. IP:n piilotus ei riitä. Katso [originin suojaus](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/).

## 3. Suodata hyökkäykset säilyttäen asiakkaat

Tarkista hallittu DDoS-suoja ja oman tilauksen mahdollisuudet. Lisää sopiva WAF: se tutkii HTTP-pyyntöjen epäilyttävät kuviot ennen välitystä. DDoS ja WAF ratkaisevat osittain yhteisiä mutta eri ongelmia; kumpikaan ei todista kaikkia hyväksyttyjä pyyntöjä halvoiksi.

Aloita perusteltavista säännöistä, tutki liikenne ja korjaa virhe-estot tarkasti. Suuri estomäärä ei yksin osoita onnistumista. Katso [DDoS-asennus ja säätö](https://developers.cloudflare.com/ddos-protection/get-started/).

## 4. Suojaa kalliit toimet erikseen

Cachesta saatu kuva on yleensä originille halvempi kuin laaja tietokantahaku. Rajaa raskaita päätepisteitä normaalikäytön ja taustapalvelun kapasiteetin mukaan.

- Yhdistä login- ja OTP-reunarajat sovelluksen tili- tai kohderajoihin. Yksi IP voi edustaa useita käyttäjiä.
- Rajaa haun ja raportin työmäärä per pyyntö; määrärajat eivät estä kaikkia raskaita pyyntöjä.
- Huomioi tunnistetuissa API-kutsuissa asiakas tai API-avain verkkosignaalien lisäksi. Hyökkääjällä voi olla monta IP:tä.

Yleistä turvallista rajaa ei ole. Seuraa laillisia huippuja, ota rajat varovasti käyttöön ja mittaa helpotus sekä oikeiden pyyntöjen hylkäykset.

## 5. Cacheta turvallisesti jaettava sisältö

Cacheta julkiset kuvat ja staattiset tiedostot, jotta toistot eivät mene originiin. Kaupassa säästyy saman kuvan jatkuva tarjoilu.

Henkilökohtaiset korit ja tilisivut tarvitsevat eri säännöt, ettei tietoja vuoda käyttäjien välillä. Tarkista avaimet ja ohitukset ennen dynaamista cachea. Se vähentää toistoa, ei automaattisesti suojaa loginia tai checkoutia kuormalta.

## 6. Käytä hätähaasteita palautussuunnitelmalla

Under Attack voi lisätä selaintarkistuksen häiriössä. Arvioi sitä tarvittaville selainreiteille ja poista tilapäinen suoja sopivasti. Koneasiakkaat ja maksuwebhookit eivät ehkä läpäise haastetta, joten ne tarvitsevat oikean tunnistuksen ja kohdistetut säännöt.

Varmista lopuksi oikeat selaukset ja ostokset sekä seuraa originviivettä, CPU:ta, kantapainetta ja virheitä. Suoran verkkohyökkäyksen tukkiessa yhteyden sovi suojaus ennen sitä hostingtoimittajan kanssa. Tavoite on hyödyllinen jatkuva palvelu, ei lupaus täydellisestä häiriöttömyydestä.

1. Aseta Cloudflare pyyntöpolulle

2. Sulje suora origin-reitti

3. Suodata hyökkäykset säilyttäen asiakkaat

4. Suojaa kalliit toimet erikseen

5. Cacheta turvallisesti jaettava sisältö

6. Käytä hätähaasteita palautussuunnitelmalla

Aiheeseen liittyvät kysymykset