Bài 51 — Network Security — Security Group, WAF, DDoS

Mở đầu — vì sao bài này quan trọng

Hãy hình dung hệ thống cloud của bạn như một khu chung cư. VPC là toàn bộ khu đất, subnet là từng tòa nhà, còn các máy chủ (instance) là từng căn hộ bên trong. Bây giờ câu hỏi sống còn: ai được phép đi vào khu đất? Ai được vào từng tòa nhà? Ai được gõ cửa từng căn hộ? Nếu bạn để cửa mở toang, sớm muộn cũng có người lạ vào — và trên Internet, "người lạ" là các bot quét cổng chạy 24/7, tìm bất kỳ máy chủ nào hở port 22, 3306 hay 6379 để tấn công.

Network Security chính là hệ thống kiểm soát cửa ra vào đó. Trong bài này chúng ta tập trung vào ba lớp phòng thủ ở tầng mạng mà bất kỳ kỹ sư cloud nào cũng phải nắm vững: Security Group (tường lửa cấp instance), Network ACL (tường lửa cấp subnet), và các cơ chế chống tấn công ứng dụng/khối lượng lớn là WAF và DDoS protection.

Đây không phải kiến thức "cho vui". Một cấu hình sai Security Group là nguyên nhân số một khiến database bị lộ ra Internet và bị đánh cắp dữ liệu. Theo các báo cáo bảo mật cloud hằng năm, phần lớn sự cố rò rỉ dữ liệu không đến từ lỗ hổng phức tạp, mà đến từ những sai lầm cấu hình đơn giản: mở 0.0.0.0/0 cho cổng SSH, để S3 public, hay quên bật WAF trước một API công khai. Học tốt bài này, bạn đã tránh được đa số rủi ro nghiêm trọng nhất.

Khái niệm cốt lõi

Security Group — tường lửa cấp instance

Security Group (SG) là một tập hợp các quy tắc (rules) kiểm soát traffic vào (inbound) và ra (outbound) của một máy chủ cụ thể. Nó gắn trực tiếp vào network interface của instance, database, load balancer... Bạn có thể hiểu SG như người bảo vệ đứng ngay trước cửa từng căn hộ.

Ba đặc điểm quan trọng nhất của Security Group:

• Stateful (có trạng thái): nếu bạn cho phép một request đi vào, thì response đi ra được tự động cho phép — bạn không cần viết rule chiều ngược lại. Đây là điểm khác biệt lớn so với Network ACL.
• Chỉ có rule Allow (cho phép), không có rule Deny (từ chối). Mặc định mọi thứ bị chặn; bạn chỉ mở đúng những gì cần. Đây là mô hình "default deny" — an toàn theo mặc định.
• Có thể tham chiếu Security Group khác thay vì IP. Ví dụ: SG của database chỉ cho phép traffic đến từ SG của web server. Khi web server tăng giảm số lượng máy, bạn không cần sửa IP — cực kỳ tiện cho auto-scaling.

Network ACL — tường lửa cấp subnet

Network ACL (NACL) hoạt động ở cấp subnet, tức là lọc traffic ra vào cả một tòa nhà, trước khi traffic chạm tới bất kỳ căn hộ nào. Đây là lớp phòng thủ rộng hơn, thô hơn nhưng cũng mạnh mẽ vì nó có thể chặn tường minh (explicit deny) — điều mà Security Group không làm được.

Bảng so sánh cốt lõi mà bạn cần thuộc lòng:

Điểm mấu chốt cần nhớ: NACL là stateless. Nếu bạn mở inbound cho port 443, bạn còn phải tự mở outbound cho ephemeral ports (dải cổng tạm 1024–65535) để response quay ra được. Rất nhiều người mới quên điều này và ngồi debug hàng giờ vì kết nối cứ bị treo.

Cách phối hợp đúng: dùng NACL như "bức tường thành phòng tuyến đầu" để chặn các dải IP độc hại đã biết ở cấp subnet, và dùng Security Group làm "lớp kiểm soát chi tiết" cho từng service. Hai lớp bổ sung cho nhau theo nguyên tắc defense in depth (phòng thủ nhiều lớp).

WAF — Web Application Firewall

Security Group và NACL làm việc ở tầng mạng (L3/L4) — chúng nhìn IP, port, protocol nhưng không hiểu nội dung HTTP. Chúng không biết phân biệt một request đăng nhập hợp lệ với một request chứa mã SQL injection. Đó là lúc WAF vào cuộc.

