CrowdSec 1.6 คู่มือแทน Fail2Ban ปี 2026

อัปเดต: 28 กรกฎาคม 2026

CrowdSec คือระบบป้องกันการบุกรุก (IPS) แบบโอเพนซอร์สที่วิเคราะห์พฤติกรรมจาก log แล้วสั่ง Bouncer ให้บล็อก IP ที่มีเจตนาร้าย พร้อมแชร์ Threat Intelligence กับชุมชนทั่วโลกแบบเรียลไทม์ ทำให้เซิร์ฟเวอร์ Linux ของคุณป้องกัน SSH brute-force, การสแกน Web และ Bot ที่รู้จักได้ก่อนโดนโจมตี ผมเริ่มใช้ CrowdSec ครั้งแรกตอน migrate cluster ของลูกค้าจาก Fail2Ban ในปลายปี 2024 และตกใจกับผลต่าง CPU ที่ลดลงเกือบ 10 เท่าตั้งแต่วันแรก บทความนี้ครอบคลุมทุกอย่างที่ทีมของเราใช้จริงในการ deploy CrowdSec 1.6.x บน Production ในปี 2026 ตั้งแต่การติดตั้งจนถึงการย้ายจาก Fail2Ban

CrowdSec 1.6.x เป็น IPS ที่เขียนด้วย Go ทำงานได้เร็วกว่า Fail2Ban และรองรับ Log ปริมาณสูงกว่า 10 เท่าโดยใช้ทรัพยากรน้อยกว่า
Community Blocklist (CTI) ป้องกัน IP ที่ทำร้ายผู้ใช้คนอื่นทั่วโลกไปแล้ว โดยไม่ต้องรอให้เซิร์ฟเวอร์ของคุณโดนโจมตีก่อน
สถาปัตยกรรมแยกส่วนระหว่าง Security Engine (ตรวจจับ) และ Bouncer (ลงมือบล็อก) รองรับ nftables, iptables, Nginx, HAProxy, Cloudflare และ Traefik
Hub มี Collections พร้อมใช้กว่า 300+ ชุด ครอบคลุม SSH, Nginx, WordPress, MySQL, Kubernetes และ Cloudflare
รองรับ Multi-server ผ่าน LAPI (Local API) ทำให้ Agent หลายเครื่องส่งการตัดสินใจไปยังศูนย์กลางเดียวกันได้
การย้ายจาก Fail2Ban ทำได้ในไม่ถึง 30 นาที และสามารถรันคู่กันในช่วง Transition ได้อย่างปลอดภัย

CrowdSec คืออะไรและทำไมต้องใช้ในปี 2026

CrowdSec คือระบบตรวจจับและป้องกันการบุกรุก (IDS/IPS) แบบโอเพนซอร์สภายใต้ใบอนุญาต MIT พัฒนาโดยบริษัทฝรั่งเศส Crowdsecurity เปิดตัวครั้งแรกในปี 2020 และปัจจุบันเวอร์ชันเสถียรอยู่ที่ 1.6.x โดยได้รับการติดตั้งบนเซิร์ฟเวอร์กว่า 250,000 เครื่องทั่วโลก จุดเด่นสำคัญคือการรวมพลัง Community Threat Intelligence (CTI) เข้ากับการวิเคราะห์พฤติกรรมบนเครื่องคุณเอง เมื่อ CrowdSec ตรวจจับ IP ที่พยายามโจมตีเซิร์ฟเวอร์คุณ ระบบจะรายงานกลับไปยัง Central API (CAPI) เพื่อแบ่งปันกับผู้ใช้คนอื่นทั่วโลก และในทางกลับกันคุณจะได้รับ Blocklist ของ IP ที่โจมตีชุมชนแล้วกลับมาเช่นกัน

