VPS'inize DDoS saldırısı: ilk saat çalışma kılavuzu

Önce, gerçekten bir saldırı olduğundan emin olun

Bir kesinti sırasındaki en maliyetli hata, yanlış şeyi tedavi etmektir. "Site yavaş", gerçek bir selin, indekslenmemiş bir sorguyu yayına alan bir deploy'un, her saat aynı dakikada veritabanını dökmeye başlayan bir cron görevinin, fasetli aramanızı keşfeden bir crawler'ın, büyük bir yerin ana sayfasına ulaşmış bir bağlantının ve dolmuş bir diskin ortak semptomudur. Bunların hepsi bir tarayıcıdan aynı görünür ve yanıtlar birbirini dışlar: bir migration bir indeksi unuttuğu için gerçek müşterileri hız sınırlamak istemezsiniz.

Üç soru bunları bir dakikadan kısa sürede ayırt eder. Trafik hacmi gerçekten anormal mi, yoksa trafik normal de sunucu mu yavaş? Bir sel, paket ya da saniye başına istek sayısında ani bir sıçrama olarak görünür; kötü bir deploy ise normal istek hacmi ve çökmüş bir yanıt süresi olarak görünür. Son bir saatte kendi tarafınızda bir şey değişti mi? Güvenlik duvarından önce deploy günlüğünü kontrol edin — küçük altyapılarda kendi kendine verilen zararlar saldırıları büyük farkla geride bırakır. Yük sitenin geneline mi yayılmış, yoksa tek bir yolda mı yoğunlaşmış? Gerçek seller genellikle ayrım gözetmez ya da ana sayfayı hedef alır; yüz istemci tarafından bombardımana tutulan pahalı bir uç nokta, bir DDoS'tan çok kötüye kullanıma yakındır ve çok daha ucuz bir çözümü vardır.

Bunları yanıtlayın, sonra devam edin. Bu rehberin geri kalanı şu yanıtı varsayar: hacim anormal, kendi tarafınızda hiçbir şey değişmedi ve kutu boğuluyor.

Beş dakikalık triyaj

Önemli olan yalnızca iki arıza biçimi vardır ve bunlar birbirine zıt tepkiler gerektirir. Ya boru doludur — paketler, yukarı bağlantınızın ya da çekirdeğinizin işleyebileceğinden daha hızlı gelir ve sunucunuz, yazılımınızın herhangi biri onu görmeden önce trafik kaybeder — ya da boru sorunsuzdur ve uygulama tükenmiştir, çünkü biçimi kusursuz istekler, uygulamanın yanıtlayabileceğinden daha hızlı gelmektedir. Bunları birbirine karıştırmak saati boşa harcar: nginx ince ayarı doymuş bir hatta karşı hiçbir işe yaramaz, daha fazla bant genişliği satın almak da bir istek seline karşı hiçbir işe yaramaz.

İki sayıyı karşılaştırarak bunları birbirinden ayırın. Arayüz sayaçlarına ve CPU dağılımına aynı anda bakın. rx bayt sayısı port hızınıza yakın bir yerde sabitlenmişse, dropped ya da overrun sayaçları yükseliyorsa ve zaman uygulamanıza değil de yazılımsal kesmelere gidiyorsa, sel Katman 3 ya da 4'tedir ve bu bir kapasite sorunudur. Bant genişliği sıra dışı değilse ama worker havuzu doymuşsa, bağlantılar kuyruğa giriyorsa ve erişim günlüğü makul görünen isteklerle doluysa, bu Katman 7'dir ve bir filtreleme sorunudur.

Ardından Katman 3/4 durumunu bir adım daha sınıflandırın, çünkü alt türler farklı davranır. Bir SYN seli, SYN-RECV durumunda on binlerce yarı açık soket olarak görünür; çekirdek, syncookies açık olduğunda bunu iyi kaldırır. Bir UDP ya da amplifikasyon seli, hiç dinlemediğiniz portlarda — DNS, NTP, memcached, CLDAP yansımaları — devasa bir gelen hacim olarak görünür ve çalıştırdığınız hiçbir şey yardımcı olamaz, çünkü paketler ağ kartınıza ulaştığında hasar çoktan verilmiştir. Bir parçalanma ya da ham paket seli, mütevazı bir bant genişliğiyle birlikte yüksek saniye başına paket sayısı olarak görünür; bu da hattı değil CPU'yu aç bırakır. Config dosyasına dokunmadan önce hangisine sahip olduğunuzu not edin.

Kutunun içinden düzeltemeyeceğiniz şey

Çoğu makalenin atladığı kısım budur ve saatinizin verimli olup olmayacağına karar veren kısım da budur. Hedef üzerindeki bir güvenlik duvarı kuralı, doymuş bir yukarı bağlantıyı kurtarmaz. iptables DROP'unuz, borunun sonundaki makinede çalışır — paket geçiş bağlantısını çoktan geçmiştir, ödediğiniz bant genişliğini çoktan tüketmiştir ve gerçek bir kullanıcının paketinin yerini çoktan almıştır. Bunu yerel olarak düşürmek, uygulamanızı döngüleri boşa harcamaktan korur ki bunun bir değeri vardır, ama bant genişliğinizi hiçbir şekilde korumaz.

Tek bir sunucu için dürüst tavan, kabaca iki sayının küçüğüdür: bağlı olduğu port hızı ve CPU'sunun sınıflandırabileceği saniye başına paket sayısı. Kural setiniz ne kadar zarif olursa olsun, 1 Gbps'lik bir port 1 Gbps'te doludur ve küçük paketlerden oluşan mütevazı bir sel, bant genişliği sayısı alarm verici görünmeden çok önce birkaç çekirdeği kesme işlemede tüketebilir. Bu noktadan sonra, işe yarayan tek şey, saldırıdan daha fazla kapasiteye sahip olan ve trafiği hattınıza hiç ulaşmadan düşüren, daha yukarıda bir cihazdır. Temizleme dediğimiz şey budur ve filomuzdaki her makinenin daha büyük bir güvenlik duvarı yerine 1.5 Tbps kesintisiz temizleme kapasitesinin arkasında durmasının nedeni de budur.

Bundan çıkan sonuç da aynı derecede önemlidir: yukarı akış korumanız yoksa, sağlayıcınızın büyük hacimsel bir saldırıya yanıtı adresinizi null-route etmektir, çünkü alternatifi o hat üzerindeki diğer her müşteriyi kötü etkilemektir. Bu kötü niyet değildir, aritmetiktir — ve bu, saldırganın hiçbir şeyi kırmadan sizi pahalıya mal ederek kazandığı anlamına gelir. Temizlemenin planınıza dahil mi yoksa hiç etkinleştirmediğiniz ücretli bir ek mi olduğunu önceden bilmek, olay sırasında değil bugün yapmaya değer beş dakikalık bir kontroldür. Bizimki her planda dahildir, ki sabahın 3'ünde işe yarayan tek düzenleme de budur.

Katman 7: trafiğe benzeyen sel

Uygulama katmanı seli daha zordur, çünkü her bir istek tek tek meşrudur. İyi kurulmuş bir HTTP seli, TCP el sıkışmasını tamamlar, TLS müzakeresi yapar, makul bir user agent ile geçerli bir GET / gönderir ve yanıtı okur. İçindeki hiçbir paket bozuk değildir. Sizi öldüren şey aritmetiktir: bir istek, saldırganın göndermesine neredeyse hiçbir şeye mal olmaz, ama size bir veritabanı sorgusuna, bir şablon render'ına ve artık başka kimseye hizmet vermeyen bir worker'ın yüz milisaniyesine mal olur.

İpuçları kendi erişim günlüğünüzdedir ve onlara bakmak yerine onları aramaya başladığınızda genellikle bariz hale gelirler. Önbellek atlatan sorgu dizeleri — /?1234567 adresine giden, her biri sahip olduğunuz her önbelleği alt eden benzersiz bir URL olan binlerce istek — tek başına en yaygın imzadır. Uzun kuyruğu olmayan bir user-agent dağılımı: gerçek trafik, yüzlerce tarayıcı sürümünün karmakarışık bir karışımıdır, bir sel ise genellikle bir milyon kez tekrarlanan üç dize ya da hiçbir gerçek kullanıcının kullanmadığı bir tanedir. Her yerde aynı olan bir referrer alanı. Statik varlıklarınızı tamamen atlayan istekler — gerçek bir tarayıcı, HTML'den sonra CSS'i, fontları ve görselleri getirir; bir sel istemcisi ise HTML'yi ister ve ayrılır. Ve fazla düz olan bir kaynak dağılımı: on bin konut adresine yayılmış ve her biri saniyede iki istek gönderen bir botnet, adres başına oran şüpheli derecede tekdüze olduğunu fark edene kadar popülerlik gibi görünür.

Sonra neredeyse hiç trafiğe ihtiyaç duymayan çeşit gelir: yavaş saldırı. Açılan, her yirmi saniyede bir başlık gönderen ve hiç bitmeyen birkaç yüz bağlantı, bant genişliği grafiğiniz düz kalırken sahip olduğunuz her worker'ı işgal eder. Çözüm bir hız sınırı değildir — istek oranı zaten çok küçüktür — çözüm agresif başlık ve gövde zaman aşımlarıdır; bu yüzden bunlar aşağıda sonradan akla gelen bir fikir olarak değil ilk yapılandırma bloğunda yer alır.

Dört kontrol, dakika başına etkiye göre sıralı

Baskı altında, önce en yüksek kaldıraçlı şeyi yapın. Aşağıdaki sıra rastgele değildir; her birinin, dikkatinizin her dakikasında ne kadar yük attığına göre kabaca azalan sırayladır.

• Ucuz bir şey sunun. Uygulamanızın önünde otuz saniyelik bir mikro önbellek, saniyede bin aynı isteği tek bir orijin isteğine ve 999 bellek okumasına dönüştürür. Neredeyse her HTTP selinde tek başına en büyük kaldıraçtır, bir direktif bloğuna mal olur ve anonim trafik için neredeyse her zaman güvenlidir. Bir önbellek kaçırmasının backend'e kalabalık bir hücum göndermemesi için proxy_cache_lock ekleyin.
• Eşzamanlılığı sınırlayın ve zaman aşımlarını kısaltın. Adres başına limit_conn artı sıkı başlık, gövde ve keepalive zaman aşımları, yavaş saldırıları kökünden öldürür ve tek bir istemcinin worker havuzunuzu kilitlemesini engeller. Bu, gerçek kullanıcılara en az maliyeti olan kontroldür.
• Hız sınırlayın, burst ile. Makul bir burst ile limit_req hassastır ama ayarlanması daha yavaştır ve kendi baseline'ınızdan değil panikten ayarlarsanız yanlış pozitif üreten kontrol de budur. Bir sayı seçebilmeden önce istemci başına normal saniye başına istek sayınızı bilmeniz gerekir — bu yüzden bu rehberin sonundaki post-mortem, kulağa geldiğinden daha önemlidir.
• Dar kapsamlı ve isteksizce engelleyin. Belirli ağları düşürmek, kaynaklar yoğunlaşmışsa işe yarar, değilse hiçbir işe yaramaz. Ayrıca kötü yaşlanır: bir olay sırasında eklediğiniz her engelleme, üç ay sonra sessizce reddediyor olabileceğiniz bir müşteridir. Kuralların kendiliğinden sona ermesi için zaman aşımlı bir set kullanın.

Listede olmayana dikkat edin: tek tek IP adreslerini elle yasaklamak, web sunucusunu tekrar tekrar yeniden başlatmak ve "işe yarıyor mu bir bakalım" diye güvenlik duvarını devre dışı bırakmak. Birincisi, dağıtık bir kaynağa karşı önemli olamayacak kadar yavaştır, ikincisi sahip olduğunuz her sıcak bağlantıyı çöpe atar ve üçüncüsü bir olayın nasıl bir ele geçirilmeye dönüştüğüdür.

Savaşı verinizi barındıran makineden vermeyin

Yukarıdaki her kontrol, veritabanınızı barındıran kutunun dışında bir yerde çalıştığında daha değerlidir. Edge'iniz ayrı bir düğümse, sel, tüm işi selleri sonlandırmak olan bir makinede sonlanır: elinde gerçek istemci adresiyle önbellekler, hız sınırlar ve düşürür; orijin ise özel bir tünel üzerinden yalnızca küçük, filtrelenmiş kalıntıyı görür. Edge çöktüğünde onu 15 min içinde değiştirirsiniz ve hiçbir şey kaybetmezsiniz, çünkü üzerinde hiçbir şey yoktur. Orijin çöktüğünde ise bir kesintiniz ve bir geri yükleme işiniz olur.

Bu ayrım, aynı zamanda çoğu temizlemeyi süse dönüştüren atlatma yolunu da kapatır. Orijinin hâlâ herkese açık bir dinleyicisi varsa, adresini bulan bir saldırgan — pasif DNS, bir sertifika şeffaflığı girdisi, bir MX kaydı ya da bir bağlantı önizlemesi yoluyla — yapılandırdığınız her kontrolü aşarak doğrudan uygulamayı vurabilir. Bu, aksi kanıtlanana kadar herhangi bir "korumalı" sitenin varsayılan durumu olarak ele alınmaya değecek kadar yaygındır. Tutan versiyonu inşa etmek başlı başına bir rehberdir: orijininde hiç herkese açık dinleyicisi olmayan bir offshore reverse proxy.

Bir olayın ortasına dair bir uyarı: bu mimaridir, ilk yardım değildir. Saldırı altındayken bir edge ayağa kaldırmak, DNS'i taşımak ve bir tüneli yeniden inşa etmek, baskı altında kötü yapılan iki saatlik bir iştir ve yalnızca DNS değişikliği bile TTL'nizin söylediği süre boyunca etkili olmayacaktır. Elinizde varsa, kullanın. Yoksa, saati elinizdeki kontrollerle atlatın ve bunu daha sonraki sakin haftada inşa edin — ki tam olarak kimsenin yapmadığı şey de budur.

Hedef değil de yansıtıcı olduğunuz gün

Bu olayın, sunucunuzun kurban olmadığı ve kimsenin size söylemediği ikinci bir versiyonu vardır. Açık bir resolver, açığa çıkmış bir NTP daemon'ı, herkese açık bir arayüzde kimlik doğrulaması olmayan bir memcached, bir konteynerin içinde bir SSDP ya da CLDAP yanıtlayıcısı — bunların her biri, başkasına yönelik küçük, sahte bir isteği çok daha büyük bir yanıtla cevaplar. Sizin tarafınızdan bakıldığında belirtiler tersine döner: giden bant genişliği yüksektir, gelen mütevazıdır, uygulamanız sorunsuzdur ve ilk gerçek sinyal bir kötüye kullanım bildirimi ya da askıya alınmış bir porttur.

Bu kontrol bir dakika sürer ve aynı çalışma kılavuzuna aittir, çünkü triyaj sırasında zaten çalıştırdığınız komutun aynısıdır. ss -tulpn, bilerek koymadığınız herkese açık bir adrese bağlı hiçbir şeyi listelememelidir ve UDP servisleri, amplifikasyon yapan servisler oldukları için özellikle şüpheyi hak eder. Özyinelemeli bir resolver, yalnızca localhost'a ya da bir tünel adresine bağlı olmalıdır; memcached ve Redis, internetten asla erişilebilir olmamalıdır; ve -p 0.0.0.0: ile bir port yayınlayan herhangi bir konteyner, yapılandırdığınız güvenlik duvarında tam da bir delik açmıştır, çünkü Docker kendi kurallarını sizinkilerden önce yazar. Bu sonuncusu insanları her seferinde şaşırtır.

Aynı örüntü, bir sağlayıcının bir adresi aniden null-route etmesinin diğer nedeni olan, zaten ele geçirilmiş bir makineden gelen giden selleri de kapsar. Giden grafiğiniz yüksek ve uygulamanız boştaysa, yapılandırmayı okumayı bırakıp süreçleri kontrol etmeye başlayın — bu bir kapasite sorunu değil bir sızmadır ve yanıt, onu filtrelemek değil, kutuyu bilinen iyi durumdaki bir yedekten yeniden inşa etmektir.

Durduktan sonra: post-mortem ve kalıcı araç seti

Saldırılar durur. Genellikle saldırgan sıkılır, bazen temizleme bunu anlamsız kılar, arada sırada da sabit süreli bir booter aboneliğinin süresi basitçe dolmuştur. O anki cazibe, her şeyi tam olarak olduğu gibi bırakıp yatağa girmektir; bir geçici hız sınırının dokuz ay sonra bütün bir ülke için kalıcı, unutulmuş, sessiz bir 429'a dönüşmesi de tam olarak böyle olur. Taze haldeyken döngüyü kapatmak için yirmi dakika ayırın.

Üretmeye değer üç çıktı vardır. Bir baseline: normal saniye başına isteğiniz, normal istemci başına oranınız, zirvedeki normal bant genişliğiniz. Bu sayılar olmadan, bir sonraki olay sırasında koyduğunuz her sınır bir tahmindir ve yarısı müşterilere zarar veren yönde yanlış olacaktır. Bir geri alma listesi: tarih ve gerekçesiyle birlikte değiştirdiğiniz her şey; böylece acil durum yapılandırması sessizce kalıcı olana dönüşmez. Dört komut uzunluğunda ve site çöktüğünde ulaşabileceğiniz bir yerde duran bir çalışma kılavuzu — sunucunun üzerinde değil, ve yalnızca kendi kafanızda da değil.

Ardından iki yapısal boşluğu kapatın, çünkü katmanın yığındaki yeri tam olarak burasıdır. Temizleme hacmi emen şeydir, edge selin verinizden uzak durmasını sağlayan şeydir ve arkalarındaki kutunun yine de düzgünce sertleştirilmesi ve geri yüklenebilir uzak konum yedeklerine sahip olması gerekir, çünkü bundan sonraki olay hiç de bir sel olmayabilir. Bir DDoS'tan sağ çıkıp bir ay sonra diskini kaybeden bir sunucu hiçbir zaman dirençli değildi — iki kez şanslıydı.

Adım adım

1. 01

   Herhangi bir şeyi değiştirmeden önce doğrulayın

   Bir config dosyasına dokunmadan önce makinenin dürüst bir görüntüsünü alın. Paketlerde ya da isteklerde ani bir sıçrama ve zamanın nereye gittiği ile ilgileniyorsunuz — yazılımsal kesmeler yüzünden CPU'dan mahrum kalmış bir uygulama, bir veritabanını bekleyen bir uygulamadan çok farklı bir olaydır.

   # is the box alive, and where is the time going?
   uptime                     # load average against your core count
   vmstat 1 5                 # 'in' and 'cs' high, 'id' near zero = packet work
   mpstat -P ALL 1 3          # %soft pinned on one core = interrupt saturation
   
   # is the pipe full, or just busy?
   ip -s link show eth0       # rx bytes, and the errors/dropped counters
   ethtool eth0 | grep -i speed
   
   # requests per second from your own log, minute by minute
   tail -n 20000 /var/log/nginx/access.log \
     | awk -F'[][]' '{print $2}' | cut -d: -f2-4 | uniq -c | tail -5

   Bunun bir saldırı olduğu sonucuna varmadan önce kendi deploy günlüğünüzü ve cron tablonuzu kontrol edin. Kendi kendine verilen kesintiler, tek bir VPS'te sellerden daha yaygındır ve dışarıdan aynı görünürler.

2. 02

   Trafiğin şeklini altmış saniyede ölçün

   Şimdi sınıflandırın. Üç soru: kaç farklı kaynak var, hangi protokol ve durumda, ve — HTTP ise — hangi yollar ve hangi agent'lar. Yanıtlar, hangi kontrole başvuracağınıza karar verir ve toplanmaları yaklaşık bir dakika sürer.

   # top source addresses on the wire right now
   timeout 20 tcpdump -nn -i eth0 -c 20000 2>/dev/null \
     | awk '{print $3}' | rev | cut -d. -f2- | rev \
     | sort | uniq -c | sort -rn | head -20
   
   # TCP state census: a wall of SYN-RECV is a SYN flood
   ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn
   
   # layer 7: talkers, paths, agents over the last 50k requests
   L=/var/log/nginx/access.log
   tail -n 50000 $L | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
   tail -n 50000 $L | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
   tail -n 50000 $L | cut -d'"' -f6   | sort | uniq -c | sort -rn | head -10

   Sonucu ipuçlarına göre okuyun: tek bir yolda benzersiz sorgu dizeleri, uzun kuyruğu olmayan bir user-agent listesi, statik varlıklarınıza yönelik hiç istek olmaması ya da tuhaf biçimde tekdüze bir adres başına oran. Bant genişliği hiç dinlemediğiniz portlarda yüksekse, burada durun — bu hacimsel bir seldir ve önemli olan tek adım altıncı adımdır.

3. 03

   Ucuz bir şey sunun ve bağlantıları sınırlayın

   Önce en yüksek kaldıraç. Otuz saniyelik bir mikro önbellek, aynı anonim isteklerden oluşan bir seli tek bir orijin isteğine indirger ve sıkı zaman aşımları, bir hız sınırının göremediği yavaş saldırıları öldürür. İkisini de http bloğuna koyun, ardından sıcak bağlantılarınızı korumak için yeniden başlatmak yerine yeniden yükleyin.

   # /etc/nginx/nginx.conf — http block
   limit_conn_zone $binary_remote_addr zone=perip:10m;
   limit_req_zone  $binary_remote_addr zone=flood:20m rate=10r/s;
   
   client_header_timeout 10s;
   client_body_timeout   10s;
   send_timeout          10s;
   keepalive_timeout     20s;
   reset_timedout_connection on;
   
   proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=hot:64m
                    max_size=2g inactive=10m use_temp_path=off;

   # the server block — cap concurrency, serve the cached copy
   limit_conn perip 20;
   
   location / {
       proxy_cache hot;
       proxy_cache_valid 200 301 302 30s;
       proxy_cache_lock on;
       proxy_cache_use_stale error timeout updating
                             http_500 http_502 http_503 http_504;
       add_header X-Cache $upstream_cache_status;
       proxy_pass http://127.0.0.1:8080;
   }

   nginx -t && systemctl reload nginx
   curl -sI https://example.com/ | grep -i x-cache   # want: HIT on the second call

4. 04

   Kendi proxy'nizi değil, gerçek istemciyi hız sınırlayın

   nginx'in önünde bir şey duruyorsa, her istek tek bir adresten gelir ve adres başına bir sınır, saldırganı değil proxy'yi kısar — ya da onu doğrudan yasaklar ve siz onu savunurken siteyi çökertir. Forward edilen başlığa yalnızca proxy adresinden güvenin, internetten asla, ardından sınırı uygulayın.

   # /etc/nginx/conf.d/realip.conf — the tunnel or edge address only
   set_real_ip_from 10.66.0.1;
   real_ip_header   X-Forwarded-For;
   real_ip_recursive off;

   # burst absorbs bursty humans; nodelay keeps the page fast for them
   location / {
       limit_req zone=flood burst=20 nodelay;
       limit_req_status 429;
   }
   
   # the expensive paths get a much tighter bucket of their own
   location ~ ^/(search|login|register|api/) {
       limit_req zone=flood burst=5;
       limit_req_status 429;
   }

   Sonra az önce ne yaptığınızı izleyin: tail -f /var/log/nginx/error.log | grep limiting. Sınırlanan adresler müşterilerinize benziyorsa, oran çok düşüktür — yükseltin. Gerçek kullanıcıları engelleyen bir sınır, kendi kendinize neden olduğunuz bir kesintidir.

5. 05

   Dar kapsamlı engelleyin ve her engellemeye bir sona erme süresi verin

   Yalnızca ikinci adım yoğunlaşmış kaynaklar gösterdiğinde yapmaya değer. Bin kural değil bir set kullanın — bir ipset araması sabit zamanlıdır, uzun bir iptables zinciri ise her paket için baştan sona taranır ve kendi başına bir hizmet reddine dönüşür. Bugünün acil durumunun gelecek yılın sessiz engelleme listesine dönüşmemesi için her girdiye bir zaman aşımı verin.

   ipset create flood hash:net timeout 3600 -exist
   iptables -I INPUT -m set --match-set flood src -j DROP
   
   # feed it from the census: /24s you actually verified, not guesses
   for n in 203.0.113.0/24 198.51.100.0/24; do ipset add flood $n -exist; done
   
   # SYN flood: let the kernel do the part it is good at
   sysctl -w net.ipv4.tcp_syncookies=1
   sysctl -w net.ipv4.tcp_max_syn_backlog=8192
   sysctl -w net.core.somaxconn=8192
   
   ipset list flood | head -20      # keep a copy of this for the post-mortem

   Kestiğiniz müşterileri isim isim sayamıyorsanız, koca bir ülkeyi coğrafi olarak engellemekten kaçının. Ve bir teoriyi test etmek için asla ufw disable yapmayın: aktif bir saldırı altında güvenlik duvarsız bir kutu, bir bant genişliği olayının nasıl bir ihlale dönüştüğüdür.

6. 06

   Gerçekten emebilecek katmana yükseltin

   Arayüz sayaçları hattın doymuş olduğunu söylüyorsa ya da CPU'nuz boştayken düşüşler yükseliyorsa, sunucuda yapabileceğiniz her şeyin tavanına ulaşmışsınız demektir. Bu okumayı doğrulayın, ardından ayarlamaya devam etmek yerine yükseltin.

   # drops in the stack itself — second column is 'dropped'
   awk '{print strtonum("0x" $2)}' /proc/net/softnet_stat | paste -sd+ | bc
   
   # interface-level loss against link speed
   ip -s link show eth0 | sed -n '3,6p'

   Yukarı akış temizlemesi devredeyken genellikle yapacak bir şey yoktur: tespit kesintisizdir ve sel, portunuza ulaşmadan önce ağ içinde düşürülür — filomuzda bu, her planın önünde duran 1.5 Tbps kapasitedir, dolayısıyla olay çoğu zaman ancak sonradan bir grafik olarak görünür hale gelir. Saldırı hacimsel değil de iyi biçimlendirilmiş bir HTTP seliyse, bu tam olarak bir L7 kalkanının işidir, çünkü istek selleri paket düzeyinde kullanıcılardan ayırt edilemez ve daha yukarıda değerlendirilmesi gerekir. Hiç temizlemeniz yoksa, gerçekçi seçenekleriniz, temizlemesi olan bir edge'in arkasına geçmek ya da beklemektir — ve bir sonraki saldırıdan önce ilkini planlamaktır.

7. 07

   Döngüyü kapatın: doğrulayın, geri alın, sonra yazıya dökün

   Makine üzerindeki bir kabuktan değil, makinenin dışından doğrulayın. Ardından acil durum önlemlerini bilinçli olarak geri alın, her zaman iyi bir fikir olanları koruyun ve bir sonraki olayın bir tahminle değil bir baseline ile başlaması için sayıları kaydedin.

   # from somewhere else entirely: is the site healthy for a normal user?
   curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer}s\n' \
        https://example.com/
   
   # did you leave a limit that is biting real people?
   grep -c 'limiting requests' /var/log/nginx/error.log
   
   # what is still blocked, and when does it expire?
   ipset list flood | head -30

   Önbelleği, zaman aşımlarını ve syncookies'i koruyun — bunlar kalıcı iyileştirmelerdir. Agresif hız sınırlarını, ölçtüğünüz baseline'a artı biraz pay bırakarak geri alın ve ipset girdilerinin kendiliğinden sona ermesine izin verin. Ardından bir ve iki numaralı adımlardaki dört komutu, normal saniye başına isteğinizin ve normal zirve bant genişliğinizin yanında, bu sunucu olmayan bir yerde saklanan bir çalışma kılavuzuna yazın. Bir sonraki saldırı, yalnızca bu iki sayı var olduğu için daha kısa bir olay olur.