Mơi trường Sandbox (SE)

Một phần của tài liệu Nghiên cứu xây dựng hệ thống VSandbox trong phân tích và phát hiện mã độc IoT Botnet. (Trang 70 - 73)

6. Bố cục của luận án

2.2. Các thành phần chính

2.2.3. Mơi trường Sandbox (SE)

IoT Botnet được xây dựng để chạy trên nhiều kiến trúc CPU khác nhau để phù hợp với sự đa dạng của các thiết bị IoT. Để cĩ thể chạy và phân tích IoT Botnet trên các kiến trúc CPU khác nhau trong mơi trường mơ phỏng, nghiên cứu sinh đã chọn sử dụng QEMU [83]. Dự án mã nguồn mở QEMU hỗ trợ nhiều kiến trúc CPU như ARM, MIPS, PowerPC, SPARC,… Bên trong mỗi mơi trường Sandbox SE sẽ sử dụng bản ảnh Debian dựng sẵn của Aurel [82] với máy chủ QEMU, các tác tử quản lý, giám sát và thu thập các hành vi tệp ELF được thực thi (minh họa trong Hình 2.6). Các tham số cấu hình để khởi chạy máy chủ QEMU, được đọc từ tệp “Configuration file”. Khối

Giả lập máy chủ C&C (C&C simulator) sử dụng các địa chỉ IP này để tạo kết nối giữa máy chủ QEMU và máy chủ C&C mơ phỏng. Tên tệp và đường dẫn của thư viện liên kết động được sử dụng để thêm các thư viện bị thiếu từ cơ sở dữ liệu thư viện liên kết động vào bản ảnh Debian. Máy chủ QEMU được khởi chạy với các tham số cấu hình được minh họa như trong Hình 2.7.

Hình 2.6 Kiến trúc bên trong SE

Hình 2.7 Lệnh khởi động mơi trường SE

Các tác tử (agents) được viết bằng ngơn ngữ C và được biên dịch chéo (cross- compiled) bởi Toolchains [84] cho các kiến trúc CPU tương ứng. Verma [85] đã trình bày cách sử dụng Toolchains để tạo các ứng dụng chạy trên các thiết bị IoT với các kiến trúc CPU khác nhau. Với các đặc trưng của IoT botnet được trình bày trong Chương 1 của luận án, mơi trường SE sẽ được tích hợp với các cơng cụ để giám sát các hành vi của mã độc, bao gồm các lời gọi hệ thống, hoạt động liên quan tới tệp và thư mục, hiệu năng máy chủ, yêu cầu thư viện liên kết động và hành vi mạng. Trong mơi trường SE, để thu thập các thơng tin kể trên nghiên cứu sinh tích hợp các tác tử, bao gồm:

- Controller agent: quản lý các tác vụ chung của các tác tử thu thập thơng tin, kích hoạt thực thi tệp ELF, nhận và truyền thơng tin được thu thập đến khối RDP.

- File agent: thu thập các hành vi liên quan đến tệp và thư mục (dựa trên cơng cụ

“lsof” [86]). Nghiên cứu sinh đã chọn sử dụng cơng cụ “lsof” để theo dõi sự tương tác với các tệp và thư mục của các tệp ELF vì hai lý do. Thứ nhất, cơng cụ này hiệu quả trong giám sát các tập tin đang được truy cập bởi các tiến trình. Ngồi ra, “lsof” cĩ thể

sử dụng trên nhiều kiến trúc CPU khác nhau vì được tích hợp sẵn vào Kernel Linux. - Host performance agent: thu thập các hành vi liên quan đến việc sử dụng tài

nguyên hệ thống, chẳng hạn như CPU, RAM (dựa trên cơng cụ “top” [87]). Để theo dõi hiệu năng của máy chủ, cĩ nhiều cơng cụ khác nhau như “top”, “iostat”, “mpstat”, … Tuy nhiên, trong đĩ cơng cụ “top” phù hợp hơn cho vấn đề này. Cơng cụ này cung cấp

khả năng giám sát thời gian thực của một hệ thống đang chạy, hoạt động của các tiến trình.

- SystemCall agent: thu thập lời gọi hệ thống của tệp ELF (dựa trên cơng cụ “strace” [88]). Để hiểu rõ hơn về hành vi của tệp ELF khi được thực thi, thơng tin hữu

ích nhất là các lời gọi hệ thống của chính nĩ. Trong Linux, cĩ nhiều cơng cụ hỗ trợ thu thập lời gọi hệ thống của một tệp thực thi (như “ftrace”, “ptrace”,…) nhưng về cơ bản hoạt động như cơng cụ “strace”. Strace theo dõi các lời gọi hệ thống và hữu ích khi khơng cĩ mã nguồn và muốn phân tích chương trình bằng cách thực thi. Trong IoT Sandbox Limon, Monnappa [52] đã sử dụng Strace để theo dõi các lời gọi hệ thống.

- Shared library requirement agent: khi xây dựng danh sách các thư viện liên kết động ngồi sử dụng “readelf” (trong khối EMF), nghiên cứu sinh cịn sử dụng cơng cụ “ldd” [89]. Cơng cụ “ldd” liệt kê các thư viện liên kết động theo yêu cầu của từng chương trình thực thi. Khơng giống như cơng cụ “readelf” trong khối EMF

(phần III-

B) chỉ phân tích nội dung tệp ELF tĩnh để xác định thư viện liên kết động, “ldd” giám sát tệp ELF ngay trong mơi trường SE để xác định các thư viện liên kết động theo yêu cầu của ELF. Điều này mang lại hiệu quả cao hơn cho việc xác định các thư viện liên kết động và đã được chứng minh bằng thực nghiệm trên Dataset của nghiên cứu sinh khi so sánh với các IoT Sandbox khác (như LiSa [51], Cuckoo [49]). Kết quả của danh sách các thư viện liên kết động xác định bởi “ldd” và “readelf” được minh họa như trong Hình 2.8 và Hình 2.9 (lưu ý rằng ldd xác định thêm hai thư viện được chia sẻ là

libc.so.6 và ld-uClibc.so.0 và đường dẫn thư mục đầy đủ hơn sử dụng readelf).

- Network agent: thu thập hành vi mạng của tệp ELF (dựa trên cơng cụ

“TCPdump” [90]). Một trong những hành vi quan trọng của IoT Botnet là kết nối với

mạng Bot và nhận lệnh từ Bot master (máy chủ C&C) - đây là những hành vi mạng điển hình của IoT Botnet. Vì vậy, Network agent được xây dựng để thu thập hành vi mạng của tệp ELF đầu vào bằng cơng cụ “TCPdump”, đây là một cơng cụ đơn giản giúp thu thập và đọc lưu lượng mạng. Cơng cụ này đã được sử dụng nhiều trong xây dựng hệ thống phát hiện xâm nhập mạng (NIDS) [91–93].

Hình 2.8 Thơng tin thư viện liên kết động xác định bởi ldd

Hình 2.9 Thơng tin thư viện liên kết động xác định bởi readelf

Một phần của tài liệu Nghiên cứu xây dựng hệ thống VSandbox trong phân tích và phát hiện mã độc IoT Botnet. (Trang 70 - 73)

Tải bản đầy đủ (DOC)

(143 trang)
w