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

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 Docker

Настройка 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

SecRule VARIABLES "OPERATOR" "TRANSFORMATION"

VARIABLES	Переменные, к которым применяется правило.
OPERATOR	Оператор, определяющий, как правило будет применяться к переменным.
TRANSFORMATION	Модификаторы, которые могут быть применены к переменным перед сравнением.

Переменные (VARIABLES)

• REQUEST_URI: URI запроса;
• ARGS: параметры запроса;
• REQUEST_BODY: тело запроса;
• REQUEST_COOKIES - куки;
• REQUEST_HEADERS - заголовки;
• XML - XML код в запросе.и т.д.

Операторы (OPERATOR)

• @contains: содержит указанное значение;
• @rx: совпадает с регулярным выражением;
• @eq: равно указанному значению и другие.

Модификаторы (TRANSFORMATION)

SecRule ARGS "password" "@rx (?i)password" "id:2,phase:2,t:none,t:lowercase,t:urldecode,t:replaceComments"

• t:none: Отключить все стандартные преобразования;
• t:lowercase: Преобразовать в нижний регистр;
• t:urldecode: Декодировать URL;
• t:replaceComments: Удалить комментарии.
  

Дополнительные опции

SecRule REQUEST_METHOD "@streq POST" "id:3,phase:2,chain,t:none,pass,nolog"

SecRule REQUEST_URI "@rx /login" "t:none,t:urldecode,t:replaceComments"

• chain: Связывает два правила так, что следующее применяется только если предыдущее сработало;
• pass: Продолжить выполнение правил вне зависимости от результата текущего;
• nolog: Не записывать событие в лог.

Примеры правил ModSecurity

Пример 1:

SecRule ARGS "password" "@rx (?i)password" "id:123,deny,status:403,msg:'Password leakage detected'"

ARGS: обращение к параметрам запроса
@rx: оператор совпадения с регулярным выражением
id: идентификатор правила
deny: действие с запросом - запретить
status: HTTP-статус ответа при срабатывании правила - 403
msg: название правила - 'Password leakage detected'

Данное правило ищет в параметрах запроса "password" и срабатывает при его обнаружении.

Пример 2:
SecRule ARGS "@rx ^(?:\'|\"|%27|%22|%3E|%3C|%3D|%3B|%20or%20|union|select|insert|update|delete|drop)" \

"id:1,phase:2,deny,msg:'SQL Injection Attack'"

Правило ищет SQL-инъекции в параметрах запроса (ARGS) и блокирует запрос, если обнаруживается соответствие с паттерном.

Пример 3:
SecRule REQUEST_COOKIES|REQUEST_HEADERS|ARGS|XML:/* \

"(<|%3C)([^sS]*s[sS]*c[cC]*r[rR]*i[iI]*p[pP]*t[tT]*)(>|%3E)" \

"id:2,phase:2,t:none,deny,msg:'Cross-site Scripting (XSS) Attack'"

Правило обнаруживает попытки вставки скриптов в запросы (XSS) и блокирует их.

Пример 4:
SecRule FILES_TMPNAMES "@inspectFile /etc/passwd" \

"id:3,phase:2,t:none,deny,msg:'Attempt to access /etc/passwd'"

Правило анализирует временные файлы, загруженные на сервер, и блокирует запрос, если в содержимом обнаруживается попытка доступа к файлу /etc/passwd.

Пример 5:
SecRule RESPONSE_BODY "@contains 'Invalid password'" \

"id:5,phase:4,t:none,log,deny,msg:'Password brute force attempt'"

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

Как писать правила ModSecurity

ModSecurity Core Rule Set (CRS) — это набор правил, разработанный сообществом Open Web Application Security Project (OWASP) для использования с ModSecurity. Эти правила предназначены для обеспечения базовой защиты от различных видов популярных веб-атак. Вам не всегда нужно создавать свои собственные правила, так как CRS уже предоставляет обширный набор правил, охватывающих множество сценариев атак.

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

1. Определите цель правила
Определите, какую атаку или вид активности вы хотите обнаруживать.
Решите, на какую часть HTTP-запроса (например, заголовки, тело запроса, параметры запроса) должно применяться правило.
2. Создайте правило
Определите фазу, на которой будет выполняться правило (например, phase:1 или phase:2).

Используйте документацию ModSecurity для создания правила, например:

SecRule REQUEST_HEADERS:User-Agent "@contains badbot" "id:1001,phase:2,deny,msg:'Bad Bot Detected.'" 

                  
Это правило запрещает запросы с User-Agent, содержащим строку "badbot" в заголовках.

3. Тестируйте правило
Включите правило и протестируйте его - нужно убедиться, что правило срабатывает на атаки и не фолсит.
Используйте инструменты для тестирования веб-безопасности (например, burp suit), чтобы проверить, как правило реагирует на различные виды запросов.
Если правило срабатывает не так, как хотелось бы, или блокирует легитимные запросы, исправьте его, чтобы снизить ложные срабатывания.
Просматривайте логи ModSecurity для выявления проблем и улучшения правил.
4. Документируйте
Добавьте комментарии к правилу, объясняющие его цель и предназначение.
Ведите документацию, чтобы другие коллеги могли легко понять, почему правило было создано.
Другой пример правила, предназначенного для блокировки SQL-инъекций:

SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/* "@rx (?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))" "phase:2,deny,status:403,id:1002,msg:'SQL Injection attempt.'" 

Это правило проверяет параметры запроса, заголовки и XML-данные на наличие попыток SQL-инъекций.

анализ логов 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&param2=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;)
                  

Примеры правил 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 SYN
• track 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
обработка трафика	+	-