Bir VPS'i DDoS altında çevrimiçi tut

“DDoS”, bir mekanizmayı değil bir niyeti tanımlar ve mekanizmaların birbiriyle neredeyse hiç ortak yanı yoktur. Bunları doğru biçimde ayırt etmek bir titizlik gösterisi değildir: işin tamamı budur, çünkü her biri tam olarak bir katmanda durdurulabilir ve diğerlerinde görünmezdir.

Hacimsel saldırılar bant genişliğinizi hedef alır. UDP amplification — DNS, NTP, memcached ve son zamanlarda küçük bir soruyu büyük bir yanıtla karşılayan her şey — bir saldırganın kendi kapasitesinin 1 Gbps'ini size yönelik 50 Gbps'e dönüştürmesini sağlar. Hedef sunucu değil, hattır. CPU'nuz baştan sona can sıkıntısından başka bir şey yaşamaz.

Protokol ve durum saldırıları çekirdeğinizdeki sonlu bir tabloyu hedef alır. Bir SYN flood, kabul kuyruğunu tüketmeye çalışır; genel bir küçük-paket saldırısı ise bağlantı izlemeyi (connection tracking) tüketmeye çalışır. İkisi de bit/saniye değil paket/saniye cinsinden ölçülür ve ikisi de yüzde 97'si boşta duran bir hat üzerinde bir makineyi öldürebilir. Küçük sunucuları çökerten sınıf budur ve çoğu rehberin atladığı sınıf da budur.

Uygulama katmanı saldırıları CPU'nuzu veya veritabanınızı hedef alır; kullandıkları istekler gerçeklerinden ayırt edilemez, çünkü zaten gerçek isteklerdir. Bir arama endpoint'ine saniyede yüz istek bir ağ için hiçbir şey ifade etmez ama bir PHP uygulaması için ölümcüldür. Hiçbir yukarı akış temizleyicisi bunu sizin için filtreleyemez: dışarıdan bakıldığında tam olarak bir başarı gibi görünür.

Üçünün de kılığına girip gelen ama aslında hiç saldırı olmayan dördüncü bir şey vardır: bir yerde iyi giden bir bağlantı, kendi hatalı davranan bir istemciniz ya da terbiyesiz bir crawler. Bunu önce eleyip geçmek bedavadır ve bunun ne kadar sık doğru cevap olduğu utanç verecek kadar yüksektir.

Adresinize 60 Gbps yöneltiliyorsa ve portunuz 1 Gbps'lik bir portsa, bu paketlerle ilgili karar sizin yönettiğiniz her şeyden birkaç hop önce, sizin yukarınızdaki bir yönlendiricide verilir. Güvenlik duvarınız onları hiçbir zaman görmez. Göremez de: sahibi olmadığınız bir hattı korumak için düşürülmüşlerdir. Bu, hacimsel saldırılar hakkındaki tek ve en önemli yapısal gerçektir ve “güvenlik duvarınızı DDoS'a karşı sertleştirin” tavsiyesinin çoğunlukla saçma olmasının nedeni budur.

Dolayısıyla anlamlı olan tek sorular, sağlayıcınızın otomatik olarak ne yaptığı ve eşiklerinin nerede durduğudur. Bizimkiler vaat edilmek yerine yayımlanmıştır: 10 Gbps altı gözle görülür bir etki olmadan emilir, 10-100 Gbps arası transit sağlayıcıda temizlenir ve hafif bir gecikme artışı fark edebilirsiniz, 100 Gbps üzerinde ise önek (prefix) özel bir temizleme hattına duyurulur — gecikme daha belirgin biçimde artar ama hizmet erişilebilir kalmaya devam eder. Bir adresi null-route yapmak yalnızca daha geniş PoP'u tehdit eden sürekli saldırılar için gündemdedir ve bu gerçekleşirse size dakikalar içinde haber veririz. Satın alınacak ya da etkinleştirilecek hiçbir şey yoktur.

