возможности применения honeypot-систем как средств обнаружения атак на объекты сетевой инфраструктуры. Общие сведения о honeypotтехнологиях Описание классификации honeypotтехнологий
 Скачать 5.81 Mb.
|
|
Модуль управления honeypot-системой. Роль данного модуля состоит в том, чтобы выполнять запуск и остановку других модулей honeypot-системы. Получая ту или иную команду, данный модуль проверяет запущен ли определенный модуль honeypot-системы, и если он не работает, то производит его запуск. Кроме этого, данный модуль реализовывает возможность подключение злоумышленника через ssh-сессию к компоненту honeypot- системы, реализующему механизм «обмана» злоумышленника, то есть к docker-контейнеру. Для этого модуль управления honeypot-системой переадресовывает весь трафик, идущий на хостовую машину, в docker- контейнер. Также данный модуль honeypot-системы после завершения своей работы производит очистку тех или иных данных, чтобы освобождать системные ресурсы от неактивных или неиспользуемых модулей системы, а также чтобы не нарушать работоспособность хостовой машины. Технология Docker. Данное программное обеспечение позволит управлять (создавать, конфигурировать, удалять, проводить мониторинг) контейнером, который используется в качестве модуля, реализующего механизм «обмана» злоумышленника. Модуль, реализующий механизм «обмана» злоумышленника. Данный модуль представляет собой docker-контейнер. Выбор механизма контейнерной виртуализации для данного модуля обусловлен тем, что контейнер на основе технологии docker может представлять из себя полноценную рабочую систему, что повысить уровень взаимодействие с злоумышленником. В то же время docker-контейнер позволит сэкономить производственные ресурсы, а также обезопасит хостовую систему от 41 компрометации. Также для привлечения внимания злоумышленника в docker- контейнер будут установлены несколько видов сервисов и служб (ssh-сервер, web-сервер и другие). Также контейнер будет иметь ряд уязвимостей, что позволит исследовать действия злоумышленника в режиме реального времени, так как все действия, проводимые с docker-контейнером, будут регистрироваться с помощью модуля обнаружения факта атаки. Модуль обнаружения факта атаки на honeypot-систему. Роль данного модуля состоит в том, чтобы регистрировать все события, связанные с атаками на систему, а также действиями злоумышленника, которые они выполняют в ходе проведения данных атак. Информацией, которая относится к данным событиям, является как обычный сетевой трафик и сетевые соединения, например, ssh-соединение, так и любые попытки авторизации в системе, а также команды и действия, выполняемые злоумышленниками в момент проникновения в систему. Модуль сбора и визуализации данных о действиях злоумышленника. Данный модуль выполняет функции сборщика всей зарегистрированной информации, которая была получена с помощью модуля обнаружена факта атаки на систему. Сбор информации происходит в специально-созданные log-файлы. После сбора всех данных в log-файлы собранная информация централизованно передается в web-интерфейс для дальнейшего анализа. Важно, чтобы данный модуль собирал информацию, которая позволила бы давать представление об IP-адресе злоумышленника, времени, в которое проводилось то или иное действие нарушителя, а также целях злоумышленника (сервисы и службы, на которые производятся атаки). 6.3 Алгоритм работы honeypot-системы Алгоритм работы высокоинтерактивной honeypot-системы представлен на рисунке А1 приложения А, а также в графической части на плакате «Алгоритм работы высокоинтерактивной honeypot-системы». 42 Модуль управления honeypot-системой проверяет не запущен ли модуль, реализующий механизм «обмана» злоумышленника в виде docker- контейнера. Если модуль управления honeypot-системой не находит образ контейнера, он завершает работу всей honeypot-системы. В случае нахождения образа docker-контейнера модуль управления honeypot-системой производит запуск модуля, реализующего механизм «обмана» злоумышленника, тем самым, делая хостовую систему доступной для подключения злоумышленника по определенному порту. Для перенаправления попыток получения доступа к хостовой системе в модуль, реализующий механизм «обмана» злоумышленника, то есть в docker- контейнер, модуль управления honeypot-системой создает правила переадресации входящего трафика и межсетевого экранирования. Далее модуль управления honeypot-системой запускает модуль обнаружения факта атаки. В случаи сетевой или системной активности в docker-контейнере, данный модуль начинает регистрировать все события. Модуль сбора и визуализации данных, который также запускается модулем управления honeypot-системой, собирает всю необходимую информацию. После этого собранная информация передается в web-интерфейс с помощью того же модуля сбора и визуализации данных. После запуска всех модулей компонент управления honeypot-системой ждет ответа от пользователя для завершения работы honeypot-системы. В случае ввода команды по завершению работы, модуль управления honeypot- системой останавливает работу других модулей системы, производит очистку docker-контейнера, а также всех правил переадресации и межсетевого экранирования. В случае же команды перезапуска модуль управления honeypot-системой производит все команды, описанные выше, после чего вновь запускает свою работу и других модулей системы. 43 6.4 Реализация модели высокоинтерактивной honeypot-системы 6.4.1 Описание архитектуры разработанной модели honeypot-системы В ходе выполнения выпускной квалификационной работы была реализована модель высокоинтерактивной honeypot-системы. В качестве хостовой системы выступала ОС Ubuntu 18.04.5 LTS. Архитектура разработанной модели высокоинтерактивной honeypot-системы представлена на рисунке 16. Рисунок 16 – Архитектура модели honeypot-системы Данная модель высокоинтерактивной honeypot-системы соответствует той архитектуре, что была определена в п. 6.2. Модуль управления honeypot-системой представляет собой программу, написанную на языке bash (honeypot.sh). Подсистема очистки реализована внутри данной программы. В роле модуля, реализующего механизм «обмана» злоумышленника, выступает docker-контейнер, созданный на основе чистой ОС Ubuntu 20.04.2. Модуль обнаружения факта атаки на honeypot-cистему представляет собой совокупность утилит tcpdump, docker logs, а также sysdig. 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-адрес, который 54 был присвоен docker-контейнеру, содержался в диапазоне адресов, чаще всего используемом в VPN-технологиях. После запуска docker-контейнера и выполнения его надстроек, honeypot.sh выполнял запуск утилит регистрации событий tcpdump, docker logs, sysdig со сбором данных в log-файлы. После чего скрипт запускал сервисы стека «Loki», настроенные в виде docker-контейнеров. В случае успешного запуска всех модулей и создания правил переадресации данный скрипт выдавал сообщение пользователю об успешном запуске всей honeypot- системы. После чего программа ждала от пользователя соответствующей команды по работе с системой. В случае, если пользователь захочет завершить работу с honeypot-cистемой, он должен ввести соответствующее значение, отвечающее за завершения работы системы, после чего bash-скрипт совершит остановку и очистку docker-контейнера, очистит все правила переадресации, а после закончит свою работу. Если же пользователь введет команду по перезапуску системы, то honeypot.sh выполнит те же команды, что при завершении работы, но при этом запустится заново. В случае, если пользователь введет любую другую команду или выполнить аварийное завершение bash-скрипта honeypot.sh, процесс очистки не произойдет. Полный текст bash-скрипта honeypot.sh представлен в приложении Г. 55 7 Разработка стенда, применяемого для выполнения учебных заданий, по ознакомлению принципа работы учебной модели высокоинтерактивной honeypot-системы 7.1 Состав разрабатываемого стенда На рисунке 17 и в графической части на плакате «Состав виртуального стенда, применяемого для изучения механизмов обнаружения атак на сетевую инфраструктуру» представлен состав виртуального стенда, применяемого для выполнения учебных заданий, по ознакомлению принципа работы учебной модели высокоинтерактивной honeypot-системы. Рисунок 17 - Состав виртуального стенда, применяемого для выполнения учебных заданий, по ознакомлению принципа работы учебной модели высокоинтерактивной honeypot-системы Перечень виртуальных машин, входящих в состав виртуального стенда, включает: виртуальная машина (ВМ) № 1 с установленной гостевой ОС Ubuntu 18.04.5 LTS, являющаяся honeypot-системой; виртуальная машина (ВМ) № 2 с установленной гостевой ОС Kali Linux 2020.4.0, которая предназначена для проведения атак на honeypot- систему и имитации работы злоумышленника. 56 Аппаратная конфигурация виртуальной машины (ВМ) № 1 включает: количество процессоров – 2; объем оперативной памяти – 2 Гбайта; виртуальный жесткий диск, подключаемый с использованием интерфейса SATA. Объем виртуального жесткого диска – 40 Гбайт; привод оптических дисков, подключаемый с использованием интерфейса SATA - 1; объем видеопамяти - 128 Мбайт; общая папка между гостевой и основной ОС. Программная конфигурация виртуальной машины (ВМ) № 1 включает: гостевая ОС - Ubuntu 18.04.5 LTS (разрядность - 64 бита); роль виртуальной машины (ВМ) – honeypot-система. Виртуальная машина (ВМ) № 2: Аппаратная конфигурация виртуальной машины (ВМ) № 2 включает: количество процессоров – 1; объем оперативной памяти – минимальный 1 Гбайт, рекомендуемый 2 Гбайта; виртуальный жесткий диск, подключаемый с использованием интерфейса SATA. Объем виртуального жесткого диска – 20 Гбайт; привод оптических дисков, подключаемый с использованием интерфейса SATA - 1; объем видеопамяти - 128 Мбайт. Программная конфигурация виртуальной машины (ВМ) № 2 включает: гостевая ОС - Kali Linux 2020.4.0 (разрядность - 64 бита); роль ВМ – имитация работы злоумышленника с целью проведения атак на honeypot-систему. 57 7.2 Подготовка виртуального стенда Для развертывания виртуального стенда, применяемого для выполнения учебных заданий, по ознакомлению принципа работы учебной модели высокоинтерактивной honeypot-системы, а также для изучения механизмов обнаружения атак на сетевую инфраструктуру было использовано программное решение в области виртуализации Virtualbox. На базе этой системы были созданы и настроены виртуальные машины, входящие в состав виртуального стенда. Виртуальная машина (ВМ) № 1 с установленной гостевой ОС Ubuntu 18.04.5 LTS, являющаяся honeypot-системой, имела имя «Honeypot-Machine». В качестве хостовой системы honeypot-системы выступала именно гостевая ОС виртуальной машины. Поэтому в данную гостевую ОС Ubuntu 18.04.5 LTS предварительно был установлен набор инструментов и средств, необходимых для работы honeypot-машины. Также были произведены все настройки программных компонентов, являющихся модулями honeypot-системой либо входящих в состав этих модулей или взаимодействующие с ними. Виртуальная машина (ВМ) № 2 с установленной гостевой ОС Kali Linux 2020.4.0, которая предназначена для проведения атак на honeypot-систему и имитации работы злоумышленника, имела имя «Hack-Machine». Для проведения атак на honeypot-систему предварительно были установлены программные средства, позволяющие проводить атаки, а также подготовлены необходимые файлы для проведения атак. В частности, были сформированы словари для атак «Brute force», подготовлены файлы для проведения атак с использованием общедоступных уязвимостей. 58 7.3 Состав учебных заданий по ознакомлению принципа работы учебной модели высокоинтерактивной honeypot-системы Состав учебных заданий, позволяющих изучить работу honeypot- системы, включал: изучение процедуры запуска и первоначальной конфигурации honeypot-системы; изучение принципа работы honeypot-системы при проведении злоумышленником сетевой разведки; изучение принципа работы honeypot-системы при получении злоумышленником доступа к honeypot-системе методом подбора учетных записей; изучение принципа работы honeypot-системы в ходе выполнения злоумышленником действий по сбору и анализу данных в honeypot-системе; изучение принципа работы honeypot-системы в ходе выполнения злоумышленником действий, связанных с закреплением в honeypot-системе методом повышения привилегий пользователя; изучение принципа работы honeypot-системы при получении злоумышленником доступа к honeypot-системе методом эксплуатации общеизвестной уязвимости; изучение принципа работы honeypot-системы в ходе проведения злоумышленником DDoS-атак методом TCP-flood. Состав учебных заданий, позволяющих изучить возможные вектора атак на honeypot-систему, включал: изучение механизма проведения сетевой разведки; изучение механизма получения доступа к объекту сетевой инфраструктуры методом подбора учетных записей; изучение механизма сбора и анализа данных внутри системы после успешной атаки на объект сетевой инфраструктуры; 59 изучение механизма закрепления в системе методом повышения привилегий пользователя; изучение механизма получения доступа к объекту сетевой инфраструктуры методом эксплуатации общеизвестной уязвимости; изучение механизма проведения DDoS-атак методом TCP-flood на объект сетевой инфраструктуры. 60 8 Описание учебных рекомендаций по работе с учебной моделью высокоинтерактивной honeypot-системой Для выполнения учебных заданий с целью изучения механизма обнаружения атак на сетевую инфраструктуру необходимо запустить виртуальную машину, являющуюся honeypot-системой, а также запустить виртуальную машину, имитирующую работу злоумышленника. Для этого необходимо запустить программу Oracle VirtualBox Менеджер. В разделе с виртуальными машинами находится виртуальная машина «Honeypot- Machine». На панели инструментов необходимо нажать кнопку «Запустить». После запуска виртуальной машины «Honeypot-Machine» будет отображаться меню входа в хостовую систему от учетной записи «user» (см. рисунок 18). Рисунок 18 – Меню входа в систему Далее необходимо ввести пароль учетной записи «user» - «P@ssw0rd!». |