Sunucu güvenliği deyince çoğu kişinin aklına hâlâ aynı ikili geliyor: fail2ban ve biraz da nftables. İş görür mü? Görür, tabi ki görür. Ama işin aslı şu: saldırılar artık tek bir IP’den tek bir makineye çarpıp duran basit denemeler değil. Botlar dolaşıyor, deneme sayısı artıyor, davranış kalıpları değişiyor — ve açık konuşayım, klasik yaklaşım bazen bu tempoya yetişemiyor. Maalesef.
Ben de bu konuyu ilk kez 2023’ün sonbaharında, İstanbul’da küçük bir müşteri projesinde kurcalamıştım. Loglar gece boyunca şişiyor, SSH’a gelen denemeler saçma sapan saatlerde artıyordu. Fail2ban çalışıyordu çalışmasına,. Bana hep “tek tek kapıları kapatıyorum” hissi veriyordu — hani bir elinizle su taşımak gibi bir şey. CrowdSec’i test ettiğimde ise daha kolektif bir mantıkla çalıştığını fark edince kafamda taşlar yerine oturdu.
Dürüst olmak gerekirse, CrowdSec’in olayı tam burada başlıyor (evet, doğru duydunuz). Sadece kendi sunucundaki kötü davranışı izlemiyor; başka makinelerde görülen saldırı desenlerinden de besleniyor. Yani biri başka yerde aynı numarayı yapmışsa, senin sistemin de o ipucundan faydalanabiliyor. Fena değil. Hatta baya işe yarıyor.
CrowdSec Neyi Farklı Yapıyor?
Bakın şimdi, CrowdSec’i sıradan bir “IP banlayan araç” gibi düşünmek biraz eksik kalır. O daha çok davranış analizi yapan bir güvenlik katmanı gibi çalışıyor; log dosyalarını okuyor, belirli kalıpları yakalıyor, buna göre karar veriyor ve sonra da ister yerel firewall’a müdahale ediyor ister Nginx gibi servislerin önüne geçip trafiği kesiyor. Güzel bir zincir kurmuşlar yani.
Burada güzel taraf şu: tehdit istihbaratı topluluk üzerinden akıyor. Bir saldırı deseni başka ülkede görülmüş ve doğrulanmışsa, sizin tarafta da tanınma ihtimali yükseliyor. Bu yapı özellikle VPS kullanan küçük ekipler için çok iyi. Sıfırdan kural yazmakla uğraşmadan biraz omurga kazanıyorsunuz.
Gel gelelim her şey güllük gülistanlık değil. Eğer log kaynaklarını düzgün bağlamazsanız ya da bouncer tarafını yanlış seçerseniz sistem “var ama yok” hissi verebiliyor. Yani kağıt üstünde süper görünüyor, pratikte biraz el emeği istiyor (kendi tecrübem). Bu kadar mı? Hayır, devam ediyor.
Neden fail2ban’dan farklı?
Fail2ban’ın en kuvvetli yani sadeliği. Kurarsınız, birkaç jail tanımlarsınız, biter gider. CrowdSec ise daha zengin bir model sunuyor; yalnızca regex tabanlı yakalama yok, bir ekosistem var. Hmm, bu iyi mi kötü mü? İkisi de aslında.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Buna rağmen bazı durumlarda fail2ban daha rahat olabiliyor. Mesela tek sunuculu minik projelerde hızlı çözüm arıyorsanız, CrowdSec’in konsol kaydı, bouncer eşlemesi ve acquisition ayarları size fazla gelebilir — haklı olarak. Ama büyüme planınız varsa iş büyük ölçüde değişiyor. O noktada fail2ban biraz küçük kalıyor.
Kurulumdan Önce Elinizin Altında Olsun
İtiraf edeyim, Lafı gevelemeden söyleyeyim: kuruluma dalmadan önce birkaç şeyi netleştirmek lazım. Ubuntu 22.04 LTS üzerinde anlatacağım ama Debian tabanlı sistemlerde de benzer şekilde ilerlersiniz. Sudo erişimi şart; bu zaten tartışmasız.
Nftables kullanmanız tavsiye edilir çünkü örnek kurulum o tarafa yaslanıyor. İptables ile de olur ama orada ayrı ayar gerekebilir. Yol var yani, ama biraz dolambaçlı.
Araya gireyim: Bir de monitoring kısmını boş geçmeyin derim. Grafana ve Prometheus (belki yanılıyorum ama) olan ortamlarda alarm görmek hayat kurtarıyor. Telegram bildirimi ise küçük ekipler için baya kullanışlı — özellikle gece yarısı garip trafik geldiğinde insanın haberi olsun istiyorsunuz, değil mi? (şaşırtıcı ama gerçek)
| Bileşen | Görev | Not |
|---|---|---|
| CrowdSec Agent | Log analizi | Karar üretir |
| Firewall Bouncer | Kural uygular | Nftables veya başka hedefe bağlanır |
| SaaS Console | Merkezi yönetim | Erişim kolaylığı verir |
Kurulum Adımları Nasıl İlerliyor?
Kurulumun ilk adımı resmi repoyu sisteme eklemekten geçiyor. Ardından agent kuruluyor, servis ayağa kalkıyor. Bu kadar basit gibi duruyor — ama ilk kontrolü atlamayın, çünkü servis aktif mi değil mi görmek önemli. Küçük ama kilit bir adım bu. Daha fazla bilgi için Telefonundan Çalışan Yapay Zekâ: PLC Ustası Olmadan Önce yazımıza bakabilirsiniz. Bu konuyla ilgili Java’da Öncelik Kuyruğu: Gerçek Zamanlı Tehdit Yönetimi yazımıza da göz atmanızı tavsiye ederim.
Durun, bir saniye.
# Repo ekle
curl -s https://install.crowdsec.net | sudo bash
# Agent kurulumu
sudo apt update && sudo apt install crowdsec -y
# Servisi kontrol et
sudo systemctl status crowdsec
sudo cscli version
Editör masasında bunu ilk kez denerken Ankara’daki test VM’ime kurmuştum; 2024 Şubat ayında yaptığım o testte wizard.sh beni epey şaşırtmıştı çünkü çalışan servisleri tarayıp acquisition dosyasına başlangıç önerileri bırakıyordu. Hani bazen araçlar sizi yorar ya, üstüne bir de düşündürür… burada tam tersi oldu diyebilirim. Şaşırdım açıkçası.
Bence, /etc/crowdsec/acquis.yaml dosyası kritik nokta (bizzat test ettim). Hangi logların okunacağını buradan belirliyorsunuz — SSH logu mu, Nginx access logu mu, auth.log mu, neyi izlemek istiyorsanız oraya bağlıyorsunuz. Burası yanlış olursa zincirin geri kalanı havada kalıyor.
Enrolment neden önemli?
CrowdSec Console’a bağlanmak sadece gösteriş için değil. Asıl olay merkezi görünürlük almak. Birden fazla sunucu yönetiyorsanız tek panelden kararları görmek ciddi rahatlık sağlıyor; bunu yaşamadan anlatması zor.
Bence orta ölçekli ekiplerde bu bölüm en değerli parça. Küçük startup’ta belki lokal kullanım yetebilir ama enterprise seviyede remote decision control olmadan işler karışıyor. Bir güvenlik olayını üç farklı sunucuda ayrı ayrı kovalamak istemezsiniz — açıkçası kimse istemez. Bu konuyla ilgili AI Ajanınıza UX Denetimi Süper Gücü: CLI + MCP ile Hızlı Başlangıç yazımıza da göz atmanızı tavsiye ederim.
Bouncer Tarafı Olmazsa Olmaz mı?
Neredeyse. Olur olmaz demeyeyim ama tüm mantık burada tamamlanıyor. Agent saldırıyı görüyor, bouncer kapıyı kapatıyor. Sadece gözlem yapmak yetmiyor; müdahale lazım. İşte o yüzden bouncer seçimi önemli. Xiaomi’nin Ultra Kameraları Neden Daha Pahalı Olabilir? yazımızda da bu konuya değinmiştik. PackGoat: Seyahat Çantasını Akıllı Toplayan Küçük Yardımcı yazımızda da bu konuya değinmiştik.
- Nftables bouncer → firewall seviyesinde engeller; — ciddi fark yaratıyor
- Nginx bouncer → web katmanında kısıtlama yapar;
- Başka özel bouncer’lar → senaryoya göre değişir; — ciddi fark yaratıyor
- Kısacası her yere aynı sopayla vurulmuyor;
- İhtiyacınıza uygun bileşeni seçmeniz gerekiyor;
- Aksi halde gereksiz karmaşa çıkabiliyor;
- Bazen hayal kırıklığı da buradan doğuyor zaten…
Şöyle söyleyeyim, Kendi deneyimimde firewall bouncer en dengeli seçenek oldu. Çünkü kaba kuvvet girişimleri genelde (söylemesi ayıp) ağ seviyesinde kesildiğinde hem kaynak tüketimi düşüyor hem de uygulama katmanı rahatlıyor; özellikle düşük kaynaklı VPS’lerde bu fark hemen hissediliyor. Anında.
CrowdSec’in en güçlü yani sadece bloklama yapması değil; doğru kurulduğunda size olayların nedenini de gösterebilmesi.
Tuning Yapmazsanız Rahat Etmezsiniz
CrowdSec kuruldu diye iş bitmiyor, bunu net söyleyeyim. İlk günlerden sonra log hacmine bakmanız lazım. Çok agresif kural varsa masum kullanıcıları rahatsız edebilirsiniz; çok gevşek kalırsanız botlar aradan sızabilir. İnce ayar işi biraz terzi işi gibi — ölçersiniz, düzeltirsiniz, tekrar bakarsınız, böyle gider.
Kısa bir not düşeyim buraya.
Mesela benim gördüğüm en yaygın hata yanlış log kaynağı seçimi oluyor. SSH auth.log okunmuyorsa bütün zincir eksik kalıyor (en azından benim deneyimim böyle). Ya da web server loglarında ters proxy yüzünden gerçek IP görünmüyorsa analiz sapabiliyor. Burada reverse proxy zincirini temiz okumak şart; bu kısmı atlatırsanız gerisi zaten çalışmıyor.
Küçük startup vs enterprise senaryosu
Küçük startup:
- Tek panel yeterli olabilir
- Basit nftables bouncer yeterli
- Telegram uyarısı çoğu zaman yeter
Enterprise:
- Merkezi console zorunluya yakın
- Birden çok agent/bouncer gerekir
- SIEM entegrasyonu anlam kazanır
Dikkat Edilmesi Gereken Pratik Noktalar
Şimdi burası biraz “öğrendim, not aldım, sizi de uyarayım” kısmı. Gerçekten yaşanan şeyler bunlar.
İlk dikkat noktası whitelist. Kendi IP’nizi ya da iç ağ bloğunu baştan listeye almazsanız, bir gün kendinizi kendi sunucunuzdan kilitlenmiş bulabilirsiniz. Kulağa saçma geliyor ama oluyor. Ben de bir kez yaşadım; o gece epey eğlenceli geçmişti, tabii eğlenceli diyorum biraz kenarından.
İkinci nokta: hub üzerinden gelen senaryoları körü körüne aktif etmeyin. Her senaryo her ortam için uygun değil. Mesela yoğun API trafiği olan bir serviste rate-limit senaryosu yanlış ayarlanırsa meşru kullanıcıları engelleyebilirsiniz. Test ortamında deneyin önce, sonra production’a alın. Bu kural aslında her araç için geçerli ama CrowdSec’te biraz daha kritik.
Üçüncü şey — ve bence en çok atlanan — düzenli metrik takibi. cscli metrics komutu size gerçekten değerli bilgi veriyor; kaç karar verildi, hangi senaryo ne kadar tetiklendi, bouncer düzgün çalışıyor mu… Bunlara bakmadan sistemi “kurdum, çalışıyor” diye bırakırsanız bir süre sonra neler döndüğünü bilmezsiniz. Bilmemek de güvenlik açısından iyi değil tabii.
Son olarak şunu da söyleyeyim: topluluk Hub’ındaki senaryolar sürekli güncelleniyor. Ara ara cscli hub update yapın. Eski senaryo eski tehditleri tanır; yeni versiyonlar daha akıllı davranıyor. Bu kısım küçük ama fark yaratıyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
