DDoS Saldırısı Nedir? VPS Koruma Rehberi

DDoS saldırısı nedir ve VPS’inizi nasıl etkiler?

Gece vardiyasında monitoring ekranında aynı anda üç alarm gördüğümde elim doğrudan reboot komutuna gitmiyor. Önce trafiğin nereden geldiğine, hangi portun dolduğuna ve makinenin gerçekten ne kadar kaynak tükettiğine bakıyorum. DDoS olaylarında aceleyle atılan bir yeniden başlatma komutu saldırıyı durdurmayabilir; yalnızca elimizdeki kanıtları ve aktif bağlantı tablosunu silebilir.

DDoS, yani Dağıtık Hizmet Engelleme saldırısı, bir sunucuya veya servise çok sayıda kaynaktan yoğun istek göndererek gerçek kullanıcıların erişimini engellemeyi amaçlar. Hedef yalnızca web sitesi değildir. DNS, oyun sunucusu, SSH, API ve doğrudan VPS’in IP adresi de saldırıya açık olabilir.

Buradaki “dağıtık” kelimesi önemli. Trafik tek bir bilgisayardan gelmediği için tek bir IP’yi engellemek çoğu zaman yeterli olmaz. Saldırganlar botnet adı verilen, ele geçirilmiş cihazlardan oluşan ağları kullanabilir. Bazı saldırılar bant genişliğini doldurur, bazıları bağlantı tablolarını tüketir. HTTP isteğine benzeyen saldırılar ise trafik miktarı çok yüksek görünmeden CPU ve veritabanı kaynaklarını bitirebilir.

VPS tarafındaki savunmayı iki ayrı katmanda düşünürüm: sunucunun içindeki kaynak tüketimini azaltmak ve zararlı trafiği veri merkezi ya da upstream sağlayıcı seviyesinde filtrelemek. İlk katmanda kendi yapılandırmalarınız işe yarar. İkinci katman için hosting sağlayıcınızın DDoS korumasına, scrubbing merkezlerine veya CDN hizmetlerine ihtiyaç duyabilirsiniz.

Saldırı türünü ayırmadan doğru önlem seçilmiyor

Her yoğun trafik DDoS değildir. Yeni yayınlanan bir kampanya, arama motoru taraması, hatalı çalışan bir cron görevi veya bir müşterinin paylaştığı bağlantı da kısa süreli trafik artışı oluşturabilir. Kaynaklara bakmadan “saldırı var” demek kadar, gerçek saldırıyı normal trafik sanmak da pahalıya patlar.

Volumetrik saldırılar

Bu saldırılarda amaç internet bağlantınızın kapasitesini doldurmaktır. UDP flood, ICMP flood ve büyük hacimli DNS yanıt trafiği bu sınıfa girer. VPS’inizde nftables kuralı yazsanız bile paketler çoğu zaman önce veri merkezinin uplink’ine ulaşır. Hat dolduktan sonra paketi sunucuda reddetmeniz gerçek kullanıcıya bant genişliği kazandırmaz.

Volumetrik saldırılarda çözüm genellikle sağlayıcı tarafında başlar. Trafik VPS’e ulaşmadan filtrelenmeli veya temizleme merkezine yönlendirilmelidir. Küçük ve kısa süreli bir taşmada yerel firewall yardımcı olabilir; bunu bağlantı kapasitesini artıran bir çözüm gibi görmemek gerekir.

Protokol ve bağlantı tüketen saldırılar

SYN flood, TCP bağlantı kurulumu aşamasındaki kaynakları tüketmeye çalışır. Çok sayıda yarım açık bağlantı oluştuğunda backlog ve conntrack tabloları baskı altına girebilir. Normal kullanıcılar da bağlantı kurmakta zorlanır.

Bu sınıfta SYN cookie gibi kernel ayarları, bağlantı limitleri ve sağlayıcı filtreleri işe yarayabilir. Rastgele sysctl değerlerini büyütmek ise çözüm değildir. Daha büyük tablolar saldırganın doldurabileceği daha büyük bir alan yaratabilir; RAM tüketimi de artar.

Uygulama katmanı saldırıları

HTTP flood, yavaş istekler ve pahalı API çağrıları dışarıdan bakıldığında normal web trafiğine benzeyebilir. İstekler 443 numaralı porta gelir, TLS başarıyla tamamlanır ve nginx ya da Apache bunları uygulamaya taşır. Trafik miktarı devasa görünmese bile her istek bir PHP worker’ı, MySQL sorgusu veya harici API çağrısı başlatıyorsa VPS kısa sürede nefessiz kalır.

