AD: Ваш Domain Admin бесполезен, если он залогинен на ПК. Разбираем "Admin Tier Model"

Хакер взломал ПК вашего HelpDesk-администратора, который также является Domain Admin. Через 10 минут хакер получил ключи от всего домена.

Почему: Вы нарушили главный принцип безопасности AD.

Admin Tier Model (Модель Уровней Администрирования) — это не "фича", это архитектурная концепция от Microsoft, которая изолирует ваши "ключи от королевства".

Суть (простыми словами): Ваша инфраструктура делится на 3 "непересекающихся" уровня:

Tier 0 (Ядро / Ключи):

Что это: Контроллеры Домена (DC), PKI (Центры Сертификации), ADFS.

Кто: Только Domain Admins. Запрещено логиниться этими учетками куда-либо, кроме Tier 0.

Tier 1 (Серверы / Приложения):

Что это: Серверы приложений, SQL, WSUS, Файловые серверы.

Кто: Server Admins. Им запрещено логиниться на Tier 0.

Tier 2 (Рабочие станции / Пользователи):

Что это: Ноутбуки, ПК пользователей, принтеры.

Кто: HelpDesk / Workstation Admins. Им запрещено логиниться на Tier 1 и Tier 0.

"Золотое правило" (Закон Гравитации): Tier 0 (DA) НИКОГДА не должен "спускаться" и логиниться на Tier 1 или Tier 2.

Почему? Как только ваш Domain Admin (Tier 0) логинится на ПК (Tier 2), его хэш пароля остается в памяти (LSASS). Хакер, взломав этот ПК, забирает хэш (Pass-the-Hash) и мгновенно становится Domain Admin.

Взгляд архитектора: Вы не просто "создаете группы". Вы проектируете барьеры. Компрометация Tier 2 (самого уязвимого) не должна приводить к компрометации Tier 1 и, тем более, Tier 0. Это основа Zero Trust и единственный способ защитить AD от атак Lateral Movement.

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

Linux: "Почему мой Docker-контейнер тормозит?" Вскрываем `cgroups`

Вы выделили Docker-контейнеру 2 CPU, а он "задыхается". Вы запускаете htop на хосте — а там 20% простоя. Что происходит?

Происходит CPU Throttling (троттлинг). Ваш контейнер хочет больше CPU, но cgroups (Control Groups) его "душат".

cgroups — это технология ядра, которая изолирует и ограничивает ресурсы (CPU, RAM, I/O) для групп процессов. Это фундамент, на котором стоят systemd, Docker и Kubernetes.

Как увидеть "троттлинг" своими глазами:

Найдите "слайс" вашего контейнера:

Bash

# Найти "слайс" Docker
systemd-cgls | grep 'docker-'
# /docker-a1b2c3d4e5f6.scope
Прочитайте статистику CPU (самое важное):

Bash

# Идем в "папку" cgroup этого контейнера
cd /sys/fs/cgroup/cpu/docker/a1b2c3d4e5f6...

# Читаем файл статистики
cat cpu.stat

* nr_periods: Сколько раз процесс "приходил" за CPU.

* nr_throttled: Сколько раз ему было отказано (он был "задушен").

* throttled_time: Суммарное время, которое процесс провел в "задушенном" состоянии (в наносекундах).

Взгляд архитектора: Если nr_throttled (количество удушений) постоянно растет — вы нашли корень зла. Вы доказали, что проблема не в "тормозах", а в нехватке выделенных ресурсов. top вам этого никогда не покажет. Архитектор валидирует лимиты, а не гадает.

#linux #sre #docker #cgroups #performance #diagnostics #гайд #architect

Windows: "Get-WmiObject — мертв". Переходим на CIM

Если вы в 2025 году все еще пишете Get-WmiObject в своих PowerShell-скриптах, у нас плохие новости. Эта команда мертва (deprecated).

Почему она мертва? Она использует "старый" протокол DCOM, который:

* Медленный.

* Блокируется файрволами (требует 100500 открытых портов).

* Неэффективный.

Новый стандарт: Get-CimInstance (CIM) CIM (Common Information Model) — это современная замена WMI.

Почему CIM — это круто:

Работает по WinRM: (Как и PowerShell Remoting). Ему нужен один порт (5985 http или 5986 https). Он "пробивает" файрволы.

Быстрый: Использует WS-Man, который намного легче, чем DCOM.

Умный: Get-CimInstance возвращает "чистые" объекты, а не системный мусор.

