Traffic Mirroring là một tính năng của Amazon Virtual Private Cloud (VPC) cho phép bạn sao chép lưu lượng mạng từ giao diện mạng linh hoạt của một phiên bản Amazon Elastic Compute Cloud (EC2) instance và gửi nó đến một dịch vụ lưu trữ mục tiêu để phân tích. Bạn có thể sử dụng nó để kiểm tra nội dung, theo dõi mối đe dọa, giám sát hiệu suất mạng và khắc phục sự cố. Bằng cách sử dụng traffic mirroring, bạn có thể phân tích các mẫu lưu lượng cụ thể để xác định các “điểm mù” hoặc “điểm tắc nghẽn” có thể gây nguy hiểm giữa các tầng ứng dụng và/hoặc các phiên bản Amazon EC2. VPC Traffic Mirroring cũng hỗ trợ bộ lọc và cắt giảm gói tin, cho phép bạn chỉ trích xuất lưu lượng quan tâm bằng cách sử dụng các công cụ giám sát theo sở thích của bạn.

Trong các bài viết trước đó, Chúng tôi đã nói về cách sử dụng tính năng VPC Traffic Mirroring và Giới thiệu về Traffic Mirroring cho các điểm cuối GWLB như mục tiêu, chúng tôi đã nói về cách sử dụng tính năng VPC Traffic Mirroring và sử dụng AWS Gateway Load Balancer (GWLB) như mục tiêu theo cách tập trung. Trong bài viết này, chúng tôi sẽ xem xét cách bạn có thể sử dụng các tính năng này và xuất các Packet Captures (PCAPs) đến một bucket dịch vụ lưu trữ đơn giản của Amazon (Amazon Simple Storage Service – S3) được tập trung sử dụng Mountpoint cho Amazon S3. Mountpoint cho Amazon S3 được sử dụng để gắn kết bucket tập trung này và truy cập nó như một hệ thống tệp cục bộ, do đó cung cấp hiệu suất truyền thông lưu lượng cao tối ưu trong việc lưu trữ và truy cập PCAPs đã tạo ra. Thiết kế sẽ liên quan đến việc sử dụng AWS GWLB, Nhóm tự động Scaling Amazon EC2, Amazon S3 và VPC Traffic Mirroring. Trước khi triển khai thiết kế này, chúng tôi khuyến nghị xem xét các giới hạn và hạn ngạch của VPC Traffic Mirroring.

Kiến trúc Giải pháp Traffic Mirroring

Giải pháp này tạo ra các phiên Traffic Mirroring liên tục trên các phiên bản EC2 nguồn và chuyển tiếp chúng đến một mục tiêu GWLB. GWLB có một nhóm mục tiêu gồm các phiên bản EC2 trong một Nhóm tự động Scaling thực hiện TCP Dump và xuất PCAPs đến một bucket S3 tập trung. Các nút Agent chụp gói tin theo định kỳ (ví dụ: mỗi 900 giây) và đổ chúng vào bucket S3 được cấu hình làm nơi lưu trữ tập trung.

Giải pháp mẫu của chúng tôi tạo ra các phiên EC2 trong hai tài khoản Spoke khác nhau cho các nguồn và tạo ra phiên sao chép. GWLB tập trung, hệ thống các nút TCP Dump và bucket S3 để lưu trữ PCAPs đặt tại tài khoản Hub. Điều này được hiển thị trong sơ đồ sau (hình 1).

Hình 1: Kiến trúc cho việc Chụp gói tin sử dụng VPC Traffic Mirroring

Triển khai các mô-đun giải pháp

Giải pháp của chúng tôi dựa trên Hashicorp Terraform và bao gồm các mô-đun chính cho các thành phần Traffic Mirroring và GWLB trong tài khoản Hub, các phiên bản EC2 nguồn và điểm cuối GWLB trong các tài khoản Spoke.

Dịch vụ GWLB Endpoint và các Điểm cuối có thể được triển khai theo các mô hình kiến trúc khác nhau:

Phương pháp 1: Cho phép tất cả nguyên tắc và kiểm soát tính năng Chấp nhận. Để đơn giản và tự động hóa, giải pháp của chúng tôi tuân theo phương pháp này. Điều này có thể được thay đổi để yêu cầu chấp nhận thủ công bằng cách cập nhật biến “enable_manual_acceptance” trong terraform.tfvars.

Phương pháp 2: Chỉ cho phép một số nguyên tắc cụ thể (qua biến) và bật Chấp nhận tự động.

Các thành phần trong tài khoản Hub: (Mô-đun: gwlb_target)

Bao gồm GWLB, Dịch vụ GWLB Endpoint, Nhóm tự động Scaling với các agent được cài đặt trên các phiên bản EC2 để thực hiện TCP Dump, và bucket S3 để lưu trữ PCAPs.

Các thành phần trong các tài khoản Spoke: (Mô-đun: ec2_src, tm_session)

Bao gồm các phiên bản EC2 nguồn, các Điểm cuối GWLB và các thành phần Traffic Mirror, như phiên, bộ lọc và quy tắc.

Các bước triển khai

1. Sao chép dự án từ nguồn GitHub.
2. Cập nhật tệp providers.tf với các vai trò Assume cần thiết cho cả tài khoản Hub và Spoke.
3. Cập nhật terraform.tfvars với các giá trị cần thiết.
4. Chạy các lệnh Terraform sau trong cửa sổ dòng lệnh của bạn để triển khai các thành phần cần thiết.

Chuẩn bị thư mục làm việc: terraform init

Kiểm tra xem cấu hình có hợp lệ không: terraform validate

Hiển thị các thay đổi cần thiết theo cấu hình hiện tại: terraform plan

Tạo hoặc cập nhật cơ sở hạ tầng: terraform apply –auto-approve

5. Xác minh việc triển khai thành công của các thành phần (liệt kê như sau) trong các tài khoản Hub và Spoke.

Các thực thể quan trọng được triển khai

• Một mục tiêu Traffic Mirroring cho điểm cuối GWLB (Mục tiêu A) trong VPC Spoke1
• Một mục tiêu Traffic Mirroring cho điểm cuối GWLB (Mục tiêu B) trong VPC Spoke2
• Một bộ lọc Traffic Mirroring với một quy tắc Traffic Mirroring cho lưu lượng TCP vào (Bộ lọc 1) cho điểm cuối GWLB
• Một phiên Traffic Mirroring cho VPC Spoke1 có các thành phần sau:

• Một nguồn Traffic Mirroring
• Một mục tiêu Traffic Mirroring (Mục tiêu A) cho điểm cuối GWLB
• Một bộ lọc Traffic Mirroring (Bộ lọc 1) với một quy tắc Traffic Mirroring cho lưu lượng TCP vào
• Một phiên Traffic Mirroring cho VPC Spoke2 có các thành phần sau:

• Một nguồn Traffic Mirroring
• Một mục tiêu Traffic Mirroring (Mục tiêu B) cho điểm cuối GWLB
• Một bộ lọc Traffic Mirroring (Bộ lọc 1) với một quy tắc Traffic Mirroring cho lưu lượng TCP vào

• GWLB được triển khai trong một VPC Hub với nhiều thiết bị đằng sau một Nhóm tự động Scaling như các mục tiêu. Các mục tiêu có dịch vụ TCP Dump được cài đặt để tạo ra các tệp PCAP (mỗi 15 phút).
• Một bucket S3 tập trung để lưu trữ các tệp PCAP. Chúng tôi gắn kết một bucket S3 bằng cách sử dụng Mountpoint cho Amazon S3 để ghi lại các tệp PCAP được tạo ra. Chi tiết về tính năng mới này được thảo luận ở đây.

Xem các tệp PCAP

Sau khi bạn đã triển khai các thành phần, các phiên Traffic Mirroring (tài khoản Spoke) sẽ bắt đầu sao chép lưu lượng và các mục tiêu sẽ chuyển tiếp nó đến Dịch vụ Điểm cuối (tài khoản Hub), như được hiển thị trong các ảnh chụp màn hình sau (hình 2 và 3).

