Файл: Общие сведения о honeypotтехнологиях Описание классификации honeypotтехнологий.pdf

44
В роле модуля сбора и визуализации данных о действиях злоумышленника выступает система записи в log-файлы, реализованная в скрипте honeypot.sh, а также стек «Loki».
6.4.2 Разработка модуля, реализующего механизм «обмана» злоумышленника
По умолчанию образ docker-контейнера с ОС Ubuntu 20.04.2 LTS не имеет предустановленного программного обеспечения. Поэтому для реализации необходимого механизма «обмана» злоумышленника был собран собственный образ docker-контейнера с помощью написанного Dockerfile.
Полный текст Dockerfile представлен в приложении Б.
За основу собственного образа docker-контейнера был взят контейнер
Ubuntu 20.04.2 LTS. Для имитации работы реальной системы был установлен список пакетов, позволяющий проверять сетевые интерфейсы, проверять доступность удаленных хостов, создавать и редактировать файлы.
Кроме этого, для того, чтобы злоумышленник мог подключаться к honeypot-системе через ssh-соединение, как было описано в п. 6.2, в docker- контейнере был развернут ssh-сервер. Так, был установлен набор программ, позволяющих производить подключения с использованием протокола SSH, в
Dockerfile была прописана команда по запуску ssh-cервера и команда, которая передавала docker-контейнеру использовать 22 порт для подключения по SSH.
Также в Dockerfile была прописана команда, которая позволяла в дальнейшем собирать данные о всех ssh-подключениях к контейнеру.
Для привлечения внимание злоумышленника в образе docker- контейнера также был развернут web-сервер «Apache httd» на 80 порту, а также сервер «Apache Tomcat» на 8080 порту. Данный сервер «Apache Tomcat» был установлен с уязвимой версией 9.0.27, которая имела общеизвестную уязвимость CVE-2020-9484.

45
По умолчанию все docker-контейнеры создаются в сети 172.17.0.1/16.
Такой диапазон может дать понять злоумышленнику, что он работает с не настоящей системой. Поэтому с помощью специального файла для docker- контейнеров «daemon.json» был указан диапазон адресов 192.168.0.150/25, в котором выдавался IP-адрес docker-контейнеру, начиная с первого свободного в указанной подсети. Выбор такого диапазона адресов обусловлен тем, что он похож на те, что назначаются для внутренних сегментов сетевой инфраструктуры. Таким образом, docker-контейнер имел IP-адрес
192.168.0.129.
Также по умолчанию все docker-контейнеры запускаются от учетной записи суперпользователя. Такая процедура запуска не подходила для реализации модели высокоинтерактивной honeypot-системы, поэтому через команды в Dockerfile собственный docker-контейнер запускался от имени учетной записи пользователя «user». Кроме этого, для учетной записи пользователя «user» был установлен пароль «qwerty123». Такой слабый пароль был установлен для того, чтобы обмануть злоумышленника и дать ему возможность попасть в docker-контейнер. Кроме этого, пользователь «user» состоял только в группе «user», то есть не имел прав суперпользователя.
В рамках изучения поведения злоумышленника после получения им доступа к учебной модели honeypot-системы в docker-контейнер был установлен пакет предоставления пользователям частичных привилегий суперпользователя «sudo» версии 1.8.31. Данная версия программы имела общедоступную уязвимость CVE-2021-3156, которая в свою очередь позволяла пользователю без прав суперпользователя повысить свои привилегии. Данный пакет был установлен только в рамках изучения работы учебной модели высокоинтерактивной honeypot-системы.
Таким образом разработанный модуль, реализующий механизм
«обмана» злоумышленника, позволит отследить поведение злоумышленника на всех этапах проведения атак на honeypot-систему, в том числе на этапе закрепления в системе.

46 6.4.3 Разработка модуля обнаружения факта атаки на honeypot-систему
Как было описано в п. 6.4, в качестве модуля обнаружена факта атаки на разрабатываемую высокоинтерактивную honeypot-систему использовалась совокупность утилит tcpdump, docker logs и sysdig. Данный набор средств запускался в хостовой системе.
Утилита tcpdump, позволяла регистрировать события, связанные с входящим сетевым трафиком, относящийся к docker-контейнеру, выступающему в роле модуля, реализующего механизм «обмана» злоумышленника. Для того, чтобы в дальнейшем было удобнее анализировать собранный трафик, tcpdump запускался с несколькими ключами. Данные ключи позволяли:
 регистрировать трафика с определенного IP-адреса;
 отображать IP-адрес вместо имени хоста;
 отображать номер порта;
 выводить минимум информации (имя протокола, отправитель и получатель сетевого пакета, порты и количество переданных данных);
