Nếu phải giải thích ngắn gọn nhất, tường lửa là người gác cổng. Nó không thay bạn sửa mã độc, cũng không thay bạn vá lỗ hổng ứng dụng. Việc của nó là đứng trước cửa và quyết định yêu cầu nào được vào tiếp hệ thống.

Đây là chỗ rất nhiều người hiểu sai. Họ thường xem tường lửa như một “lá chắn toàn năng”, trong khi về bản chất nó là bộ lọc truy cập. Nó đặc biệt hữu ích ở giai đoạn đầu của luồng truy cập: kiểm tra cổng nào đang mở, IP nào được phép đi vào, kết nối nào có dấu hiệu bất thường, và ở mức cao hơn thì yêu cầu web nào nên bị từ chối trước khi chạm sâu vào website.

Trong thực tế vận hành, tường lửa giúp giảm hai nhóm rủi ro lớn. Một là truy cập trái phép, ví dụ cố dò vào dịch vụ không nên mở ra ngoài hoặc cố gửi yêu cầu độc hại. Hai là gây quá tải bằng lượng kết nối rất lớn, thường thấy trong các đợt DoS hoặc DDoS. Nói cách khác, nó không thay mọi cơ chế bảo mật khác, nhưng gần như luôn là tuyến phòng thủ đầu tiên đáng có.

Moment quan trọng ở đây là: tường lửa không làm website của bạn “bất khả xâm phạm”. Nó chỉ khiến kẻ tấn công khó đi qua cổng hơn, và giúp hệ thống bớt lãng phí tài nguyên cho lưu lượng xấu.

Đây là phần đáng hiểu rõ nhất, vì chỉ cần nhầm chỗ này là bạn sẽ chọn sai công cụ. Nhìn đơn giản, ba nhóm này khác nhau ở mức độ thông tin mà chúng đọc được từ mỗi kết nối.

1. Tường lửa không trạng thái

Loại này chủ yếu lọc theo IP, port và quy tắc cố định. Nó khá giống một người bảo vệ chỉ đối chiếu danh sách: ai đến từ đâu, đi vào cổng nào, có nằm trong danh sách cho phép hay không. Ưu điểm là nhanh, gọn, ít tốn tài nguyên. Nhược điểm là nó không “nhìn sâu” vào ngữ cảnh của kết nối.

Điểm dễ hiểu sai là nhiều người mở port xong và nghĩ như vậy là đã đủ an toàn. Thực tế, mở đúng cổng chỉ mới giải quyết khả năng truy cập hợp lệ. Nó chưa đủ để tự phân biệt mọi hành vi tốt và xấu đi qua cổng đó.

2. Tường lửa có trạng thái

Loại này đi thêm một bước. Nó không chỉ thấy IP và port, mà còn theo dõi trạng thái kết nối: đang mở, đã thiết lập, có quá nhiều phiên đồng thời hay có dấu hiệu lạm dụng hay không. Nhờ vậy, nó có thể phản ứng thông minh hơn với các mẫu hành vi bất thường, chẳng hạn quá nhiều kết nối dồn dập từ cùng một nguồn.

Đổi lại, nó cần nhiều tài nguyên hơn. Đây là quy luật rất bình thường: càng đọc nhiều thông tin, càng phải xử lý nhiều hơn. Nhưng lợi ích là khả năng chặn lạm dụng tốt hơn nhiều so với kiểu lọc thô chỉ dựa trên quy tắc tĩnh.

3. WAF ở tầng ứng dụng

WAF là nơi mọi thứ bắt đầu khác hẳn. Nó không dừng ở chuyện “IP nào, port nào”, mà đi tới chính yêu cầu web. Nó có thể nhìn URL nào đang bị gọi, phương thức GET hay POST, user-agent là gì, yêu cầu có dấu hiệu bất thường hay không, và trong nhiều tình huống còn chặn theo quy tắc rất cụ thể cho ứng dụng web.

Đây là “moment of clarity” rất quan trọng: port 80 và 443 của webserver gần như luôn phải mở cho khách truy cập hợp lệ. Khi cổng buộc phải mở, tường lửa mạng không thể chỉ đóng lại để giải quyết vấn đề. Lúc đó, bạn cần một lớp lọc tinh hơn ở ngay phần lưu lượng web. Đó chính là lý do WAF tồn tại.