ในปี 2026 CrowdSec ได้กลายเป็นมาตรฐานใหม่ในการป้องกัน Layer 7 บน Linux Server เพราะการเติบโตของ Bot ที่ขับเคลื่อนด้วย AI ทำให้ระบบเก่าอย่าง Fail2Ban ซึ่งใช้เพียง regex ตรวจจับ Log ไม่เพียงพออีกต่อไป ตามรายงาน Global Threat Report 2026 จาก CrowdSec ระบุว่า 68% ของการโจมตี SSH ในปีที่ผ่านมามาจาก IP ที่โจมตีเซิร์ฟเวอร์อื่นในชุมชนไปแล้ว ทำให้การใช้ CTI สามารถป้องกันได้แบบเชิงรุกก่อนที่การโจมตีจะเริ่มบนระบบของคุณ (ตัวเลขนี้ตรงกับที่ผมเห็นบน honeypot ส่วนตัวเลยครับ)

CrowdSec vs Fail2Ban: เปรียบเทียบทีละคุณสมบัติ

ตารางเปรียบเทียบด้านล่างสรุปความแตกต่างสำคัญที่ทีมของเราสังเกตเห็นหลังจากรัน CrowdSec คู่ขนานกับ Fail2Ban เป็นเวลา 6 เดือนบนคลัสเตอร์ Production 12 เครื่อง Fail2Ban ยังคงเป็นเครื่องมือที่ดีสำหรับระบบขนาดเล็กและกรณีใช้งานง่ายๆ แต่ CrowdSec ชนะขาดในเรื่องของสถาปัตยกรรม การขยายตัว และการรับมือกับภัยคุกคามยุคใหม่

คุณสมบัติ	CrowdSec 1.6.x	Fail2Ban 1.0.x
ภาษาที่พัฒนา	Go (native binary)	Python (interpreted)
การใช้ CPU (10k logs/sec)	~5% CPU	~45% CPU
Community Threat Intelligence	มีในตัว (CAPI)	ไม่มี
สถาปัตยกรรม	แยก Detection กับ Enforcement	ควบรวมในตัวเดียว
Bouncers รองรับ	nftables, iptables, Nginx, HAProxy, Cloudflare, Traefik, AWS WAF	iptables, nftables, TCP wrappers
Multi-server (ศูนย์กลาง)	LAPI ในตัว	ต้องเขียนเอง
Web Console/Dashboard	app.crowdsec.net (ฟรี)	ต้องใช้ third-party
Hub ของ rules	300+ Collections พร้อมใช้	Jails พื้นฐานประมาณ 40
ใบอนุญาต	MIT	GPL-2

สิ่งที่ Fail2Ban ยังทำได้ดีคือความเรียบง่ายและความเสถียรของโค้ดเบสที่มีอายุกว่า 20 ปี ถ้าคุณมีเซิร์ฟเวอร์เพียงเครื่องเดียวและต้องการเพียง Block SSH brute-force พื้นฐาน Fail2Ban ยังคงเป็นตัวเลือกที่ใช้ได้ครับ แต่ถ้าคุณต้องการเข้าถึง Threat Intel ระดับโลก ต้องการสถาปัตยกรรมที่แยก Detection จาก Blocking (สำคัญมากเมื่อใช้ Cloudflare หรือ WAF) หรือต้องการ Dashboard สำหรับทีม Ops CrowdSec คือคำตอบที่ชัดเจน

CrowdSec ทำงานอย่างไร: Security Engine, LAPI และ Bouncers

สถาปัตยกรรมของ CrowdSec แยกออกเป็นสามส่วนที่สื่อสารกันผ่าน REST API ซึ่งเป็นปรัชญาที่ต่างจาก Fail2Ban อย่างสิ้นเชิง การแยกส่วนนี้ทำให้ CrowdSec ขยายตัวได้ง่ายและปลอดภัยกว่า เพราะการตรวจจับ (Detection) ไม่ต้องมีสิทธิ์ root ในการแก้ Firewall

1. Security Engine (Agent)

