Cloudflare Rate Limiting ile DDoS Koruması Nasıl Yapılır?

Bir sabah uyandığınızda sunucunuzun yanıt vermediğini, log dosyalarının gigabaytlarca şüpheli istekle dolup taştığını ve hosting faturanızın tavan yaptığını görmek… Bu senaryoyu yaşayan her sistem yöneticisi, bir daha aynı hataya düşmemek için elinden geleni yapar. DDoS saldırıları artık sadece büyük şirketlerin sorunu değil; küçük bir blog, bir e-ticaret sitesi, hatta kişisel portföy sayfası bile hedef alınabiliyor. İşte tam bu noktada Cloudflare Rate Limiting devreye giriyor ve hayat kurtarıcı bir kalkan görevi görüyor.

Cloudflare Rate Limiting Nedir ve Neden Önemlidir?

Rate limiting, kısaca belirli bir zaman diliminde bir IP adresinden veya kullanıcıdan gelebilecek istek sayısını sınırlandırmak demektir. Cloudflare bu mekanizmayı kendi edge ağı üzerinde çalıştırır; yani kötü niyetli trafik sunucunuza hiç ulaşmadan durdurulur. Bu, hem bant genişliğinizi korur hem de sunucu kaynaklarınızın gereksiz yere tüketilmesinin önüne geçer.

Cloudflare’in rate limiting özelliği birkaç farklı katmanda çalışır:

  • HTTP istek bazlı sınırlama: Belirli bir URL veya URL pattern’ine gelen istekleri sınırlar
  • IP tabanlı sınırlama: Aynı IP’den gelen aşırı istekleri engeller
  • Ülke veya ASN bazlı sınırlama: Belirli coğrafyalardan gelen trafiği filtreler
  • Kullanıcı ajanı bazlı sınırlama: Şüpheli bot imzalarını yakalar

Free plan kullanıcıları için Cloudflare, basit rate limiting kuralları sunarken Pro ve Business planlarında çok daha gelişmiş seçenekler mevcut. Özellikle Advanced Rate Limiting özelliği, istek gövdesini, başlıklarını ve çerezleri de analiz edebiliyor.

Temel Kavramlar ve Terminoloji

Cloudflare paneline girip kural yazmadan önce birkaç temel kavramı netleştirelim.

Threshold (Eşik): Belirlediğiniz zaman diliminde kaç isteğe izin vereceğiniz. Örneğin 60 saniyede 100 istek.

Period (Süre): İsteklerin sayıldığı zaman penceresi. Cloudflare bu değer için 10, 60 veya 600 saniyelik seçenekler sunar.

Action (Eylem): Eşik aşıldığında ne yapılacağı. Seçenekler şunlardır:

  • Block: İsteği doğrudan reddeder, 429 döner
  • Challenge: CAPTCHA veya JavaScript challenge sunar
  • Managed Challenge: Cloudflare’in kendi AI tabanlı challenge sistemi
  • Log: Sadece kayıt tutar, engelleme yapmaz (test aşaması için ideal)

Mitigation Timeout: Kural tetiklendikten sonra ne kadar süre boyunca kısıtlamanın devam edeceği.

Cloudflare Dashboard Üzerinden Rate Limiting Kuralı Oluşturma

Cloudflare paneline giriş yapın, alan adınızı seçin ve sol menüden Security > WAF > Rate Limiting Rules yolunu izleyin.

“Create rule” butonuna tıkladığınızda karşınıza bir kural oluşturma formu gelir. Bu formu doğru doldurmak kritik önem taşır.

Önce basit bir örnek yapalım: Login endpoint’inizi brute force saldırılarından koruyalım.

# Cloudflare API üzerinden rate limiting kuralı oluşturma
# Önce Zone ID'nizi öğrenin
curl -X GET "https://api.cloudflare.com/client/v4/zones" 
  -H "X-Auth-Email: [email protected]" 
  -H "X-Auth-Key: YOUR_API_KEY" 
  -H "Content-Type: application/json" | jq '.result[] | {name: .name, id: .id}'

Zone ID’nizi aldıktan sonra rate limiting kuralını API üzerinden de oluşturabilirsiniz:

# Login sayfası için rate limiting kuralı oluşturma
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/rate_limits" 
  -H "X-Auth-Email: [email protected]" 
  -H "X-Auth-Key: YOUR_API_KEY" 
  -H "Content-Type: application/json" 
  --data '{
    "description": "Login Brute Force Korumasi",
    "match": {
      "request": {
        "methods": ["POST"],
        "url_pattern": "*/login*"
      },
      "response": {
        "status": [200, 401, 403]
      }
    },
    "threshold": 5,
    "period": 60,
    "action": {
      "mode": "ban",
      "timeout": 600,
      "response": {
        "content_type": "application/json",
        "body": "{"error": "Cok fazla deneme. Lutfen 10 dakika sonra tekrar deneyin."}"
      }
    },
    "enabled": true
  }'

