Windows: Охота на "невидимых". Скрипт для поиска WMI-персистентности

Боль: Ваш EDR/антивирус молчит, но сервер "тормозит" и генерирует странный трафик. Вы не находите .exe или подозрительных служб. Вероятно, вы столкнулись с "бесфайловой" (Fileless) атакой.

Один из любимых методов хакеров — WMI Event Subscription. Злоумышленник "говорит" WMI: "Когда любой пользователь залогинится, пожалуйста, запусти этот powershell -enc ...". Это невидимая автозагрузка.

Реакция админа: Переустановить ОС.
Реакция архитектора: Найти и удалить подписку.

Этот PowerShell-скрипт (на CIM) сканирует "сердце" WMI (`root\subscription`) и показывает вам все активные WMI-подписки.

Код скрипта:
PowerShell

Write-Host "--- Начинаю поиск постоянных (Permanent) WMI-подписок ---" -ForegroundColor Cyan

# Мы ищем три компонента, из которых состоит атака:
# 1. __EventFilter: "За каким событием следить?" (e.g., "logon")
# 2. __EventConsumer: "Что запустить?" (e.g., "powershell.exe ...")
# 3. __FilterToConsumerBinding: "Как они связаны?"

$Namespace = "root\subscription"

Write-Host "`n[+] 1. Поиск Фильтров (__EventFilter):" -ForegroundColor Yellow
$Filters = Get-CimInstance -Namespace $Namespace -ClassName "__EventFilter"
$Filters | Select-Object Name, Query

Write-Host "`n[+] 2. Поиск 'Потребителей' (__EventConsumer):" -ForegroundColor Yellow
$Consumers = Get-CimInstance -Namespace $Namespace -ClassName "__EventConsumer"
$Consumers | Select-Object Name, __CLASS

Write-Host "`n[+] 3. Поиск Связей (Binding):" -ForegroundColor Yellow
$Bindings = Get-CimInstance -Namespace $Namespace -ClassName "__FilterToConsumerBinding"
$Bindings | Select-Object Filter, Consumer

Write-Host "`n--- Проверка завершена ---"
Write-Host "Задача: Вручную проверьте все, что не является 'Microsoft' или вашим ПО (e.g., 'Dell')."

Взгляд архитектора: Это — проактивный Threat Hunting. 99% админов никогда не заглядывают в WMI-подписки. Вы должны. Если вы видите здесь что-то "неродное", особенно CommandLineEventConsumer — вы, скорее всего, нашли активную угрозу.

#windows #powershell #security #threat_hunting #wmi #cybersecurity #скрипты #architect

Linux: "Куда делся диск?" Скрипт для поиска "призрачных" файлов

Боль: Вы запускаете df -h и видите Use% 99% на разделе /var. Вы запускаете du -sh /var... и он показывает, что занято только 50%. Где остальные 49%?!

