Обнаружение на периметре.
Honeytoken
Honeytoken — ложная информация в системе или на сайте компании для привлечения внимания и определения факта НСД. Может быть в виде фиктивных учетных записей или файлов, содержащих ложную информацию. Часто являются компонентом honeypot-систем. Последовательность размещения:
- Создание Honeytoken в зависимости от эмулируемых данных (например, поддомен организации).
- Размещение на ресурсе внешнего периметра организации (в случае с OSINT). Например, поддельные учетные данные, используемые удаленного доступа к высокочувствительным ресурсам размещаются в обсуждении на форуме.
- Систему управления Honeytoken связывают с системой обнаружения вторжений (IDS) или платформой управления информационной безопасностью и событиями безопасности (SIEM) или просто почта/мессенджеры.
- После срабатывания оповещения вступает в силу план реагирования на инциденты организации.
- Данные, собранные в результате анализа события, используются для принятия мер безопасности. Направления использования Honeytoken дают представление о частях сети, подвергающихся наибольшему риску, а также о типах инструментов, необходимых для защиты этих областей.
Настройка получения уведомлений о проведении OSINT
При проведении OSINT пытаются получить следующие данные:
- Доменные имена, которые принадлежат организации;
- Почтовые адреса сотрудников;
- Социальные сети организации и ее сотрудников;
- Исходный код из репозиториев в системах контроля версий.
Каждый из этих информационных ресурсов возможно эмулировать и размещать в открытых источниках.
DNS Canarytoken
Механизм обнаружения НСД к DNS-серверам. Это уникальный DNS-запрос, который не должен быть использован нормальными пользователями или приложениями. Если кто-то попытается использовать этот запрос, это будет сигналом о возможной атаке. DNS Canarytoken может быть размещен на DNS-сервере или в зоне DNS-имен и может быть настроен для определенных типов DNS-запросов или для всех запросов.
Поиск поддоменов третьего уровня — одно из действий при проведении OSINT. Самые распространенные префиксы попадают в словари утилит для поиска поддоменов. Регистрируем неиспользуемый поддомен, содержащийся среди ключевых слов сканеров и при доступе к которому будет происходить оповещение об обращении к нему.
Данный функционал реализован в Canarytokens. Уведомления об обращении присылаются на почтовый адрес, возможны webhook'и мессенджеров. Настройка осуществляется при помощи файла окружения.
В Knary поддерживаются следующие сервисы для оповещения: Discord, Slack, Microsoft Teams, Pushover, Lark, Telegram.
E-mail адреса
Обычно почтовые адреса аналогичны домену организации. Регистрируют поддельный e-mail. При выявлении деятельности (спам-рассылка, множественные попытки входа, использование почтового адреса в качестве логина при аутентификации, запросы к БД, содержащие сгенерированный e-mail) система обнаружения генерирует уведомление.
Репозитории Git
Часто в оставленных в публичном доступе репозиториях присутствуют API-токены доступа ко внутренним сервисам организации. Им могут пользоваться. Эмуляция и отслеживание аномальной активности, связанной с поддельным токеном (или даже целым endpoint’ом) выявляет факт компрометации исходного кода.
Для автоматизации и эффективного отслеживания деятельности злоумышленника на внешнем периметре компании можно использовать средство «Manuka», которое представляет собой агрегатор указанных выше методик по созданию honeytoken’ов.
Также для обнаружения OSINT’a возможно разворачивание средства T-Pot на внешнем периметре. Данное средство представляет собой сборку популярных honeypot-систем, эмулирующих отдельные сервисы (в т.ч. и DNS-серверы).
Анализ логов
Анализ логов выявляет подозрительные действия, указывающие на попытку проникновения. Можно определить:
- источник атаки (IP, устройства и т.д.)
- серьезность угрозы
- были ли предприняты какие-либо действия для компрометации системы
Основные файлы журналов в Linux-системах
Текущая схема журналирования в Debian:
[Программы] → journald → (опционально) rsyslog → /var/log/*.logПодробнее о логах. rsyslog по умолчанию не установлен. Список журналов:
| 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
Демон 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
Для средств защиты сети, таких как IDS/IPS и WAF, основными полями для расследования в логах будут являться следующие поля:
- IP-адреса источника и назначения;
- Порты источника и назначения;
- Используемый протокол (как минимум 4 уровня, если по какой-то причине невозможно получить данные об используемых портах - пригодится и более верхнеуровневая информация по протоколам);
- Название сработавшего правила (как обсуждалось ранее, это поле "msg" в правилах Snort, Suricata или ModSecurity).
Общий алгоритм анализа логов:
| Сбор логов | Логи содержат информацию об обнаруженных событиях, таких как сетевые атаки, подозрительная активность или нарушения безопасности. На этом этапе система записывает данные о событиях в свои лог-файлы. |
| Фильтрация и предварительный анализ | Перед тем как начать полноценный анализ, происходит предварительная фильтрация данных. Это может включать в себя удаление дубликатов, фильтрацию по типу события, времени или другим критериям, чтобы уменьшить объем данных для более эффективного анализа. |
| Идентификация потенциально вредоносных событий | Аналитики обращают внимание на события, которые могут указывать на потенциальные вторжения или атаки. Это включает в себя анализ сигнатур, обнаружение отклонений от нормы, анализ аномалий и другие методы идентификации аномальной активности. |
| Классификация и приоритезация событий | События классифицируются по типу атаки или нарушения безопасности. Каждому событию присваивается приоритет в зависимости от потенциального воздействия на безопасность системы и данных. |
| Корреляция событий | Иногда важно анализировать события в контексте других событий. Корреляция событий позволяет выявить более сложные атаки, которые могут проявляться через несколько этапов или методов. |
| Анализ сетевого трафика | При обнаружении атаки аналитики могут анализировать сетевой трафик, связанный с атакой. Это включает в себя детальный анализ пакетов, их содержимого и потоков данных для более глубокого понимания характеристик атаки. |
| Дополнительные проверки | Дополнительные проверки могут включать в себя анализ журналов системы, анализ конфигураций уязвимых систем, а также использование внешних источников данных - то есть поиск информации в других системах, отличных от средств сетевой защиты. |
| Реакция и реагирование | В зависимости от важности и типа обнаруженной атаки, принимаются меры по реагированию. Это может включать в себя блокировку атакующего IP-адреса, изменение конфигурации системы, оповещение ответственных лиц и другие меры. |
| Документация и отчетность |
Все обнаруженные события и предпринятые меры должны быть документированы. Это важно для дальнейшего анализа, а также для отчетности и аудита.
|
ModSecurity
ModSecurity — веб-брандмауэр (Web Application Firewall, WAF), в виде модуля веб-сервера. Встраивается в цикл обработки запросов и ответов веб-сервера Задачи:
- Обнаруживает и блокирует SQLi, XSS, инъекции кода, и другие уязвимости веб-приложений;
- Логирование событий
Компоненты:
- Rule Engine (Движок обработки правил) — компонент, ответственный за принятие решений на основе правил безопасности.
- Rule Language (Язык/синтаксис правил) — специальный синтаксис, используемый для написания правил обработки входящего и исходящего трафика.
- Rule Set (Набор правил) — набор заранее определенных правил безопасности, который может быть настроен и расширен под нужды конкретного приложения.
Apache
sudo apt update
sudo apt install apache2 libapache2-mod-security2Активация модуля
sudo ln -s /etc/modsecurity/modsecurity.conf /etc/apache2/conf-enabled/
sudo systemctl restart apache2Настройка 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 — настройки для журналирования аудита.
Проверка работоспособности
Можно создать простой тестовый файл, чтобы убедиться, что ModSecurity работает.
Создайте файл test.php в вашем веб-каталоге с содержимым:
<?php echo "Hello, World!"; ?>
Откройте этот файл в веб-браузере и убедитесь, что он доступен. Затем попробуйте создать запрос, который сработает на одном из правил ModSecurity, чтобы убедиться, что он блокирует нежелательные запросы.
анализ логов ModSecurity
Логи ModSecurity могут быть объемными и содержать различные сведения о запросах, правилах, срабатываниях и действиях, принятых модулем. Обычно логи ModSecurity находятся в каталоге, указанном в конфигурационном файле, например, /var/log/modsec_audit.log для журнала аудита.
Использование утилит для анализа логов:
Для анализа логов ModSecurity вы можете использовать утилиты, такие как grep, awk, sed, cat и другие.
Пример команды для просмотра последних 100 строк журнала аудита:
tail -n 100 /var/log/modsec_audit.log
Фильтрация логов по определенным событиям:
Используйте grep или другие инструменты для фильтрации логов по конкретным событиям. Например, для поиска срабатываний правила с ID 1001:
grep 'id:1001' /var/log/modsec_audit.log
Формат логов:
Включите необходимые поля в логах, используя настройки в конфигурационном файле, такие как SecAuditLogParts.
SecAuditLogParts в ModSecurity — это настройка, которая определяет, какие части данных будут включены в журнал аудита (audit log). Эта настройка позволяет настраивать формат вывода логов и включать в них только необходимую информацию. Каждая часть, определенная в SecAuditLogParts, представляет собой отдельный блок данных, который может быть включен или исключен в зависимости от потребностей анализа.
Пример использования SecAuditLogPart:
SecAuditLogParts ABCDEFGHZ
Основные части, которые можно включить в SecAuditLogParts:
A - Request Headers (REQUEST_HEADERS): Заголовки запроса
B - Request Body (REQUEST_BODY): Тело запроса
C - Response Headers (RESPONSE_HEADERS): Заголовки ответа
D - Response Body (RESPONSE_BODY): Тело ответа
E - UUID (UUID): Уникальный идентификатор транзакции
F - Unique ID (UNIQUE_ID): Уникальный идентификатор запроса (например, Apache unique request ID)
G - События в аудите (AUDIT_LOG): События в формате JSON
H - Примерный перевод событий в аудите (AUDIT_LOG_RELEVANT): Примерный перевод событий в формате JSON.
Z - Завершающая строка (END): Завершающая строка для каждого запроса
Использование SecAuditLogParts обеспечивает гибкость в конфигурации логирования ModSecurity, что важно при настройке системы безопасности для конкретных потребностей вашего веб-приложения.
Использование инструментов для визуализации
Используйте инструменты визуализации логов, такие как modsec_audit_log_viewer, modsecurity-transaction-dashboard, или другие, чтобы более наглядно анализировать данные.
Проверка статуса срабатывания правил
При анализе логов обратите внимание на статусы срабатывания правил. Например, status:403 указывает на блокировку запроса.
Использование инструментов анализа безопасности:
Используйте инструменты безопасности, такие как ModSecurity-Log-Analyzer, которые специально созданы для анализа логов ModSecurity.
Простой пример лога:
--eca96d83-A-- [12/Dec/2023:15:30:45 +0000] U9Qn8HO@ABoAAHwMnNoAAAAB 192.168.1.100 12345 192.168.1.200 80
--eca96d83-B-- POST /example.php HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 param1=value1¶m2=value2
--eca96d83-C-- HTTP/1.1 403 Forbidden Content-Length: 214 Content-Type: text/html; charset=iso-8859-1
--eca96d83-F-- ...
--eca96d83-H-- Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:\b(?:union\s*all|select\s*(?:.+)\s*from|create\s*(?:.+)\s*table|delete\s*from|drop\s*(?:.+)\s*table|exec\s*(?:\w+\s*|\s*)\(|insert\s*into|shutdown|update\s*(?:.+)\s*set)\b))" at ARGS_NAMES:param1. [file "/etc/modsecurity/modsecurity.conf"] [line "21"] [id "1001"] [msg "SQL Injection attempt."] [severity "CRITICAL"] [hostname "www.example.com"] [uri "/example.php"] [unique_id "U9Qn8HO@ABoAAHwMnNoAAAAB"]
--eca96d83-Z--
Части логов:
A - Информация о запросе, включая уникальный идентификатор события (U9Qn8HO@ABoAAHwMnNoAAAAB), IP-адрес клиента, порт клиента, IP-адрес сервера, и порт сервера.
B - Содержит сам запрос, включая метод (POST), URI (/example.php), HTTP-версию, заголовки запроса и тело запроса.
C - Информация о ответе сервера, включая код состояния (403 Forbidden), длину содержимого и тип контента.
F - Дополнительная информация (не показана в примере).
H - Лог ModSecurity, содержащий информацию о срабатывании правила. В данном случае, правило с id "1001" (SQL Injection attempt) сработало из-за обнаружения попытки SQL-инъекции в параметре param1.
Z - Завершающая часть лога.
Реагирование на инциденты с использованием ModSecurity
ModSecurity предоставляет несколько методов оповещения администратора об инцидентах безопасности. Эти методы включают в себя логирование событий, отправку электронных сообщений, уведомления в системные журналы и использование внешних систем мониторинга. Вот несколько способов, как ModSecurity может делать оповещения:
Логирование событий:
ModSecurity создает логи событий, которые могут быть анализированы администраторами. В журналах содержится информация о срабатываниях правил, заблокированных запросах и других событиях и инцидентах
Логи могут быть настроены в соответствии с требованиями и включать в себя различные уровни детализации, в зависимости от потребностей безопасности вашего приложения
Электронные уведомления:
В ModSecurity может быть настроена отправка почтовых сообщений в случае срабатывания определенных правил или классов атак. Для этого можно использовать настройку SecAction с действием:
log, pass, phase:2, msg:'Message to alert admin', logdata:'adminadmin@email.com'
Интеграция с системами мониторинга:
ModSecurity может интегрироваться с внешними системами мониторинга, такими как SIEM. Это позволяет администраторам централизованно отслеживать безопасность в реальном времени и получать оповещения.
Мониторинг системных журналов:
События ModSecurity также могут быть отправлены в системные журналы операционной системы. Администраторы могут настроить мониторинг этих журналов для обнаружения и реагирования на инциденты.
Использование специфических настроек в конфигурации:
В ModSecurity существует настройка SecAuditLogRelevantStatus, которая позволяет настроить конкретные статусы ответов, при которых должны генерироваться оповещения. Например, для оповещения при срабатывании правил, приводящих к статусам 5xx и 4xx, вы можете установить:
SecAuditLogRelevantStatus "^(5|4[0-9][0-9])$"
Как было сказано ранее, ModSecurity можно использовать в базовой комплектации правил, но как правило, ее может быть недостаточно, поэтому очень важна кастомизация ModSecurity. Она позволит адаптировать WAF под конкретные потребности безопасности веб-приложения. Это может включать в себя настройку правил фильтрации, оптимизацию производительности, а также логирования событий под требования безопасности.
Кастомизация ModSecurity также полезна для учета специфических сценариев использования, например, когда веб-приложение использует веб-сервисы или API. Так как ModSecurity — инструмент с открытым исходным кодом, он легко поддается кастомизации, и также может интегрироваться с внешними системами мониторинга и управления инцидентами.
Snort
Snort — IDS/IPS с открытым исходным кодом. Метод обнаружения атак — сигнатурный анализ трафика. Поддерживает обнаружение атак на различных уровнях сети, включая IP, TCP, UDP, ICMP, и другие протоколы.
Примеры правил Snort
Пример 1: Правило обнаруживает попытки SQL-инъекций в URL с использованием одинарной кавычки (%27).
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection Attempt";
flow:to_server,established; content:"%27"; classtype:web-application-attack; sid:1;)Пример 2: Правило обнаруживает попытки доступа к файлу /etc/passwd в сетевом трафике.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Attempt to access /etc/passwd";
content:"/etc/passwd"; classtype:attempted-recon; sid:2;)Пример 3: Правило обнаруживает попытки XSS-атак с использованием встроенного скрипта в теле HTTP-запроса.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"XSS Attack Attempt";
flow:to_server,established; content:"<script>"; classtype:web-application-attack; sid:3;)Пример 4: Правило обнаруживает попытки загрузки файлов с подозрительным содержимым, начинающимся с сигнатуры MZ, что может указывать на исполняемый файл.
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential Malicious File Download"; flow:to_client,established; file_data; content:"MZ";
isdataat:!1,relative; classtype:trojan-activity; sid:4;)Suricata
Suricata - инструмент сетевой безопасности с открытым исходным кодом, который является средствами IDS/IPS и предоставляет мониторинг сетевой активности. Suricata использует сигнатурный анализ для выявления атак в трафике. Сигнатурный анализ основывается на заранее определенных сигнатурах (правилах), описывающих известные атаки и угрозы, IDS/IPS сверяет содержимое пакета на наличие паттернов, определенных в сигнатуре, и срабатывает в случае совпадения с этим паттерном.
Suricata считается логическим продолжением Snort.
Синтаксис правил Suricata
action proto src_ip src_port direction dst_ip dst_port (options; content; classtype; sid; rev; msg;)| Поле | Описание |
|---|---|
action |
Действие, которое предпринимается при срабатывании правила: alert для предупреждения, drop для блокировки трафика |
proto |
Протокол: TCP, UDP, ICMP, IP, HTTP и т. д. |
src_ip, dst_ip |
Адреса источника и назначения |
src_port,dst_port |
Порты источника и назначения |
direc
tion |
Направление трафика: -> для однонаправленного, <-> для двунаправленного |
options |
Дополнительные опции правила, такие как flow для указания направления трафика, content для поиска содержимого в пакетах, flowbits для работы с битами состояния, и другие. |
class
type |
Класс атаки, например, attempted-recon, successful-admin, web-application-attack, и т. д. |
sid |
Уникальный идентификатор сигнатуры |
rev |
Номер версии правила, обновляется каждый раз, когда вендор обновляет сигнатуру |
msg |
Имя правила |
Примеры правил Suricata
Пример 1:
alert tcp any any -> $HOME_NET any (msg:"Port Scan Detected"; flags:S; threshold: type both, track by_src, count 5, seconds 60;)Правило обнаруживает сканирование:
flags:S- правило находит в трафике пакеты TCP SYNtrack by_src,count 5,seconds 60- срабатывает при превышении порогового значения в 5 пакетов от одного источника за 60 секунд
Пример 2:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Suspicious User-Agent (hi)";
flow:established,to_server; http.header; content:"User-Agent|3a 20|hi|0d 0a|";
nocase; classtype:trojan-activity; sid:2018381;
rev:4; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2014_04_10,
deployment Perimeter, former_category HUNTING, signature_severity Major, tag User_Agent, updated_at 2020_04_29;)Правило обнаруживает подозрительный User-Agent "hi" в HTTP-трафике.
Пример 3:
alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE Gimmiv Infection Ping Outbound"; icode:0; itype:8; dsize:20;
content:"abcde12345fghij6789"; reference:url,doc.emergingthreats.net/2008726;
classtype:trojan-activity; sid:2008726; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)Правило обнаруживает троян Gimmiv в ICMP-трафике по строке abcde12345fghij6789.
Пример 4:
alert dns any any -> $HOME_NET any (msg:"ET ATTACK_RESPONSE PowerShell String Base64 Encoded Text.Encoding (ZXh0LkVuY29k) in DNS TXT Reponse"; content:!"v=DKIM";
content:"|00 00 10 00 01 c0 0c 00 10 00 01|"; content:"ZXh0LkVuY29k"; distance:0; fast_pattern; reference:url,github.com/no0be/DNSlivery; classtype:bad-unknown; sid:2043164;
rev:2; metadata:attack_target Client_Endpoint, created_at 2023_01_03, deployment Perimeter, former_category ATTACK_RESPONSE, performance_impact Low, signature_severity Major, updated_at 2023_01_24;)Правило обнаруживает закодированную в base64 cтроку PowerShell в ответе DNS TXT.
Пример 5:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential Malicious File Download"; flow:to_client,established; file_data; content:"MZ";
isdataat:!1,relative; classtype:trojan-activity; sid:4;)Правило обнаруживает попытки загрузки файлов с подозрительным содержимым, начинающимся с сигнатуры MZ, что может указывать на исполняемый файл.
Группы хостов
Suricata и Snort, используют группы хостов для определения, какие узлы сети следует рассматривать в контексте правил. Группы хостов определяются администраторами IDS/IPS.
Рассмотрим некоторые группы:
$HOME_NET - обозначает внутреннюю сеть, которую вы хотите защитить. Это может включать в себя все внутренние IP-адреса и сети организации.
$EXTERNAL_NET - обозначает внешнюю сеть или сети, которые считаются внешними для вашей инфраструктуры. Это может включать в себя весь интернет или определенные сетевые диапазоны, обычно в EXTERNAL_NET берутся все хосты, которые не включены в HOME_NET, то есть $EXTERNAL_NET = !($HOME_NET)
$DNS_SERVERS - определяет серверы DNS
$DC_SERVERS - контроллеры домена
$SMTP_SERVERS - серверы электронной почты
$HTTP_SERVERS - веб-серверы и т.д.
Сравнение Suricata и Snort
| Suricata | Snort | |
| Многопоточность | Многопоточная | Однопоточная |
| Блокировка трафика | + | +/- |
| Сложные переменные | + | +/- |
| Протоколы | + | +/- |
| Действия | дополнительные действия в правилах, такие как reject и replace | alert drop |
| обработка трафика | + | - |
Классификация угроз
Threat Hunting — это проактивный поиск угроз, вредоносной деятельности в компьютерных сетях.
Цель - обнаружении кибератак, которые не могут быть выявлены с помощью традиционных методов защиты (брандмауэры, антивирусные программы). Для этого проводится ручной или автоматизированный поиск и анализ индикаторов компрометации (IoC).
Дополнение к существующей системе защиты. Шаги:
- формулирование гипотезы: предположения о местах, где могут находиться угрозы, используя как внутренние, так и внешние данные
- проверка гипотезы.: гипотезы тестируются путем анализа данных с конечных точек для обнаружения индикаторов компрометации, связанных с новыми вредоносными программами.
Если гипотеза подтверждается, нужно принять меры. Полученная информация также может быть использована для формулирования новых гипотез и улучшения системы защиты, например, для обновления правил фильтрации трафика.
Hunting Maturity Model (HMM - «модель зрелости активного поиска угроз») — это система оценки готовности организации к активному поиску угроз. Существует пять уровней зрелости компании в HMM:
- Начальный уровень: организация полагается в основном на традиционные системы безопасности и собирает минимальное количество информации о ключевых элементах IT-инфраструктуры.
- Минимальный уровень: аналитики регулярно собирают информацию из IT-инфраструктуры и используют данные киберразведки.
- Процедурный уровень: организация использует стандартные процедуры активного поиска угроз, собирает и анализирует большой объем данных, но не разрабатывает собственные процедуры поиска угроз.
- Инновационный уровень: специалисты собирают и анализируют большой объем данных, разрабатывают собственные методы поиска угроз и регулярно их применяют.
- Передовой уровень: специалисты не только разрабатывают методы поиска и анализа угроз, но и автоматизируют их. Благодаря этому выявляется больше угроз, и аналитики могут сосредоточиться на совершенствовании системы обнаружения и защиты организации в целом.
Индикатор компрометации (IoC) – активность или вредоносный объект, обнаруженный в сети или на конечной точке. Возможно идентифицировать индикаторы и улучшить возможности по обнаружению будущих атак вдобавок к используемым корреляционным правилам. Разные типы индикаторов имеют разный срок “жизни” и разный уровень надежности.
Основные типы индикаторов компрометации с показателем надежности:
- IP-адреса - низкий уровень надежности, могут быть ложноположительными, если на одном IP-адресе находится более одного домена.
- Hash (SHA1, SHA256, MD5) - высокий уровень надежности, но злоумышленник может легко внести небольшое изменение в файл для изменения хэш-суммы инструмента для атаки или полезной нагрузки.
- Domain - высокий уровень надежности.
- URL-адреса - высокий уровень надежности.
- Filename (утилиты, библиотеки) - редко используются ввиду низкого уровня ненадежности, но могут быть полезными при поиске скомпрометированных устройств по названиям специфичных файлов в рамках одного домена.
Ресурсы, где можно найти открытые базы индикаторов компрометации:
- https://otx.alienvault.com/
- https://exchange.xforce.ibmcloud.com/
- https://www.dan.me.uk/tornodes
- https://www.abuseipdb.com/
- https://urlhaus.abuse.ch/browse/
- https://opentip.kaspersky.com/
Инструменты для поиска по IOCs
Минус Loki, THOR, YARA - нет централизованного управления. Для распространения утилит по инфраструктуре необходимо будет воспользоваться групповыми политиками (GPO), System Center Configuration Manager(SCCM), Ansible, или с помощью антивирусного решения.
Loki
Это простой IOC и YARA сканнер, который отлично подходит для поиска следов взлома. Loki предоставляет нам четыре способа выявления взлома:
- имена файлов (соответствие регулярному выражению полного пути файла);
- проверка в соответствии с правилами Yara (поиск на соответствие сигнатурам Yara по содержимому файлов и памяти процессов);
- проверка хешей (сравнение просканированных файлов с хешами (MD5, SHA-1, SHA-256) известных вредоносных файлов);
- проверка обратной связи C2 (сравнивает конечные точки технологического соединения с C2 IOC).
Дополнительные проверки:
- проверка файловой системы Regin (через --reginfs);
- проверка аномалий системных и пользовательских процессов;
- сканирование распакованных SWF;
- проверка дампа SAM;
- проверка DoublePulsar — попытка выявить бэкдор DoublePulsar, слушающий порты 445/tcp и 3389/tcp.
Типовыми признаками (Indicators of Compromise) компроментации:
- появление на компьютере malware (вирусов, бэкдоров, троянов, кейлоггеров, крипторов, майнеров и так далее), а также хакерских утилит (например, для исследования сети, эксплуатации уязвимостей, сбора учетных данных). Loki имеет свою базу правил для выявления известных вредоносных объектов и функцию выявления аномалий в расположении файлов с системными названиями;
- появление неизвестных новых исполняемых и других файлов, даже если они не детектируются антивирусным движком как malware-код;
- аномальная сетевая активность (подключение к удаленным хостам, открытие для прослушивания портов неизвестными программами и прочее);
- аномальная активность на дисковых устройствах (I/O) и повышенное потребление ресурсов системы (CPU, RAM, Swap).
THOR
Это сканер IOC и YARA с расширенный функционалом, база более 17 000 сигнатурами YARA, 400 правилам Sigma, многочисленным правилам обнаружения аномалий и тысячам IOC. Так же есть бесплатная, но с ограниченными функциями версия THOR Lite.
Дополнительный функции THOR:
широкая кроссплатформенность с поддержкой Windows, Linux, macOS и AIX;
функция THOR Remote позволяет сканировать несколько конечных систем Windows с одной привилегированной рабочей станции;
поддерживает SIGMA. SIGMA — это унифицированный формат описания правил детектирования, основанных на данных из логов;
поддерживает функцию анализа реестра;
модуль для анализа SHIM Cache, который проверяет содержимое AppCompatCache в системах Windows. Этот модуль позволяет обнаруживать вредоносные или подозрительные записи программ, давно удаленных злоумышленниками;
анализатор именованных каналов(pipe), мьютексов, журналов событий
Комната на TryHackMe для знакомства с THOR Lite
YARA
Это опенсорсный инструмент, который помогает исследователям искать и классифицировать вредоносные семплы и даже проводить Threat Hunting. Утилита выполняет сигнатурный анализ на основе формальных YARA-описаний (правил). В них содержатся индикаторы компрометации для разных типов вредоносного ПО.
Фишка в том, что делать правила легко и не занимает много времени. Именно поэтому YARA используют в AlienVault, Avast, ESET, FireEye, Group-IB, Kaspersky, Trend Micro, Virus Total, x64dbg... В общем, почти все, кто имеет дело с анализом вредоносного ПО.
YARA-правила могут обрабатывать не только исполняемые файлы, но и документы, библиотеки, драйверы — все что угодно. Ими же можно сканировать сетевой трафик, хранилища данных, дампы памяти. Эти правила можно включать в другие инструменты, такие как SIEM, антифишинг, IDS, песочницы.
Инструмент YARA и YARA-правила
Структура правил
Обычно правила хранятся в текстовом формате файла с расширением .yar и состоят из двух секций:
- Секции определений (strings) — содержит характерные для малвари константы, хеши, HEX-фрагменты, ссылки, строки.
- Секции условия (condition) — содержит условия, по которым принимаются решения относительно анализируемого файла.
rule SomeMalwareName
{
meta:
author = "AuthorName"
strings:
…
condition:
…
}Пример отображения секций
Применения YARA
Минимально необходимые секции — это название правила и его условия. Для примера напишем простое правило, в котором будем детектировать объекты только по их imphash:
import "pe"
rule MyLittleAgentTeslaRuleDetect
{
condition:
pe.imphash() == "b21a7468eedc66a1ef417421057d3157" or
pe.imphash() == "f34d5f2d4577ed6d9ceec516c1f5a744"
}Сохраним файл как AT.yar и запустим на директории с семплами Agent Tesla. Посмотрим на результат и убедимся, что правило отработало на всех представителях Agent Tesla:
Результат — все из всех.
Правила YARA поддерживают импорт полезных модулей, соответственно, можно написать свои модули. Ниже представлены наиболее часто используемые:
pe— функции, нужные при работе с объектами Portable Executable, например: контрольная сумма imphash, метка времени создания, расположение секций;hash— расчет контрольных сумм и криптографических хешей;math— математические подсчеты, например: среднее арифметическое или энтропия.
С полным списком модулей можно ознакомиться в официальной документации по YARA.
Создание правил
В опциональной секции определений можно использовать маски (wildcard, подобия регулярных выражений). Таким образом, для шестнадцатеричных строк возможны следующие маски:
- символ
?— наличие любого байта на месте этого символа; - диапазоны (
[4-6]— от 4 до 6 различных байтов); - альтернативы (логическое ИЛИ —
|).
Рассмотрим еще один пример с несколькими правилами и увидим разнообразие возможностей детектирования YARA:
import "hash"
rule RUFUS_found
{
strings:
$HEX_string = { E0 38 D2 21 32 4D 1B C1 79 EC 00 70 76 F5 62 B6 }
condition:
$HEX_string and hash.md5(0, filesize) == "d35936d329ac21ac3b59c525e2054078"
}Правило RUFUS_found— срабатывает при соблюдении двух секций, если будет обнаружен указанный машинный код и совпадет хеш MD5.
Загрузим на хост rufus-2.17p.exe и запустим проверку с нашим правилом MyExe.yar и оценим результат.
По полученному результату видно, что YARA-правило составлено корректно.
Утилиты для автоматической генерации YARA
Для получения правил есть три пути:
- Скачать готовые (официальный репозиторий и агрегаторы правил на GitHub).
- Сделать самому (вариант для энтузиастов).
- Заставить машину сделать их самостоятельно. В этом случае подойдут разные генераторы, например: yabin, YaYaGen, yarGen, BASS.
Для генерации правил они находят уникальные строки во фрагментах вредоносов. Но надо понимать, что это не самый надежный способ, поэтому правила обязательно нужно проверять и корректировать.
Практический пример Threat Hunting
Threat Hunting начинается с построения гипотезы, возьмем гипотезу способов загрузки с зараженного хоста эксплоита, хакерской утилиты или любой другой полезной нагрузки для закрепления или исполнения в системе. В нашей ситуации так же события не направляются в SIEM систему из-за ограничения лицензии в объеме коррелируемых событий, поэтому поиск будем производить в журналах событий самого хоста.
В сети интернет есть ресурс GTFOBins, где описаны встроенные в систему утилиты/команды, которые могут использоваться для двойного назначения, как для выполнения специальных функций свойственных для данных утилит/команд, так и в нашем случае для загрузки в систему.
Самые популярные утилиты для загрузки в систему полезной нагрузки — это curl, wget, ftp,
Возьмем их для начала и выполним поиск по журналу событий auditd с помощью команды grep.
Используем в команде ключ -i , который указывает на регистронезависимый поиск.
Обратные слеши (\) перед оператором чередования (|) используется для экранирования оператора чередования.
Может к счастью, а может и нет, но наш поиск не выдает результатов.
Продолжаем поиск. Проверим следующий список утилит известной для нас командой grep состоящий из scp, smbclient, lwp-download.
На картинке ниже можно увидеть 3 типа события SYSCALL, EXECVE, PATH, которые фиксируют активность c утилитой scp. Если посмотреть на тип события EXECVE, который логирует исполненную командную строку, то можно увидеть, что с помощью команды scp был загружен файл payload в директорию /tmp.
Гипотезы можно строить различные для выявления угроз, успешные из которых следует преобразовывать в корреляционные правила, но это не всегда возможно, в виду большого количества возможных ложных срабатываний (FP), но в таком случае можно оставить гипотезу как сохраненный поисковый запрос для периодического ручного запуска в SIEM.
Противодействие на периметре
Основные этапы от DDOS
- Анализ информации (сбор метрик с сетевого оборудования с учетом информация о пострадавших системах).
- Построение гипотезы о типе атаки и ее цели.
- Противодействие.
Противодействие для малого бизнеса
Общие рекомендации:
- Коммуникация с Интернет-провайдером с целью ограничения пропускной полосы для протоколов, подверженным Amplification атакам, например 53 (dns), 11211 (memcache), 123 (ntp)*
- Восстановить работоспособность офисного сегмента, изменив DNS записи для публикуемых сервисов.
- Если п.2 не помог, запросить изменение IP адреса на WAN интерфейсе или сменить Интернет-провайдера.
- Полный или частичный (proxy) перенос сервисов на облачные площадки (SaaS или VPS).*
Специфично для Flood-атак (когда страдает не канал, а сетевое оборудование)
- Разделение сетевого оборудование на внутреннее и внешнее.*
- Уменьшение сессионных таймаутов.*
- Применение вендор-специфик рекомендаций, например MikroTik: документация, презентация.*
Противодействие для среднего бизнеса
Общие рекомендации, отличные от озвученных ранее и для случаев, если они не помогают или не доступны
- Связаться с поставщиком услуг по защите от DDoS атак.
- Следовать его рекомендациям по передаче права анонсирования вашей /24 сети от их AS.
L7 DDoS-атака или Нарушение работы веб-приложения
В учебном курсе "Профессия - Белый хакер" в разделе 5 "Уровень 2.1. Взлом веб-приложений" описаны основные и часто встречаемые угрозы. Кроме этого существуют различные DDoS атаки, которые нацеленные на уровень приложения. Это может быть и разновидность Slowloris-атак, рассчитанная на медленную коммуникацию по протоколу HTTP после установления ТСР-соединения. Так и спам легитимных запросов, но которые генерят большую нагрузку на сам сервер или бэкенд, например поиск по сайту.
Web Application Firewall
Для противостояния таким угрозам, желательно иметь Web Application Firewall (WAF). В качестве довольно быстрого в развертывании и бесплатного решения мы можем использовать:
- CloudFlare
- ModSecurity (Nginx и Apache2)
- open-appsec (Nginx)
ModSecurity - WAF с открытым исходным кодом, имеющий модули для web серверов на базе apache2 и nginx (End-of-Live 2024), основан на сигнатурном анализе.
CloudFlare - облачный поставщик услуг, бесплатно предоставляющий защиту от DDoS атак и распространенных атак на веб приложение. Так же в бесплатной версии предоставляет возможность создать 10 собственных блокирующих правил. Вероятно, не подойдет для бизнесов, имеющих ограничения на обработку персональных данных или другой чувствительной информации.
open-appsec - новый перспективный ML WAF, как с возможностью локальной установки и управления, так и подключения к облачной Web консоли управления. Имеет как платную, так и бесплатную версии. Последняя сравнима с бесплатным функционалом CloudFlare.
Альтернатива WAF
В случаях, когда WAF по каким-то причинам недоступен, у нас все еще остается возможность:
- Используемые конфигурационные возможности Web сервера
- Приминять Rate Limit правила и в автоматическом режиме банить IP
- iptables
Apache2 - имеет два конфигурируемых параметра: Timeout и KeepAliveTimeout, которые я рекомендовал бы выставить в значения 60 и 5 соответственно, 300 и 15 - значения по умолчанию. Так же у этого сервиса имеется модуль mod_ratelimit, который может контролировать кол-во входящих запросов с IP адреса.
fail2ban - приложение, которые в автоматическом режиме модифицирует правила на локальном firewall, блокируя IP адрес на определенное время. Решение принимается на основе лог файлов аппликейшн. Например, sshd залогировал 5 неуспешных попыток входа с одного ip адреса - fail2ban заблокирует этому IP вход на порт tcp/22 на 10 минут. Аналогичным образом могут отслеживаться попытки входа в админ панели или аккаунты, перечисление каталогов (большое количество ошибок 404) и даже попытки эксплуатаций SQL injection (+SELECT+) или Path Traversal (../../).
iptables - уровень фантастики, но когда ничего другого не остается:
iptables -A INPUT -p tcp --dport 80 -m string --algo kmp --string "+SELECT+" -j DROPОбратите внимание, что этот метод будет работать только с расшифрованным HTTPS, а значит расшифровка SSL должна проходить заранее.