DDoS saldırısı nedir? Teknik, katmanlar ve savunma
Bir DDoS saldırısının teknik olarak nasıl işlediği, hangi dört sonlu kaynağı doldurduğu, onu kendi ölçüm değerlerinizden nasıl tanıyacağınız ve savunmanın sunucuda nerede bittiği. İşletimden gerçek saldırı vakalarıyla.
Bir DDoS saldırısı, yapay olarak üretilen aşırı yük yoluyla bir hizmeti erişilemez kılma denemesidir ve bunu aynı anda çok sayıda farklı gönderen üstlenir. Kısaltma Distributed Denial of Service ifadesinin karşılığıdır: dağıtık biçimde meydana getirilen bir Denial of Service'tir. Saldırılan şey ne bir sunucunun içeriği ne de yazılımındaki bir güvenlik açığıdır, sonlu olan bir kaynaktır: hattın bant genişliği, ağ kartının paket hızı, kernel'in bir durum tablosundaki bir yer ya da uygulamanın tek bir istek için harcadığı işlem zamanı. Bu dört kaynaktan biri dolduğunda gerçek kullanıcılar artık geçemez, üstelik kimsenin sisteme girmesine gerek kalmadan.
Bu yazı konuya giriştir. Saldırıların gerçekleştiği üç katmanı, hangi amplifikasyon faktörleriyle bir baytlık bir istekten 51.000 baytlık bir yanıtın oluştuğunu, saldırı kapasitesinin nereden geldiğini ve piyasada ne kadara mal olduğunu, bir saldırıyı kendi ölçüm değerlerinizden nasıl tanıyacağınızı, sunucunun kendisinde neyin hâlâ yardımcı olduğunu ve bu sınırın tam olarak nerede geçtiğini anlatıyor. Bütün sayılar kaynağıyla birlikte verilmiştir, böylece onları doğrulayabilirsiniz. Hizmetiniz şu anda duruyorsa önce “Saldırı durumunda ne yapılmalı” bölümünü okuyun ve ayar değiştirmek yerine ölçün.
Bir DDoS saldırısı teknik olarak nedir
Her DDoS saldırısı bir asimetriden beslenir: Bir paket göndermek saldırgana, o paketi işlemenin hedefe mal olduğundan daha aza mal olmalıdır. Geri kalan her şey yalnızca bu asimetrinin hangi noktada en büyük olduğu sorusudur. Tam olarak dört nokta vardır ve her birinin hesaplanabilen sert bir üst sınırı bulunur.
Hattın bant genişliği. 1 Gbit/s'lik bir bağlantı saniyede 125 megabayt taşır, daha fazlasını değil. Daha fazlasını gönderen kayıp üretir ve kayıplar, saldırganınkiler kadar kullanıcılarınızın paketlerini de vurur, çünkü dolu bir bağlantı seçim yapmaz.
Paket hızı. İzin verilen en küçük Ethernet paketi 64 bayt uzunluğundadır ve preamble ile paket arası boşlukla birlikte hatta 84 bayt yer kaplar. 1 Gbit/s içine bunlardan saniyede yaklaşık 1,49 milyon sığar. Sıradan bir sunucu kernel'i, düşürmeye başlamadan önce CPU ve ağ kartına göre birkaç yüz bin tanesini işler. Paket hızı bu yüzden neredeyse her zaman bant genişliğinden önce ulaşılan sınırdır.
Durum tabloları. Kernel, yarı açık TCP bağlantılarını ve paket akışlarını hatırlar. Bu tablolar saniyedeki bit cinsinden değil, sayıca sınırlıdır. Her paket yeni bir gönderen adresi taşıyorsa çok az bant genişliğiyle doldurulabilirler.
Uygulamanın işlem zamanı. Bir arama isteği, parola denetimli bir oturum açma denemesi ya da bütün bir mod listesini geri veren bir sunucu sorgusu, hedefe gönderene kıyasla bin kat pahalıya mal olur. Burada etkili bir saldırının çoğu zaman 10 Mbit/s'ye bile ihtiyacı yoktur.
DoS ve DDoS: ölçülebilen fark
Kavramsal temeli RFC 4732, “Internet Denial-of-Service Considerations”, IETF'in Kasım 2006 tarihli bilgilendirici yayını veriyor. Orada kelimesi kelimesine şöyle yazıyor: “A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.” Yani bir DoS saldırısı kaynak sayısıyla değil, etkisiyle tanımlanır. Dağıtık, yani DDoS olması, bu kaynaklar çok sayıda ve birbirinden bağımsız olduğunda söz konusudur.
Pratikte fark tam olarak tek bir noktada sayılır: engelleme listenizin uzunluğunda. Tek kaynaktan gelen bir DoS saldırısını tek bir kuralla bitirirsiniz. Cloudflare, Mayıs 2025'te 161 ülkeden ve 5.433 otonom sistemden gelen 122.145 farklı kaynak adresli bir saldırıyı belgeledi: ortalama saniyede 26.855 yeni adres, zirvede 45.097. Böyle bir şeye karşı yeterince hızlı büyüyen bir engelleme listesi yoktur ve içindeki her kayıt, zaten aşırı yüklü olan cihazda ek bellek ve arama süresi harcar.
CISA, FBI ve MS-ISAC'ın ortak kılavuzu “Understanding and Responding to Distributed Denial-of-Service Attacks”, saldırıları tam olarak üç tekniğe ayırıyor: hacimsel, protokole dayalı ve uygulamaya dayalı. Bu üçlü ayrım var olanların en kullanışlısıdır, çünkü aynı zamanda dört kaynağınızdan hangisine saldırıldığını ve savunmanın nerede durması gerektiğini de tarif eder.
Bir DDoS saldırısının üç katmanı
Layer 3 ve 4 üzerindeki hacimsel saldırılar
Hacimsel bir saldırı, hedefin önündeki hattı doldurmaktan başka bir şey istemez. Ölçü birimi saniyedeki bittir. Aracı kural olarak bir UDP flood'udur, çünkü UDP talep edilebilecek bir bağlantı kurulumu tanımaz ve gönderen adresleri sahte olabilir.
Şu anda kamuya açık biçimde belgelenmiş en büyük örnek: Cloudflare, 2025 sonuna kadarki dönem için otomatik olarak savuşturulan ve 35 saniye süren 31,4 Tbit/s'lik bir saldırı bildiriyor. Bu, 1 Gbit/s'lik yaklaşık 31.400 sunucu bağlantısının kapasitesine denk gelir, aynı anda ve yarım dakikayı aşkın süreyle. Aynı raporda, büyüklük mertebesini zirve değerden daha iyi kavratan ikinci bir değer var: 2025 yılında aynı işletmeci 47,1 milyon DDoS saldırısı savuşturdu, bir önceki yıla göre %121 artış, ortalama saatte 5.376 saldırı.
Mayıs 2025'ten gelen daha iyi belgelenmiş vaka, böyle bir saldırının parçalarına ayrıldığında nasıl göründüğünü gösteriyor: zirvede 7,3 Tbit/s, 45 saniyede 37,4 terabayt veri, yani ortalama saniyede yaklaşık 830 gigabayt. 1 Gbit/s'lik bir hat aynı veri miktarı için üç günden fazlasına ihtiyaç duyardı. Trafiğin %99,996'sı saf UDP flood'uydu ve aynı anda ortalama 21.925, zirvede 34.517 hedef porta dağılmıştı. Bütün portlara yayılan bu dağılım tipiktir: Saldırgan hangi portun önemli olduğunu bilmez, o yüzden hepsini alır.
Protokol saldırıları: hat değil, tablolar
Bir protokol saldırısı, kernel'in durumları hatırlamak zorunda olmasından yararlanır. Standart örnek SYN flood'udur: Saldırgan, SYN biti ayarlanmış ve gönderen adresi sahte TCP paketleri gönderir, sunucu her biri için yarı açık bağlantı kuyruğunda bir kayıt açar, hiç yanıt vermemiş bir adrese SYN-ACK ile karşılık verir ve bekler. Burada ölçü gigabit değil, saniyedeki pakettir.
Bu kuyruğun uzunluğu net.ipv4.tcp_max_syn_backlog içinde yazar ve sıradan bir sunucuda dört basamaklı bir aralıktadır. 1.024 yerlik bir kuyruk, saniyede 1,49 milyon SYN paketinde bir milisaniyeden kısa sürede dolar. Bunun için hesap olarak 1 Gbit/s yeter ve hedef yalnızca tabloysa bunun küçük bir kısmı yeter.
Aynı aileye, ancak 2021'de tarif edilmiş bir yöntem daha girer: durum tutan ara cihazlar üzerinden TCP yansıtması. “Weaponizing Middleboxes for TCP Reflected Amplification” çalışması, TCP durumunu yalnızca yarım izleyen güvenlik duvarlarının ve sansür altyapısının tek bir sahte pakete sayfalarca yanıtla karşılık verdiğini gösteriyor. Böylece o zamana kadar pratikte imkânsız sayılan bir şey, amplifikasyon için TCP'nin kötüye kullanılması da ilk kez mümkün oluyor.
Layer 7 üzerindeki uygulama saldırıları
Bir uygulama saldırısı sıradan trafik gibi görünür, çünkü sıradan trafiktir, yalnızca yanlış miktarda. Ölçü birimi saniyedeki istektir. Tam olarak kurulmuş bir bağlantı üzerinden gelir, yani yalnızca bağlantı kurulumunu değerlendiren her denetimi atlatır ve az bant genişliğine ihtiyaç duyar: Saniyede 10.000 HTTP isteği, istek boyutuna göre 50 Mbit/s'nin altındadır ve buna rağmen bir veritabanını dize getirmeye yeter.
Bunun ölçütü HTTP/2 Rapid Reset'tir, 10 Ekim 2023'te CVE-2023-44487 olarak açıklandı. Zafiyet HTTP/2'nin çoğullama yeteneğinde yatıyor: Saldırgan bir veri akışı açar, isteği gönderir ve akışı hemen yeniden iptal eder. Sunucu işe çoktan başlamıştır, saldırgan ise pencerede hemen yeniden boş bir yere sahiptir. Bununla ulaşılan değerler saniyede 201 milyon istek (Cloudflare), 398 milyon (Google) ve 155 milyon (Amazon) düzeyindeydi. Karşılaştırma için: Cloudflare'in o zamana kadar ölçtüğü en yüksek Layer 7 saldırısı saniyede 71 milyon istekti.
Oyun sunucularında Layer 7 katmanı bağlantı kurulumunun kendisidir. Minecraft ağlarına karşı Nullping, QuietException ve sahte handshake flood'ları neredeyse hiç bant genişliği gerektirmez ve bütün proxy birliklerini felç eder, çünkü her paket proxy'yi pahalı bir durum kararına zorlar. Bu kalıpların tam olarak nasıl göründüğü Minecraft DDoS koruması ve Nullping koruması yazısında duruyor.
Üç katmanın karşılaştırması
| Katman | Neye saldırılıyor | Ölçü birimi | Tipik yöntemler | Savunmanın nerede durması gerektiği |
|---|---|---|---|---|
| Hacimsel (Layer 3 ve 4) | Hattın bant genişliği | Gbit/s ve Tbit/s | UDP flood'u, DNS, NTP, memcached, CLDAP üzerinden amplifikasyon saldırıları | yalnızca sunucunun önündeki ağda |
| Protokol (Layer 3 ve 4) | Kernel'in, güvenlik duvarının ve yük dengeleyicinin durum tabloları | saniyedeki paket | SYN flood'u, ACK flood'u, parçalanmış paketler, ara cihazlar üzerinden TCP yansıtması | kısmen sunucuda, saniyede birkaç yüz bin paketten sonra sunucunun önünde |
| Uygulama (Layer 7) | İşlem zamanı, veritabanı, uygulamanın bağlantı kurulumu | saniyedeki istek | HTTP flood'u, HTTP/2 Rapid Reset, oturum açma seli, sorgu flood'u, slot tükenmesi | uygulamada ve önündeki filtrelemede, ikisi birlikte |
Gerçek saldırılar bu sınıflandırmaya uymaz. Pratikte en rahatsız edici durum çok katmanlı saldırıdır: hattı meşgul eden hacimsel bir pay, buna ek olarak dikkatin bant genişliğinde olduğu anda geçen bir Layer 7 payı. Aşağıda gösterilen, KernelHost'ta filtrelenmiş saldırılardan biri aynı anda on ikiden fazla farklı ana kalıptan oluşuyordu.
Amplifikasyon saldırıları: bir bayttan 51.000 bayt nasıl olur
Amplifikasyon saldırısı, saldırganın hedefe kendisi ateş etmediği, bunun yerine yabancı ve herkese açık erişilebilir hizmetleri bunu onun yerine yapmaya ittiği bir saldırıdır. Açık bir hizmete küçük bir istek gönderir ve gönderen olarak kurbanın IP adresini yazar. Hizmet görevi gereği yanıt verir, yalnızca kurbana, ve yanıt istekten kat kat büyüktür.
Yanıt boyutu ile istek boyutu arasındaki orana Bandwidth Amplification Factor, kısaca BAF denir. 50'lik bir BAF, kendi bağlantısı 1 Gbit/s olan bir saldırganın hedefe 50 Gbit/s yönlendirdiği anlamına gelir. Bunun işlemesi için iki şeyin bir araya gelmesi gerekir: sorulduğundan fazlasını yanıtlayan, UDP üzerinde çalışan bir protokol ve gönderen adresini sahte yapabilme imkânı. IP spoofing bu yüzden her amplifikasyon saldırısının ön koşuludur, yalnızca bir gizleme taktiği değil.
Savunan taraf için bundan rahatsız edici bir özellik çıkar: Trafik gerçek, meşru sunuculardan gelir. Bunlar gerçek DNS çözümleyicileri, gerçek zaman sunucuları, gerçek oyun sunucularıdır. Yani kaynak adrese göre bir engelleme listesi ya yarım ülkeleri dışarıda bırakır ya da etki etmez.
Kötüye kullanılan protokollerin amplifikasyon faktörleri
Aşağıdaki faktörler, 2014'ten bu yana sürekli genişletilen US-CERT, yani CISA uyarısı TA14-017A “UDP-Based Amplification Attacks” içinden geliyor. Bütün sektörün dayandığı referans budur.
| Protokol | Amplifikasyon faktörü | Kötüye kullanılan işlem |
|---|---|---|
| memcached (Port 11211) | 10.000 ila 51.000 | Önbelleğe alınmış içeriklerin çağrılması |
| NTP (Port 123) | 556,9 | monlist sorgusu |
| CharGEN (Port 19) | 358,8 | Karakter üreteci |
| WS-Discovery (Port 3702) | 10 ila 500 | Ağda cihaz araması |
| QOTD (Port 17) | 140,3 | Alıntı sorgusu |
| RIPv1 (Port 520) | 131,24 | Hatalı rota isteği |
| CLDAP (Port 389) | 56 ila 70 | Hatalı dizin isteği |
| Quake protokolü | 63,9 | Sunucu bilgisi |
| TFTP (Port 69) | 60 | Dosya talebi |
| LDAP (Port 389) | 46 ila 55 | Hatalı dizin isteği |
| DNS (Port 53) | 28 ila 54 | Büyük yanıt veren sorgu |
| SSDP (Port 1900) | 30,8 | SEARCH isteği |
| Portmap / RPCbind (Port 111) | 7 ila 28 | Hatalı istek |
| Kad | 16,3 | Düğüm listesinin değişimi |
| mDNS (Port 5353) | 2 ila 10 | Unicast üzerinden sorgu |
| SNMPv2 (Port 161) | 6,3 | GetBulk isteği |
| Steam protokolü | 5,5 | Sunucu sorgusu |
| NetBIOS (Port 137) | 3,8 | Ad çözümleme |
| BitTorrent | 3,8 | Dosya araması |
Tablo, iyi bakılan her güvenlik duvarında kapatılmış portların listesinin neden benzer göründüğünü açıklıyor. Kendiniz yapabileceğiniz şey sınırlı ama önemli: ss -lnup ile sunucunuzda bu tablodan bir hizmetin ağa açık durup durmadığını kontrol edin. 127.0.0.1 adresine bağlanmamış bir memcached, sunucunuzu üçüncü kişilere karşı bir silaha dönüştürür, kendi giden bant genişliğinize mal olur ve IP adresinizi, çıkması zor engelleme listelerine sokar.
Oyun sorgu protokolleri neden bu listeye ait
Oyun sunucuları bu tabloda iki rolle birden bulunur. Amplifikasyon aracıdırlar, çünkü sorgu portları küçük bir pakete ad, harita, oyuncu sayısı ve mod listesinin tamamıyla yanıt verir. Ve kurbandırlar, çünkü aynı sorgu işlem zamanına mal olur, çoğu zaman tam da oyun simülasyonunu taşıyan çekirdekte.
Steam protokolünün amplifikasyon faktörü 5,5 ile düşük, daha eski Quake protokolününki 63,9 ile yüksektir. Etki ise yalnızca faktöre değil, tek tek durumdaki yanıt boyutuna bağlıdır: 200 modlu bir sunucu, modsuz olandan belirgin biçimde daha büyük bir yanıt verir. Bohemia Interactive, Arma 3 için T83469 kaydı altında 2015'ten bu yana Steam sorgu portuna gönderilen 4 Mbit/s sahte sorgunun bile bir sunucuyu dondurmaya yettiğini belgeliyor. Saniyede dört megabit, tek bir ev bağlantısının üretebileceğinden azdır.
Bundan her oyun için geçerli olan kural çıkar: Sorgu portunu sınırlayın, kapatmayın. Kapatan kişi sunucu listesinden düşer ve yeni oyuncular tarafından artık bulunamaz. Bu portun oyun başına hangisi olduğu ve ne kadar sıkı işletilebileceği aşağıdaki oyuna özgü yazılarda duruyor, örneğin Arma 3, CS2 ve Source başlıkları ya da Rust yazılarında.
memcached örneği: GitHub'a karşı 1,35 Tbit/s
28 Şubat 2018'de GitHub saat 17.21 ile 17.26 UTC arasında erişilemez, saat 17.30 UTC'ye kadar da yalnızca zaman zaman erişilebilirdi. Saldırı saniyede 126,9 milyon pakette 1,35 Tbit/s'ye ulaştı ve 1.000'den fazla farklı otonom sistemden, on binlerce ayrı uç noktadan geldi. Amplifikasyon memcached üzerinden yapıldı, 51.000'e varan bir faktörle: Saldırganın bir baytı, hedefe doğru 51 kilobayta kadar üretiyordu.
Bu vaka bugün hâlâ en iyi ders örneğidir, çünkü üç şeyi aynı anda gösterir. Birincisi: Amplifikasyon, botnet büyüklüğünü yener. Saldırganın yüz bin cihaza ihtiyacı yoktu, açık memcached örneklerine ihtiyacı vardı ve o zamanlar dünya çapında 90.000'den fazlası ağda duruyordu. İkincisi: Saniyede 126,9 milyon paket, 1 Gbit/s'lik bir hattın taşıyabileceğinin yaklaşık 85 katıdır. Sunucudaki hiçbir ayar bunu değiştirmez. Üçüncüsü: Savunma işe yaradı, çünkü trafik bir filtreleme ağına yönlendirildi ve kesinti süresi böylece dokuz saat yerine dokuz dakikada bitti.
Bir DDoS saldırısının kapasitesi nereden geliyor
Ele geçirilmiş cihazlardan oluşan botnetler
Botnet, bir saldırganın merkezden uzaktan yönettiği, zararlı yazılımla ele geçirilmiş yabancı cihazlardan oluşan bir birliktir. Sahipleri bunu kural olarak fark etmez, çünkü cihaz satın alındığı işi yapmayı sürdürür. Saldırıya uğrayan öncelikle sürekli ağda duran, seyrek güncellenen ve öntanımlı parola taşıyan cihazlardır: yönlendiriciler, güvenlik kameraları, ağ kaydediciler, televizyon kutuları.
Ölçüt Mirai'dir; kaynak kodu Eylül 2016 sonunda yayımlandı. “Understanding the Mirai Botnet” çalışması (USENIX Security 2017) ağı yedi ay boyunca izliyor ve en yüksek seviyeyi 600.000'den fazla enfekte cihaz olarak veriyor. Eylül 2016'da Brian Krebs'in sayfasına yapılan saldırı 620 Gbit/s'ye ulaştı ve 175.000'den fazla cihazdan geldi. Twitter, Spotify ve Reddit'i aynı anda erişilemez kılan, 21 Ekim 2016'da DNS işletmecisi Dyn'e yapılan saldırıda ise yaklaşık 107.000 saldıran IP adresi sayıldı.
Dokuz yıl sonra büyüklük mertebesi başka. Cloudflare, 31,4 Tbit/s'lik rekor saldırıyı, çoğunluğu Android televizyon kutuları olan ve tahminî büyüklüğü bir ila dört milyon enfekte cihaz olan bir botnete bağlıyor. Aralık 2025'teki saldırı dalgasında 902 hiperhacimsel saldırı sayıldı, günde ortalama 53 tane, saniyede 9 milyar paket, 24 Tbit/s ve saniyede 205 milyon istek zirve değerleriyle. Botnet büyüklüğü böylece on yıl içinde 5 kat, ulaşılan bant genişliği 50 kat arttı.
Booter ve stresser hizmetleri ve bir saldırının maliyeti
Botnet ile sipariş veren arasında, saldırı kapasitesini abonelikle satan bir hizmet oturur. Bu hizmetler “booter”, “stresser” ya da “IP stresser” adıyla ortaya çıkar ve kullanım koşullarında kendi sistemlerinin yük testine hizmet ettiklerini öne sürer. Bunu yaparken girilen hedefin kullanıcıya ait olup olmadığını hiç denetlemezler ve bir araç ile bir teklif arasındaki fark tam olarak budur.
Kullanımı üç alanlı bir web arayüzüdür: hedef, port, süre. Ödeme işlemleri, müşteri desteği ve bayi programları vardır. Giriş paketleri ayda yaklaşık 10 ila 20 EUR, daha fazla bant genişliği ve daha uzun saldırı süresi olan büyük paketler ayda birkaç yüz EUR düzeyindedir. Bununla küçük projelerin de neden vurulduğu sorusu yanıtlanmış oluyor: Bir oyun sunucusuna cumartesi akşamını kaybettiren bir saldırı, tetikleyen kişiye iki sinema biletinden aza mal olur ve hiçbir teknik bilgi gerektirmez.
Diğer tarafta kalıcı bir takip baskısı var. Uluslararası PowerOFF operasyonunun Nisan 2026'daki eylem haftasında 21 ülkeden makamlar bu tür hizmetlerin 53 alan adını devraldı, dört kişiyi tutukladı ve 25 ev araması yaptı. Bu sırada soruşturmacılar üç milyondan fazla kullanıcı hesabının verilerine erişim elde etti ve tespit edilen 75.000'den fazla kullanıcıya yazı gönderildi. Aralık 2024'te aynı operasyonda 27 platform kapatılmıştı. Yani böyle bir hizmete para ödeyen kişi, er ya da geç el konulacak bir veritabanında bir ödeme izi bırakıyor.
Bir DDoS saldırısını nasıl fark edersiniz
Kullanıcılar ne bildiriyor ve bu şimdiden ne anlatıyor
İlk bilgi neredeyse her zaman kullanıcılardan gelir ve kulağa geldiğinden daha kullanışlıdır. Dört bildirimin açık bir anlamı vardır:
- “Herkes aynı anda atıldı.” Bütün kullanıcılarda aynı anda yaşanan bir kopma, tek tek bağlantılara değil, hatta ya da hizmet sürecine işaret eder. Bir yük sorunu kullanıcıları arka arkaya vurur.
- “Ping 20'den 400'e sıçrayıp geri dönüyor.” Bağlantı sürerken dalgalanan gecikme, aşırı yüklü bir sürecin değil, hedefin önündeki dolu bir kuyruğun kalıbıdır.
- “Sunucu listesi bizi çevrimdışı gösteriyor ama ben bağlanabiliyorum.” Bu, bir sorgu flood'una işaret eder: Sorgu portu artık yanıt vermiyor, oyun portu hâlâ veriyor.
- “Mobil hattan girebiliyorum, kendi bağlantımdan giremiyorum.” Erişim ağına göre farklı davranış, sunucunuzun değil, oraya giden bir yolun doyuma ulaştığını düşündürür.
Sunucudaki dört ölçüm değeri
Ardından ölçülür, hem de şu sırayla: paket hızı, bant genişliği, bağlantı durumları, düşürülen paket sayaçları. CPU'nun doluluk göstergesi en sona kalır, çünkü bir ağ saldırısında çoğu zaman dikkat çekmez.
sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max
sar -n DEV 1 10, on saniye boyunca arayüz başına saniyedeki paket ve bayt sayısını verir. Belirleyici olan orandır: Az bayta karşılık çok paket, küçük paket demektir, yani bir protokol saldırısı. Çok bayta karşılık az paket, büyük paket demektir, yani bir amplifikasyon saldırısı. ip -s link show, dropped ve overrun sütunlarında kernel'in çoktan düşürüp düşürmediğini gösterir. ss -tn state syn-recv yarı açık bağlantıları sayar: Üç basamaklı bir değer normaldir, beş basamaklı olan bir SYN flood'udur. Ve nstat, saldırı bittikten sonra da kalan sayaçları verir.
En önemli adım, neredeyse hiç kimsenin önceden atmadığı adımdır: her şey normal işlerken bir karşılaştırma temeli oluşturmak. Normal değer olmadan saniyede 40.000 paketin çok mu olduğunu yoksa yalnızca cumartesi akşamı mı olduğunu söyleyemezsiniz. apt-get install -y vnstat sysstat ile ölçüm kalıcı olarak birlikte çalışır. Değerlendirmeye dair ayrıntılı rehber DDoS saldırısını tanıma yazısında.
Kesin olan log satırları
Kernel logundaki ve web sunucusu logundaki dört mesaj pratikte kanıt niteliğindedir. dmesg -T | tail -50 ilk üçünü gösterir:
kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough
Birinci satır, yarı açık bağlantı kuyruğunun taştığı ve kernel'in SYN cookie'lerine geçtiği anlamına gelir. Orada bunun yerine Dropping request yazıyorsa net.ipv4.tcp_syncookies 0 olarak ayarlanmış demektir ve sunucu gerçek olanlar dâhil istekleri düşürür. İkinci satır, bağlantı izlemenin dolu olduğu anlamına gelir ve bu andan itibaren sunucu meşru trafiği de düşürür. Üçüncü satır bir yan etkidir: Kernel mesajları bastırır, yoksa log tutmakla meşgul olurdu. Dördüncü satır sorunu uygulamaya taşır.
Web sunucusunun erişim logunda iki şey anlamlıdır. 499 durum kodunun ani bir payı, istemcinin yanıt tamamlanmadan bağlantıyı kapattığı anlamına gelir ve yalnızca iş çıkarmak isteyen, okumak istemeyen bir Layer 7 saldırısı tam olarak bunu yapar. Neredeyse bütün isteklerde boş bir referrer alanı ise bir saldırıyı, arama motorlarından ve sosyal ağlardan referrer getiren gerçek bir ziyaretçi akınından ayırır.
Karşı sınama: saldırı mı, akın mı, kendi hatanız mı
| Gözlem | Olası neden | Sonraki ölçüm adımı |
|---|---|---|
| Gelen paket hızı yüksek, CPU yükü düşük | hacimsel ya da protokol saldırısı | Paket boyutunu bayt bölü paket olarak hesaplayın |
| CPU yükü yüksek, paket hızı normal | Layer 7 saldırısı ya da uygulamadaki kendi hatanız | Erişim logunu tekrar eden URL ve 499 durum kodu için gözden geçirin |
127.0.0.1 üzerinden hizmet hızlı yanıt veriyor, dışarıdan vermiyor |
sorun ağdadır, uygulamada değil | Arayüzün düşürülen paket sayaçlarını ve dışarıdan gecikmeyi kontrol edin |
| Yük, hizmet yeniden başlatıldıktan hemen sonra geri geliyor | dışarıdan saldırı | Bağlantıları değil, kaynak adresleri sayın |
| Çok az adresten çok sayıda bağlantı | tek tek kaynak, engellenebilir | Kaynak adres başına hız sınırlaması koyun |
| Çok sayıda adresten çok az bağlantı | dağıtık saldırı, engellenemez | Sunucunun önünde filtreleme, sağlayıcıyı dâhil edin |
| Giden yön gelenden belirgin biçimde fazla | gerçek ziyaretçi akını ya da sunucunuz üçüncü kişilere karşı amplifikasyon aracı | ss -lnup ile açık UDP hizmetlerini kontrol edin |
| Başlangıç tam olarak bir yeniden başlatma, güncelleme ya da cron çalışmasından sonra | kendi hatanız | Değişikliği geri alın ve yeniden ölçün |
Sunucunun kendisinde ne işe yarar
Sunucuda çoğu zaman iddia edilenden fazlası başarılabilir, hem de küçük kalan her şeye karşı: özensiz botlar, tek tek kaynaklar, sorgu flood'ları ve uygulama saldırıları. Bunun araçları nftables, bağlantı izleme, SYN cookie'leri ve kaynak adres başına hız sınırlamasıdır. Aşağıdaki bütün bilgiler Debian 12, Debian 13, Ubuntu 22.04 LTS ve Ubuntu 24.04 LTS için geçerlidir ve root kullanıcısı için yazılmıştır.
nftables: erken düşür, az hesapla
İlke şudur: Düşürülecek bir paket olabildiğince erken ve olabildiğince ucuz düşürülmelidir. Ondan önce çalışan her kural, işlem zamanı çarpı paket hızı kadara mal olur. /etc/nftables.conf için aşağıdaki kural seti bir web sunucusunu ve bir oyun hizmetini geçirir, geri kalanı düşürür ve yeni TCP bağlantıları için kaynak adres başına bir hız sınırlaması içerir:
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
set adminips {
type ipv4_addr
flags interval
elements = { 203.0.113.10 }
}
set newconn {
type ipv4_addr
size 131072
flags dynamic,timeout
timeout 1m
}
chain input {
type filter hook input priority filter; policy drop;
iif lo accept
ct state established,related accept
ct state invalid counter drop
ip saddr @adminips tcp dport 22 accept
tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
tcp dport { 80, 443 } accept
udp dport 25565 accept
icmp type echo-request limit rate 5/second accept
icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept
counter drop
}
chain forward { type filter hook forward priority filter; policy drop; }
chain output { type filter hook output priority filter; policy accept; }
}
Yüklemeden önce adminips altına kendi sabit adresinizi yazın, yoksa kendinizi SSH'tan dışarıda bırakırsınız. Kontrol ve etkinleştirme şöyle yapılır:
nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn
Etkiyi üç nokta belirler. ct state established,related accept bilinçli olarak ikinci kural olarak durur, böylece mevcut bağlantılar bütün kural setinden geçmez. ct state invalid counter drop, tek tek tarif etmenize gerek kalmadan hatalı bayrak birleşimlerini ve gecikmiş parçaları temizler. Ve her drop öncesindeki counter, sonradan hangi kuralın işlediğini bilmenizin nedenidir: Sayaçlar sıfırda kalıyorsa kurala ulaşılmıyordur ve bu, etkisiz bir kural setinden tamamen başka bir teşhistir.
SYN cookie'leri ve backlog'un sınırı
SYN cookie'leri, sunucunun yarı açık bir bağlantıyı hatırlamadığı, gerekli bilgileri şifreleyerek kendi yanıt numarasına yazdığı bir yöntemdir. Bağlantı kurulumunun üçüncü paketi geri geldiğinde durumu bundan yeniden hesaplar. Böylece kuyruk artık taşmaz, çünkü bu bağlantılar için bir kuyruk yoktur.
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
Bu değerler /etc/sysctl.d/ altındaki bir dosyaya girer ve sysctl --system ile devralınır, yoksa bir sonraki yeniden başlatmadan sonra kaybolurlar. Debian ve Ubuntu'da tcp_syncookies fabrika ayarında 1'dir ve bu doğrudur. 1 değeri “her zaman cookie” demek değildir, “kuyruk taşar taşmaz cookie” demektir.
Bunun bedeli gerçektir ve seyrek dile getirilir. Bir cookie'de karşı tarafın TCP seçenekleri için yer yoktur. Linux, pencere ölçeklendirmeyi ve seçici onaylamayı yalnızca net.ipv4.tcp_timestamps 1 olduğunda kurtarır, çünkü bilgiler o zaman zaman damgasıyla birlikte yol alır. Zaman damgası olmadan düşerler ve bağlantı, ömrünün geri kalanında daha yavaş çalışır. Ayrıca azami paket boyutu için yalnızca üç bit vardır, yani tam değer yerine sekiz kaba kademe. SYN cookie'leri bağlantıları kurtaran bir acil durum işletimidir, normal durum için bir ayar değil.
conntrack: ilk dolan tablo
Kernel'in bağlantı izlemesi her paket akışı için bir kayıt açar, UDP bağlantı tanımasa da UDP için de. Dağıtık bir saldırıda ilk biten kaynak tam olarak bu tablodur ve çok hızlı biter: Her biri yeni gönderen adresli saniyede 1,49 milyon pakette, 262.144 yerlik bir tablo saniyenin beşte birinden kısa sürede dolar.
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
Bir kayıt yaklaşık 300 bayt yer kaplar, 524.288 kayıt yani yaklaşık 150 megabayt kernel belleği. Hash tablosunun boyutu sysctl ile değil, modül parametresi olarak ayarlanır, genellikle üst sınırın dörtte birine, /etc/modprobe.d/nf_conntrack.conf dosyasında:
options nf_conntrack hashsize=131072
Saf bir oyun ya da ses sunucusu için daha zarif çözüm, oyun trafiğini hiç izletmemektir. Bu, tabloyu tamamen tasarruf eder:
nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack
Dikkat: notrack ile durum tutan kurallar birbirini dışlar. Bir portu izlemeden çıkaran kişi, o port için artık ct state içeren bir kural kullanamaz, yoksa izin kuralı işlemez ve hizmet kapanır.
Kaynak adres başına hız sınırlaması
Kaynak adres başına hız sınırlaması, sunucudaki en etkili tek önlemdir, çünkü tam olarak bir saldırganın yaptığını vurur ve tam olarak bir kullanıcının yaptığını geçirir. Fark büyüktür: Gerçek bir sunucu tarayıcısı dakikada birkaç kez sorgular, bir saldırgan saniyede yüzlerce kez. nftables ile bunun için yukarıdaki kural setindeki gibi dinamik kümelerle, klasik iptables ile hashlimit ile çalışılır:
iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP
Böyle kurallardaki bütün sayılar başlangıç değerleridir, gerçek değil. Önce bir hafta normal işletimde ölçün, yoksa kendi kullanıcılarınızı dışarı atarsınız, hem de en kötü anda. Ayrıca saf iptables kurallarının bir yeniden başlatmadan sonra kaybolduğunu (apt-get install -y iptables-persistent, ardından netfilter-persistent save) ve UFW altında /etc/ufw/before.rules dosyasına ait olduklarını unutmayın, çünkü yoksa bir sonraki ufw reload komutunda kaybolurlar. Süren işletim için tam kural seti Sunucuyu DDoS saldırılarından koruma yazısında.
Sunucudaki her filtreleme nerede biter
Şimdi hiçbir yapılandırma dosyasının çözmediği kısım. Şimdiye kadarki bütün önlemler sunucunuzda, yani hattın ucunda çalışır. Bir güvenlik duvarı kuralı, kablodan çoktan geçmiş bir paket hakkında karar verir. Onu düşürebilirsiniz, ama gönderilmemiş yapamazsınız. Önündeki hat doluysa kullanıcılarınızın paketleri daha öncesinde ulaşamaz, hem de kural setinizin ne kadar iyi olduğundan bağımsız olarak.
| Bağlantı | Saniyedeki kullanıcı verisi | 64 baytta saniyedeki paket |
|---|---|---|
| 1 Gbit/s | 125 megabayt | 1.488.095 |
| 2 kez 1 Gbit/s | 250 megabayt | 2.976.190 |
| 10 Gbit/s | 1.250 megabayt | 14.880.952 |
| 25 Gbit/s | 3.125 megabayt | 37.202.381 |
| 100 Gbit/s | 12.500 megabayt | 148.809.523 |
Bu tablo, kendi korumasının yetip yetmediği sorusunu her tek durum için yanıtlıyor. GitHub'a yapılan, saniyede 126,9 milyon paketlik saldırı paket hızı bakımından 100 Gbit/s'lik bir bağlantıya kıl payı sığar, 1,35 Tbit/s hacminde ise bunlardan aynı anda on dört tanesi gerekirdi. 31,4 Tbit/s'lik rekor saldırı, 100 Gbit/s'lik tamamen doymuş 314 bağlantıya denk gelir. Bir oyun sunucusu tipik olarak 1 Gbit/s'ye ya da iki kez 1 Gbit/s'ye bağlıdır: Kendi korumasının sınırı böylece saniyede yaklaşık 1,5 ila 3 milyon pakette durur, pratikte ise belirgin biçimde altında, çünkü kernel daha önce pes eder.
İkinci ve daha rahatsız edici bir sınır daha var. Hat doyuma ulaştığı anda, ölçüm yapmak istediğiniz SSH oturumu bile size ulaşmayabilir. O durumda ağdan bağımsız bir erişimi, örneğin müşteri panelindeki bir VNC konsolunu olmayan kişi ne olduğuna bakamaz bile.
Yalnızca sunucunun önünde işe yarayan şey: ağda filtreleme ve scrubbing
Etkili filtreleme yalnızca saldırıdan fazla kapasiteye sahip olanın elinden gelir. Bu, çok sayıda hattın birleştiği bir noktayı, yani bir makineyi değil bir ağı gerektirir. Orada birbirini tamamlayan iki yöntem vardır.
Ağda gerçek zamanlı filtreleme. Bütün trafik, sunucuya iletilmeden önce her paketi değerlendiren bir filtreleme kademesinden kalıcı olarak geçer. Avantajı, bir geçiş olmamasıdır: Korumanın etki etmek için önce bir saldırıyı tanıması gerekmez. Oyunlarda belirleyici olan tam da budur, çünkü iki dakikalık bir geçiş süresi kaybedilmiş bir tur demektir ve 35 saniye süren bir saldırıda iki dakikalık geçiş süresi hiçbir savunma değildir.
Scrubbing. Ağ büyük bir hacimsel saldırı tanıdığında, etkilenen trafik filtreleme merkezlerine yönlendirilir, orada zararlı paylarından arındırılır ve ardından hedefe doğru teslim edilir. Bu yönlendirmenin anlamı yakınlıktır: Saldırı trafiği veri merkezinde değil, girdiği noktada son bulur. Filtreleme kuralları bunun için ağda dağıtılır, teknik olarak RFC 8955'te Flow Specification olarak tarif edilmiştir.
Sahte gönderen adreslerine karşı yapısal karşı önlem ise 2000 yılından bu yana biliniyor ve RFC 2827'de, yani BCP 38'de duruyor: Bir müşteriyi bağlayan taraf, bu sınırda gönderen adresi o müşteriye ait olmayan bütün paketleri düşürür. RFC 3704 bunu çok bağlantılı ağlara genişletir. Bütün ağ işletmecileri bunu uygulasaydı amplifikasyon saldırılarının bütün sınıfı biterdi. Bitmedi, çünkü bazılarının bunu yapmaması yetiyor.
Ve bilinmesi gereken üçüncü bir yöntem daha var, çünkü sık sık koruma diye satılıyor: null routing, teknik olarak RFC 5635'e göre Remote Triggered Black Hole Filtering. Bunda saldırıya uğrayan IP adresi ağda erişilemez olarak duyurulur, ona giden bütün trafik düşürülür, saldırı trafiği de kullanıcılarınızınki de. Bu, sağlayıcının ağını korur; sizin için sonuç başarılı bir saldırıyla aynıdır, genellikle sonrasında saatlerce de sürer. Tereddüt ederseniz filtreleme mi yapıldığını yoksa null routing mi uygulandığını sorun. Yanıt, erişilebilirliğiniz hakkında herhangi bir donanım bilgisinden daha çok şey belirler.
KernelHost buna karşı ne koyuyor
Her sunucu paketinde dâhil olan sürekli koruma
KernelHost'un DDoS koruması iki kademeli kuruludur ve siz herhangi bir şeyi açmak, sipariş etmek veya yapılandırmak zorunda kalmadan kalıcı olarak etkindir:
- 1. kademe: küresel scrubbing ağında 17 Tbps mitigasyon kapasitesi. Hacimsel saldırılar, veri merkezine ulaşmadan önce kaynaklarına yakın bir noktada temizlenir.
- 2. kademe: Frankfurt am Main'de 3,2 Tbps ile Arbor gerçek zamanlı filtreleme. Doğrudan sunucunun önünde protokole özgü kalıplar tanınır ve paket paket düşürülür.
İki özellik belirleyicidir. Koruma kalıcı olarak çalışır ve sunucunun teslim edilmesinden itibaren etkindir; yani bir saldırının başında hizmetin kayıp olduğu dakikalar yaşanmaz. Ayrıca null routing kullanılmaz: IP adresiniz ağda kalır, yalnızca zararlı paketler düşürülür. Hangi oyunların ve protokollerin kendi filtreleme profillerine sahip olduğunu Gerçek zamanlı oyun sunucusu DDoS koruması yazısı listeliyor.
Sürekli ateş altındaki projeler için Advanced DDoS Protection
Bazı projelere ara sıra değil, hedefli biçimde ve haftalar boyunca saldırılır, her akşam aynı saatte ve değişen kalıplarla. Bunun için ayda 50,00 EUR'dan başlayan, PrePaid, asgari süresi ve kurulum ücreti olmayan Advanced DDoS Protection var. Fark, daha fazla kapasitede değil, kontrolde:
- Dedicated koruma IP'si: Frankfurt çekirdek ağından verilir ve sunucunuz kendi ağı içinde bu adrese geçirilir. Sizin tarafınızda hiçbir değişiklik gerekmez.
- Kendiniz yönetebileceğiniz, port ve protokol başına koruma kuralları: Müşteri panelinde oyun portunda neye, sorgu portunda neye izin verildiğini ayrı ayrı ayarlarsınız ve böylece sorgu protokolleri bölümündeki asimetriden tam olarak yararlanabilirsiniz.
- Değişiklikler gerçek zamanlı etki eder, yani bir bakım penceresini beklemek yerine süren bir saldırı sırasında ince ayar yapabilirsiniz.
- Her hizmete uygun koruma profili, aynı şekilde herhangi bir TCP veya UDP portunda çalışan değiştirilmiş ve kendi yazdığınız uygulamalar için de.
Advanced DDoS Protection, KernelHost müşterilerine yöneliktir ve KernelHost'ta bir sunucu gerektirir. Projeniz şu anda başka bir yerde çalışıyor ve orada düzenli olarak saldırı altındaysa, doğru yol buraya taşınmaktır, mevcut adresinizin uzaktan bakımı değil.
İki kademenin karşılaştırması
| Özellik | Dâhil olan sürekli DDoS koruması | Advanced DDoS Protection |
|---|---|---|
| Fiyat | her sunucu paketinde dâhil, ek ücret olmadan | ayda 50,00 EUR'dan başlar, PrePaid |
| Filtreleme kapasitesi | 17 Tbps küresel scrubbing artı Frankfurt am Main'de 3,2 Tbps ile Arbor gerçek zamanlı filtreleme | aynı iki kademeli filtreleme |
| Şu andan itibaren etkin | sunucunun teslimi | koruma IP'sinin teslimi |
| IP adresi | sunucunuzun IP adresi | ek dedicated koruma IP'si |
| Kural seti | otomatik profiller, yapılandırma gerekmez | müşteri panelinde port ve protokol başına kendi kurallarınız |
| Değişiklikler | otomatik olarak birlikte ilerler | gerçek zamanlı etki eder, bir saldırı sırasında da |
| Null routing | hayır | hayır |
| Süre | sunucu paketine bağlı | PrePaid, asgari süre yok, fesih bildirim süresi yok, kurulum ücreti yok |
İşletimden dört gerçek filtrelenmiş saldırı
Aşağıdaki dört saldırı KernelHost müşterilerinin sunucularını vurdu ve her birinde kesinti olmadan, tamamen gerçek zamanlı filtrelendi. Görseller savunmanın canlı izlemesinden geliyor.
TeamSpeak 3 ses sunucusu, 9987 UDP portu. Aynı anda birden fazla kalıp içeren karmaşık saldırı, 473,4 Gbit/s'nin ve saniyede 41,5 milyon paketin üzerinde. Bu, 1 Gbit/s'lik bir bağlantının paket hızının yaklaşık 28 katıdır.

