DDoS Korumalı Sunucu Almalı mıyım?

"DDoS korumalı sunucu almalı mıyım" sorusu genellikle iki anda sorulur: ya bir hosting firmasının paket sayfasında "DDoS korumalı" ibaresini görüp bunun ne kadar fark yarattığını merak edersiniz, ya da siteniz bir kere çökmüş, destek "saldırı vardı, IP'nizi geçici olarak kapattık" demiş ve o cümlenin ne anlama geldiğini anlamaya çalışıyorsunuzdur. İkinci grup için üzücü haber şudur: o cümlenin karşılığı, sağlayıcının sizi korumak yerine sizi ağdan çıkararak diğer müşterilerini koruduğudur. Bunun adı null-route'tur ve neredeyse her sağlayıcının politikasında vardır — sadece satış sayfasında yazmaz.

Türkçe kaynakların büyük çoğunluğu DDoS saldırısının tanımını yapıp orada duruyor. Bu yazı tanım yazısı değil; satın alma kararı yazısıdır. Koruma paketlerinde teknik olarak tam olarak neyin satıldığını, "kaç Gbps koruma" ifadesinin ne anlama geldiğini ve neyi ölçmediğini, ücretsiz CDN korumasının nerede yettiğini ve nerede duvara tosladığını, null-route uygulamasının müşteri açısından sonucunu, hangi site tiplerinin bu bütçeyi hak ettiğini ve satın almadan önce sağlayıcıya sorulacak somut soruları sırayla ele alıyoruz.

DDoS Koruması Aslında Ne Satar#

Bir DDoS koruma hizmeti üç ayrı şeyden birini veya birkaçını satar: hacim emme kapasitesi, protokol seviyesinde filtreleme ve uygulama katmanı ayıklama. Paket sayfalarında bunlar tek bir "DDoS korumalı" etiketi altında birleştirildiği için kullanıcı neyi aldığını bilmez. Ayrımı bilmezseniz, L3 saldırıya karşı satın aldığınız korumanın L7 saldırıda hiçbir işe yaramadığını canlı ortamda öğrenirsiniz.

Saldırıları katmanlarına göre ayıralım:

Bu tablonun en önemli satırı sonuncusudur ve hiçbir koruma paketinde yer almaz: saniyede 50 istekle bile, her istek 3 saniyelik bir arama sorgusu çalıştırıyorsa siteniz çöker. Bu bir DDoS saldırısı değil, bir kapasite sorunudur; ne kadar Gbps koruma alırsanız alın çözülmez. Saldırı tiplerinin ayrıntılı anlatımı için DDoS saldırısı nedir yazısına bakabilirsiniz.

"Kaç Gbps Koruma" İfadesi Ne Anlama Gelir, Neyi Ölçmez#

Gbps rakamı, sağlayıcının temizleme (scrubbing) altyapısının toplam emme kapasitesidir — size ayrılmış garanti değildir. Bu ayrım Türkçe içeriklerde hiç yapılmaz ve satın alma kararında en yanıltıcı noktadır.

Somutlaştıralım. Bir sağlayıcı "X Tbps DDoS koruma" diyorsa, bu onun tüm veri merkezlerinin toplam emme kapasitesidir; sizin IP'nize gelen saldırının o kapasitenin tamamına erişeceği anlamına gelmez. Sizin için asıl belirleyici olan üç sayı vardır:

1. Sunucunuzun bağlı olduğu portun hızı. Saldırı bu portu doyurduğu anda, temizleme merkezi ne kadar büyük olursa olsun trafik sizin sunucunuza ulaşamaz. Temizleme yukarıda yapılıyorsa sorun yoktur; yapılmıyorsa port doyar ve iş biter.
2. Temizlemenin nerede yapıldığı. Filtre sunucunuzun önünde mi, veri merkezinin sınırında mı, yoksa dağıtık bir ağda mı? Filtre ne kadar yukarıda olursa hat o kadar korunur.
3. Devreye girme süresi ve yöntemi. Koruma her zaman açık (always-on) mı, yoksa saldırı algılandığında mı devreye giriyor? Algılamalı sistemlerde ilk 30–120 saniye genellikle kayıptır.

Sorulacak doğru soru "kaç Gbps" değil, şudur: "Bana gelen saldırı X Gbps'i geçtiğinde ne yapıyorsunuz?" Cevap üç seçenekten biridir — temizleyip geçiririz, hız sınırlarız, ya da IP'yi null-route'a alırız. Üçüncüsü sizin için tam kesinti demektir.