Burada CDN, web sunucusu rate limit’leri, önbellek, kimlik doğrulama ve uygulama içi kota mekanizmaları birlikte ele alınmalıdır. Yalnızca IP engellemek genellikle yetersiz kalır; botnet’in binlerce adresi olabilir.

İlk beş dakika: yeniden başlatmadan kanıt toplayın

Saldırı sırasında ilk hedefim teşhis süresini kısa tutmak. Önce sağlayıcının panelinde trafik grafiğine, kaynak kullanımına ve varsa DDoS alarmına bakarım. Ardından SSH ile bağlanıp genel tabloyu çıkarırım. SSH erişimi de etkileniyorsa sağlayıcının konsolu daha güvenli bir yol olabilir.

date
hostname
uptime
free -h
ip -s link
ss -s

Buradaki hostname satırını atlamayın. Production prompt’larımı kırmızı kullanmamın nedeni de bu tür kontrolleri görünür kılmak. ip -s link arayüz seviyesindeki paket ve hata sayaçlarını, ss -s ise TCP durumlarının kaba dağılımını gösterir. Tek başına hiçbiri saldırının kesin kanıtı değildir.

Belirli bir portu incelemek için:

ss -Htan state syn-recv | wc -l
ss -Htan '( sport = :80 or sport = :443 )' | head -20
ss -Huan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

İlk komut yarım açık TCP bağlantı sayısını verir. İkinci komut HTTP ve HTTPS bağlantılarından örnek gösterir. Üçüncü komut UDP uçlarını kabaca sayar; IPv6 adresleri veya farklı çıktı biçimleri için bu kısa awk zincirine körü körüne güvenmeyin. Ben olay sırasında çıktıyı dosyaya da alırım:

ss -s > /root/incident-ss-$(date +%F-%H%M).txt
journalctl -k --since "10 minutes ago" > /root/incident-kernel.log

Kernel log’unda drop, SYN flood, conntrack veya network driver uyarıları görülebilir. Log yoksa saldırı yok demek değildir; bazı sayaçlar log üretmeden yükselir.

VPS üzerinde uygulanabilecek savunmalar

Gereksiz portları kapatın

Dışarıya açık her servis saldırı yüzeyinin bir parçasıdır. Önce dinleyen servisleri görün:

sudo ss -lntup

Burada özellikle 0.0.0.0 veya :: üzerinde dinleyen servisleri incelerim. PostgreSQL, Redis ve MySQL gibi servislerin internete açık olması çoğu kurulumda gereksizdir. MySQL kurulumu ve güvenli yapılandırma sırasında bind adresini ve firewall erişimini birlikte kontrol etmek gerekir; yalnızca güçlü parola yazmak yeterli güvenlik sağlamaz.

Firewall tarafında yalnızca gerçekten kullandığınız portlara izin verin. SSH, HTTP ve HTTPS kullanan basit bir nftables başlangıcı şöyle olabilir:

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;

    iifname "lo" accept
    ct state established,related accept
    ip protocol icmp accept
    ip6 nexthdr ipv6-icmp accept
    tcp dport 22 ct state new limit rate 15/minute accept
    tcp dport { 80, 443 } accept
  }

  chain forward { type filter hook forward priority filter; policy drop; }
  chain output { type filter hook output priority filter; policy accept; }
}

Bu örnek dağıtıma, uzaktan erişim politikanıza ve IPv6 kullanımınıza göre değiştirilmelidir. SSH için sabit yönetim IP’niz varsa kuralı onunla sınırlandırmak daha iyi olur. Uzaktan firewall değişikliği yaparken ikinci bir oturum açarım. Öğrendim ki açık kalan tek SSH oturumu, yanlış kuralın bedelini çok hızlı hatırlatıyor.

SSH’yi saldırının merkezinden çıkarın

SSH portunu 22’den başka bir porta almak güvenlik değildir. Otomatik taramaların bir kısmını azaltabilir; asıl kontroller anahtar tabanlı kimlik doğrulama, root girişinin kapatılması, güncel OpenSSH ve firewall kısıtlamasıdır.

sudoedit /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3

Yapılandırmayı yeniden yüklemeden önce kontrol edin:

sudo sshd -t && sudo systemctl reload ssh

Ubuntu ve Debian sistemlerinde servis adı çoğunlukla ssh olur; bazı dağıtımlarda sshd kullanılır. Mevcut oturumu kapatmadan yeni anahtarla giriş testini yapın. Ben bir firewall değişikliğinden sonra ikinci terminali açmayı unuttuğum için, mevcut SSH oturumunu bakım bitene kadar dikkatle açık tutmak zorunda kalmıştım. Küçük bir ihmal.

Web sunucusunda rate limit kullanın

HTTP katmanında nginx’in limit_req ve limit_conn modülleri belirli endpoint’leri koruyabilir. Giriş, arama ve pahalı rapor API’ları için genel sayfalardan farklı limitler tanımlamak daha mantıklıdır.

http {
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        limit_conn addr 30;

        location = /wp-login.php {
            limit_req zone=login_limit burst=3 nodelay;
            include fastcgi_params;
            # Uygulamanızın mevcut PHP-FPM ayarları burada kalır.
        }
    }
}

Bu kural her kurulumda kopyalanıp uygulanacak bir WordPress reçetesi değildir. NAT arkasındaki çok sayıda gerçek kullanıcı aynı public IP’yi paylaşabilir; IP başına limit bu kullanıcıları da etkileyebilir. API anahtarı, oturum veya kullanıcı hesabı bazında kota uygulamak, uygulama katmanında daha doğru sonuç verebilir.

Yapılandırma sonrası:

sudo nginx -t
sudo systemctl reload nginx

nginx -t başarılı olmadan reload yapmayın. Rate limit yazıp cache kurmamak da sık gördüğüm bir hata. Her isteği PHP’ye ve veritabanına göndermek yerine anonim, cache’lenebilir içerikleri edge veya nginx seviyesinde karşılamak sunucu yükünü ciddi biçimde azaltabilir.

Sağlayıcı ve CDN katmanı neden gerekli?

VPS’iniz saniyede yüzlerce megabit trafik alıyorsa sunucudaki firewall kuralları paketi işleyebilir. Fakat VPS’e ayrılmış bağlantı kapasitesi saldırı yüzünden dolmuşsa gerçek kullanıcı trafiği içeri giremez. Bu noktada yerel kuralın etkisi sınırlıdır; filtreleme trafiğin kaynağına daha yakın yapılmalıdır.

Hosting sağlayıcınıza bildirirken “site yavaş” demek yerine ölçülebilir bilgiler gönderin:

• Saldırının başladığı ve yoğunlaştığı zaman aralığı
• Hedeflenen IPv4 veya IPv6 adresi ve port
• Trafiğin TCP, UDP, ICMP veya HTTP ağırlıklı olup olmadığı
• Gözlenen bant genişliği, paket sayısı ve bağlantı durumu
• Uygulama loglarında görülen belirgin URL veya User-Agent örüntüleri
• Gerçek kullanıcıların hangi hizmete erişemediği

Sağlayıcınız blackhole routing uyguluyorsa saldırı sırasında IP geçici olarak karartılabilir. Bu, sunucuyu korur ama hizmeti de erişilemez yapar. Scrubbing veya upstream filtreleme seçeneği varsa kesintiyi azaltma ihtimali daha yüksektir. Planınızda “DDoS korumalı” yazması, bu ayrıntıların otomatik çözüldüğü anlamına gelmez.

Web sitesi için reverse proxy veya CDN, istemcinin doğrudan VPS IP’sini görmesini engelleyebilir. DNS kaydını CDN’e almak tek başına yeterli değildir. Origin IP daha önce açığa çıktıysa saldırgan doğrudan IP’ye trafik göndermeye devam edebilir. Origin firewall’ında yalnızca proxy sağlayıcısının güncel IP aralıklarına izin vermek gerekir; bu listeleri düzenli takip etmek de operasyonun parçasıdır.

DNS tarafında da dikkatli olun. A kaydı eski origin adresini açıkça gösteriyorsa proxy kullanımının etkisi azalır. dig +short ile dışarıdan görülen adresleri ve yanlış kalmış alt alan adlarını kontrol ederim:

dig +short example.com A
dig +short www.example.com A
dig +short example.com AAAA

Bu çıktı beklediğiniz proxy adreslerini göstermiyorsa DNS ve origin tasarımını birlikte gözden geçirin. IPv6’yı unutmak, IPv4 için yaptığınız korumayı boşa çıkarabilir.

