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

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 как формат предоставления данных.

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

Веб-серверы и языки сценариев

Веб-сервер Nginx

У Nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами, которые выполняют фактическую обработку запросов.

Конфигурация Nginx разделяется на виртуальные серверы (директива «server»). Виртуальные серверы, в свою очередь, разделяются на location. Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения. 

Конфигурационный файл nginx.conf, каталоге /usr/local/nginx/conf, /etc/nginx или /usr/local/etc/nginx.

При работе Nginx ведет два файла журналов - access.log и error.log. Первый отвечает за журналирование успешно обработанных запросов клиентов, второй - за журнал ошибок. (access_log и error_log). По умолчанию Nginx имеет следующий формат логов: 

• $remote_addr – IP адрес источника, с которого был сделан запрос;
• $remote_user – пользователь, прошедший HTTP-аутентификацию;
• [$time_local] – время посещения в часовом поясе сервера;
• “$request” – тип HTTP-запроса, запрошенный путь без аргументов и версия HTTP;
• $status – код ответа от сервера;
• $body_bytes_sent– размер ответа сервера в байтах;
• “$http_referer” – URI страницы, с которой пользователь сделал запрос;
• “$http_user_agent” – user-агент;

Сортировка лога по коду ответа: 

cat access.log | cut -d '"' -f3 | cut -d ' ' -f2 | sort | uniq -c | sort -rn

Найти запросы, которые получили в ответ 404 ошибку, и отсортировать по числу запросов на URL: 

awk '($9 ~ /404/)' access.log | awk '{print $7}' | sort | uniq -c | sort -rn

Список IP, с которых идут запросы к конкретному url:

awk -F\" '($2 ~ "/wp-admin/install.php"){print $1}' access.log | awk '{print $1}' | sort | uniq -c | sort -r

Список самых популярных URL:

awk -F\" '{print $2}' access.log | awk '{print $2}' | sort | uniq -c | sort -

В Elasticsearch для работы с такими логами удобно использовать фильтр event.category: "web". Также, для быстрого доступа к нужным данным можно выбрать интересующие аналитика поля в левой части в разделе Selected Fields, и нажав на значок "+" рядом с именем поля.

Обнаружение перечисления веб-сервера (Enumeration)

Обычно на фазе подготовки производят перечисление (enumeration) веб-сервера. В случае веб атак интересуют доступные URL, версия веб-сервера и установленные интерпретаторы. 

Для определения ОС и версии Nginx сервера, воспользуемся инструментом Nmap. Для определения версий ПО ключ -sV. 

nmap ip_addr -sV

При сканировании Nmap добавляет в заголовки запросов записи (поэтому нужно менять user-agent), позволяющие его идентифицировать.

Обнаружить перебор директорий по логам веб-сервера происходит с помощью контроля всплеска запросов с ответом от сервера 404 - Not found. Также в запросах подставляется несуществующий или устаревший User-agent, в нашем случае мы видим Mozilla/4.0 для Windows NT. 

Обнаружение атаки Local File Inclusion

В логах обращений к веб-серверу будет запись вида ../../ В SIEM. применим следующие фильтры:

event.category: process;
event.code: 1 - Sysmon event 1 описывает событие создания нового процесса;
winlog.event_data.ParentUser: www-data - нас интересуют процессы, запускаемые от пользователя www-data;

Поскольку Sysmon изначально был написан для Windows, некоторые системы используют уже работающие для Windows модули для импорта логов. Пусть вас не смущает Winlog в названии поля, в нашем случае это поле описывает пользователя-родителя процесса в Linux-системе. event.module: sysmon_linux - нас интересуют логи Sysmon for Linux.

Анализ логов Linux

Инцидент повышения привилегий является серьезным инцидентом безопасности. При подозрении важно провести углубленное расследование. Признаками повышения привилегий могут являться вредоносное ПО в конфиденциальных системах, подозрительные входы в систему и необычные сетевые соединения, срабатывания систем EDR, NIDS, DLP итд.

С позиции Blue Team-специалиста, такие инструменты как LinPEAS генерируют большое количество событий подряд (запуск команд для работы с текстовыми данными grep), не характерное для работы человека, занимающимся фильтрацией данных. Определения всплеска такой активности может помочь с обнаружением.

Web-shell. Самым простой - восстановление сайта из резервной копии и последующее устранение уязвимостей, которые привели к компрометации. Альтернативный способ — сравнить имеющиеся на сервере файлы с оригиналами, или настроить File Integrity monitoring (FIM). 

FIM — это способ контроля целостности файлов. Программа с некоторой периодичностью создает контрольные суммы файлов системы, и сравнивает их с предыдущими значениями. Если контрольная сумма изменилась — значит файл был изменен, и программа запишет это событие в лог.

Из Open-source решений, которые делают FIM можно выделить три самых популярных:

• Auditbeat’s File Integrity Monitoring: Auditbeat’s File Integrity Monitoring
• Auditd: Auditd
• Wazuh’s File Integrity Monitoring: Wazuh’s File Integrity Monitoring

IDS/IPS

ModSecurity — веб-брандмауэр (Web Application Firewall, WAF), в виде модуля веб-сервера. Встраивается в цикл обработки запросов и ответов веб-сервера Задачи:

• Обнаруживает и блокирует SQLi, XSS, инъекции кода, и другие уязвимости веб-приложений;
• Логирование событий

Компоненты:

• Rule Engine (Движок обработки правил) — компонент, ответственный за принятие решений на основе правил безопасности.
• Rule Language (Язык/синтаксис правил) — специальный синтаксис, используемый для написания правил обработки входящего и исходящего трафика.
• Rule Set (Набор правил) — набор заранее определенных правил безопасности, который может быть настроен и расширен под нужды конкретного приложения.

Установка Ubuntu:

sudo apt update 
sudo apt install apache2 libapache2-mod-security2

Настройка ModSecurity

/etc/modsecurity/modsecurity.conf. 

# Основные настройки
SecRuleEngine On
SecRequestBodyAccess On
SecDataDir /var/cache/modsecurity
SecRequestBodyLimit 13107200

# Настройки логгирования
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIFHZ
SecAuditLogType
Serial SecAuditLog /var/log/modsec_audit.log

#### Правила блокировки/пропускания запросов
# Правило пропускает запросы с IP адресов из whitelist
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/modsecurity/whitelist.conf" "phase:1,nolog,allow"
# Правило разрешает метод OPTIONS
SecRule REQUEST_METHOD "OPTIONS" "phase:1,nolog,allow"
# Правило разрешает метод CONNECT
SecRule REQUEST_METHOD "CONNECT" "phase:1,nolog,allow"
# Правило запрещает использование любых методов кроме GET, HEAD и POST, и обозначает статус-код ошибки 405-ым
SecRule REQUEST_METHOD "!^(GET|HEAD|POST)$" "phase:2,deny,status:405,log,msg:'Method is not allowed.'"

#### Правила обнаружения атак
# Правило проверяет заголовок host - есть ли в нем IP адрес
SecRule REQUEST_HEADERS:Host "@rx ^\d+\.\d+\.\d+\.\d+$" "phase:1,block,log,msg:'IP address in Host header.'"
# Правило проверяет используемый протокол в запросе и блокирует соединения по HTTP, выдавая 403 код ответа
SecRule REQUEST_URI|REQUEST_HEADERS "!(?i:^https?://)" "phase:1,deny,status:403,id:1005,msg:'Non-HTTPS traffic not allowed.'"
# Правило блокирует трафик от ботов и сканеров, определеяя их по юзер-агенту
SecRule REQUEST_HEADERS:User-Agent "@pm (googlebot|bingbot)" "phase:1,deny,status:403,id:1006,msg:'Bot not allowed.'" 
# Правило для блокировки запросов с неправильными Referer - Referer отличается от SERVER_NAME
SecRule REQUEST_HEADERS:Referer "!@contains %{SERVER_NAME}" "phase:1,deny,status:403,id:1007,msg:'Invalid Referer.'" 
# Правило блокирует запросы с неправильными Content-Type
SecRule REQUEST_HEADERS:Content-Type "!@rx ^(application/x-www-form-urlencoded|multipart/form-data|text/plain)$" "phase:1,deny,status:403,id:1008,msg:'Invalid Content-Type.'"
# Правило блокирует запросы с неправильным User-Agent
SecRule REQUEST_HEADERS:User-Agent "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1009,msg:'Invalid User-Agent.'"
# Правило блокирует запросы с неправильными Accept-Charset
SecRule REQUEST_HEADERS:Accept-Charset "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1010,msg:'Invalid Accept-Charset.'"
# Правило блокирует запросы с неправильным Accept-Encoding
SecRule REQUEST_HEADERS:Accept-Encoding "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1011,msg:'Invalid Accept-Encoding.'"
# Правило блокирует запросы с неправильным Accept-Language
SecRule REQUEST_HEADERS:Accept-Language "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1012,msg:'Invalid Accept-Language.'" 

Некоторые из ключевых параметров:

SecRuleEngine — определяет, включен ли ModSecurity (On - включено, Off - выключено).
SecRequestBodyAccess — определяет, имеет ли ModSecurity доступ к телу запроса (On - включено, Off - выключено).
SecDataDir — определяет директорию для хранения данных, таких как временные файлы и директории.
SecDebugLog, SecDebugLogLevel — определяют файл и уровень журнала отладки.
SecAuditEngine, SecAuditLog, SecAuditLogRelevantStatus, SecAuditLogParts — настройки для журналирования аудита.

Активация модуля в Apache

Создайте символическую ссылку на конфигурационный файл в директории conf-enabled:

sudo ln -s /etc/modsecurity/modsecurity.conf /etc/apache2/conf-enabled/

Перезапустите Apache:

sudo systemctl restart apache2

Проверка работоспособности

Можно создать простой тестовый файл, чтобы убедиться, что ModSecurity работает.
Создайте файл test.php в вашем веб-каталоге с содержимым:

<?php echo "Hello, World!"; ?>

Откройте этот файл в веб-браузере и убедитесь, что он доступен. Затем попробуйте создать запрос, который сработает на одном из правил ModSecurity, чтобы убедиться, что он блокирует нежелательные запросы.

Настройка ModSecurity Docker