Ngăn chặn DDoS Layer 7: Hướng dẫn cấu hình ModSecurity WAF với Nginx Reverse Proxy

Server báo tải CPU chạm đỉnh 100%, RAM cạn kiệt, worker pool của Nginx đỏ rực và API liên tục báo timeout. Bạn hoảng hốt mở biểu đồ traffic và nhận ra băng thông mạng vẫn ở mức rất thấp (chỉ vài Mbps). Đáng sợ hơn, hệ thống đang hứng chịu hàng vạn request HTTP trông như thật, mang đầy đủ User-Agent và Cookie hợp lệ, nhắm thẳng vào các endpoint tốn tài nguyên nhất.

Chào mừng bạn đến với cơn ác mộng mang tên DDoS Layer 7 (Application Layer), nơi kẻ tấn công không dùng sức mạnh băng thông mà dùng kỹ thuật để vắt kiệt khả năng xử lý của backend.

Để giải quyết bài toán này, việc cấu hình ModSecurity WAF với Nginx Reverse Proxy từng là giải pháp quen thuộc của mọi SysAdmin. Tuy nhiên, mang những kiến thức compile (biên dịch) thủ công của 5 năm trước áp dụng vào hiện tại có thể khiến hệ thống của bạn sập nhanh hơn cả bị tấn công. Vậy làm thế nào để tích hợp một Tường lửa ứng dụng web (WAF) thế hệ mới, tối ưu hiệu năng và không bị rò rỉ RAM? Hãy cùng bóc tách kiến trúc phòng thủ thực chiến ngay dưới đây.

Điểm mù của firewall truyền thống: Khi API kiệt sức vì những request như thật

Nhiều developer vẫn tin rằng chỉ cần cấu hình Iptables, UFW hay AWS Security Groups là đủ an toàn. Thực tế phũ phàng là các giải pháp tường lửa mạng (Layer 3/4) này làm rất tốt nhiệm vụ định tuyến, chặn port, chặn IP, nhưng lại mất tác dụng hoàn toàn trước nội dung của giao thức HTTP/HTTPS.

Kẻ tấn công biết rõ điểm yếu này và triển khai các đòn đánh cực kỳ hiểm hóc:

• HTTP Flood (GET/POST Flood): Kẻ tấn công hoàn thành bắt tay 3 bước (3-way handshake) hợp lệ qua cổng 443, sau đó gửi hàng loạt request vào các API nặng logic (như /api/search hay /login). Tường lửa L3/4 thấy kết nối TCP hợp lệ nên mặc nhiên cho qua, đẩy toàn bộ gánh nặng về phía Nginx và Database.
• Slowloris (Kẻ bóp nghẹt thầm lặng): Gửi các phần header cực kỳ chậm (nhỏ giọt từng byte), cố tình giữ cho socket kết nối luôn mở. Chỉ cần vài trăm Kilobyte băng thông, kỹ thuật này vắt kiệt hồ chứa kết nối (Connection Pool) của Nginx, khiến người dùng thật không thể truy cập vì máy chủ không còn luồng để phục vụ.
• Automated Scanners (Bot rà soát lỗi tự động): Các công cụ như Nikto, sqlmap gửi hàng loạt payload chứa mã độc (SQLi, XSS, Path Traversal) ẩn trong query string hoặc body request. Vì được bọc trong lớp mã hóa TLS, firewall mạng hoàn toàn không thể phân tích được nội dung bên trong.

Hậu quả? Máy chủ của bạn phải tự mình giải mã SSL/TLS và vắt kiệt CPU xử lý logic ứng dụng cho hàng vạn request rác, dẫn đến tê liệt.

Sự tiến hóa của WAF: Tạm biệt ModSecurity v3, đón chào Coraza WAF

Nếu bạn đọc các tài liệu cũ, 90% sẽ hướng dẫn bạn tải mã nguồn C++ của libmodsecurity3, cài đặt hàng tá thư viện và chạy lệnh make -j để biên dịch thủ công.

Đừng làm vậy trên Production ở thời điểm hiện tại! Việc compile ModSecurity v3 thủ công mang lại quá nhiều rủi ro:

1. Rủi ro Out-of-Memory (OOM): Tiến trình compile tốn rất nhiều RAM. VPS cấu hình thấp (1-2GB RAM) sẽ treo cứng hoặc bị hệ điều hành tắt ép buộc ngay lập tức.
2. Memory Leak (Rò rỉ RAM): Kiến trúc ModSecurity v3 kết hợp với Nginx Connector thường xuyên bị báo cáo lỗi ngốn CPU và rò rỉ bộ nhớ mỗi khi reload Nginx do quản lý vùng nhớ C++ không tối ưu.
3. Khó bảo trì: Mỗi lần Nginx có bản cập nhật mới, bạn lại phải biên dịch lại module từ đầu để tránh lỗi không tương thích.