Paket ve bant genişliği hesaplarını kavramak isterseniz bant genişliği hesaplayıcı aracı, "benim hattım kaç Gbps'de doyar" sorusunu somutlaştırmakta işe yarar.

Null-Route Nedir: Sağlayıcı Neden Sunucunuzu Kapatır#

Null-route (blackhole), saldırı altındaki bir IP adresine gelen tüm trafiğin ağ girişinde çöpe atılmasıdır; yani saldırıyı durdurmak yerine hedefi ağdan çıkarır. Sizin açınızdan sonucu tam kesintidir: site açılmaz, e-posta gelmez, SSH bağlanmaz. Saldırgan açısından ise saldırı başarılı olmuştur.

Sağlayıcı bunu kötü niyetle yapmaz. Tek bir müşteriye gelen 40 Gbps'lik bir saldırı, aynı hattı paylaşan yüzlerce müşterinin trafiğini de bozar. Sağlayıcı bir noktada "bir müşteri mi, hepsi mi" kararı verir ve tek IP'yi kapatır. Bu yüzden neredeyse her sağlayıcının kullanım şartlarında buna izin veren bir madde vardır.

Bilmeniz gereken pratik ayrıntılar:

• Null-route genellikle zaman aşımlıdır. Tipik uygulama, IP'yi belirli bir süre (çoğunlukla saatlerle ölçülen) kapatıp otomatik açmaktır. Açıldığında saldırı sürüyorsa yeniden kapanır.
• Kapanan şey IP'dir, sunucu değildir. Sunucunuz çalışmaya devam eder; sadece o IP'ye kimse ulaşamaz. Bu yüzden konsol/IPMI erişimi olan sağlayıcılarda sunucuya bakabilirsiniz.
• Yeni IP almak çözüm değildir. Saldırgan alan adınızı çözümlüyorsa yeni IP'yi de dakikalar içinde bulur. Alan adı DNS kaydınız korumalı bir katmanın arkasında değilse IP değiştirmek zaman kazandırır, sorunu çözmez.
• Politikayı satın almadan önce sorun. "Saldırı durumunda IP'yi ne kadar süre null-route'a alıyorsunuz, otomatik mi manuel mi, uyarı gönderiyor musunuz?" — bu üç sorunun cevabı, paket sayfasındaki Gbps rakamından çok daha belirleyicidir.

Sunucunuzun bir saldırı yüzünden mi yoksa başka bir sebeple mi erişilemez olduğunu ayırmak için site açılmıyor ne yapmalı yazısındaki sıralı tanılama adımlarını izleyin; yönetimsel askıya alma ile null-route farklı şeylerdir ve hosting hesabım askıya alındı yazısı ikincisini anlatır.

Ücretsiz CDN Koruması Nerede Yeter, Nerede Yetmez#

Ücretsiz CDN/proxy katmanları, web trafiği (80/443) için hacimsel saldırıların büyük kısmını gerçekten emer; ama sunucunuzun web dışındaki servislerini ve gerçek IP'nizi korumaz. Türkçe içeriklerde bu karşılaştırma neredeyse hiç yapılmaz, oysa çoğu küçük ve orta ölçekli site için karar tam olarak burada verilir.

Ücretsiz proxy katmanının yettiği durumlar:

• Trafiği yalnızca 80/443 üzerinden gelen bir web sitesi veya blog işletiyorsanız.
• Saldırı hacimsel ve web tabanlıysa (HTTP flood, basit UDP amplifikasyon).
• Statik içeriğin büyük bölümü önbelleğe alınabiliyorsa; önbellekten dönen istek sunucunuza hiç ulaşmaz.
• Acil durumda tüm ziyaretçilere doğrulama sayfası göstermeyi kabul edebiliyorsanız. Bunun nasıl yapıldığını Cloudflare Under Attack modu yazısında adım adım anlattım.

Yetmediği durumlar:

• Gerçek IP'niz sızmışsa. Saldırgan sunucunuzun asıl IP'sini biliyorsa proxy'yi atlar ve doğrudan sunucuya vurur. IP genellikle şu yollarla sızar: eski DNS kayıtları, doğrudan bağlanan e-posta sunucusu, sunucudan giden bağlantıların kaynak IP'si, SSL sertifikası geçmişi ve cpanel. / mail. gibi proxy dışı bırakılmış alt alan adları.
• Web dışı servis çalıştırıyorsanız. Oyun sunucusu, VoIP, özel TCP/UDP portlarında çalışan uygulamalar ücretsiz web proxy'lerinin kapsamı dışındadır.
• Saldırı uygulama mantığını hedefliyorsa. Saniyede birkaç yüz istekle veritabanınızı kilitleyen bir saldırı, hacimsel eşiğe hiç takılmadan sitenizi çökertir.
• E-posta akışınız etkileniyorsa. MX kaydınız gerçek IP'yi gösterir ve proxy arkasına alınamaz; bu, IP sızıntısının en yaygın kaynağıdır.

Gerçek IP'nizin sızıp sızmadığını kaba biçimde şöyle kontrol edebilirsiniz:

# Alan adının proxy IP'si
dig +short example.com

# Alt alan adları proxy dışında mı kalmış?
for s in mail ftp cpanel webmail direct dev test; do
  echo -n "$s -> "; dig +short $s.example.com
done

# MX kaydı hangi IP'yi gösteriyor?
dig +short MX example.com
dig +short mail.example.com

Çıkan IP'lerden biri proxy aralığında değilse, gerçek sunucu adresiniz açıktadır. Bu durumda yapılacak ilk iş sunucunun güvenlik duvarında yalnız proxy IP aralıklarından gelen 80/443 trafiğine izin vermektir:

# Örnek: yalnız belirli kaynaklardan web trafiği kabul et
ufw default deny incoming
ufw allow from 203.0.113.0/24 to any port 443 proto tcp
ufw allow from 203.0.113.0/24 to any port 80 proto tcp
ufw allow 22/tcp
ufw enable

Kural setinin mantığını ve kalıcı hâle getirmeyi UFW güvenlik duvarı ve iptables ile güvenlik duvarı yazılarında bulabilirsiniz.

Hangi Siteler DDoS Koruması İçin Ek Bütçe Ayırmalı#

Herkesin ödemesi gereken bir maliyet değildir. Ek koruma bütçesini şu profillerden birine giriyorsanız ayırın:

Kesinlikle ayırmalı olanlar

1. E-ticaret ve ödeme alan siteler. Kesinti doğrudan gelir kaybıdır ve saldırganların şantaj hedefi olarak seçtiği ilk gruptur. Kampanya günleri klasik saldırı zamanıdır.
2. Oyun sunucuları ve gerçek zamanlı servisler. Rakip veya kızgın kullanıcı kaynaklı saldırılar bu alanda çok yaygındır ve web dışı portlar kullanıldığı için ücretsiz proxy koruması işlemez.
3. Rekabetin sert olduğu sektörlerdeki siteler. Belirli sektörlerde saldırı, rekabetin bir aracı hâline gelmiştir; bir kere hedef olduysanız tekrarı yüksek olasılıktır.
4. Kesintinin sözleşmeye bağlı olduğu B2B servisler. SLA taahhüdü verdiğiniz bir API veya panel işletiyorsanız kesintinin bedeli parayla ölçülüdür.
5. Daha önce saldırıya uğramış herkes. Bir kere hedef olan altyapı listelenir ve tekrar hedef alınır.

Muhtemelen gerekmeyenler

• Kurumsal tanıtım sitesi, kişisel blog, portföy sitesi: ücretsiz proxy katmanı + doğru güvenlik duvarı kuralları çoğu durumda yeterlidir.
• Trafiği düşük, tamamen statik veya iyi önbelleklenmiş siteler.
• Yalnızca iç ağdan erişilen, internete kapalı uygulamalar.

Karar verirken şu hesabı yapın: bir saatlik kesinti size ne kadara mal olur, ayda kaç saat kesinti riskini kabul edebilirsiniz. Bu iki sayıyı bilmeden hiçbir güvenlik harcaması rasyonel olarak gerekçelendirilemez. Kesinti süresi ve erişilebilirlik yüzdesi arasındaki ilişkiyi somutlaştırmak için uptime SLA hesaplayıcı aracını kullanabilirsiniz.

Koruma Almadan Önce Yapılabilecek Ücretsiz İşler#

Yıllardır gördüğüm en yaygın hata şudur: insanlar ilk çöküşün ardından doğrudan koruma paketi almaya koşar, oysa çöküşün sebebi çoğu zaman saldırının büyüklüğü değil, sunucunun hiç ayarlanmamış olmasıdır. Aşağıdaki maddeler hiçbir ek bütçe gerektirmez ve tek başına birçok küçük ölçekli saldırıyı etkisiz hâle getirir.

