Cấu hình ModSecurity và OWASP CRS cho shared hosting mà không chặn nhầm

Để cấu hình ModSecurity với OWASP Core Rule Set (CRS) trên shared hosting mà không chặn nhầm, hãy giữ paranoia level 1, lấy ngưỡng inbound mặc định là 5 làm đích, bật dần cho từng website, và xử lý chặn nhầm bằng ngoại lệ hẹp chỉ cho một website, một URL và một tham số thay vì tắt luật cho cả server. Đồng thời kiểm tra phiên bản: CRS 3.3.x đã hết vòng đời, còn các bản CRS 4 hiện hành và cả hai engine ModSecurity vẫn đang được duy trì.

Bài này đi cùng với hướng dẫn WAF cho WordPress, nơi so sánh WAF đám mây, plugin và WAF trên server. Ở đây chúng tôi tập trung vào điều quan trọng khi một tường lửa bảo vệ hàng chục, hàng trăm website không liên quan đến nhau.

Phiên bản ModSecurity và CRS nào đang hiện hành?

Bức tranh thay đổi từ 2024: Trustwave ngừng hỗ trợ ModSecurity từ 1/7/2024 và dự án chuyển sang OWASP, nơi cả hai dòng engine tiếp tục trong kho mã ModSecurity.

Thành phần	Bản mới nhất (10/2026)	Tình trạng
ModSecurity v2 (module Apache)	2.9.15, 29/9/2026	OWASP duy trì
ModSecurity v3 (libmodsecurity)	3.0.17, 29/9/2026	OWASP duy trì; dùng với nginx qua ModSecurity-nginx connector
Coraza (Go)	Xem Coraza	CRS khuyên dùng cho triển khai CRS 4 mới
CRS 4	4.30.0, 2/10/2026	Bản phát hành CRS hiện hành
CRS 4 LTS	4.25.2, 2/10/2026	Dòng hỗ trợ dài hạn, đến quý 3/2027
CRS 3.3	3.3.10, 2/7/2026	Hết vòng đời, theo website CRS

Ghi chú về engine khi chuyển từ CRS 3 sang 4 của nhóm CRS đáng đọc trước khi chọn:

• ModSecurity v2 trên Apache là engine "trưởng thành nhất, nơi CRS từ trước đến nay được phát triển và kiểm thử". CRS 4 cần v2.9.x.
• ModSecurity v3 với nginx được hỗ trợ, nhưng connector nginx "từng có khoảng trống trong hỗ trợ SecLang", nên nhóm CRS khuyên kiểm thử kỹ. Apache đi với v3 không được hỗ trợ, còn hỗ trợ nginx đi với v2 đã bị gỡ bỏ.
• Coraza "phát triển nhanh hơn ModSecurity v3" và là "engine được khuyên dùng cho triển khai CRS 4 mới".

Bản phân phối của bạn đang cung cấp gì?

Nếu cài từ gói của Ubuntu hoặc Debian, bạn nhận CRS 3.3.x, không phải CRS 4:

Bản phát hành	Gói modsecurity-crs	Module ModSecurity cho nginx
Ubuntu 22.04	3.3.2	Không có
Ubuntu 24.04	3.3.5	Có
Ubuntu 26.04	3.3.8	Có
Debian 12	3.3.4 (có cập nhật bảo mật)	Có
Debian 13	3.3.7 (có cập nhật bảo mật)	Có

Nguồn: Launchpad và Debian sources. Đội bảo mật của bản phân phối có vá lỗi vào gói, nhưng bạn không có tính năng mới của CRS 4 lẫn thời gian hỗ trợ từ upstream. Nếu tự duy trì WAF trong nhiều năm, hãy lên kế hoạch chuyển sang CRS 4.

CRS quyết định chặn thế nào: anomaly score

CRS không chặn ngay khi một luật khớp. Mỗi luật khớp cộng điểm vào anomaly score, và request chỉ bị chặn khi tổng điểm chạm ngưỡng. Theo tài liệu CRS về anomaly scoring:

Mức độ	Điểm
CRITICAL	5
ERROR	4
WARNING	3
NOTICE	2

Ngưỡng inbound mặc định là 5, nên một lần khớp mức critical (ví dụ một SQL injection rõ ràng) là đủ chặn request. Ngưỡng outbound là 4. Nâng ngưỡng làm CRS kém nhạy hơn, và tài liệu cảnh báo giữ ngưỡng cao sẽ để lọt nhiều tấn công, nên giá trị cao chỉ dùng tạm thời trong lúc tinh chỉnh.

Điều này quan trọng với chặn nhầm: một luật NOTICE ồn ào không tự chặn được request. Khi request hợp lệ bị chặn, thường là do một luật critical hoặc vài cảnh báo cộng dồn, và audit log cho bạn biết đó là luật nào.

Paranoia level: bắt đầu ở mức 1

CRS chia luật thành bốn paranoia level. Mức 1 là "bảo mật nền tảng, ít phải tinh chỉnh chặn nhầm". Mức 2 hợp với website xử lý dữ liệu người dùng thật, như shop. Mức 3 và 4 dành cho mục tiêu giá trị cao và đi kèm rất nhiều chặn nhầm.