Hiểu ngắn gọn: không trạng thái là lọc thô, có trạng thái là lọc thông minh hơn theo phiên kết nối, còn WAF là lọc sát vào nội dung yêu cầu web. Ba lớp này không phải thay thế nhau hoàn toàn; chúng bổ sung cho nhau.

Nghe tới đây, nhiều người sẽ nghĩ: nếu WAF nhìn được sâu hơn, vậy cứ dùng WAF cho xong. Đây là một kỳ vọng rất phổ biến, nhưng cũng là chỗ dễ vấp nhất.

Lý do đầu tiên là tài nguyên. WAF phải đọc và xử lý nhiều thông tin hơn trên mỗi yêu cầu. Điều đó đồng nghĩa nó nặng hơn tường lửa mạng. Nếu cấu hình không hợp lý, chính lớp bảo vệ này có thể làm website chậm đi hoặc phát sinh chặn nhầm với truy cập hợp lệ.

Lý do thứ hai là vai trò. Tường lửa mạng phù hợp để làm nhiệm vụ “gác cổng ngoài”, còn WAF phù hợp để làm nhiệm vụ “soi kỹ người đã đi tới cửa web”. Đem toàn bộ việc bảo vệ đẩy hết cho một lớp duy nhất thường không phải cách tối ưu, cả về hiệu năng lẫn độ an toàn.

Nói dễ hiểu hơn: người gác cổng ngoài không cần kỹ năng phân tích sâu như cận vệ đứng sát mục tiêu, nhưng họ lại rất cần để chặn bớt dòng người ngay từ xa. Bảo mật nhiều lớp hiệu quả không phải vì lớp nào cũng làm tất cả, mà vì mỗi lớp làm đúng việc của mình.

Đây là câu hỏi rất thực tế khi bạn vận hành WordPress trên VPS. Cùng là WAF, nhưng cách triển khai quyết định rất nhiều tới mức độ chủ động, chi phí và khả năng chịu tải khi bị tấn công.

WAF trên máy chủ

Kiểu này chạy ngay trên server của bạn hoặc bám vào cấu hình webserver. Ưu điểm là kiểm soát sát, linh hoạt, phù hợp với người có khả năng quản trị hệ thống và muốn tinh chỉnh quy tắc theo nhu cầu riêng. Tuy nhiên, nếu đợt tấn công quá lớn, chính máy chủ của bạn vẫn là nơi phải gánh trước.

Cloud WAF

Cloud WAF thường đứng ở dạng proxy ngược, nằm trước máy chủ gốc. Điểm mạnh lớn nhất là khả năng hấp thụ và lọc lượng truy cập lớn trên hạ tầng phân tán của nhà cung cấp. Điều này đặc biệt hữu ích khi gặp các đợt DDoS mạnh hoặc khi bạn không muốn tự gánh toàn bộ bài toán lọc lưu lượng ở server nội bộ.

Đổi lại, bạn phải chấp nhận chi phí, phụ thuộc thêm vào dịch vụ bên ngoài, và trong một số tình huống có thể phát sinh thêm độ trễ. Nói ngắn gọn, Cloud WAF thường tiện và mạnh hơn cho bài toán chống đỡ quy mô lớn, còn WAF trên máy chủ hợp với mô hình tự kiểm soát và tinh chỉnh sâu hơn.

Điểm chốt cần nhớ là: nếu website của bạn chỉ thỉnh thoảng có bot quét vặt, chưa chắc đã cần một cấu hình phức tạp. Nhưng nếu bạn đã từng bị đập lưu lượng mạnh, lớp cloud đứng trước server thường là khoản đầu tư thực tế hơn rất nhiều.

Phần này quan trọng vì người mới thường thấy quá nhiều tên công cụ rồi tưởng chúng giống nhau. Thực ra chúng nằm ở các lớp rất khác nhau.

• iptables, firewalld, ufw: đây là các công cụ tường lửa mạng phổ biến ở cấp hệ điều hành, dùng để quản lý cổng và quy tắc truy cập.
• CSF: một lớp quản trị tường lửa phong phú hơn, mạnh về cấu hình nhưng cũng dễ trở nên rối nếu bạn chưa quen.
• Fail2ban: bản thân nó không phải tường lửa “đứng độc lập”, mà đọc log rồi dùng cơ chế firewall của hệ thống để cấm IP vi phạm theo quy tắc.
• ModSecurity: WAF mã nguồn mở phổ biến cho Apache hoặc LiteSpeed, mạnh nhưng có thể làm chậm và đôi khi chặn nhầm nếu bộ rule quá gắt.
• Cloudflare, Sucuri, quic.cloud: các lựa chọn WAF/cloud proxy quen thuộc, phù hợp khi cần lớp bảo vệ đứng trước máy chủ.
• Wordfence, BBQ Firewall, iThemes Security, WebARX: nhóm plugin bảo mật/tường lửa ở phía WordPress, mức độ can thiệp và cách hoạt động không giống nhau.