Kỷ nguyên mới: OWASP Coraza WAF – động cơ hiện đại cho luật ModSecurity

Cộng đồng DevSecOps hiện nay đã chuyển dịch sang các giải pháp an toàn bộ nhớ (memory-safe). Tương lai của WAF mã nguồn mở chính là OWASP Coraza WAF.

Được viết bằng Golang, Coraza khắc phục hoàn toàn điểm yếu rò rỉ RAM của ModSecurity cũ. Điểm tuyệt vời nhất là Coraza hiểu 100% ngôn ngữ luật SecLang của ModSecurity. Điều này có nghĩa là khi chúng ta nói về việc cấu hình ModSecurity WAF với Nginx Reverse Proxy trong kỷ nguyên mới, bản chất là chúng ta đang sử dụng engine Coraza tốc độ cao để chạy hệ sinh thái luật (rules) của ModSecurity (như OWASP CRS).

Chiến lược phòng thủ đa tầng (Defense in Depth)

Dù bạn dùng engine Coraza hay ModSecurity truyền thống, nguyên tắc cốt lõi không thay đổi: WAF không bao giờ được đứng một mình chống lại DDoS.

Việc bắt WAF chạy hàng trăm biểu thức chính quy (Regex) để phân tích từng request là một tác vụ cực kỳ tốn CPU. Nếu bị tấn công HTTP Flood, chính WAF sẽ làm sập máy chủ trước khi bảo vệ được nó. Do đó, hạ tầng máy chủ của bạn cần đáp ứng được khối lượng tính toán này. Nếu bạn chưa có một hệ thống đủ mạnh hoặc đang phân vân nâng cấp, hãy tham khảo ngay cẩm nang hướng dẫn chi tiết về 5 thông số quan trọng khi chọn mua VPS để đảm bảo WAF hoạt động mượt mà không bị Out-of-Memory.

Sự phối hợp hoàn hảo ở đây là:

1. Nginx (Tiền tuyến – Cản bước thể tích): Dùng Rate Limit (limit_req) và Connection Limit (limit_conn) để chặn đứng các request flood dồn dập. Chi phí CPU để Nginx drop một gói tin vượt ngưỡng là gần như bằng không.
2. WAF (Hậu phương – Soi chiếu ngữ nghĩa): Chỉ nhận phần lưu lượng đã được Nginx làm sạch tần suất. Lúc này WAF mới thong thả phân tích payload để chặn SQLi, XSS, RCE.

Bốn bước cấu hình ModSecurity WAF với Nginx Reverse Proxy (thực chiến)

Trong hướng dẫn này, chúng ta sẽ thực hiện trên Ubuntu LTS (22.04 / 24.04). Chúng tôi sẽ cung cấp 2 lựa chọn cài đặt Engine WAF để bạn linh hoạt quyết định.

Bước 1: Cài đặt WAF Engine vào Nginx (không compile thủ công)

Thay vì đợi 20 phút để compile, hãy sử dụng các bản dựng sẵn (pre-built).

▶ Lựa chọn 1 (Khuyên dùng – Xu hướng 2026): Cài đặt Coraza Nginx Module

Coraza cung cấp module động (.so) build sẵn cho Nginx, cài đặt rất nhanh chóng.

Cài đặt Nginx:

sudo apt update && sudo apt install nginx -y

Tải Coraza Nginx Module build sẵn (Kiểm tra version mới nhất trên Github Coraza):

wget https://github.com/corazawaf/coraza-nginx/releases/download/v1.0.2/coraza-nginx-1.0.2-linux-amd64.tar.gz
tar -xvf coraza-nginx-1.0.2-linux-amd64.tar.gz

Chuyển file .so vào thư mục module của Nginx:

sudo mkdir -p /etc/nginx/modules
sudo mv mod_coraza_nginx.so /etc/nginx/modules/

Khởi tạo thư mục cấu hình:

sudo mkdir -p /etc/nginx/modsec

▶ Lựa chọn 2 (Dành cho hệ thống Legacy): Cài đặt ModSecurity v3 qua APT

Nếu quy định công ty bắt buộc dùng engine cũ, hãy tải bản đóng gói sẵn của Ubuntu thay vì compile.

Cài đặt Nginx và ModSecurity, sau đó cấu hình thư mục cơ bản:

