macOS (Security): Аудит LaunchAgents/Daemons на «подозрительные» пути и неподписанные бинарники

Боль: Пользователь жалуется на фантомные процессы. В ~/Library/LaunchAgents лежит «что-то», что перезапускается после удаления.
Реакция админа: «Снесём руками».
Реакция архитектора: «Сначала найдём источник автозапуска и оценим риски.»

Скрипт (Bash). Ищет .plist с исполняемыми из пользовательских/временных директорий, помеченные quarantine или неподписанные бинарники.

#!/usr/bin/env bash
# --- macOS LaunchAgents/Daemons Audit ---
set -euo pipefail

echo "--- Начинаю аудит LaunchAgents/Daemons ---"

dirs=( "$HOME/Library/LaunchAgents" "/Library/LaunchAgents" "/Library/LaunchDaemons" )

for d in "${dirs[@]}"; do
  [ -d "$d" ] || continue
  while IFS= read -r -d '' plist; do
    program=$(/usr/libexec/PlistBuddy -c 'Print :Program' "$plist" 2>/dev/null || true)
    if [ -z "${program:-}" ]; then
      program=$(/usr/libexec/PlistBuddy -c 'Print :ProgramArguments:0' "$plist" 2>/dev/null || true)
    fi

    suspicious=""
    unsigned=""
    quarantine=""

    if [ -n "${program:-}" ]; then
      dir=$(dirname "$program")
      # Подозрительные пути: пользовательские/временные директории
      if [[ "$program" =~ ^/Users/ ]] || [[ "$program" =~ ^/tmp/ ]] || [[ "$program" =~ ^/private/tmp/ ]]; then
        if [ -w "$dir" ]; then suspicious="user-writable"; fi
      fi
      # quarantine-атрибут
      if [ -f "$program" ] && xattr -p com.apple.quarantine "$program" >/dev/null 2>&1; then
        quarantine="quarantined"
      fi
      # неподписанность
      if [ -f "$program" ]; then
        if ! codesign -dv "$program" >/dev/null 2>&1; then unsigned="unsigned"; fi
      fi
    fi

    if [ -n "$suspicious$quarantine$unsigned" ]; then
      echo "plist: $plist"
      echo "  Program: ${program:-<none>}"
      echo "  Flags: $suspicious $quarantine $unsigned"
      echo "----------------------------------------"
    fi
  done < <(find "$d" -name '*.plist' -print0 2>/dev/null)
done

echo "--- Аудит завершен ---"
echo "Рекомендация: бэкапнуть plist и бинарь, затем удалить через launchctl (disable/unload), проверить персистентность."

Взгляд архитектора: Постоянство (persistence) — базовая TTP вредоносов. Мы валидируем автозапуски против критериев доверия пути/подписи/карантина, а не «по чувствам».

#macos #security #incident_response #forensics #bash #скрипты

🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей

Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.

Это не героизм. Это провал организации процесса.

Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.

Три кита нормального on-call:

Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.

ШАБЛОН МАТРИЦЫ ЭСКАЛАЦИИ

Уровень 1 (0–15 мин):  Дежурный инженер (primary)
  -> Автоматический runbook, первичная диагностика

Уровень 2 (15–30 мин): Дежурный инженер (secondary)
  -> Подключается если primary не отвечает или нужна помощь

Уровень 3 (30–60 мин): Тимлид / старший инженер
  -> Техническое решение нестандартной ситуации

Уровень 4 (60+ мин):   Руководитель
  -> Только для бизнес-решений: откат релиза,
     уведомление клиентов, привлечение вендора

ПРАВИЛО: каждый уровень получает уведомление автоматически.
Никакого "позвони сам если не справляешься" — это перекладывание
ответственности на усталого человека в 3 ночи.

Второе — алерты, которые требуют действия. Каждый алерт должен отвечать на один вопрос: "нужно ли действие прямо сейчас?" Усталость от алертов возникает из плохого соотношения сигнал/шум.

Аудит алертов раз в квартал — три категории:

[ACTIONABLE]  Алерт требует действия в течение 15 минут.
              Будит людей. Должен быть в PagerDuty/Grafana OnCall.

[WATCHFUL]    Алерт требует внимания в рабочее время.
              Тикет в очередь, не звонок ночью.

[NOISE]       Алерт не требует никаких действий.
              Отключить немедленно.

Реальная статистика большинства команд при честном аудите:
- 20% алертов — ACTIONABLE
- 30% — WATCHFUL
- 50% — NOISE (которые будят людей ночью годами)

Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.

Шаблон постмортема за 30 минут:

## Постмортем: [Название инцидента] | [Дата] | Severity: P[1-3]

### Что случилось (2-3 предложения)
### Timeline (с точными временными метками)
### Влияние на пользователей и бизнес
### Root Cause (система/процесс, не человек)
### Что сработало хорошо
### Что нужно улучшить
### Action items:
  | Задача | Владелец | Дедлайн |
  |--------|----------|---------|
  | ...    | ...      | ...     |

ЗАПРЕЩЁННЫЕ ФОРМУЛИРОВКИ:
  ❌ "Инженер не заметил алерт"
  ✅ "Алерт не имел достаточного приоритета в системе"
  ❌ "админ забыл обновить конфиг"
  ✅ "Процедура деплоя не включала проверку конфигурации"

Зачем это нужно:
Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся.

Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация.

#skills #oncall #incident #postmortem #sysadmin #sre #admin_future