Website-ஐ DDoS-இலிருந்து பாதுகாக்க Cloudflare எப்படி configure செய்வது?

Question

IT Interview Practice · Accepted Answer

**Requests Cloudflare வழியாகச் சென்று, மீதமுள்ள traffic-ஐ application கையாள முடிந்தால் website-க்கு சிறந்த பாதுகாப்பு கிடைக்கும்.** ஒரு setting-ஐ இயக்குவது server-க்கான எல்லா வழிகளையும் பாதுகாக்காது.

ஒரு online shop-ஐக் கற்பனை செய்யுங்கள். Attackers product images-ஐ வெள்ளம்போல் கோரலாம், அதிகச் செலவுள்ள search endpoint-ஐத் திரும்ப அழைக்கலாம், அல்லது server-ஐ நேரடியாக அணுகலாம். இவை வெவ்வேறு வளங்களைப் பயன்படுத்துவதால் பல அடுக்குகள் தேவை.

## 1. Request பாதையில் Cloudflare-ஐ வைக்கவும்

Website-ன் ஆதரிக்கப்படும் DNS records-க்கு proxied status இயக்கவும். Website இயங்கும் உண்மையான server ஆன origin-க்கு முன் visitors Cloudflare-ஐ அடைவார்கள். DNS-only record பெயர் தீர்மானிப்பை மட்டும் வழங்கும்; website HTTP traffic-ஐ இந்தப் பாதுகாப்புப் பாதையில் அனுப்பாது.

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

இதுவே அடித்தளம்: Cloudflare-ஐ அடையும் requests-க்கு மட்டுமே அங்குள்ள filtering உதவும். Main domain மட்டும் அல்ல, API hostname உட்பட shop பயன்படுத்தும் ஒவ்வொரு public hostname-ஐயும் சரிபார்க்கவும்.

## 2. Origin-க்கான நேரடி வழியை மூடவும்

Attackers origin-ஐ நேரடியாக அடைய முடிந்தால் filtering-ஐத் தவிர்க்கலாம். Public web ingress-ஐ ஏற்ற Cloudflare IP ranges-க்கு மட்டும் அனுமதித்து அவற்றைப் புதுப்பிக்கவும். மாற்றாக Cloudflare Tunnel மதிப்பிடலாம்; அது வெளியே இணைந்து public inbound web ports தேவையை நீக்கலாம்.

Administrative access-ஐ தனிப் பாதுகாப்புப் பாதையில் வைத்து databases-ஐ public internet-இலிருந்து விலக்குங்கள். Cloudflare வழி normal access-யும் direct access மறுப்பையும் சோதியுங்கள். IP address-ஐ மறைப்பது மட்டும் போதாது. [Origin பாதுகாப்பு](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/) பார்க்கவும்.

## 3. உண்மையான வாடிக்கையாளர்களைக் காத்து attacks-ஐ வடிகட்டவும்

Managed DDoS protection மற்றும் உங்கள் plan controls-ஐ ஆய்வு செய்யுங்கள். ஏற்ற WAF rules சேர்க்கவும்: WAF HTTP requests-ஐ forward செய்யும்முன் சந்தேகமான patterns பார்க்கிறது. DDoS protection மற்றும் WAF rules தொடர்புடைய ஆனால் வேறுபட்ட பிரச்சினைகளைக் கையாளுகின்றன; ஏற்றுக்கொண்ட ஒவ்வொரு request-மும் application-க்கு மலிவானது என எதுவும் நிரூபிக்காது.