В результате использования ключей команда по запуску утилиты tcpdump для регистрации событий, связанных с сетевым трафиком, имела следующий вид: sudo tcpdump dst ${CONTAINER_IP} -n -nn –q –t где CONTAINER_IP – IP-адрес docker-контейнера.
Для регистрации событий, связанных с сетевыми соединениями к honeypot-системе, а также попытками авторизации в honeypot-системе, использовалась утилита docker logs. Команда по запуску утилиты docker logs выглядела следующим образом: sudo docker logs -f ${CONTAINER_NAME} где CONTAINER_NAME – имя используемого docker-контейнера в качестве модуля.

47
Для регистрации событий, связанных с чтением, записью и изменением прав доступа к файлам и директориям, использовался инструмент для отслеживания системной активности – sysdig [17]. В частности, использовались специально-созданные для работы инструмента sysdig скрипты chisels, написанные на языке lua. Так, применялись следующие скрипты chisels:
 echo_fds – скрипт, отслеживающий данные, которые читаются и записываются тем или иным процессом;
 spy_users – скрипт, который отлеживает все команды, выполняемые тем или иным пользователем в интерактивном режиме (например, из bash);
 spy_file – скрипт, который отслеживает все операции чтения и записи файлов в той или иной системе.
В результате команды по запуску утилиты sysdig вместе с скриптами chisels выглядели следующим образом: sudo sysdig
-pc
-A
-c echo_fds container.name=${CONTAINER_NAME} and proc.name=sshd and
"evt.is_io_read=true and not fd.type contains pipe and not fd.name contains /" sudo sysdig
-pc
-A
-c
/usr/share/sysdig/chisels/spy_users container.name=${CONTAINER_NAME}
"and not fd.name contains /usr/local/tomcat/ and not fd.name contains
/usr/bin/" sudo sysdig
-pc
-A
-c
/usr/share/sysdig/chisels/spy_file container.name=${CONTAINER_NAME}
"and not fd.name contains /lib/x86_64-linux-gnu/ and not fd.name contains
/dev/null and not fd.name contains /usr/share/nano/ and not fd.name contains /etc/nsswitch.conf and not fd.name contains /lib/terminfo/x/ and not fd.name contains

48
/usr/lib/ssl/ and not fd.name contains /etc/ssh and not fd.name contains /usr/local/tomcat/ and not fd.name contains
/dev/urandom and not fd.name contains
/usr/lib/jvm/ and not fd.name contains /etc/localtime and not fd.name contains /usr/local/tomcat/ and not fd.name contains
/etc/apache2/ and not fd.name contains
/proc/filesystems and not fd.name contains /etc/gai.conf and not fd.name contains /proc/self/ and not fd.name contains /usr/lib/apache2/ and not fd.name contains
/proc/self/ and not fd.name contains /sys/fs/ and not fd.name contains /proc/net/ and not fd.name contains
/etc/resolv.conf and not fd.name contains /proc/sys/ and not fd.name contains /sys/devices/ and not fd.name contains
/etc/timezone and not fd.name contains
/usr/bin/which and not fd.name contains /etc/group and not fd.name contains /etc/host.conf and not fd.name contains etc/resolv.conf and not fd.name contains
/dev/random and not fd.name contains /etc/mime.types and not fd.name contains /etc/nanorc" где CONTAINER_NAME – имя используемого docker-контейнера в качестве модуля, реализующего механизм «обмана» злоумышленника.
6.4.4 Разработка модуля сбора и визуализации данных о действиях злоумышленника
Для сбора данных о действиях злоумышленника использовались специально-созданные log-файлы, куда сохранялась вся зарегистрированная информация с помощью утилит tcpdump, docker logs и sysdig. Данные файлы располагались в специально-созданной директории на хостовой машине
/var/log/honeypot.

