ANTICHAT - Honeypot с нуля: установка, мониторинг и реагирование на инциденты

Автор: n0_mad
Источник: ex. DaMaGeLab

Уровень: Novice + Mid.

Honeypot — опция, предназначенная для отвлечения внимания злоумышленников и анализа их действий внутри вашей инфраструктуры при попытке воздействия на неё. Данная опция важна для выявления уязвимостей, а так же позволяет протестировать системы безопасности и собрать данные об актуальных методах атак на вашу сферу деятельности и корпоративную сеть.

Подготовка.
Для начала необходимо определить тип honeypot.
В основном, выделяются 2 типа:
1. Низкоуровневый(Low-Interaction), эмулирующие ограниченное количество сервисов и служб, не предоставляя полноценное окружение.

Реагирует, например, на взаимодействия с SSH / HTTP.
Собирает аналитические данные без вреда для основной системы.
Прост в установке и не требует большого количества ресурсов.

2. Высокоуровневый(High-Interaction), предоставляющие полноценное окружение с реальными операционными системами и сервисами, позволяя взаимодействовать с системой так, как если бы это была настоящая цель.

Полноценные виртуальные машины или контейнеры с установленными сервисами и приложениями.
Получение более обширных аналитических данных, а так же детальной информации о компрометации и пост-эксплуатации.
Возможность мониторинга атак и логгирования действий.

Low-Interaction.
Для низкоуровневых honeypot мы будем использовать Cowrie, который позволит нам имитировать SSH и Telnet.

1. Установим необходимые пакеты.

Bash:

Код:

sudo

apt

install

git

python3 python3-pip python3-virtualenv -y

2. Копируем репозиторий Cowrie.

Bash:

Код:

git

clone https://github.com/cowrie/cowrie.git

cd

cowrie

3. Создаём виртуальное окружение Cowrie.

Bash:

Код:

virtualenv cowrie-env

Bash:

Код:

source

cowrie-env/bin/activate

4. Устанавливаем зависимости.

Bash:

Код:

pip

install

-r requirements.txt

Код:

На этом мы установили Cowrie на нашу Linux систему, однако нам необходимо теперь так же её настроить, чтобы по итогам конфигурации мы получали необходимый результат.

5. Редактируем конфигурационный файл.

Bash:

Код:

nano

cowrie.cfg

Нам необходимо изменить следующие параметры:
1.

Код:

hostname

- задаём имя honeypot.
2.

Код:

listen_port

- указываем порт, который будет "прослушиваться" с помощью honeypot (например, 2222 или 22 для SSH).

6. Сохраняем изменения в конфигурации.

7. Делаем, чтобы Cowrie запускался как служба.

Для этого создадим файл типа systemd.

Bash:

Код:

sudo

nano

/etc/systemd/system/cowrie.service

После этого необходимо добавить следующее содержимое:

Код:

Код:

[Unit]



Description=Cowrie SSH/Telnet Honeypot



After=network.target



[Service]



Type=simple



User=your_username # Замените на имя пользователя



WorkingDirectory=/path/to/cowrie # Укажите путь к каталогу cowrie



ExecStart=/path/to/cowrie/cowrie-env/bin/python3 /path/to/cowrie/bin/cowrie start



Restart=on-failure



[Install]



WantedBy=multi-user.target

Не забываем заменить "/path/to/cowrie" на фактический путь к директории.

8. Запускаем сервис и настраиваем автозагрузку.

Bash:

Код:

sudo

systemctl start cowrie.service

sudo

systemctl

enable

cowrie.service

9. Проверяем статус работы системы.
Bash:Скопировать в буфер обмена
sudo systemctl status cowrie.service

При успешном отклике мы можем считать настройку успешной. Однако, нам важно анализировать данные, которые позволят нам корректировать собственные защитные линии. Все логи хранятся по пути: cowrie/log

Поэтому, для просмотра действий с honeypot в вашей инфраструктуре используем:

