Vào lúc 2:14 sáng thứ Ba tuần trước, PagerDuty liên tục báo động điện thoại của tôi với các cảnh báo bộ nhớ trên cả ba node production. RAM hệ thống đã tăng vọt qua mức 92%, và các worker process của Nginx rơi vào tình trạng quá tải (thrashing) trước lượng request lên tới khoảng 4.000 lượt mỗi giây. Khi kiểm tra kỹ /var/log/auth.log và access log của Nginx, chúng tôi phát hiện một cuộc tấn công rà quét phối hợp dạng low-and-slow kinh điển.
Kẻ tấn công đang rải payload credential-stuffing vào route /api/v1/auth/login của chúng tôi, đồng thời dò quét dịch vụ SSH trên port 22. Thay vì dội lượng traffic khổng lồ từ một vài địa chỉ IP data center, kẻ tấn công luân chuyển qua khoảng 8.500 proxy dân cư (residential proxy). Mỗi IP chỉ gửi request đến endpoint của chúng tôi đúng một lần mỗi 5 phút—dễ dàng vượt qua các ngưỡng rate-limiting tiêu chuẩn mà không hề bị phát hiện.
So sánh phương pháp: Phòng thủ cục bộ và Threat Intelligence cộng tác
Khi các cuộc tấn công xuất phát từ hàng nghìn địa chỉ IP dân cư xoay vòng, các công cụ phòng thủ độc lập hoàn toàn bất lực. Việc so sánh giữa các công cụ phân tích log truyền thống với một hệ thống ngăn ngừa xâm nhập (IPS) cộng tác hiện đại sẽ làm sáng tỏ gốc rễ của vấn đề.
1. Công cụ theo dõi log cục bộ (ví dụ: Fail2Ban)
Các công cụ như Fail2Ban quét các file log cục bộ bằng regular expression (regex). Khi một IP đơn lẻ vượt quá ngưỡng thiết lập sẵn—chẳng hạn như 5 lần đăng nhập SSH thất bại trong 10 phút—nó sẽ ghi một rule tạm thời để drop kết nối vào iptables hoặc nftables. Cơ chế này xử lý rất hiệu quả các đợt quét ồn ào từ các script chạy trên từng máy chủ VPS đơn lẻ.
Tuy nhiên, các mạng botnet phân tán lại hoàn toàn qua mặt được logic này. Nếu kẻ tấn công điều phối 10.000 node sao cho mỗi node chỉ thử đăng nhập đúng một lần mỗi ngày, Fail2Ban sẽ không bao giờ chạm tới ngưỡng kích hoạt. Máy chủ của bạn phải hứng chịu đòn tấn công trong thế cô lập hoàn toàn. Nó không thể biết được rằng chính IP đó vừa tấn công 500 máy chủ khác chỉ vài phút trước đó.
2. Hệ thống SIEM doanh nghiệp tập trung / Cloud WAF
Các nhà cung cấp giải pháp edge trên đám mây (như Cloudflare hay AWS WAF) cùng các hệ thống SIEM được quản lý duy trì nguồn cấp dữ liệu mối đe dọa (threat feed) toàn cầu khổng lồ. Chúng lọc sạch traffic HTTP từ trước khi đến máy chủ gốc của bạn. Nhưng giải pháp này cũng có sự đánh đổi: chi phí tính theo request tăng rất nhanh khi lượng truy cập đột biến, và các edge proxy không thể bảo vệ các dịch vụ TCP thuần túy như SSH, SFTP hay các socket listener tùy chỉnh chạy ở tầng kernel.
3. Phát hiện và xử lý dựa trên sự cộng tác (CrowdSec)
CrowdSec tách biệt bảo mật thành hai vai trò độc lập: phát hiện (Security Engine) và thực thi (Bouncer). Daemon lõi phân tích log tại chỗ bằng goroutine và các scenario viết bằng YAML khai báo. Khi máy chủ của bạn phát hiện một kẻ tấn công, nó sẽ chặn IP đó ở mức cục bộ, đồng thời gửi một cảnh báo ẩn danh về engine đồng thuận trung tâm của CrowdSec.
Engine trung tâm này xử lý tín hiệu từ hàng chục nghìn node đang hoạt động trên hơn 180 quốc gia. Nó xác thực các báo cáo thông qua thuật toán đồng thuận, loại bỏ các cảnh báo giả (false positive) và đẩy blocklist đã được chọn lọc trở lại cho tất cả các node tham gia. Máy chủ Linux của bạn sẽ drop các gói tin độc hại từ trước khi kẻ tấn công kịp chạm vào hệ thống, đơn giản là vì một máy chủ khác trong mạng lưới đã bắt được chúng từ trước.
Ưu và nhược điểm: Đánh giá CrowdSec cho môi trường Production
Mọi lựa chọn kiến trúc đều đi kèm sự đánh đổi. Dưới đây là phân tích ưu nhược điểm thực tế của CrowdSec trong môi trường production.
Ưu điểm
- Threat Intelligence từ cộng đồng: Bạn được bảo vệ chủ động trước hơn 50.000 IP độc hại đang hoạt động mà không cần tự duy trì danh sách chặn thủ công hay tốn chi phí mua các gói threat intelligence thương mại đắt đỏ.
- Kiến trúc tách rời (Decoupled): Việc phân tích log hoạt động độc lập với cơ chế thực thi tường lửa. Bạn có thể phân tích log trên máy chủ ứng dụng nhưng lại drop gói tin ngay tại router biên, hoặc hiển thị captcha tự động thông qua bouncer của Nginx hay Traefik.
- Chiếm dụng tài nguyên cực thấp: Được viết bằng Go, daemon CrowdSec thường chỉ chiếm khoảng 40–60 MB RAM ở trạng thái chờ và dùng dưới 1% CPU dưới mức tải vừa phải, nhẹ hơn rất nhiều so với các agent SIEM viết bằng Java hay script scraper viết bằng Python.
- Hub mở rộng linh hoạt: Các bộ parser và scenario do cộng đồng duy trì dành cho Nginx, SSH, Postfix, Docker và PostgreSQL có thể được cài đặt chỉ trong vài giây qua trình quản lý gói
cscli.
Nhược điểm
- Cần thiết lập nhiều thành phần: Bản thân engine chỉ làm nhiệm vụ phát hiện tấn công chứ không tự chặn kết nối. Bạn bắt buộc phải cài thêm bouncer xử lý tương ứng (như bouncer nftables) để drop gói tin. Nếu bỏ qua bước này, máy chủ vẫn sẽ không được bảo vệ.
- Yêu cầu kết nối mạng chiều đi (Outbound): Dù việc phân tích log cục bộ và blocklist đã lưu cache vẫn hoạt động tốt khi offline, việc cập nhật danh sách đồng thuận cộng đồng vẫn đòi hỏi quyền kết nối HTTPS ra ngoài (port 443) tới API trung tâm của CrowdSec.
Thiết lập khuyến nghị: Kiến trúc và mô hình mạng
Đối với một máy chủ bastion Linux hoặc server production đơn node có khả năng chống chịu cao, hãy triển khai ngăn xếp sau:
- CrowdSec Security Engine: Đọc journal của systemd, auth log của SSH và log của web server (Nginx/Caddy) để theo dõi các mẫu hành vi bất thường.
- Firewall Remediation Bouncer (nftables / iptables): Giao tiếp với Local API (LAPI) qua port 8080 và ghi các rule drop trực tiếp vào bộ lọc gói tin của Linux kernel.
- CrowdSec Hub Collections: Các profile phát hiện được đóng gói sẵn như
crowdsecurity/linux,crowdsecurity/sshdvàcrowdsecurity/nginx.
Hãy siết chặt các thông tin đăng nhập quản trị trước khi đưa các công cụ phát hiện xâm nhập mới ra các interface công khai. Mỗi khi khởi tạo node mới hoặc luân chuyển credential vận hành trong các sự cố, tôi luôn tạo mật khẩu root và mật khẩu service có độ hỗn loạn (entropy) cao bằng công cụ tạo mật khẩu trên trình duyệt tại toolcraft.app/vi/tools/security/password-generator. Công cụ này hoạt động hoàn toàn ở phía client và không gửi mật khẩu qua mạng. Khi quyền truy cập cơ bản đã được bảo mật an toàn, chúng ta có thể tiến hành cấu hình hệ thống phòng thủ tự động.
Hướng dẫn triển khai: Từng bước cài đặt trên Linux
Các bước triển khai dưới đây áp dụng cho hệ thống Ubuntu 22.04 / 24.04 và Debian 12.
Bước 1: Cài đặt Repository và Engine của CrowdSec
Thêm repository chính thức bằng script cài đặt tự động của CrowdSec, sau đó cài đặt daemon lõi:
# Tải về và đăng ký repository chính thức
curl -s https://install.crowdsec.net | sudo bash
# Cài đặt security engine CrowdSec
sudo apt-get update
sudo apt-get install -y crowdsec
Trong quá trình cài đặt, engine sẽ quét /var/log để tìm các dịch vụ đang chạy như OpenSSH hoặc Nginx. Nó sẽ tự động tạo đường dẫn thu thập log ban đầu trong file /etc/crowdsec/acquis.yaml.
Bước 2: Xác minh việc thu thập log và các Collection
Kiểm tra xem CrowdSec đã nhận diện những dịch vụ nào và xem danh sách các scenario phát hiện đã cài đặt:
# Kiểm tra các nguồn log đã nhận diện và thông lượng parser
sudo cscli metrics
# Xem lại các collection đang hoạt động
sudo cscli collections list
Nếu bạn đang chạy Nginx hoặc một reverse proxy khác, hãy cài đặt các collection scenario tương ứng trực tiếp từ CrowdSec Hub:
# Cài đặt các scenario bảo vệ Nginx và HTTP tiêu chuẩn
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/http-cve
# Tải lại CrowdSec để áp dụng các scenario mới
sudo systemctl reload crowdsec
Bước 3: Cài đặt Firewall Remediation Bouncer
Engine lõi chỉ có nhiệm vụ phát hiện tấn công. Bạn cần một thành phần xử lý để thực thi việc chặn. Trên các bản phân phối Linux hiện đại sử dụng nftables, hãy cài đặt gói bouncer tương ứng:
# Cài đặt firewall remediation bouncer
sudo apt-get install -y crowdsec-firewall-bouncer-nftables
Xác nhận rằng bouncer đã tự đăng ký với Local API (LAPI):
# Liệt kê các bouncer đã đăng ký
sudo cscli bouncers list
Kết quả đầu ra sẽ hiển thị crowdsec-firewall-bouncer-nftables kèm API key hợp lệ và trạng thái active.
Bước 4: Kiểm tra và theo dõi các quyết định (Decisions) đang có hiệu lực
CrowdSec sẽ tải danh sách blocklist đồng thuận cộng đồng ngay sau khi khởi động. Bạn có thể kiểm tra cơ sở dữ liệu quyết định cục bộ để xác nhận các lệnh cấm đang có hiệu lực:
# Xem các lệnh cấm đang có hiệu lực và các lượt chặn đồng thuận từ cộng đồng
sudo cscli decisions list
Để kiểm tra tính năng chặn cục bộ trong điều kiện thực tế, hãy giả lập một lệnh cấm thủ công tạm thời đối với một địa chỉ IP thử nghiệm theo chuẩn RFC 5737:
# Áp dụng lệnh cấm thử nghiệm 15 phút đối với một IP test
sudo cscli decisions add --ip 192.0.2.1 --duration 15m --reason "lệnh cấm thử nghiệm thủ công"
# Xác nhận rule đã được ghi nhận
sudo cscli decisions list --ip 192.0.2.1
# Xóa quyết định thử nghiệm
sudo cscli decisions delete --ip 192.0.2.1
Bước 5: Đăng ký với Central Console
Để có cái nhìn bao quát trên toàn bộ cụm máy chủ và giám sát các cuộc tấn công hướng vào từ một dashboard duy nhất, hãy liên kết node của bạn với CrowdSec Console (miễn phí cho các quản trị viên cá nhân):
# Đăng ký instance bằng token đăng ký console của bạn
sudo cscli console enroll <YOUR_ENROLLMENT_KEY>
# Khởi động lại dịch vụ để thiết lập đồng bộ
sudo systemctl restart crowdsec
Trở lại với cuộc gọi xử lý sự cố lúc 2 giờ sáng hôm ấy, CrowdSec đã giải quyết triệt để vấn đề chỉ trong chưa đầy hai mươi phút. Ngay khi bouncer nftables được kích hoạt, nó đã drop hơn 3.200 kết nối từ các IP dân cư độc hại ngay tại bộ lọc gói tin của Linux kernel. Mức tải CPU của worker Nginx giảm mạnh từ 98% xuống còn 4%, giải phóng bộ nhớ RAM và giúp lưu lượng truy cập hợp lệ của khách hàng được duy trì thông suốt.
