Công nghệ ảo hóa – một khái niệm đã quá quen thuộc và gần như gắn liền với công việc của các quản trị viên hệ thống công nghệ thông tin. Đây là công nghệ giúp cho quản trị viên dễ dàng hơn trong việc thiết lập quản trị máy chủ, tối ưu hóa việc vận hành hệ thống. Với các doanh nghiệp có sử dụng giải pháp ảo hóa, an toàn thông tin có lẽ là yếu tố cần đặt lên hàng đầu do tính chất giải pháp là nền tảng cho toàn bộ các máy chủ, dịch vụ hoạt động trên nó. Đặt giả sử hệ thống ảo hóa bị tấn công và bị chiếm quyền điều khiển, kẻ tấn công có thể thực hiện các hành vi tấn công và cụ thể nhất có lẽ là hành vi phá hoại (https://attack.mitre.org/tactics/TA0040/) . Chỉ với một vài thao tác, kẻ tấn công có thể thêm, sửa, xóa, bật hay tắt các máy chủ bao gồm các dịch vụ quan trọng đang chạy trên hệ thống. Trường hợp này rõ ràng là không ai mong muốn, từ quản trị viên hệ thống đến chủ doanh nghiệp có các dịch vụ quan trọng yêu cầu tính chất hoạt động gần như liên tục, có tập người dùng lớn. Vậy với góc độ về kỹ thuật, ta có thể làm gì để giảm thiểu khả năng hệ thống bị tấn công cũng như phát hiện các dấu hiệu tấn công sớm nhất có thể. Nội dung bài viết này sẽ cung cấp thông tin về một số kịch bản và các khuyến nghị phòng chống tấn công với hạ tầng ảo hóa khá phổ biến – Vmware vSphere.

VMware vSphere là gì?

VMware vSphere là nền tảng ảo hóa của Vmware, giúp chuyển đổi các trung tâm dữ liệu thành một hạ tầng điện toán tổng hợp bao gồm các loại tài nguyên như CPU, storage hay network. vSphere cho phép quản lý hạ tầng công nghệ thông tin một cách thống nhất, cung cấp cho quản trị viên các công cụ để quản trị trong môi trường.

Sơ đồ hoạt động của vSphere

Hai thành phần chính trong giải pháp vSphere là ESXi và vCenter Server. ESXi là nền tảng ảo hóa nơi quản trị viên tạo và chạy các máy ảo cũng như thiết bị ảo. vCenter Server là dịch vụ thông qua đó cho phép quản lý nhiều máy chủ được kết nối trong mạng và nhóm tài nguyên máy chủ.

Chi tiết xem thêm tại https://docs.vmware.com/en/VMware-vSphere/index.html

Một số kịch bản phát hiện tấn công

Với vSphere, người dùng truy cập vào ứng dụng dịch vụ/console chủ yếu là các quản trị viên hệ thống với số lượng không lớn. Do vậy việc chuẩn hóa luồng truy cập vào hệ thống là đặc biệt cần thiết. Trong nội dung bài viết này, chúng tôi đưa ra một số test case liên quan tới hành vi đăng nhập của quản trị viên hệ thống vào 2 thành phần chính của vSphere là ESXi và vCenter.

Điều kiện đầu vào:

• Danh sách người dùng có quyền truy cập trên hệ thống (web, console)
• Danh sách source ip được phép truy cập vào hệ thống (web, console): thường liên quan tới dải ip của quản trị viên, Jump Server.

No	Testcase	Description
1	Đăng nhập giao diện vSphere Client trên trình duyệt từ địa chỉ ip không hợp lệ.	Thông thường hệ thống vSphere client để quản trị sẽ chỉ được truy cập từ một số source ip nhất định hoặc dải ip thuộc team quản trị.
2	Đăng nhập giao diện ESXi trên trình duyệt từ địa chỉ ip không hợp lệ.	Thông thường dịch vụ ESXi để quản trị sẽ chỉ được truy cập từ một số source ip nhất định hoặc dải ip thuộc team quản trị.
3	Đăng nhập SSH vào ESXi Server từ địa chỉ ip không hợp lệ	Thông thường ESXi Server để quản trị sẽ chỉ được truy cập từ một số source ip nhất định hoặc dải ip thuộc team quản trị.
4	Đăng nhập SSH vào vCenter Server từ địa chỉ ip không hợp lệ	Thông thường hệ thống vCenter Server để quản trị sẽ chỉ được truy cập từ một số source ip nhất định hoặc dải ip thuộc team quản trị.
5	Thay đổi cấu hình dịch vụ ssh cho phép truy cập SSH vào ESXi Server	Việc thay đổi cấu hình có thể cho phép kẻ tấn công truy cập ssh vào ESXi Server

Chi Tiết

Kịch bản 1: Đăng nhập giao diện vSphere client trên trình duyệt từ địa chỉ ip không hợp lệ

Truy cập vào địa chỉ của vcenter trên trình duyệt và tiến hành đăng nhập.

Trên giao diện vSphere client, chọn Inventory > Hosts and Clusters. Chọn cluster cần check. Click chọn Monitor > Tasks and Events > Events.

Tại đây, sau khi kiểm tra sẽ check được thông tin tài khoản đăng nhập cùng địa chỉ ip nguồn.

Trên consle, đường dẫn log được lưu tại file: /var/log/vmware/sso/websso.log

Kịch bản 2: Đăng nhập giao diện ESXi trên trình duyệt từ địa chỉ ip không hợp lệ.

Truy cập vào địa chỉ của ESXI trên trình duyệt và tiến hành đăng nhập (thêm /ui và sau ip của EXSi server)

Trên giao diện ESXi, truy cập Navigator > Host > Monitor > Events để hiện thị thông tin log đăng nhập.

Trên console, đường dẫn log được lưu tại file: /var/log/hostd.log

Kịch bản 3: Đăng nhập SSH vào ESXi Server từ địa chỉ ip không hợp lệ

Trên giao diện ESXi, truy cập Navigator > Host > Monitor > Logs, chọn file log /var/log/auth.log để hiển thị thông tin đăng nhập qua dịch vụ SSH.

Kịch bản 4: Đăng nhập SSH vào vCenter Server từ địa chỉ ip không hợp lệ

Trên console vCenter Server, truy cập đường dẫn file chứa log của dịch vụ SSH, ví dụ: /var/log/audit/sshinfo.log (đường dẫn này có thể thay đổi phụ thuộc vào cấu hình dịch vụ ssh, rsyslog)

Kịch bản 5: Thay đổi trạng thái dịch vụ ssh cho phép truy cập SSH vào ESXi Server.

Truy cập vSphere client, chọn ESXi host cần thay đổi, chọn Configure > System > Service > SSH. Tại đây chọn start dịch vụ ssh.

Trên giao diện ESXi, truy cập Navigator > Host > Monitor > Logs, chọn file log /var/log/vobd.log:

Log ghi nhận lại trạng thái dịch vụ bị thay đổi:

Kết luận

• Với các kịch bản 1,2,3,4: trong log thu được có xác định các trường quan trọng như source ip address, username. Nhân sự phân tích có thể đối chiếu các thông tin này với danh sách các luồng truy cập hợp lệ (source ip, username) để đưa ra nhận định về tính bất thường của sự kiện.
• Với kịch bản 5: trong log thu được hành vi liên quan tới sự kiện kích hoạt dịch vụ ssh trên máy chủ ESXi. Nhân sự phân tích có thể tìm kiếm theo thông tin của người dùng đăng nhập gần nhất và xác nhận lại hành vi. Trong trường hợp không phải hành vi hợp lệ của người quản trị, tiến hành điều tra để tìm ra nguyên nhân của hành vi này.
• Một cách hiệu quả cho việc giám sát các hành vi này là thu thập các sự kiện trong các file log tương ứng với các hành vi (chi tiết trong từng kịch bản) về một hệ thống SIEM. Từ đây, sau khi tiến hành chuẩn hóa các sự kiện, ta có thể thực hiện cấu hình các tập luật trên hệ thống SIEM dựa theo các kịch bản đã đề ra, mục đích là đưa ra cảnh báo và tiến hành điều tra ngay khi phát hiện một hành vi khả nghi và ngăn chặn sớm cuộc tấn công nếu có.
• Trên đây chỉ là một số kịch bản cơ bản có thể sử dụng cho việc giám sát và điều tra ATTT trên hệ thống vCenter, ESXi. Trên thực tế, số lượng các kịch bản có thể được bổ sung cho quá trình giám sát hệ thống vSphere có thể tăng thêm nhiều hơn. Do vậy, cần cập nhật và update thông tin về các usecase liên tục trong quá trình vận hành và giám sát hệ thống.

Mitigation (Biện pháp giảm thiểu)

Đặt trong tình huống vCenter, ESXi bị tấn công, đặc biệt là tấn công phá hoại như phá hủy tài nguyên của ứng dụng/dịch vụ, mã hóa dữ liệu, ta có thể đưa ra kế hoạch thực hiện một số bước như sau để giảm thiểu khả năng bị ảnh hưởng của hệ thống:

• Hệ thống backup cần tách biệt hoàn toàn(không join domain, không phải là máy ảo thuộc ESXi) nhằm tránh bị ảnh hưởng khi sự cố xảy ra.
• Thiết lập và tuân thủ quy trình truy cập, quản trị các hạ tầng/hệ thống quan trọng (vCenter, ESXi, các máy chủ quan trọng như AD, Mail, …). Chỉ cho phép truy cập mục đích quản trị từ một số whitelist IP (Jump server), sử dụng giải pháp quản lý truy cập PAM  và xem xét áp dụng 2-FA với các xác thực quản trị (ví dụ yêu cầu xác thực 2-FA vào vCenter, 2-FA vào PAM, 2-FA vào các jump server, …).  Thậm chí không dùng chung jump server để quản lý toàn bộ hệ thống mà có thể tách riêng/dành riêng một số jump server chỉ để phục vụ việc truy cập quản trị tới các hệ thống quan trọng so với  các hệ thống khác.
• Rà soát, đánh giá bảo mật , nâng cấp các bản vá bảo mật – đặc biệt chú trọng tới các hệ thống vSphere, Email, AD và các hệ thống ứng dụng Public trên Internet.
• Đối với giám sát: bổ sung thu thập log sources liên quan truy cập/xác thực với hệ thống vCenter, ESXi về SIEM. Thống nhất các tài khoản và các whitelist IP truy cập hợp lệ, từ đó phát hiện các hành vi truy cập/xác thực bất thường.
• Có kế hoạch backup/restore hệ thống một cách thường xuyên để đảm bảo dữ liệu có thể phục hồi nhanh nhất trong trường hợp hệ thống bị tấn công.

 

 

Author: Purple Team