Bash:Скопировать в буфер обмена
tail -f cowrie/log/cowrie.log

High-Interaction.
Для высокоуровневых honeypot мы будем использовать более комплексный инструмент, поэтому для примера возьмём Dionaea.

1. Установим необходимые для работы пакеты.
Bash:Скопировать в буфер обмена
sudo apt update sudo apt install git build-essential python3 python3-pip python3-dev libssl-dev \ libffi-dev libtool automake autoconf libglib2.0-dev libpcap-dev \ libsqlite3-dev libcurl4-openssl-dev libgcrypt20-dev libnetfilter-queue-dev \ libnetfilter-conntrack-dev

2. Копируем репозиторий Deonaea.

Bash:Скопировать в буфер обмена
git clone GitHub - DinoTools/dionaea: Home of the dionaea honeypot cd dionaea

3. Компилируем Dionaea.

Bash:Скопировать в буфер обмена
./autogen.sh ./configure make

4. Проводим настройку конфигурационного файла.

Обычно файл находится по адресу dionaea/etc/dionaea.conf, но применим команду:

Bash:Скопировать в буфер обмена
nano etc/dionaea.conf

Необходимо уделить внимание важным параметрам:

[http]: Настройки HTTP. Например: "port = 80"
[ftp]: Настройки FTP. Например: "port = 21"
[sip]: Настройки SIP (если это применимо).
[logging]: Настройки логирования. Например: "logfile = /var/log/dionaea.log"

5. Создаем базу данных SQLite.

Dionaea использует MySQL и SQLite для хранения данных, поэтому рассмотрим создание именно второго варианта.

Bash:Скопировать в буфер обмена
mkdir -p /var/lib/dionaea touch /var/lib/dionaea/dionaea.sqlite
Не забываем проверить, что у Dionaea есть права записи:

Bash:Скопировать в буфер обмена
sudo chown -R $(whoami):$(whoami) /var/lib/dionaea

6. Запускаем Dionaea.

Bash:Скопировать в буфер обмена
sudo ./dionaea/dionaea -c etc/dionaea.conf

7. Добавляем опцию автозапуска системы.

Bash:Скопировать в буфер обмена
sudo nano /etc/systemd/system/dionaea.service

Добавляем следующие строки:

[Unit]
Description=Dionaea Honeypot

[Service]
Type=simple
ExecStart=/path/to/dionaea/dionaea -c /path/to/dionaea/etc/dionaea.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target
Не забываем заменить "/path/to/dionaea/" на нужный нам путь.

8. Активируем и запускаем сервис.

Bash:Скопировать в буфер обмена
sudo systemctl enable dionaea.service sudo systemctl start dionaea.service

9. Логирование.

Как и в случае с Cowrie, мы используем аналогичную команду для просмотра логов:

Bash:Скопировать в буфер обмена
tail -f /var/log/dionaea.log

Complexity is the key.
Мы рассмотрели опцию настройки honeypot для высокоуровневых и низкоуровневых типов. Однако, подобные решения скорее представляют из себя точечные или даже костыльные меры, поскольку требуют довольно много настроек и внимания со стороны master-user, а так же скорее направлены на какой-то конкретный раздел.

В качестве комплексного решения для обеспечения безопасности вашей инфраструктуры, с точки зрения обеспечения корпоративной кибебезопасности, можно использовать такой инструмент как Illusive Shadow(Proofpoint).

Поскольку Illusive Shadow имеет возможность имитации различных сетевых сервисов таких как SSH, HTTP и FTP для привлечения внимания, а также приложений, то этот инструмент, за счёт удобных опций настройки является одним из оптимальных решений.

Помимо самого варианта создания honeypot'ов, каждый сотрудник ИБ и знтузиаст может найти для себя и другие функции, которые будут полезны в процессе работы над обеспечением безопасности систем:
- Сбор данных для последующего анализа.
Платформа собирает данные о IP, типах угроз, используемых инструментах.