WAF hoạt động ở tầng ứng dụng (L7), đọc và hiểu nội dung HTTP: URL, header, body, cookie, query string. Nó bảo vệ chống lại các đòn tấn công phổ biến trong danh sách OWASP Top 10 như SQL injection, Cross-site scripting (XSS), path traversal... Ngoài ra WAF còn cho phép:

• Rate limiting: giới hạn số request từ một IP trong khoảng thời gian (ví dụ tối đa 2000 request/5 phút).
• Geo-blocking: chặn traffic theo quốc gia.
• Managed rules: bộ quy tắc dựng sẵn do nhà cung cấp cập nhật liên tục (AWS Managed Rules, Cloudflare Managed Ruleset).

Trên AWS là AWS WAF, gắn vào CloudFront, ALB hoặc API Gateway. Trên GCP là Cloud Armor. Trên Azure là Azure WAF (trong Application Gateway/Front Door). Cloudflare là một lựa chọn phổ biến độc lập, đặc biệt được nhiều doanh nghiệp Việt Nam ưa dùng.

DDoS — tấn công từ chối dịch vụ phân tán

DDoS (Distributed Denial of Service) là kiểu tấn công dùng hàng ngàn, hàng triệu nguồn cùng gửi traffic để làm nghẽn và sập hệ thống. Có ba loại chính:

• Volumetric (tấn công khối lượng): làm tràn băng thông, ví dụ UDP flood, DNS amplification. Đo bằng Gbps.
• Protocol (tấn công giao thức): khai thác điểm yếu ở L3/L4 như SYN flood, làm cạn tài nguyên kết nối.
• Application layer (tấn công tầng ứng dụng, L7): gửi lượng lớn request "trông có vẻ hợp lệ" tới các endpoint tốn tài nguyên. Khó phát hiện nhất.

Các nhà cung cấp cloud lớn đều có dịch vụ chống DDoS: AWS Shield (Standard miễn phí, Advanced trả phí), GCP Cloud Armor, Azure DDoS Protection, và Cloudflare. Lớp bảo vệ volumetric/protocol thường được xử lý ở tầng edge/CDN, còn lớp L7 thì kết hợp với WAF và rate limiting.

Tình huống thực tế

Tình huống 1 — Sàn thương mại điện tử để lộ database Redis

Một startup thương mại điện tử ở TP.HCM, tạm gọi là "ShopViet", chạy trên AWS. Một kỹ sư mới muốn kết nối nhanh vào Redis cache từ máy cá nhân để debug, nên đã sửa Security Group của instance Redis thành inbound cho phép port 6379 từ nguồn 0.0.0.0/0 — nghĩa là mở cho toàn bộ Internet. Anh ta định "sửa xong sẽ đóng lại" nhưng rồi quên mất.

Chỉ sau khoảng 6 giờ, các bot quét Internet đã tìm thấy port Redis mở. Redis mặc định không đặt password, nên kẻ tấn công ghi được dữ liệu vào, chèn cron job độc hại và bắt đầu đào tiền ảo bằng tài nguyên máy chủ. Đội vận hành phát hiện khi thấy hóa đơn CPU tăng đột biến và cache liên tục bị flush.

Bài học rút ra: không bao giờ mở port dịch vụ nội bộ (database, cache, message queue) ra 0.0.0.0/0. Redis, MySQL, MongoDB... chỉ nên nhận traffic từ Security Group của application server, thông qua tham chiếu SG chứ không phải IP. Nếu cần truy cập từ máy cá nhân để debug, hãy dùng bastion host hoặc SSM Session Manager, không mở port thẳng ra Internet. Đây là lỗi kinh điển và cực kỳ phổ biến.

Tình huống 2 — Báo điện tử bị DDoS trong đợt bầu chọn

Một trang báo điện tử lớn ở Việt Nam tổ chức một chương trình bình chọn trực tuyến. Trong giờ cao điểm, lượng traffic thật tăng vọt, nhưng lẫn trong đó là một đợt tấn công L7: khoảng 1,2 triệu request/phút dồn vào endpoint gửi phiếu bầu, khiến server ứng dụng quá tải và cả trang chậm hẳn.

Đội kỹ thuật đã dùng Cloudflare đặt trước hệ thống. Họ bật rate limiting: giới hạn mỗi IP tối đa 30 request/phút tới endpoint bình chọn, thêm challenge (kiểm tra JavaScript/CAPTCHA) khi vượt ngưỡng, và bật geo-analysis để nhận diện các cụm IP bất thường từ nước ngoài. Kết quả: traffic tấn công bị lọc ở tầng edge trước khi chạm tới origin server, trang web ổn định trở lại trong vòng chưa đầy một giờ.