Ответ: Это "файлы-призраки". Процесс (например, nginx или java`) держит лог-файл открытым, а `logrotate в это время его rm (удалил). Файл исчез с диска, но пространство не освободится, пока процесс держит его "в памяти".

Реакция админа: reboot сервера.
Реакция архитектора: Найти "призрака" с lsof и освободить место без перезагрузки.

Этот Bash-скрипт использует lsof для поиска всех файлов, которые помечены как (deleted) , но все еще удерживаются процессами.

Код скрипта:
Bash

#!/bin/bash
# --- Поиск "призрачных" файлов (deleted but held open) ---

echo "--- Начинаю поиск файлов, удаленных, но удерживаемых процессами... ---"
echo "PID    USER     COMMAND     SIZE(MB)   FILE"
echo "----------------------------------------------------------------------"

# 1. lsof +L1: Найти файлы с link count < 1 (классический "призрак")
# 2. awk: Форматируем вывод, чтобы показать PID, User, Command, Size
# 3. sort: Сортируем по размеру (7-е поле, numeric-reverse)
# 4. head: Показываем топ-15

lsof +L1 -n | \
    awk '
    { 
        size_mb = $7 / (1024*1024); 
        if (size_mb > 1) { 
            printf "%-7s %-10s %-15s %-10.2f %s\n", $2, $3, $1, size_mb, $9 
        } 
    }' | \
    sort -k4 -nr | \
    head -n 15

Как использовать:
1. Сохраните как find_ghosts.sh и chmod +x find_ghosts.sh.
2. sudo ./find_ghosts.sh
3. Результат: Вы увидите, что PID 1234 (java) держит файл app.log (deleted) размером 10240 MB.
4. Решение: systemctl restart java-app.service. (Перезапуск процесса, а не всего сервера).

Взгляд архитектора: Вы не "гадаете", вы диагностируете. Вы понимаете, как VFS (Virtual File System) в Linux работает с inode и file descriptors . Это глубокое знание системы, которое отличает инженера от "эникейщика".

#linux #bash #sre #diagnostics #lsof #storage #скрипты #гайд

Linux: `systemd-nspawn` — контейнеры без Docker

Боль: Вам нужно быстро протестировать скрипт или сервис на "чистой" Ubuntu 24.04, но у вас RHEL. Вы не хотите ставить Docker, настраивать daemon.json или разворачивать тяжелую VM.

Решение: systemd-nspawn Это "секретное оружие" systemd . По сути, это chroot на стероидах, который встроен в вашу ОС. Он запускает легковесные контейнеры, используя то же ядро, но с полной изоляцией процессов и файловой системы.

Как это работает (на пальцах):

1. Создаем образ ОС (например, Ubuntu):
Bash

# (Нужен `debootstrap`)
sudo debootstrap jammy /srv/ubuntu-jammy

2. Запускаем контейнер:
Bash

# -D = директория
# -b = загрузиться в контейнер (boot)
sudo systemd-nspawn -D /srv/ubuntu-jammy -b

Готово. Вы в полноценной Ubuntu, которая запущена как сервис systemd .

Взгляд архитектора: Это идеальная "песочница" для отладки. Вы получаете полную, загружаемую ОС-контейнер без оверхеда Docker-демона. systemd-nspawn — лучший инструмент для тестирования systemd -юнитов и проверки скриптов в чистой среде перед "раскаткой" в прод.

#linux #systemd #container #devops #sre #гайд

Security: `Nmap Scripting Engine (NSE)` — когда `nmap` становится "хакерским"

Боль: Вы сканируете сервер: nmap -p 80 192.168.1.10 . PORT 80/tcp OPEN . И что? Эта информация бесполезна. Открытый порт — это не уязвимость.

Решение: `Nmap Scripting Engine (NSE)` Это встроенный в nmap движок на LUA, который превращает сканер портов в активный сканер уязвимостей.

3 команды, которые меняют всё:
1. "Базовый" скриптовый скан:
Bash

# -sC или --script=default
# Запускает "безопасный" набор скриптов: ищет анонимный FTP, версию SSH, http-title
nmap -sC 192.168.1.10

2. Охота на "низко висящие фрукты":
Bash

# --script=vuln
# Ищет САМЫЕ ИЗВЕСТНЫЕ уязвимости (Heartbleed, Shellshock, SMB MS17-010)
sudo nmap -sV --script=vuln 192.168.1.10

3. Поиск конкретной уязвимости:
Bash

# Проверяем ВСЕ веб-серверы в сети на уязвимость Log4Shell
nmap -p 80,443,8080 192.168.1.0/24 --script=http-log4shell

Взгляд архитектора: Вы переходите от "Network Discovery" (обнаружение сети) к "Vulnerability Auditing" (аудит уязвимостей). Вы смотрите на свою сеть глазами атакующего, что является основой проактивной защиты.

#security #nmap #cybersecurity #pentest #networking #гайд #musthave

AD: "Путь к Domain Admin". Аудит путей атаки с PowerShell

Боль: Вы запустили BloodHound и увидели 50 "красных" путей к правам Domain Admin. Вы в ужасе. Что делать дальше?

Реакция админа: "Закрою 1-2 самые очевидные дыры".
Реакция архитектора: Начать систематический аудит "Control Paths" (путей контроля).

Атака BloodHound — это не магия. Это злоупотребление "опасными" правами (ACL), которые вы сами раздали. Самые опасные — GenericAll , GenericWrite , WriteDacl .

Этот PowerShell-скрипт (на модуле ActiveDirectory ) — оборонительный BloodHound . Он найдет, кто имеет "опасные" права на ваш самый ценный объект — группу "Domain Admins".

Код скрипта:
PowerShell

Import-Module ActiveDirectory

Write-Host "--- Начинаю аудит 'опасных' ACL на группе 'Domain Admins' ---" -ForegroundColor Cyan

$DAMinGroupDN = (Get-ADGroup "Domain Admins").DistinguishedName
$ACLs = (Get-Acl "AD:$DAMinGroupDN").Access

# Список "смертельных" прав, которые дают полный контроль
$DangerousRights = @(
    "GenericAll",
    "GenericWrite",
    "WriteDacl",
    "WriteProperty",
    "WriteOwner"
)

# Ищем всех, у кого есть эти права, КРОМЕ "ожидаемых" (Админы, SYSTEM...)
$SuspiciousACLs = $ACLs | Where-Object {
    ($_.ActiveDirectoryRights -in $DangerousRights) -and
    ($_.IdentityReference -notin @("NT AUTHORITY\SYSTEM", "BUILTIN\Administrators", "CORP\Domain Admins"))
}

if ($SuspiciousACLs.Count -gt 0) {
    Write-Host "`n[!!!] ОБНАРУЖЕНЫ КРИТИЧЕСКИЕ ПУТИ АТАКИ:" -ForegroundColor Red
    $SuspiciousACLs | Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType
} else {
    Write-Host "`n[OK] 'Лишних' прав на группе Domain Admins не найдено." -ForegroundColor Green
}

Взгляд архитектора: Вы не "ищете" уязвимость. Вы валидируете вашу Admin Tier Model. Этот скрипт — ваш первый шаг к "очистке" AD-безопасности.

#windows #security #activedirectory #powershell #bloodhound #architect #скрипты #musthave

Windows: `Perfmon` — это не 'топ'. `ETW` — вот настоящий 'eBPF'

Боль: `Perfmon` (Системный монитор) показывает 100% I/O на диске, но не говорит, КАКОЙ процесс и КАКОЙ файл это вызвал. Вы "слепы".

Решение: ETW (Event Tracing for Windows) ETW — это "черный ящик" ядра Windows. Это самый низкоуровневый и производительный (почти 0% оверхеда) механизм трассировки всего: I/O, Registry, Network, CPU...

PerfView — это бесплатный инструмент от Microsoft для "чтения" ETW.

Как найти "пожирателя" I/O (на пальцах):

1. Скачайте PerfView.exe (один файл, не требует установки).

2. Запустите сбор:
* PerfView.exe collect
* Оставьте на 30-60 секунд, пока идет "торможение".
* Нажмите "Stop Collection".

3.Анализируйте *.etl.zip файл:
* Откройте файл.
* Найдите "File I/O".
* БИНГО: Вы видите таблицу, где Process Name (sqlservr.exe), File Name (C:\DB\data.mdf) и IO_Time (ms) (90% всего времени).

Взгляд архитектора: Sysmon — это "что случилось". Perfmon — это "как сильно". ETW / PerfView — это "ПОЧЕМУ". Это ваш "микроскоп" для SRE-диагностики, который дает неопровержимые данные о том, какая функция в каком процессе "убивает" вашу систему.

#windows #sre #performance #diagnostics #etw #perfview #architect #гайд

Windows: FSRM — "SWAT-команда" для вашего файлового сервера

Боль: Ваш файловый сервер превратился в свалку. Пользователи хранят там .iso и .mp3 , а в один "прекрасный" день 10 000 файлов внезапно получают расширение .crypted .

Реакция админа: Писать скрипты для поиска .mp3 и восстанавливать бэкапы после атаки.
Реакция архитектора: Предотвратить это на уровне файловой системы.

В Windows Server есть "спящий гигант" — FSRM (File Server Resource Manager). Это не просто "квоты", это активная защита.

2 киллер-фичи, которые нужно включить:

1. File Screening (Блокировка по типу): Это ваш главный щит от шифровальщиков.
* Как: Вы создаете "экран", который запрещает запись файлов по маске (например, *.crypt, *.locked, *.wncry).
* Результат: Процесс шифровальщика просто не сможет создать/переименовать файл. Атака "захлебнется" на первом же файле.
* Бонус: Сюда же добавляем *.exe, *.bat, *.ps1 (запретить запуск) и *.mp3, *.avi (сэкономить место).

2. Quotas (Умные квоты): Не просто "100 ГБ на папку", а автоматическое применение квоты (2 ГБ) для каждой новой папки пользователя, созданной в \\Shares\Users\.

Взгляд архитектора: FSRM — это не "управление диском". Это критический слой безопасности (Defense in Depth). Вы не "надеетесь" на EDR, вы блокируете сам вектор атаки на уровне файловой системы.

#windows #security #fsrm #ransomware #sysadmin #гайд #musthave

Linux: htop — это прошлое. Встречаем btop++ — ваш SRE-дашборд

Боль: `htop` — это легенда, но он показывает только CPU и RAM . Чтобы увидеть диски, нужен iotop . Чтобы увидеть сеть — nethogs . Чтобы увидеть сенсоры — sensors .

Решение: btop++ . Это современный, написанный на C++ "комбайн", который показывает ВСЁ в одном, красивом, интерактивном окне.

Почему это "убийца" htop :
* Всё-в-одном: CPU, Память, Диски (I/O, iowait!), Сеть и Процессы — на одном экране.
* Интерактивность: Полная поддержка мыши, удобная фильтрация (F), дерево процессов.
* Визуализация: Встроенные ASCII-графики загрузки в реальном времени.

Установка (проще простого):
Bash

# Ubuntu/Debian
sudo apt install btop

# RHEL/CentOS (EPEL)
sudo yum install btop

# macOS
brew install btop

Взгляд архитектора: Это High-Resolution Observability (наблюдаемость высокого разрешения). Вы переходите от гадания "что тормозит?" к корреляции. Вы мгновенно видите: "Ага, CPU в норме, но Disk I/O уперся в 100%, и это процесс java (PID 1234)". Это сокращает MTTR (Mean Time to Resolution) с часов до секунд.

#linux #monitoring #sre #btop #sysadmin #tools #гайд

AD Security: Kerberoasting — это "вход". Pass-the-Ticket — это "движение"

Боль: Мы уже говорили, как хакеры "вытаскивают" хэши сервисных учеток (Kerberoasting). Но что они делают дальше?

Реакция админа: "Я просто сменю пароль уязвимой учетке SQL-Service". Реакция архитектора: "Я пойму, куда он мог с ней пойти, и закрою этот путь".

Pass-the-Ticket (PtT) — это техника Lateral Movement (бокового смещения).

Как это работает:
1. Атакующий (через Kerberoasting) получил Kerberos-билет (TGS) для службы SQL-Service. Пароль ему не нужен.
2. Он "инжектит" этот билет в свою сессию (mimikatz, Rubeus).
3. Теперь он — SQL-Service.
4. Он смотрит, куда SQL-Service имеет права (например, SQL-Service — локальный админ на FILE-SRV-01).
5. Он "прыгает" на FILE-SRV-01 (через PsExec или WMI) с правами SQL-Service и повторяет цикл.

Взгляд архитектора: Это доказывает, почему Admin Tier Model и Принцип Наименьших Привилегий (PoLP) — это не "бюрократия", а фундамент защиты.
* Ваша SQL-Service (Tier 1) не должна быть админом на FILE-SRV-01 (Tier 1).
* Ваша HelpDesk (Tier 2) не должна иметь прав на серверах (Tier 1).

Компрометация одной учетки не должна приводить к компрометации всего домена.

#security #windows #activedirectory #kerberos #cybersecurity #architect #гайд

Windows (Security): Охота на C2-трафик. Скрипт-аудит эфемерных портов

Боль: Ваш EDR молчит. netstat показывает кучу соединений от svchost.exe или powershell.exe с "высоких" портов (49152+). Вы не знаете, "легитимный" это трафик или нет.

Реакция админа: "Наверное, это Windows...".
Реакция архитектора: "Вредоносы (C2, маяки) обожают прятаться в эфемерных (динамических) портах, чтобы слиться с "шумом". Я должен проверить, кто их использует".

Этот PowerShell-скрипт — ваш сканер. Он показывает только активные соединения в динамическом диапазоне портов и привязывает их к процессу и его пути.

Код скрипта:
PowerShell

Write-Host "--- Начинаю аудит процессов, использующих эфемерные порты ---" -ForegroundColor Cyan

# 1. Получаем динамический диапазон TCP-портов
$DynamicRange = netsh int ipv4 show dynamicport tcp
$StartPort = ($DynamicRange | Select-String "Start Port") -replace "\D", ""
$NumPorts = ($DynamicRange | Select-String "Number of Ports") -replace "\D", ""
$EndPort = [int]$StartPort + [int]$NumPorts
Write-Host "Динамический диапазон: $StartPort - $EndPort" -ForegroundColor Gray

# 2. Получаем все TCP-соединения
$Connections = Get-NetTCPConnection -State Established

# 3. Фильтруем
$Suspicious = $Connections | Where-Object {
    $_.RemotePort -ge $StartPort -and $_.RemotePort -le $EndPort
} | Select-Object -Property LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess, State

if ($Suspicious.Count -eq 0) {
    Write-Host "[OK] Подозрительных соединений в эфемерном диапазоне не найдено." -ForegroundColor Green
    exit
}

Write-Host "[!!!] ОБНАРУЖЕНЫ ПРОЦЕССЫ С СОЕДИНЕНИЯМИ В ЭФЕМЕРНОМ ДИАПАЗОНЕ:" -ForegroundColor Yellow

# Обогащаем данные путем к процессу
$Report = $Suspicious | ForEach-Object {
    $Process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        PID = $_.OwningProcess
        ProcessName = $Process.ProcessName
        Path = $Process.Path
        RemoteAddress = $_.RemoteAddress
        RemotePort = $_.RemotePort
    }
}