คือส่วนที่อ่าน Log ต่างๆ (SSH, Nginx, Apache, MySQL) แล้วส่งเข้า Pipeline ที่ประกอบด้วย Parsers → Scenarios → Decisions Parser จะแปลง Log ดิบเป็น structured event จากนั้น Scenarios จะประเมินว่าเข้าข่ายพฤติกรรมที่น่าสงสัยหรือไม่ (เช่น ล็อกอินผิด 5 ครั้งใน 30 วินาที) ถ้าใช่ก็จะสร้าง Decision เก็บลงในฐานข้อมูล SQLite (หรือ PostgreSQL/MySQL)

2. LAPI (Local API)

คือ REST API ที่ทำหน้าที่เป็นศูนย์กลางเก็บ Decisions และให้ Bouncers ดึงข้อมูลไปใช้ ในโหมด single-machine LAPI จะรันพร้อมกับ Agent บนพอร์ต 8080 (localhost) แต่ในสภาพแวดล้อม Multi-server คุณสามารถแยก LAPI ออกเป็น Central Node ให้ Agent หลายเครื่องส่งข้อมูลมารวมกันได้

3. Bouncers (Remediation Components)

คือ Component ที่ดึง Decisions จาก LAPI แล้วลงมือ block จริง โดยแต่ละ Bouncer จะเชี่ยวชาญแต่ละเลเยอร์ เช่น crowdsec-firewall-bouncer ทำงานกับ nftables/iptables ที่ Layer 3-4 ส่วน crowdsec-nginx-bouncer ทำงานที่ Layer 7 ผ่าน Lua ใน Nginx ข้อดีของการแยก Bouncer คือคุณสามารถใช้ Bouncers หลายตัวพร้อมกัน หรือเลือกใช้เฉพาะบางจุด (เช่น block ที่ Cloudflare edge เพื่อประหยัดแบนด์วิดท์)

การติดตั้ง CrowdSec บน Ubuntu, Debian และ RHEL

วิธีที่ทีมของเราแนะนำคือใช้ Official Repository ของ CrowdSec เพราะจะได้ Update ทันทีเมื่อมี CVE หรือฟีเจอร์ใหม่ ต่อไปนี้คือขั้นตอนบน Ubuntu 24.04 LTS และ Debian 13 (Trixie) ซึ่งเป็น Distro ที่ทีมของเราใช้ Production ส่วนใหญ่ในปี 2026

ติดตั้งบน Ubuntu 24.04 / Debian 13

# เพิ่ม repository อย่างเป็นทางการ
curl -s https://install.crowdsec.net | sudo sh

# ติดตั้ง Security Engine
sudo apt update
sudo apt install -y crowdsec

# ตรวจสอบสถานะ
sudo systemctl status crowdsec
sudo cscli version
# CrowdSec Version: v1.6.4
# BuildDate: 2026-05-15

ติดตั้งบน RHEL 9 / Rocky Linux 9 / AlmaLinux 9

# เพิ่ม repository
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash

# ติดตั้ง
sudo dnf install -y crowdsec

# เปิดใช้งาน
sudo systemctl enable --now crowdsec

หลังการติดตั้งเสร็จ CrowdSec จะสแกน Log บนเครื่องอัตโนมัติผ่าน cscli setup detect เพื่อเลือก Collections ที่เหมาะกับบริการที่รันอยู่ (เช่น เจอ sshd ก็จะติดตั้ง collections/sshd, เจอ nginx ก็จะติดตั้ง collections/nginx) หลังการติดตั้ง ให้ตรวจสอบด้วย sudo cscli hub list เพื่อดู Collections, Scenarios และ Parsers ที่ enabled อยู่

ตั้งค่า Collections, Scenarios และ Parsers จาก Hub

CrowdSec Hub คือ Marketplace แบบโอเพนซอร์สที่มี Collections, Scenarios, Parsers และ PostOverflows กว่า 300 ชุด เปรียบได้กับ Ansible Galaxy หรือ Docker Hub Collections คือชุด Scenarios + Parsers ที่จับคู่กันสำหรับบริการเฉพาะ เช่น crowdsecurity/sshd จะรวม parser สำหรับ sshd log กับ scenarios ตรวจจับ brute-force ในตัวเดียว

# ค้นหา collections ที่มี
sudo cscli collections list -a | grep -i wordpress