1. Hız sınırlama koyun. Nginx tarafında istek ve bağlantı sınırları, en ucuz L7 korumasıdır:

limit_req_zone $binary_remote_addr zone=genel:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=baglanti:10m;

server {
    location / {
        limit_req zone=genel burst=20 nodelay;
        limit_conn baglanti 20;
    }

    # Giriş sayfası gibi pahalı uçları ayrı ve daha sıkı sınırlayın
    location = /wp-login.php {
        limit_req zone=genel burst=3 nodelay;
    }
}

Ayrıntılı yapılandırma için nginx rate limit ve güvenlik başlıkları yazısına bakın.

2. Yavaş bağlantı saldırılarına karşı zaman aşımlarını kısın. Slowloris tipi saldırılar hacim gerektirmez; yalnızca bağlantı havuzunuzu doldurur.

client_body_timeout 10s;
client_header_timeout 10s;
send_timeout 10s;
keepalive_timeout 30s;

3. Önbelleği açın. Önbellekten dönen bir istek PHP ve veritabanına hiç ulaşmaz. Statik bir sayfayı önbelleğe almak, aynı sayfayı dinamik üretmeye göre kat kat az kaynak harcar.

4. Tekrarlayan saldırgan IP'leri otomatik banlayın. Fail2ban kurulumu yazısındaki filtrelerle giriş denemelerini ve anormal istek desenlerini otomatik engelleyebilirsiniz.

5. Kullanmadığınız portları kapatın. Açık bir DNS çözümleyici, açık bir NTP servisi veya yapılandırılmamış bir memcached, sizi saldırının hedefi değil aracı hâline getirir; sağlayıcınız o zaman sizi kötü niyetli trafik kaynağı olarak askıya alır. Açık portlarınızı açık port taraması nmap yazısındaki yöntemle kontrol edin.

6. DNS TTL değerlerini makul tutun. Saldırı anında trafiği başka bir yere yönlendirmeniz gerekirse, 86400 saniyelik bir TTL sizi bir gün boyunca eski adrese kilitler. Normal zamanda 3600, kritik kayıtlarda 300 makul bir dengedir.

7. Uygulamadaki pahalı uçları bulun. Erişim kayıtlarında en çok zaman alan istekleri çıkarın; saldırgan her zaman en pahalı ucu bulur.

# En çok istek alan IP'ler
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# En çok istek alan yollar
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Anlık eşzamanlı bağlantı sayısı
ss -ant | awk '{print $1}' | sort | uniq -c

Saldırı Anında Ne Yapılır: Sıralı Müdahale#

Saldırı sürerken doğru sırayla hareket etmek, panikle rastgele ayar değiştirmekten çok daha etkilidir.

1. Önce teşhis koyun. Gerçekten saldırı mı, yoksa bir kampanya sonrası doğal trafik artışı mı? Erişim kayıtlarındaki istek deseni, kaynak IP çeşitliliği ve hedef yol dağılımı bunu hemen söyler.
2. Katmanı belirleyin. Hat mı doldu (sunucuya SSH bile bağlanamıyorsunuz), yoksa web sunucusu mu tıkandı (SSH çalışıyor ama site açılmıyor)? İkisinin çözümü farklıdır.
3. En hızlı fren: doğrulama modu. Proxy katmanınız varsa tüm ziyaretçilere doğrulama uygulayan acil durum modunu açın. Meşru kullanıcı deneyimi bozulur ama site ayakta kalır.
4. Hedef daraltın. Saldırı tek bir yola geliyorsa o yolu geçici olarak kapatın veya statik bir yanıtla değiştirin.
5. Sağlayıcıya haber verin. Null-route uygulanmadan önce haber vermek, süreyi ve kapsamı konuşabilmenizi sağlar. Saldırı başladıktan sonra açılan bir kayıt, otomatik sistem çoktan devreye girdikten sonra ulaşır.
6. Kanıt toplayın. Kayıt dosyalarını, ss çıktısını ve trafik grafiklerini saklayın. Hem sağlayıcıya hem gerekirse adli sürece lazım olur.
7. Sonrasında kalıcı önlem alın. Saldırı bittiğinde acil durum modunu kapatıp hiçbir şey yapmamak, bir sonraki saldırıya aynı hazırlıksızlıkla girmek demektir.