Trên shared hosting, hãy giữ server ở paranoia level 1. Bạn không kiểm soát code của các website mình host, và mỗi mức tăng thêm nhân khối lượng tinh chỉnh lên cho tất cả. CRS còn có "executing paranoia level": luật ở mức cao hơn vẫn chạy và ghi log nhưng không tính vào quyết định chặn, giúp bạn xem PL2 sẽ bắt được gì trước khi bật thật.

Triển khai trên server dùng chung

Có hai trường phái:

1. Chỉ ghi log trước. Đặt engine ở DetectionOnly cho một website, thu vài ngày traffic, sửa các chỗ chặn nhầm, rồi chuyển sang chặn. Dễ hiểu và an toàn cho khách.
2. Chặn ngay với ngưỡng rất cao. Tài liệu CRS khuyên với triển khai mới nên bắt đầu ở chế độ chặn với ngưỡng anomaly rất cao, thậm chí tới 10000, rồi hạ dần. Ưu điểm là cơ chế chặn hoạt động ngay từ ngày đầu.

Trên server dùng chung, cách thứ nhất thường dễ giải thích với khách hơn, vì chế độ ghi log theo website không bao giờ làm hỏng gì. Dù chọn cách nào, hãy làm theo từng website, không bật cho cả server cùng lúc, và bắt đầu từ những website bạn hiểu rõ.

Sửa chặn nhầm mà không làm yếu mọi website

Đọc audit log trước

Mọi request bị chặn hoặc bị ghi lại đều nằm trong audit log của ModSecurity, kèm ID các luật đã khớp. Với audit log dạng JSON (SecAuditLogFormat JSON trên v3), bạn liệt kê nhanh host, URI và luật:

jq -r '.transaction | [.request.headers.Host // .request.headers.host, .request.uri,
  (.messages | map(.details.ruleId) | join(","))] | @tsv' /var/log/modsec_audit.log | sort | uniq -c | sort -rn | head

Sửa đường dẫn theo hệ thống của bạn. Tìm quy luật: cùng một luật, cùng URL, cùng website lặp đi lặp lại là ứng viên chặn nhầm. Một luật khớp với URL ngẫu nhiên từ nhiều IP nhiều khả năng là tấn công thật.

Chọn ngoại lệ hẹp nhất

Tài liệu CRS về chặn nhầm và tinh chỉnh mô tả hai nhóm ngoại lệ:

Loại	Directive	Áp dụng	Đặt ở đâu
Lúc nạp cấu hình	SecRuleRemoveById, SecRuleRemoveByTag, SecRuleUpdateTargetById	Mọi request trong phạm vi	Sau khi include CRS
Lúc chạy	ctl:ruleRemoveById, ctl:ruleRemoveTargetById trong một SecRule	Chỉ request khớp điều kiện của bạn	Trước khi include CRS

Cách sửa hẹp nhất là loại một tham số khỏi một luật trên một website và đường dẫn. Ví dụ, page builder trên shop.example.com lưu HTML trong trường content và kích hoạt luật SQL injection 942100:

# Đặt trước luật CRS. Chỉ host này, chỉ URL này, chỉ trường này.
SecRule REQUEST_HEADERS:Host "@streq shop.example.com" \
    "id:10001,phase:1,pass,nolog,chain"
    SecRule REQUEST_FILENAME "@endsWith /wp-admin/post.php" \
        "t:none,ctl:ruleRemoveTargetById=942100;ARGS:content"

Luật 942100 vẫn bảo vệ mọi trường khác trên website đó, và mọi website khác trên server. So với SecRuleRemoveById 942100 ở cấp server, thứ gỡ bỏ phát hiện SQL injection cho mọi khách cùng lúc.

Tài liệu CRS cũng khuyên: đừng sửa trực tiếp file luật của CRS (bản cập nhật sẽ ghi đè), tránh loại trừ theo tag rộng như language-multi vốn bao trùm hàng trăm luật, và đừng khớp theo nội dung thông báo của luật.

Dùng gói ngoại lệ cho ứng dụng

CRS có sẵn gói ngoại lệ cho các ứng dụng phổ biến, gồm WordPress, Drupal, Nextcloud, phpBB, phpMyAdmin, DokuWiki, XenForo và cPanel. Ở CRS 3.3 bạn bật bằng biến như tx.crs_exclusions_wordpress=1; ở CRS 4 chúng được tách thành plugin riêng. Trên shared hosting, chỉ bật mỗi gói cho đúng các host chạy ứng dụng đó, không bật toàn server, và coi nó là điểm xuất phát: plugin và page builder vẫn có thể kích hoạt luật.

Giữ WAF nhẹ