İzleme, loglama ve saldırı sonrası temizlik

DDoS savunması olay anında yazılan birkaç firewall kuralından ibaret değildir. Normal davranışı bilmezseniz anormalliği seçemezsiniz. Uptime Kuma erişilebilirliği, Prometheus ile node_exporter CPU, RAM, ağ ve disk ölçümlerini izler; Grafana da bunları zaman çizelgesinde görmemi sağlar. Evdeki Proxmox laboratuvarımda bu üçlü, alarm eşiklerini güvenli biçimde denememe yarıyor.

Takip etmeniz gereken göstergeler şunlardır:

• Gelen ve giden ağ trafiği ile paket sayısı
• TCP bağlantı durumları ve conntrack kullanımı
• Web sunucusu istek sayısı, 4xx/5xx oranı ve yanıt süreleri
• CPU kullanımının yanında load average ve iowait değeri
• RAM, swap ve disk I/O tüketimi
• Uygulama worker sayısı, kuyruk uzunluğu ve veritabanı bağlantıları

RAM bittiğinde swap alanının devreye girmesi sistemi kurtarıyor gibi görünebilir; yoğun swap kullanımı gecikmeyi büyütür. VPS’te Swap Alanı Oluşturma ve Linux Bellek Yönetimi yazısında anlattığım gibi swap’i fiziksel RAM yerine koymamak gerekir. DDoS sırasında yükselen swap, uygulama kaynaklı bir HTTP saldırısının da işareti olabilir.

Olay bitince engellediğiniz geçici kuralları, test için eklediğiniz limitleri ve DNS değişikliklerini kayıt altına alın. Logları saldırı süresince kaybetmemek için uzak log sunucusu veya sağlayıcı loglama hizmeti kullanmak iyi fikirdir. Saldırganın IP listesini kalıcı firewall listesine çevirmek çoğu zaman bakım yükü üretir; IP’ler değişir, gerçek kullanıcılar yanlışlıkla engellenir.

Web uygulamasındaki açık noktaları da kontrol edin. Eski bir eklenti veya pahalı bir endpoint, saldırıyı mümkün kılmasa bile etkisini büyütebilir. Linux Sunucu Güvenliği için Zorunlu 10 Temel Adım içindeki güncelleme, minimum yetki ve log izleme kontrolleri burada doğrudan işinize yarar.

Ne zaman VPS’i büyütmek, ne zaman mimariyi değiştirmek gerekir?

CPU’yu iki katına çıkarmak uygulama katmanındaki küçük bir flood için zaman kazandırabilir. Bant genişliğini dolduran bir saldırıda ise daha güçlü VPS çoğu zaman yalnızca daha pahalı bir hedef olur. Önce darboğazı bulun.

İş yükünüz düzenli olarak yüksek trafik alıyorsa CDN, load balancer, ayrı veritabanı, rate limit servisi ve çoklu origin gibi bileşenler gündeme gelebilir. Her site için bunların tamamı gerekmez. Tek bir VPS üzerinde çalışan küçük bir uygulamada önce gereksiz portları kapatmak, pahalı sorguları düzeltmek ve sağlayıcının DDoS politikasını öğrenmek daha akıllı bir başlangıçtır.

Yedekleri de bu planın dışında bırakmayın. DDoS doğrudan veriyi silmeyebilir; panik sırasında yanlış komut çalıştırmak, firewall değişikliğiyle servisleri bozmak veya saldırı sonrasında sistemi yeniden kurmak yine mümkündür. Test edilmemiş yedek yalnızca dosya koleksiyonudur. Geri dönüş prosedürünü ayrı bir VPS’te deneyin ve mümkünse aylık bir restore provası yapın.

Yapılmaması gereken kısa yollar

• Her şeyi root olarak çalıştırmak: Saldırı sırasında hata yapma maliyetini artırır. Yönetim işlemlerinde sudo ve ayrı kullanıcılar kullanın.
• SSH portunu değiştirip güvende olduğunu sanmak: Gürültüyü azaltabilir ama kimlik doğrulama ve firewall açığını kapatmaz.
• Her gelen IP’yi elle engellemek: Dağıtık saldırıda liste hızla büyür ve yanlış pozitif üretir.
• Firewall’ı tamamen kapatmak: Teşhis için kısa süreli bir test bile olsa açık bırakılmış pencere unutulabilir.
• Log okumadan reboot etmek: Kök nedeni saklar ve bağlantı tablolarını sıfırlar.
• Limitsiz rate limit uygulamak: Gerçek kullanıcıları ve NAT arkasındaki müşterileri de engelleyebilirsiniz.