Bài học rút ra: DDoS L7 không thể chỉ chặn bằng Security Group (nó nhìn IP/port, không hiểu logic ứng dụng). Bạn cần WAF + rate limiting ở tầng L7, và tốt nhất là đặt sau một lớp CDN/edge để hấp thụ traffic. Ngoài ra, các endpoint "đắt tài nguyên" như bình chọn, tìm kiếm, đăng nhập nên có rate limit riêng, chặt hơn phần còn lại của site.

Tình huống 3 — API ngân hàng số bị dò SQL injection

Một ngân hàng số (neobank) ở Đông Nam Á cung cấp API công khai cho ứng dụng mobile. Đội security phát hiện trong log có nhiều request chứa payload dạng ' OR '1'='1 và UNION SELECT nhắm vào tham số tìm kiếm giao dịch — dấu hiệu rõ ràng của việc dò SQL injection tự động.

Họ triển khai AWS WAF gắn vào API Gateway, bật bộ AWS Managed Rules (nhóm SQLi và Common Rule Set), đồng thời thêm rate limit 2000 request/5 phút cho mỗi IP. Trong tuần đầu, WAF chặn hơn 40.000 request độc hại, và quan trọng hơn, đội dev có thời gian rà soát code để đảm bảo dùng parameterized query (truy vấn tham số hóa) ở tầng ứng dụng.

Bài học rút ra: WAF là lớp phòng thủ giá trị, nhưng nó là "lá chắn", không phải "phương thuốc". Bạn vẫn phải viết code an toàn (parameterized query, validate input). WAF mua cho bạn thời gian và chặn phần lớn tấn công tự động, nhưng bảo mật thực sự đến từ nhiều lớp cùng hoạt động — mạng, ứng dụng, và code.

Hướng dẫn từng bước

Dưới đây là quy trình thiết lập network security cho một ứng dụng web ba tầng (web — app — database) trên cloud. Nguyên tắc xuyên suốt: least privilege (chỉ mở tối thiểu những gì cần).

• Vẽ sơ đồ luồng traffic trước khi cấu hình. Xác định ai cần nói chuyện với ai: Internet → Load Balancer (443) → App Server (8080) → Database (3306). Chỉ những mũi tên này được phép tồn tại.

• Tạo Security Group cho Load Balancer. Inbound: cho phép port 443 (HTTPS) và 80 (HTTP, để redirect sang HTTPS) từ 0.0.0.0/0. Đây là service duy nhất được mở ra Internet.

• Tạo Security Group cho App Server. Inbound: chỉ cho phép port 8080 từ Security Group của Load Balancer (tham chiếu SG, không dùng IP). App server không được nhận traffic trực tiếp từ Internet.

• Tạo Security Group cho Database. Inbound: chỉ cho phép port 3306 từ Security Group của App Server. Tuyệt đối không mở ra 0.0.0.0/0. Database nằm ở private subnet.

• Cấu hình Network ACL cho subnet. Ở private subnet chứa database, thêm rule deny các dải IP độc hại đã biết. Nhớ mở ephemeral ports (1024–65535) ở chiều outbound vì NACL là stateless.

• Gắn WAF vào Load Balancer hoặc CDN. Bật managed rules (OWASP Core Rule Set), thêm rate limiting theo IP, cân nhắc geo-blocking nếu dịch vụ chỉ phục vụ trong nước.

• Bật DDoS protection. Tối thiểu dùng gói miễn phí (AWS Shield Standard / Cloudflare Free). Với dịch vụ quan trọng, cân nhắc gói Advanced và đặt CDN ở phía trước để hấp thụ traffic volumetric.

• Bật logging và giám sát. Bật VPC Flow Logs, WAF logs. Đặt alert khi có traffic bất thường. Không có log thì bạn không biết mình đang bị tấn công.

• Kiểm thử. Dùng công cụ quét port từ bên ngoài (ví dụ nmap) để xác nhận chỉ port 443/80 mở ra Internet, mọi port khác đều đóng.

Lỗi thường gặp & mẹo

• Mở 0.0.0.0/0 cho SSH (22) hoặc RDP (3389). Đây là lỗi phổ biến nhất và nguy hiểm nhất. Bot quét sẽ brute-force ngay. Hãy giới hạn theo IP văn phòng/VPN, hoặc dùng SSM Session Manager để bỏ hẳn SSH mở.