Temizleme hakkında satıcıların nadiren gönüllü olarak paylaştığı iki şey bilinmeye değer. Birincisi, yalnızca kendi savunmalarınızla değil, komşuluk tarafından da korunuyor olmanızdır: sizinle aynı üst /20'yi paylaşan bir müşteriye yönelik saldırı, herhangi birinin önekine ulaşmadan önce emilir — Paris'te komşu bir aralığa yönelen ~340 Gbps'lik bir taşkın, bizimkinde ölçülebilir hiçbir etki yaratmadan geçti; kimsenin fark etmediği sonuç da tam olarak budur. İkincisi, temizleyicilerin sezgisel (heuristic) yöntemlerle çalıştığı ve sezgisel yöntemlerin bazen yanıldığıdır: aynı ağda, bir temizleyici bir keresinde bir komşuya yönelik saldırıyı filtrelerken meşru bağlantılara karşı dokuz dakika boyunca TCP reset göndermiştir. Her iki olay da herkese açık olay günlüğünde yer alır. Oturumlarınız, başkasının saldırısı sırasında bir zaman aşımı yerine etkin bir reset gibi görünen bir biçimde kapanıyorsa, bu gerçek bir arıza modudur ve bir saat boyunca yerel olarak hata ayıklamak yerine bildirilmeye değer.

Her yanlış DDoS tepkisi, kimse ne olduğunu anlamadan yapılan bir değişiklikle başlar. Önce dört sayıyı edinin. Tek ekrana sığarlar ve katmanı sizin yerinize adlandırırlar.

# 1. bits vs packets  — which axis is saturated?
sar -n DEV 1 5            # or: ifstat -i eth0 1

# 2. socket states     — SYN-RECV piling up means a SYN flood
ss -s
ss -tan state syn-recv | wc -l

# 3. kernel drop counters (these are the ones that matter)
nstat -az | grep -E 'ListenDrops|ListenOverflows|SyncookiesSent|TCPReqQFullDrop'
dmesg -T | tail -20       # look for: nf_conntrack: table full, dropping packet

# 4. connection tracking headroom
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Bunları birlikte okuyun. Yüksek bit/saniye, düşük paket/saniye, düşük CPU hacimsel bir saldırıdır ve göreviniz bunu doğrulayıp yazmayı bırakmaktır. Yüksek paket/saniye, düşük bit/saniye — çok sayıda ufak paket — bir durum saldırısıdır; hemen SyncookiesSent'e ve conntrack sayısına bakın. CPU sabitlenmişken her iki eksende de mütevazı trafik katman 7'dir ve cevap güvenlik duvarınızda değil, web sunucunuzda ve veritabanınızdadır.

Sezgiye aykırı bir okuma içselleştirilmeye değer: gerçek bir hacimsel taşkın sırasında arayüzünüz neredeyse sakin görünebilir. Gördükleriniz hayatta kalanlardır — zaten dolu bir hattan geçebilenler ya da yukarı akış temizleyicisinin bıraktıklarıdır. Kullanıcılar tam bir erişilemezlik bildirirken 1 Gbps'lik bir portta 900 Mbps gösteren bir arayüz, saldırıya karşı bir kanıt değildir. Tam olarak saldırının şeklidir.

Sonra trafiğin sadece gerçek olmadığını kontrol edin. Erişim günlüğünüzü on saniye boyunca tail -f ile izleyin: yönlendiren (referrer) bilgisi olmadan binlerce farklı adres tarafından tekrarlanan tek bir yol bir saldırıdır; normal tarayıcılardan gelen normal yolların dağılımıysa bir kitledir ve onu hız sınırlamak saldırganın işini onun yerine yapmak olur.

Her açık port, bir saldırganın doldurabileceği bir kuyruktur ve guest'inizin bakmak zorunda olduğu her paket, siz onu düşürseniz bile size bir CPU döngüsüne ve bir conntrack kaydına mal olur. En ucuz paket, makinenizin hiç almadığı pakettir; guest'in üzerinde filtrelemenin guest'in içinde filtrelemekten daha değerli olmasının nedeni de budur.

