Чеклист (Windows: 5 пунктов проверки админа)

1️⃣ Антивирус включён
2️⃣ Обновления стоят
3️⃣ Диск C: >20% свободного
4️⃣ Бэкапы протестированы
5️⃣ Логи ошибок проверены

🛠️ Дежурная проверка перед выходными.
#windows #чеклисты #audit

Команды (Linux: полезные команды)

uptime
w
whoami
crontab -l
ls -lah /var/log

👀 Показывают, сколько времени сервер работает, кто вошёл, права текущего пользователя, расписание задач, лог-файлы.
#linux #команды #monitoring

Чеклист (Windows: Hardening Checklist базовый)

1️⃣ Обновить Windows Server до последних патчей
2️⃣ Отключить гостевой аккаунт и переименовать локального администратора
3️⃣ Настроить политики паролей (длина ≥12, сложность)
4️⃣ Включить брандмауэр и закрыть ненужные порты
5️⃣ Отключить службы и роли, не используемые сервером

#windows #чеклисты #security

🎉 С праздником, товарищи программисты!

Сегодня — День программиста, профессиональный праздник, который отмечают в 256-й день года.

Почему именно 256?
ℹ️ Это 2⁸ — количество различных значений, которые можно выразить с помощью одного байта.
Это также максимальная целая степень числа 2, которая не превышает количество дней в году (365 или 366).

Пусть ваш код всегда компилится с первой попытки, баги сами закрываются, а кофе никогда не кончается ☕💻

#деньпрограммиста #it #системныеадмины #праздник

Чеклист: подготовка к уязвимостям (Zero-Day Ready)

Админ всегда должен быть готов к внезапным zero-day уязвимостям. Вот быстрый чеклист, который снижает риски:

1️⃣ Включён централизованный аудит логов (SIEM или хотя бы syslog/Event Viewer forwarding).
2️⃣ Резервные копии отделены от продакшн-сети.
3️⃣ Сервера обновляются пакетами безопасности в автоматическом режиме.
4️⃣ Локальные учётки → минимум, пароли уникальные.
5️⃣ Сервисы мониторинга → оповещают в реальном времени (почта/Telegram/Slack).
6️⃣ Уязвимые сервисы (RDP, SSH) закрыты на прямой интернет.
7️⃣ План отката и тест восстановления проверены на практике.

Zero-day не предупредит. Но подготовленный админ = спокойная ночь.

#security #чеклисты #zeroday #adminlife

PowerShell: мониторинг дисков + уведомление в Telegram

1. Создай бота

В Telegram напиши @BotFather → /newbot.

Сохрани TOKEN.

2. Узнай свой chat_id

Напиши что-то боту,

Перейди по ссылке в браузере:
https://api.telegram.org/bot<TOKEN>/getUpdates

Найди "chat":{"id":123456789} → это твой chat_id.

3. Скрипт PowerShell

$token = "<BOT_TOKEN>"         # токен бота
$chatId = "<CHAT_ID>"          # твой chat_id
$threshold = 15
$disks = Get-WmiObject Win32_LogicalDisk -Filter "DriveType=3"

foreach ($disk in $disks) {
    $free = [math]::Round(($disk.FreeSpace / $disk.Size) * 100, 2)
    if ($free -lt $threshold) {
        $msg = "⚠️ Внимание! Диск $($disk.DeviceID) заполнен, осталось только $free%."
        $url = "https://api.telegram.org/bot$token/sendMessage?chat_id=$chatId&text=$([uri]::EscapeDataString($msg))"
        Invoke-RestMethod -Uri $url -Method Get
    }
}

Теперь при нехватке места (<15%) скрипт будет слать сообщение в Telegram.
Добавь его в Task Scheduler → получишь автоматические уведомления.

#powershell #windows #скрипты #telegram #monitoring

Полезная находка