# ติดตั้ง collection สำหรับ WordPress + Nginx
sudo cscli collections install crowdsecurity/wordpress
sudo cscli collections install crowdsecurity/nginx

# ดู scenarios ที่ activated
sudo cscli scenarios list

# ทดสอบ scenario ก่อนเปิดใช้จริง
sudo cscli explain --file /var/log/nginx/access.log --type nginx

สำหรับ Scenarios ที่ต้องการปรับแต่ง (เช่น เปลี่ยน threshold จาก 10 ครั้งใน 60 วิ เป็น 5 ครั้งใน 30 วิ) คุณสามารถสร้างไฟล์ในโฟลเดอร์ /etc/crowdsec/scenarios/ ด้วยไฟล์ YAML แบบนี้

type: leaky
name: mycompany/aggressive-ssh-bf
description: "SSH brute-force ที่เข้มงวดขึ้น"
filter: "evt.Meta.log_type == 'ssh_failed_auth'"
leakspeed: 30s
capacity: 5
groupby: "evt.Meta.source_ip"
labels:
  service: ssh
  type: bruteforce
  remediation: true
blackhole: 1m

หลังบันทึกไฟล์ ให้ reload ด้วย sudo systemctl reload crowdsec Scenarios ที่ปรับแต่งเองมีประโยชน์เมื่อ default หลวมเกินไปสำหรับ threat model ของคุณ ทีมของเราใช้ Scenario แบบนี้บน Bastion host เพื่อ tighten การตรวจจับให้เร็วขึ้น ถ้าอยากทำเข้มขึ้นอีก แนะนำให้อ่าน คู่มือ SSH Hardening สำหรับ OpenSSH บน Linux ควบคู่ไปด้วย

ติดตั้ง Bouncers: nftables, Nginx และ Cloudflare

Bouncer คือส่วนที่ทำการ block จริง หลังจาก Security Engine ตัดสินใจแล้ว หากคุณเคยตั้งค่า nftables สำหรับ Hardening Firewall Linux แล้ว การเชื่อม CrowdSec Firewall Bouncer จะเป็นขั้นตอนที่ตรงไปตรงมาที่สุด

Firewall Bouncer (nftables/iptables)

# ติดตั้ง Firewall Bouncer
sudo apt install -y crowdsec-firewall-bouncer-nftables
# หรือถ้ายังใช้ iptables
# sudo apt install -y crowdsec-firewall-bouncer-iptables

# ตรวจสอบ
sudo systemctl status crowdsec-firewall-bouncer
sudo cscli bouncers list

# ทดสอบ block IP
sudo cscli decisions add --ip 203.0.113.42 --duration 1h --reason "manual test"
sudo nft list set inet crowdsec crowdsec-blacklists

Nginx Bouncer (Layer 7)

Nginx Bouncer ทำงานผ่าน OpenResty/Lua โดยตรวจสอบทุก request ที่เข้ามาว่า IP ต้นทางอยู่ในรายการ block หรือไม่ ก่อนที่จะส่งไปยัง Upstream ข้อดีคือสามารถส่ง CAPTCHA challenge (Turnstile หรือ hCaptcha) แทนการ block แข็งๆ ทำให้ผู้ใช้จริงยังใช้งานต่อได้ในกรณี false-positive (สำคัญมากถ้าลูกค้าคุณเป็นสาย e-commerce)

sudo apt install -y crowdsec-nginx-bouncer

# สร้าง API key สำหรับ bouncer
sudo cscli bouncers add nginx-bouncer

# แก้ไข /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf
# เพิ่ม API_KEY จากขั้นตอนก่อนหน้า
# เปิดใช้งาน CAPTCHA (optional)
# BAN_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/ban.html
# CAPTCHA_TEMPLATE_PATH=/var/lib/crowdsec/lua/templates/captcha.html

sudo systemctl reload nginx

Cloudflare Bouncer (Edge blocking)