Benim pahalı hatalarımın çoğu teknik bilgi eksikliğinden değil, olay anında planın olmamasından çıktı. Kimin aranacağını, hangi IP’nin origin olduğunu, hangi portların gerekli olduğunu ve geri dönüş adımlarını saldırı yokken yazılı hale getirin. Küçük bir runbook, gece vardiyasında hafızadan daha güvenilirdir.

VPS için pratik DDoS kontrol listesi

1. VPS’inizin public IPv4 ve IPv6 adreslerini, açık portlarını ve kritik servislerini listeleyin.
2. Hosting sağlayıcınızın volumetrik saldırı eşiğini, otomatik filtreleme politikasını ve acil iletişim kanalını öğrenin.
3. SSH’yi anahtar doğrulama ve yönetim IP’si kısıtlamasıyla koruyun.
4. Gereksiz servisleri kapatın; MySQL, Redis ve yönetim panellerini doğrudan internete açmayın.
5. nginx veya uygulama katmanında giriş, arama ve API endpoint’leri için makul kotalar tanımlayın.
6. CDN kullanıyorsanız origin IP’sini gizleyin ve firewall’ı yalnızca proxy ağlarına göre düzenleyin.
7. Prometheus, Grafana veya mevcut monitoring sisteminizde ağ, bağlantı, CPU, RAM ve hata oranı alarmları oluşturun.
8. Saldırı sırasında kullanılacak komutları ve sağlayıcıya gönderilecek bilgileri bir runbook’a yazın.
9. Yedekleri farklı bir konumda tutun ve geri yüklemeyi düzenli olarak test edin.

DDoS saldırısı nedir sorusunun kısa cevabı, hizmeti erişilemez kılmak için dağıtık kaynaklardan trafik veya istek üretmektir. VPS’i korumanın yolu ise tek bir firewall kuralından geçmez: kapasiteyi doğru yerde filtreleyen sağlayıcı, ölçülü yerel kurallar, cache, uygulama limitleri ve sakin bir müdahale planı birlikte gerekir.

Şimdi kendi sunucunuzda ss -lntup çalıştırın ve gerçekten dışarıdan erişilmesi gereken servisleri işaretleyin. Ben bu kontrolü düzenli yapmaya başladığımda, “geçici” diye açılmış iki yönetim portunun aylarca açık kaldığını görmüştüm. Geçicilik, kayıt altına alınmadığında kalıcı bir yapılandırma biçimine dönüşüyor.

Sık Sorulan Sorular

DDoS saldırısı ile normal trafik artışını nasıl ayırt ederim?

Grafiklerdeki ani yükselişi tek başına ölçüt almayın; kaynak IP dağılımını, istek yollarını, User-Agent bilgisini, HTTP hata oranını ve uygulama kaynak kullanımını birlikte inceleyin. Kampanya trafiğinde genellikle anlamlı URL’ler ve tutarlı istemci davranışı görülürken saldırıda çok sayıda anormal örüntü bulunabilir.

VPS firewall’ı DDoS saldırısını tamamen engeller mi?

Hayır. Firewall küçük ve orta ölçekli bağlantı ya da uygulama katmanı baskısını azaltabilir, fakat internet hattınızı dolduran volumetrik saldırıyı VPS’e ulaştıktan sonra durduramaz. Bu durumda veri merkezi veya upstream seviyesinde filtreleme gerekir.

CDN kullanmak VPS’in DDoS koruması için yeterli midir?

Web trafiği açısından ciddi bir katman ekler, fakat origin IP’niz açığa çıkmışsa saldırgan CDN’i atlayabilir. DNS kayıtlarını, eski alt alan adlarını, e-posta ve diğer servisleri kontrol edip origin firewall’ını proxy ağlarıyla sınırlandırmanız gerekir.

DDoS sırasında sunucuyu yeniden başlatmalı mıyım?

Genellikle ilk adım bu olmamalı. Önce trafik, bağlantı durumları, kernel logları ve sağlayıcı grafikleriyle kanıt toplayın; yeniden başlatma yalnızca kaynakları geçici olarak temizler ve saldırının nedenini çözmez.