Архитектура: DevOps "умер"? Встречаем Platform Engineering

Если вы освоили Ansible и Kubernetes, вы — DevOps. Но какой следующий шаг?

В англоязычном IT все говорят о Platform Engineering (Инженерия Платформ).

DevOps: Строит "двигатель" (CI/CD, Kubernetes, Terraform).

Platform Engineer: Строит "автомобиль" (всю платформу) и отдает разработчику только ключ зажигания и руль.

Суть: Platform Engineering создает Internal Developer Platform (IDP) — внутренний продукт (как "Heroku" или "Vercel" внутри вашей компании).

Разработчик не знает про kubectl apply, helm или Ansible. Он просто пишет в config.yml: app: my-app, replicas: 3, deploy: true -> нажимает git push -> и его приложение в "проде".

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

#architect #devops #sre #platformengineering #career #стратегия #гайд

Проект на выходные: Запускаем Windows VM... внутри Kubernetes. Знакомство с KubeVirt

Проблема: Ваша компания перешла на Kubernetes. 90% сервисов — контейнеры. Но у вас остался "старый, добрый" монолит на Windows Server (например, 1С или старый IIS-апп), который нельзя контейнеризировать.

Решение: Не держать "зоопарк" (Kubernetes + Proxmox/VMware). А запустить эту VM внутри Kubernetes.

KubeVirt — это проект CNCF, который позволяет управлять Виртуальными Машинами (VM) так же, как и контейнерами.

Как это работает: Вы пишете YAML-манифест так же, как для Deployment, но с типом VirtualMachineInstance.
YAML

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-windows-vm
spec:
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
        # ...и т.д.

Взгляд архитектора: Это "Единый Оркестратор". У вас ОДИН инструмент (kubectl) и ОДНА "панель управления" (Kubernetes) для всех ваших нагрузок — и современных (контейнеры), и "легаси" (VM). Это упрощает сеть, хранилище и мониторинг.

#linux #kubernetes #kubevirt #devops #virtualization #architect #гайд

RKN получает "root-доступ" к Рунету. Что это меняет для инженеров?

Новость, которая напрямую влияет на нашу работу. С 1 марта 2026 года Роскомнадзор получает беспрецедентные права на управление российским сегментом интернета.

Если коротко, РКН сможет:

Отдавать обязательные команды операторам связи.
Перенаправлять трафик через свои тех. средства (ТСPU).
Менять маршруты передачи данных.
В случае "угрозы" (критерии неясны) брать ручное управление всей сетью.

Формально это объясняется "устойчивостью и безопасностью". Фактически — это полная централизация управления сетью.

Взгляд архитектора: Что это значит для нас?

Это не политика. Это новые технические риски, которые мы обязаны учитывать при проектировании систем.

"Черный ящик" в маршрутизации: traceroute и mtr могут стать менее информативными. Мы получаем "черный ящик" (ТСPU) в середине маршрута, который может резать, фильтровать и замедлять трафик. Диагностика проблем с "тормозами" до AWS или Azure станет в разы сложнее.

Хрупкая избыточность: Ваша отказоустойчивая схема с двумя разными ISP (например, "Ростелеком" и "Билайн") теряет смысл, если РКН в "ручном режиме" направит трафик обоих провайдеров через один и тот же "бутылочное горлышко".

Риск изоляции: Доступ к критически важным внешним ресурсам (GitHub, Docker Hub, PyPI, apt-репозитории) может быть ограничен в любой момент по щелчку, если их сочтут "опасными".

Новый DR-план: В наших Disaster Recovery планах должен появиться новый сценарий: "Полная изоляция Рунета". Что будет делать ваш бизнес, если внешние API и SaaS-сервисы (включая ваш Cloud) просто исчезнут на N часов/дней?

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

#security #networking #architect #sre #devops #russia

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