49
По умолчанию утилита tcpdump имеет возможность сохранять собранные данные в файл только формата «pcap». Данный формат файлов не позволяет читать и анализировать данные в формате, удобному обычному пользователю. Поэтому всю зарегистрированную информацию с помощью tcpdump было решено сохранять в файл с помощью механизма перенаправление ввода-вывода Linux. Команда по запуску tcpdump c сохранением информации log-файл выполнялась в bash-скрипте «honeypot.sh»
(в модуле управления honeypot-системой) и имела следующий вид: sudo tcpdump dst ${CONTAINER_IP} -n -nn -q >
/var/log/honeypot/docker_net.log 2>&1 &> где /var/log/honeypot/docker_net.log – log-файл, куда сохранялась вся информация, связанная с сетевым трафиком docker-контейнера.
Для сохранения полученной информации с помощью docker logs был также использован механизм перенаправления ввода-вывода Linux. Команда по сохранению информации, регистрируемой docker logs, в log-файл выглядела следующим образом: sudo docker logs -f -t ${CONTAINER_NAME} >
/var/log/honeypot/docker_logs.log 2>&1 & где /var/log/honeypot/docker_logs.log – имя файла, куда сохранялась информация, связанная c сетевыми соединениями к honeypot- системе и попытками авторизации в системе.
Также, как и утилита tcpdump, инструмент sysdig по умолчанию имеет возможность сохранения данных в файл только формата «scap», который обычный пользователь не может прочитать. Поэтому для сбора информации в log-файлы скрипты chisels были изменены таким образом, что все данные и операции, которые эти скрипты отслеживали в ходе своей работы, сохранялись в эти файлы. Помимо этого, и сам вывод данных, который производили данные «chisels», был отредактирован. Так, для вывода скрипта chisels «spy_users» были добавлены строки, которые давали представление об

50
выполняемой команде в системе. Для скрипта chisels «spy_file» была добавлена строка, которая давала представление об выполненной операции.
Скрипт chisels «echo_fds» применялся для регистрации событий, связанных с вводом злоумышленником какой-либо информации при получении доступа к honeypot-системе. В частности, данный скрипт отлеживал все пароли, которые злоумышленник вводил при получении доступа через ssh-соединение. Однако chisels «echo_fds» собирал большее количество мусора в связи со спецификой своей работы, поэтому помимо обычного сохранения данных в log-файл, который осуществлялся при запуске инструмента sysdig вместе с chisels «echo_fds», использовалась утилита sed.
Данная утилита позволяла убирать мусор, который хранился в log-файле, и оставлять только ту информацию, которая давала понятие об вводимых злоумышленником паролей.
В результате описанных выше всех дополнительных настроек команды по запуску утилиты sysdig вместе с скриптом chisels «echo_fds» выглядела следующим образом: sudo sysdig
-pc
-A
-c echo_fds container.name=${CONTAINER_NAME} and proc.name=sshd and
"evt.is_io_read=true and not fd.type contains pipe and not fd.name contains
/"
>
/var/log/honeypot/password_garbage.log && sed -i '/^$/d'
/var/log/honeypot/password_garbage.log
&& sed
-rni
'/^.{4,10}$/p' /var/log/honeypot/password_garbage.log && sed
-i
'/eth\|%\|+/d'
/var/log/honeypot/password_garbage.log
&& sed
-i
's/^/ENTER_PASSWORD
/'
/var/log/honeypot/password_garbage.log
&& cp
/var/log/honeypot/password_garbage.log
/var/log/honeypot/password_${CONTAINER_NAME}.log 2>&1 &