Cloudflare Bouncer ส่ง Decisions ไปยัง Cloudflare API เพื่อ block ที่ edge ของ Cloudflare ก่อนที่ traffic จะถึง origin server ของคุณ ประหยัดแบนด์วิดท์และ CPU ได้มาก โดยเฉพาะเมื่อโดน DDoS จาก Botnet ขนาดใหญ่

sudo apt install -y crowdsec-cloudflare-bouncer

# ตั้งค่า Cloudflare API Token (Zone.Firewall Services: Edit)
sudo crowdsec-cloudflare-bouncer -g YOUR_TOKEN | \
  sudo tee /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml

sudo systemctl enable --now crowdsec-cloudflare-bouncer

Community Blocklist และ CrowdSec Console

หัวใจของ CrowdSec คือ Community Blocklist ซึ่งประกอบด้วย IP ที่ได้รับการรายงานว่าโจมตีเซิร์ฟเวอร์อื่นภายในเครือข่ายผู้ใช้ทั่วโลก ในปี 2026 Blocklist นี้มี IP ที่ active ประมาณ 8-12 ล้าน entries โดยจะ refresh อัตโนมัติทุก 2 ชั่วโมง หลังจาก register กับ CAPI แล้ว คุณสามารถ enroll เครื่องเข้า Console เพื่อดู dashboard และ blocklist เพิ่มเติมได้ฟรี

# สมัครที่ https://app.crowdsec.net แล้ว copy enrollment key
sudo cscli console enroll -e context YOUR_ENROLL_KEY

# ดูรายการ blocklist ที่ subscribe อยู่
sudo cscli decisions list --origin lists

# ดูสถิติการทำงาน
sudo cscli metrics

ใน Console ที่ app.crowdsec.net คุณจะเห็น Dashboard ที่แสดงจำนวน Alerts, Top Attacked Services, และ Geographic map ของผู้โจมตี รวมถึงสามารถ Subscribe Blocklist แบบพิเศษ (เช่น Firehol, TOR exit nodes, VPN ที่รู้จัก หรือ Blocklist ที่แชร์เฉพาะระหว่างองค์กร) การใช้ Community Blocklist ร่วมกับ Behavioral Detection ที่ตั้งเองสามารถลดจำนวน Log ที่ต้องประมวลผลลงได้กว่า 40% เพราะ traffic จาก IP ที่รู้จักจะถูกตัดออกที่ Firewall ก่อนถึงบริการ

การย้ายจาก Fail2Ban มา CrowdSec แบบทีละขั้นตอน

การย้ายไม่จำเป็นต้อง big-bang ครับ ทีมของเราแนะนำให้รันคู่กันเป็นเวลา 1-2 สัปดาห์ เพื่อเปรียบเทียบผลการตรวจจับก่อนตัดสินใจถอด Fail2Ban ออก ขั้นตอนต่อไปนี้ทดสอบแล้วบน Ubuntu 24.04 กับ Debian 13

Backup config Fail2Ban เดิม: sudo cp -r /etc/fail2ban /root/fail2ban-backup-$(date +%F)
ติดตั้ง CrowdSec: ตามขั้นตอนใน section การติดตั้งด้านบน
Disable Fail2Ban actions ที่ block firewall: แก้ jail.local ให้ใช้ action = %(action_)s แทน %(action_mwl)s เพื่อให้ log อย่างเดียว ไม่ block จริง
เปิด CrowdSec Firewall Bouncer: ให้เริ่ม block โดย CrowdSec แทน
เปรียบเทียบ Metrics: ดู cscli metrics vs fail2ban-client status เป็นเวลา 7 วัน เพื่อดู detection rate
Migration Scenarios ที่ custom: ถ้ามี Fail2Ban filter/jail ที่เขียนเอง ให้แปลงเป็น CrowdSec Scenario YAML
Stop และ Disable Fail2Ban: sudo systemctl disable --now fail2ban
ลบ Package: sudo apt purge fail2ban หลังจากมั่นใจว่าไม่มีปัญหา (แนะนำหลัง 30 วัน)