ARK oyun sunucusu, 7777 UDP portu. Karmaşık bir yapısı olmayan basit UDP flood'u, buna karşılık 112,2 Gbit/s'nin ve saniyede 8,7 milyon paketin üzerinde. Bir ARK kümesinin yanı sıra kendi başına nasıl güvene alındığı ARK sunucusunu DDoS'tan koruma yazısında.

Tüm portlara saldırı, 0-65535 TCP ve UDP portları. Aynı anda bütün portlara karşı on ikiden fazla farklı ana saldırı kalıbı, toplamda 21,3 Gbit/s'nin ve saniyede 3,9 milyon paketin üzerinde. Bu vaka, Mayıs 2025 tarihli Cloudflare vakasının ortalama 21.925 hedef portla gösterdiği dağılımı da ortaya koyuyor.

Minecraft ve OpenVPN, 25565 TCP ve 1194 UDP portları. On altıdan fazla farklı ana saldırı kalıbı, saniyede 4 milyonun üzerinde paket ve 8,6 Gbit/s'nin üzerinde hacim içeren birleşik saldırı. Farklı protokoller konuşmalarına rağmen her iki hizmet de kesintisiz erişilebilir kaldı.

Saldırı durumunda ne yapılmalı, hangi sırayla
Sıra, tek tek adımlardan daha önemlidir, çünkü en sık yapılan hatalar ilk beş dakikada olur.
- Ayar değiştirmeyin, ölçün. Önce
sar -n DEV 1 10,ip -s link show,ss -svedmesg -Tçıktılarındaki değerleri bir dosyaya kaydedin. Saldırıdan sonra kaybolurlar ve onlar olmadan kimse size yardım edemez. - Yeniden başlatmayın. Bir yeniden başlatma bütün sayaçları, bütün bağlantı durumlarını ve her kanıtı siler, yük ise birkaç saniye sonra geri gelir.
- Hangi katman olduğunu belirleyin. Bayt bölü paket, ortalama paket boyutunu verir. 100 baytın altı bir protokol saldırısına, 1.000 baytın üstü bir amplifikasyon saldırısına, yüksek CPU yükünde normal boyutlar ise Layer 7'ye işaret eder.
- Yönetim portlarını kapatın. Panel, veritabanı, RCON ve herkese açık olması gerekmeyen her şey kendi adresinize sınırlanmalıdır. Bu, saldırı yüzeyini hemen ve kullanıcılar için risk olmadan küçültür.
- Hız sınırlaması koyun: sorgu portunda dar, kullanım portunda geniş. Sorgu portunu kapatmayın, yoksa her sunucu listesinden düşersiniz.
- Kendi adresinizi aceleyle değiştirmeyin. Bir adres değişikliği yalnızca yeni adres yeniden herkese açık durmadığı sürece işe yarar ve unutulmuş eski bir DNS kaydı değişikliği etkisiz kılar.
- Sağlayıcıyı sayılarla dâhil edin. Zaman, hedef port, paket hızı, bant genişliği ve ortalama paket boyutu bilgileriyle bir talep açın. Bu beş bilgi, adresiniz için filtreleme kurallarının ne kadar hızlı yeniden ayarlanacağını belirler.
- Sonrasında belgeleyin. Ne zaman başladığını, ne kadar sürdüğünü ve hangi kalıp olduğunu not edin. Aynı saatte tekrar eden saldırılar, bir projenin dedicated bir koruma IP'sine ihtiyaç duyup duymadığının ölçütüdür.
Ağır ve uzun süren bir saldırı için ayrıntılı akış Ağır DDoS saldırısı: ne yapmalı yazısında.
Hukuki durum: bir DDoS saldırısı suçtur
Avusturya'da bir DDoS saldırısı, Avusturya Ceza Kanunu'nun (StGB) “bir bilgisayar sisteminin işleyişinin bozulması” başlıklı § 126b maddesi kapsamına girer. Temel suç tipi altı aya kadar hapis cezası ya da 360 gün karşılığına kadar para cezası öngörür. Bozulma daha uzun sürerse iki yıla kadar çıkar. Çok sayıda sisteme, görülebilir biçimde bunun için yazılmış bir programla saldırılırsa üç yıla kadar çıkar. 300.000 EUR'nun üzerinde bir zararda, kritik altyapıya yönelik bir saldırıda ya da bir suç örgütü üyesi olarak ise çerçeve altı aydan beş yıla kadardır. Tamamlayıcı olarak StGB § 126c, bunun için üretilmiş programların hazırlanmasını, yayılmasını ve erişilebilir kılınmasını da cezalandırır.
Almanya'da Alman Ceza Kanunu'nun (StGB) “bilgisayar sabotajı” başlıklı § 303b maddesi devreye girer: üç yıla kadar hapis cezası ya da para cezası, veri işleme bir işletmeye, bir şirkete ya da bir kuruma hizmet ediyorsa beş yıla kadar, özellikle ağır hâllerde ise altı aydan on yıla kadar, örneğin ticari biçimde hareket edildiğinde ya da kritik altyapı zarar gördüğünde. Teşebbüs de cezalandırılır ve hazırlık hareketleri için § 303b Fıkra 5 StGB, § 202c StGB'ye atıf yapar.
Booter ve stresser hizmetleri bu yüzden gri bir alan değil, bir suçun parayla ödenen parçasıdır. Bu konuda üç nokta düzenli olarak yanlış anlaşılır. Birincisi, “yalnızca kendi sistemlerinizin yük testi için” notu hiçbir şeyi yasal kılmaz, çünkü hizmetler girilen hedefin kime ait olduğunu denetlemez. İkincisi, yalnızca işletmeci değil, sipariş veren de cezalandırılır: Europol, Nisan 2026'daki eylem haftasının ardından tam da bunu netleştirmek için tespit edilen 75.000'den fazla kullanıcıya açıkça yazı gönderdi. Üçüncüsü, kendi sunucunuza böyle bir hizmet üzerinden yapılan bir yük testi de çözüm değildir, çünkü saldırı trafiği sağlayıcının ağından ve dolayısıyla diğer müşterilerin hatlarından geçer, ki bunu her barındırma sözleşmesi yasaklar. Hizmetinin dayanıklılığını gerçekten ölçmek isteyen bunu önceden duyurarak ve sağlayıcıyla mutabık kalarak yapar. Bu bölüm yasal durumu aktarır ve hukuki danışmanlık değildir.
Hizmetinize uygun rehber
Bu yazı ilkeyi anlatıyor. Hangi portun açık olması gerektiği, hangi yapılandırma direktifinin hangi sorguyu sınırladığı ve ilgili oyunda sınırın nerede olduğu: Bunlar tek tek hizmete ait yazılarda, her birinde portların bulunduğu bir gerçekler tablosuyla birlikte duruyor.
- Temeller ve akış: DDoS saldırısını tanıma, Sunucuyu DDoS saldırılarından koruma, Ağır DDoS saldırısı: ne yapmalı, Gerçek zamanlı filtrelemeyle oyun DDoS koruması
- Minecraft ve ses: Minecraft ve Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
- GTA tabanlı rol yapma: FiveM, RedM, RAGE MP ve alt:V, SA-MP ve open.mp, MTA:SA
- Hayatta kalma ve inşa: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
- Taktik ve nişancı: CS2 ve Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2
Kısaca özetle
- Bir DDoS saldırısı dört sonlu kaynaktan birini doldurur: bant genişliği, paket hızı, kernel'in bir durum tablosu ya da uygulamanın işlem zamanı. Bir güvenlik açığı kullanmaz, bu yüzden tek başına güncellemek korumaz.
- RFC 4732 bir DoS saldırısını kaynak sayısıyla değil, etkisiyle tanımlar. Kaynaklar çok sayıda olduğunda dağıtık denir: Mayıs 2025 tarihli Cloudflare vakasında 161 ülkeden 122.145 adres vardı.
- CISA, FBI ve MS-ISAC üç tekniği ayırır: Gbit/s cinsinden hacimsel, saniyedeki paket cinsinden protokole dayalı, saniyedeki istek cinsinden uygulamaya dayalı. Her birinin başka bir savunmaya ihtiyacı vardır.
- Amplifikasyon saldırıları açık UDP hizmetlerini kötüye kullanır. Faktörler Steam protokolünde 5,5'ten SSDP'de 30,8 ve NTP'de 556,9 üzerinden memcached'de 51.000'e kadar uzanır, US-CERT TA14-017A içinde okunabilir.
- Kapasite, ele geçirilmiş cihazlardan oluşan botnetlerden gelir: 2016'da Mirai'de 600.000'den, 31,4 Tbit/s'lik rekor saldırının arkasındaki tahminî bir ila dört milyona kadar; ve ayda yaklaşık 10 EUR'dan başlayarak yeniden satılır.
- Sunucuda
nftables, SYN cookie'leri, uyarlanmış conntrack sınırları ve kaynak adres başına hız sınırlaması işe yarar. Bunlar saniyede yaklaşık 1,5 milyon pakette biter, çünkü 1 Gbit/s'lik bir bağlantı daha fazlasını taşımaz. - Bu sınırın üstünde yalnızca sunucunun önündeki ağda yapılan filtreleme belirleyicidir. Null routing bir savunma değil, saldırganın istediği sonuçtur.
- KernelHost'ta iki kademeli sürekli koruma her sunucu paketinde ek ücret olmadan dâhildir, teslimden itibaren etkindir ve null routing kullanmaz: küresel scrubbing ağında 17 Tbps mitigasyon kapasitesi artı Frankfurt am Main'de 3,2 Tbps ile Arbor gerçek zamanlı filtreleme. Advanced DDoS Protection ise ayda 50,00 EUR'dan başlayarak buna dedicated bir koruma IP'si ve port başına kendiniz yönetebileceğiniz kurallar ekler.
- Bir DDoS saldırısı Avusturya'da § 126b StGB, Almanya'da § 303b StGB uyarınca suçtur; hizmetleri işletenler kadar sipariş verenler için de.
Projeniz hâlihazırda KernelHost'ta çalışıyorsa filtreleme, siz hiçbir şey yapmak zorunda kalmadan etkindir. Buna rağmen dikkat çekici bir durum fark ederseniz, IP adresiniz için filtreleme kurallarının yeniden ayarlanması amacıyla 7. adımdaki beş bilgiyle bir destek talebi açın. Süren bir saldırı sırasında bize ek olarak +43 650 8209883 numarasındaki WhatsApp acil durum sohbeti üzerinden ulaşabilirsiniz.
Sıkça sorulan sorular
DDoS saldırısı nedir?
DoS ile DDoS arasındaki fark nedir?
DDoS saldırılarının hangi türleri var?
Amplifikasyon saldırısı nedir ve amplifikasyon faktörleri ne kadar yüksek?
Bir DDoS saldırısının kapasitesi nereden geliyor ve bir saldırı ne kadara mal oluyor?
Sunucumun şu anda saldırı altında olduğunu nasıl anlarım?
Hangi log satırları bir DDoS saldırısını kanıtlar?
Sunucudaki bir güvenlik duvarı DDoS saldırılarına karşı yeter mi?
Sunucuda hangi ayarlar DDoS'a karşı gerçekten yardımcı olur?
Sorgu portunu neden öylece kapatmamalıyım?
Null routing nedir ve neden bir savunma değildir?
Sunucum şu anda saldırı altındaysa ilk olarak ne yaparım?
KernelHost'taki sunucum bir saldırı sırasında kapatılır mı?
KernelHost'ta DDoS koruması ne kadar ve Advanced DDoS Protection'a ne zaman ihtiyaç duyarım?
Bir DDoS saldırısı suç mudur?
2023-2026 KernelHost GmbH. Tüm hakları saklıdır. Bu rehber telif hakkıyla korunmaktadır. Yazının başka web sitelerinde tamamen, kısmen ya da düzenlenmiş biçimde yayımlanması, yazılı iznimiz olmadan serbest değildir. Kaynak belirtilerek ve bağlantı verilerek yapılan alıntılar ise memnuniyetle karşılanır.