• Quên NACL là stateless. Bạn mở inbound nhưng quên mở outbound cho ephemeral ports, kết nối treo. Với Security Group thì không lo vì nó stateful — nhưng đừng lẫn lộn hai loại.

• Dùng IP thay vì tham chiếu Security Group. Trong môi trường auto-scaling, IP thay đổi liên tục. Tham chiếu SG-to-SG giúp rule luôn đúng mà không cần cập nhật thủ công.

• Bật WAF ở chế độ Block ngay từ đầu mà không test. Managed rules đôi khi chặn nhầm traffic hợp lệ (false positive). Mẹo: chạy WAF ở chế độ Count (chỉ đếm, không chặn) vài ngày, xem log, tinh chỉnh rồi mới chuyển sang Block.

• Tưởng WAF chống được mọi DDoS. WAF giỏi ở L7, nhưng tấn công volumetric ở L3/L4 cần lớp CDN/edge và dịch vụ Shield/DDoS Protection chuyên dụng.

• Chỉ dựa vào một lớp phòng thủ. Bảo mật đúng là nhiều lớp: NACL + Security Group + WAF + DDoS protection + code an toàn. Một lớp thủng thì các lớp khác vẫn đỡ.

• Mẹo gắn tag và đặt tên rõ ràng. Đặt tên SG kiểu sg-app-prod, sg-db-prod thay vì sg-1, sg-test-2. Sáu tháng sau bạn sẽ cảm ơn chính mình khi phải audit.

Bài tập thực hành

• Thiết kế trên giấy. Vẽ sơ đồ Security Group cho một ứng dụng web ba tầng (LB — App — DB). Ghi rõ mỗi SG mở port nào, nguồn là gì (IP hay tham chiếu SG). Kiểm tra: có SG nào mở database ra 0.0.0.0/0 không? Nếu có, sửa lại.

• So sánh và phân loại. Cho các nhu cầu sau, hãy chọn công cụ phù hợp (Security Group / NACL / WAF / DDoS protection): (a) chặn dải IP 203.0.113.0/24 khỏi toàn subnet; (b) chỉ cho app server nói chuyện với database; (c) chặn request chứa SQL injection; (d) chống SYN flood 50 Gbps. Giải thích lý do mỗi lựa chọn.

• Thực hành trên môi trường thật (nếu có tài khoản cloud free tier). Tạo một EC2/VM, cấu hình Security Group chỉ mở port 443. Dùng nmap -Pn <public-ip> từ máy khác để xác nhận các port khác đều đóng. Sau đó thử mở thêm port 22 giới hạn theo IP của bạn và kiểm tra lại.

• Tình huống phân tích. Một API công khai đang bị 500.000 request/giờ từ khoảng 3.000 IP khác nhau, mỗi request đều "hợp lệ về mặt cú pháp". Đây là loại tấn công gì? Bạn sẽ dùng những lớp phòng thủ nào và cấu hình cụ thể ra sao? Viết ra 4–5 bước xử lý.

Tóm tắt

Network security trên cloud được xây theo mô hình phòng thủ nhiều lớp. Security Group là tường lửa stateful cấp instance, chỉ có rule Allow, mặc định chặn hết, và cho phép tham chiếu SG khác — đây là lớp kiểm soát chi tiết bạn dùng nhiều nhất. Network ACL là tường lửa stateless cấp subnet, có cả Allow lẫn Deny, dùng để chặn diện rộng ở tuyến đầu — nhớ mở ephemeral ports vì nó không nhớ trạng thái kết nối.

Hai công cụ trên làm việc ở tầng mạng (L3/L4) và không hiểu nội dung HTTP. Để bảo vệ tầng ứng dụng, bạn cần WAF — chặn SQL injection, XSS, làm rate limiting và geo-blocking. Cuối cùng, DDoS protection kết hợp với CDN/edge để hấp thụ tấn công khối lượng lớn.

Nguyên tắc vàng cần khắc cốt ghi tâm: least privilege (chỉ mở tối thiểu), không bao giờ để database/SSH mở ra 0.0.0.0/0, ưu tiên tham chiếu SG thay vì IP, test WAF ở chế độ Count trước khi Block, và luôn bật logging để biết mình đang bị gì. Bảo mật không phải một công tắc — nó là nhiều lớp cùng phối hợp, và code an toàn vẫn là nền tảng cuối cùng.