Обнаружение на периметре.

Целями первичных атак являются узлы DMZ облачной инфраструктуры. Главная цель — попасть в закрытую сеть (Internal Network на карте сети). Для определения векторов атаки злоумышленник проводит поиск информации по открытым источникам, далее пытается эксплуатировать известные уязвимости, которые обеспечат первоначальный доступ в сеть.

Своевременное обнаружение факта разведки поможет быстрее среагировать на следующие действия злоумышленника.

Honeytoken — это ложная информация, которая размещается в системе или на сайте компании для привлечения внимания и определения факта НСД. Может быть в виде фиктивных учетных записей, файлов или документов, которые содержат ложную информацию. Часто являются частью honeypot-систем. Последовательность размещения:

Создание Honeytoken в зависимости от эмулируемых данных (например, поддомен организации).
Honeytoken размещается на ресурсе внешнего периметра организации (в случае с OSINT), например, поддельные учетные данные, используемые для удаленного доступа к высокочувствительным ресурсам, намеренно размещаются в обсуждении на форуме.
Систему управления Honeytoken связывают с системой обнаружения вторжений (IDS) или платформой управления информационной безопасностью и событиями безопасности (SIEM).
После срабатывания оповещения вступает в силу план реагирования на инциденты организации.
Данные, собранные в результате анализа события срабатывания обнаружения, затем могут быть использованы для принятия мер безопасности. Информация, полученная в результате использования Honeytoken, дает представление о частях сети, подвергающихся наибольшему риску, а также о типах инструментов, необходимых для защиты этих областей.

Настройка получения уведомлений о проведении OSINT

При проведении OSINT пытаются получить следующие данные:

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

Каждый из этих информационных ресурсов возможно эмулировать и размещать в открытых источниках.

DNS Canarytoken

Механизм обнаружения НСД к DNS-серверам. Это уникальный DNS-запрос, который не должен быть использован нормальными пользователями или приложениями. Если кто-то попытается использовать этот запрос, это будет сигналом о возможной атаке. DNS Canarytoken может быть размещен на DNS-сервере или в зоне DNS-имен и может быть настроен для определенных типов DNS-запросов или для всех запросов.

Как правило, при регистрации сервисов на внешнем периметре организации используют доменные имена третьего уровня. Поиск таких поддоменов — одно из первых действий злоумышленника при проведении OSINT. Чаще всего сервисы называются в соответствии с их функционалом (например, blog.company.com, docs.company.com и т.п.). Самые распространенные префиксы попадают в словари утилит для поиска поддоменов.

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

Данный функционал реализован в Canarytokens. Уведомления об обращении присылаются на почтовый адрес, возможны webhook'и мессенджеров. Настройка осуществляется при помощи файла окружения.

В Knary поддерживаются следующие сервисы для оповещения: Discord, Slack, Microsoft Teams, Pushover, Lark, Telegram.

Алгоритм размещения и внедрения поддельных данных может быть представлен следующими шагами:

Определение типа эмулируемых данных (DNS, email, API-ключ и т.п.).
Создание и размещение данных на внешних сервисах.
Настройка системы уведомлений об использовании поддельных данных (SMTP, Telegram, SIEM).

E-mail адреса

Обычно почтовые адреса расположены в том же домене, что и остальные информационные ресурсы организации. Для обнаружения факта компрометации почтового адреса возможно зарегистрировать поддельный e-mail, который будет выступать в качестве honeytoken’а. При выявлении аномальной деятельности (спам-рассылка, множественные попытки входа, использование почтового адреса в качестве логина при аутентификации, запросы к БД, содержащие сгенерированный e-mail) система обнаружения должна генерировать уведомление.

Репозитории Git

Очень часто в оставленных в публичном доступе репозиториях присутствуют API-токены доступа ко внутренним сервисам организации. Злоумышленники могут пользоваться этим при проведении разведки. Эмуляция и отслеживание аномальной активности, связанной с поддельным токеном (или даже целым endpoint’ом) позволит выявить факт компрометации исходного кода.

Для автоматизации и эффективного отслеживания деятельности злоумышленника на внешнем периметре компании можно использовать средство «Manuka», которое представляет собой агрегатор указанных выше методик по созданию honeytoken’ов.

Архитектура утилиты manuka (ссылка на источник)

Также для обнаружения OSINT’a возможно разворачивание средства T-Pot на внешнем периметре. Данное средство представляет собой сборку популярных honeypot-систем, эмулирующих отдельные сервисы (в т.ч. и DNS-серверы).

Анализ логов

Анализ логов выявляет подозрительные действия, указывающие на попытку проникновения. Можно определить:

источник атаки (IP, устройства и т.д.)
серьезность является угрозы
были ли предприняты какие-либо действия для компрометации системы

Основные файлы журналов в Linux-системах

Текущая схема журналирования в Debian:

[Программы] → journald → (опционально) rsyslog → /var/log/*.log

Подробнее о логах. rsyslog по умолчанию не установлен.

Журналы обычно текстовые файлы, каждая строчка одно событие. Обычно метка времени, тип события и краткое описание. Файлы журналов как правило принадлежат пользователю root и находятся в каталоге /var/log. Список журналов:

rsyslog/journald	логи, генерируемые менеджером
kernel.log	логи ядра ОС
audit.log	логи ядра, которые пишет auditd, если он настроен
auth.log/secure	журнал событий безопасности
Логи приложений	например, веб-севера, БД или прочих

Файлы журналов различаются в разных ОС. Например, логи событий для команд sshd, sudo и прочих действий, связанных с безопасностью в Ubuntu, находятся в /var/log/auth.log, а в CentOS в /var/log/secure. Также, файлы менеджера журналирования находятся в /var/log/syslog для Ubuntu, а в CentOS - /var/log/messages.

Daemon (демоны) в системах Linux

В ОС Linux демоны — фоновые программ, работающие без взаимодействия с пользователем.

Демон Syslog

Менеджер журналов. Есть Nxlog и Syslog-NG, но Syslog наиболее распространен. Задача Syslog — прием событий от локальных служб, обработка, запись их в файлы журналов /var/log или пересылка событий по сети. Виды Syslog:

Syslog как менеджер журналов;
Syslog как сетевой протокол передачи данных;
Syslog как формат предоставления данных.

Обычно приложения отправляют события менеджеру журналов в своем формате, и для удобства чтения логов из разных источников эти сообщения нужно стандартизировать. Возьмем событие sshd и изменим формат.

Для преобразования событий в стандартизированный формат (мы будем использовать RFC3164) нам нужно создать шаблон в /etc/rsyslog.conf или /etc/rsyslog.d/custom_name.conf.

Пример шаблона формата сообщений

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

Давайте разберем данное событие:

<38> — значение приоритета, получается за счет комбинирования значений facility и severity. Чем меньше цифра, тем важнее событие;
Dec 3 21:45:02 — временная метка;
ubuntu-server — имя сервера, на котором произошло событие: поле важно при отправке логов на другой сервер;
sshd — имя сервиса, который создал запись о событии;
[2057] — номер процесса, Process ID;
Failed password.... — собственно, само событие: SIEM в процессе нормализации логов выделит дополнительные поля, такие как source_ip, action, user и тд..
Значение приоритета syslog считается по формуле facility * 8 + severity. Facility имеет заданные значения, и определяет к какому типу относится событие. Например, facility #0 относится к событиям ядра, а #4 - к событиям систем безопасности.

Severity отвечает за уровень критичности событий, где 0 это максимум(emergency), а уровень 7 - малоинформативные данные, используемые для отладки(debug).

В нашем примере число 38 получается за счет facility 4 и severity 6 (info).

Journald
Современные Linux-системы помимо rsyslog параллельно используют journald для обработки и хранения логов.

Journald является частью systemd, менеджера конфигурации и управления службами (демонами), который после анонса в 2015 году стал де-факто стандартом для большинства Linux-систем. Systemd_journald или просто journal отвечает за централизованное управление логами. Для обеспечения целостности данных journald хранит логи в бинарном формате, в отличие от rsyslog, который использует обычные текстовые файлы. Предполагается, что journald в будущем заменит rsyslog, который сам в свою очередь заменил более старую версию syslog. Для обеспечения обратной совместимости на большинстве Linux систем rsyslog работает вместе с journald, получая от него сообщения и записывая их в файлы. Чтобы убедиться в этом, давайте посмотрим, какой процесс записывает события в файл журнала с помощью команды lsof.

Как мы видим, это rsyslogd. Давайте теперь посмотрим, откуда rsyslog берет эти сообщения. Откроем файл конфигурации /etc/rsyslog.conf:

Обратите внимание, что параллельно со старым модулем imuxsock в качестве источника событий используется модуль imjournal. В этом случае каждое событие дублируется — одна копия записывается в текстовый файл демоном rsyslog, а вторая копия помещается в журнал journald.

Давайте найдем события демона sshd в журнале journald. Для этого используем команду journalctl:

Ключ -u отвечает за фильтрацию логов по демонам (-u = unit), а ключ -S (--since) — за фильтр по времени.

Более подробное логирование событий в системе, таких как создание процессов, обращение к файлам или инициирование сетевых подключений, которые можно настроить с помощью специального ПО, например, auditd или sysmon for linux, мы разберем позже.