Burada iki katman vardır ve aynı şey değildirler. Kenar filtresi isteğe bağlıdır, sunucu başına yapılandırılır, durum bilgili (stateful) ve varsayılan reddeder, hipervizör üzerinde çalışır — orada reddettiğiniz trafik sanal NIC'inize hiç ulaşmaz, dolayısıyla size ne CPU, ne bellek ne de bir durum tablosu kaydı harcatır. Guest güvenlik duvarı — nftables kural setiniz — tamamen sizindir ve biz ona asla dokunmayız. Bir saldırıyla temas ettikten sonra ayakta kalan örüntü, kaba ve kararlı katman-4 gerçeğini kenarda ifade etmek (“bu makine 80, 443 ve SSH'yi yalnızca şu adreslerden sunar, başka hiçbir şey yoktur”) ve guest kural setini uygulamanızla birlikte değişen ince taneli iş için saklamaktır. İkisi de güvenlik duvarı dokümantasyonunda anlatılır.

Sonra geriye kalanı daraltın. SSH'yi gerçekten yönettiğiniz adreslerle sınırlamak burada bir sertleştirme inceliği değildir — makinenizden bağlantı-tükenmesi saldırılarının koca bir sınıfını kaldırır. 127.0.0.1'e veya bir WireGuard adresine bağlı bir veritabanı internetten hiçbir şekilde sel altında bırakılamaz. Ve saf biçimde dahili bir kontrol düzlemi sunuyorsanız, onu üzerinde parola olan herkese açık bir port yerine bir WireGuard arayüzünün arkasına koyun.

Bir SYN flood el sıkışmayı istismar eder: saldırgan bir bağlantı isteği akışı gönderir ve bunları hiçbir zaman tamamlamaz, her biri zaman aşımına uğrayana kadar çekirdeğin SYN kuyruğunda bir yer işgal eder. Kuyruk dolduğunda meşru el sıkışmalar düşürülür — hizmetiniz ayaktadır, dinlemektedir ve erişilemezdir.

Linux'un doksanlardan beri temiz bir cevabı var ve bu varsayılan olarak açıktır. SYN cookie'ler, çekirdeğin yarı açık bağlantılar için bellek ayırmayı tamamen bırakmasını sağlar: bağlantı durumunu geri gönderdiği sıra numarasının içine kodlar ve istemci el sıkışmayı tamamlarsa bunu yeniden oluşturur. Bunu varsaymak yerine doğrulayın ve kuyruklara bir patlamayı atlatacak kadar yer verin:

# /etc/sysctl.d/99-flood.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_abort_on_overflow = 0

sysctl --system

tcp_synack_retries = 2 göründüğünden daha önemlidir: varsayılan değer olan beş, sahte bir el sıkışmanın çekirdeği yaklaşık üç dakika boyunca işgal etmesi anlamına gelir; iki ise bunu yaklaşık yedi saniyeye indirir. somaxconn'u yükseltmek işin yalnızca yarısıdır — kuyruk derinliği bu değer ile uygulamanın istediği değerin küçük olanıdır, bu yüzden çekirdek ayarının bir anlam ifade etmesi için önce nginx'in listen 443 ssl backlog=8192;'ye ve bir reload'a ihtiyacı vardır. Bu, uygulanmış görünen ama hiçbir işe yaramayan klasik bir sysctl örneğidir.

Taşkını uygulamaya ulaşmadan tamamen durdurmak istiyorsanız, nftables el sıkışmaları çekirdek adına tamamlayabilir ve yalnızca gerçek olduğu ortaya çıkan bağlantıları devredebilir:

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 80, 443 } ct state new synproxy mss 1460 wscale 7 timestamp sack-perm
    tcp dport { 80, 443 } accept
    ip protocol icmp icmp type echo-request limit rate 5/second accept
  }
}

Ona güvenmeden önce synproxy'yi hâlâ konsoldan erişebileceğiniz bir makinede test edin; yanlış yapılandırıldığında kendinizi kendi sunucunuzun dışında bırakmanın mükemmel bir yoludur. Çoğu insan için yukarıdaki sysctl bloğu yeterlidir ve dürüst sıralama şudur: önce syncookies, sonra backlog, synproxy ise ancak ilk ikisinin yetersiz kaldığını ölçtüyseniz.

Deneyimli insanları bile yakalayan budur. Durum bilgili bir güvenlik duvarı, gördüğü her akışı hatırlamak zorundadır ve bu hafıza, önyükleme sırasında sabit bir boyut seçilen bir hash tablosu olan nf_conntrack'tir. Dolduğunda çekirdek yeni bağlantıları düşürür — saldırgan ya da müşteri fark etmeksizin hepsini — ve kimsenin izlemediği dmesg'e tek bir satır yazar:

nf_conntrack: table full, dropping packet

Bu kadar etkili olmasının nedeni aritmetiktir. Küçük bir VPS'teki varsayılan tablo, birkaç on binin altında bir yerde kayıt tutar ve yeni bir kaynak adresten gelen her paket bir kayıt oluşturur — UDP paketleri dahil, düşürdüğünüz paketler dahil, taşkının kendisi dahil. Sahte kaynaklardan saniyede yirmi bin paket, birkaç megabitlik bir hat üzerinde onu iki saniyeden kısa sürede doldurur. Bant genişliği grafiğiniz hiçbir şey göstermeyecektir.

# /etc/sysctl.d/99-conntrack.conf
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_udp_timeout = 20

Zaman aşımları, boyuttan daha fazla iyilik yapar. Kurulu bir TCP akışı için varsayılan ömür beş gündür; bu da bir haftadır ayakta olan bir sunucunun salı günü sona ermiş bağlantılar için durum tuttuğu anlamına gelir. Boşta duran bir SSH oturumu olmayan hiçbir şey için bir saat fazlasıyla yeterlidir ve net.ipv4.tcp_keepalive_time = 600 bunları kazara değil, düzgün biçimde canlı tutar. Boyutlandırırken kayıt başına kabaca 300 bayt çekirdek belleği hesaba katın: 262.144 kayıt yaklaşık 80 MB'tır, ki bu 4 GB'lık bir makinede sorun değildir ama bir forumda öyle denildi diye onu on milyona ayarlarsanız sorun olur.

Gerçekten durumsuz (stateless) ve yüksek hacimli bir şey çalıştırıyorsanız — yetkili bir DNS sunucusu, herkese açık bir oyun sunucusu, bir Tor rölesi — daha iyi cevap onu izlemeyi tamamen bırakmaktır. Anlamlı bağlantıları olmayan bir servis için bağlantı izleme saf maliyettir:

table ip raw {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    udp dport 51820 notrack
    tcp dport 9001 notrack
  }
}

Böyle bir trafiğin ct state established kurallarınızı atladığını, dolayısıyla filter zincirinde açık kabul kurallarına ihtiyaç duyduğunu unutmayın. Denge budur: o port için durum bilgisini bırakırsınız ve karşılığında doldurulamayan bir tablo elde edersiniz.

Küçük bir sunucuya karşı en verimli saldırı bir taşkın bile değildir. Saniyede birkaç yüz özenle seçilmiş HTTP isteğidir; her biri kusursuzca geçerlidir, her biri indekslenmemiş bir sorgu çalıştıran ya da önbelleğe alınmamış bir sayfa render eden tek endpoint'i vurur. Ekonomisi acımasızdır: istek saldırgana birkaç yüz bayta mal olur, size ise 200 milisaniyelik CPU ve bir veritabanı bağlantısına mal olur. Karşılayabileceğiniz herhangi bir hacimde bu yarışı kaybedersiniz.

İçgüdü, saldırganı engellemektir. Her biri saniyede iki istek gönderen, binlerce ev kullanıcısı adresine yayılmış bir botnete karşı IP'ye göre engelleme tiyatrodan ibarettir — gerçek kullanıcılarınıza izin veren hiçbir adres başı hız sınırı asla tetiklenmez ve kesinti boyunca site çökük kalırken kural eklemekle uğraşırsınız. Kazanan hamle sayıyı değil, maliyeti değiştirmektir.

Önce önbelleğe alın, miss'i de önbelleğe alın. Tam sayfa önbelleği, pahalı bir isteği bir bellek okumasına dönüştürür ve bir saldırı sırasında en çok önem taşıyan direktif, binlerce eşzamanlı miss'in binlerce eşzamanlı veritabanı sorgusuna dönüşmesini engelleyen direktiftir:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app:64m max_size=2g inactive=60m;