$Report | Format-Table -AutoSize

Взгляд архитектора: Вы не "гадаете". Вы валидируете. Если powershell.exe из C:\Users\Vasya\AppData держит соединение на порт 51234 с неизвестным IP — вы, вероятно, только что поймали C2-маяк (beacon).

#windows #powershell #security #threat_hunting #networking #скрипты #cybersecurity

Linux (Audit): Скрипт-аудит "мертвых душ". Ищем "бесхозные" файлы

Боль: Вы удалили пользователя vasya (userdel vasya). Но вы не удалили его файлы (userdel -r). Теперь в системе лежат гигабайты данных (в /home/vasya или /tmp), у которых нет владельца.

Чем опасно:
1. Безопасность: Если система переиспользует UID (ID пользователя) vasya для нового пользователя petya, petya автоматически станет владельцем всех старых файлов vasya.
2. Гигиена: Это "цифровой мусор", который забивает диск.

Реакция админа: "Они не мешают".
Реакция архитектора: "Ни один файл не должен быть бесхозным".

Этот Bash-скрипт использует find для поиска всех файлов, у которых UID (владелец) или GID (группа) не существуют в /etc/passwd или /etc/group.

Код скрипта:
Bash

#!/bin/bash
# --- Поиск "бесхозных" (orphaned) файлов ---