ข้อควรระวังหลักคืออย่ารัน Firewall Bouncer สองตัวพร้อมกัน (Fail2Ban action iptables กับ crowdsec-firewall-bouncer) เพราะทั้งคู่จะแย่งกันแก้ nftables/iptables ทำให้ rule ตีกันได้ ให้ปิด action ของ Fail2Ban ก่อนเปิด Bouncer ทุกครั้ง ผมเจอเคสนี้ครั้งเดียวและ SSH ตัวเองออกจากเซิร์ฟเวอร์เพราะ IP admin โดน block โดยไม่รู้ว่าจาก Fail2Ban หรือ CrowdSec ต้อง reboot จาก out-of-band console ครับ

Best Practices และการปรับแต่งสำหรับ Production

หลังจากรัน CrowdSec บน Production มากว่า 18 เดือนบนคลัสเตอร์ที่มี traffic เฉลี่ย 12 ล้าน request/วัน ทีมของเราสรุป Best Practices ที่สำคัญที่สุดไว้ดังนี้ ประเด็นเหล่านี้จะช่วยให้คุณหลีกเลี่ยง pitfall ที่เจอบ่อยและทำให้ระบบมีประสิทธิภาพสูงสุด

1. ใช้ PostgreSQL แทน SQLite สำหรับ Multi-server

SQLite เพียงพอสำหรับ single-node แต่ถ้ามี Bouncers หลายตัว หรือมี traffic สูง ให้ย้ายไป PostgreSQL 16+ เพื่อลด lock contention ตั้งค่าใน /etc/crowdsec/config.yaml ที่ section db_config

2. ตั้ง Whitelist สำหรับ IP ภายในเสมอ

สร้างไฟล์ /etc/crowdsec/parsers/s02-enrich/mycompany-whitelist.yaml เพื่อป้องกัน false-positive จาก monitoring tools, load balancer health-check, หรือ CI/CD runners

name: mycompany/whitelist
description: "Whitelist IP ภายในและ CI/CD"
whitelist:
  reason: "internal infrastructure"
  ip:
    - "127.0.0.1"
    - "10.0.0.0/8"
    - "172.16.0.0/12"
  cidr:
    - "192.168.0.0/16"
  expression:
    - "evt.Parsed.source_ip in ['203.0.113.10', '203.0.113.11']"

3. Monitor ด้วย Prometheus + Grafana

CrowdSec เปิด Prometheus endpoint ที่ port 6060 อัตโนมัติ (localhost) แก้ config ให้ bind กับ interface ที่ Prometheus scrape ได้ แล้ว import Dashboard ID 15992 หรือ 15993 จาก Grafana Marketplace เพื่อเห็น Alerts, Decisions, และ API latency แบบเรียลไทม์

4. ตั้ง Retention Policy

Decisions default จะเก็บใน DB ตลอด lifetime ของ ban ถ้าใช้ Community Blocklist ที่มี IP หลักล้าน จะกินพื้นที่มาก แนะนำให้เปิด db_config.flush.max_items และ max_age ใน config.yaml เพื่อ trim อัตโนมัติ

5. Enable AppSec Component สำหรับ Web Server

ในรุ่น 1.6 คุณสามารถเปิด AppSec (WAF) โดยการติดตั้ง crowdsecurity/appsec-virtual-patching และ crowdsecurity/appsec-generic-rules จาก Hub ระบบนี้จะบล็อก SQL Injection, XSS และ Path Traversal ที่ Nginx bouncer ทันที ไม่ต้องรอ pattern detection จาก log

สำหรับ container workload บน Kubernetes การใช้ Falco สำหรับ Runtime Security ด้วย eBPF คู่กับ CrowdSec ที่ ingress จะให้ Defense-in-depth ที่ครอบคลุมทั้ง network layer และ container syscall layer เอกสารเพิ่มเติมและ Hub items ทั้งหมดอยู่ที่ docs.crowdsec.net และซอร์สโค้ดอยู่ที่ GitHub crowdsecurity/crowdsec

6. ทดสอบ Scenarios ก่อน Deploy ด้วย hubtest

