İçindekiler
- 1 Küçük ve Orta Ölçekli Siteler İçin DDoS Neden Ciddi Bir Risk?
- 2 DDoS Saldırı Türlerini Kısa ve Net Anlamak
- 3 Neden Çok Katmanlı DDoS Koruma Şart?
- 4 Cloudflare Katmanında Uygulanabilir Ayarlar
- 5 Rate Limit Stratejileri: Cloudflare + Sunucu El Ele
- 6 Sunucu ve İşletim Sistemi Ayarlarıyla Dayanıklılığı Artırmak
- 7 Olay Anında Yol Haritası: DDoS Saldırısı Sırasında Ne Yapmalı?
- 8 DCHost Altyapısında Örnek Mimari Önerileri
- 9 Sonuç: DDoS Korkusunu Yönetilebilir Bir Risk Hâline Getirmek
Küçük ve Orta Ölçekli Siteler İçin DDoS Neden Ciddi Bir Risk?
Küçük ve orta ölçekli sitelerin büyük markalara göre daha az hedef olacağı düşüncesi artık gerçekçi değil. E-ticaret siteleri, ajans portalları, SaaS panelleri, hatta basit kurumsal siteler bile; rekabet, politik motivasyonlar, otomatik bot ağları veya basit “eğlence” amaçlı saldırıların hedefi hâline gelebiliyor. Kapasite analizi veya mimari tasarım toplantılarında en çok konuştuğumuz konulardan biri, sınırlı bütçeyle DDoS riskini nasıl yönetilebilir seviyeye indireceğiniz oluyor.
İyi haber şu: Küçük ve orta ölçekli bir site için milyonlarca liralık güvenlik yatırımı gerekmiyor. Doğru CDN/DNS katmanı (örneğin Cloudflare), akıllı rate limit politikaları ve birkaç kritik sunucu ayarı ile saldırıların büyük çoğunluğunu etkisiz hâle getirmek mümkün. Üstelik bunların önemli bir kısmı, doğru kurgulandığında sitenin performansını da iyileştiriyor. Bu yazıda, DCHost ekibi olarak pratikte uyguladığımız DDoS koruma stratejilerini; Cloudflare ayarları, rate limit yaklaşımları ve sunucu tarafı optimizasyonları üzerinden adım adım anlatacağız.
DDoS kavramına tamamen yabancıysanız önce DDoS nedir ve temel korunma yöntemleri yazısına göz atmanız faydalı olur. Burada ise doğrudan uygulanabilir mimari ve ayarlara odaklanacağız.
DDoS Saldırı Türlerini Kısa ve Net Anlamak
Etkin bir savunma için önce neye karşı mücadele ettiğimizi bilmemiz gerekiyor. Küçük ve orta ölçekli siteleri en çok etkileyen 3 temel DDoS kategorisi var:
L3/L4 Saldırıları: Bant Genişliği ve TCP/UDP Taşkını
Bu tür saldırılarda amaç, doğrudan ağ katmanını ve işletim sisteminin TCP/UDP yığınını boğmak:
- Gigabit’lerce UDP veya TCP SYN paketi gönderilir.
- Hedef; router, firewall veya sunucunun network stack’ini kilitlemektir.
- Çoğu zaman uygulama loglarında anlamlı bir şey göremezsiniz; çünkü trafik, web sunucusuna bile ulaşmadan ağ katmanında boğar.
Küçük sitelerin bu tür saldırılara doğrudan, tek bir VPS veya dedicated sunucu ile dayanması neredeyse imkânsızdır. Bu yüzden ön hatta bir CDN/proxy (Cloudflare) koymak neredeyse zorunludur.
L7 (Uygulama Katmanı) Saldırıları: WordPress, API ve Arama Sayfaları
Uygulama katmanı DDoS’ta saldırgan, normal istekleri taklit eder:
- WordPress’te
/wp-login.phpveya ağır sorgular içeren arama/filtreleme sayfaları hedeflenir. - API uç noktalarına saniyede onlarca/yüzlerce istek atılır.
- Sunucunun CPU, RAM veya veritabanı kaynakları tüketilir.
Bu saldırıların tespiti zordur çünkü istekler “normal HTTP trafiği” gibi görünür. Burada Cloudflare WAF kuralları, rate limit politikaları ve web sunucusu (Nginx/Apache) seviyesinde ek limitler kritik rol oynar.
Hedefli mi, Otomatik mi?
Küçük sitelerin önemli kısmı, aslında tamamen hedefli saldırı almıyor; çoğu, internette IP tarayan bot ağlarının “rastgele” saldırı dalgalarına maruz kalıyor. Bu iyi bir haber, çünkü iyi yapılandırılmış temel savunma bu dalgaların büyük bölümünü süpürmeye yetiyor. Yani hedefiniz ilk aşamada “kurumsal seviyede DDoS koruması” değil, sağlam bir temel barikat kurmak olmalı.
Neden Çok Katmanlı DDoS Koruma Şart?
DDoS savunmasını tek bir ürün veya tek bir ayara emanet etmek risklidir. Sağlam bir mimari en az üç katman içerir:
- Ön Hat (Cloudflare gibi ters proxy/CDN): L3/L4 trafiği ve kaba L7 saldırılar burada süzülür.
- Uygulama Katmanı (WAF + Rate Limit): Spesifik URL’lere veya pattern’lere gelen saldırılar burada kesilir.
- Sunucu ve OS Katmanı: TCP stack ayarları, firewall, web sunucusu ve PHP-FPM limitleri, saldırı atlatırsa son savunmayı oluşturur.
DCHost tarafında da küçük bir WordPress blog ile yoğun sipariş alan bir WooCommerce mağazasına aynı şablonu önermiyoruz. Ancak katmanlı koruma prensibi her ölçekte aynı: Trafiği dışarıda durdur, uygulamayı koru, sunucuyu boğulmadan yönet.
Cloudflare Katmanında Uygulanabilir Ayarlar
Birçok küçük/orta ölçekli site için ilk ve en etkili adım, DNS’i Cloudflare’e taşıyıp trafiği proxy’den geçirmek oluyor. Ancak sadece “turuncu bulut” açmak yetmez; birkaç önemli ayarı netleştirelim.
1. DNS ve Proxy Yapılandırması
- Site için kullandığınız
AveyaAAAAkayıtlarının proxied (turuncu bulut) olduğundan emin olun. - Gerçek sunucu IP’nizi sadece gerekli servisler (örn. SMTP) için açık bırakın; web trafiğini her zaman proxy üzerinden geçirin.
- Mümkünse yönetim paneline (örn.
panel.ornek.com) ayrı subdomain açıp proxy kapalı (gri bulut) ama IP erişimini firewalld/iptables ile IP kısıtlamalı yönetin.
Cloudflare DNS ve hosting DNS tercihleri arasında kararsızsanız, en doğru nameserver stratejisini anlattığımız rehbere göz atabilirsiniz.
2. Security Level ve Temel Koruma Modları
Cloudflare Security Level ayarı, hangi visitor profiline ne kadar katı davranacağını belirler:
- Medium: Çoğu küçük site için dengeli bir varsayılan seviyedir.
- High / Under Attack: Devam eden bir saldırı veya çok yoğun bot trafiği olduğunda geçici olarak kullanılır.
Önerimiz, normal zamanda Medium veya sitenizin doğasına göre High kullanmanız; saldırı anında ise kısa süreliğine Under Attack Mode aktif etmeniz. Bu mod, yeni gelen ziyaretçilere JavaScript tabanlı bir doğrulama sayfası gösterir ve kaba botları epey temizler.
3. WAF ve Bot Koruması
Eğer planınız destekliyorsa Cloudflare WAF kurallarını aktif etmek, L7 DDoS ve kötü amaçlı botlara karşı ciddi avantaj sağlar:
- WordPress kurulumları için
/wp-login.phpve/xmlrpc.phpadreslerine özel kurallar oluşturun. - Ödeme, sepet ve kritik API yollarını daha sıkı kurallarla koruyun.
- Ülke bazlı (country-based) bloklama veya kısıtlama gerekirse WAF üzerinden uygulayın.
Cloudflare tarafındaki WAF ve bot ayarlarını detaylı ele aldığımız Cloudflare güvenlik ayarları rehberi ile bu bölümdeki adımları daha da derinleştirebilirsiniz.
4. Önbellekleme (Cache) ve Edge Seviyesinde Hafifletme
İyi yapılandırılmış bir önbellek politikası, DDoS sırasında da hayat kurtarır:
- Statik içerikleri (CSS, JS, görseller) uzun süreli cache’leyin.
- WordPress gibi sitelerde statik sayfalar için cache süresini artırarak origin üzerindeki yükü düşürün.
- “Cache Everything” kuralını sadece giriş yapılmayan, tamamen statik sayfalar için uygulayın; admin, sepet, ödeme sayfaları gibi kişisel alanları hariç tutun.
Cloudflare önbellekleme, site hızınızı iyileştirirken DDoS sırasında sunucuya gelen gerçek istek sayısını dramatik biçimde azaltır. Bu da rate limit ve sunucu ayarlarının işini kolaylaştırır.
Rate Limit Stratejileri: Cloudflare + Sunucu El Ele
DDoS saldırılarında sadece “toplam trafik” değil, bir IP’nin belirli bir endpoint’e kaç istekte bulunduğu da önemli bir göstergedir. İşte burada rate limit devreye girer. Amaç, gerçek kullanıcıyı rahatsız etmeden, anormal istek patlamalarını törpülemektir.
1. Nerede Rate Limit Uygulamalısınız?
Küçük ve orta ölçekli sitelerde kritik noktalar genelde şunlardır:
- Giriş sayfaları:
/wp-login.php,/admin, özel login endpoint’leriniz. - Yoğun sorgulu sayfalar: Arama, filtreleme, rapor ekranları.
- API uç noktaları: Özellikle “write” yapan veya pahalı işlemler tetikleyen endpoint’ler.
Bu noktalara hem Cloudflare tarafında hem de web sunucusunda farklı eşiklerle rate limit koymak, çok iyi sonuç verir. API ve mikroservisler için daha gelişmiş stratejilerle ilgileniyorsanız Nginx, Cloudflare ve Redis ile rate limiting rehberimize mutlaka göz atın.
2. Cloudflare Rate Limit Örneği (L7 Tarafı)
Cloudflare tarafında tipik bir WordPress sitesi için şu mantık güvenli bir başlangıçtır:
/wp-login.phpiçin: Aynı IP’den 1 dakika içinde 10’dan fazla istek geliyorsa 5 dakika blok + Captcha.- API için: IP başına 1 saniyede 5–10 istekten fazlasını sınırlamak.
Hassas endpoint’lerde eşikleri düşük, genel API veya listeleme sayfalarında ise biraz daha yüksek tutabilirsiniz. İlk haftalarda logları inceleyip gerçek kullanıcı davranışına göre eşikleri ayarlamak iyi bir pratiktir.
3. Nginx Üzerinde Basit Rate Limit Örneği
Origin sunucu tarafında Nginx kullanıyorsanız, limit_req direktifi ile basit ama etkili bir ikinci katman oluşturabilirsiniz:
http {
limit_req_zone $binary_remote_addr zone=login_zone:10m rate=10r/m;
server {
location = /wp-login.php {
limit_req zone=login_zone burst=20 nodelay;
include fastcgi_params;
# PHP-FPM ayarları...
}
}
}
Bu örnek, login endpoint’ine IP başına dakikada 10 istek hızında izin verir, anlık patlamalara (burst=20) müsaade eder ama bunun ötesini sınırlar. Cloudflare tarafındaki kurallarla birlikte çalıştığında, bot’ların işi oldukça zorlaşır.
4. Apache (mod_ratelimit / mod_evasive) ile Yaklaşım
Apache tarafında da mod_evasive ve benzeri modüllerle benzer bir koruma kurabilirsiniz. Temel fikir aynı:
- Kısa sürede çok fazla istek atan IP’yi geçici olarak engelle.
- Belirli URL pattern’lerini daha sıkı koru.
- Logları izleyerek eşikleri gerçek kullanıma göre optimize et.
Önemli nokta, rate limit stratejisini “kullanıcıyı rahatsız etmeyen ama bot’u bezdiren” noktaya getirmektir. Bu yüzden ilk konfigürasyondan sonra mutlaka birkaç gün log analizi yapın.
Sunucu ve İşletim Sistemi Ayarlarıyla Dayanıklılığı Artırmak
Cloudflare ve rate limit katmanı düzgün olsa bile, saldırının bir kısmı sunucunuza ulaşabilir. Burada amaç, sunucunun “güzelce yavaşlaması” değil, kararlı kalmasıdır. Yani saldırı olsa bile SSH, monitoring ve temel servisler çalışmaya devam etmeli.
1. Firewall ve Temel Ağ Sertleştirmesi
Linux tabanlı VPS veya dedicated sunucularda ilk adım her zaman güvenlik duvarı kurallarıdır:
- Gereksiz tüm portları kapatın, sadece HTTP/HTTPS, SSH ve gerçekten gereken servisleri açık bırakın.
- SSH için IP kısıtlaması veya VPN (WireGuard vb.) arkasından erişim kullanın.
- TCP SYN flood gibi saldırılara karşı basit
iptables/nftableskurallarıyla bağlantı sayılarını sınırlayın.
Güvenlik duvarı tarafını adım adım kurmak istiyorsanız, VPS’te ufw, firewalld ve iptables ile firewall yapılandırma rehberimizi referans alabilirsiniz.
2. Fail2ban ile Kaba Kuvvet ve Basit L7 DDoS Denemelerini Süpürmek
fail2ban, log dosyalarınızı izleyip şüpheli IP’leri otomatik olarak engelleyen hafif bir araçtır. Özellikle şu alanlarda çok iş görür:
- SSH brute-force saldırıları.
- Apache/Nginx error log’larında yoğun 404, 403 veya login denemeleri.
- Özel uygulama log’larında belirli pattern’ler (örneğin hatalı token, çok sık istek).
WordPress örneğinde /wp-login.php için hem Cloudflare rate limit hem de Nginx limit_req kullandığınızda, aradan sızan agresif IP’leri fail2ban ile tamamen düşürebilirsiniz. Daha geniş perspektiften bakmak için Cloudflare, ModSecurity ve fail2ban’ı birlikte kullandığımız WAF ve bot koruması rehberine göz atmanızı öneririz.
3. TCP Stack ve Kaynak Limitleri
Yoğun bağlantı altında Linux’un daha dayanıklı davranması için bazı sysctl ayarlarını optimize etmek gerekebilir. Örneğin:
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 15
Bu tür ayarlar:
- Daha fazla bekleyen bağlantıyı düzgünce sıraya almanıza,
- SYN flood saldırılarına karşı daha dirençli olmanıza,
- Zombi bağlantıların daha hızlı temizlenmesine
yardımcı olur. Elbette her sunucu için tek bir “mükemmel ayar” yok; CPU, RAM ve iş yüküne göre ince ayar yapmak gerekir.
4. PHP-FPM, Veritabanı ve Uygulama Kaynak Sınırları
DDoS sırasında en sık gördüğümüz problem: Tüm PHP-FPM çocuk süreçleri dolup yeni isteklerin kuyrukta patlaması, ardından veritabanının da boğulması. Bunu önlemek için:
- PHP-FPM:
pm.max_children,pm.max_requestsdeğerlerini sitenin normal trafiğine göre hesaplayın; aşırı iyimser davranmayın. - Veritabanı: Maksimum bağlantı sayısını (max_connections) sınırlandırın, PHP tarafında connection pool veya yeniden kullanım stratejisi uygulayın.
- Uygulama: Çok pahalı sorgulara (özellikle arama/filtre) sayfa başına limit ve basit cache mekanizmaları ekleyin.
DCHost olarak optimizasyon taleplerinde ilk baktığımız şeylerden biri, uygulama ve veritabanı tarafındaki bu limitlerin gerçekçi olup olmadığı. Güçlü bir sunucu bile yanlış limitler yüzünden DDoS etkisinde çok kırılganlaşabiliyor.
Olay Anında Yol Haritası: DDoS Saldırısı Sırasında Ne Yapmalı?
Her koruma katmanına rağmen saldırı almanız mümkün. Önemli olan, o anda ne yapacağınızı önceden planlamış olmanız. Küçük/orta ölçekli siteler için pratik bir kontrol listesi:
- 1. Durumu doğrulayın: Sunucu kaynaklarını, HTTP hata oranlarını ve Cloudflare analytics verilerini kontrol edin.
- 2. Cloudflare modunu yükseltin: Geçici olarak Under Attack moduna alın, Security Level’i artırın.
- 3. Hedeflenen URL’leri tespit edin: Loglardan en çok istek alan yol ve IP’leri çıkarın; gerekiyorsa ekstra rate limit ve WAF kuralı tanımlayın.
- 4. Sunucudaki servislere nefes aldırın: Gereksiz arka plan işleri, cron’lar veya yoğun raporlamaları geçici olarak durdurun.
- 5. İletişim: Ekip içi ve müşteri iletişimini (durum sayfası, e-posta) net tutun; “güncel durum” bilgisini paylaşın.
Daha kurumsal yapılarda bu listeyi bir incident runbook hâline getirip belirli periyotlarda tatbikat yapılmasını öneriyoruz. Küçük projelerde bile en azından bir “DDoS sırasında ilk 30 dakika planı” yazılı olmalı.
DCHost Altyapısında Örnek Mimari Önerileri
DCHost tarafında küçük ve orta ölçekli müşteriler için sık önerdiğimiz birkaç pratik mimari var:
1. Küçük WordPress / Kurumsal Site
- 1 adet DCHost VPS (CPU/RAM sitenin trafiğine göre boyutlandırılmış).
- Cloudflare DNS + proxy aktif.
- Cloudflare’de temel WAF kuralları +
/wp-login.phpve/xmlrpc.phpiçin rate limit. - Sunucuda ufw/iptables ile temel firewall, fail2ban ile SSH ve Nginx log takibi.
- Nginx üzerinde login ve admin URL’leri için
limit_reqkuralı.
2. Orta Trafikli WooCommerce / Basit SaaS
- Uygulama ve veritabanını ayrı DCHost VPS’lere bölmek (özellikle veritabanı için ayrı kaynak ayırmak).
- Cloudflare tarafında daha agresif önbellekleme (ürün listeleri, blog, statik sayfalar için uzun cache).
- Kritik API ve ödeme adımları için özel WAF kuralları ve daha sıkı rate limit.
- Sunucu tarafında PHP-FPM, MySQL/PostgreSQL ve TCP stack için dikkatli tuning.
- Log analizi ve basit izleme (Uptime, response time, hata oranı) ile anormallikleri hızlı fark etmek.
Daha ileri seviye ihtiyaçlarda dedicated sunucu veya colocation ile özel ağ/filtreleme kurulumları da mümkün. Ancak çoğu KOBİ ve ajans için, iyi yapılandırılmış bir DCHost VPS mimarisi + Cloudflare katmanı, hem bütçe dostu hem de oldukça dayanıklı bir çözüm sunuyor.
Sonuç: DDoS Korkusunu Yönetilebilir Bir Risk Hâline Getirmek
DDoS’u tamamen yok etmek mümkün değil; ama yönetilebilir ve kabul edilebilir bir risk seviyesine indirmek kesinlikle mümkün. Özellikle küçük ve orta ölçekli siteler için amaç, milyonlarca liralık donanımlar almak değil, akıllı ve katmanlı bir mimari kurmak olmalı. Bu yazıda özetlediğimiz gibi:
- Cloudflare proxy + WAF + rate limit ile trafiği mümkün olduğunca edge’te temizleyin.
- Uygulama tarafında login, arama, API gibi pahalı endpoint’leri özel korumaya alın.
- Sunucu ve işletim sistemi ayarlarıyla; firewall, TCP stack, PHP-FPM ve veritabanını gerçekçi limitlerle sertleştirin.
- Olay anında ne yapacağınızı önceden yazın; log, izleme ve iletişim kanallarınızı hazır tutun.
Eğer “Bizim sitede ne kadarına gerçekten ihtiyacımız var?” diye düşünüyorsanız, mevcut mimarinizi birlikte gözden geçirmek için DCHost ekibiyle iletişime geçebilirsiniz. Trafik profiliniz, kullandığınız yazılım (WordPress, Laravel, özel PHP, Node.js vb.) ve bütçeniz üzerinden; doğru boyutlandırılmış bir DCHost VPS veya dedicated sunucu ile size özel DDoS koruma planı çıkarmak mümkün. Böylece bir sonraki saldırı haberi geldiğinde panik yapmak yerine, sadece dashboard’ları sakin sakin izlersiniz.