server {
  location / {
    proxy_cache app;
    proxy_cache_valid 200 301 302 10m;
    proxy_cache_lock on;              # one origin request per key, not a thousand
    proxy_cache_lock_timeout 5s;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on; # serve stale, refresh behind it
    add_header X-Cache $upstream_cache_status always;
    proxy_pass http://127.0.0.1:8080;
  }
}

proxy_cache_lock ve use_stale, bir trafik patlamasının atlatılabilir olup olmadığını belirleyen iki satırdır. Bunlar olmadan, sıcak bir anahtarın süresi dolduğu anda uçuştaki her istek bir origin isteğine dönüşür — yönetilebilir bir saldırıyı bir kesintiye çeviren izdiham budur. Bunlarla, backend'iniz aralık başına anahtar başına bir istek sunar ve geri kalan herkes hafifçe bayat bir sayfa alır; bu da alternatifin hiç sayfa olmadığı her durumda doğru dengedir.

Sonra özellikle pahalı yolları hız sınırlayın, cömertçe ve görünür biçimde başarısız olacak şekilde:

limit_req_zone $binary_remote_addr zone=general:16m rate=20r/s;
limit_req_zone $binary_remote_addr zone=costly:16m  rate=2r/s;
limit_conn_zone $binary_remote_addr zone=conn:16m;
limit_req_status 429;
limit_conn_status 429;

