auditd для перехвата execve

# Установка правил auditd для логирования выполнения команд
# /etc/audit/rules.d/command-logging.rules

# Логировать все вызовы execve для пользователей с UID >= 1000
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_commands
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k user_commands

# Логировать выполнение конкретных утилит
-w /usr/bin/curl -k network_download
-w /usr/bin/wget -k network_download
-w /usr/bin/nc -k network_tool
-w /usr/bin/bash -k shell_execution
-w /usr/bin/python3 -k script_execution

# Исключить системные службы для снижения шума
-a never,exit -F arch=b64 -S execve -F auid=0 -F exe=/usr/sbin/sshd
-a never,exit -F arch=b64 -S execve -F auid=0 -F exe=/usr/sbin/cron

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

bash_history и его ограничения

HISTFILE сохраняет команды после завершения сессии, но имеет уязвимости: пользователь может очистить историю, отключить запись через HISTSIZE=0, использовать приватные сессии.

# Усиление bash_history через /etc/profile.d/audit.sh

# Запрет отключения истории
readonly HISTSIZE=10000
readonly HISTFILESIZE=20000
export HISTTIMEFORMAT="%F %T "

# Отправка команд в syslog в реальном времени
export PROMPT_COMMAND='logger -t bash_history -p local6.info "USER=$(whoami) PWD=$PWD CMD=$(history 1)"'

# Запрет на редактирование переменных
readonly PROMPT_COMMAND

PROMPT_COMMAND отправляет каждую команду в syslog до её выполнения. Это даёт реальное время логирования, но требует доверия к пользователю — он может обойти через запуск другой оболочки.

process accounting (acct/psacct)

# Установка и настройка process accounting
apt install acct  # или yum install psacct
systemctl enable acct
systemctl start acct

# Просмотр выполненных команд
lastcomm --user username
lastcomm --command bash
lastcomm --exec /usr/bin/curl

# Экспорт в читаемый формат
acctdump /var/log/account/pacct | grep "2026-02-27"

Process accounting записывает метаданные выполнения: имя команды, пользователь, время старта/финиша, коды завершения. Не хранит аргументы командной строки, но полезен для ретроспективного анализа.

eBPF для продвинутого мониторинга

eBPF-программы позволяют перехватывать события выполнения с минимальным overhead и гибкой фильтрацией. Требуют ядра 4.x+ и root-доступа для загрузки программ.

# Пример eBPF-скрипта через bpftrace для логирования exec
bpftrace -e '
tracepoint:syscalls:sys_enter_execve
/uid >= 1000/
{
  printf("%s %s executed by uid %dn", comm, str(args->argv[0]), uid);
}'

# Альтернатива через falco с правилами
- rule: Shell spawned in container
  desc: Detect shell execution in container
  condition: >
    spawned_process and container
    and shell_procs
  output: "Shell spawned in container (user=%user.name container=%container.id)"
  priority: WARNING

Пример правила корреляции

rule: suspicious_powershell_chain
description: Обнаружение цепочки PowerShell с загрузкой и выполнением
conditions:
  - event_type: powershell_script
  - script_content MATCH "(IEX|Invoke-Expression|DownloadString|WebClient)"
  - count >= 2
  - time_window: 5m
  - group_by: [user, host]
actions:
  - severity: high
  - alert: true
  - enrich:
      - user_risk_score
      - process_tree
  - notify: soc_team

Это правило срабатывает при двух и более PowerShell-скриптах с признаками загрузки кода за 5 минут от одного пользователя. Система добавляет оценку риска пользователя и строит дерево процессов для контекста.

Сценарии для детектирования

[✓] Последовательность: процесс с аргументами -EncodedCommand → загрузка файла → выполнение — почему: типичный паттерн fileless-атаки через PowerShell

[✓] Команда curl/wget с последующим chmod +x и запуском — почему: признак загрузки и выполнения внешней утилиты

[✓] Выполнение certutil -decode или bitsadmin /transfer — почему: легитимные утилиты, часто используемые для обхода защиты

[ ] Массовое выполнение find/grep по чувствительным путям — почему: может указывать на поиск данных, но требует контекста роли пользователя

Паттерны для маскирования

# Пример Grok-паттерна для Logstash для маскирования секретов
filter {
  if [event_type] == "process_create" or [event_type] == "exec_command" {
    mutate {
      gsub => [
        "cmdline_args", "(?i)(password|passwd|pwd|token|api[_-]?key|secret)[=:s]+[^s]+", "1=***",
        "cmdline_args", "(?i)(Bearer|Basic)s+[A-Za-z0-9+/=]+", "Authorization: ***",
        "cmdline_args", "(?i)https?://[^:]+:[^@]+@", "https://***:***@"
      ]
    }
  }
}

# Альтернатива через Lua-скрипт в Fluentd
function filter(tag, time, record)
  if record["cmdline_args"] then
    record["cmdline_args"] = record["cmdline_args"]
      :gsub("(password|token|secret)[=:%s]+[^%s]+", "%1=***")
      :gsub("(https?://)[^:]+:[^@]+@", "%1***:***@")
  end
  return true, record
end

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

Контроль доступа к логам

[✓] Разделение ролей: сбор, анализ, администрирование — разные учётные записи — почему: предотвращает злоупотребление привилегиями одним пользователем

[✓] MFA для доступа к интерфейсу и API — почему: блокирует использование украденных учётных данных

[✓] Аудит действий администраторов самой системы логирования — почему: обеспечивает подотчётность тех, кто имеет доступ к доказательной базе

[✓] Шифрование данных в покое и при передаче — почему: защищает от утечки при компрометации хранилища или перехвате трафика