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

Ansible для Всех: Автоматизация Харденинга Linux-серверов без Написания Ролей с Нуля

😫 Проблема: Ручной Харденинг
Представим: у вас 50+ Linux-серверов, и служба безопасности требует привести их в соответствие со стандартом CIS Benchmarks. Делать это вручную по SSH — прямой путь к ошибкам, несоответствиям и бессонным ночам. А главное, через месяц конфигурации серверов неизбежно "разъедутся" (configuration drift).

💡 Решение: Сила Ansible Galaxy и Готовых Ролей
Ansible — это не только написание плейбуков с нуля. Его экосистема включает Ansible Galaxy — огромный репозиторий готовых ролей. Для нашей задачи идеально подходит коллекция devsec.hardening, реализующая лучшие практики безопасности.

1️⃣ Шаг 1: Подготовка Окружения
Установите Ansible на вашу управляющую машину.

Установите коллекцию devsec.hardening одной командой:

Bash

ansible-galaxy collection install devsec.hardening

Создайте inventory.ini файл с вашими серверами:

Ini, TOML

[webservers]
web01.example.com
web02.example.com
[dbservers]
db01.example.com

2️⃣ Шаг 2: Создание Плейбука с Готовой Ролью
Вам не нужно знать, как именно работает каждый параметр безопасности. Вам нужно лишь декларативно описать исключения для вашей среды. Например, роль os_hardening по умолчанию отключает IP-форвардинг, который нужен для Docker. Мы можем это легко переопределить.

Код плейбука (playbook.yml):

YAML

- name: Harden all Linux servers
  hosts: all
  become: yes
  roles:
    - role: devsec.hardening.os_hardening
      vars:
        # Пример: разрешаем Docker'у работать
        sysctl_overwrite:
          net.ipv4.ip_forward: 1
        # Пример: оставляем файловую систему vfat для UEFI
        os_filesystem_whitelist:
          - vfat

- name: Harden SSH configuration
  hosts: all
  become: yes
  roles:
    - role: devsec.hardening.ssh_hardening
      vars:
        # Пример: разрешаем вход по паролю (не для прода!)
        sshd_password_authentication: "yes"

3️⃣ Шаг 3: Запуск и Проверка
Сначала выполняем "пробный запуск", который покажет изменения, но ничего не применит:

Bash

ansible-playbook -i inventory.ini playbook.yml --check

Убедившись, что всё корректно, запускаем в рабочем режиме:

Bash

ansible-playbook -i inventory.ini playbook.yml

Ключевое свойство Ansible — идемпотентность. Повторный запуск плейбука не вызовет ошибок. Ansible просто проверит, что все настройки в порядке, и исправит только то, что отклонилось от стандарта. Это позволяет использовать плейбук для регулярной борьбы с "дрейфом конфигурации".

🚀 Заключение: От Администратора к Инженеру по Автоматизации
С помощью нескольких десятков строк YAML-кода мы применили сотни настроек безопасности к целой группе серверов. Это и есть переход к Infrastructure as Code (IaC). Вы не просто администрируете серверы — вы управляете их состоянием через код.

#IaC #Ansible #Linux #Hardening #DevSecOps #Automation

etcd: Цифровой мозг Kubernetes и современных систем

Вечером предлагаю поговорить не о командах, а об идеях. Что общего у Kubernetes, Cloudflare, CoreDNS и десятков других сложных систем? В их основе лежит один и тот же тихий и невероятно надежный компонент — etcd.

Многие админы никогда не работали с ним напрямую, но именно он является цифровой нервной системой для самых критичных частей современной инфраструктуры.

Что такое etcd простыми словами?

Это распределенное хранилище формата «ключ-значение». По сути, это как словарь или телефонная книга, но размазанная по нескольким серверам (кластеру).

Его суперсила — гарантия консистентности. Благодаря алгоритму консенсуса Raft, если вы записали данные в etcd, вы можете быть на 100% уверены, что они сохранены, верны и одинаковы на всех узлах. Кластер etcd может пережить отказ нескольких серверов, не потеряв ни байта.

Почему это так важно для архитектора?
В распределенной системе (как Kubernetes) главная проблема — договориться. Как сотни компонентов (scheduler, kubelet, controllers) должны знать, в каком состоянии находится кластер? Какое состояние является «правильным»?

etcd решает эту проблему, выступая как единый источник правды (Single Source of Truth).

Хранение состояния: В etcd хранится вся конфигурация K8s кластера: какие поды должны быть запущены, какие у них IP, какие секреты используются. Это «желаемое состояние» системы.

