WAF và Firewall Server đều lọc traffic nhưng trả lời hai câu hỏi khác nhau. Firewall Server quyết định kết nối mạng nào được phép đi tới host/port nào; WAF quyết định một request HTTP/HTTPS đã được phép tới website có dấu hiệu độc hại hoặc vi phạm policy ứng dụng hay không.
Vì vậy WAF không thay thế firewall server, và firewall server cũng không thay thế WAF. Một website public thường cần cả hai: firewall thu hẹp network exposure, còn WAF kiểm tra traffic web chạy trên những port đã được phép như 80/443.
Bảng so sánh WAF và Firewall Server
| Tiêu chí | Firewall Server | WAF |
|---|---|---|
| Phạm vi chính | Network/transport traffic | Web application và API traffic |
| Tín hiệu thường dùng | Source/destination IP, port, protocol, connection state | Hostname, URL, method, header, cookie, query, body, request pattern |
| Câu hỏi chính | Kết nối này có được phép tới dịch vụ này không? | Request web này có nên được phép xử lý không? |
| Ví dụ control | Chỉ mở 22 từ bastion; chỉ mở 443 từ reverse proxy | Block pattern SQLi; challenge bot; rate limit login |
| Traffic ngoài HTTP | Có thể kiểm soát | Thường không phải phạm vi |
| Vị trí | Host, network edge, security group/firewall appliance | Reverse proxy, CDN/edge, appliance hoặc web-server module |
| Failure điển hình | Mở port/source quá rộng | False positive, exception quá rộng, origin bypass |
Hai lớp bảo vệ khác nhau ở đâu?
Firewall Server bảo vệ lớp nào?
Firewall trên server hoặc network boundary tập trung vào luồng kết nối. Nó rất phù hợp với policy như “chỉ 80/443 public”, “SSH chỉ từ VPN/bastion”, “database không được public Internet” hoặc “origin chỉ nhận web traffic từ dải IP của reverse proxy”.
Điều này làm giảm attack surface trước khi request chạm tới application. Nếu port 3306 không cần public, firewall có thể chặn toàn bộ đường truy cập từ Internet mà không cần hiểu query MySQL bên trong.
Phần thiết kế inbound policy, UFW/nftables và nguyên tắc least exposure đã có owner riêng tại Linux Firewall cho Web Server.
WAF bảo vệ lớp nào?
OWASP định nghĩa WAF là application firewall cho HTTP application. WAF áp rule lên HTTP conversation và thường được dùng để phát hiện hoặc chặn các attack pattern web như SQL injection hoặc cross-site scripting. Nó có thể quan sát chi tiết mà firewall mạng thông thường không dùng làm policy: path, method, header, cookie, parameter hoặc request body.
Ví dụ, cả request hợp lệ và request có payload tấn công đều có thể đi qua TCP/443. Với firewall server, hai kết nối này đều “đúng port”. WAF có thêm context để phân biệt request ở tầng HTTP. Bài WAF là gì? giải thích sâu hơn về cách WAF xử lý rule và request.
Ba tình huống thực tế để chọn đúng control
Ví dụ 1: SQL injection qua HTTPS
Website cần public HTTPS nên firewall server cho phép TCP/443. Attacker gửi một request chứa chuỗi có dấu hiệu SQL injection qua chính kết nối HTTPS được phép đó.
- Firewall Server: kết nối tới 443 phù hợp network policy nên có thể được cho qua.
- WAF: sau khi traffic được terminate/inspect ở lớp phù hợp, rule có thể đánh giá URL, parameter hoặc body và áp action.
- Application: vẫn phải dùng parameterized query và sửa root cause; WAF không phải patch thay code.
Ví dụ 2: SSH bị mở cho toàn Internet
Nếu SSH trên port 22 đang public cho mọi source, đây là bài toán network exposure.
- Firewall Server: có thể giới hạn source IP/VPN/bastion hoặc đóng port khi không cần.
- WAF: không phải control phù hợp vì SSH không phải HTTP application traffic.
Trong trường hợp này, cần xử lý bằng firewall và SSH Hardening, không phải thêm WAF rule.
Ví dụ 3: chỉ cho phép origin nhận traffic từ CDN/WAF
Cloud WAF có thể bảo vệ request đi qua edge, nhưng nếu origin IP vẫn public trực tiếp thì attacker có thể thử bypass lớp edge. Đây là nơi WAF và firewall server phối hợp:
- WAF/CDN lọc HTTP traffic ở edge;
- firewall/security group tại origin chỉ cho phép những đường vào thực sự cần thiết;
- origin authentication hoặc cơ chế xác minh proxy có thể bổ sung tùy kiến trúc;
- DNS và historical exposure cũng phải được xem xét, không chỉ rule hiện tại.
Owner cho bài toán này là Origin Protection: cách ngăn attacker bypass CDN/WAF.
Boundary kỹ thuật cần hiểu
WAF có phải luôn là Layer 7, còn firewall luôn là Layer 3/4?
Đây là cách giải thích hữu ích để hiểu boundary, nhưng không nên biến thành quy tắc tuyệt đối về mọi sản phẩm. Next-generation firewall có thể có application awareness, IDS/IPS, TLS inspection hoặc policy sâu hơn L3/L4. Ngược lại, WAF là control chuyên biệt cho HTTP/web application.
Vì vậy khi đánh giá một sản phẩm cụ thể, hãy nhìn vào traffic mà nó thực sự inspect, nơi TLS được terminate, dữ liệu nào rule engine thấy được và action nào có thể áp dụng, thay vì chỉ dựa vào nhãn “firewall”.
TLS ảnh hưởng tới WAF và firewall như thế nào?
HTTP hiện nay thường chạy bên trong TLS. Một thiết bị chỉ nhìn thấy kết nối mã hóa sẽ không tự động thấy URL parameter, cookie hoặc body. Muốn áp policy dựa trên nội dung HTTP, traffic phải được giải mã/terminate ở điểm có quyền inspect phù hợp.
Cloud WAF/reverse proxy thường là một trong các điểm terminate TLS trước khi request được proxy tới origin. Network firewall có thể có TLS inspection trong một số kiến trúc, nhưng đó là capability riêng và kéo theo yêu cầu về certificate, privacy, performance và trust boundary. Không nên mặc định mọi firewall đều “đọc được HTTPS”.
Chọn control theo loại rủi ro
WAF và Firewall Server chặn các loại rủi ro nào?
| Tình huống | Firewall Server | WAF | Control chính khác |
|---|---|---|---|
| SSH public quá rộng | Mạnh | Không phù hợp | SSH hardening, VPN/bastion |
| Database public Internet | Mạnh | Không phù hợp | DB hardening, network segmentation |
| SQLi/XSS pattern trong HTTP | Hạn chế nếu chỉ lọc network | Phù hợp | Secure coding, patch |
| Bot abuse login | Hạn chế | Hữu ích | Rate limiting, MFA, bot controls |
| Broken access control | Không giải quyết root cause | Thường không đủ context | Authorization trong application |
| Volumetric DDoS | Có thể drop nhưng có thể quá muộn | Không phải lớp duy nhất | Upstream/CDN/DDoS mitigation |
Có WAF rồi có cần Firewall Server nữa không?
Có. WAF chỉ nên nhận traffic web mà application cần. Server vẫn có SSH, monitoring agent, database connection, internal service hoặc management interface cần network policy riêng. Nếu bỏ firewall vì đã có WAF, attack surface ngoài HTTP có thể vẫn mở.
Một baseline tốt thường đi từ inventory attack surface rồi đóng service/port không cần thiết trước khi thêm các lớp application security.
Có Firewall Server rồi có cần WAF nữa không?
Không phải website nào cũng có cùng risk profile, nhưng network firewall không thể thay thế việc hiểu request HTTP. Nếu web application có login, API, checkout, upload, form phức tạp hoặc thường xuyên bị exploit scan, WAF có thể cung cấp thêm lớp detection/mitigation hữu ích.
Quyết định nên dựa trên threat model và khả năng vận hành, không phải checklist sản phẩm. Xem Khi nào website cần WAF? để đánh giá nhu cầu theo exposure và critical flow.
Mô hình phối hợp thực tế
Internet ↓ CDN / DDoS Protection / WAF ↓ Origin Firewall / Security Group ↓ Reverse Proxy / Web Server ↓ Application / API ↓ Internal Firewall / Segmentation ↓ Database / Internal Services
Ở mô hình này, mỗi lớp có owner task rõ ràng. WAF không cần biết cách quản lý SSH; firewall không cần tự hiểu business logic của checkout; application vẫn chịu trách nhiệm authorization và validation. Defense in depth hiệu quả khi mỗi control có boundary rõ và không có lớp nào được xem là “bảo vệ tất cả”.
Sai lầm cấu hình thường gặp
- Mở 80/443 từ mọi nơi ở origin dù đã dùng CDN/WAF: có thể tạo đường bypass.
- Dùng WAF để thay patch: virtual patch chỉ là mitigation tạm thời, không sửa lỗ hổng gốc.
- Chặn theo IP tại WAF nhưng quên IP thật/proxy chain: có thể policy sai source.
- Firewall allowlist dải proxy nhưng không có quy trình cập nhật: thay đổi upstream có thể gây outage.
- Bật rule WAF quá rộng: login, checkout, API hoặc webhook có thể false positive.
- Không ghi log ở cả hai lớp: khó biết request bị drop ở network hay bị block ở application edge.
Checklist chọn control đúng
- Nếu câu hỏi là “port/service nào được public?” → bắt đầu từ firewall.
- Nếu câu hỏi là “request HTTP này có độc hại?” → đánh giá WAF.
- Nếu câu hỏi là “traffic lớn có làm nghẽn upstream?” → cần DDoS/CDN/upstream capacity.
- Nếu câu hỏi là “user này có được phép xem object kia?” → sửa authorization ở application.
- Nếu câu hỏi là “origin có bị bypass edge?” → phối hợp firewall + origin protection.
- Nếu câu hỏi là “rule đang chặn nhầm?” → dùng WAF telemetry và false-positive workflow.
Kết luận
Firewall Server và WAF không phải hai lựa chọn thay thế. Firewall giảm network exposure và kiểm soát kết nối tới host/service; WAF chuyên kiểm tra HTTP/HTTPS tới web application. Một kiến trúc an toàn thường dùng firewall để giới hạn đường vào, sau đó dùng WAF cho traffic web được phép, đồng thời vẫn vá ứng dụng và bảo vệ origin.