Сравнение "до" и "после":

МЕРТВО (не делайте так):

PowerShell

# Медленно, через DCOM
Get-WmiObject -Class Win32_OperatingSystem -ComputerName SERVER01

ЖИВО (делайте так):

PowerShell

# Быстро, через WinRM
Get-CimInstance -ClassName Win32_OperatingSystem -ComputerName SERVER01

(...или New-CimSession для создания постоянного подключения).

Взгляд архитектора: Выбирать правильный инструмент — это и есть архитектура. Get-WmiObject — это "костыль" из эры Server 2003. Get-CimInstance — это стандарт для современной, автоматизированной Windows-инфраструктуры.

#windows #powershell #automation #wmi #cim #sysadmin #гайд #musthave

Защита от "самого себя": Как обезопасить критичные конфиги в Linux

Проблема: Один rm -rf по ошибке. Одна неудачная правка nginx.conf в 3 часа ночи. И prod лежит. "Админ" надеется на бэкапы (восстановление). "Архитектор" предотвращает саму возможность ошибки.

Вот 3 уровня эшелонированной обороны для ваших самых важных файлов (конфигов, скриптов, сертификатов).

Уровень 1: "Бетонный бункер" (chattr)
Это — ваш immutable (неизменяемый) флаг. Самая сильная защита, даже от root.

⏺ Как включить: sudo chattr +i /etc/nginx/nginx.conf

Теперь этот файл нельзя удалить, изменить, переименовать или даже создать на него ссылку. Совсем.

⏺ Как выключить (для плановых правок): sudo chattr -i /etc/nginx/nginx.conf

#АрхитекторскийЛайфхак: Сделали правки -> немедленно включили защиту обратно! Это лучшая защита от случайного rm или sed -i.

Уровень 2: "Гибкий контроль" (ACL)
Стандартных rwx (владелец/группа/остальные) часто не хватает. ACL (Access Control Lists) дают гранулярный доступ.

Задача: Дать юзеру deploy право только читать конфиг, но не менять.

⏺ Назначаем права: sudo setfacl -m u:deploy:r /etc/nginx/nginx.conf

⏺ Проверяем права: getfacl /etc/nginx/nginx.conf

Это намного чище, чем добавлять deploy в группу root (чего делать нельзя никогда).

Уровень 3: "Умный Sudo" (sudoers)
Никогда не давайте сервисным юзерам и коллегам ALL=(ALL) ALL. Это "ключи от королевства". Давайте только то, что нужно.

Задача: Дать deploy право только перезапускать Nginx, но не редактировать или удалять его файлы.

⏺ Редактируем visudo: deploy ALL=(root) NOPASSWD: /bin/systemctl restart nginx

Теперь deploy может выполнить sudo systemctl restart nginx, но sudo rm /etc/nginx/nginx.conf ему "откажет в доступе".

Итог: sudoers защищает от эскалации привилегий. ACL защищает от случайных правок другими пользователями. chattr защищает от root-ошибок (включая вас самих в 3 часа ночи).

#linux #security #sysadmin #chattr #acl #sudo #bestpractice

— DeepSeek слишком любит сникерсы.

SUDO. ДЛЯ. WINDOWS. Официально.

Microsoft анонсировала sudo для Windows Server 2025 (и уже в Insider-сборках Windows 11).

Это фундаментальное изменение в философии администрирования Windows, которого мы ждали 20 лет.

Как это работает (по данным Microsoft): Это не runas. Это sudo.
PowerShell

# Пример: Запускаем команду в том же окне, но с правами Admin
sudo Remove-Item C:\Windows\System32\Drivers\etc\hosts

Ключевые фичи:
Три режима:
1. inline (по умолчанию): Команда запускается в текущем окне (как в Linux).
2. in a new window: Открывает новое UAC-окно.
3. disabled: Отключено.

Конфигурация: Настраивается через sudo config.

Безопасность: Запрашивает UAC-подтверждение (пока), но это уже шаг к гранулярному повышению привилегий.

Взгляд архитектора: Это не просто "копия" Linux. Это признание Microsoft, что временное, гранулярное повышение привилегий (Principle of Least Privilege) — это единственный путь к безопасности. Мы уходим от эры, где админ сидит 8 часов в сессии с правами Domain Admin. Это меняет всё в скриптах автоматизации и в подходе к безопасности.

#windows #security #sudo #powershell #architect #musthave #hotnews

Архитектура: 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 #скрипты #гайд