51
где /var/log/honeypot/password_garbage.log – имя файла, где хранилась зарегистрированная информация, позволяющая отследить вводимые злоумышленником пароли при получении доступа к honeypot- cистеме, /var/log/honeypot/password_${CONTAINER_NAME}.log
– имя файла, где хранилась обработанная утилитой sed информация.
Команды по запуску всех утилит, связанных с регистрацией событий и сбором данных в log-файлы, были прописаны в bash-скрипте «honeypot.sh».
Для централизованного сбора всех данных, которые хранились в log- файлах, использовался, как было описано в п. 6.4, стек «Loki» [18]. Данный стек является общедоступным и представляет из себя совокупность средства хранения собранных данных (Loki), элемента обработки данных, отправляющего входящие данные в Loki (Promtail), а также web-интерфейса для визуализации и анализа собранных данных (Grafana).
Так, инструмент Promtail собирал все данные из log-файлов, передавал их в Loki, который выполнял хранение собранных данных и передавал в web- интерфейс Grafana. Инструмент Grafana в свою очередь выводил все данные в своей информационной панели, где можно было отследить каждое зарегистрированное событие, связанное с honeypot-системой.
Для работы с данным набором программных средств была произведена их установка и настройка на хостовой системе в виде docker-контейнеров. Все docker-контейнеры используемых сервисов запускались с помощью специально созданного файла «loki-stask.yml». Данный файл представлен в приложении В.
Кроме этого, был разработан собственный файл конфигурации программы Promtail, который собирал все данные из log-файлов, находившихся в директории /var/log/honeypot. Файл конфигурации приложения «Promtail» представлен в приложении В. В результате команда по запуску все сервисов стека «Loki» имела следующий вид: docker-compose –f loki-stask.yml up

52
Данная команда по запуску выше описанных сервисов была прописана в bash-скрипте «honeypot.sh».
6.4.5 Разработка модуля управления honeypot-системой
Как было описано в п. 6.4, модуль управления honeypot-системой представляет собой bash-скрипт honeypot.sh. Основными функциями данного скрипта являлись:
 определение внешнего сетевого интерфейса хостовой системы;
 запуск docker-контейнера;
 перенаправление трафика из хостовой системы в docker-контейнер;
 запуск утилиты регистрации событий со сбором данных в log-файлы;
 запуск стека «Loki» для анализа и визуализации данных из log-файлов;
 остановка всех модулей honeypot-системы при завершении работы данной программы;
 очистка docker-образа, log-файлов и правил перенаправления после завершения своей работы.
Для определения внешнего сетевого интерфейса хостовой системы использовались стандартные утилиты ОС Linux, позволяющие получить список сетевых интерфейсов системы. Далее скрипт выводил информацию о доступных сетевых интерфейсах системы, а также выводил сообщение о выборе пользователем внешнего сетевого интерфейса хостовой системы.
После ввода пользователем внешнего интерфейса из предложенного списка введенная информация записывалась в переменную, отвечающую за внешний сетевой интерфейс хостовой системы.
Проверка наличия образа контейнера осуществлялась через стандартные средства управления docker-образами. С помощью этих же средств проводилась проверка на наличие незапущенного docker-контейнера. В обоих случаях, если проверки давали ложный результат, для пользователя выводилось сообщение в оболочке терминала OC Linux. После проведенных

53
проверок выполнялся запуск docker-контейнера через стандартные команды запуска контейнеров.
Для осуществления перенаправление сетевого трафика из хостовой системы в docker-контейнеры использовалась утилита iptables. Так, для перенаправления трафика в скрипте honeypot.sh использовались следующие команды: iptables -A FORWARD -p tcp -d ${CONTAINER_IP} -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A PREROUTING -i ${EXIT_INTERFACE} - p tcp -d ${HOST_NAME} -j DNAT --to-destination
${CONTAINER_IP} где CONTAINER_IP – IP-адрес docker-контейнера, EXIT_INTERFACE - внешний интерфейс хостовой системы, HOST_NAME - внешний IP-адрес хостовой системы.
Первая команда создавала новое правило в цепочке FORWARD
(цепочка приходящих пакетов) для сетевого протокола TCP, которое разрешало принимать приходящие пакеты на IP-адрес docker-контейнера с проверкой состояний соединений.
Вторая команда создавала новое правило в цепочке PREROUTING
(цепочка изменения входящих пакетов, устанавливающая новое соединение) для сетевого протокола TCP, которое подменяло адрес хостовой системы на адрес docker-контейнера для всех входящих пакетов.
В результате с помощью этих правил весь трафик направлялся в docker- контейнер, выступающий в роле модуля, реализующего механизм «обмана» злоумышленника.
Далее для увеличения вероятности обмана злоумышленника скрипт honeypot.sh добавлял еще один сетевой интерфейс в docker-контейнер c IP- адресом 10.10.3.3/24. Для этого было использовано общедоступное программное обеспечение pipework [19]. Данный адрес позволял сделать honeypot-систему еще более похожую на реальную, так как IP-адрес, который