Имеет интеграцию AI+ML, что позволяет адаптировать поведение защиты в случае угрозы.
Интеграция с SIEM для получения обширного спектра возможностей интеграции с текущими системами безопасности для централизованного мониторинга.

Однако, считаю, что настройке такой системы должна быть посвящена отдельная статья.

Заключение.
Использование honeypot как меры обеспечения безопасности может сослужить хорошую службу, исходя из всех аналитических данных. Поскольку есть вариация использования таких ловушек для отвлечени внимания, теста гипотез, определения векторов атак, оптимизации работы системы безопасности, то понимание принципов работы и вытекающие отчёты являются клдчами в общей связке для достижения необходимого уровня безопасности организации.
Понятие "Incident".
Инцидентом считается любое событие, которое влечёт за собой полную недоступность критической сервиса корпоративной инфраструктуры. Обычно классификация выглядит следующим образом:

External Incident(например, хакерская атака).
Internal Incident(внутренняя проблема технического характера).
Non-Tech Incident(ошибка на основании человеческого фактора).

Команда SOAR.
Создание команды "ГБР" является важным, а иногда и ключевым фактором в обеспечении безопасности организации, так как во многом влияет организация процесса и коммуникация между различными отделами, ответственными за Incident Management.

Если мы говорим о конкретных специализациях, то команда выглядит следующим образом:
1. Lead.
Ответственный за принятия решений и координацию действий. На практике это представитель C-level(CTO, CSO, CCO etc.)
2. InfoSec.
Представители команды информационной безопасности необходимы для анализа вектора атак, оценки угроз, мер противодействия.
3. IT.
Я обобщил данный сектор, так как ответственные вызываются, в зависимости от сервиса, следовательно за недоступность функционала сайта будет вызван Frontend Dev, либо могут быть задействованы несколько различных отделов разработки.
4. PR / Customer Support.
Репутация нарабатывается временем, а теряется по щелчку пальцев. При длительной недоступности каких-то функций, которыми пользуются тысячи или миллионы пользователей, ваш имидж страдает в первую очередь, поэтому необходимо своевременно комментировать ваши неполадки и взаимодействовать с клиентами.
5. DevOps.
Так как core system чаще всего является сферой влияния именно данного отдела, то их присутствие будет определенно преимуществом.

При этом недостаточно просто иметь готовую команду, так же необходимы планирование, адаптация и практика. К чему мы скоро и перейдём.

Разработка плана и процедур реагирования.
Эффективный план реагирования имеет чёткую структуру:
1. Описание целей и задач плана.
2. Перечисление ответственных лиц.
3. Описание инцидентов.
4. Сценарии инцидентов.
5. Процедуры для сценариев реагирования.

Сам план реагирования крайне удобно визуализировать, например, блок-схемами в XMind. Вы будете чётко понимать саму процедуру в каждом случае применения.

В вашем IMP(Incident Management Plan) так же важно охватить такую тему как "определение уровней риска", так как обычно от этого зависит само понятие инцидента.

Для простоты привожу формулу расчёта:
Уровень_риска = Вероятность × Воздействие

Вероятность — исходя из всех имеющихся данных, практическая вероятность частного случая.

Воздействие — какое воздействие данный случай имеет на вашу инфраструктуру.

Классификация рисков по уровням:

Низкий
Средний
Высокий

Данный вывод поможет определить что именно является полной недоступностью или критическим сервисом, а так же основанием для запуска процедуры реагирования на инциденты.

Практические командные тесты.(Стратегии).
Я затрагивал тему аудита систем безопасности и реагирования на инциденты для определения наиболее подходящих инструментов, в своих предыдущих статьях.

На практике мною было выделено, что самый лучший аудит проводится практическим методом. Поэтому ниже привожу несколько сценариев для тестирования:

1. Симуляция инцидента. (R/B Team).
Команда 1 создаёт инцидент с помощью внутренних или внешних инструментов. Необходимо создать триггер для своевременной реакции со стороны ответственных(Команда 2), согласно IMP.
Например:
1. Создаётся имитация.

- Потери соединения:

Пример:
Bash:Скопировать в буфер обмена
sudo ip link set eth0 down

- Повышенной нагрузки:

Пример:
Bash:Скопировать в буфер обмена
sudo apt-get install stress stress --cpu 8 --timeout 60

- Повышенного лага сети:

Пример:
Bash:Скопировать в буфер обмена
sudo tc qdisc add dev eth0 root netem delay 100ms

- Отключение конкретного Product Service.

Пример: Payment system.
2. Происходит оповещение команды 2.
3. Происходит тест процедур IMP.
Выводы: Координация процесса, скорость реагирования, возможное противодействие, скорость исправления.
2. Тренировка на основе сценариев.
Составленные заранее вов ремя планирования сценарии необходимо так же тестировать.
Например:
Составлен сценарий противодействия DDoS атаке.
Команде необходимо отточить полностью процедуру, которая будет включать в себя такие этапы как:
1. Обнаружение ициндента с помощью мониторинговых систем.
2. Оценка и анализ ситуации ответственной 1-й линией.
3. Уведомление SOAR.
4. Сбор кейсов и доказательств.
5. Реакция и противодействие Incident Management Team.
6. Постинциндентый анализ.
Выводы: Опрелеление эффективности частных сценариев, доработка процедур, определение необходимых мониторинговых систем.

3. Ротация ролей.
Для понимания зоны ответственности и специфики смежных по специализации ролей, в Incident Management Team возможно проводить ротацию для создание более полноценной картины.
Например:
PR Customer Support.
Предоставление возможности отделу PR взаимодействовать со входящими обращениями клиентов через каналы связи, а Customer Support составлению плана исключения или смягчения репутационных рисков.
Выводы: Более дополненное представление сотрудников о реагировании на инциденты.

Выводы из тестов.
Проведя все тесты, мы получаем тонны данных для анализа, а следовательно дальнейших вариаций противодействия атаке на инфраструктуру. Это позволит вам составлять более чёткие процессы и процедуры реагирования, оптимизировать свои SIEM-системы или же дополнять арсенал инструментов.

Однако, я бы хотел вознаградить постоянных читателей небольшим бонусом. Самое первое, что влияет на скорость реакции это дашборды, которые в режиме реального времени могут показывать аномальные изменения поведения ваших систем. Первые в голову приходят такие инструменты как Grafana, Kibana(в сочетании с Elastic search), Prometheus и NetData. Поэтому мы создадим бесплатно простой дашборд с помощью 2-х инструментов - Grafana + Prometheus для логгирования событий безопасности и визуализации:
Шаг 1. Устанавливаем инструменты.

Prometheus отвечает за сбор данных и хранения метрик.
Grafana отвечает за визуализацию данных.

Bash:Скопировать в буфер обмена
# Установка Prometheus sudo apt-get update sudo apt-get install prometheus # Установка Grafana sudo apt-get install grafana

Шаг 2. Настроим Prometheus.

Создаём конфигурационный файл prometheus.yml и вставляем следующее:

YAML:Скопировать в буфер обмена
global: scrape_interval: 15s scrape_configs: - job_name: 'linux_metrics' static_configs: - targets: ['localhost:9090'] # Укажите адрес вашего сервера

Сохраняем.

Шаг 3. Запуск Prometheus.

Bash:Скопировать в буфер обмена
prometheus --config.file=prometheus.yml

Шаг 4. Сбор данных.

Для сбора данных будем использовать auditd, чтобы отслеживать, например, событие входа в систему.

Устанавливаем auditd:

Bash:Скопировать в буфер обмена
sudo apt-get install auditd

Шаг 5. Настраиваем правила аудита.

Откроем файл по пути etc/audit/audit.rules и добавим правило:

Bash:Скопировать в буфер обмена
-w /var/log/auth.log -p wa -k auth_log

Шаг 6. Перезапускаем auditd.

Bash:Скопировать в буфер обмена
sudo service auditd restart

Шаг 7. Настроим экспорт метрик.

Для этого используем node_exporter, устанавливаем:

Bash:Скопировать в буфер обмена
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-.linux-amd64.tar.gz tar xvfz node_exporter-.linux-amd64.tar.gz cd node_exporter-.linux-amd64 ./node_exporter &

Шаг 8. Добавляем в конфигурацию Prometheus.

Снова открываем файл prometheus.yml и добавляем:

YAML:Скопировать в буфер обмена
- job_name: 'node_exporter' static_configs: - targets: ['localhost:9100']

Шаг 7. Запустим Grafana.

Bash:Скопировать в буфер обмена
sudo service grafana-server start

Шаг 8. Переходим в веб-интерфейс Grafana.

Обычно интерфейс доступен по адресу http://localhost:3000.

Шаг 9. Входим в Grafana.

- Входим с помощью стандартных admin/admin.

- Добавляем источник данных.
"Configurations" -> "Data Sources".

- Выбираем Prometheus и указываем URL.

Шаг 10. Создаём дашборд.

1. Перейдите в "Dashboards" > "New Dashboard".
2. Добавьте панели для отображения метрик безопасности:

Количество неудачных попыток входа: используйте запросы к логам auth.log.
Активные пользователи: количество активных сессий.
События аудита: количество событий, зарегистрированных auditd.

Пример запроса для неудачных попыток входа:

Код:Скопировать в буфер обмена
sum(rate(auditd_events_total{event_type="failed_lo gin"}[5m]))

Шаг 11. Добавляем визуализацию.

Настройте графики и таблицы, которые хотелось бы отслеживать, в зависимости от ваших требований.

Если кто-то держит в уме Part 1, то заодно скажу, что Grafana отлично сочетается так же и с honeypot ловушками от Cowrie, которые так же можно взаимосвязать.

Данные из Cowrie обычно хранятся в базе данных SQLite, но так же есть формат JSON.

Поэтому, чтобы интегрировать Cowrie с Grafana, нам необходимо экспортировать логи в систему мониторинга - Prometheus.

Правда для этого нам понадобится Exporter для Cowrie.

https://github.com/marvinpinto/cowrie-exporte, либо же написать свой скрипт на Python.

Шаг 1. Установим репозиторий.

Bash:Скопировать в буфер обмена
git clone https://github.com/marvinpinto/cowrie-exporter.git cd cowrie-exporter

Шаг 2. Установите зависимости.

Bash:Скопировать в буфер обмена
pip install prometheus_client requests

Шаг 3. Настройка Exporter.

Откройте файл cowrie_exporter.py и измените параметры подключения к вашему экземпляру Cowrie (например, путь к логам или API, если используется).

Шаг 4. Запускаем Exporter.

Bash:Скопировать в буфер обмена
python cowrie_exporter.py --cowrie-log-dir /path/to/cowrie/logs --port 8080

Не забываем убедиться в правильном пути к логам Cowrie.

Шаг 5. Изменить файл конфигурации Prometheus(prometheus.yml).

Например:
YAML:Скопировать в буфер обмена
global: scrape_interval: 15s scrape_configs: - job_name: 'cowrie' static_configs: - targets: ['localhost:8080'] # Порт, на котором работает ваш exporter

Дальше мы запускаем Prometheus и повторяем процедуру с настройкой дашбордов в веб-интефейсе Grafana.

В дальнейшем можно улучшать, модернизировать и добавлять сервисы, которые вы захотите мониторить. Мой опыт подсказывает, что необходимо отслеживать всё, что вы считаете критичным и лучше иметь, но не нуждаться, чем нуждаться, но не иметь.

В этой части я буду заканчивать. Скоро увидимся!