“Moment of clarity” ở đây là: thấy có plugin firewall trong WordPress không có nghĩa là bạn đã có cùng loại bảo vệ với firewall mạng hoặc Cloud WAF. Chúng không đứng ở cùng vị trí trong luồng truy cập, nên tác dụng cũng không giống nhau.

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

firewall-cmd --zone=public --add-port=80/tcp
ufw allow 80

Ba lệnh trên chỉ là ví dụ minh họa cho ba hệ công cụ khác nhau. Đừng copy rồi chạy máy móc nếu bạn chưa biết máy chủ của mình đang dùng công cụ nào, policy mặc định ra sao và còn lớp cloud/security group nào đứng phía trước hay không.

Đây là phần rất dễ bị tranh luận sai. Nói đơn giản, không có lớp bảo vệ nào là miễn phí hoàn toàn về mặt xử lý. Càng đọc kỹ lưu lượng, càng phải dùng thêm tài nguyên.

Tường lửa mạng ở mức IP/port thường nhẹ hơn và ít ảnh hưởng tới hiệu năng máy chủ. Trong nhiều tình huống, nó còn giúp hệ thống “dễ thở” hơn vì chặn bớt kết nối xấu ngay từ sớm. Ngược lại, WAF thường nặng hơn vì phải xử lý quy tắc cho từng yêu cầu web đi qua.

Nhưng nếu chỉ dừng ở đây thì vẫn chưa đủ. Trong điều kiện bình thường, thêm WAF có thể khiến website chậm hơn đôi chút. Trong điều kiện bị tấn công, câu chuyện có thể đảo ngược: hệ thống có lớp lọc hợp lý lại giữ được ổn định tốt hơn so với hệ thống không có bất kỳ lớp cản nào.

Nói cách khác, đánh giá hiệu năng của tường lửa không thể chỉ nhìn speed test trong lúc yên bình. Phải nhìn cả lúc hệ thống bị quấy phá. Lúc đó, một lớp bảo vệ tốt không chỉ là bảo mật, mà còn là cách giữ tài nguyên cho người dùng thật.

Nếu website của bạn rất ít giá trị, gần như không ai đụng tới, chưa từng thấy bot quét, chưa từng có dấu hiệu dò đăng nhập hay tấn công lưu lượng, bạn có thể chưa cần một hệ thống phòng thủ phức tạp. Nhưng đó là trạng thái “chưa cần tối đa”, không phải lý do để bỏ qua các lớp bảo vệ cơ bản.

Với website WordPress thật sự đang hoạt động, đặc biệt có trang đăng nhập, wp-admin, biểu mẫu, WooCommerce hoặc API mở ra ngoài, việc có ít nhất một lớp firewall mạng hợp lý và một chiến lược lọc truy cập web là điều nên có. Không nhất thiết phải phức tạp, nhưng nên có.

Điều không nên kỳ vọng quá mức là: cài một plugin rồi coi như xong bảo mật. Tường lửa không thay thế cập nhật hệ thống, không thay thế phân quyền đúng, không thay thế mật khẩu mạnh, không thay thế backup, cũng không thay thế việc đóng các cổng không cần dùng.

Chốt lại thật ngắn: hãy dùng tường lửa như một phần của kiến trúc phòng thủ nhiều lớp. Đặt nó đúng chỗ, đúng vai trò, và đúng mức độ cần thiết. Làm vậy vừa thực tế, vừa bền hơn nhiều so với tư duy “cài một thứ để giải quyết tất cả”.

Tường lửa không phải món trang trí để “bật cho yên tâm”. Nó là lớp quyết định ai được bước tiếp vào hệ thống và ai phải dừng lại từ sớm. Khi hiểu đúng sự khác nhau giữa firewall mạng, firewall có trạng thái và WAF, bạn sẽ bớt chọn sai công cụ, bớt kỳ vọng sai vào plugin, và xây được lớp bảo vệ hợp lý hơn cho WordPress hoặc VPS của mình.