Hình 2: Các phiên Traffic Mirroring được tạo trong tài khoản Spoke

Hình 3: Các mục tiêu Traffic Mirroring trong tài khoản Hub

Bây giờ, đăng nhập vào tài khoản Hub nơi bạn triển khai các agent TCP Dump và xác minh việc tạo ra PCAP. Các dịch vụ sau đây nên ở trạng thái chạy:

trafficmirror-tcpdump.service: Dịch vụ thực hiện hoạt động TCP Dump và tạo ra PCAP mỗi 900 giây (có thể cấu hình trong run_tcpdump.sh) (hình 4)

systemctl status trafficmirror-tcpdump.service

trafficmirror-svc-alerts.service: Dịch vụ gửi cảnh báo qua email Amazon Simple Notification Service (SNS) nếu dịch vụ TCP Dump gặp sự cố (hình 5)

systemctl status trafficmirror-svc-alerts.service

Hình 5: Trạng thái dịch vụ systemd Traffic Mirror alerts

Bucket S3 tập trung đã được gắn kết vào thư mục packet-captures (hình 6)

Hình 6: S3 Mountpoint trên thư mục ghi nhận gói tin (packet captures)

Thư mục ghi nhận gói tin có một thư mục với ID hiện tại của phiên bản EC2 lưu trữ tất cả các tệp PCAP được tạo ra. Các tệp PCAP được lưu trữ theo định dạng YYYY-MM-DD-HH-MM (hình 7).

Hình 7: Các tệp PCAP được tạo ra được lưu trữ trong thư mục S3 Mountpoint

Các tệp PCAP cũng có sẵn trong bucket S3 được cấu hình (tài khoản Hub), như được hiển thị trong ảnh chụp màn hình sau (hình 8):

Hình 8: Các tệp PCAP được lưu trữ trong bucket Amazon S3

Bạn có thể sử dụng các công cụ như Wireshark để truy cập vào các tệp PCAP này từ Amazon S3 (mà không cần lưu trữ cục bộ) và phân tích chúng.

Dọn dẹp

Để lại các tài nguyên mà bạn không còn cần trong tài khoản AWS của bạn có thể phát sinh các khoản phí. Chạy lệnh sau để xóa cơ sở hạ tầng đã được tạo ra như một phần của việc triển khai giải pháp được thảo luận trong bài viết này:

Huỷ cơ sở hạ tầng: terraform destroy –auto-approve

Kết luận

Trong bài viết này, chúng tôi đã chỉ ra cách thực hiện ghi nhận gói tin dựa trên sự kiện và lưu trữ chúng trong Amazon S3. Chúng tôi cũng tận dụng Mountpoint cho Amazon S3 để tận dụng khả năng thông lượng linh hoạt. Các ghi nhận gói tin được tạo ra có thể được tải xuống và xem bằng cách sử dụng các công cụ của bên thứ ba, như Wireshark, để khắc phục sự cố hoặc xác định các mối đe dọa bảo mật. Kịch bản được thực thi trên các agent được cài đặt trên các phiên bản EC2 có thể được thay đổi để điều chỉnh kích thước gói tin hoặc thực hiện ghi nhận trong một khoảng thời gian nhất định.

Giới thiệu về các tác giả

Ramesh Mathikumar

Ramesh Mathikumar là một Cố vấn Cấp cao trong lĩnh vực Dịch vụ Tài chính Toàn cầu. Anh đã làm việc với các khách hàng trong lĩnh vực Dịch vụ tài chính trong suốt 25 năm qua. Tại AWS, anh giúp khách hàng thành công trong hành trình điện toán đám mây của họ bằng cách triển khai các công nghệ AWS hàng ngày.

Sundar Shanmugam

Sundar Shanmugam là một Kiến trúc sư Hạ tầng Đám mây cấp cao tại AWS, nơi anh giúp khách hàng thiết kế, triển khai các giải pháp có khả năng mở rộng và chịu lỗi, di chuyển các khối công việc và áp dụng các phương pháp DevOps để đảm bảo thành công trên AWS.