Firewall là gì: tường lửa không phải một thứ mà là nhiều tầng
Firewall (tường lửa) là hệ thống lọc traffic (lưu lượng dữ liệu) ra vào một mạng hoặc thiết bị, cho phép những gì an toàn và chặn những gì nghi ngờ dựa trên bộ quy tắc được thiết lập trước. Ý tưởng cốt lõi đơn giản: mọi kết nối đến đều phải đi qua kiểm tra, không ai vào tự do.
Tên gọi “firewall” xuất phát từ kỹ thuật xây dựng: tường ngăn lửa (firewall) trong tòa nhà dùng để ngăn lửa lan từ khu vực này sang khu vực khác. Trong an ninh mạng, firewall ngăn traffic độc hại lan sang hệ thống được bảo vệ.
Điều khiến nhiều người nhầm lẫn là “firewall” không chỉ là một thiết bị hay một phần mềm cụ thể. Đây là khái niệm tổng quát áp dụng ở nhiều tầng khác nhau trong hệ thống. Firewall trên router nhà bạn, firewall trên máy chủ Linux và WAF (Web Application Firewall) trên website đều được gọi là “firewall” nhưng hoạt động ở các tầng hoàn toàn khác nhau và bảo vệ trước các loại tấn công hoàn toàn khác nhau.
Ba loại tường lửa và vị trí của từng loại trong hệ thống
Để hiểu tại sao website cần WAF riêng mà không thể dùng chung firewall mạng, cần nhìn vào vị trí của từng loại trong hệ thống và những gì chúng có thể kiểm tra:
| Loại tường lửa | Ngồi ở đâu | Kiểm tra gì | Ngăn được loại tấn công nào | Không ngăn được gì |
|---|---|---|---|---|
| Network Firewall (tường lửa mạng) | Ở ranh giới mạng, trước khi traffic vào hệ thống | Địa chỉ IP nguồn, cổng kết nối, giao thức mạng | Chặn IP độc, chặn cổng không cần thiết, ngăn DDoS cơ bản | Không đọc được nội dung của gói tin đã vào cổng cho phép, không hiểu HTTP |
| Host-based Firewall (tường lửa máy chủ) | Trên chính máy chủ, bảo vệ từng server riêng | Traffic vào ra máy chủ đó, kiểm soát process nào được kết nối mạng | Giới hạn chương trình nào được gửi/nhận dữ liệu, phát hiện process bất thường | Không phân tích nội dung HTTP request ở tầng ứng dụng |
| WAF (Web Application Firewall) | Trước web server, đọc từng HTTP request trước khi vào ứng dụng | Toàn bộ nội dung HTTP: URL, header, query string, body của request | SQL injection, XSS (cross-site scripting), CSRF, path traversal, tấn công ứng dụng web theo OWASP Top 10 | Không thay thế được firewall mạng, không bảo vệ hệ thống ngoài tầng web |
Điểm phản biện quan trọng: nhiều chủ web nghĩ “đã có firewall của hosting rồi thì an toàn”. Firewall của hosting là loại network hoặc host-based, không đọc được nội dung HTTP. Nếu attacker gửi SQL injection qua cổng 443 (HTTPS) thì firewall mạng không thể phân biệt được đó là request bình thường hay tấn công, vì nó chỉ thấy “traffic HTTPS từ IP chưa bị blacklist”.
WAF ngồi ở đâu trong đường đi của một lượt truy cập
Mỗi khi ai đó gõ địa chỉ website của bạn và nhấn Enter, request đó đi qua một loạt tầng trước khi chạm tới ứng dụng. WAF ngồi ở một vị trí rất cụ thể trong chuỗi đó:
Chuỗi đi như sau: người dùng gửi request → qua DNS phân giải tên miền → qua CDN (nếu có) → vào WAF → WAF kiểm tra → nếu an toàn thì chuyển sang web server → server xử lý và trả về nội dung. WAF hoạt động như một trạm kiểm soát đặt ngay trước cửa vào ứng dụng.
WAF làm việc như một reverse proxy (đại diện ngược): thay vì client kết nối thẳng vào server, client kết nối vào WAF, WAF kiểm tra rồi mới kết nối vào server thay mặt client. Điều này có nghĩa là server thật không bao giờ tiếp xúc trực tiếp với request từ bên ngoài mà không qua lọc. Cloudflare và Sucuri là hai dịch vụ WAF phổ biến hoạt động theo mô hình này, với traffic đi qua hạ tầng của họ trước khi về server của bạn.
WAF chặn được gì và không chặn được gì
WAF không phải lá chắn toàn năng. Hiểu đúng giới hạn của WAF quan trọng không kém hiểu những gì nó làm được, để không phụ thuộc sai cách:
WAF chặn được: SQL injection, XSS (cross-site scripting), CSRF (cross-site request forgery), tấn công brute force vào trang đăng nhập, bad bot quét lỗ hổng tự động, và nhiều loại tấn công ứng dụng web khác trong danh sách OWASP Top 10. WAF cũng có thể hạn chế tấn công DDoS ở tầng ứng dụng bằng cách giới hạn số request từ một IP trong một khoảng thời gian.
WAF không chặn được: Malware đã tồn tại trên server (WAF chỉ lọc traffic vào ra, không scan file trên server), tấn công qua SSH hoặc FTP, lỗ hổng logic trong code ứng dụng mà attacker khai thác bằng request hợp lệ về hình thức, zero-day exploit chưa có trong rule của WAF, và tấn công từ bên trong hệ thống.
Đây là lý do tại sao bảo mật website là nhiều tầng, không phải một giải pháp duy nhất. WAF bảo vệ tầng ứng dụng từ bên ngoài. Nếu website đã bị nhiễm malware từ trước hoặc qua con đường khác (như plugin lậu), WAF không giúp ích được gì cho việc dọn dẹp đó. Xem thêm bài malware là gì để hiểu các con đường malware xâm nhập mà WAF không thể ngăn.
Khi nào website thực sự cần WAF
Không phải website nào cũng cần WAF ngay từ đầu. Nhưng có những tình huống mà việc không có WAF là rủi ro rõ ràng:
Website có form nhận dữ liệu từ người dùng: Form đăng nhập, form liên hệ, form tìm kiếm, giỏ hàng đều là điểm tiềm năng cho SQL injection và XSS. Nếu code không được viết an toàn từ đầu, WAF là lớp bảo vệ bổ sung.
Website chạy WordPress hoặc CMS phổ biến: Các CMS phổ biến là mục tiêu được bot quét liên tục vì attacker biết rõ cấu trúc và các lỗ hổng phiên bản cũ. WAF có thể chặn các scan tự động này trước khi chúng tìm ra điểm yếu.
Website có traffic tương đối và thiệt hại kinh doanh khi downtime: Nếu website không hoạt động một ngày gây thiệt hại đáng kể, chi phí WAF hàng tháng thường nhỏ hơn nhiều so với chi phí dọn malware hoặc phục hồi sau tấn công.
Website chưa được cập nhật đều đặn: Nếu vì lý do nào đó bạn không thể cập nhật plugin và WordPress ngay khi có bản vá, WAF có thể “vá tạm” những lỗ hổng đã biết ở tầng traffic trong khi chờ cập nhật thật.
Người không rành kỹ thuật cần biết về firewall tới mức nào
Bạn không cần biết cách cấu hình rule của WAF hay đọc firewall log. Nhưng có hai điều quan trọng nên nắm:
Thứ nhất, hỏi thẳng nhà cung cấp hosting xem gói của bạn có WAF không. Nhiều gói hosting chia sẻ có firewall mạng cơ bản nhưng không có WAF cho tầng ứng dụng. Đây là câu hỏi đơn giản nhưng ít người hỏi.
Thứ hai, biết rằng firewall không đồng nghĩa với bất khả xâm phạm. Một website có WAF vẫn cần cập nhật plugin thường xuyên, dùng mật khẩu mạnh và có backup định kỳ. WAF là một tầng trong nhiều tầng bảo vệ, không phải giải pháp độc lập thay thế tất cả.
Nếu bạn muốn có người chuyên trách kiểm tra và duy trì các tầng bảo mật này cho website, xem thêm dịch vụ bảo mật website của Web22 để biết những gì được kiểm tra và giám sát định kỳ.
Câu hỏi thường gặp về firewall
Cloudflare free có phải WAF không?
Gói miễn phí của Cloudflare có một số tính năng lọc DDoS cơ bản nhưng bộ rule WAF đầy đủ (chặn OWASP Top 10, custom rule) chỉ có ở gói trả phí. Gói free giúp được phần nào với DDoS và bot đơn giản, nhưng không thay thế được WAF thực sự cho website thương mại.
WAF có làm chậm website không?
Có thêm một bước kiểm tra trong đường đi của request nên về lý thuyết là có độ trễ. Nhưng với WAF dạng CDN (như Cloudflare hay Sucuri), traffic đi qua mạng của họ thường nhanh hơn đường thẳng vì được phân phối qua các điểm gần người dùng. Trong thực tế nhiều website sau khi bật WAF qua CDN lại tải nhanh hơn chứ không chậm hơn.
Có thể tự cài WAF trên WordPress không?
Plugin bảo mật WordPress như Wordfence hay Sucuri Security có tính năng WAF tích hợp, hoạt động ở tầng PHP (muộn hơn trong chu kỳ xử lý request so với WAF đặt trước web server). Loại này dễ cài hơn và phù hợp cho website nhỏ, nhưng kém hiệu quả hơn WAF đặt ngoài vì request vẫn chạm đến server trước khi bị kiểm tra.
Firewall máy chủ và WAF có cần dùng cùng lúc không?
Cần, vì chúng bảo vệ ở hai tầng khác nhau. Firewall máy chủ giới hạn cổng kết nối và bảo vệ hệ thống tổng thể; WAF lọc request ứng dụng web. Thiếu một trong hai thì để hở tầng tương ứng. Đây cũng là lý do các dịch vụ bảo mật website toàn diện thường kết hợp cả hai thay vì chọn một.