Bu kural şunu yapar: Bir IP adresi 60 saniye içinde /login endpoint’ine 5’ten fazla POST isteği gönderirse, 10 dakika boyunca engellenir ve özel bir hata mesajı görür.

Gerçek Dünya Senaryosu 1: E-Ticaret Sitesi Koruması

Bir e-ticaret müşterim vardı, ürün fiyatlarını rakipleri sürekli scrape ediyordu. Hem sunucuyu yoruyordu hem de iş açısından ciddi bir sorundu. Şöyle bir strateji uyguladık:

# Ürün sayfaları için agresif scraping koruması
# Cloudflare Ruleset Engine kullanarak

curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/rulesets/YOUR_RULESET_ID/rules" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "description": "Product Page Scraping Korumasi",
    "expression": "(http.request.uri.path matches "^/products/.*") and (not cf.client.bot)",
    "action": "block",
    "ratelimit": {
      "characteristics": ["ip.src", "http.request.headers["user-agent"]"],
      "period": 60,
      "requests_per_period": 30,
      "mitigation_timeout": 3600
    }
  }'

Bu kuralda dikkat çeken nokta characteristics alanı. Hem IP adresi hem de User-Agent birlikte değerlendiriliyor. Böylece tek bir IP’den farklı User-Agent’lar kullanılarak yapılan rotasyon saldırıları da yakalanıyor.

Aynı müşteri için API endpoint’lerine de ayrı bir kural koyduk:

# API endpoint koruması - authenticated kullanıcılar için daha yüksek limit
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/rulesets/YOUR_RULESET_ID/rules" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "description": "API Rate Limiting - Authenticated",
    "expression": "(http.request.uri.path matches "^/api/v1/.*") and (http.request.headers["Authorization"] ne "")",
    "action": "block",
    "ratelimit": {
      "characteristics": ["http.request.headers["Authorization"]"],
      "period": 60,
      "requests_per_period": 100,
      "mitigation_timeout": 60
    }
  }'

Authenticated kullanıcılar için Authorization header’ına göre sınırlama yapıyoruz, böylece aynı IP’den birden fazla kullanıcı bağlanıyorsa (şirket NAT’ı gibi durumlar) haksız engelleme olmuyor.

Gerçek Dünya Senaryosu 2: WordPress Sitesi DDoS Koruması

WordPress siteleri özellikle xmlrpc.php ve wp-login.php dosyaları üzerinden sürekli saldırı alır. Cloudflare ile bu noktaları kilitleyelim:

# WordPress özel koruma kuralları
# xmlrpc.php tamamen engelle
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/rulesets/YOUR_RULESET_ID/rules" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "description": "WordPress xmlrpc.php Engelleme",
    "expression": "(http.request.uri.path eq "/xmlrpc.php")",
    "action": "block"
  }'
# wp-admin için IP whitelist + rate limiting kombinasyonu
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/rulesets/YOUR_RULESET_ID/rules" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "description": "wp-admin Korumasi",
    "expression": "(http.request.uri.path matches "^/wp-admin/.*") and (not ip.src in {203.0.113.10 203.0.113.20})",
    "action": "managed_challenge",
    "ratelimit": {
      "characteristics": ["ip.src"],
      "period": 60,
      "requests_per_period": 10,
      "mitigation_timeout": 600
    }
  }'

Bu kural, güvenilir IP adresleriniz dışından wp-admin’e erişmeye çalışan herkese önce CAPTCHA challenge gönderir. Eğer 60 saniyede 10’dan fazla istek gelirse de engelleme devreye girer.

Terraform ile Infrastructure as Code Yaklaşımı

Cloudflare kurallarını elle yönetmek, ekip büyüdükçe kaosa dönüşebilir. Terraform kullanarak bu kuralları versiyon kontrolü altına almak çok daha sağlıklı bir yaklaşım:

# Önce Terraform Cloudflare provider kurulumu
# main.tf dosyası

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