sudo apt update
sudo apt install nginx libnginx-mod-http-modsecurity -y
sudo mkdir -p /etc/nginx/modsec
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Kích hoạt Module vào Nginx:

Mở file /etc/nginx/nginx.conf và thêm dòng nạp module ở ngay dòng đầu tiên:

(Với Coraza): load_module modules/mod_coraza_nginx.so;

(Với ModSec v3): load_module modules/ngx_http_modsecurity_module.so;

Bước 2: Tích hợp bộ não OWASP Core Rule Set (CRS 4.x)

Dù dùng engine nào, WAF cũng cần bộ luật CRS để biết thế nào là tấn công. Hãy tải phiên bản CRS 4.x (Long-Term Support) – bản này thông minh hơn và ít báo động giả (False Positive) hơn hẳn bản 3.x.

Tải và giải nén CRS 4.x LTS:

wget https://github.com/coreruleset/coreruleset/releases/download/v4.25.0/coreruleset-4.25.0.tar.gz
tar -zxvf coreruleset-4.25.0.tar.gz
sudo mv coreruleset-4.25.0 /etc/nginx/owasp-crs

Chuẩn bị file cấu hình gốc:

cd /etc/nginx/owasp-crs
sudo cp crs-setup.conf.example crs-setup.conf

Tạo một file Master Include (VD: /etc/nginx/modsec/main.conf) để nạp luật theo đúng thứ tự bắt buộc:

# Nếu dùng ModSec v3, thêm dòng: Include /etc/nginx/modsec/modsecurity.conf ở đây
Include /etc/nginx/owasp-crs/crs-setup.conf
Include /etc/nginx/owasp-crs/rules/*.conf

Bước 3: Hardening Nginx – lá chắn thép cắt đứt Slowloris và HTTP Flood

Đây là bước tối quan trọng để bảo vệ CPU của máy chủ. Chúng ta chèn các rules giới hạn trực tiếp vào file cấu hình nginx.conf (trong block http hoặc server):

http {
    # 1. Giới hạn kết nối (Bóp nghẹt Slowloris) - Tối đa 30 kết nối/IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn_status 429;

    # 2. Giới hạn tốc độ request (Cắt cơn HTTP Flood) - 10 request/giây
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req_status 429;

    # 3. Ép Timeout khắt khe để ngắt connection không hoạt động
    client_header_timeout 10s;
    client_body_timeout 10s;

    server {
        listen 80;
        server_name api.yourdomain.com;

        # Áp dụng giới hạn mạng
        limit_conn conn_limit 30;
        limit_req zone=req_limit burst=20 nodelay;

        # Kích hoạt WAF cho Virtual Host (Áp dụng cho Coraza/ModSecurity)
        coraza_on on; # Dùng modsecurity on; nếu bạn chọn cách 2
        coraza_rules_file /etc/nginx/modsec/main.conf; # Dùng modsecurity_rules_file nếu chọn cách 2

        location / {
            proxy_pass http://localhost:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        # Bỏ qua WAF cho file tĩnh để tiết kiệm CPU tuyệt đối
        location ~* \.(jpg|jpeg|png|gif|css|js|ico|svg)$ {
            coraza_on off; # Hoặc modsecurity off;
            proxy_pass http://localhost:8080;
        }
    }
}

Bước 4: Kích hoạt CRS DoS Protection Plugin (vũ khí tối thượng)

Điểm nâng cấp đáng giá nhất của CRS 4.x là tính năng chống DoS đã được tách thành một Plugin độc lập. Thay vì xử lý rườm rà, nó đếm các đợt request đột biến (burst) và ngắt kết nối cực sớm ở Phase 1.

1. Bật collection theo dõi IP trong /etc/nginx/owasp-crs/crs-setup.conf bằng cách bỏ comment Rule id:900130.
2. Tải DoS plugin từ kho Github của Coreruleset và đưa 3 file cấu hình (.conf) vào thư mục plugins/ của CRS.
3. Tinh chỉnh ngưỡng trong dos-protection-config.conf:
   • TX:DOS_COUNTER_THRESHOLD: Số lượng request hợp lệ trước khi bị tính là 1 burst (VD: 100 requests).
   • TX:DOS_BURST_TIME_SLICE: Khoảng thời gian đo lường burst (VD: 60 giây).
   • TX:DOS_BLOCK_TIMEOUT: Thời gian đưa IP vi phạm vào danh sách chặn (VD: 600 giây).

Kết quả? Khi một IP gửi lượng lớn request vào API của bạn, WAF sẽ gán cờ IP:DOS_BLOCK và hủy thẳng gói tin ngay khi vừa đọc xong Header, bảo vệ an toàn toàn bộ hệ thống backend.

Best practices: Đưa WAF lên Production không làm sập server

Sai lầm nghiêm trọng nhất của các SysAdmin là bật WAF ở chế độ chặn cứng (Blocking) ngay ngày đầu tiên lên Production. Hậu quả là WAF chặn luôn cả request hợp lệ của khách hàng (False Positives), tính năng upload ảnh lỗi, API thanh toán timeout.

Để triển khai an toàn, hãy tuân thủ quy trình cuốn chiếu 3 giai đoạn:

1. Giai đoạn 1 – Bắt đầu với DetectionOnly: Trong cấu hình engine, hãy thiết lập SecRuleEngine DetectionOnly. Ở trạng thái này, WAF sẽ quét, chấm điểm và ghi log mọi bất thường nhưng không hủy request của user. Chạy giám sát từ 1-2 tuần để thu thập dữ liệu lưu lượng thật.
2. Giai đoạn 2 – Tuning False Positives (Tinh chỉnh cảnh báo giả): Mở error.log. Nếu thấy một endpoint API thỉnh thoảng truyền chuỗi JSON phức tạp bị dính nhầm cảnh báo SQL Injection, hãy viết quy tắc loại trừ (Rule Exclusions) để tắt riêng Rule ID đó cho endpoint kia. Tuyệt đối không tắt WAF trên diện rộng.
3. Giai đoạn 3 – Bật SecRuleEngine On: Khi log hệ thống đã không còn báo động giả, lúc này bạn mới chính thức kích hoạt chế độ chặn cứng.

Đưa phòng thủ lên tầm cao mới: Kết hợp CrowdSec (kẻ thay thế Fail2Ban)

Trước đây, khi thiết lập tường lửa ứng dụng, chúng ta thường gắn kèm Fail2Ban để tự động đọc file log. Bạn có thể xem lại bài viết hướng dẫn cấu hình bảo mật VPS với Fail2Ban giúp chống Brute Force toàn diện khi dùng Nginx Reverse Proxy để hiểu rõ cơ chế cũ: nếu IP nào bị WAF cảnh báo quá nhiều lần, Fail2Ban sẽ đẩy IP đó xuống Iptables (Layer 3) để chặn đứng từ card mạng.

Tuy nhiên, Fail2Ban đã trở nên cũ kỹ, tìm kiếm tuyến tính chậm chạp và tiêu tốn rất nhiều tài nguyên khi file log phình to. Ngày nay, giới DevSecOps sử dụng CrowdSec làm giải pháp thay thế hoàn hảo.

• Hiệu năng vượt trội: CrowdSec được viết bằng Golang, đọc log siêu tốc và tiêu tốn cực ít RAM/CPU của VPS.
• Mạng lưới tình báo toàn cầu (CTI): Đây là điểm giá trị nhất! Nếu IP 1.2.3.4 bị CrowdSec trên máy chủ của một doanh nghiệp ở Mỹ phát hiện đang rà soát lỗ hổng, IP đó sẽ lập tức bị đưa vào danh sách đen toàn cầu. Máy chủ của bạn ở Việt Nam sẽ tự động đồng bộ danh sách này và chặn ngay IP 1.2.3.4 từ cửa mạng (Layer 3) trước cả khi nó kịp chạm đến Nginx.
• Triển khai nhanh chóng: Chỉ cần cài đặt CrowdSec Agent và Nginx Bouncer, hệ thống sẽ tự động liên kết với log của WAF và thiết lập lá chắn bảo vệ.

Khi WAF Layer 7 của bạn (Coraza/ModSecurity) làm nhiệm vụ phát hiện kẻ xấu, CrowdSec sẽ đóng vai trò giám sát: thu thập IP, báo cáo lên mạng lưới toàn cầu và khóa vĩnh viễn IP đó ở mọi cổng kết nối.

Câu hỏi thường gặp (FAQ)

1. Có nên tiếp tục dùng ModSecurity v3 nữa không?

Hạn chế tối đa. Nên chuyển sang OWASP Coraza. ModSecurity v3 bằng C++ thường bị rò rỉ RAM (memory leak) và ngốn CPU khi reload Nginx. Chỉ giữ lại ModSec v3 nếu hệ thống legacy của bạn bắt buộc không thể thay đổi.

2. Coraza WAF có tiêu thụ nhiều RAM như ModSecurity cũ không?

Rất ít. Coraza được viết bằng Golang (memory-safe), cơ chế dọn rác (Garbage Collection) tối ưu, giải quyết triệt để vấn đề quá tải RAM và treo VPS của thế hệ cũ.

3. Bật WAF (Coraza/ModSecurity) có làm chậm API hay tăng Ping không?

Có, nhưng không đáng kể (chỉ tăng thêm khoảng 1-5ms). WAF bắt buộc phải đệm (buffer) request để quét Regex. Mẹo tối ưu: Luôn tắt WAF (coraza_on off;) đối với các file tĩnh (ảnh, CSS, JS) để giải phóng CPU.

4. Làm sao biết WAF đang chặn nhầm (False Positive) hay bị tấn công thật?

Kiểm tra error.log. Nếu 1 IP liên tục gửi ký tự lạ (<script>, ' OR 1=1) vào đủ mọi endpoint -> Bị tấn công. Nếu khách hàng báo lỗi ngay khi thao tác thanh toán, và log báo duy nhất 1 Rule ID chặn đoạn JSON tại API /checkout -> Chặn nhầm. Cần viết Rule Exclusion riêng cho API đó.

5. OWASP CRS có thường xuyên chặn nhầm chức năng Upload File hay gửi JSON API không?

Rất thường xuyên! CRS kiểm tra chặt chẽ kích thước body và các ký tự đặc biệt (base64, dấu ngoặc kép). Giải pháp: Chạy WAF ở chế độ DetectionOnly 1-2 tuần, kiểm tra kỹ luồng upload, sau đó viết luật loại trừ (Rule Remove) riêng cho tham số chứa file đính kèm trước khi bật Blocking.

Q6: Đã dùng Cloudflare (bản Free) rồi, có cần cài thêm Coraza WAF trên VPS không? TL;DR: Bắt buộc CÓ. Cloudflare Free là khiên chắn vòng ngoài, chủ yếu ngăn chặn DDoS mạng (Layer 3/4). Coraza kết hợp OWASP CRS trên VPS là lớp bảo vệ Layer 7 chuyên sâu, ngăn chặn mọi mã độc SQLi/XSS tinh vi vượt qua được hệ thống của Cloudflare.

Q7: VPS của tôi chỉ có 1GB RAM thì có chạy nổi Nginx + WAF không? TL;DR: Không nên. WAF cần RAM để đệm request body. Nếu gặp một đợt rà soát tự động liên tục, RAM 1GB sẽ cạn sạch và gây sập OOM (Out-Of-Memory). Khuyến nghị: Dùng VPS tối thiểu 2GB RAM và bắt buộc phải cấu hình thêm Swap (RAM ảo).

Kết luận

Việc bảo vệ ứng dụng Web hiện nay đã trở nên thông minh và tinh gọn hơn rất nhiều nhờ sự chuyển dịch sang các engine thế hệ mới như OWASP Coraza, CRS 4.x và các hệ thống CTI như CrowdSec. Bằng cách cấu hình ModSecurity WAF với Nginx Reverse Proxy theo chuẩn hiện đại (bỏ qua những bước compile thủ công rủi ro), bạn đã xây dựng được một kiến trúc Defense in Depth vững chắc: Nginx lọc kết nối, WAF phân tích mã độc, và CrowdSec ngăn chặn triệt để từ vòng ngoài.

Lưu ý quan trọng: Tường lửa ứng dụng web chỉ sinh ra để giải quyết bài toán DDoS Layer 7. Nếu VPS của bạn bị quá tải bởi những cuộc tấn công Layer 3/Layer 4 (UDP/TCP Flood) lên đến hàng chục Gbps làm nghẽn vật lý đường truyền, bạn bắt buộc phải đưa hệ thống nấp sau một lớp Cloud CDN/Anti-DDoS chuyên dụng.

Hệ thống của bạn đang sử dụng Nginx Rate Limit tiêu chuẩn hay đã trang bị lớp WAF? Bạn đã từng gặp tình huống khó khăn khi WAF chặn nhầm tính năng của khách hàng chưa? Hãy để lại bình luận để chúng ta cùng thảo luận cách tối ưu rule hiệu quả nhất nhé!

Tài liệu tham khảo

• GitHub – coreruleset/coreruleset: OWASP CRS (Official Repository) · GitHub
• False Positives and Tuning :: CRS Documentation
• Anomaly Scoring :: CRS Documentation
• Paranoia Levels :: CRS Documentation
• GitHub – owasp-modsecurity/ModSecurity: ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis. · GitHub
• GitHub – owasp-modsecurity/ModSecurity-nginx: ModSecurity v3 Nginx Connector · GitHub