YARA-X строже проверяет фигурные скобки

При переносе правил с YARA 4.x обратите внимание на литерал { в регулярных выражениях. В YARA-X вне оператора повторения его нужно экранировать:

/abc{/ → /abc\{/

Строгая проверка помогает поймать и опечатку {1:5} вместо {1,5}. YARA 4.x могла принять ошибочную конструкцию за буквальный текст.

Флаг --relaxed-re-syntax ослабляет проверку. Он не превращает такую опечатку в нужное повторение. Есть и другие различия: строка с модификатором base64 должна содержать минимум 3 символа.

После компиляции проверьте правила на положительных и отрицательных образцах. Успешная компиляция ещё не означает, что правила находят те же совпадения.

Различия YARA и YARA-X
#patch_notes

Библиотека хакера

Уязвимый магазин для своей лаборатории

OWASP Juice Shop специально содержит уязвимости для обучения и CTF. В исходном ролике авторов видны магазин и Score Board с заданиями.

Локальный запуск из README:

docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Затем откройте http://localhost:3000. Привязка порта к loopback нужна, чтобы заведомо уязвимый стенд не слушал внешние интерфейсы. Для занятия выберите одну задачу и сравните поведение приложения до и после её решения.

Публичная демоверсия предназначена для знакомства и проверки развёртывания. Проводить на ней собственные атаки авторы прямо запрещают. Практику проводите в собственной локальной копии.

README и варианты запуска
#ctf_challenge

Библиотека хакера

Для Sigma в EVTX нужен mapping

Chainsaw ищет по журналам событий Windows без развёртывания SIEM. Для Sigma нужны правила и mapping, который указывает поля журнала для сопоставления.

В примере авторов:

./chainsaw hunt EVTX-ATTACK-SAMPLES/ -s sigma/ --mapping mappings/sigma-event-logs-all.yml

Все три пути должны существовать. Начиная с версии 2 Sigma и EVTX samples не включены как submodules. Их берут отдельно либо используют подходящий all-in-one release.

Проверьте в выводе, сколько правил загрузилось. В примере README часть правил не загрузилась. Переданный каталог ещё не означает, что проверены все правила. Совпадение требует разбора контекста. Пустой результат не доказывает, что endpoint чист.

Примеры Chainsaw
#tool_of_the_week

Библиотека хакера

Пункт ASVS: номер вместе с версией

Номер требования может измениться между выпусками. Поэтому в отчёте или задаче полезнее запись v5.0.0-1.2.5, чем просто 1.2.5: она привязывает требование к конкретной версии ASVS.

Это рекомендуемый авторами формат. В примере ASVS 5.0.0 пункт относится к защите от OS command injection. На карточке разобраны части идентификатора.

Для проверки по конкретному выпуску берите стабильный tag v5.0.0. Ветка master содержит рабочие изменения. В репозитории есть и CSV с требованиями, если нужно перенести их в собственный чек-лист.

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

Зафиксированный выпуск ASVS 5.0.0
#resource_drop

Библиотека хакера

Что именно сообщает secret-scanning alert

GitHub различает три типа уведомлений о секретах. Они отличаются причиной срабатывания и получателем.

— User alert: в репозитории найден поддерживаемый секрет. Повтор одного секрета несколько раз в одном файле даёт один alert.
— Push protection alert: участник обошёл push protection репозитория. Такие события можно найти фильтром bypassed: true. При обходе только персональной защиты alert не создаётся, если защита самого репозитория выключена.
— Partner alert: GitHub уведомил провайдера из партнёрской программы об утечке в публичном репозитории или npm-пакете. В Security and quality репозитория это уведомление не показывается.

Сам alert ещё не доказывает, что найденные учётные данные действуют или что ими воспользовались. GitHub предупреждает, что среди generic- и AI-alerts может быть больше ложных срабатываний и секретов из тестов.

Типы alerts и границы обнаружения в GitHub Docs

Библиотека хакера

SF в Zeek: нормальное завершение TCP-соединения

В TCP-записи conn.log статус SF в поле conn_state означает нормальное установление и завершение соединения. В примере документации обе стороны закрыли его через FIN. О безопасности переданных данных этот статус ничего не говорит.

Выбирайте поля записи под вопрос расследования. id.orig_h и id.resp_h показывают стороны, порты уточняют конечные точки, duration — длительность. orig_bytes и resp_bytes описывают объём полезной нагрузки по направлениям, а поля с ip_bytes — объём на IP-уровне.

Не смешивайте service и ip_proto. Первое — распознанный прикладной протокол. Второе — номер IP-протокола, в том числе для потоков вроде OSPF. Поле появилось в Zeek 7.1.

Дальше берите uid и ищите связанную активность в других журналах Zeek. Выводы ограничены пакетами, которые видел сенсор. Для UDP тот же SF трактуется иначе, чем для TCP.

Разбор TCP- и UDP-записей в Book of Zeek
#cheat_sheet

Одного ingress-разрешения для Pod может быть мало

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

Ingress и egress независимы. Пока Pod не выбран политикой для конкретного направления, ограничения NetworkPolicy в этом направлении не действуют. Ответный трафик разрешённого соединения допускается неявно.

Разрешения всех применимых политик объединяются. Добавление ещё одной политики с узким списком не отменяет более широкое разрешение из другой. Порядок политик этого не меняет.

Всё это работает только с сетевым плагином, реализующим NetworkPolicy. Поведение для hostNetwork зависит от реализации. Схема показывает обычное соединение Pod → Pod при изоляции обеих сторон.

Модель NetworkPolicy и её ограничения
#cheat_sheet

User namespace ещё не означает rootless Docker

При проверке прав Docker смотрите и на daemon. В режиме userns-remap он остаётся root, хотя UID и GID контейнеров отображаются через user namespace.

В rootless mode и daemon, и контейнеры работают внутри user namespace без root-привилегий на хосте.

У rootless есть предварительные требования: newuidmap и newgidmap на хосте, минимум 65 536 subordinate UID и столько же GID для пользователя в /etc/subuid и /etc/subgid. Утилиты отображения ID — оговорённое документацией исключение из правила об отсутствии SETUID-бинарников и file capabilities.

Если системный rootful daemon уже запущен, настройка rootless сама по себе его не отключает.

Устройство rootless mode и требования к хосту

Библиотека хакера

Что ProtectSystem оставляет за пределами read-only

В режиме strict директива ProtectSystem делает иерархию файловой системы read-only для процессов unit, но исключает API-поддеревья /dev, /proc и /sys. Для них предусмотрены отдельные ограничения.

Есть и явно разрешённые пути записи. Их задают ReadWritePaths, StateDirectory, LogsDirectory и связанные настройки. При включённом PrivateTmp временные каталоги остаются доступными для записи. А read-only каталог сам по себе не запрещает общение с AF_UNIX-сокетом внутри него.

Файловые ограничения дополняют другими механизмами. NoNewPrivileges запрещает процессу и его потомкам получать новые привилегии через execve. SystemCallFilter ограничивает системные вызовы через seccomp. Действие NoNewPrivileges не распространяется на процессы, запущенные по запросу через отдельный IPC-сервис.

Эффект зависит от доступных механизмов ядра, контекста запуска и версии systemd. Состав групп syscall тоже меняется между версиями. Часть настроек без нужной поддержки отключается, а привилегированный процесс может отменить файловые ограничения. Набор директив нужно проверять на конкретном сервисе.

Sandboxing и исключения в systemd.exec

Тело Secret может оказаться и в audit log

Уровень аудита Kubernetes определяет, какие данные API-запроса попадут в журнал.

Metadata сохраняет пользователя, время, ресурс, verb и другие метаданные без тел запроса и ответа. Request добавляет тело запроса. RequestResponse — ещё и тело ответа. Последние два уровня в части тел не применяются к non-resource requests. None отключает запись совпавшего события.

Правила читаются по порядку, уровень задаёт первое совпадение. В официальном примере для Secrets выбран Metadata. При проверке policy важно выяснить, не попадут ли чувствительные значения вместе с телами в хранилище логов.

Policy определяет состав события, backend сохраняет его в файл или отправляет webhook. Нужно проверять оба: без audit-policy-file события не записываются, а переполнение буфера экспорта может приводить к потерям. Аудит также расходует память API server на контекст запросов.

Это журнал действий через Kubernetes API. Для расследования сетевого обмена внутри Pod потребуются другие данные.

Уровни, порядок правил и экспорт Kubernetes audit

В pg_hba.conf нет запасного правила после отказа

PostgreSQL выбирает первую строку, совпавшую по типу соединения, адресу клиента, базе и пользователю. Затем применяет указанный в ней метод аутентификации. При отказе аутентификации PostgreSQL не пробует следующую строку. Нет совпадений — доступ запрещён.

Поэтому более строгое правило ниже широкого совпадения может вообще не участвовать в проверке. Подключённые файлы не меняют этот порядок: их содержимое вставляется на месте include. Для include_dir важен ещё и порядок имён файлов по правилам C locale.

Отдельно смотрите на тип соединения. host совпадает и с SSL, и без него. hostssl требует SSL-соединения, поддержки SSL в сервере и включённого параметра ssl. Иначе такая строка игнорируется с предупреждением.

Прохождение HBA не заменяет право CONNECT к базе. Схема — только о выборе правила, по документации PostgreSQL 18.

Порядок проверки pg_hba.conf

Страшный сон любой компании — взлом.

Что делать в первые часы и какие процессы восстанавливать в первую очередь? А если злоумышленники ещё внутри?
Серия видеоподкастов «НЕ ЗАЩИЩЕНЫ. 24 часа после взлома» — это опыт работы команды «Инфосистемы Джет» на 100+ крупных инцидентах.

🔹Взлом произошёл. Что происходит с инфраструктурой, кто принимает решения и на чём теряется драгоценное время.
🔹Контроль возвращён, но бизнес ещё стоит. Как определять приоритеты восстановления и работать под давлением, когда полной картины нет.
🔹Взлом глазами хакера. Как атакующие выбирают цель, закрепляются в инфраструктуре и на какие ошибки команд рассчитывают.
🔹Как компании переживают взлом. Ошибки, работа команд под давлением и какие решения помогают снизить негативные последствия
🔹Атака позади. Что в защите требует пересмотра и как превратить пережитый инцидент в опыт, а не просто в отчёт.

Смотреть выпуски.

Тише алерты — меньше атак?

После настройки порогов Suricata лента может опустеть, хотя пакеты продолжают совпадать с правилом. В документации Suricata 8.0.0 полезно сравнить три механизма:

• threshold: type limit ограничивает число алертов за заданное окно.
• threshold: type threshold выдаёт алерт на каждое C-е совпадение и сбрасывает счётчик. При заданном окне C совпадений должны уложиться в него.
• detection_filter после достижения порога выдаёт алерт на каждое следующее совпадение.

При этом действия drop в IPS и reject применяются к каждому совпавшему пакету, независимо от порога алертов. Поэтому при разборе трафика проверяйте отдельно уведомления и действия с пакетами. По тишине в ленте нельзя судить, исчез ли трафик.

Разбор порогов в Suricata 8.0.0

Библиотека хакера #cheat_sheet