CC BY
95
УДК 004.056.57 Т.И. Вишневская, О.К. Макаренко
ГРНТИ 81.93.29 МГТУ им. Н.Э. Баумана
ВИРТУАЛЬНАЯ СРЕДА ДЛЯ КОНТРОЛЯ ЗА ДЕЙСТВИЯМИ ПРОГРАММ НА ОПЕРАЦИОННОЙ СИСТЕМЕ LINUX
В работе представлена реализация виртуальной среды для контроля за действиями программ на операционной системе Linux. Даны описания результатов сбора событий запускаемого приложения. Продемонстрирована целесообразность использования данной среды. Описаны возможные сценарии применения среды при анализе программ.
Ключевые слова: информационная безопасность, контроль за действиями программ, модуль безопасности Linux, виртуальная машина.
ТЛ. Vishnevskaya, О.К. Makarenko
Bauman Moscow State Technical University
THE VIRTUAL ENVIRONMENT FOR MONITORING THE ACTIONS OF PROGRAMS ON THE LINUX OS
The paper presents the implementation of a virtual environment for monitoring the actions ofprograms on the Linux operating system. A description of the result of the collection of events of the launched application is given. The expediency of using this medium is demonstrated. Possible scenarios for using the environment in software analysis are described.
Keywords: information security, program control, Linux security module, virtual machine.
Введение
В настоящее время операционная система (ОС) Linux используется не только на домашних компьютерах, но также в различных сетевых устройствах, таких как маршрутизаторы, межсетевые экраны, и т.п. ОС Linux ставится на рабочие станции в офисах и поликлиниках. Определённые дистрибутивы устанавливаются даже на рабочие места в учреждениях Минобороны России. В связи с ростом популярности Linux широко встал вопрос о защищённости данной операционной системы. Вредоносные программы, осуществляющие целевые атаки, атаки нулевого дня, могут распространяться через запускаемые файлы, через скрипты, получаемые по почте или передаваемые на переносных накопителях, через открытые сетевые порты. Антивирусы могут не обнаружить такие программы.
Для анализа действий запускаемых файлов и для оценки уровня риска запускаемого файла используются специально разработанные исследовательские среды на различных операционных системах. В таких исследовательских средах подозрительный файл запускается, собирается информация о его действиях, эта информация анализируется и по ней выносится вердикт, считать ли такой файл безопасным или вредоносным. Существует достаточное количество таких сред на операционной системе Windows, но с Linux таких разработанных и применённых на практике систем крайне мало. Одной из таких сред с Windows является открытая система Cuckoo-Sandbox [1]. Для пользовательского доступа существуют среды от DrWeb и Kaspersky, но в них нет поддержки исполняемых файлов Linux [2]. Для исследования действий файлов на операционной системе Linux существует закрытая система JoeSecurity [3]. Собственными реализациями таких виртуальных сред пользуются компании DrWeb и Kaspersky для анализа файлов и для пополнения собственной антивирусной базы, но полного доступа к виртуальной среде, а также к результатам анализа файлов у пользователя нет. Пользователю же предоставляется только список хеш-сумм файлов, которые по мнению компаний, считаются вредоносными. Такой подход не сможет обеспечить полноценную защиту от атак нулевого дня, а также от вредоносных программ, постоянно меняющих свою структуру [4].
Целью данной работы является создание собственной виртуальной среды, контролирующей действия запускаемой программы, оказывающей на эту программу минимальное влияние, скрывающей своё присутствие в системе от выполняемой программы и обнаруживающей большинство, если не все, действия контролируемой программы.
Реализуемая в данной работе система позволяет пользователю анализировать запускаемые файлы для операционной системе Linux, собирать информацию о действиях процессов, анализировать загруженность эмулируемой системы во время выполнения программы, собирать дампы оперативной памяти для их дальнейшего анализа, выдавать отчёт о произошедших событиях в форма-
Информационные технологии в науке, образовании и управлении те удобном для пользователя.
В данной работе описывается реализованная виртуальная среда, удовлетворяющая вышеизложенным требованиям, для операционной системы Linux.
Виртуальная среда для контроля за действиями программ
Для полноценного запуска приложений в системе необходимо эмулировать всё окружение операционной системы, включая линковщик, различные библиотеки, системные службы, файловую систему, ядро, и т.п. Существующие реализации сред для безопасного исполнения программ (песочницы), устанавливаемые на систему пользователя, могут очень сильно влиять на производительность системы и иметь проблемы эмуляции определённых частей операционных систем.
В операционной системе Linux существует достаточно средств для изолированного запуска приложений, такие как chroot, LXC, WWW, но все они обладают общими недостатками:
- Не эмулируется ядро системы. При запуске приложения, эксплуатирующего уязвимость для получения системных привилегий, может быть изменено ядро системы на которой оно было запущено;
- Нет средства для сбора информации о действиях программы;
- Ограниченный функционал. Можно запускать только определённые приложения, не использующие сторонние библиотеки;
- Сложность настройки. Для запуска приложения, использующего, например, Java, необходимо не только установить всё окружение Java на хостовую машину, но еще и настроить средство виртуализации для того, чтобы оно использовалось при запуске приложения;
- Лёгкость обнаружения. Приложение может узнать, запущено ли оно в каком-либо эмулируемом окружении, или нет, и после этого изменить своё поведение.
Отдельная виртуальная машина, установленная на системе, может решить задачу эмуляции системы практически полностью, т.к. эмуляция происходит, начиная от уровня BIOS и заканчивая уровнем различных пользовательских библиотек. Также преимуществом отдельной виртуальной машины является настройка максимального потребления ресурсов виртуальной машины.
Для использования виртуальной машины в качестве среды для анализа действий файлов необходимо решить следующие задачи:
- разработать алгоритм взаимодействия с хостовой системой,
- разработать алгоритм сбора действий запускаемой программы.
Анализ возможных реализаций модуля для сбора действий программ
Модуль для сбора действий программ является основной частью виртуальной среды для контроля действий. В таблице 1 представлены возможные методы реализации модуля с их преимуществами и недостатками.
Таблица 1. Возможные реализации модуля сбора событий на операционной система Linux
Название метода Преимущества Недостатки
Отладка приложений (strace, autrace) Лёгкость реализации Простота обнаружения
Логгирование действий с помощью syslogd Лёгкость реализации, перехват в пространстве ядра Нет настройки обнаружения конкретных действий от конкретных приложений
Перехват системных вызовов с помощью предзагружаемой библиотеки Полное покрытие системных вызовов, совместимость с любым дистрибутивом Linux Простота обнаружения, метод не будет работать с приложениями, не использующими динамические библиотеки
Перехват системных вызовов с помощью подмены таблицы системных вызовов Полное покрытие системных вызовов При запуске конкретных приложений, специально меняющих таблицу системных вызовов, возможно столкнуться с неработоспособностью системы.
Модуль безопасности LSM (Linux Security Module) Полное покрытие системных вызовов, Сложность обнаружения, Перехват в пространстве ядра Сложность реализации, Возможна несовместимость с другими модулями LSM.
Исходя из таблицы 1, самым надёжным методом реализации является модуль безопасности LSM. LSM расшифровывается как «Linux Security Module», или же «Модуль безопасности Linux». В данной работе принципиально важно, может ли запускаемое приложение изменить своё поведение при обнаружении себя в исследовательской среде, поэтому было решено реализовать модуль сбора событий именно при помощи LSM модулей.
Реализация модуля LSM
В виртуальной среде модуль сбора событий реализован в виде отдельного LSM модуля. Были разработаны собственные обработчики всех LSM вызовов, описанных в документации ядра Linux. Данный модуль включён в сборку ядра операционной системы Linux и установлен на виртуальную систему.
Основная идея модуля сбора событий состоит в том, чтобы записывать информацию о сработавших перехватах, а также дополнительную информацию об объекте и субъекте в некоторый буфер, предоставляя возможность включения или отключения перехвата событий для определённых файлов и/или процессов. Буфер был реализован в виде очереди. Доступ к буферу осуществляется через файл в виртуальной файловой системе. При чтении файла в пользовательское пространство копируется список перехваченных событий, содержащий:
- номер события по порядку,
- время выполнения события,
- описание события,
- объект - в виде полного пути к исполняемому файлу текущего процесса,
- цель события - в зависимости от перехваченного события представляет собой цель, на которую направлено действие,
- дополнительные данные - содержат в себе ID потока, группы, пользователя, а также дополнительные флаги, с которыми был выполнен системный вызов.
В основном функции LSM вызываются до выполнения различных системных вызовов. На вход в функцию LSM подаётся информация о системном вызове, дополнительная информация о системном вызове, текущий процесс, выполнивший системный вызов [5].
Во время работы системы исполняется очень большое количество LSM вызовов. Для получения событий, относящихся конкретно к запущенному приложению, необходимо фильтровать все вызовы функций LSM, оставляя только то, что было вызвано файлом программы.
На рисунке 1 показана схема реализованного алгоритма сбора и фильтрации событий модулем LSM.
Процессы, рождаясь в системе, начинают выполнять код из исполняемого файла только после фактического открытия файла или загрузки его в память. На этом основан алгоритм фильтрации событий конкретно от необходимого исполняемого файла. Процесс, открывший файл, загрузивший его в память, или же выполнивший его, добавляется в список отслеживаемых процессов. Любое событие, которое было выполнено процессом из такого списка, попадает в конечный список событий.
В качестве примера, реализованного перехвата, рассмотрим перехват события «Открытие файла». Перед системным вызовом sys_open вызывается проверка модулем безопасности, вызывается функция
int (*file permission)(struct file *file, int mask).
Для того, чтобы при вызове данной функции, вызвался наш реализованный обработчик, добавляющей информацию о произошедшем действии в список действий, необходимо зарегистрировать свой обработчик в подсистеме LSM. Для этого используется макрос
LSM_HOOK_INIT(file_permission, syshook file permission).
Рис. 1. Алгоритм сбора и фильтрации событий модулем LSM
Рис. 2. Алгоритм отслеживания потомков запущенных процессов
Запускаемые файлы могут создавать другие процессы. Для отслеживания потомков необходимо реализовать добавление потомка при его рождении в список отслеживаемых. При выделении памяти при создании процесса вызывается реализованный обработчик LSM вызова
int (*task_alloc)(struct task_struct *task, unsigned long clone_flags).
Данный обработчик вызывается процессом, который создаёт потомка. В первом аргументе передаётся указатель на выделенную структуру процесса-потомка. Структуру текущего процесса можно получить, используя глобальный макрос current. Был реализован обработчик данного LSM вызова, реализующий алгоритм, показанный на рисунке 2.
Была решена проблема совместимости с другими LSM модулями системы. В пятой версии ядра Linux был добавлен стек вызовов разных модулей LSM [6]. Его суть заключается в том, что во время проверки LSM последовательно вызываются соответствующие функции различных модулей. Реализуемый модуль контроля должен вызываться ранее всех остальных модулей - это настраивается при регистрации модулей в ядре.
Алгоритм запуска приложения в виртуальной среде
Для запуска приложения в виртуальной среде необходимо иметь доступ к хранилищу виртуальной среды. Доступ к хранилищу может осуществляться как посредством удалённого доступа, так и внешними эмулируемыми носителями.
Запуск файла в виртуальной среде ограничен по времени по желанию пользователя. Если необходимо запустить большое, ресурсоёмкое приложение, то время должно быть задано больше. При запуске приложения инициируется таймер, по истечении которого виртуальная машина записывает в файл список собранных событий и восстанавливает своё состояние.
Восстановление виртуальной машины реализовано с помощью функции снимков хранилища, встроенной в систему виртуализации. Восстановление среды необходимо для того, чтобы минимизировать возможный риск потери виртуальной среды от разрушительных действий какого-либо приложения.
На рисунке 2 изображён алгоритм запуска приложения в виртуальной среде.
Начало
Ввод: йп приложения, параметры запуска./ время анализа
Сохранение состояния виртуальной среды
Запуск виртуальной среды с модулем сбора событий
Копирование файла
приложения на виртуальную среду
Запуск приложения в виртуальной среде и инициация таймера
с
Копирование списка
событий в файл
1 г
Г \
Сброс виртуальной среды в
изначальное состояние
Вывод файл со списком
событий
Рис. 3. Общий алгоритм запуска приложений в виртуальной среде
Вывод файла может также осуществляться, используя доступ к хранилищу виртуальной среды. Есть опция вывода файла со списком событий через консольные порты виртуальной машины в определённый файл.
Результаты работы виртуальной среды
В качестве примера анализа на виртуальной среде рассмотрим запуск вредоносной программы, удаляющей все файлы из /home каталога. Код программы приведён в листинге 1.
Данная программа вызовом system вызовет оболочку и запустит в ней команду rm с ключами рекурсивного и принудительного удаления файлов из папки /home. В данной папке могут находится файлы пользователей, начиная от конфигурационных файлов и заканчивая документами. Их потеря может быть критична.
#include "stdlib.h"
int main() {
system("rm -rf /home/*");
}
Листинг 1. Пример вредоносной программы.
Программа была скомпилирована при помощи GCC в запускаемый файл формата ELF и запущена на реализованной виртуальной машине. В таблицах 2, 3 и 4 представлены части списка перехваченных событий, полученные из виртуальной машины.
Таблица 2. Перехваченные события после запуска программы
N PID Событие Объект Цель Дополнительные данные
1 1656 Открытие файла /bin/bash /home/user/hello.elf tid=1656; gid=1000; uid=1000; flags=O LARGEFILE
2 1656 Выделение памяти /bin/bash pages=2 tid=1656; gid=1000; uid=1000;
3 1656 Установка контекста безопасности процесса /bin/bash /home/user/hello.elf tid=1656; gid=1000; uid=1000;
4 1656 Чтение файла /bin/bash /home/user/hello.elf tid=1656; gid=1000; uid=1000; flags=O LARGEFILE
5 1656 Чтение символической ссылки /bin/bash /lib64/ld-linux-x86-64.so.2 tid=1656; gid=1000; uid=1000;
6 1656 Чтение файла /bin/bash /lib/x86_64-linux-gnu/ld-2.24.so tid=1656; gid=1000; uid=1000; flags=O LARGEFILE
7 1656 Установка нового контекста безопасности процесса /home/user/hello.elf /home/user/hello.elf tid=1656; gid=1000; uid=1000;
8 1656 Отображение файла в памяти /home/user/hello.elf /home/user/hello.elf tid=1656; gid=1000; uid=1000; reqprot=PROT READ | PROT EXEC
9 1656 Отображение адреса в памяти /home/user/hello.elf 5601c82ea000 tid=1656; gid=1000; uid=1000;
В таблице 2 можно увидеть момент, когда процесс начал отслеживаться модулем сбора событий - событие открытия файла попало в список событий. После открытия файла процесс вызвал функцию exec, переводя процесс в новое адресное пространство (событие 7) и заменяя имя процесса, оставшегося после создания нового процесса.
После выделения страниц памяти для процесса произошли события открытия файлов и загрузка в память различных динамических библиотек. Рассмотрим события, произошедшие после компоновки (линковки) всех библиотек.
Таблица 3. Перехваченные события после компоновки библиотек
N PID Событие Объект Цель Дополнительные данные
70 1656 Создание процесса /home/user/hello.elf tid= 1656; gid=1000; uid=1000;
71 1656 Выделение памяти /home/user/hello.elf pages=2 tid= 1656; gid=1000; uid=1000;
80 1693 Запуск бинарного файла /home/user/hello.elf /bin/dash tid= 1693; gid=1000; uid=1000; interp=/bin/sh; argv='sh -c rm -rf /home/*'
92 1694 Установка контекста безопасности процесса по бинарному файлу /bin/dash /bin/rm tid=1694; gid=1000; uid=1000;
93 1694 Запуск бинарного файла /bin/dash /bin/rm tid=1694; gid=1000; uid=1000; interp=/bin/rm; argv='rm -rf /home/user'
В таблице 3 можно увидеть моменты создания процессов отслеживаемым приложением. Сначала приложение запустило системную оболочку dash(событие 80). Аргументом запуска является строка «sh -c rm -rf /home/*». Событие 93 показывает запуск самой утилиты rm с аргументами рекурсивного удаления.
Таблица 4. Перехваченные события во время выполнения программы
N PID Событие Объект Цель Дополнительные данные
124 1694 Удаление файла /bin/rm /home/user/Downloads/intel-microcode_3.20180807a.2~deb9u1_amd64.deb tid=1694; gid=1000; uid=1000;
125 1694 Удаление файла /bin/rm /home/user/Downloads/intel-microcode_3.20180425.1~deb9u 1_amd64.deb tid=1694; gid=1000; uid=1000;
126 1694 Удаление файла /bin/rm /home/user/Downloads/iucode-tool 2.1.11 amd64.deb tid=1694; gid=1000; uid=1000;
127 1694 Удаление каталога /bin/rm /home/user/Downloads tid=1694; gid=1000; uid=1000;
128 1694 Удаление файла /bin/rm /home/user/.xsession-errors.old tid=1694; gid=1000; uid=1000;
В таблице 4 можно увидеть события удаления пользовательских файлов, инициированные исследуемой программой.
Таким образом, получив список действий программы из виртуальной среды, пользователь может получить исчерпывающую информацию о действиях программы, не запуская её на собственной системе. Анализ списка событий можно проводить вручную, а также можно реализовать отдельное решение для автоматического анализа получаемых событий.
Заключение
Авторы считают, что в данной работе были достигнуты следующие результаты:
1. Описана виртуальная среда для мониторинга действий подозрительных процессов.
2. В виртуальной среде сохранен основной функционал существующих модулей безопасности.
3. Одним из преимуществ реализованной виртуальной среды является то, что пользователю предоставляется полный контроль над виртуальной машиной во время сбора событий, а также предоставляется файл со списком перехваченных событий в удобном для чтения формате.
4. Данная виртуальная среда уже имеет применение в коммерческой системе анализа и выявления вредоносного ПО.
Литература
1. Бородавкин Д.А. Система вынесения вердиктов по отчетам Cuckoo Sandbox // Решетнев-ские чтения. 2015. № 19. URL: https://cyberleninka.ru/article/n/sistema-vyneseniya-verdiktovpo-otchetam-cuckoo-sandbox (дата обращения: 23.06.2019).
2. Албаков И.Д. Обзор программного обеспечения для компьютерной безопасности в организации // Вестник науки. 2019. Т. 4. № 6 (15). С. 273-275.
3. Rodriguez R.J., Alonso J., Rodriguez Gaston I. Towards the detection of isolation-aware malware // IEEE Latin America Transactions. 2016. Т. 14. № 2. С. 1024-1036.
4. Каракашев А.В., Смирнов Я.Д. Использование ложных информационных систем -перспективное направление защиты информационных систем от атак "нулевого" дня // Известия института инженерной физики. 2018. № 49. С. 91-93. ISSN: 2073-8110
5. Isohara, Takamasa & Takemori, Keisuke & Miyake, Yutaka & Qu, Ning & Perrig, Adrian. LSM-based Secure System Monitoring Using Kernel Protection Schemes. 2010. С. 591-596. 10.1109/ARES.2010.48.
6. LSM: Module stacking for all - URL: https://lwn.net/Articles/786307/ (дата обращения: 20.06.2019)
Сведения об авторах Татьяна Ивановна Вишневская
к.ф.-м.н. доцент
МГТУ им. Н.Э. Баумана, факультет Информатика и системы управления
Россия, г. Москва, 2-я Бауманская ул., д.5, стр.1
Эл. почта: [email protected]
Олег Константинович Макаренко
студент магистратуры
МГТУ им. Н.Э. Баумана, факультет Информатика и системы управления
Россия, г. Москва, 2-я Бауманская ул., д.5, стр.1 Эл. почта: [email protected]
Information about authors
Tatyana Ivanovna Vishnevskaya
Ph.D. Physical and mathematical sciences Associate Professor
Bauman Moscow State Technical University, Department of Computer Science and Control Systems 2nd Baumanskaya St., 5, bld. 1, Moscow, 105005 E-mail: [email protected] Oleg Konstantinovich Makarenko Master's degree student
Bauman Moscow State Technical University, Department of Computer Science and Control Systems 2nd Baumanskaya St., 5, bld. 1, Moscow, 105005 E-mail: [email protected]
УДК 004 С.Н.Гринченко
ГРНТИ 28.23, 28.19.19 Федеральный исследовательский центр «Информатика и
управление» РАН, Институт проблем информатики
О ПРОСТРАНСТВЕННОМ СТРУКТУРИРОВАНИИ ФЕНОМЕНА «ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ»
Опираясь на предложенную ранее автором информатико-кибернетическую модель самоуправляющейся иерархо-сетевой системы Человечества, в рамках которой было введено понятие «че-ловеко-аппаратурной интеллектуальной единицы», последнюю предлагается интерпретировать как феномен «личностного естественно-искусственного интеллекта», вышележащие в системной пространственной иерархии ярусы-сообщества различного характерного размера - как феномен «собственно» искусственного интеллекта сообществ в его функциональном проявлении, а нижележащие ярусы-«точности производственных технологий» различного характерного размера - как формы «субстрата» искусственного интеллекта соответствующих сообществ (т.е. аппаратной основы носителей памяти и алгоритмов).
Ключевые слова: информатико-кибернетическая модель самоуправляющейся иерархо-сетевой системы Человечества, человеко-аппаратурная интеллектуальная единица, личностный естественно-искусственный интеллект, системная пространственная иерархия, феномен искусственного интеллекта, пространственное структурирование искусственного интеллекта, «субстрат» искусственного интеллекта