Satın Almadan Önce Sağlayıcıya Sorulacak Sorular#

Paket sayfasındaki rakamlar yerine bu sekiz sorunun cevabını isteyin. Cevapların netliği, sağlayıcının koruma iddiasının ne kadar gerçek olduğunu Gbps rakamından daha iyi gösterir.

1. Koruma her zaman açık mı, yoksa algılamayla mı devreye giriyor? Devreye girme süresi ne kadar?
2. Filtreleme hangi katmanları kapsıyor — yalnız L3/L4 mü, L7 dahil mi?
3. Saldırı kapasitenizi aştığında ne yapıyorsunuz? Null-route uygular mısınız, ne kadar süreyle?
4. Null-route uygulandığında bana bildirim geliyor mu, hangi kanaldan?
5. Web dışı portlar (özel TCP/UDP servisler) koruma kapsamında mı?
6. Koruma sırasında meşru trafik için ek gecikme oluşuyor mu, ne kadar?
7. Saldırı raporu veya trafik grafiği paylaşıyor musunuz?
8. Sözleşmede saldırı kaynaklı kesinti SLA dışında mı tutuluyor?

Son madde özellikle önemlidir: birçok sözleşmede saldırı kaynaklı kesinti erişilebilirlik taahhüdünün dışında bırakılır. Yani "%99,9 uptime" ifadesi, DDoS saldırısı sırasında geçerli olmayabilir.

Sıkça Sorulan Sorular#

Küçük bir kurumsal site için DDoS koruması gerekli mi#

Küçük kurumsal siteler için ayrı bir ücretli DDoS koruma paketi çoğunlukla gerekli değildir. Ücretsiz bir proxy/CDN katmanı, doğru yapılandırılmış güvenlik duvarı ve web sunucusu tarafında hız sınırlama, bu ölçekte karşılaşılan saldırıların büyük kısmını karşılar. Ek bütçeyi, kesintinin doğrudan gelir kaybına dönüştüğü durumlarda veya daha önce hedef olduysanız ayırmak mantıklıdır. Bunun yerine aynı bütçeyi yedekleme ve izleme tarafına ayırmak çoğu küçük site için daha yüksek getiri sağlar.

Cloudflare gibi ücretsiz servisler DDoS'a karşı yeterli mi#

Web trafiği için büyük ölçüde yeterlidir, ancak üç koşulla: gerçek sunucu IP'nizin sızmamış olması, saldırının 80/443 üzerinden gelmesi ve sunucunuzun yalnız proxy IP aralıklarını kabul edecek şekilde ayarlanmış olması. Bu üçü sağlanmazsa saldırgan proxy'yi atlayıp doğrudan sunucunuza vurur ve koruma hiç devreye girmez. Oyun sunucusu, VoIP veya özel port kullanan servisler ücretsiz web proxy'lerinin kapsamı dışındadır. Uygulama mantığını hedefleyen düşük hacimli saldırılarda ise hacim eşiğine hiç takılmadığı için koruma tetiklenmez.

Null-route uygulanırsa ne kadar sürede açılır#

Süre sağlayıcıya göre değişir ve genellikle otomatik bir zaman aşımına bağlıdır; birkaç saatlik pencereler yaygındır. Süre dolduğunda IP otomatik açılır, saldırı devam ediyorsa yeniden kapatılır. Bu yüzden asıl mesele süreyi öğrenmek değil, saldırı bittiğinde yeniden kapanmayacak bir yapılandırmayla dönmektir. Satın alma öncesi sağlayıcıya süreyi, otomatik mi manuel mi olduğunu ve bildirim gönderip göndermediklerini mutlaka sorun.

Saldırı sırasında sunucumun IP'sini değiştirmek işe yarar mı#

Kısa vadede rahatlatır, kalıcı çözüm sağlamaz. Saldırgan alan adınızı çözümleyerek yeni IP'yi genellikle dakikalar içinde bulur; DNS TTL değeriniz düşükse bu süre daha da kısalır. IP değişikliği yalnızca aynı anda bir proxy katmanının arkasına geçiyorsanız ve yeni IP'yi hiçbir kayıtta açık etmiyorsanız işe yarar. Yeni IP'ye geçerken MX kaydı, eski alt alan adları ve doğrudan bağlanan servisler üzerinden adresin tekrar sızmamasına dikkat edin.