echo "--- Начинаю поиск файлов без владельца (nouser) или группы (nogroup) ---"
echo "Проверка может занять длительное время..."

# -xdev: Искать только в этой файловой системе (не заходить в /mnt, /proc)
# -nouser: Владелец (UID) не найден в /etc/passwd
# -nogroup: Группа (GID) не найдена в /etc/group
# -print: Печатать результат

# Запускать от root
find / -xdev \( -nouser -o -nogroup \) -print 2>/dev/null

echo "--- Поиск завершен ---"
echo "Рекомендация: Проверьте список и либо удалите файлы, либо смените владельца (chown root:root ...)"

Взгляд архитектора: Это — непрерывный аудит. Этот скрипт должен запускаться по cron раз в месяц, а отчет — ложиться вам на почту. Это гарантирует, что ваша система чиста и предсказуема.

#linux #bash #security #audit #sysadmin #скрипты #гайд

Full-Stack (DevOps): "Нет!" паролям в Git. Скрипт `pre-commit` hook

Боль: Ваш инженер случайно коммитит config.prod.yml с открытым паролем от базы данных. Через 30 секунд Gitleaks-боты на GitHub находят его, и ваша БД взломана.

Реакция админа: "Я поменяю пароль и буду ругать инженера".
Реакция архитектора: Предотвратить сам факт коммита.