Хочу поделиться курсом [Профессия — Белый Хакер] на Stepik.
https://stepik.org/course/169003/
Курс бесплатный и подойдёт всем, кто интересуется информационной безопасностью и хочет системно изучить тему этичного хакинга.

Это не реклама, просто делюсь с теми, кому может быть интересно

Linux (bash): алерт по свободному месту + Telegram

Проверяет все смонтированные разделы, шлёт алерт если <15% свободно.#!/usr/bin/env bash
TOKEN="<BOT_TOKEN>"
CHAT_ID="<CHAT_ID>"
THRESHOLD=15

df -P -h | awk 'NR>1 {print $1,$5,$6}' | while read FS USE MNT; do
  PCT=${USE%\%}
  if [ "$PCT" -ge $((100-THRESHOLD)) ]; then
    MSG="⚠️ Диск почти заполнен: $FS на $MNT — занято $USE"
    curl -s "https://api.telegram.org/bot${TOKEN}/sendMessage" \
      -d chat_id="${CHAT_ID}" -d text="$(echo "$MSG")" >/dev/null
  fi
done
Поставь в cron раз в час.

#linux #bash #monitoring #telegram

Windows (PowerShell): контроль критичных сервисов + авто-рестарт + Telegram
Проверяет список сервисов; если «Stopped» — перезапускает и шлёт алерт.

$token   = "<BOT_TOKEN>"
$chatId  = "<CHAT_ID>"
$services = @("Spooler","LanmanServer","Dhcp","Dnscache")  # поменяй на свои

foreach ($s in $services) {
  $svc = Get-Service -Name $s -ErrorAction SilentlyContinue
  if ($null -ne $svc -and $svc.Status -ne 'Running') {
    try {
      Start-Service -Name $s -ErrorAction Stop
      $msg = "✅ Сервис $s был остановлен и перезапущен."
    } catch {
      $msg = "❌ Не удалось запустить сервис $s: $($_.Exception.Message)"
    }
    $url = "https://api.telegram.org/bot$token/sendMessage"
    Invoke-RestMethod -Uri $url -Method Post -Body @{chat_id=$chatId;text=$msg}
  }
}
Планировщик задач: каждые 10–15 минут.

#windows #powershell #services #telegram

Windows: поднятие WSUS с нуля + автоматическая чистка

Чтобы экономить интернет-канал и ускорять обновления, админы поднимают локальный сервер WSUS. Настроить его можно за вечер, если идти по шагам.

1️⃣ Установка роли

Через PowerShell:

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools

Мастер установки спросит:

Папку для хранения обновлений (лучше на отдельном диске).

Тип базы данных — встроенная WID (SQL не обязателен).

После установки запускаем мастер конфигурации.

2️⃣ Настройка сервера WSUS

▪️ Указываем апстрим-сервер (по умолчанию Microsoft Update).
▪️ Выбираем продукты: Windows 10/11, Windows Server 2019/2022.
▪️ Выбираем классификации:

Critical Updates

Security Updates

Definition Updates (для Defender).
▪️ Настраиваем синхронизацию (ручная или по расписанию).

3️⃣ Настройка клиентов через GPO

В домене открываем GPMC → создаём политику.
Путь:
Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update

Основные параметры:

Specify intranet Microsoft update service location → http://wsus-server:8530

Configure Automatic Updates → 4 (автоматическая загрузка и установка).

Automatic Maintenance Activation Boundary → время установки.

Применяем GPO к OU с нужными ПК.

4️⃣ Первичная проверка

На клиенте:

gpupdate /force
wuauclt /detectnow

Через 10–15 минут клиент должен появиться в консоли WSUS.

5️⃣ Автоматическая чистка WSUS

WSUS очень быстро разрастается, поэтому включаем регулярное обслуживание.