• Bỏ qua file tĩnh. Ảnh, CSS, JavaScript không cần kiểm tra và chiếm phần lớn số request.
• Tắt kiểm tra nội dung response trừ khi cần phát hiện rò rỉ dữ liệu. Nó tốn RAM và CPU trên mọi trang.
• Chỉ ghi audit log cho sự kiện liên quan (request bị chặn và lỗi server), và xoay vòng log.
• Giữ paranoia level 1 cho server, chỉ nâng cho website cụ thể cần thiết.

ZoPanel xử lý ModSecurity và CRS thế nào?

ZoPanel cài ModSecurity v3 với connector nginx và gói OWASP CRS của bản phân phối, từ Security → Web application firewall. Theo tài liệu công cụ website và tài liệu bảo mật:

• Tường lửa tắt với mọi website cho đến khi được bật, và bộ luật chỉ được nạp khi có ít nhất một website dùng, tốn khoảng 25 MB RAM mỗi worker nginx.
• Mỗi website có ba chế độ trong tab Tools: On (block attacks), Detect only (log) và Off. Apply to all websites đặt một chế độ cho mọi website.
• Bảng sự kiện hiện thời gian, IP, request và lý do cho từng website. Nút Allow this trên một sự kiện thêm ID luật đã khớp vào Allowed rules của riêng website đó, nên ngoại lệ không ảnh hưởng khách khác.
• File tĩnh không đi qua tường lửa.
• Website tạo theo ứng dụng đã biết, như WordPress, được áp gói ngoại lệ CRS của ứng dụng đó, khớp theo tên host.

Giới hạn cần nói thẳng: vì dùng gói của bản phân phối, bộ luật là CRS 3.3.x (ví dụ 3.3.5 trên Ubuntu 24.04), không phải CRS 4. Allow this gỡ một luật cho cả website chứ không phải cho một tham số, thô hơn ngoại lệ lúc chạy ở trên. Và Ubuntu 22.04 không có module ModSecurity cho nginx, nên không dùng được WAF ở đó. Ai cần tinh chỉnh tới từng tham số hoặc cần CRS 4 ngay bây giờ sẽ có nhiều quyền kiểm soát hơn với hệ thống tự duy trì hoặc dịch vụ WAF chuyên dụng. Dù thế nào, WAF chỉ lọc request: nó không thay thế cách ly tài khoản hay kế hoạch dọn website bị hack.

Kết luận

Cấu hình ModSecurity với OWASP CRS chạy tốt trên shared hosting khi bạn coi nó là triển khai theo từng website chứ không phải một công tắc cho cả server: paranoia level 1, ngưỡng mặc định làm đích, ghi log hoặc chặn với ngưỡng cao trước, và ngoại lệ chỉ cho một website, một đường dẫn, một tham số. Kiểm tra cả phiên bản, vì gói CRS 3.3 mà phần lớn bản phân phối cung cấp đã hết vòng đời ở upstream.

Nếu bạn muốn có chế độ WAF theo website và ngoại lệ một cú nhấp mà không phải viết SecLang, hãy thử trên gói Free của ZoPanel (3 tài khoản hosting, 10 website, không giới hạn thời gian) với Ubuntu 24.04, 26.04 hoặc Debian. Chi tiết các lớp bảo mật có ở trang tính năng bảo mật.

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

ModSecurity và OWASP CRS khác nhau thế nào?

ModSecurity là engine: nó kiểm tra request HTTP và chạy các luật viết bằng ngôn ngữ luật của nó. OWASP Core Rule Set là bộ luật phát hiện tấn công tổng quát cho engine đó, bao gồm SQL injection, XSS, chạy mã từ xa, máy quét lỗ hổng và nhiều loại khác. Bạn cần cả hai, hoặc một engine tương thích như Coraza.

Nên dùng ModSecurity v2 hay v3?

Tuỳ web server. Trên Apache, ModSecurity v2 là lựa chọn trưởng thành nhất và được CRS 4 hỗ trợ đầy đủ. Trên nginx, v3 với connector nginx là con đường được hỗ trợ. Với triển khai CRS 4 hoàn toàn mới, dự án CRS khuyên dùng Coraza.

CRS 3.3 còn được hỗ trợ không?

Không. Website CRS ghi rõ CRS 3.3.x đã hết vòng đời và khuyên chuyển đổi. Ubuntu và Debian vẫn phát hành gói 3.3.x và vá qua quy trình bảo mật riêng, nên hãy kiểm tra bản phân phối của bạn cập nhật thế nào.

Làm sao để ModSecurity không chặn một request hợp lệ?

Tìm ID luật trong audit log, rồi thêm ngoại lệ hẹp nhất đủ sửa lỗi: loại một tham số khỏi một luật cho một URL và host, dùng ctl:ruleRemoveTargetById đặt trước luật CRS. Tránh gỡ cả luật cho toàn server, và đừng bao giờ sửa trực tiếp file của CRS.

ModSecurity có làm website chậm không?

Nó tốn thêm một ít CPU cho mỗi request được kiểm tra và RAM cho mỗi worker web server. Bỏ qua file tĩnh, tắt kiểm tra response, giữ paranoia level 1 và phục vụ trang từ cache giúp chi phí này nhỏ so với thời gian PHP dựng một trang.