ping — это не просто "жив/мертв". Диагностируем MTU как SRE

Все используют ping <host>, чтобы проверить, "поднят" ли сервер. Но 90% проблем в сети — не "упало", а "тормозит" или "теряет пакеты".

Продвинутый инженер использует ping для диагностики MTU (Maximum Transmission Unit).

Сценарий: Сервер пингуется, SSH работает, но apt update или git clone "виснут". Скорее всего, у вас MTU Black Hole.

Как найти проблему: Мы отправляем пакет с флагом DF (Don't Fragment) и вручную меняем его размер, пока не найдем "потолок".

Команда "скальпель":

Bash

# -c 3       = отправить 3 пакета
# -M do      = установить DF-бит (Don't Fragment)
# -s 1472    = размер полезной нагрузки (1472 + 28 байт заголовков = 1500)
ping -c 3 -M do -s 1472 google.com

* Получили ответ? Отлично, 1500 MTU работает.

* Получили Frag needed and DF set? БИНГО! Пакет слишком большой. Уменьшайте размер (-s 1462, -s 1452...) пока пакеты не пойдут.

* Вы нашли "потолок", например, 1452. Это и есть ваш MSS.

Взгляд архитектора: Вы не просто "пингуете". Вы валидируете 3-й уровень (L3) вашей сети. Вы не гадаете, а доказываете наличие проблемы с MTU. Это позволяет вам пойти к сетевым инженерам не с жалобой "у меня тормозит", а с фактом: "На этом маршруте Path MTU Discovery не работает, пакеты с MTU > 1480 дропаются. Проверяйте конфиг ip tcp mss-adjust".

#linux #networking #ping #sre #diagnostics #команды #гайд

SELinux: Хватит делать setenforce 0. Учимся "читать" логи аудита

"Приложение не работает. Наверное, SELinux. setenforce 0... О, заработало! Готово".

Это — самый опасный рефлекс системного администратора. Вы только что отключили самый мощный механизм защиты в ядре Linux, который мог бы спасти вас от 0-day уязвимости.

SELinux (Security-Enhanced Linux) — это Mandatory Access Control (MAC). Он не дает root-процессу, если он скомпрометирован (например, Nginx), читать /etc/shadow. Он работает по принципу "запрещено всё, что явно не разрешено политикой".

Проблема: Как "разрешить", не отключая всю систему? Решение: auditd и audit2allow.

План "Архитектора" по решению SELinux-проблемы (на 3 минуты):

Сценарий: Ваш Nginx не может прочитать файлы в /srv/www/html. Вы видите Permission Denied.

1. Проверьте, что это SELinux:
Bash

# Временно переводим в "разрешающий" режим (только логи, без блокировки)
sudo setenforce 0

# Проверяем, заработало ли приложение. Если да — виновник 100% SELinux.

# ВОЗВРАЩАЕМ ЗАЩИТУ!
sudo setenforce 1

2. Находим причину в логах аудита: auditd пишет все "denied" в /var/log/audit/audit.log.
Bash

# Находим все отказы SELinux за последнее время
sudo ausearch -m AVC -ts recent

# ...или "классика"
sudo grep "denied" /var/log/audit/audit.log | tail -n 5

Вы увидите строку, где comm="nginx" (процесс) пытался read (действие) на path="/srv/www/html/index.html" (цель).

3. Генерируем "исключение" (магия): Утилита audit2allow читает этот лог и сама пишет модуль политики за вас.
Bash

# 1. Собираем все недавние отказы в один файл
sudo ausearch -m AVC -ts recent > /tmp/nginx_denials.log

# 2. Генерируем модуль (myNginxFix)
sudo audit2allow -M myNginxFix -i /tmp/nginx_denials.log

# 3. Устанавливаем этот модуль в политику
sudo semodule -i myNginxFix.pp

Готово. Вы не "отключили" безопасность. Вы уточнили политику, разрешив только Nginx читать только вашу папку.

Взгляд архитектора: setenforce 0 — это признание поражения. semodule -i ... — это инженерное решение. Архитектор управляет политиками безопасности, а не отключает их. Это и есть Principle of Least Privilege (Принцип наименьших привилегий) в действии.

#linux #security #selinux #audit #sre #гайд #musthave

Linux: "Кто съел весь канал?" top для вашей сети — nethogs

Классическая проблема: сервер "тормозит", вы запускаете top — CPU в норме, iotop — диски спят. Но пинги высокие, а ssh лагает. Кто-то "ест" всю полосу пропускания, но кто?

netstat и ss покажут соединения. nethogs покажет, какой ПРОЦЕСС генерирует этот трафик.

Как это работает: nethogs — это top для сети. Он группирует трафик по PID и показывает, сколько KB/sec отправляет и получает каждый процесс в реальном времени.

Установка и запуск:
Bash

# Ubuntu/Debian
sudo apt update && sudo apt install nethogs

# RHEL/CentOS
sudo yum install nethogs

Запуск (обязательно с sudo):
Bash

# 1. Мониторить весь трафик
sudo nethogs

# 2. Мониторить только один интерфейс (например, eth0)
sudo nethogs eth0

Вы увидите интерактивный список: PID - USER - PROGRAM - INTERFACE - SENT - RECEIVED.

Взгляд архитектора: Вы не просто "смотрите" на трафик. Вы проводите аудит. Вы можете мгновенно определить:
* backup.sh (rsync), который забыли ограничить по скорости.
* Скомпрометированный apache2, который стал частью ботнета и рассылает спам.
* java-приложение с утечкой данных.

Это переход от "наверное, сеть" к "процесс PID 1234, запущенный от user www-data, шлет 50 МБ/с на этот IP".

#linux #networking #sre #diagnostics #nethogs #команды #гайд

Windows: "Пятничный аудит дисков". Собираем отчет о месте на 100 серверах

Нет ничего хуже, чем получить в субботу critical alert "Disk C: is full on SERVER-SQL-01". Это 100% предотвратимая проблема.

Реакция админа: Вручную проверять 10 серверов. Реакция архитектора: За 5 минут до ухода домой запустить скрипт, который проверит все серверы и пришлет отчет.

Этот PowerShell-скрипт — ваш аудитор "на выходные".

Что делает скрипт:

1. Берёт список серверов из $ServerList.
2. Параллельно (-Parallel) опрашивает их через WMI.
3. Собирает данные только по дискам, заполненным более чем на 85%.
Код скрипта:
PowerShell

[CmdletBinding()]
param (
    [string[]]$ServerList = @(
        "DC01",
        "SQL01",
        "APP01",
        "FILESRV01"
        # ...добавьте все свои серверы
    ),
    [int]$ThresholdPercent = 85
)

Write-Host "--- Начинаю аудит дисков (пороговое значение: $ThresholdPercent%). ---" -ForegroundColor Cyan

# Используем ForEach-Object -Parallel для ускорения.
# ThrottleLimit - сколько серверов опрашивать ОДНОВРЕМЕННО.
$Report = $ServerList | ForEach-Object -Parallel {
    $Server = $_
    $ErrorActionPreference = 'SilentlyContinue' # Игнорировать недоступные хосты
    
    Get-CimInstance -ComputerName $Server -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object @{Name="Server"; Expression={$Server}},
                  DeviceID,
                  @{Name="SizeGB"; Expression={[math]::Round($_.Size / 1GB, 2)}},
                  @{Name="FreeGB"; Expression={[math]::Round($_.FreeSpace / 1GB, 2)}},
                  @{Name="PercentFree"; Expression={[math]::Round(($_.FreeSpace / $_.Size) * 100, 2)}}
} -ThrottleLimit 10

# Фильтруем по порогу и выводим отчет
$CriticalDisks = $Report | Where-Object { $_.PercentFree -lt (100 - $ThresholdPercent) }

if ($CriticalDisks) {
    Write-Host "`n[!!!] ВНИМАНИЕ! ОБНАРУЖЕНЫ КРИТИЧЕСКИЕ ДИСКИ: " -ForegroundColor Red
    $CriticalDisks | Format-Table
} else {
    Write-Host "`n[OK] Все диски в норме. Можно спокойно уходить на выходные." -ForegroundColor Green
}

Взгляд архитектора: Это проактивное управление ёмкостью (Capacity Management). Вы не ждете сбоя. Вы получаете данные для принятия решений: "На FILESRV01 нужно выделить место" или "На APP01 лог-файлы растут слишком быстро". Следующий шаг — поставить этот скрипт в Scheduled Task на 16:00 пятницы.

#windows #powershell #automation #sre #скрипты #audit

Проект на выходные: Homer — ваш идеальный Dashboard для Home Lab

У вас 10+ self-hosted сервисов: Proxmox, Gitea, Uptime Kuma, Nginx Proxy Manager... И вы держите все их IP и порты в голове или в закладках браузера. Это хаос.

Homer — это ваш единый, красивый "пульт управления" для всех ваших сервисов. Это просто статический HTML/YAML сайт.

Почему Homer, а не другие:

* Конфигурация как Код (IaC): Вы не "кликаете" в GUI. Вы описываете свой дашборд в одном config.yml файле.
* Легковесность: Это просто статика. Не нужна БД. Потребляет 0% CPU.
* Интеграции: Показывает "статус" (зеленый/красный) для ваших сервисов.
* Идеально для GitOps: Храните ваш config.yml в Git (на Gitea, который мы ставили!), и ваш дашборд будет версионируемым.

Как запустить (в Docker за 30 сек):
Bash

# 1. Создайте папку и конфиг
mkdir -p /opt/homer/data
touch /opt/homer/data/config.yml

# 2. Запустите контейнер
docker run -d \
  -p 8080:8080 \
  -v /opt/homer/data:/www/assets \
  --name homer \
  b4bz/homer:latest

Теперь откройте http://<ip>:8080 и начните редактировать config.yml, добавляя свои сервисы.

Взгляд архитектора: Это "Single Pane of Glass" (Единое окно). Архитектор не ищет инструменты, он организует их. Homer — это не просто "красиво". Это точка входа в вашу инфраструктуру, которая экономит время и снижает когнитивную нагрузку.

#linux #docker #selfhosted #homelab #devops #гайд #weekendproject

Windows: Ваш PowerShell устарел. Переходим на pwsh.exe

Если вы до сих пор кликаете на синюю иконку (powershell.exe), вы работаете с инструментом 2016 года (версия 5.1).
Современный стандарт — это PowerShell 7+ (pwsh.exe).
Это не просто "обновление", это другой инструмент.

Почему нужно перейти прямо сейчас:

1. Кроссплатформенность: Это главный пункт. pwsh.exe работает одинаково на Windows, Linux и macOS. Вы пишете один скрипт для аудита всей вашей инфраструктуры.

2. Производительность: Он работает на современном .NET Core (6, 7, 8), что делает его значительно быстрее "старого" .NET Framework.

3. Новые фичи: ForEach-Object -Parallel для параллельного выполнения, тернарный оператор (? :), новые командлеты для JSON и RegEx.

Взгляд архитектора: powershell.exe — это оболочка для Windows. pwsh.exe — это универсальный язык автоматизации для всей гибридной инфраструктуры (Cloud + On-prem). Это стандарт де-факто для Azure и Ansible.

#windows #powershell #automation #linux #architect #гайд

Linux: Хватит мучиться с nano и vim. Встречаем micro

Правка конфигов в терминале — это боль. nano слишком примитивен (нет подсветки, неудобный поиск). vim — невероятно мощный, но с высоким порогом входа (как из него выйти?!).

micro — это современный терминальный редактор, который "просто работает". Это nano на стероидах.

Почему он вам понравится:

1. Привычные горячие клавиши: Ctrl+S (сохранить), Ctrl+C (копировать), Ctrl+V (вставить), Ctrl+Q (выйти).

2. Поддержка мыши: Выделение, скроллинг — "из коробки".

3. Подсветка синтаксиса: Понимает >100 языков (YAML, Python, Dockerfile, Bash...).

4. Мощный поиск: Ctrl+F (с поддержкой RegEx).

Установка одной строкой:
Bash

curl https://getmic.ro | bash
# (Или sudo apt install micro / brew install micro)

Взгляд архитектора: Инструменты должны быть удобными. micro снижает "трение" (friction) при работе с серверами, делая вас быстрее и эффективнее. Меньше времени на борьбу с редактором — больше времени на решение задач.

#linux #cli #tools #sysadmin #devops #гайд

Что такое GitOps?

Это не "Git". Это принцип, при котором ваш Git-репозиторий — единственный источник правды.

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

1. Инженер: Пушит config.yml в Git.

2. Автоматика (CI/CD): Видит изменение.

3. Система (Kubernetes/Ansible): Приводит инфраструктуру в соответствие с Git.

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

#architect #devops #gitops #git #iac #sre

Windows: "Аудит красных флагов". Ищем SMBv1 и WinRM HTTP

"Работает — не трогай" — опасный принцип. Часто в сети "живут" серверы со старыми, уязвимыми настройками, оставленными по умолчанию. Две из них — это "открытые ворота" для атак.

1. SMBv1: Древний протокол. Привет, WannaCry. Должен быть выключен везде.

2. WinRM (HTTP): Удаленное управление PowerShell по нешифрованному каналу. Позволяет перехватывать учетные данные.

Этот PowerShell-скрипт — ваш сканер "красных флагов".
Что делает скрипт:
* Берёт список серверов.
* Параллельно (-Parallel) опрашивает их.
* Проверяет, включен ли протокол SMBv1.
* Проверяет, слушает ли WinRM нешифрованный HTTP-порт (5985).
Код скрипта:
PowerShell

[CmdletBinding()]
param (
    [string[]]$ComputerNames = @("SERVER01", "DC01", "APP-02"),
    [switch]$CheckSMB1 = $true,
    [switch]$CheckWinRMHttp = $true
)

Write-Host "--- Начинаю аудит безопасности (SMBv1, WinRM HTTP) ---" -ForegroundColor Cyan

$Report = $ComputerNames | ForEach-Object -Parallel {
    $Server = $_
    $ErrorActionPreference = 'SilentlyContinue'
    
    $Result = [PSCustomObject]@{
        Server = $Server
        SMBv1_Enabled = $null
        WinRM_HTTP_Enabled = $null
    }
    
    if (-not (Test-Connection -ComputerName $Server -Count 1 -Quiet)) {
        $Result.SMBv1_Enabled = "HOST_UNREACHABLE"
        $Result.WinRM_HTTP_Enabled = "HOST_UNREACHABLE"
    } else {
        # 1. Проверка SMBv1
        if ($CheckSMB1) {
            $Result.SMBv1_Enabled = (Get-SmbServerConfiguration -CimSession $Server).EnableSMB1Protocol
        }
        
        # 2. Проверка WinRM HTTP
        if ($CheckWinRMHttp) {
            $Listeners = Get-WSManInstance -CimSession $Server -ResourceURI "winrm/config/Listener"
            $HttpListener = $Listeners | Where-Object { $_.Transport -eq 'HTTP' }
            $Result.WinRM_HTTP_Enabled = [bool]$HttpListener
        }
    }
    
    $Result
} -ThrottleLimit 10

Write-Host "`n--- РЕЗУЛЬТАТ АУДИТА ---"
$Report | Format-Table

Write-Host "`n[!!!] Везде, где 'True' — это уязвимость. Требуется немедленное исправление." -ForegroundColor Red

Взгляд архитектора: Это не просто "аудит". Это валидация вашего Security Baseline. Найденные "True" — это ваше ТЗ на GPO или PowerShell DSC, которые должны принудительно установить EnableSMB1Protocol = $false и удалить HTTP-листенер WinRM по всей инфраструктуре.

#windows #powershell #security #audit #скрипты #sysadmin #smb

Linux: find — это не поиск. Это ваш "скальпель" для файловой системы

Когда df -h показывает 99% на /var, админ начинает судорожно grep-ать логи. Архитектор использует find — один из самых мощных инструментов для массовой обработки файлов.

3 команды find, которые решают реальные проблемы:

1. Найти "пожирателей" места (файлы > 500МБ):
Bash

# Ищем во всей системе (-/) файлы (-type f) размером более 500 МБ
sudo find / -type f -size +500M -exec ls -lh {} \;

Это мгновенно найдет "раздутые" .iso или старые бэкапы.

2. Найти файлы, измененные за последние 24 часа:
Незаменимо при расследовании инцидента. "Что хакер успел поменять?"
Bash

# Ищем в /etc все файлы (-type f), измененные (-mtime) менее 1 дня назад
sudo find /etc -type f -mtime -1

3. Автоматическая чистка старых логов: Зачем делать это вручную?
Bash

# Найти в /var/log все файлы с .log, старше 30 дней, и УДАЛИТЬ их
# Сначала запустите без -delete, чтобы посмотреть, что найдется!
sudo find /var/log -name "*.log" -mtime +30 -delete

-exec rm {} \; тоже сработает, но -delete эффективнее.

Взгляд архитектора: find — это не про "поиск". Это про автоматизацию. Команда find ... -delete — это основа для вашего cron-скрипта по ротации логов и поддержанию гигиены системы.

#linux #find #cli #automation #sysadmin #команды #гайд

ИБ: "Меняйте пароль каждые 30 дней" — Эта политика мертва.

Все мы это настраивали. Классическая GPO: "пароль должен меняться каждые 42 дня" и "содержать 3 из 4...".

Результат: Пользователи пишут пароли на стикерах: MyP@ssw0rd_May, MyP@ssw0rd_June... Это театр безопасности, который снижает защиту.

Современный подход (NIST, Microsoft):

Длина > Сложность: Пароль из 14+ символов (например, "ЯлюблюАдминФьючер2025") надежнее, чем P@s$w0rd!.

ОТКАЗ от принудительной смены: Пароли не должны истекать, если нет признаков компрометации.

MFA — это король: Включите Multi-Factor Authentication везде, где можно. Лучше простой пароль + MFA, чем сложный пароль без него.

Блокировка "слитых" паролей: Используйте Azure AD Password Protection (даже On-prem), чтобы запретить пароли типа "Password123".

FGPP (Fine-Grained Password Policies): Применяйте разные политики. Для Domain Admins — 25+ символов, для User_Vasya — 14+ и MFA.

Взгляд архитектора: Архитектор управляет рисками, а не "ставит галочки". Безопасность не должна мешать работе. Лучше потратить силы на внедрение MFA и FGPP для защиты админов, чем заставлять 1000 пользователей менять пароли каждый месяц.

#security #activedirectory #mfa #zerotrust #architect #гайд

Чек-лист: "Day 0". Первые 10 шагов при вводе нового сервера в строй

Вы развернули VM. Она пингуется. Готово? Нет. "Чистый" сервер — это уязвимый сервер. Вот 10 шагов, которые нужно сделать до того, как отдать сервер в "прод".

□ Hostname & DNS: Установить осмысленное имя. Зарегистрировать в DNS (A-запись и PTR).

□ Сеть: Настроить статический IP, маску, шлюз, DNS-серверы.

□ Часовой пояс & NTP: timedatectl set-timezone ... (Lin) / GPO (Win). Время — критично для Kerberos и логов.

□ Обновления: Установить все последние патчи безопасности (apt update && apt upgrade / wuauclt /detectnow).

□ Удаленный доступ:

Lin: Настроить sshd_config (Key-only, PermitRootLogin no).

Win: Включить и настроить WinRM / RDP (ограничить доступ к RDP!).

□ Базовая безопасность:

Lin: Настроить fail2ban и базовый ufw/firewalld.

Win: Включить LAPS. Убедиться, что файрвол включен.

□ Мониторинг: Установить и настроить агент (Zabbix, Prometheus node_exporter).

□ Бэкап: Настроить агент системы бэкапирования.

□ Логирование: Настроить journald-forwarder (Lin) / WEF (Win) для отправки логов в SIEM.

□ Ввод в домен / CM: Ввести в домен (Win) / Применить плейбук Ansible (Lin).

Взгляд архитектора: Этот чек-лист — не для "ручной" работы. Это техническое задание (ТЗ) для вашего Ansible-плейбука или PowerShell DSC скрипта. Цель — чтобы "Шаг 10" автоматически выполнял шаги 1-9.

#чеклисты #sysadmin #automation #security #windows #linux

Windows: "Призрак" USN Rollback. Почему ваш бэкап AD — это бомба замедленного действия

Каждый админ знает: "Нужно бэкапить Контроллер Домена (DC)". Большинство делает это, просто делая снапшот VM в Hyper-V или VMware.

И ЭТО КАТАСТРОФИЧЕСКАЯ ОШИБКА.

Почему: Active Directory — это мульти-мастер база данных. Каждый DC имеет "счетчик" изменений (USN - Update Sequence Number). Если вы "откатите" DC из снапшота, он "проснется" в прошлом.

Результат: USN Rollback. Ваш "откаченный" DC будет считать, что у него самые свежие данные (хотя это не так), а другие DC будут считать его данные устаревшими. Репликация в домене необратимо ломается. Вы получаете "призраков" (объекты, которые удалены на одном DC, но "воскресли" на другом).

Как ПРАВИЛЬНО бэкапить AD:

Инструмент: Используйте AD-aware софт. Встроенный Windows Server Backup (wbadmin.exe) — самый простой. Он "понимает", что бэкапит DC, и корректно помечает базу ntds.dit.

Восстановление: Всегда используйте Authoritative или Non-Authoritative Restore из DSRM (Directory Services Restore Mode).

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

#windows #activedirectory #security #backup #disasterrecovery #architect #гайд

Проект на выходные: top — мертв. Строим свой SRE-мониторинг на Prometheus + Grafana

htop — это отлично. Но он показывает, что происходит сейчас. Он не скажет вам, что "каждую ночь в 3:05 CPU подскакивает до 100%".

Путь архитектора — это Observability. Вам нужны данные во времени.

Prometheus + Grafana — это "золотой стандарт" SRE и DevOps.

Prometheus: Собирает и хранит метрики (CPU, RAM, I/O, кастомные метрики) в базе данных временных рядов.

Grafana: Визуализирует эти данные в красивые, живые дашборды.

Как запустить за 5 минут (в Docker): Вам нужен docker-compose.yml:
YAML

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Дальнейшие шаги:

Запустите docker-compose up -d.
Настройте Grafana (порт 3000), добавив Prometheus (порт 9090) как DataSource.
Начните собирать метрики с хостов, установив на них node_exporter (для Linux) или windows_exporter (для Windows).

Взгляд архитектора: Вы переходите от реактивного ("сервер упал") к проактивному ("мы видим, что место на диске закончится через 3 дня") мониторингу.

#linux #devops #sre #prometheus #grafana #docker #monitoring #weekendproject

Архитектура: "Docs as Code". Почему ваша документация — это ваш главный актив

Реакция админа: "У меня нет времени писать документацию".
Мысль архитектора: "У меня нет времени НЕ писать документацию".

Документация — это не "скучные Word-файлы".
В современном IT, документация — это код.

Что такое "Docs as Code":

Формат: Вы пишете в Markdown (.md). Это простой, чистый текст.

Хранилище: Вы храните .md файлы в Git-репозитории (на том же Gitea, что мы ставили) вместе с вашими скриптами и IaC-конфигами.

Инструменты: Вы используете MkDocs, Hugo или просто VS Code для рендеринга.

Почему это меняет всё:

Версионность: Ваша документация имеет историю. Вы видите, кто и когда изменил IP-адрес сервера в "runbook".

Runbooks: Вы не "чините по памяти". Вы открываете restore_db.md и копируете проверенные команды.

Схемы как Код: Вы рисуете диаграммы с помощью PlantUML или Mermaid — прямо текстом!

Масштабирование: Вы можете "форкнуть" документацию, предложить изменения через Pull Request.

Взгляд архитектора: Если вас "завтра уволят", а инфраструктура "умрет" через неделю, потому что никто не знает, "как оно работает" — вы были плохим архитектором. Документация — это ваш главный инструмент масштабирования вашего собственного мозга.

#architect #devops #gitops #documentation #sre #стратегия #гайд

Pets vs Cattle: Главный принцип облачной архитектуры

Этот афоризм из мира облачных вычислений меняет всё.

Pets (питомцы):

Это серверы, к которым вы относитесь как к домашним любимцам.

У них есть уникальные имена (db-master-01).

Вы их холите и лелеете, лечите, когда они "болеют".

Если такой сервер падает — это катастрофа, все бегут его поднимать.

Cattle (скот):

Это серверы, к которым относятся как к стаду.

У них нет имён, только номера (web-worker-001, web-worker-002).

Их никто не лечит. Если один сервер "заболел", его просто "пристреливают" (удаляют), а на его место автоматически приходит новый, созданный из того же образа.

Взгляд архитектора: Цель современной архитектуры — превратить как можно больше "питомцев" в "стадо". Это достигается через автоматизацию (Ansible, Terraform) и контейнеризацию (Docker, Kubernetes).

#architect #devops #cloud #sre #petsvscattle #стратегия

Windows 11: Диспетчер задач стал "бессмертным зомби" (KB5067036)

Это не шутка. Это ирония судьбы (или Microsoft).
Инструмент, призванный чистить систему от зависших процессов, сам превратился в "мусор, пожирающий ресурсы".

Суть проблемы (после KB5067036):
При каждом запуске Диспетчера задач (taskmgr.exe) в Windows 11 создается несколько его копий. Эти копии не закрываются после завершения работы с Диспетчером, продолжая висеть в фоне и потреблять CPU/RAM.

Результат:
Утилита, созданная для повышения производительности, начинает замедлять ваш компьютер. Это настоящий "Диспетчер-зомби".

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

Что делать:
1. Будьте внимательны к потреблению ресурсов после установки KB5067036.
2. Если проблема обнаружена — придется завершать "зомби-процессы" через командную строку (taskkill) или ждать исправления от Microsoft.
Подробности: https://www.securitylab.ru/news/565626.php

#windows #windows11 #баги #sysadmin #проблемы #update

ИБ: Атака "Living Off the Land" (LotL). Почему ваш PowerShell опаснее вируса

Забудьте о .exe-вирусах.
Современные атаки (особенно шифровальщики) не заносят "вирус" — они используют ваши собственные, доверенные инструменты против вас.
Это называется "Living Off the Land" (жизнь за счет земли).

Главные "предатели" в вашей системе:

powershell.exe: Запуск base64-команд, скачивание и выполнение скриптов из памяти (IEX (New-Object Net.WebClient).DownloadString(...)).

wmic.exe: Удаленное выполнение команд на других машинах (Lateral Movement).

bitsadmin.exe: Стандартная утилита для скачивания... вредоносных модулей.

certutil.exe: "Легальное" скачивание и декодирование файлов.

Почему это работает? Ваш "классический" антивирус видит, что powershell.exe — это доверенный процесс Microsoft, и игнорирует его вредоносную активность.

Взгляд архитектора: Вы не можете просто "заблокировать PowerShell". Архитектор переходит от сигнатурного анализа к поведенческому.

Внедрите Sysmon: (Мы о нем писали). Он покажет, какой процесс запустил powershell.exe с какими аргументами.

Включите Script Block Logging в GPO: Начните логировать весь код, который выполняет PowerShell.

AppLocker/WDAC: Перейдите в режим "белого списка". Запретите powershell.exe запускаться из папок AppData или Downloads.

#security #windows #powershell #cybersecurity #zerotrust #architect #гайд

Linux: Ваш chroot на стероидах. Знакомство с distrobox

У вас на рабочей машине (или сервере) CentOS, но вам срочно нужен инструмент, который есть только в Ubuntu? Или нужно протестировать скрипт в Arch Linux?

Раньше вы бы ставили VirtualBox или мучились с chroot. Сегодня есть distrobox.

distrobox — это утилита, которая использует podman или docker для запуска любого дистрибутива Linux, но делает это с глубокой интеграцией в вашу основную систему.

Как это работает: Вы запускаете:
Bash

# Создаем "коробку" с Ubuntu 22.04
distrobox create -n ubuntu-box -i ubuntu:22.04
# Входим в нее
distrobox enter ubuntu-box

В чем магия:
* Ваш HOME проброшен внутрь.
* USB-устройства, графика (включая GUI-приложения!) — все работает.
* Вы можете установить zsh в ubuntu-box, и он появится в списке оболочек вашей основной системы.
* Вы можете запустить VS Code из ubuntu-box так, будто он установлен у вас.

Это одноразовые, чистые окружения, которые не загрязняют вашу основную ОС.

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

#linux #distrobox #docker #podman #devops #sysadmin #гайд

Windows Server 2025: "Hotpatching" — это революция. Обновления без перезагрузки

Мы 20 лет жили по правилу: "Вторник — патчи, среда (3 часа ночи) — перезагрузка". Это правило (почти) мертво.

В Windows Server 2025 (и уже сейчас в Azure Edition) Microsoft выкатила "Hotpatching" (Горячее исправление) для всех.

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

Базовый план: Раз в несколько месяцев вы ставите "большой" кумулятивный апдейт (с перезагрузкой).

"Горячие" патчи: В промежутках Microsoft выпускает только патчи безопасности, которые применяются на лету, в оперативной памяти работающих процессов.

Результат: rundll32.exe или lsass.exe "бесшовно" перезапускаются в памяти с новым, исправленным кодом. Сервер не перезагружается. Сервисы не останавливаются.

Взгляд архитектора: Это не "удобство". Это фундаментальное изменение в SLA (Service Level Agreement). Мы больше не выбираем между "быть безопасным" и "быть в аптайме". Мы можем гарантировать 99.99% доступности и быть защищенными. Это меняет подход к проектированию кластеров и окон обслуживания.

#windows #windowsserver #hotpatching #sysadmin #architect #musthave #гайд