Координация и блокировки: Какой контроллер сейчас главный (leader election)? etcd помогает сервисам «договориться» и избежать конфликтов.

Обнаружение сервисов (Service Discovery): Как один сервис находит другой? Он смотрит в etcd, как в адресную книгу.

Что это значит для нас, админов?
Понимание etcd — это ключ к пониманию того, как работает и «думает» Kubernetes.

Бэкап etcd — это бэкап всего состояния вашего кластера. Потеряете etcd — потеряете всё. Это самая важная резервная копия в мире K8s.

Здоровье etcd — это здоровье вашего кластера. Медленный диск под etcd = медленный API и медленная работа всего оркестратора.

С помощью утилиты etcdctl можно напрямую заглянуть «в мозг» кластера (но делать это в prod нужно с большой осторожностью).

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

Отличного вечера!

#Kubernetes #DistributedSystems #etcd #DevOps #Архитектура #SysAdmin

Windows Security: Как правильно заблокировать Microsoft Store через AppLocker

Доброе утро! Начинаем день с важного шага по усилению безопасности рабочих станций.

Одна из неочевидных «лазеек» в Windows — стандартные правила AppLocker для упакованных приложений (Packaged apps). По умолчанию они слишком разрешающие и позволяют любому пользователю устанавливать ПО из Microsoft Store, что открывает вектор для нежелательного ПО и потенциальных атак.

Давайте закроем эту дверь, оставив работать только необходимые системные приложения.

План действий:
❌ 1. Удаляем слишком общее правило
В политике AppLocker для Packaged App Rules найдите и удалите правило по умолчанию, которое называется (Default Rule) Allow all signed packaged apps.

✅ 2. Создаём точечное разрешающее правило
Вместо удаленного правила создайте новое, основанное на издателе (Publisher). Разрешите приложения только от Microsoft:

Издатель: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

Результат: После применения этой политики системные UWP-приложения (Калькулятор, Фотографии и т.д.) продолжат работать, но возможность установки сторонних приложений из Microsoft Store будет заблокирована.

🔄 От Политики к Процессу
Помните главный принцип работы с AppLocker: это не разовая настройка, а непрерывный процесс.

Аудит → Анализ логов → Уточнение правил → Принуждение

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

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

PowerShell/Bash: Массовое Переименование Файлов с Журналированием (и Откатом!)

Сколько раз приходилось переименовывать сотни файлов, добавляя префикс, меняя расширение или убирая лишние символы? Руками — долго и чревато ошибками. Автоматизация — наш лучший друг.

Но что, если что-то пойдёт не так? Важно иметь план отката. Этот пост покажет, как массово переименовывать файлы с сохранением журнала операций, чтобы при необходимости всё можно было вернуть как было.

⊞ Windows (PowerShell): С Журналом и Откатом
Этот скрипт позволяет добавить префикс к именам файлов, записывая старые и новые имена в CSV-файл для возможного отката.

▪️ Скрипт (Rename-Files.ps1):

PowerShell

[CmdletBinding()]
param(
    [string]$Path = (Get-Location).Path,
    [string]$Prefix = "NEW_",
    [string]$LogFile = "rename_log.csv"
)

# Проверяем, существует ли папка для логов
$logPath = Join-Path $Path $LogFile

# Если лог-файл уже существует, спрашиваем, перезаписать или добавить
if (Test-Path $logPath) {
    Write-Warning "Log file '$logPath' already exists. Appending to it."
}

$renameActions = @()

Write-Host "Начинаем переименование файлов в '$Path' с префиксом '$Prefix'..."

Get-ChildItem -Path $Path -File | ForEach-Object {
    $oldName = $_.Name
    $newName = $Prefix + $oldName
    
    try {
        Rename-Item -Path $_.FullName -NewName $newName -PassThru -ErrorAction Stop
        Write-Host "Переименовано: '$oldName' -> '$newName'"
        
        $renameActions += [PSCustomObject]@{
            Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
            OldPath = $_.FullName
            NewPath = Join-Path $_.Directory.FullName $newName
            OldName = $oldName
            NewName = $newName
            Status = "Success"
            Action = "Rename"
        }
    }
    catch {
        Write-Error "Ошибка при переименовании '$oldName': $($_.Exception.Message)"
        $renameActions += [PSCustomObject]@{
            Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
            OldPath = $_.FullName
            NewPath = $null
            OldName = $oldName
            NewName = $null
            Status = "Failed"
            Action = "Rename"
            ErrorMessage = $_.Exception.Message
        }
    }
}

# Экспортируем журнал
$renameActions | Export-Csv -Path $logPath -Append -NoTypeInformation -Force
Write-Host "Журнал операций сохранен в '$logPath'"