Git Hooks — это скрипты, которые Git запускает автоматически при определенных действиях (например, pre-commit — перед тем, как коммит будет создан).

Код скрипта (Bash, положить в .git/hooks/pre-commit):
Bash

#!/bin/bash
# --- Простой Pre-Commit Hook для блокировки секретов ---

echo "--- Запускаю проверку на секреты... ---"

# 1. Запрещенные слова. Добавьте свои (api_key, password, etc.)
FORBIDDEN_PATTERNS=(
    "password:"
    "password ="
    "api_key:"
    "api_key ="
    "SECRET_KEY"
    "BEGIN RSA PRIVATE KEY"
)

# 2. git diff --cached: Показывает ТОЛЬКО те изменения, которые вы собираетесь коммитить
FILES_TO_CHECK=$(git diff --cached --name-only --diff-filter=ACM)

if [ -z "$FILES_TO_CHECK" ]; then
    echo "Нет файлов для проверки. Пропускаю."
    exit 0
fi

# 3. Проверяем каждый файл
for FILE in $FILES_TO_CHECK; do
    for PATTERN in "${FORBIDDEN_PATTERNS[@]}"; do
        if grep -q -i "$PATTERN" "$FILE"; then
            echo "=============================================="
            echo "[!!!] ОШИБКА: ОБНАРУЖЕН СЕКРЕТ В ФАЙЛЕ!"
            echo "Файл:   $FILE"
            echo "Паттерн: '$PATTERN'"
            echo "=============================================="
            echo "Коммит ОТКЛОНЕН. Удалите секрет перед коммитом (используйте Vault или .env)"
            exit 1 # <--- Главная магия. Ненулевой exit code БЛОКИРУЕТ коммит.
        fi
    done
done

echo "[OK] Секреты не найдены. Коммит разрешен."
exit 0

(Не забудьте сделать его исполняемым: chmod +x .git/hooks/pre-commit )

Взгляд архитектора: Это "Shift-Left Security" (Сдвиг безопасности влево). Вы не реагируете на утечку, вы встраиваете безопасность в процесс разработки.

#security #devops #git #automation #bash #скрипты #гайд

Kubernetes (Security): Аудит «привилегированных» Pod’ов и опасных контекстов

Боль: Кластер «зелёный», но в проде внезапно есть Pod’ы с privileged, hostNetwork и контейнеры, которые по факту бегут от root.
Реакция админа: «Они же работают».
Реакция архитектора: «Любая эскалация — это вопрос времени. Я хочу сигнал в моменте.»

Скрипт (Bash + kubectl + jq), выводит только рискованные контейнеры:

#!/usr/bin/env bash
# --- Kubernetes Risky Pods Audit ---
set -euo pipefail

command -v kubectl >/dev/null || { echo "[!!!] Требуется kubectl"; exit 2; }
command -v jq >/dev/null || { echo "[!!!] Требуется jq"; exit 2; }

echo "--- Начинаю аудит Pod'ов с опасными настройками ---"

data=$(kubectl get pods -A -o json)
echo "$data" | jq -r '
  [.items[] as $p
   | ($p.spec.containers + ($p.spec.initContainers // []))[]? as $c
   | {
       ns: $p.metadata.namespace,
       pod: $p.metadata.name,
       cont: $c.name,
       img: $c.image,
       privileged: ($c.securityContext.privileged // false),
       hostNetwork: ($p.spec.hostNetwork // false),
       hostPID: ($p.spec.hostPID // false),
       runAsRoot:
         ((( $c.securityContext.runAsUser
           // $p.spec.securityContext.runAsUser // null) == 0)
          or ( ($c.securityContext.runAsNonRoot
                // $p.spec.securityContext.runAsNonRoot // false) == false)),
       capAdd: ($c.securityContext.capabilities.add // [])
     }
  ]
  | map(select(.privileged or .hostNetwork or .hostPID or .runAsRoot
               or (.capAdd | index("SYS_ADMIN") or index("NET_ADMIN"))))
  | if length==0
      then "OK\tБезопасные настройки: нарушений не найдено"
    else
      (["NAMESPACE","POD","CONT","REASON","IMAGE"],
       (.[] | [
         .ns, .pod, .cont,
         ([
            (if .privileged then "privileged" else empty end),
            (if .hostNetwork then "hostNetwork" else empty end),
            (if .hostPID then "hostPID" else empty end),
            (if .runAsRoot then "runAsRoot" else empty end),
            (if (.capAdd|index("SYS_ADMIN")) then "SYS_ADMIN" else empty end),
            (if (.capAdd|index("NET_ADMIN")) then "NET_ADMIN" else empty end)
          ] | join(",")),
         .img
       ]))
      | @tsv
    end
' | column -t

echo "--- Аудит завершен ---"
echo "Рекомендация: навесьте PSP/PSa, OPA/Gatekeeper/Kyverno и зафиксируйте политику по умолчанию (runAsNonRoot=true, drop ALL)."

Взгляд архитектора: Вы не охотитесь на последствия, вы контролируете «плоскость допуска» (admission). Скрипт — датчик, политика — предохранитель.

#kubernetes #security #sre #devops #bash #jq #скрипты

AWS (IAM Audit): Пользователи без MFA и «древние» access-keys

Боль: В компании сотни IAM-юзеров. Кто-то без MFA, у кого-то ключи живут годами.
Реакция админа: «Сделаем раз в квартал ручную проверку».
Реакция архитектора: «Автоматизировать и зафиксировать SLO по возрасту ключей.»

Скрипт (Bash + awscli + jq). Показывает: пользователей без MFA; access-keys старше N дней; прямой AdministratorAccess.

#!/usr/bin/env bash
# --- AWS IAM Hygiene Audit ---
set -euo pipefail

DAYS=${1:-90}
command -v aws >/dev/null || { echo "[!!!] Требуется AWS CLI"; exit 2; }
command -v jq  >/dev/null || { echo "[!!!] Требуется jq"; exit 2; }

echo "--- Начинаю аудит IAM ---"

users=$(aws iam list-users --output json | jq -r '.Users[].UserName')

echo "[1/3] Пользователи без MFA:"
any_mfa_issues=0
while read -r u; do
  [ -z "$u" ] && continue
  mfa_count=$(aws iam list-mfa-devices --user-name "$u" --output json | jq '.MFADevices | length')
  if [ "$mfa_count" -eq 0 ]; then
    echo " - $u"
    any_mfa_issues=1
  fi
done <<< "$users"
[ $any_mfa_issues -eq 0 ] && echo " [OK] Все пользователи с MFA."

echo "[2/3] Access-keys старше $DAYS дн.:"
now_epoch=$(date -u +%s)
any_old_keys=0
while read -r u; do
  [ -z "$u" ] && continue
  aws iam list-access-keys --user-name "$u" --output json \
  | jq -r '.AccessKeyMetadata[] | "\(.AccessKeyId) \(.CreateDate)"' \
  | while read -r key created; do
      [ -z "$key" ] && continue
      created_epoch=$(date -d "$created" +%s)
      age=$(( (now_epoch - created_epoch) / 86400 ))
      if [ "$age" -gt "$DAYS" ]; then
        echo " - $u  $key  ${age}d"
        any_old_keys=1
      fi
    done
done <<< "$users"
[ $any_old_keys -eq 0 ] && echo " [OK] Старых ключей нет."

echo "[3/3] Прямой AdministratorAccess на юзере:"
any_admin=0
while read -r u; do
  [ -z "$u" ] && continue
  pol=$(aws iam list-attached-user-policies --user-name "$u" --output json \
        | jq -r '.AttachedPolicies[].PolicyName')
  if echo "$pol" | grep -q "^AdministratorAccess$"; then
    echo " - $u"
    any_admin=1
  fi
done <<< "$users"
[ $any_admin -eq 0 ] && echo " [OK] Прямого админа нет (проверьте группы!)"

echo "--- Аудит завершен ---"
echo "Рекомендация: enforce MFA, ротация ключей <= ${DAYS} дн., доступ через роли вместо пользователей."

Взгляд архитектора: Без MFA и с «вечными» ключами у вас фактически перманентная сессия на проде. Считайте это инцидентом, который просто ещё не случился.

#aws #iam #security #audit #bash #cli #скрипты

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 #скрипты

Windows (Security): JEA — "PowerShell-тюрьма" для админов

Боль: Вам нужно дать HelpDesk-у право только перезапускать службу MyWebApp на 10 серверах.
Реакция админа: Дать ему RDP и права локального админа. (Итог: он "случайно" перезагружает весь сервер).
Реакция архитектора: Внедрить JEA (Just Enough Administration).

JEA — это не "права". Это "PowerShell-бункер".
Вы создаете специальный, изолированный PowerShell-endpoint (конечную точку), к которому подключается админ.

Как это работает:

1. Вы декларативно описываете "роль" в файле .psrc (Role Capability).
2. В этом файле вы разрешаете ТОЛЬКО одну команду: Restart-Service -Name "MyWebApp".
3. Админ подключается: Enter-PSSession -ComputerName SRV-01 -ConfigurationName JEA_Endpoint
4. Результат: Он может выполнить Restart-Service, но если он наберет Get-Process или reboot — он получит "команда не найдена".

Взгляд архитектора: Это абсолютный Zero Trust. Вы не "даете права" на сервер. Вы предоставляете безопасное API к нему. Это "золотой стандарт" для делегирования полномочий, который делает атаки Lateral Movement практически невозможными.

#windows #security #powershell #jea #zerotrust #architect #гайд #musthave

Windows: "Автозагрузка", которую вы не видите. Скрипт-аудит Scheduled Tasks

Боль: Ваш EDR/антивирус "молчит", но с сервера идет странный трафик. Вы проверили Run, Startup, Services — всё чисто. Где "сидит" вредонос?

Ответ: В Планировщике Задач (Scheduled Tasks). Это любимый метод персистентности (Persistence) для 90% современных атак (Fileless, C2-маяки).

Реакция админа: "Открыть GUI и пролистать 200 задач".
Реакция архитектора: "Запустить PowerShell-аудит, который найдет паттерны атаки".

Этот PowerShell-скрипт — ваш "охотник". Он ищет "красные флаги" в задачах.

Код скрипта:
PowerShell

Write-Host "--- Начинаю аудит Scheduled Tasks на 'красные флаги' ---" -ForegroundColor Cyan

# Получаем ВСЕ задачи
$Tasks = Get-ScheduledTask

$Report = foreach ($Task in $Tasks) {
    $TaskInfo = Get-ScheduledTaskInfo $Task
    $TaskAction = $Task.Actions.Execute

    # --- КРАСНЫЕ ФЛАГИ (добавьте свои) ---
    $Suspicious = $false
    
    # 1. Запуск от SYSTEM с высоким приоритетом
    if ($TaskInfo.Principal -match "SYSTEM" -and $TaskInfo.Priority -lt 5) { $Suspicious = $true }
    
    # 2. Запуск PowerShell с закодированной командой
    if ($TaskAction -match "powershell.*-enc") { $Suspicious = $true }
    
    # 3. Запуск из "странных" папок (Temp, AppData)
    if ($TaskAction -match "AppData" -or $TaskAction -match "Temp") { $Suspicious = $true }

    if ($Suspicious) {
        [PSCustomObject]@{
            Path = $Task.TaskPath
            Name = $Task.TaskName
            State = $TaskInfo.State
            User = $TaskInfo.Principal
            Action = $TaskAction
        }
    }
}

if ($Report) {
    Write-Host "`n[!!!] ОБНАРУЖЕНЫ ПОДОЗРИТЕЛЬНЫЕ ЗАДАЧИ:" -ForegroundColor Red
    $Report | Format-Table -Wrap -AutoSize
} else {
    Write-Host "`n[OK] Подозрительных задач не найдено." -ForegroundColor Green
}

Взгляд архитектора: Это проактивный Threat Hunting. Вы не ждете срабатывания EDR. Вы сами ищете TTPs (тактики, техники, процедуры) атакующих, зная, как они работают.

#windows #powershell #security #threat_hunting #cybersecurity #скрипты #гайд

Linux: htop врёт. Куда на самом деле уходит память? Вскрываем pmap

Боль: Вы запускаете htop. Он показывает: VIRT: 25.0G, RES: 500M. Вопрос: Куда "делись" 24.5 ГБ? Почему VIRT (виртуальная) такой огромный, а RES (физическая) — маленький?

Реакция админа: "Наверное, это кэш. Перезагружу".
Реакция SRE: "Я посмотрю карту памяти процесса".

pmap (Process Memory Map) — это "рентген" для процесса. Он показывает каждый регион памяти, который процесс "попросил" у ядра.

Как это читать:
1. Найдите PID (например, pidof java -> 1234).
2. Запустите pmap с флагом -x (расширенный):
Bash

pmap -x 1234

Что вы увидите:
*Сотни строк с .so файлами (это shared libraries — общие библиотеки).
* [ anon ]: Это "анонимная" память — то, что malloc() выделил в "куче" (heap). Если эта цифра растет — у вас 100% утечка памяти (memory leak).
* [ stack ]: Стек процесса.

"Убийца"-команда (показать итог):
Bash

# Показать только ИТОГО (Total)
pmap -x 1234 | tail -n 1
# Вывод: total ---- 25165824K

Бинго! Вот ваши 25 ГБ. Это не "утечка", а 1000+ .so-библиотек, которые "раздули" виртуальное адресное пространство.

Взгляд архитектора: Вы перестаете "гадать" по htop. Вы видите корень проблемы. pmap — это ваш микроскоп для диагностики утечек памяти и "раздутых" приложений.

#linux #sre #performance #diagnostics #pmap #команды #гайд #architect

Windows (Security): "Крепость" внутри AD. Внедряем Authentication Silos

Боль: Ваш Domain Admin залогинился на ноутбук HelpDesk ( Tier 2 ), чтобы "быстро что-то поправить".
Хакер, сидящий на этом ноутбуке, ворует его Kerberos-билет и через 5 минут захватывает Контроллер Домена (атака Pass-the-Ticket ).

Реакция админа: "Я больше так не буду".
Реакция архитектора: "Я сделаю так, чтобы этот билет был бесполезен".

Authentication Silos (Хранилища Аутентификации) — это ваш "ядерный бункер" внутри AD.
Это контейнер, который привязывает высокопривилегированные учетки (как Domain Admins ) только к высокопривилегированным хостам (как Domain Controllers ).

Как это работает:
1. Вы создаете "Silo" (Хранилище) и "Policy" (Политику).
2. Вы помещаете в "Silo" своих Domain Admins и свои Domain Controllers.
3. Kerberos (KDC) теперь выдает непередаваемые (non-forwardable) билеты. TGT (билет), выданный для Domain Admin'а, не может быть использован для доступа ни к чему, кроме хостов из этого же "Silo" (то есть, к другим DC).

Взгляд архитектора: Это реальное, техническое принуждение для вашей Admin Tier Model. Вы не "надеетесь", что админ не залогинится на ПК. Вы гарантируете, что если он это сделает, его украденный билет будет просто бесполезным мусором для хакера.

#windows #security #activedirectory #kerberos #zerotrust #architect #гайд #musthave

🛡️ Windows (Архитектура): "NTFS-права" мертвы. Будущее — это Dynamic Access Control (DAC)

Боль: У вас 50 файловых шар. Вам приходит задача: "Дать доступ к папке Finance_Reports только менеджерам из отдела Sales , которые находятся в Казахстане".

Реакция админа: Создать еще одну AD-группу KZ_Sales_Managers_Finance_Access и вручную добавить в нее 10 человек. (Через год в AD будет 5000 групп).

Реакция архитектора: Использовать Dynamic Access Control (DAC).

DAC (динамический контроль доступа) — это "умные" NTFS-права. Вы даете доступ не "пользователю", а "по правилу".

Как это работает:
1. Классификация: Вы "маркируете" файлы (через FSRM): file.Confidentiality = High.
2.Атрибуты: Вы используете существующие атрибуты AD: user.Department = "Sales", user.Country = "KZ".
3. Политика (в GPO): Вы пишете одно правило для папки:
* Allow: Read
* IF: (user.Department == "Sales")
* AND: (user.Country == "KZ")
* AND: (file.Confidentiality == "High")

Взгляд архитектора: Вы переходите от "управления 1000 групп" к "управлению 10 политиками". Это Policy as Code для данных.

#windows #security #activedirectory #dac #zerotrust #architect #гайд