விளக்கக்கூடிய rules-இல் தொடங்கி பாதிக்கப்பட்ட traffic-ஐ ஆய்ந்து, legitimate customers block ஆனால் குறுகிய மாற்றம் செய்யுங்கள். Blocked-request எண்ணிக்கை அதிகமாக இருப்பதே success metric அல்ல. Cloudflare [DDoS setup மற்றும் tuning](https://developers.cloudflare.com/ddos-protection/get-started/) விளக்குகிறது.

## 4. அதிகச் செலவுள்ள operations-ஐத் தனியாகப் பாதுகாக்கவும்

Cache செய்யப்பட்ட image request, பல database records scan செய்யும் search-ஐவிட origin-க்கு பொதுவாக மலிவானது. சாதாரண பயன்பாடும் பின்னுள்ள service capacity-யும் அடிப்படையாகக் கொண்டு costly endpoints-க்கு rate limits அமைக்கவும்.

- Login அல்லது OTP delivery-க்கு edge limits-உடன் account அல்லது destination அடிப்படையிலான application limits சேர்க்கவும். ஒரே IP பல உண்மையான users-ஐக் குறிக்கலாம்.
- Search அல்லது report generation-இல் ஒவ்வொரு request தூண்டும் வேலையைக் கட்டுப்படுத்தவும்; request எண்ணிக்கையை மட்டும் குறைத்தாலும் costly requests அபாயமாக இருக்கலாம்.
- Authenticated APIs-க்கு network signals-உடன் customer அல்லது API key-யும் கவனிக்கவும். Distributed attackers பல IP addresses பயன்படுத்தலாம்.

அனைத்துக்கும் பொருந்தும் பாதுகாப்பான threshold இல்லை. Legitimate peaks கவனித்து limits-ஐ மெதுவாக அறிமுகப்படுத்துங்கள்; backend relief மற்றும் மறுக்கப்பட்ட valid requests இரண்டையும் அளவிடுங்கள்.

## 5. பகிர்வது பாதுகாப்பான இடங்களில் caching பயன்படுத்தவும்

Public images, static files cache செய்தால் repeated requests origin-ஐ அடையாமல் பதிலளிக்கலாம். Shop-இல் ஒரே product image-ஐ மீண்டும் மீண்டும் வழங்கும் வளச் செலவு குறையும்.

Personal carts, account pages-க்கு வேறு rules தேவை; users பிறரின் data பெறக்கூடாது. Dynamic responses cache செய்வதற்கு முன் cache keys மற்றும் bypass conditions பாருங்கள். Caching repeated work குறைக்கும்; load-இல் login அல்லது checkout-ஐ தானாகப் பாதுகாப்பாக்காது.

## 6. Recovery திட்டத்துடன் அவசர challenges பயன்படுத்தவும்

Incident நேரத்தில் Under Attack mode browser challenge வழங்கலாம். பாதிக்கப்பட்ட browser routes-க்கு மதிப்பிட்டு, தேவையானபோது தற்காலிக நடவடிக்கையை அகற்றுங்கள். Machine clients, payment webhooks browser challenges முடிக்காமல் இருக்கலாம்; அவற்றின் routes-க்கு ஏற்ற authentication மற்றும் targeted controls தேவை.

இறுதியாக origin latency, CPU, database pressure, errors கண்காணித்தபடி உண்மையான customers browse செய்து checkout முடிக்கிறார்களா என உறுதிசெய்யவும். Direct network attack origin connection-ஐ நிரப்பினால் hosting provider-உடன் upstream protection ஒருங்கிணைக்கவும். நோக்கம் பயனுள்ள service தொடர்வது; எந்த attack-மும் disruption ஏற்படுத்தாது என்ற வாக்குறுதி அல்ல.

1. Request பாதையில் Cloudflare-ஐ வைக்கவும்

2. Origin-க்கான நேரடி வழியை மூடவும்

3. உண்மையான வாடிக்கையாளர்களைக் காத்து attacks-ஐ வடிகட்டவும்

4. அதிகச் செலவுள்ள operations-ஐத் தனியாகப் பாதுகாக்கவும்

5. பகிர்வது பாதுகாப்பான இடங்களில் caching பயன்படுத்தவும்

6. Recovery திட்டத்துடன் அவசர challenges பயன்படுத்தவும்

தொடர்புடைய கேள்விகள்