server {
  limit_req  zone=general burst=40 nodelay;
  limit_conn conn 24;

  location /search { limit_req zone=costly burst=5 nodelay; proxy_pass http://127.0.0.1:8080; }
  location /login  { limit_req zone=costly burst=3 nodelay; proxy_pass http://127.0.0.1:8080; }
}

nodelay olmadan burst, fazla istekleri reddetmek yerine kuyruğa alır; bu da saldırı altında nginx'in sizin adınıza kibarca binlerce bağlantıyı açık tutması anlamına gelir — bir istek taşkınını bir bağlantı taşkınına dönüştürmüş olursunuz. nodelay kullanın, hemen 429 döndürün ve istemcinin bununla uğraşmasına izin verin. Ve herhangi bir proxy'nin arkasında, set_real_ip_from ve real_ip_header'ı doğru yapılandırmadığınız sürece $binary_remote_addr'ın proxy'nin kendisi olduğunu unutmayın; kendi ön uç adresinize göre anahtarlanmış bir hız sınırı, ilk tetiklendiğinde tüm kullanıcıları aynı anda dışarıda bırakır.

Slowloris tarzı saldırılar — çok sayıda bağlantı, her biri bir isteği seferde bir bayt damlatarak gönderir — nginx'in event modelini neredeyse hiç zorlamaz, ama zaman aşımlarını yine de sıkılaştırmaya değer: client_header_timeout 8s; client_body_timeout 8s; send_timeout 10s; reset_timedout_connection on;. limit_conn ile birleştirildiğinde savunmanın tamamı budur.

fail2ban gerçekten faydalıdır ve farklı bir sorunu hedef alır. Günlük dosyalarını okur, M dakika içinde N başarısızlıktan sonra karar verir ve bir güvenlik duvarı kuralı ekler. Bunun her parçası bir taşkın için yanlış şekildedir.

Çok yavaştır: kırk saniye süren bir patlama, yasaklama penceresi kapanmadan çoktan bitmiştir. Günlükleri okur, dolayısıyla saldırı size her isteğin tam bedelini çoktan ödetmiştir — ayrıştırma hasardan sonra gerçekleşir. Tek tek adresleri yasaklar, dolayısıyla on bin kaynağa karşı ya hiçbir şey yapmaz ya da on bin doğrusal kural ekler; bu noktada güvenlik duvarının kendisi darboğaz haline gelir ve saldırıyı saldırganınız adına siz tamamlamış olursunuz. Ve günlükleriniz tarafından tetiklendiği için, bir diski günlük satırlarıyla doldurmaya yetecek kadar büyük bir taşkın, sunucuyu hiç düşünmediğiniz bir yoldan çökertebilir.

Dinamik engelleme istiyorsanız, bunu aramanın bir hash olduğu ve süre dolumunun otomatik olduğu veri düzleminde yapın. Bir nftables dinamik seti, boyuttan bağımsız olarak O(1)'dir ve kendiliğinden unutur:

table inet filter {
  set flooders {
    type ipv4_addr
    flags dynamic, timeout
    timeout 10m
    size 65535
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr @flooders drop
    tcp dport { 80, 443 } ct state new add @flooders { ip saddr limit rate over 50/second burst 100 packets } drop
    tcp dport { 80, 443 } accept
  }
}

Kuralı dikkatlice okuyun, çünkü olumsuzlama insanların ayağına dolanır: adres sete yalnızca oran limitin üzerinde olduğunda eklenir ve düşürülür. fail2ban'ı iyi olduğu iş için saklayın — SSH ve uygulama girişlerine karşı yavaş kimlik bilgisi tahmini, yani belirli bir adrese insan zaman ölçeğinde bir yasaklamanın tam olarak doğru olduğu yer.

Her büyük hacimsel saldırı, operatörleri katıldıklarını bilmeyen sunucular tarafından beslenir. Mekanizma, küçük sahte bir isteği büyük bir yanıtla karşılayan bir UDP servisidir: açık bir DNS resolver'ı kendisinden istenenin 50 katını döndürür, yanlış yapılandırılmış NTP ve memcached daha da kötüdür ve kimin sorduğunu doğrulayamadan yanıt veren her protokol bir adaydır.

Sonuçları, kurbana ulaşmadan önce size ulaşır. Uplink'iniz kendi giden yanıtlarınızla dolar, sağlayıcınız portunuzdan çıkan sürekli istismarcı trafiği görür ve bunu alan transit tedarikçileri geldiği aralıkları null-route yapmaya başlar — kabul edilebilir kullanım politikasının hemen hemen her şeye izin verirken saldırı başlatma ve amplification konusunda sert bir çizgi çizmesinin nedeni de budur. Habersiz bir yansıtıcı (reflector) olmak, çalıştırmayı hiç amaçlamadığınız hiçbir şeyle ilgisi olmayan bir adresi kaybetmenin en hızlı yoludur.

# bind a recursive resolver to localhost, never 0.0.0.0
# unbound: interface: 127.0.0.1  +  access-control: 0.0.0.0/0 refuse

# what is actually listening on a public address?
ss -ulpn
ss -tlpn

# from another machine, confirm you do not answer strangers
dig @your.server.ip example.com +short          # must time out
ntpq -c rv your.server.ip                        # must fail

Kasıtlı olarak herkese açık bir UDP servisi çalıştırıyorsanız — bir oyun sunucusu, yetkili bir nameserver, bir WireGuard endpoint'i — kural her yerdeki gibi aynıdır: yanıtı hız sınırlayın, isteği asla. bind ve knot'un ikisi de yanıt hız sınırlamasını (response rate limiting) uygular; bunu kullanın, çünkü kullanıcılarınıza hizmet vermekle başkasının saldırısını taşımak arasındaki fark budur.

Yukarıdakilerin tamamı, adresinizi zaten bulmuş bir saldırı için hasar kontrolüdür. Yapmaya değer ama ikinci en iyisidir. Kimsenin adını koyamadığı bir origin, katman 3 veya 4'te hiçbir şekilde saldırılamaz ve trafiği sunan adresi dünyanın bildiği adresten ayırmak, bu sayfadaki en yüksek kaldıraçlı iştir.

Origin adresleri neredeyse hiçbir zaman akıllıca saldırılar yoluyla sızmaz. Kısa ve iyi bilinen bir listedeki geçmiş ve dikkatsizlik yoluyla sızarlar. Eski DNS kayıtları her zamanki suçludur: pasif-DNS arşivleri, bir ön uç yerleştirmeden önce sahip olduğunuz A kaydını sonsuza dek hatırlar. Certificate transparency günlükleri herkese açık ve kalıcıdır, dolayısıyla doğrudan origin'e işaret eden bir hostname için verilmiş bir sertifika, eskiden nerede yaşadığınızın imzalı, zaman damgalı bir kaydıdır. Giden posta, gönderen sunucunun adresini her mesajın başlıklarına damgalar. Ve sessiz olanı: web sunucunuzun çıplak IP'sinde yanıt vermesi, adres uzayını sitenizin HTML'i için tarayan herkesin sizi bir öğleden sonra içinde içerikle bulmasını sağlar.

Sonuncusu iki satırlık bir düzeltmedir ve neredeyse kimse bunu yapmaz. Varsayılan sunucuyu, sunduğunuz bir hostname ile gelmeyen her şeyi reddedecek şekilde ayarlayın:

server {
  listen 80 default_server;
  listen 443 ssl default_server;
  ssl_reject_handshake on;      # nginx 1.19.4+: no certificate, no fingerprint
  return 444;                   # close without a response
}

Sonra bir ön yüz (front) seçin. Ticari bir CDN, bariz cevaptır ve burada önemli olan gerçek bir maliyetle gelir: TLS'inizi sonlandıran, düz metninizi gören, origin'inizi bilen ve seçmediğiniz bir yargı bölgesinde kendisine yasal işlem tebliğ edilebilecek bir şirket eklemiş olursunuz — bu da sunucunun isimsiz kripto ile ödenmesinin sebebinin iyi bir kısmını geçersiz kılar. Yine de yaparsanız, origin'in hiçbir zaman herkese açık olmamış olması gerektiğini ve birinin eski bir kayıt bulduğu anda tüm düzenlemenin çöktüğünü anlayın.

Ödediğiniz mülkiyeti koruyan alternatif, kendi ön yüzünüz olmaktır. İkinci bir bölgede nginx'i ters proxy olarak çalıştıran, origin'in kenar filtresinin yalnızca o tek adresten trafik kabul ettiği 5 dolarlık bir instance, size beş dakikada yeniden adresleyebileceğiniz feda edilebilir bir adres ve yalnızca size yanıt veren bir kontrol düzlemi verir. Aynı mimaridir, sadece üçüncü taraf olmadan. Ve kitlenin kullanabildiği yerlerde, bir Tor onion servisi IP'yi denklemden tamamen çıkarır — sel altında bırakılacak bir adres yoktur, gerçi onion servislerinin giriş noktalarında (introduction points) kendi saldırı yüzeyleri vardır, modern Tor'un tam olarak bunun için bir proof-of-work savunması sunmasının nedeni de budur.

Er ya da geç biri bir ülkeyi engellemeyi önerir. Kabadır, ara sıra doğrudur ve çoğunlukla meşgul hissetmenin bir yoludur.

Hizmetinizin gerçekten sınırlı bir kitlesi olduğunda — bölgesel bir oyun sunucusu, dahili bir araç, bir kontrol paneli — ve yanlış pozitiflerin sorumluluğunu almaya hazırsanız savunulabilir; bunlar arasında seyahat eden kendi kullanıcılarınız ve tuhaf biçimde yönlendirilen herkes vardır. Sizinki de dahil her ülkedeki ev bağlantılarına dağılmış modern bir botnete karşı neredeyse işe yaramaz ve herkese açık herhangi bir şey için doğrudan zararlıdır: gerçek insanları sessizce kaybedersiniz ve ayrılanları asla göremezsiniz.

ASN'ye göre engellemek daha keskindir. Bir avuç barındırma sağlayıcısından — saatlik kiralanan ucuz VPS aralıklarından — kaynaklanan saldırı trafiği, bir ülke engelinden çok daha az zayiatla önek (prefix) bazında düşürülebilir, çünkü sıradan kullanıcılar bir veri merkezinden gezinmez. Veri merkezi aralıkları, uygun biçimde, scraping ve credential stuffing'in de geldiği yerdir.

Ama bu fikrin kalıcı versiyonu coğrafya değildir: trafiğin kaynağı yerine şekline göre filtrelemektir. Bir saldırı genellikle yapısal bir şeyi paylaşır — aynı user agent, aynı eksik başlık, aynı sorgu parametresine sahip aynı URL, aynı TLS parmak izi, gerçek bir tarayıcının her zaman yaptığı ikinci isteğin tam bir yokluğu. Paylaşılan özelliği bulun, hiçbir şeye mal olmayan ve saldırganın adres değiştirmesinden -ki bunu siz onları listeleyebileceğinizden daha hızlı yapacaktır- sağ çıkan tek bir kural yazın.

# in an attack: what do these requests have in common?
awk '{print $1}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # addresses
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # user agents
awk '{print $7}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # paths

Bir user agent isteklerin yüzde 90'ını oluşturuyorsa, bir düzeltmeye doksan saniye uzaktasınız demektir. En yüksek yirmi adresin her biri trafiğin yüzde 2'sini oluşturuyorsa, adres aramayı bırakın — bu dağıtık bir saldırıdır ve cevap önbellekleme ve hız sınırlarıdır.

Bazen saldırı hedeflidir, kalıcıdır ve rastgele bir adrese değil kişisel olarak size yöneliktir; doğru tepki adresi savunmayı bırakıp terk etmektir. Bu bir yenilgi değildir; küçük bir hizmet için genellikle mümkün olan en ucuz sonuçtur ve yalnızca bunu hiç prova etmediyseniz acı vericidir.

Bunu hızlı yapan şey önceden karar verilmiş olmasıdır. DNS TTL'lerini kalıcı bir tutum olarak 300 saniyede tutun — maliyeti ihmal edilebilir düzeydedir, faydası ise bir gün yerine beş dakikada taşınabilmenizdir. Devreye alımınızı yeniden üretilebilir tutun, çünkü yeniden inşa edebileceğiniz bir sunucu, taşıyabileceğiniz bir sunucudur; yeniden inşa etmek martta ne yaptığınızı hatırlamak anlamına geliyorsa, elinizde bir plan değil bir rehine vardır. Farklı bir bölgede geri yüklenebilir bir yedek tutun ve gerçek bir tatbikattan bir geri yüklemenin ne kadar sürdüğünü bilin.

Sonra asıl hamle kısadır: başka bir bölgede devreye alın, geri yükleyin, DNS'e dokunmadan önce hostname override ile yeni adreste doğrulayın, kaydı çevirin ve son resolver'lar yetişene kadar eski sunucuyu yeterince uzun süre çalışır durumda tutun. Taşıma rehberi sıralamayı düzgün biçimde ele alır ve performans için mi yoksa biri sinirlendiği için mi taşındığınız fark etmeksizin sıralama aynıdır.

Faturalandırma modeli provayı esasen bedava hale getirir: ücretler bakiyenize karşı günlük olarak orantılı düşer, bu yüzden bir öğleden sonra içinde devreye alıp test edip yok edeceğiniz ikinci bir makine birkaç sente mal olur; ne bir sözleşme, ne bir kart ne de iptal edilecek bir yenileme vardır. İlk yeniden adresleme provanızın bir saldırı altında gerçekleşmesi için hiçbir sebep yoktur.

İki dürüst kapanış notu, çünkü bu sayfanın geri kalanı yapısı gereği iyimserdir.

Birincisi, hiçbir barındırma sağlayıcısının her şeyi emmediği ve aksini iddia eden herhangi bir sağlayıcının satış yaptığıdır. Kapasite sonludur, temizleme kapasitesi daha da sonludur ve yeterince büyük bir ölçekte, binlerce müşteriyi koruyan bir ağ için ekonomik olarak rasyonel eylem, tek bir adresi duyurmayı bırakmaktır. Bunu, daha geniş PoP'u tehdit eden sürekli saldırılara karşı son çare olarak ele alırız ve bunu sizin kendiniz hata ayıklamanıza bırakmak yerine size söyleriz — ama bunun asla olamayacağına dair bir vaat yalan olurdu ve böyle bir vaatte bulunan herhangi bir sağlayıcıyı şüpheyle karşılamalısınız.

İkincisi, misillemenin menüde olmadığıdır. Booter ve stresser servisleri, test aracı kılığına girmiş kiralık saldırılardır; önem taşıyan yargı bölgelerinin çoğunda yasa dışıdırlar, yoğun biçimde izlenirler ve neredeyse her şeye izin veren bir politika altında burada sunucunuzun sonlandırılmasına yol açarlar. DDoS'u bir saldırgan için çekici kılan asimetri, onu bir savunmacı için değersiz kılar: kaybedecek hiçbir şeyi olmayan birini sel yarışında geçemezsiniz. Saldırıyı emin, önbelleğe alın, taşının ve sıkıcı hale gelmesine izin verin — ki gönderdiği trafik için ödeme yapan herkes için er ya da geç bu gerçekleşir.