resource "cloudflare_rate_limit" "login_protection" {
  zone_id   = var.zone_id
  threshold = 5
  period    = 60
  
  match {
    request {
      url_pattern = "${var.domain}/login*"
      schemes     = ["HTTP", "HTTPS"]
      methods     = ["POST"]
    }
    response {
      statuses       = [200, 401, 403]
      origin_traffic = true
    }
  }
  
  action {
    mode    = "ban"
    timeout = 600
    
    response {
      content_type = "application/json"
      body         = jsonencode({
        error   = "Rate limit asildi"
        message = "Cok fazla basarisiz giris denemesi"
        retry_after = 600
      })
    }
  }
  
  correlate {
    by = "nat"
  }
  
  disabled    = false
  description = "Login endpoint brute force korumasi"
}

Bu Terraform konfigürasyonunu Git reponuza ekleyip CI/CD pipeline’ınıza entegre edebilirsiniz. Böylece her kural değişikliği code review sürecinden geçer.

Rate Limiting Kurallarını Test Etme

Kural yazdınız, peki doğru çalışıyor mu? Test etmek için basit bir bash scripti:

#!/bin/bash
# rate_limit_test.sh
# Rate limiting kurallarini test etmek icin

TARGET_URL="https://siteniz.com/login"
REQUEST_COUNT=20
DELAY=0.5  # saniye

echo "Rate limiting testi basliyor..."
echo "Hedef: $TARGET_URL"
echo "Toplam istek: $REQUEST_COUNT"
echo "Gecikme: ${DELAY}s"
echo "---"

for i in $(seq 1 $REQUEST_COUNT); do
    RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" 
        -X POST 
        -H "Content-Type: application/json" 
        -d '{"username":"test","password":"wrongpassword"}' 
        "$TARGET_URL")
    
    TIMESTAMP=$(date '+%H:%M:%S')
    echo "[$TIMESTAMP] Istek $i: HTTP $RESPONSE"
    
    if [ "$RESPONSE" = "429" ]; then
        echo ">>> Rate limit tetiklendi! ($i. istekte)"
        break
    fi
    
    sleep $DELAY
done

echo "---"
echo "Test tamamlandi."

Bu scripti çalıştırıp kaçıncı istekte 429 aldığınızı kontrol edin. Belirlediğiniz eşikle örtüşüyorsa kural doğru çalışıyor demektir.

Cloudflare Analytics ile Rate Limiting İzleme

Kuralları koydunuz ama ne kadar etkin çalışıyor? Cloudflare’in Analytics API’sini kullanarak bu soruyu yanıtlayabilirsiniz:

# Rate limiting olaylarini GraphQL API ile sorgula
curl -X POST "https://api.cloudflare.com/client/v4/graphql" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "query": "
      query RateLimitingStats($zoneTag: String!, $since: Time!, $until: Time!) {
        viewer {
          zones(filter: {zoneTag: $zoneTag}) {
            httpRequestsAdaptiveGroups(
              filter: {
                datetime_geq: $since
                datetime_leq: $until
                edgeResponseStatus: 429
              }
              limit: 100
              orderBy: [count_DESC]
            ) {
              count
              dimensions {
                clientIP
                clientRequestHTTPHost
                clientRequestPath
                userAgent
              }
            }
          }
        }
      }
    ",
    "variables": {
      "zoneTag": "YOUR_ZONE_ID",
      "since": "2024-01-15T00:00:00Z",
      "until": "2024-01-15T23:59:59Z"
    }
  }' | jq '.data.viewer.zones[0].httpRequestsAdaptiveGroups'

Bu sorgu size hangi IP’lerin rate limit yedi, hangi path’lere saldırı geldi ve hangi user-agent’lar kullanıldı gibi değerli bilgileri getirir.

Yaygın Hatalar ve Nasıl Kaçınılır

Rate limiting kuralları yazarken en sık karşılaştığım hatalar şunlar:

Çok agresif eşikler belirlemek: Bir API’ye dakikada 5 istek limiti koyarsanız, meşru kullanıcılarınız da mağdur olur. Önce Cloudflare Analytics’e bakın, normal trafik örüntülerinizi anlayın, sonra sınır koyun.

Test etmeden production’a almak: Yukarıdaki test scriptini mutlaka kullanın. “Log” modunda birkaç gün çalıştırıp gerçek trafik verilerini görün.

Shared hosting ve NAT’ı göz ardı etmek: Eğer hedef kitleniz kurumsal kullanıcılardan oluşuyorsa, aynı IP’den onlarca kullanıcı bağlanıyor olabilir. Bu durumda IP bazlı sınırlama yerine session veya token bazlı sınırlama daha doğru olur.

Bypass yollarını kapatmamak: Rate limiting sadece Cloudflare üzerinden gelen trafik için geçerlidir. Eğer sunucunuzun gerçek IP’si sızdıysa, saldırgan Cloudflare’i bypass edebilir. iptables veya fail2ban ile sunucu tarafında da bir koruma katmanı ekleyin:

# Sunucu tarafında sadece Cloudflare IP'lerinden gelen trafiğe izin ver
# /etc/iptables/rules.v4 dosyasına ekleyin

# Cloudflare IPv4 adresleri (guncel listeyi https://www.cloudflare.com/ips adresinden alin)
iptables -A INPUT -p tcp --dport 80 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s 103.22.200.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 103.22.200.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s 141.101.64.0/18 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 141.101.64.0/18 -j ACCEPT
# Diger Cloudflare IP bloklari icin devam edin...

# Cloudflare'den gelmeyen HTTP/HTTPS trafiğini reddet
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

İleri Seviye: Bot Yönetimi ile Entegrasyon

Cloudflare’in Bot Management özelliği (Enterprise plan), rate limiting ile kombinlendiğinde çok güçlü bir kalkan oluşturur. Bot skoru 1 ile 99 arasında bir değer döner; düşük skor kötü bot anlamına gelir.

Firewall kurallarınızda bu skoru kullanabilirsiniz:

# Bot Management + Rate Limiting kombinasyonu
# Expression: Bot skoru 30'un altindaysa ve rate limit asilmissa engelle
# Bu kural Cloudflare dashboard Expression Builder'da yazilir:

# (cf.bot_management.score lt 30) and 
# (http.request.uri.path matches "^/api/") and
# (rate_limit.requests_per_period gt 50)

Bot Fight Mode özelliği (Pro plan dahil), bilinen kötü bot imzalarını otomatik olarak engeller. Bu özelliği aktif etmek için:

  • Dashboard > Security > Bots yolunu izleyin
  • “Bot Fight Mode” toggle’ını açın
  • “Super Bot Fight Mode” (Pro ve üzeri) seçeneğini değerlendirin

Olay Müdahalesi: Saldırı Altındayken Ne Yapmalı

Aktif bir DDoS saldırısı altındaysanız, hızlı hareket etmeniz gerekir. Şu adımları takip edin:

İlk olarak Cloudflare’i “Under Attack Mode” a alın. Bu mod, siteye gelen tüm ziyaretçilere otomatik olarak JavaScript challenge uygular ve botların büyük çoğunluğunu süzer. Dashboard > Overview sayfasından veya API ile yapabilirsiniz.

# Under Attack Mode'u API ile aktif et
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/settings/security_level" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{"value": "under_attack"}'

Saldırı yatıştıktan sonra güvenlik seviyesini normale alın:

# Güvenlik seviyesini normale döndür
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/settings/security_level" 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{"value": "medium"}'

Monitoring ve Alerting Kurulumu

Cloudflare Notifications özelliğini kullanarak rate limiting olayları için alert kurabilirsiniz:

  • Dashboard > Notifications > Add Notification
  • “Security” kategorisinden “HTTP DDoS Attack Alert” seçin
  • E-posta veya webhook (Slack, PagerDuty) hedefi belirleyin
  • Alert eşiklerini ayarlayın

Özellikle on-call rotasyonu olan ekipler için webhook entegrasyonu kritiktir. Gece 3’te bir DDoS saldırısı başladığında, Slack’e düşen bir alert hayat kurtarır.

Sonuç

Cloudflare rate limiting, doğru yapılandırıldığında gerçekten güçlü bir koruma katmanı sunar. Ancak “bir kural koy, unut” mantığıyla yaklaşmamak gerekiyor. Trafik örüntüleriniz değişir, yeni saldırı vektörleri ortaya çıkar, uygulamanız büyür; buna göre kurallarınızı da güncellemeniz şart.

Pratik önerim şu: Önce mevcut trafiğinizi analiz edin, sonra “Log” modunda kurallar yazın ve en az bir hafta izleyin. Gerçek verilere dayalı eşikler belirleyin, ardından “Block” veya “Challenge” moduna geçin. Terraform gibi IaC araçlarıyla kurallarınızı versiyon kontrolüne alın ve değişiklikleri code review süreciyle yönetin.

Rate limiting tek başına yeterli değil; WAF kuralları, bot yönetimi ve sunucu tarafı iptables korumasıyla birlikte katmanlı bir güvenlik mimarisi oluşturmanız gerekiyor. Cloudflare bu katmanların en önemli ilki, ama tek kalkan değil. Güvenlik her zaman derinlemesine savunma prensibiyle yaklaşılması gereken bir konu; ve bu prensibi benimsediğinizde, o sabah uyandığınızda sunucunuzun sapasağlam çalıştığını görme ihtimaliniz çok daha yüksek olur.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir