Melindungi Server dengan Data Komunitas CrowdSec

Kamu baru saja menyalakan VPS baru, dan belum genap sejam, log SSH sudah berisi percobaan login dari IP yang tidak dikenal. IP yang sama mungkin sudah mencoba hal serupa ke banyak server lain sebelum sampai ke servermu. CrowdSec dibangun dari ide sederhana: kalau server lain sudah melihat IP itu menyerang, servermu bisa memblokirnya lebih awal.

CrowdSec adalah perangkat keamanan open-source yang membaca log server, mengenali perilaku menyerang lewat skenario, lalu memblokir pelakunya. Bedanya dengan alat berbasis log yang lebih tua: setiap instalasi bisa ikut membagikan sinyal serangan, dan sebagai gantinya menerima daftar IP penyerang yang sudah divalidasi dari komunitas pengguna lain.

Komponen yang perlu dipahami

Dokumentasi CrowdSec membagi sistemnya menjadi beberapa bagian dengan tugas yang jelas. Per 4 November 2026, rilis terbaru Security Engine di halaman GitHub-nya adalah v1.8.2.

Security Engine adalah inti yang dipasang di server. Di dalamnya ada Log Processor, yang membaca log dari berbagai sumber dan mencocokkannya dengan skenario perilaku, misalnya banyak login gagal dalam waktu singkat atau pemindaian path yang tidak ada. Fitur WAF milik CrowdSec, AppSec, adalah bagian dari Log Processor dan menyaring request HTTP dari web server yang kompatibel. Lalu ada Local API, yang menyimpan keputusan (misalnya "blokir IP ini 4 jam") dan menjadi penghubung semua komponen.

Remediation Components, yang sering disebut bouncer, adalah bagian yang benar-benar menjalankan keputusan. Bouncer bisa bekerja di firewall (iptables, nftables), di web server, atau di reverse proxy. Pemisahan ini berarti satu Security Engine bisa melayani beberapa bouncer, dan keputusan dari satu server bisa diterapkan di server lain.

Central API menerima sinyal yang dibagikan dan mengirim balik blocklist komunitas. Console di app.crowdsec.net adalah antarmuka web opsional untuk melihat peringatan dari banyak server sekaligus.

Apa bedanya dengan Fail2ban?

Keduanya membaca log dan memblokir IP, jadi wajar bila dibandingkan. Perbedaannya ada pada arsitektur dan sumber data.

Fail2ban tetap pilihan yang masuk akal untuk satu server dengan kebutuhan sederhana, dan konfigurasinya dibahas di Fail2ban untuk blokir brute force. CrowdSec lebih menarik bila kamu mengelola beberapa server, ingin blokir di level reverse proxy atau firewall jaringan, atau ingin manfaat dari data serangan yang dilihat pengguna lain. Menjalankan keduanya sekaligus untuk log yang sama biasanya hanya menambah kerumitan.

Memasang di Debian atau Ubuntu

Dokumentasi resmi memakai skrip yang menambahkan repositori paket CrowdSec, lalu memasang lewat apt:

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec

Sebelum menjalankan skrip dari internet, kamu bisa membuka isinya dulu di browser. Dokumentasi resminya menegaskan bahwa Security Engine sendiri hanya mendeteksi. Pada tahap ini belum ada yang diblokir.

Blokir baru terjadi setelah bouncer dipasang. Untuk web server atau reverse proxy seperti Nginx, dokumentasi menganjurkan bouncer khusus yang juga mendukung WAF, misalnya crowdsec-nginx-bouncer. Untuk layanan non-web seperti SSH, pakai bouncer firewall. Paket resmi untuk iptables:

sudo apt install crowdsec-firewall-bouncer-iptables

Beberapa perintah cscli untuk memeriksa hasilnya:

• sudo cscli metrics menampilkan log yang dibaca, parser yang bekerja, dan bouncer yang terhubung.
• sudo cscli decisions list menampilkan IP yang sedang diblokir dan alasannya.
• sudo cscli alerts list menampilkan peringatan yang memicu keputusan.
• sudo cscli collections install crowdsecurity/nginx menambah koleksi untuk layanan tertentu, di contoh ini Nginx.

Seperti alat blokir apa pun, pastikan IP kantor dan server monitoring tidak ikut terblokir. CrowdSec menyediakan mekanisme allowlist untuk itu. Siapkan juga akses konsol darurat dari panel penyedia server. Langkah pengamanan dasar lain tetap berlaku, seperti di cara mengamankan VPS baru.

Data apa yang dibagikan, dan bisakah dibatasi?

Ini pertanyaan wajar untuk alat yang mengandalkan komunitas. Menurut dokumentasi Central API, Local API mengirim metadata sinyal berupa nama skenario yang terpicu, hash dan versinya, waktu keputusan, ID mesin, serta IP pelaku beserta informasi geolokasinya bila ada. Saat login ke Central API, Security Engine juga melaporkan daftar skenario yang aktif. Isi log server dan data pengunjung yang sah tidak termasuk dalam daftar yang disebutkan dokumentasi.

Pengiriman ini bisa diatur. Dokumentasi menyebut pengiriman metadata sinyal bisa dimatikan, dan peringatan dari skenario buatan sendiri atau skenario yang sudah diubah bisa dikecualikan dengan cscli console disable custom dan cscli console disable tainted. Keputusan manual hanya dikirim bila opsi manual aktif, yang menurut dokumentasi diaktifkan oleh cscli console enroll.

Perlu dipahami imbal baliknya. Blocklist komunitas yang diterima disesuaikan dengan skenario yang kamu jalankan dan bergantung pada partisipasi berbagi. Bila pengiriman dimatikan sepenuhnya, CrowdSec tetap bekerja sebagai pendeteksi lokal, tapi manfaat data komunitasnya berkurang. Untuk bisnis yang punya kebijakan ketat soal data keluar, baca halaman privasi dan dokumentasi Central API secara utuh sebelum mendaftarkan server ke Console.

Di mana CrowdSec berhenti

CrowdSec menangani perilaku yang terlihat di log, terutama brute force, pemindaian, dan penyalahgunaan yang berulang. Ia tidak menambal aplikasi yang punya celah, dan blokir per IP kurang berdaya menghadapi serangan dari ribuan IP berbeda yang masing-masing mengirim sedikit request. Untuk banjir trafik berskala besar, perlindungan di level jaringan tetap dibutuhkan, seperti dibahas di anti-DDoS VPS.

Ringkasnya, CrowdSec memisahkan mata (Security Engine) dari tangan (bouncer), lalu menambahkan ingatan bersama dari komunitas. Pasang Security Engine dan satu bouncer firewall dulu, cek hasilnya dengan cscli metrics dan cscli decisions list, lalu putuskan seberapa banyak sinyal yang ingin kamu bagikan.