Geçen ay orta ölçekli bir e-ticaret müşterimizin sunucu loglarına rutin bakım için girdik ve tek bir hafta sonunda yönetici paneline 41 bin başarısız giriş denemesi saydık. Müşterinin haberi bile yoktu. "Bizim gibi küçük bir siteye kim saldırır ki?" dedi telefonda — bu cümleyi son beş yılda kaç kere duyduğumu sayamıyorum. Cevap her seferinde aynı: kimse size özel olarak saldırmıyor. Saldırıların ezici çoğunluğu hedefli değil, otomatik. Botlar IP bloklarını sırayla tarıyor, zayıf bulduklarına yükleniyor. Küçük olmanız sizi hedef listesinden çıkarmıyor; sadece savunmasız yakalanma ihtimalinizi artırıyor, çünkü büyük kurumların güvenlik bütçesi sizde yok.
Bu yazıda, sahada en çok karşılaştığımız üç saldırı tipini ve her biri için gerçekçi — yani bütçenizi bitirmeyen — savunmayı anlatacağım.
Brute force: en sıradan saldırı, en dolu ganimet
Botlar, geçmiş veri sızıntılarından derlenmiş milyonlarca e-posta/şifre çiftini giriş formlarınızda 7/24 dener. Buna credential stuffing deniyor ve işe yaramasının tek sebebi, insanların aynı şifreyi her yerde kullanması. Sizin sisteminiz hiç sızmamış olabilir; ama müşterinizin başka bir sitede kullandığı şifre sızmışsa ve aynısını sizde de kullanıyorsa, saldırgan kapıdan anahtarla giriyor demektir.
Savunma katman katman kurulur. Giriş denemesi başına artan gecikme koyun: ilk hata bedava, ikincisi iki saniye, üçüncüsü sekiz... Bot için bu, işi ekonomik olmaktan çıkarır. Hesap ve IP bazlı kilitleme ekleyin; sunucu tarafında fail2ban bu işi gayet iyi görür, uygulama içinde de yapılabilir. Yönetici panellerini IP kısıtına alın ya da en azından ikinci bir doğrulama katmanının arkasına koyun.
Ve asıl mesele: 2FA. İki faktörlü doğrulama açıksa, şifre sızsa bile hesap düşmez. Bu tek önlem, brute force saldırılarının bütün ekonomisini bozar. Yönetici hesaplarında 2FA'yı tercih değil zorunluluk yapın — biz bunu müşterilerimize artık sözleşme maddesi ciddiyetiyle söylüyoruz.
Panel URL'sini değiştirmek gerçek bir koruma mı? Değil; bulan bulur. Ama bot gürültüsünü ciddi azalttığı için loglarınız okunur hale gelir, gerçek tehdidi fark etmeniz kolaylaşır. Biz buna "koruma değil, hijyen" diyoruz.
Bir de görünürlük meselesi var. Baştaki müşterimiz saldırıyı fark etmemişti, çünkü kimse loglara bakmıyordu — ve bakılmayan log, hiç tutulmayan log kadar işe yaramaz. Başarısız giriş denemelerini sayan, eşik aşıldığında e-posta veya mesaj atan basit bir uyarı düzeneği, çoğu framework'te yarım günlük iştir. Saldırıyı tek başına durdurmaz belki; ama size en kıymetli şeyi kazandırır: erken haber. Güvenlik olaylarının maliyeti, fark edilme süresiyle katlanarak büyür.
DDoS'ta amaç musluğu kapatmak değil, suyu süzmek
Hacimsel DDoS'un acı gerçeği şu: o trafiği kendi sunucunuzda karşılayamazsınız. Saldırı size ulaşmadan boru dolar; hosting firmanız da genellikle sizi korumak yerine IP'nizi null-route edip (yani erişime tamamen kapatıp) kendi ağını kurtarır. Saldırganın istediği kesinti, bizzat hosting firmanız eliyle gerçekleşmiş olur. Bu yüzden "daha güçlü sunucu alalım" refleksi, bu problemde para israfıdır.
Saldırının ekonomisini de bilmekte fayda var: yeraltı piyasasında "booter" denen kiralık DDoS servisleri, birkaç dolara dakikalarca saldırı satıyor. Yani size husumet besleyen herhangi biri — rakip firma şart değil, sitenizden azarlanan bir müşteri bile — harçlığıyla sizi hedefleyebilir. Savunmanın saldırıdan kat kat pahalı olduğu bu asimetride tek rasyonel strateji, yükü kendi omzunuzdan çok daha büyük oyuncuların omzuna, yani CDN katmanına devretmektir.
Gerçekçi çözüm, trafiği sizden önce bir CDN/proxy katmanından geçirmek. Cloudflare ve benzeri servisler kötü trafiği kenarda süzer, temizini size iletir; origin sunucunuzun IP'si de dış dünyadan gizlenir. Küçük ve orta ölçekli siteler için bu servislerin ücretsiz veya düşük maliyetli katmanları bile hayat kurtarır.
Yalnız bir ayrıntı var ki sahada defalarca canımızı yaktı: origin IP'niz DNS geçmişi kayıtlarından, unutulmuş alt alan adlarından veya sunucunuzdan atılan e-postaların başlıklarından çoktan sızmış olabilir. Sızmışsa, saldırgan CDN'e hiç uğramadan doğrudan sunucunuzu vurur ve bütün yatırım boşa gider. CDN arkasına geçerken origin IP'yi de değiştirin; güvenlik duvarında yalnızca CDN'in IP aralıklarına izin verin. Bu iki adımı atlanmış kurulumu o kadar çok gördük ki, artık kontrol listemizin en başında duruyor.
Sinsi olan: uygulama katmanı DoS
Herkes saniyede yüz binlerce isteklik saldırıları konuşur; oysa bir siteyi saniyede 10 istekle de düşürebilirsiniz — yeter ki o istek pahalı olsun. Filtresiz çalışan bir arama sayfası, tarih aralığı sınırı olmayan bir rapor ekranı, her satır için ayrı sorgu atan N+1'li bir liste... Bu uçlara yüklenen bir saldırgan (hatta bazen kötü niyeti bile olmayan bir bot), veritabanınızı dakikalar içinde dize getirir.
Geçen yıl bir müşterimizde tam bu senaryoyu yaşadık: sıradan bir arama motoru botu, sitedeki filtre kombinasyonlarını gezerken her seferinde tam tablo taraması tetikleyen bir sorguya denk geliyordu. Ortada saldırı yoktu; site yine de düştü.
Buradaki savunma, rate limiting'i endpoint'in maliyetine göre ayarlamaktır. Ana sayfaya dakikada 300 istek normal olabilir; ağır rapor ekranına dakikada 5 bile fazladır. Pahalı işleri kuyruğa alın, kullanıcıya "raporunuz hazırlanıyor, bitince haber vereceğiz" deyin. Her sorguya zaman aşımı koyun ki tek bir kaçak sorgu bütün bağlantı havuzunu rehin almasın.
Önbelleğin de bu katmanda hakkı yenir. Anonim kullanıcıya dönen sayfalar cache'ten servis ediliyorsa, gelen istek seli veritabanınıza hiç ulaşmaz; kenar sunucu emer, geçer. Yani performans için yaptığınız her önbellek yatırımı aynı zamanda bir güvenlik yatırımıdır — tek taşla iki kuş, üstelik ikisi de semiz.
Bütçesi ne olursa olsun herkesin yapması gereken dört iş
Bunca yıllık saha deneyimini dört maddeye sıkıştırmam gerekse şunları söylerim: sitenizi bir CDN/proxy katmanının arkasına alın (origin IP'yi değiştirerek), girişlere 2FA ve deneme limiti koyun, pahalı endpoint'leri ayrı ve sıkı limitleyin, anormal trafikte sizi gece uyandıracak bir izleme kurun. Bu dördü ne para ne zaman olarak büyük yatırım; ama otomatik saldırıların %95'ini sizin için sıkıcı hale getirir.
Güvenlikte amaç zaten tam olarak bu: saldırgana kolay lokma olmamak. Botlar romantik değildir; direnç gördükleri yerde bir sonraki IP'ye geçerler.
Yazının başındaki müşterimize dönersek — o 41 bin denemenin tamamı, iki saatlik bir çalışmayla kurduğumuz deneme limiti ve 2FA duvarına çarpıp söndü. Sonraki ay aynı panelde 200'ün altında deneme kaldı; botlar sıkılmıştı. Kendi loglarınızda neler döndüğünü merak ediyorsanız (ve bence etmelisiniz), bir güvenlik kontrolü için bize yazın; bakması bizden, kararı sizden.