PowerShell-скрипт для чистки (сохраняем как wsus_cleanup.ps1):

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("localhost",$false)
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope `
    -Property @{
        DeclineSupersededUpdates = $true
        DeclineExpiredUpdates    = $true
        CleanupObsoleteUpdates   = $true
        CompressUpdates          = $true
        CleanupObsoleteComputers = $true
        CleanupUnneededContentFiles = $true
    }
$cleanupManager = $wsus.GetCleanupManager()
$cleanupManager.PerformCleanup($cleanupScope)
Write-Output "WSUS cleanup complete"

📌 Добавь этот скрипт в Task Scheduler (например, раз в неделю ночью).

6️⃣ Поддержка и обслуживание

Следим за размером базы и хранилища.

Проверяем отчёты о применении обновлений.

Раз в месяц вручную запускаем Server Cleanup Wizard для проверки.

📊 Теперь клиенты получают обновления локально:
— быстрее,
— без нагрузки на внешний канал,
— с автоматическим обслуживанием WSUS.

#windows #update #wsus #powershell #automation

WSUS vs SCCM (ConfigMgr): когда пора апгрейдиться?

WSUS — простой сервер обновлений. Он кэширует патчи и раздаёт их клиентам. Но у него есть предел возможностей. Когда инфраструктура растёт, часто переходят на SCCM (Microsoft Endpoint Configuration Manager).

🔹 Что умеет WSUS

✅ Кэшировать обновления Microsoft (Windows, Office, Defender).
✅ Работает на встроенной базе WID или SQL.
✅ Управление через GPO.
✅ Бесплатен (часть Windows Server).

❌ Ограничения:

Только продукты Microsoft.
Нет детальной отчётности (какие апдейты встали, а какие нет).
Нет управления сторонними софтом/драйверами.
Консоль тормозит на больших базах (1000+ клиентов).
Требует ручной чистки и обслуживания.

🔹 Что добавляет SCCM (ConfigMgr)

✅ Полное управление обновлениями Microsoft + стороннего софта (Adobe, Java, драйверы).
✅ Поддержка Windows, Linux, macOS.
✅ Развёртывание ПО и конфигураций (application deployment).
✅ Инвентаризация железа и софта.
✅ Расширенная отчётность (какой апдейт где применился).
✅ Гибкие коллекции устройств, таргетинг, правила автоустановки.
✅ Интеграция с Intune (гибрид MDM).

❌ Минусы:

Сложнее в развертывании.
Требует полноценного SQL Server.
Нужны лицензии (Software Assurance или отдельные CAL).

🔹 Когда WSUS уже «не тянет»

Клиентов >1000.
Нужно управлять обновлениями сторонних приложений.
Требуется инвентаризация ПО/железа.
Руководство требует детальной отчётности.
Инфраструктура гибридная (on-prem + облако).

📌 Вывод

Для малого бизнеса или филиала на 100–500 ПК → WSUS = нормальное решение.

Для средней и крупной инфраструктуры → SCCM даёт полный контроль, особенно если нужно управлять не только апдейтами, но и всем софтом.

⚡ Совет: если WSUS уже «трещит по швам», попробуй Windows Update for Business (политики обновлений через Intune) — это упрощённый вариант для гибридных сетей.

#windows #update #wsus #sccm #configmgr

Linux: systemd timers вместо cron

Cron — это классика, но у него есть минусы: он не знает о состоянии системы и «пропускает» задачи, если сервер был выключен. Systemd timers решают эти проблемы и дают больше гибкости.

1️⃣ Создаём unit для скрипта

/etc/systemd/system/backup.service

[Unit]
Description=Nightly backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

💡 Type=oneshot подходит для одноразовых задач (бэкап, очистка логов, sync).

2️⃣ Создаём таймер

/etc/systemd/system/backup.timer

[Unit]
Description=Run backup daily at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

🔹 OnCalendar — расписание (аналог cron).
🔹 Persistent=true — если сервер был выключен в 02:00, задача выполнится при следующем старте.
🔹 RandomizedDelaySec=300 — случайная задержка до 5 минут → полезно при десятках серверов (чтобы они не падали на диск одновременно).

3️⃣ Запуск и проверка

systemctl enable --now backup.timer
systemctl list-timers --all

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

4️⃣ Дополнительные сценарии

OnBootSec=10min — запуск через 10 минут после старта системы.
OnUnitInactiveSec=1h — повтор каждые 60 минут.
AccuracySec=1m — точность до минуты (экономит ресурсы при сотнях таймеров).

📌 Преимущества systemd timers

✅ Помнят пропущенные задачи (в отличие от cron).
✅ Интеграция с journald → логи доступны через journalctl -u backup.service.
✅ Гибкие триггеры (OnBootSec, OnActiveSec, OnUnitInactiveSec).
✅ Поддержка случайных задержек (RandomizedDelaySec) для распределения нагрузки.

⚡ Итого: timers = cron 2.0. Если ты уже используешь systemd, смысла держать cron мало.

#linux #systemd #automation #scheduling

Linux: Nginx как Reverse Proxy — швейцарский нож для админа

Просто хостить сайт на сервере — это прошлое. Современный подход — спрятать ваше приложение (Apache, Gunicorn, Node.js) за Nginx, который будет работать как обратный прокси. Это повышает безопасность, гибкость и производительность.

1️⃣ Зачем это нужно?

SSL/TLS Termination: Nginx берёт на себя всю работу с шифрованием, разгружая ваше приложение. Управлять сертификатами в одном месте — бесценно.
Load Balancing: Легко распределять трафик на несколько серверов-бэкендов.
Security: Прячет архитектуру вашего бэкенда. Можно настроить файрвол на Nginx и заблокировать вредоносный трафик до того, как он дойдёт до приложения.
Кэширование: Nginx может кэшировать статический контент (CSS, JS, картинки) и отдавать его мгновенно.

2️⃣ Установка и базовая настройка
Устанавливаем Nginx и удаляем дефолтный конфиг.

sudo apt update && sudo apt install nginx
sudo rm /etc/nginx/sites-enabled/default

3️⃣ Конфигурация Reverse Proxy
Создаём файл /etc/nginx/sites-available/myapp.conf. Предположим, ваше приложение работает на порту 8080.

Nginx

server {
    listen 80;
    server_name your_domain.com;

    # Перенаправляем весь трафик на бэкенд
    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # Передаём реальный IP клиента и другие заголовки
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

4️⃣ Включаем HTTPS (SSL Termination)
Добавим SSL с помощью Certbot (Let's Encrypt).

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d your_domain.com

Certbot автоматически изменит конфиг, добавив listen 443 ssl; и пути к сертификатам.

5️⃣ Активация и проверка

# Проверяем синтаксис конфига
sudo nginx -t

# Создаём символическую ссылку для активации
sudo ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/

# Перезапускаем Nginx
sudo systemctl restart nginx

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

#linux #nginx #proxy #security #network #архитектура

Чек-лист: Аудит логов Linux для поиска аномалий

Регулярный анализ логов — это как гигиена для сервера. Он помогает находить проблемы до того, как они станут критичными, и обнаруживать следы подозрительной активности. Сохраняйте этот базовый чек-лист для быстрой проверки.

Инструменты: journalctl, grep, awk, less.

▪️ 1. Проверка системных ошибок и сбоев
Ищем в journald записи с высоким приоритетом (ошибки, критические сбои).

Bash

journalctl -p 0..3 -n 50 --no-pager

-p 0..3 — фильтр по приоритетам от emerg до err.
-n 50 — показать последние 50 записей.
Что ищем: ошибки ядра (kernel panic), сбои сервисов, проблемы с дисками.

▪️ 2. Анализ попыток входа по SSH
Кто и откуда пытался подключиться к серверу?

Bash

# Все неудачные попытки входа
grep "Failed password" /var/log/auth.log | less

# IP-адреса, с которых было больше 10 неудачных попыток
grep "Failed password" /var/log/auth.log | \
awk '{print $(NF-3)}' | sort | uniq -c | \
awk '{if ($1 > 10) print "Count: " $1 ", IP: " $2}'

Что ищем: брутфорс-атаки, попытки входа под несуществующими пользователями.

▪️ 3. Проверка использования sudo
Кто выполнял команды с повышенными привилегиями?

Bash

grep "sudo" /var/log/auth.log | grep "COMMAND" | less

Что ищем: неожиданные команды, выполнение команд пользователями, у которых не должно быть sudo-доступа.

▪️ 4. Мониторинг логов веб-сервера (Nginx/Apache)
Ищем ошибки и подозрительные запросы.

Bash

# Показать все 404 ошибки (запросы к несуществующим страницам)
grep " 404 " /var/log/nginx/access.log | less

# Показать ошибки 5xx (проблемы на стороне сервера)
grep " 50. " /var/log/nginx/error.log | less

Что ищем: попытки сканирования уязвимостей (SQL-инъекции, LFI), неработающие скрипты.

▪️ 5. Проверка логов cron
Убедитесь, что запланированные задачи выполняются корректно.

Bash

grep CRON /var/log/syslog | less

Что ищем: ошибки выполнения скриптов, задачи, которые запускаются слишком часто или не запускаются вовсе.

📌 Автоматизация: Настройте logwatch или goaccess для получения ежедневных сводок и алертов, чтобы не делать всё вручную.

#linux #security #чеклисты #logs #audit

Кейс: «Сервер тормозит, но CPU и RAM в норме». В поисках дискового I/O.

Проблема: Один из наших веб-серверов (Ubuntu + Nginx + PostgreSQL) начал отвечать на запросы очень медленно. Стандартные дашборды в Grafana показывали, что загрузка CPU — 20-30%, использование RAM — около 60%. На первый взгляд, всё в порядке.

Симптомы:

top и htop не показывали процессов, которые бы «съедали» процессор.
Время ответа сайта (TTFB) выросло с 200 мс до 2-3 секунд.
Пользователи жаловались на «зависания» при работе с базой данных.

Диагностика: копаем в сторону дисков
Первая гипотеза: если не CPU и не RAM, значит, проблема в дисковой подсистеме (I/O). Процессы могут простаивать в ожидании, пока диск прочитает или запишет данные.

Шаг 1: top и iowait
Запускаем top и смотрим на строку %Cpu(s). Нас интересует параметр wa — iowait. Он показывал значения 40-50%, что аномально много. Это значит, что процессор почти половину времени ждёт ответа от дисков.

Шаг 2: iotop
Устанавливаем iotop (sudo apt install iotop), чтобы увидеть, какой именно процесс создаёт нагрузку на диск.

Bash

sudo iotop

Картина прояснилась: процесс postgres постоянно что-то писал на диск с высокой скоростью, а также системный процесс jbd2/sda1-8 (журналирование файловой системы ext4) показывал высокую активность.

Ша-г 3: Анализ работы PostgreSQL
Проверка настроек PostgreSQL показала, что уровень логирования был установлен на statement, то есть каждый SQL-запрос писался в лог-файл. Нагрузка на сайт выросла, и база данных генерировала гигантский объём логов, забивая всю пропускную способность диска.

Решение:

Изменили уровень логирования. В postgresql.conf параметр log_statement был изменён с all на ddl. Теперь логируются только изменения схемы, а не каждый SELECT.

Вынесли логи на отдельный диск. В идеальном мире, логи и данные должны лежать на разных физических дисках, чтобы не конкурировать за I/O.

Оптимизировали checkpoint'ы. Увеличили интервалы между checkpoint'ами, чтобы снизить частоту записи «грязных» буферов на диск.

Вывод:
Когда сервер тормозит, а CPU и RAM свободны, — всегда смотрите на iowait. Это «слепая зона» для многих админов. Умение диагностировать дисковые проблемы с помощью iotop и iostat — ключевой навык для поддержания производительности высоконагруженных систем.

#linux #devops #case #postgresql #performance #debug

Как быстро создать файл любого размера для тестов? (Win/Lin/Mac)

Классическая задача: нужно протестировать работу мониторинга, скрипта очистки или уведомлений о заканчивающемся месте на диске. Для этого нужен «мусорный» файл большого размера, но создавать его копированием реальных данных — долго и неудобно.

Вот как сгенерировать такой файл мгновенно в любой ОС.

🐧 Linux: fallocate
Современный и самый быстрый способ. Файл создаётся моментально, так как место под него просто резервируется (pre-allocated), а не заполняется нулями.

▪️ Команда:

Bash

# Создать файл размером 10 гигабайт
fallocate -l 10G large_file.tmp

-l — задаёт размер. Можно использовать K, M, G, T (кило-, мега-, гига-, терабайты).

Классическая альтернатива — dd, но он работает медленнее, так как реально пишет нули на диск:

dd if=/dev/zero of=large_file.tmp bs=1G count=10

⊞ Windows: fsutil
В Windows для этого есть встроенная утилита fsutil. Она работает по тому же принципу, что и fallocate, — мгновенно создаёт пустой файл заданного размера.

▪️ Команда (запускать в CMD или PowerShell от имени администратора):

PowerShell

# Создать файл размером 5 гигабайт (размер в байтах)
fsutil file createnew C:\temp\large_file.tmp 5368709120

Важно: размер указывается в байтах.
Лайфхак для PowerShell, чтобы не считать нули:

PowerShell

# Создать файл на 5 ГБ
fsutil file createnew C:\temp\large_file.tmp (5 * 1GB)

 macOS: mkfile
В macOS (и других BSD-системах) есть своя специальная утилита — mkfile.

▪️ Команда:

Bash

# Создать файл размером 2 гигабайта
mkfile 2g large_file.tmp

Суффиксы k, m, g для размеров также поддерживаются.

📌 Почему fallocate и fsutil лучше?

Эти утилиты не тратят время и ресурсы диска на запись данных. Они просто сообщают файловой системе: «Зарезервируй здесь 10 ГБ». Поэтому файл любого, даже самого гигантского, размера появляется мгновенно. Идеально для быстрых тестов.

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

#команды #linux #windows #macos #testing #sysadmin

От сисадмина к архитектору: 3 нетехнических навыка для роста

Вечер — хорошее время, чтобы на шаг отойти от рутины и подумать о будущем. Мы все умеем гуглить ошибки, чинить упавший сервер и настраивать бэкапы. Эти технические навыки — наш фундамент. Но чтобы расти дальше, от реактивного «тушения пожаров» к проактивному проектированию систем, нужны другие компетенции.

Вот 3 «гибких» навыка, которые отличают опытного админа от архитектора.

1. Системное мышление (Видеть лес за деревьями)

Админ: думает, как починить конкретный сервис.

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

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

2. Умение говорить на языке бизнеса

Админ: «Нам нужно обновить СХД, потому что старая медленная».

Архитектор: «Инвестировав в новую СХД, мы ускорим формирование отчетов на 40% и снизим риск простоя, час которого обходится компании в X тысяч рублей».

Бизнес не мыслит гигабайтами и мегагерцами. Он мыслит деньгами, рисками и эффективностью. Умение перевести техническую необходимость в измеримую бизнес-выгоду — ключевой навык для получения бюджетов и реализации крупных проектов.

3. Проактивная лень (Стратегическая автоматизация)

Реактивная автоматизация — это скрипт, который перезапускает упавший сервис. Проактивная — это система мониторинга и автоматизации, которая предсказывает возможное падение по косвенным метрикам (например, рост iowait) и заранее переносит нагрузку или уведомляет инженера.

Архитектор не просто автоматизирует рутину. Он проектирует системы, которые требуют минимального ручного вмешательства и способны к самодиагностике.

Технические знания — это то, что позволяет нам работать.
Но именно эти три навыка определяют, насколько высоко мы сможем подняться.

#карьера #softskills #архитектура #devops #sysadmin

От Запрета к Контролю: Харденинг Windows с AppLocker на Уровне Архитектора

В современных IT-инфраструктурах традиционные антивирусы и черные списки уже недостаточны. Они реагируют на известные угрозы, оставляя систему уязвимой для атак "нулевого дня". Настоящая безопасность начинается с проактивного контроля.

AppLocker — это не просто блокировщик .exe, а мощный фреймворк для реализации принципа наименьших привилегий на уровне приложений. В отличие от WDAC, AppLocker идеально подходит для гранулярного управления доступом для конкретных пользователей или групп, например, на терминальных серверах.

Шаг 1: Создание Базовой Политики в Режиме Аудита
Самая дорогая ошибка при внедрении AppLocker — немедленное включение блокирующих правил. Это почти гарантированно нарушит бизнес-процессы. Архитектурный подход начинается со сбора данных в безопасном "режиме аудита" (Audit mode). В этом режиме все действия лишь записываются в журнал, не влияя на работу пользователей.

План действий:
▪️ Убедитесь, что служба "Удостоверение приложения" (Application Identity) запущена и настроена на автозапуск. Без нее AppLocker не работает.
▪️ Через GPO перейдите в Computer Configuration > ... > AppLocker.
▪️ Для каждого типа правил (Executable, Script и т.д.) создайте правила по умолчанию (Default Rules). Они разрешают запуск всего из C:\Windows и C:\Program Files, что необходимо для работы ОС.
▪️ В свойствах AppLocker установите режим принуждения в "Audit only" для всех категорий.

Шаг 2: Архитектурный Подход к Исключениям через Группы AD
Управление исключениями через прямое редактирование GPO — негибко. Мощь AppLocker раскрывается при привязке правил к группам безопасности Active Directory. Это превращает статическую политику в динамическую систему управления доступом.

Сценарий: Заблокировать mmc.exe для всех, кроме системных администраторов.

❌ Неправильный подход: Создать правило "Deny" для "Everyone" и "Allow" для "Admins". Microsoft не рекомендует смешивать Deny и Allow для одного приложения.

✅ Правильный подход: Использовать только разрешающие правила. Мы создаем правило, которое разрешает запуск mmc.exe только членам специальной группы. Чтобы дать доступ, нужно просто добавить пользователя в группу, а не лезть в GPO.

Действия:
Создайте группу безопасности в AD:

PowerShell

New-ADGroup -Name "SG_AppLocker_Allow_MMC" -GroupScope Global

В AppLocker (Executable Rules) создайте новое правило "Allow".
Укажите созданную группу SG_AppLocker_Allow_MMC.

В качестве условия выберите "Издатель" (Publisher) и укажите путь к mmc.exe. Это правило не сломается при обновлении файла, в отличие от хэша.

Шаг 3: Блокировка Microsoft Store и WinGet
Правила по умолчанию для упакованных приложений слишком разрешающие. Они позволяют любому пользователю устанавливать ПО из Microsoft Store.

План действий:
▪️ Удалите стандартное правило "Allow all signed packaged apps".
▪️ Создайте новое правило по издателю, разрешающее приложения только от CN=Microsoft Corporation.... Это позволит работать системным UWP-приложениям (Калькулятор, Фото), но заблокирует установку сторонних.

🔄 Заключение: От Политики к Процессу
Внедрение AppLocker — это не разовая настройка, а непрерывный процесс: аудит, анализ логов (Event Viewer > AppLocker), уточнение правил и только потом — переход в режим принудительного применения (Enforce rules). Регулярно просматривайте логи, чтобы адаптировать политики к новым легитимным приложениям.

#Security #Windows #AppLocker #BlueTeam #Hardening #GPO