Ta đã biết cách AWS định tuyến cho VPC, bây giờ, hãy chuyển qua vấn đề bảo mật mạng, xem cách cấu hình tường lửa trong VPC như thế nào để cho phép và chặn kết nối.
Trong bài này:
- 1. Stateful vs Stateless Firewall
- 2. Network Access Control List (NACL)
- 3. Security Group
- Tài liệu tham khảo
1. Stateful vs Stateless Firewall
Hẳn bạn đọc đã từng nghe đến khái niệm tường lửa (firewall). Đây là một hệ thống bảo mật mạng máy tính, kiểm soát các kết nối đến mạng, định cho phép hoặc chặn các gói tin dựa trên IP nguồn, IP đích, cổng, và giao thức mạng. Chúng có thể được phân thành hai loại: stateful (có lưu trạng thái) và stateless (không lưu trạng thái).
Trong hình minh hoạ, giả sử một máy tính có IP 100.12.34.56 muốn kết nối đến EC2 instance có public IP 98.76.54.32. Nhìn từ phía EC2 instance (cũng là từ phía subnet, VPC), phần Request của kết nối này đi đến, nên gọi là inbound connection, ngược lại, phần Response đi ra, nên gọi là outbound connection. Hai thuật ngữ inbound và outbound sẽ xuất hiện nhiều trong bài này là ở góc độ phía AWS (VPC, subnet hoặc tài nguyên bên trong).
Gói tin đi đến (của Request) gửi từ máy tính sẽ có Source IP 100.12.34.56, Source Port là ephemeral port (cổng tạm thời, được sử dụng trong thời gian ngắn khi thiết lập kết nối), ngẫu nhiên trong khoảng từ 1024 đến 65535 tuỳ hệ điều hành. Destination IP là 98.76.54.32, với Destination Port 443 nếu giao thức là HTTPS, 80 nếu là HTTP.
Gói tin phản hồi (của Response) gửi từ EC2 instance trở lại sẽ có Source và Destination ngược lại, tức lần lượt là 98.76.54.32:443 và 100.12.34.56:1024.
1.1. Stateless Firewall
Như tên gọi, đây là loại tường lửa không lưu trạng thái, xử lý từng gói tin độc lập, nó sẽ coi hai phần Request và Response của cùng kết nối như không liên quan gì đến nhau. Do đó, để kết nối thành công, tại tường lửa, người dùng cần đặt cả inbound rule cho phép Request đi vào, và outbound rule cho phép Response đi ra. Nếu chỉ có inbound rule, EC2 instance vẫn nhận được gói tin và xử lý, nhưng outbound rule sẽ chặn gói tin phản hồi, và đương nhiên máy tính kia sẽ không thể nhận được.
Hiển nhiên, việc phải thiết lập tường minh cả hai rule này làm tăng chi phí và công sức quản lý (thuật ngữ tiếng Anh là management overhead, sẽ gặp rất nhiều khi thi chứng chỉ AWS), do ta cần quản lý cả inbound rule và outbound rule.
Hơn nữa, do không giữ lại trạng thái kết nối trước đó, nên trong Response, tường lửa loại này sẽ không biết Request tương ứng sử dụng ephemeral port nào. Do đó, để gói tin phản hồi có thể đi ra, outbound rule cần phải cho phép toàn bộ dải ephemeral port 1024-65535, làm tăng nguy cơ bảo mật.
1.2. Stateful Firewall
Loại tường lửa này theo dõi và ghi nhớ trạng thái của từng kết nối (Source, Destination IP/Port, cùng với giao thức mạng). Khi một gói tin đi đến được inbound rule cho phép đi vào, nó tự động cho phép gói tin phản hồi (đối ứng Source, Destination) đi ra mà không cần đặt outbound rule tường minh.
Trong ví dụ trên, nếu tạo inbound rule cho phép các gói tin từ Source IP 100.12.34.56, Source Port 1024 qua giao thức HTTPS tới EC2, thì gói tin phản hồi tương ứng (có Destination IP 100.12.34.56, Destination Port 1024) sẽ tự động được phép đi ra.
Không cần tốn công sức quản lý outbound rule tường minh, và ephemeral port nào được sử dụng sẽ được phản hồi đúng, an toàn hơn so với tường lửa không lưu trạng thái.
2. Network Access Control List (NACL)
Trong AWS, NACL là một dạng Stateless Firewall, làm việc với subnet (khác với Security Group làm việc với tài nguyên cụ thể trong subnet). Mỗi subnet chỉ có thể có một NACL, nhưng một NACL có thể dùng cho nhiều subnet. Do chỉ hoạt động với subnet, NACL chỉ kiểm soát dữ liệu vào/ra subnet, không kiểm soát dữ liệu trao đổi giữa các tài nguyên bên trong subnet.
Hình dưới đây mô tả NACL inbound rule cho ví dụ trong mục 1, lọc các kết nối chiều đến subnet.
Trong đó:
- Rule number: số thứ tự đánh giá rule. Khi có nhiều rule áp dụng lên cùng mục tiêu thì rule có số nhỏ nhất sẽ được áp dụng, bỏ qua các rule còn lại.
- Type: hầu hết trường hợp sẽ chọn giao thức kết nối ở đây, cột Protocol bên cạnh sẽ được điền sẵn. Có thể chọn TCP, UDP, ICMP, HTTP, HTTPS, SMPT, FTP, telnet, v.v., và có thể tuỳ chỉnh.
- Port range: cổng lắng nghe tín hiệu. Ví dụ, 443 cho HTTPS, 80 cho HTTP, được điền sẵn. Khi chọn protocol tuỳ chỉnh có thể sửa.
- Source: IP muốn kết nối đến subnet.
- Allow/Deny: chọn cho phép hoặc chặn kết nối đến.
Ở đây, rule 100 cho phép tất cả IP dùng HTTPS kết nối đến subnet qua port 433, rule mặc định * chặn tất cả kết nối đến bất kể giao thức gì (kể cả HTTPS).
Như vậy, với các kết nối HTTPS, có 2 rule áp dụng. Theo quy tắc, ta sẽ áp dụng rule nhỏ hơn (100) cho HTTPS, bỏ qua rule mặc định.
Các kết nối không phải HTTPS sẽ bị chặn.
Để gửi phản hồi trở lại, do NACL là stateless firewall, ta cần đặt outbound rule tương ứng. Ở đây ta cần chọn Type Custom TCP, với Port range 1024-65535 là dải ephemeral port. Vì như đã phân tích, stateless firewall không lưu trạng thái, nên ta không biết Request đến subnet sử dụng cổng nào trong dải cổng đó, nên cần cho phép toàn bộ.
Cấu hình NACL này hoạt động trong trường hợp bên ngoài chủ động kết nối đến subnet, còn nếu subnet chủ động kết nối ra bên ngoài thì sao? Ví dụ, EC2 instance trong subnet gửi Request đến 1.1.1.1 để tải bản cập nhật phần mềm, rồi nhận lại Response từ IP đó, với giao thức HTTPS.
Khi này, Request có Source IP là private IP của EC2 instance (vì NACL hoạt động với subnet, tức sẽ lọc kết nối trước khi đưa tới NAT Gateway hoặc Internet Gateway, nên Source IP sẽ là private IP trong dải CIDR của subnet), Source Port là ephemeral port trong dải 1024-65535, Destination IP là 1.1.1.1, Destination Port là 443 cho HTTPS. Response thì ngược lại.
Do đó, NACL cần cho phép kết nối chiều đi (outbound) đến Internet (0.0.0.0/0), port 443 (listening port của request là 443 của máy chủ 1.1.1.1), và cho phép kết nối chiều về (inbound) từ 0.0.0.0/0, port 1024-65535 (listening port của response là ephemeral port trên EC2 instance trong subnet).
Ta có outbound và inbound rule cho trường hợp này như sau:
# Outbound Rule
Rule number Type Protocol Port range Destination Allow/Deny
100 HTTPS TCP 443 0.0.0.0/0 Allow
* All All All 0.0.0.0/0 Deny
# Inbound Rule
Rule number Type Protocol Port range Source Allow/Deny
100 Custom TCP TCP 1024-65535 0.0.0.0/0 Allow
* All All All 0.0.0.0/0 Deny
Security Group
Khác với NACL, Security Group là một dạng Stateful Firewall, lưu giữ trạng thái kết nối và tự động cho phép Response đi qua nếu Request tương ứng được cho phép. Người dùng chỉ cần quản lý một phía, cũng không phải mở cả dải ephemeral port tường minh, hạn chế bớt các nguy cơ bảo mật.
Hơn nữa, Security Group hoạt động ở cấp độ tài nguyên trong subnet (gán vào Elastic Network Interface của EC2 instance), nên có thể chi tiết hoá tường lửa cho từng instance, hay kiểm soát cả dữ liệu trao đổi giữa các instance. Những việc này NACL không thể thực hiện (do NACL chỉ làm việc với subnet), nên phần lớn trường hợp Security Group được ưa chuộng hơn.
Trở lại ví dụ trong mục 1, ta có thể đặt inbound rule cho Security Group của EC2 instance cho phép kết nối đến qua HTTPS port 443 từ Internet:
Và không cần đặt outbound rule với ephemeral port tương ứng! Lưu ý, trên thực tế vì lý do bảo mật, nên đặt Source càng cụ thể càng tốt, không nên cho phép toàn bộ IP trên Internet (0.0.0.0/0).
Một lợi ích khác của Security Group là hỗ trợ logical reference, cho phép đặt Source (trong inbound rule khi bên ngoài chủ động kết nối đến instance) hay Destination (trong outbound rule khi instance chủ động kết nối ra bên ngoài) là một Security Group khác hoặc chính nó.
Trở lại ví dụ ứng dụng đa tầng trong bài Thiết kế VPC, giả sử các EC2 trong subnet Web có Security Group SG-web, cần kết nối với các EC2 trong subnet App với Security Group SG-app qua TCP (tầng giao diện cần giao tiếp với tầng tính toán), ta có thể đặt inbound rule của SG-app như sau:
# Inbound Rule in SG-app
Type Protocol Port Range Source
Custom TCP TCP 1024-65535 SG-web
Logical reference áp dụng cho tất cả tài nguyên được gán Security Group được tham chiếu. Ở đây inbound rule của SG-app cho phép Source từ SG-web, tức tất cả EC2 trong subnet Web mà được gán SG-web sẽ được phép kết nối đến subnet App, mà không cần chỉ rõ IP (thứ có thể thay đổi về sau). Rõ ràng, tính năng này giúp quản lý ứng dụng dễ dàng hơn.
Tuy nhiên, hạn chế của Security Group là chỉ cho phép Allow, không có Allow là ngầm từ chối, nhưng không cho phép từ chối rõ ràng (explicit deny) kết nối cụ thể.
Do đó, không thể dùng Security Group để chặn kết nối từ các IP (hoặc dải IP) đáng nghi. Trong trường hợp này, hãy dùng NACL như một lớp bảo mật thứ hai.
Tổng kết:
| Security Group | NACL | |
|---|---|---|
| Loại tường lửa | Stateful | Stateless |
| Cấp độ hoạt động | EC2 instance (gắn vào ENI) | Subnet |
| Các trạng thái cho phép | Chỉ Allow |
Cả Allow & Deny |
| Đánh giá rule | Các rule có độ ưu tiên như nhau | Rule nhỏ được ưu tiên |
| Mặc định | Chặn tất cả kết nối | Chặn tất cả kết nối |
| Hỗ trợ logical reference | Có | Không |
Tài liệu tham khảo
Đến đây, tất cả các thành phần cơ bản trong VPC đã được giới thiệu. Hy vọng bạn đọc cảm thấy series bài này hữu ích. Tiếp theo, hãy chuyển sang dịch vụ phổ biến bậc nhất trong AWS: Simple Storage Service (S3).