DDoS saldırısı hosting hesabımın kapatılmasına sebep olur mu#

Evet, iki farklı şekilde olabilir. Birincisi hedef olmanız durumunda IP'nizin null-route'a alınmasıdır; bu geçicidir ve saldırı bitince düzelir. İkincisi ve daha ciddi olanı, sunucunuzun saldırının kaynağı veya aracısı hâline gelmesidir — açık bir DNS çözümleyici, güvenliği aşılmış bir site veya kötü amaçlı bir betik yüzünden sunucunuz başkalarına saldırıyorsa hesabınız askıya alınır. İkinci durumda çözüm koruma satın almak değil, sunucudaki zararlı yazılımı temizlemek ve açık servisleri kapatmaktır.

DDoS koruması sitemi yavaşlatır mı#

Doğru kurulmuş bir koruma katmanı genellikle ölçülebilir ama kabul edilebilir bir gecikme ekler; kötü kurulmuş olan belirgin biçimde yavaşlatır. Trafiğiniz temizleme merkezinden geçtiği için fiziksel olarak fazladan bir durak eklenir; bu durak coğrafi olarak uzaktaysa gecikme artar. Buna karşılık CDN özellikli koruma katmanları statik içeriği ziyaretçiye yakın noktadan sunarak toplam süreyi düşürebilir, yani net etki hızlanma bile olabilir. Karar vermeden önce koruma açık ve kapalıyken ilk bayt süresini ölçüp karşılaştırın.

Paylaşımlı hostingde DDoS koruması nasıl çalışır#

Paylaşımlı hostingde koruma sunucu seviyesinde uygulanır ve tek tek siteler için ayarlanamaz. Aynı sunucudaki başka bir siteye gelen saldırı sizi de etkileyebilir, çünkü kaynaklar ortaktır. Sağlayıcı genellikle saldırı alan hesabı geçici olarak devre dışı bırakarak diğer siteleri korur. Bu yüzden saldırı riski yüksek bir proje işletiyorsanız paylaşımlı hosting yerine kendi IP'sine ve kaynağına sahip bir sanal sunucu daha kontrol edilebilir bir zemin sunar.

WAF ile DDoS koruması aynı şey mi#

Aynı şey değildir; farklı katmanlarda çalışırlar ve birbirinin yerine geçmezler. DDoS koruması esas olarak hacim ve paket seli ile ilgilenir, amacı hattı ve sunucuyu ayakta tutmaktır. WAF ise isteklerin içeriğine bakar; SQL enjeksiyonu, XSS ve uygulama seviyesindeki kötüye kullanımı engeller. Uygulama katmanına yönelen bir istek seli her ikisinin de kesişiminde kalır: hız sınırlama ve bot ayıklama yapan bir WAF bu saldırıyı durdurabilirken, saf hacimsel bir saldırıya karşı hiçbir şey yapamaz. Sağlıklı bir kurulumda ikisi birlikte bulunur.

Kapanış#

"DDoS korumalı sunucu almalı mıyım" sorusunun cevabı site tipinize ve kesintinin size maliyetine bağlıdır. Karar verirken paket sayfasındaki Gbps rakamına değil şu dört şeye bakın: korumanın hangi katmanları kapsadığı, her zaman açık mı olduğu, kapasite aşıldığında null-route uygulanıp uygulanmadığı ve web dışı servislerinizin kapsama girip girmediği. Ayrıca koruma satın almadan önce ücretsiz olarak yapabileceğiniz işleri bitirin — hız sınırlama, zaman aşımı kısaltma, önbellek, kullanılmayan portları kapatma ve gerçek IP'nizi gizleme. Çoğu küçük ölçekli çöküşün sebebi saldırının büyüklüğü değil, sunucunun hiç ayarlanmamış olmasıdır.

Kesintinin doğrudan gelir kaybına dönüştüğü bir proje işletiyorsanız DDoS koruma hizmetinin kapsamına, uygulama katmanındaki istek selleri ve kötüye kullanım için WAF çözümüne bakabilirsiniz. Paylaşımlı ortamdaki komşu etkisinden kurtulup kendi IP'niz ve kaynağınızla çalışmak istiyorsanız VDS paketleri daha kontrol edilebilir bir zemin sunar; güvenlik duvarı kurallarını, hız sınırlarını ve izlemeyi sizin yerinize kuran bir ekip istiyorsanız sunucu yönetimi hizmeti bu işi üstlenir.