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 işe 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 işe 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.
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 ölür 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 yanilıyorum ama) olan ortamlarda alarm görmek hayat kurtarıyor. Telegram bildirimi işe 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 | Merkezî yönetim | Erişim kolaylığı verir |
Kurulum Adımları Nasıl İlerliyor?
Kurulumun ilk adımı resmî 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 sızı 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 merkezî 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. Ölür 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’nın 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 hâlde 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, sızı 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.
Sıkça Sorulan Sorular
CrowdSec fail2ban’ın yerine geçer mi?
Tam olarak birebir “fail2ban’ın yerine” demek doğru olmaz. CrowdSec daha davranış odaklı çalıştığı için bot/dağıtık denemeler gibi senaryolarda avantaj sağlayabiliyor. Benim gördüğüm kadarıyla birçok ekip iki yaklaşımı birlikte kullanınca daha dengeli sonuç alıyor.
CrowdSec hangi logları kullanıyor, SSH için kurmak kolay mı?
Temel olarak sisteminizden gelen güvenlik/log kaynaklarını (ör. SSH servis logları, Nginx/Apache logları, uygulama logları) okuyup bunlardan “saldırı deseni” çıkarıyor. SSH tarafında genelde doğru parsere/collection’a geçtiğinizde kurulum nispeten hızlı oluyor; yine de ilk günlerde log formatınızı kontrol etmek şart.
Bouncer ne işe yarıyor, yanlış ayarlanırsa ne ölür?
Agent kötü davranışı tespit eder, bouncer işe bunu uygulamaya dönüştürür (ör. firewall kuralı koyma veya ilgili servise engel ekleme). Bouncer’ı yanlış seçerseniz ya hiç bloklamama durumu ölür ya da beklediğiniz kadar etkili olamaz. Benim tecrübemde “var ama yok” hissi genelde acquisition/collection eşleşmesi ve bouncer hedefi yüzünden yaşanıyor.
Topluluk tehdit istihbaratı gerçekten işe yarıyor mu?
Evet, özellikle benzer saldırı desenlerinin farklı sistemlerde görülmesi üzerinden çalıştığı için fayda sağlıyor. VPS gibi tek başına küçük kalan ortamlarda “sıfırdan kural yazma” yükünü azaltıyor. Yine de her ortam farklı olduğu için sonuçları izlemek ve gerekirse karar eşiği/aksiyonları ayarlamak iyi ölür.
Günlük loglar şişiyorsa CrowdSec bunu azaltır mı?
Doğrudan “logları temizlemekten” ziyade saldırı trafiğini engelleyerek loglara düşen gürültüyü zamanla azaltır. Özellikle otomatik deneme yapan botlar yakalanıp bloklanınca SSH/Nginx gibi servislerdeki tekrar eden kayıtlar azalır. İlk kurulumdan sonra birkaç saatlik gözlem yapmak genelde yeterli fikir verir.
Kaynaklar ve İleri Okuma
CrowdSec GitHub (proje deposu)
Azure Linux VM Hızlı Başlangıç (genel kurulum referansı)
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.