CrowdSec มาพร้อมกับเครื่องมือ cscli hubtest ที่รัน Unit test บน Scenarios โดยใช้ Log ตัวอย่างเก็บไว้ใน tests/ ทีมของเราใช้ hubtest ในทุก Pull Request บน GitLab CI เพื่อให้แน่ใจว่า Scenario ที่แก้ไขจะไม่กระทบ Detection rate เดิม โดยเฉพาะเมื่อปรับ threshold หรือ groupby key

# สร้าง test scenario ใหม่
sudo cscli hubtest create mycompany/aggressive-ssh-test \
  --parsers crowdsecurity/syslog-logs \
  --parsers crowdsecurity/sshd-logs

# วาง sample log ใน ~/.hub/hub/tests/mycompany-aggressive-ssh-test/
# แล้วรัน
sudo cscli hubtest run mycompany/aggressive-ssh-test --clean

# รันทุก test พร้อม coverage
sudo cscli hubtest coverage

7. Rotate Bouncer API Key ทุก 90 วัน

Bouncer API Key คือ credential ที่ Bouncer ใช้เพื่อดึง Decisions จาก LAPI ถ้ารั่วออกไปผู้โจมตีสามารถ query blocklist หรือแม้แต่สร้าง fake decision ได้ (แล้วแต่ role) ทีมของเราตั้ง Cron job ที่ rotate key ทุก 90 วัน โดยใช้ cscli bouncers add newname && cscli bouncers delete oldname พร้อมอัปเดต config ของ Bouncer แต่ละตัว

คำถามที่พบบ่อย

CrowdSec ต่างจาก Fail2Ban อย่างไร?

CrowdSec เขียนด้วย Go ทำงานเร็วกว่า Fail2Ban 5-10 เท่า มี Community Threat Intelligence ในตัว มีสถาปัตยกรรมแยก Detection กับ Blocking และรองรับ Bouncers หลากหลาย (nftables, Nginx, Cloudflare, HAProxy) ในขณะที่ Fail2Ban ทำงานได้เฉพาะ iptables/nftables local เท่านั้น

CrowdSec ฟรีหรือไม่และมีค่าใช้จ่ายอะไรบ้าง?

Security Engine, Bouncers, Hub Collections และ Community Blocklist ทั้งหมดฟรีภายใต้ MIT License Console ก็ใช้ได้ฟรีสำหรับ 3 เครื่องแรก ส่วนที่มีค่าใช้จ่ายคือ Premium Blocklists พิเศษ (เช่น TOR exit, VPN, botnet IPs) และ Enterprise support สำหรับองค์กรที่ต้องการ SLA

CrowdSec ปลอดภัยหรือไม่ในการแชร์ข้อมูลกับชุมชน?

ปลอดภัยครับ เพราะ CrowdSec แชร์เพียง IP ต้นทาง, ประเภทของ scenario ที่ trigger และเวลาเท่านั้น ไม่มีการส่ง log content, hostname, username หรือข้อมูลระบุตัวตนใดๆ นโยบายความเป็นส่วนตัวสอดคล้องกับ GDPR และสามารถ opt-out ได้ทุกเมื่อ

CrowdSec ใช้ทรัพยากรเครื่องเท่าไหร่?

บนเซิร์ฟเวอร์ทั่วไปที่รับ 1,000-5,000 request/วินาที CrowdSec ใช้ RAM ประมาณ 80-150 MB และ CPU น้อยกว่า 5% เทียบกับ Fail2Ban ที่ใช้ RAM 200-400 MB และ CPU 30-45% ในโหลดเดียวกัน ทำให้เหมาะกับทั้ง VPS เล็กและ Production cluster

CrowdSec ทำงานกับ Kubernetes ได้หรือไม่?

ได้ครับ CrowdSec มี Helm chart อย่างเป็นทางการ สามารถ deploy เป็น DaemonSet เพื่ออ่าน pod logs และ Bouncer สำหรับ Nginx Ingress Controller, Traefik, หรือ Istio ในสถาปัตยกรรมนี้ Agent ในแต่ละ node จะส่ง Decision ไปยัง LAPI ที่รันเป็น central service