# --- Скрипт для отката (сохраните отдельно как Revert-Rename.ps1) ---
<#
.SYNOPSIS
    Откатывает операции переименования файлов на основе CSV-лога.
.EXAMPLE
    .\Revert-Rename.ps1 -LogFile "rename_log.csv"
#>
# Revert-Rename.ps1
param(
    [string]$LogFile = "rename_log.csv"
)

if (-not (Test-Path $LogFile)) {
    Write-Error "Log file '$LogFile' not found."
    exit
}

$actions = Import-Csv -Path $LogFile | Where-Object { $_.Status -eq "Success" -and $_.Action -eq "Rename" }

Write-Host "Начинаем откат операций переименования..."

$actions | ForEach-Object {
    $currentNewPath = $_.NewPath
    $originalOldName = $_.OldName
    
    if (Test-Path $currentNewPath) {
        try {
            Rename-Item -Path $currentNewPath -NewName $originalOldName -PassThru -ErrorAction Stop
            Write-Host "Откачено: '$currentNewPath' -> '$originalOldName'"
        }
        catch {
            Write-Error "Ошибка при откате '$currentNewPath': $($_.Exception.Message)"
        }
    } else {
        Write-Warning "Файл не найден для отката: '$currentNewPath'. Возможно, уже откачен или удален."
    }
}
Write-Host "Откат завершен."

▪️ Как использовать:

Сохраните первый блок как Rename-Files.ps1.
Сохраните второй блок (от <# до конца) как Revert-Rename.ps1.
Запустите .\Rename-Files.ps1 -Path "C:\MyFiles" -Prefix "ARCHIVE_"
Для отката: .\Revert-Rename.ps1 -LogFile "C:\MyFiles\rename_log.csv"

🐧 Linux (Bash): Массовое Переименование + Журнал
Этот Bash-скрипт массово переименовывает файлы, добавляя префикс и создавая простой лог.

▪️ Скрипт (rename_files.sh):

Bash

#!/bin/bash
# Путь к директории (по умолчанию - текущая)
TARGET_DIR="${1:-.}"
# Префикс для новых имен
PREFIX="${2:-NEW_}"
# Файл для журнала
LOG_FILE="${TARGET_DIR}/rename_log_$(date +%Y%m%d%H%M%S).txt"

echo "Начинаем переименование файлов в '${TARGET_DIR}' с префиксом '${PREFIX}'..."
echo "Журнал будет сохранен в '${LOG_FILE}'"
echo "--- Переименование файлов ---" > "${LOG_FILE}"

find "${TARGET_DIR}" -maxdepth 1 -type f | while read -r old_path; do
    old_name=$(basename "$old_path")
    new_name="${PREFIX}${old_name}"
    new_path=$(dirname "$old_path")/"$new_name"

    if mv -v "$old_path" "$new_path"; then
        echo "Переименовано: '$old_name' -> '$new_name'"
        echo "$(date +%Y-%m-%d\ %H:%M:%S) SUCCESS: '$old_name' -> '$new_name'" >> "${LOG_FILE}"
    else
        echo "Ошибка при переименовании: '$old_name'"
        echo "$(date +%Y-%m-%d\ %H:%M:%S) FAILED: '$old_name'" >> "${LOG_FILE}"
    fi
done

echo "Переименование завершено. Журнал в '${LOG_FILE}'"
echo "--- Конец журнала ---" >> "${LOG_FILE}"

▪️ Как использовать:

Сохраните как rename_files.sh и дайте права на выполнение: chmod +x rename_files.sh
Запустите: ./rename_files.sh /path/to/my/files "ARCHIVE_"
/path/to/my/files — директория.
"ARCHIVE_" — префикс.

📌 Важно для отката в Bash:
В отличие от PowerShell, в Bash нет встроенной команды для отката на основе лога mv. Для отката вам нужно будет вручную проанализировать созданный rename_log_*.txt и выполнить обратные команды mv.

Bash
`
# Пример записи из лога:
# SUCCESS: 'old_file.txt' -> 'NEW_old_file.txt'

# Команда для отката:
mv /path/to/files/NEW_old_file.txt /path/to/files/old_file.txt
`
Это демонстрирует, почему PowerShell часто предпочтительнее для сложных операций, где требуется атомарность и лёгкость отката.

#powershell #bash #скрипты #automation #files #sysadmin

От Пингов к Инсайтам: Развертывание Стека Observability (Prometheus, Loki, Grafana)

Традиционный мониторинг отвечает на вопрос «Что сломалось?». Наблюдаемость (observability) отвечает на вопрос «Почему это сломалось?». Она строится на трех столпах: метриках (числа), логах (события) и трейсах (путь запроса).

Этот гайд проведет вас по полному циклу развертывания золотого стандарта open-source для связки метрик и логов.

1️⃣ Шаг 1: Установка Prometheus и Node Exporter (Метрики)
▪️ Prometheus: Это сервер, который будет опрашивать (scrape) источники метрик. Скачайте и запустите его.
▪️ Node Exporter: Это агент, который вы ставите на каждый наблюдаемый сервер. Он собирает системные метрики (CPU, RAM, диск, сеть) и отдает их Prometheus'у.

Существуют сотни других экспортеров для баз данных, веб-серверов и оборудования, что делает Prometheus универсальной платформой.

▪️ Конфигурация prometheus.yml: Добавьте Node Exporter как цель.

YAML

scrape_configs:
  - job_name: 'node_exporter_metrics'
    static_configs:
      - targets: ['your_server_ip:9100']

После запуска проверьте метрики в веб-интерфейсе Prometheus (http://<prometheus_ip>:9090).

2️⃣ Шаг 2: Установка Loki и Promtail (Логи)
▪️ Loki: Сервер, который принимает и хранит ваши логи.
▪️ Promtail: Агент, который ставится на серверы, "читает" лог-файлы (/var/log/*.log), добавляет к ним метки (labels) и отправляет в Loki.

Ключевое отличие Loki от ELK: он не индексирует всё содержимое логов, а только метки (например, job="nginx"). Это делает его чрезвычайно экономичным и быстрым.

▪️ Конфигурация promtail-config.yml:

YAML

server:
  http_listen_port: 9080

clients:
  - url: http://<loki_ip>:3100/loki/api/v1/push

scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      host: your_server_hostname
      __path__: /var/log/*.log

3️⃣ Шаг 3: Установка Grafana и Интеграция
▪️ Установите и запустите Grafana — наш будущий центр управления.
▪️ В веб-интерфейсе (http://<grafana_ip>:3000) перейдите в Connections > Data sources.
▪️ Добавьте Prometheus, указав его URL.
▪️ Добавьте Loki, указав его URL.

4️⃣ Шаг 4: Магия Корреляции Данных
Теперь самое главное. На одном экране мы видим график метрик и связанные с ним логи.

Сценарий: Пользователи жалуются на тормоза сайта.

Вы открываете дашборд в Grafana и видите пик загрузки CPU (данные из Prometheus).

Прямо под этим графиком у вас панель с логами из Loki, отфильтрованными по job="nginx" и level="error".

Вы видите, что в момент пика CPU в логах Nginx появился шквал ошибок upstream timed out.

Вывод: Проблема не в сервере, а в бэкенд-приложении. Диагностика заняла минуты, а не часы.

План действий в Grafana:
▪️ Импортируйте готовый дашборд для Node Exporter (ID: 1860).
▪️ Добавьте на него новую панель с источником данных Loki.
▪️ Используйте LogQL-запрос для фильтрации, например: {host="$hostname"} |= "error".

#Observability #Monitoring #Prometheus #Loki #Grafana #DevOps

Пятница, вечер. Ноутбук закрыт, задачи на паузе.

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

Давайте подведем итоги недели в нашем стиле. Без отчетов и совещаний, а одним кликом.

Опрос: Главная «боль» этой недели — это...

1️⃣ Сетевые проблемы (VPN, DNS, «не пингуется!»)
Когда половина дня уходит на поиск причины, а виноват кабель или кривой роутинг.

2️⃣ Софт/Сервисы (база упала, приложение зависло)
Когда логи кричат об ошибках, а разработчики говорят, что у них «все работает».

3️⃣ Железо/Виртуализация (диски, память, хосты)
Когда сервер решил, что ему пора на пенсию, не предупредив об этом.

4️⃣ Пользователи/Безопасность (странные тикеты, фишинг)
Когда самый непредсказуемый элемент системы — это человек.

5️⃣ Всё было на удивление спокойно (такое бывает?)
Когда все работает как часы, и ты начинаешь подозревать, что что-то не так.

Всем, кто справился — наше уважение. Отличных и спокойных выходных, коллеги!

#Пятница #SysadminLife #Опрос #IT

Запускаем Ansible в один клик: Визуализация автоматизации с помощью AWX/Semaphore

Многие из нас используют Ansible, запуская плейбуки из командной строки. Это отлично работает для личных задач. Но как только мы начинаем работать в команде, возникают вопросы:

Как безопасно хранить ключи и пароли?

Как дать junior-админу кнопку для запуска рутинной задачи, не давая SSH-доступ к серверам?

Как видеть историю всех запусков и кто что изменил?

Ответ — веб-интерфейс для Ansible.

▪️ Что это такое?
AWX (open-source версия Ansible Tower) и его легковесный аналог Semaphore — это веб-панели, которые превращают ваши плейбуки в полноценный сервис автоматизации.

▪️ Что вы получаете:

Централизованное управление: Все ваши плейбуки, инвентари и проекты в одном месте.

Безопасное хранение credentials: SSH-ключи, токены облаков и пароли хранятся в зашифрованном виде.

RBAC (Role-Based Access Control): Вы можете создать учетные записи для коллег и дать им права только на запуск конкретных плейбуков (например, «Перезагрузить тестовый веб-сервер»).

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

Планировщик заданий (Scheduler): Встроенный аналог cron для запуска плейбуков по расписанию.

API: Управляйте автоматизацией из других систем, встраивая ее в CI/CD пайплайны.

🧠 Взгляд архитектора:
Переход на AWX/Semaphore — это не просто удобство. Это смена парадигмы. Вы перестаете быть «человеком, который запускает скрипты» и становитесь инженером, который строит платформу автоматизации для всей команды. Вы начинаете управлять не серверами, а процессами.

▪️ Как начать?
Самый простой способ — развернуть Semaphore или AWX через docker-compose. Подключите свой Git-репозиторий с плейбуками, настройте доступы, и ваша командная работа выйдет на новый уровень.

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

#Ansible #AWX #Semaphore #DevOps #Automation #IaC #Архитектура

Логи без боли: Как поднять централизованный сбор логов за 15 минут с Loki

Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.

Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.

▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.

Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.

▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.

YAML

version: "3"

networks:
  loki:

services:
  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/local-config.yaml
    networks:
      - loki

  promtail:
    image: grafana/promtail:latest
    volumes:
      - /var/log:/var/log
      - ./promtail-config.yml:/etc/promtail/config.yml
    command: -config.file=/etc/promtail/config.yml
    networks:
      - loki

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    networks:
      - loki

▪️ Что нужно сделать:

Сохраните текст выше в файл docker-compose.yml.

Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).

Запустите: docker-compose up -d.

Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.

Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.

#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin

WireGuard: VPN нового поколения. Просто, быстро и безопасно.

Годами мы настраивали громоздкие и сложные IPsec и OpenVPN. Но мир не стоит на месте. WireGuard — это современный взгляд на VPN, который ставит во главу угла простоту, производительность и криптографическую надёжность.

▪️ Почему WireGuard — это будущее?

Минимализм: Весь код WireGuard — это всего несколько тысяч строк, в то время как OpenVPN или IPsec — это сотни тысяч. Его можно проаудировать за один день. Меньше кода — меньше потенциальных уязвимостей.

Производительность: WireGuard работает на уровне ядра Linux, что обеспечивает огромный прирост в скорости и минимальные задержки по сравнению с аналогами, работающими в user-space.

Современная криптография: Он использует новейшие и проверенные криптографические примитивы (ChaCha20, Poly1305, Curve25519), избавляясь от устаревших и небезопасных алгоритмов.

Простота конфигурации: Забудьте о сотнях параметров. Конфигурация WireGuard напоминает настройку SSH-ключей. Вы обмениваетесь публичными ключами, и всё работает.

▪️ Пример: Настройка простого туннеля "сервер-клиент"
Задача: Соединить ваш ноутбук (клиент) с домашним сервером (сервер).

Установка: sudo apt install wireguard или sudo dnf install wireguard-tools

Генерация ключей (на обеих машинах):

Bash

wg genkey | tee privatekey | wg pubkey > publickey

Конфигурация Сервера (/etc/wireguard/wg0.conf):

Ini, TOML

[Interface]
Address = 10.10.0.1/24
PrivateKey = <содержимое privatekey сервера>
ListenPort = 51820

[Peer]
PublicKey = <содержимое publickey клиента>
AllowedIPs = 10.10.0.2/32

Конфигурация Клиента (например, на ноутбуке):

Ini, TOML

[Interface]
Address = 10.10.0.2/24
PrivateKey = <содержимое privatekey клиента>

[Peer]
PublicKey = <содержимое publickey сервера>
Endpoint = <публичный_IP_сервера>:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25

Запуск (на обеих машинах): wg-quick up wg0

Теперь ваш клиент может обращаться к серверу по адресу 10.10.0.1 так, как будто они в одной локальной сети. Это элегантно, быстро и безопасно.

#WireGuard #VPN #Security #Linux #Networking #DevSecOps