🪟 Windows: Официальный sudo — конец эпохи лишних окон консоли
Мы только что обсуждали, как Linux избавляется от sudo в пользу run0. Иронично, но в мире Windows происходит ровно обратное. В Windows 11 и Windows Server 2025 утилита sudo стала официальной встроенной частью операционной системы.
Границы между администрированием Windows и Linux продолжают стираться. Консоль становится универсальным и удобным местом для работы.
#windows #sudo #cli #powershell #sysadmin #admin_future
Мы только что обсуждали, как Linux избавляется от sudo в пользу run0. Иронично, но в мире Windows происходит ровно обратное. В Windows 11 и Windows Server 2025 утилита sudo стала официальной встроенной частью операционной системы.
Вы открыли обычный PowerShell, пишите скрипт, пытаетесь перезапустить службу, и получаете Access Denied. Приходилось тянуться за мышкой, искать ярлык PowerShell, нажимать «Запуск от имени администратора», копировать туда команду и выполнять.
Microsoft добавила нативный sudo. Прямо в текущем окне с правами обычного пользователя вы пишете:
sudo Restart-Service -Name W3SVC
В настройках системы (Settings — For developers — Enable sudo) админ может выбрать один из трех режимов работы:
1. В новом окне (In a new window) — классическое поведение Windows.
2. С отключенным вводом (With input disabled) — команда выполнится в этом же окне, но не сможет запрашивать у вас дополнительные данные (безопасный режим для скриптов).
3. Встроенный (Inline) — полная аналогия с Linux. Команда выполняется прямо здесь и сейчас, весь вывод идет в текущую консоль.
Для удобства и скорости. Если вы много работаете в терминале Windows Terminal, вам больше не нужно жонглировать вкладками с разными уровнями привилегий.
Границы между администрированием Windows и Linux продолжают стираться. Консоль становится универсальным и удобным местом для работы.
#windows #sudo #cli #powershell #sysadmin #admin_future
🧹 Windows: Уборка в лесу — ищем GPO-призраки через PowerShell
Коллеги, в любом домене со временем накапливается мусор. Мы создаем тестовые политики, применяем их, а потом забываем удалить. Когда приходит время провести масштабную реструктуризацию политик и передать часть функционала коллеге, этот мусор сильно мешает и путает.
Код для PowerShell:
#windows #powershell #activedirectory #gpo #sysadmin #admin_future
Коллеги, в любом домене со временем накапливается мусор. Мы создаем тестовые политики, применяем их, а потом забываем удалить. Когда приходит время провести масштабную реструктуризацию политик и передать часть функционала коллеге, этот мусор сильно мешает и путает.
Скрипт ниже найдет все групповые политики, которые либо полностью отключены, либо никуда не привязаны.
Код для PowerShell:
$AllGPOs = Get-GPO -All
foreach ($GPO in $AllGPOs) {
$Report = Get-GPOReport -Guid $GPO.Id -ReportType Xml
if ($GPO.GpoStatus -eq 'AllSettingsDisabled' -or $Report -notmatch 'LinksTo') {
Write-Host "Кандидат на удаление: " $GPO.DisplayName}
}
Чистый Active Directory работает быстрее и предсказуемее. Любая реструктуризация GPO должна начинаться с удаления всего, что не работает и просто висит мертвым грузом.
#windows #powershell #activedirectory #gpo #sysadmin #admin_future
🔥1
🛡️ Network: Автоматическая чистка неактивных пиров WireGuard на MikroTik
WireGuard шикарен, но у него есть особенность: он работает без классических сессий. Из-за этого сложно сходу понять, жив ли пир (клиент) или ключ давно скомпрометирован и валяется без дела. Если у вас подняты десятки туннелей, нужен скрипт, который будет отслеживать активность.
Код для RouterOS (добавляем в System Scripts и ставим в Scheduler):
#mikrotik #routeros #wireguard #networking #security #admin_future
WireGuard шикарен, но у него есть особенность: он работает без классических сессий. Из-за этого сложно сходу понять, жив ли пир (клиент) или ключ давно скомпрометирован и валяется без дела. Если у вас подняты десятки туннелей, нужен скрипт, который будет отслеживать активность.
Давайте напишем код для RouterOS, который проверяет время последнего рукопожатия и выключает пир, если его не было слишком долго.
Код для RouterOS (добавляем в System Scripts и ставим в Scheduler):
:local maxIdleDays 30;
/interface wireguard peers
:foreach peer in=[find] do={
:local lastHandshake [get $peer last-handshake];
:if ([:len $lastHandshake] > 0) do={
:local idleTime ([/system clock get time] - $lastHandshake);
:if ($idleTime > "30d 00:00:00") do={
disable $peer;
:log warning ("Отключен неактивный WireGuard пир");
}
}
}
Для жесточайшей гигиены периметра. Неиспользуемые доступы — главная дыра в безопасности. Если подрядчик уволился, а вы забыли закрыть доступ, этот скрипт подстрахует вашу сеть.
#mikrotik #routeros #wireguard #networking #security #admin_future
🚌 Skills: «Фактор автобуса» — главный риск, о котором молчат сисадмины
Представьте ситуацию: вы единственный, кто знает, как работает связка вашей базы данных, DMZ-зоны и хитрого скрипта очистки логов. А теперь представьте, что вы выиграли в лотерею и улетели на острова без связи. Или, что менее приятно, попали под автобус (отсюда и термин Bus Factor).
Почему это вредит лично вам:
Как повышать Bus Factor в 2026 году:
Незаменимых людей нет, есть люди, после ухода которых приходится всё перестраивать с нуля. Делитесь знаниями и не будьте узким горлышком своей инфраструктуры.
#skills #management #busfactor #sysadmin #bestpractices #admin_future
Представьте ситуацию: вы единственный, кто знает, как работает связка вашей базы данных, DMZ-зоны и хитрого скрипта очистки логов. А теперь представьте, что вы выиграли в лотерею и улетели на острова без связи. Или, что менее приятно, попали под автобус (отсюда и термин Bus Factor).
Фактор автобуса — это количество людей в команде, которых нужно потерять, чтобы IT-инфраструктура компании полностью встала. Если этот фактор равен единице (только вы), это катастрофа и для бизнеса, и лично для вас.
Почему это вредит лично вам:
— Невозможно уйти в нормальный отпуск. Телефон будет звонить даже на пляже.
— Невозможно пойти на повышение. Вас банально некем заменить на текущем месте, вы стали заложником собственной инфраструктуры.
— Выгорание. Вы несете ответственность за все системы 24 на 7.
Как повышать Bus Factor в 2026 году:
— Пароли: Никаких личных блокнотов и файлов на рабочем столе. Только корпоративный менеджер паролей с доступом для коллег.
— Документация: Описывайте не только «как сделать», но и «почему мы сделали именно так».
— Перекрестное обучение: Возьмите за правило раз в неделю садиться с коллегой и показывать ему одну из ваших систем. Разбирали вчера архитектуру DMZ-сервера? Проведите мини-презентацию для отдела.
Незаменимых людей нет, есть люди, после ухода которых приходится всё перестраивать с нуля. Делитесь знаниями и не будьте узким горлышком своей инфраструктуры.
#skills #management #busfactor #sysadmin #bestpractices #admin_future
🐧 Linux: Хватит раскидывать ключи ssh-rsa. Переходим на SSH-сертификаты
Коллеги, управлять ключами SSH даже в небольшой команде — это боль. Мы генерируем ключи, копируем их в authorized_keys на десятки серверов. А когда администратор увольняется или теряет ноутбук, мы судорожно пытаемся вспомнить, на каких именно машинах нужно срочно зачистить его доступы. В 2026 году такой подход — это дыра в безопасности.
Современный стандарт — настройка внутреннего удостоверяющего центра (CA) для SSH.
Как это работает:
Зачем это нужно:
У вас на серверах больше нет файла authorized_keys с десятками непонятных строк. Вы полностью избавляетесь от процесса отзыва доступов. Если человек ушел в отпуск или уволился — его сертификат просто истекает к концу рабочего дня и превращается в тыкву. Взлом ноутбука инженера на выходных больше не дает хакеру ключи от всего продакшена.
Настроить SSH CA можно за пару часов встроенными средствами OpenSSH. Это тот самый случай, когда внедрение крутой безопасности делает жизнь админа проще, а не сложнее.
#linux #ssh #security #sysadmin #bestpractices #admin_future
Коллеги, управлять ключами SSH даже в небольшой команде — это боль. Мы генерируем ключи, копируем их в authorized_keys на десятки серверов. А когда администратор увольняется или теряет ноутбук, мы судорожно пытаемся вспомнить, на каких именно машинах нужно срочно зачистить его доступы. В 2026 году такой подход — это дыра в безопасности.
Современный стандарт — настройка внутреннего удостоверяющего центра (CA) для SSH.
Как это работает:
— Вы генерируете одну пару ключей для Удостоверяющего Центра (CA).
— Публичный ключ CA кладется на все ваши серверы в конфигурацию sshd.
— Когда инженеру нужен доступ, он отправляет свой публичный ключ на CA.
— CA выдает ему подписанный сертификат, в котором жестко указано: кому он выдан и сколько времени он действует (например, ровно 8 часов).
Зачем это нужно:
У вас на серверах больше нет файла authorized_keys с десятками непонятных строк. Вы полностью избавляетесь от процесса отзыва доступов. Если человек ушел в отпуск или уволился — его сертификат просто истекает к концу рабочего дня и превращается в тыкву. Взлом ноутбука инженера на выходных больше не дает хакеру ключи от всего продакшена.
Настроить SSH CA можно за пару часов встроенными средствами OpenSSH. Это тот самый случай, когда внедрение крутой безопасности делает жизнь админа проще, а не сложнее.
#linux #ssh #security #sysadmin #bestpractices #admin_future
🔥4
🪟 Windows: Обновляем весь зоопарк софта одной командой через WinGet
Раньше для централизованного обновления стороннего софта (браузеры, архиваторы, мессенджеры) на парке машин мы использовали тяжеловесные решения вроде SCCM, сторонние патч-менеджеры или писали километровые скрипты-обертки.
Сейчас все стало гораздо элегантнее. Встроенный пакетный менеджер WinGet давно оброс мускулами и отлично справляется с этой задачей через консоль.
Скрипт для PowerShell (запускать от администратора):
Как это работает:
Уязвимости нулевого дня в браузерах и PDF-читалках — это любимый вектор атак шифровальщиков. Повесьте этот скрипт в Планировщик задач на компьютерах пользователей, например, на обеденное время среды. Система сама закроет 90% дыр в стороннем софте без вашего ручного вмешательства.
#windows #powershell #winget #automation #sysadmin #admin_future
Раньше для централизованного обновления стороннего софта (браузеры, архиваторы, мессенджеры) на парке машин мы использовали тяжеловесные решения вроде SCCM, сторонние патч-менеджеры или писали километровые скрипты-обертки.
Сейчас все стало гораздо элегантнее. Встроенный пакетный менеджер WinGet давно оброс мускулами и отлично справляется с этой задачей через консоль.
Скрипт для PowerShell (запускать от администратора):
winget upgrade --all --silent --accept-package-agreements --accept-source-agreements
Как это работает:
Команда проверяет абсолютно все установленные приложения, сравнивает их версии с официальными репозиториями и в тихом режиме (без окон установки) накатывает свежие патчи, автоматически соглашаясь с лицензионными условиями.
Уязвимости нулевого дня в браузерах и PDF-читалках — это любимый вектор атак шифровальщиков. Повесьте этот скрипт в Планировщик задач на компьютерах пользователей, например, на обеденное время среды. Система сама закроет 90% дыр в стороннем софте без вашего ручного вмешательства.
#windows #powershell #winget #automation #sysadmin #admin_future
❤2
🧠 Skills: Бэкап Шредингера — почему ваши резервные копии ничего не стоят
У вас настроены автоматические бэкапы баз данных, конфигураций роутеров выгружаются по расписанию, а виртуалки снепшотятся каждую ночь. Вы молодец, спите спокойно. Но задайте себе один неудобный вопрос: когда вы в последний раз пробовали развернуть инфраструктуру с нуля из этих архивов?
Суровая истина системного администрирования гласит: бэкап, который никогда не восстанавливали — это не бэкап. Это просто дорогой файл, занимающий место на диске.
Что происходит на практике в момент аварии:
Выясняется, что скрипт полгода копировал пустые папки. Пароль от зашифрованного архива знает только бывший сотрудник. Свежая база данных отказывается разворачиваться на старой версии СУБД, а файл с конфигурацией Nginx почему-то вообще не попал в список исключений для бэкапа.
Как лечить:
Опыт инженера измеряется не умением написать bash-скрипт для архивации, а гарантированным временем (RTO), за которое он способен поднять компанию из пепла.Тестируйте восстановление, пока это можно сделать без паники и седых волос.
#skills #backup #disasterrecovery #management #sysadmin #admin_future
У вас настроены автоматические бэкапы баз данных, конфигураций роутеров выгружаются по расписанию, а виртуалки снепшотятся каждую ночь. Вы молодец, спите спокойно. Но задайте себе один неудобный вопрос: когда вы в последний раз пробовали развернуть инфраструктуру с нуля из этих архивов?
Суровая истина системного администрирования гласит: бэкап, который никогда не восстанавливали — это не бэкап. Это просто дорогой файл, занимающий место на диске.
Что происходит на практике в момент аварии:
Выясняется, что скрипт полгода копировал пустые папки. Пароль от зашифрованного архива знает только бывший сотрудник. Свежая база данных отказывается разворачиваться на старой версии СУБД, а файл с конфигурацией Nginx почему-то вообще не попал в список исключений для бэкапа.
Как лечить:
Внедряйте правило Disaster Recovery Day (День аварийного восстановления). Раз в квартал выделяйте чистый тестовый сервер. Отключайтесь от основной сети и пытайтесь поднять копию критического сервиса, используя исключительно вашу документацию и ночные бэкапы.
Опыт инженера измеряется не умением написать bash-скрипт для архивации, а гарантированным временем (RTO), за которое он способен поднять компанию из пепла.
#skills #backup #disasterrecovery #management #sysadmin #admin_future
🐧 LINUX: КАК НАЙТИ РУТКИТ ИЛИ МАЙНЕР, КОТОРЫЙ ПРЯЧЕТСЯ ОТ КОМАНДЫ PS
Коллеги, если сервер в DMZ тормозит, а команды top и ps aux показывают нормальную загрузку, возможно, вы столкнулись с процессом, который спрятали в изолированном PID-namespace.
Современные майнеры активно используют архитектуру Linux для маскировки, и базовой гигиены здесь уже недостаточно.
Стандартные утилиты читают директорию /proc. Если злоумышленник примонтировал поверх /proc пустую файловую систему tmpfs, вы ничего не увидите.
Скрипт для поиска скрытых процессов через обход пользовательских mount namespaces:
Зачем это нужно:
Для глубокого аудита безопасности инфраструктуры. Простые проверки больше не работают. Этот трюк позволяет увидеть реальную картину процессов на уровне ядра, игнорируя пользовательские маскировки.
#linux #security #namespaces #sysadmin #admin_future
Коллеги, если сервер в DMZ тормозит, а команды top и ps aux показывают нормальную загрузку, возможно, вы столкнулись с процессом, который спрятали в изолированном PID-namespace.
Современные майнеры активно используют архитектуру Linux для маскировки, и базовой гигиены здесь уже недостаточно.
Стандартные утилиты читают директорию /proc. Если злоумышленник примонтировал поверх /proc пустую файловую систему tmpfs, вы ничего не увидите.
Скрипт для поиска скрытых процессов через обход пользовательских mount namespaces:
mkdir /mnt/real_proc
mount -o bind /proc /mnt/real_proc
ls -l /mnt/real_proc | grep '^[0-9]'
Зачем это нужно:
Для глубокого аудита безопасности инфраструктуры. Простые проверки больше не работают. Этот трюк позволяет увидеть реальную картину процессов на уровне ядра, игнорируя пользовательские маскировки.
#linux #security #namespaces #sysadmin #admin_future
✍2
👻 WINDOWS: ОХОТА ЗА ПРИЗРАКАМИ. УДАЛЯЕМ МЕРТВЫЕ SID ИЗ ПРАВ ДОСТУПА
При реорганизации инфраструктуры и чистке домена от легаси-объектов мы часто удаляем старые учетные записи. Но права доступа на файловых серверах (NTFS ACL) остаются. Вместо имен пользователей там появляются неопознанные SID (начинаются с S-1-5-21...).
Это не просто эстетическая проблема. При миграции серверов или глубоком аудите эти мертвые души сильно тормозят пересчет прав, ломают наследование и создают хаос в политиках безопасности.
PowerShell скрипт для поиска и удаления мертвых SID:
Зачем это нужно:
Порядок в Active Directory должен отражаться порядком в файловых системах. Идеально подходит для включения в план реструктуризации домена и вывода из эксплуатации старых систем вроде Windows 2012 R2.
#windows #powershell #activedirectory #security #admin_future
При реорганизации инфраструктуры и чистке домена от легаси-объектов мы часто удаляем старые учетные записи. Но права доступа на файловых серверах (NTFS ACL) остаются. Вместо имен пользователей там появляются неопознанные SID (начинаются с S-1-5-21...).
Это не просто эстетическая проблема. При миграции серверов или глубоком аудите эти мертвые души сильно тормозят пересчет прав, ломают наследование и создают хаос в политиках безопасности.
PowerShell скрипт для поиска и удаления мертвых SID:
$Path = "C:\Shares\Department"
$ACLs = Get-Acl -Path $Path
$Rules = $ACLs.Access | Where-Object { $_.IdentityReference -match "^S-1-5-21" }
foreach ($Rule in $Rules) {
$ACLs.RemoveAccessRule($Rule) | Out-Null
Write-Host "Удален мертвый SID: " $Rule.IdentityReference
}
Set-Acl -Path $Path -AclObject $ACLs
Зачем это нужно:
Порядок в Active Directory должен отражаться порядком в файловых системах. Идеально подходит для включения в план реструктуризации домена и вывода из эксплуатации старых систем вроде Windows 2012 R2.
#windows #powershell #activedirectory #security #admin_future
❤3
🐧 Linux: eBPF-трейсинг вместо strace — хирургия без анестезии
Коллеги, когда в 3 ночи продакшн-сервис начинает вести себя странно, первый рефлекс — запустить strace на процесс. И вот ты сидишь, смотришь в поток syscall-ов, теряешь контекст, а overhead от strace в худшем случае убивает процесс быстрее, чем сам баг.
В 2026 году так делать стыдно. Добро пожаловать в bpftrace — если strace это кувалда, то bpftrace это эндоскоп.
Хочешь знать, какие файлы открывает конкретный процесс, сколько времени он тратит в ядре и где реально лежит латентность — без остановки сервиса и почти без overhead:
Зачем это нужно:
Бизнес платит за uptime, а не за твои ночные медитации над strace-логом. bpftrace работает в ядре, не требует перезапуска процессов, не ломает продакшн и даёт гистограммы латентности за секунды. Когда Роман спрашивает "в чём причина деградации?", у тебя есть ответ с цифрами, а не с "ну, мы смотрим".
Итог: strace незаменим для разработки. Но в живом продакшне — только eBPF. Это разница между вскрытием и МРТ.
#linux #ebpf #bpftrace #performance #sysadmin #admin_future
Коллеги, когда в 3 ночи продакшн-сервис начинает вести себя странно, первый рефлекс — запустить strace на процесс. И вот ты сидишь, смотришь в поток syscall-ов, теряешь контекст, а overhead от strace в худшем случае убивает процесс быстрее, чем сам баг.
В 2026 году так делать стыдно. Добро пожаловать в bpftrace — если strace это кувалда, то bpftrace это эндоскоп.
Хочешь знать, какие файлы открывает конкретный процесс, сколько времени он тратит в ядре и где реально лежит латентность — без остановки сервиса и почти без overhead:
# Все открываемые файлы процессом nginx в реальном времени
bpftrace -e '
tracepoint:syscalls:sys_enter_openat
/comm == "nginx"/
{
printf("%s -> %s\n", comm, str(args->filename));
}
'
# Латентность read() по перцентилям — находим I/O-узкое место
bpftrace -e '
tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
tracepoint:syscalls:sys_exit_read /@start[tid]/
{
@lat = hist(nsecs - @start[tid]);
delete(@start[tid]);
}
'
Зачем это нужно:
Бизнес платит за uptime, а не за твои ночные медитации над strace-логом. bpftrace работает в ядре, не требует перезапуска процессов, не ломает продакшн и даёт гистограммы латентности за секунды. Когда Роман спрашивает "в чём причина деградации?", у тебя есть ответ с цифрами, а не с "ну, мы смотрим".
Итог: strace незаменим для разработки. Но в живом продакшне — только eBPF. Это разница между вскрытием и МРТ.
#linux #ebpf #bpftrace #performance #sysadmin #admin_future
🪟 Windows: LAPS v2 + Entra ID — хватит хранить пароль локального админа в Excel
Коллеги, я знаю, что где-то в вашей сети до сих пор живёт локальный Administrator с паролем из 2019 года, который записан в заметках у Богдана. И Богдан уже полгода как уволился.
Классический LAPS первого поколения умел ротировать пароль и класть его в AD — и это было неплохо. Но LAPS v2, встроенный в Windows Server 2025 и Windows 11, это уже другой уровень: шифрование пароля в AD, история паролей, поддержка Entra ID (Azure AD) для гибридных сред и ротация по требованию через PowerShell или Intune.
Включаем и настраиваем правильно:
Зачем это нужно:
Lateral movement через один скомпрометированный локальный пароль — классика пентестов и реальных атак. LAPS v2 с шифрованием и историей убирает этот вектор полностью. Пентестеры будут грустить, аудиторы — радоваться, а ты — спать спокойно.
Итог: Если у тебя больше 20 машин в домене и LAPS не настроен — это не техдолг, это открытая дверь. Закрой её сегодня, это займёт два часа.
#windows #laps #activedirectory #security #sysadmin #admin_future
Коллеги, я знаю, что где-то в вашей сети до сих пор живёт локальный Administrator с паролем из 2019 года, который записан в заметках у Богдана. И Богдан уже полгода как уволился.
Классический LAPS первого поколения умел ротировать пароль и класть его в AD — и это было неплохо. Но LAPS v2, встроенный в Windows Server 2025 и Windows 11, это уже другой уровень: шифрование пароля в AD, история паролей, поддержка Entra ID (Azure AD) для гибридных сред и ротация по требованию через PowerShell или Intune.
Включаем и настраиваем правильно:
# 1. Обновляем схему AD (один раз, на DC)
Update-LapsADSchema
# 2. Настраиваем права на OU с рабочими станциями
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"
# 3. Создаём GPO-политику через PowerShell (или через GUI GPMC)
# Путь в GPO: Computer -> Admin Templates -> LAPS
# Ключевые параметры:
# - Enable password backup to AD: Enabled
# - Password complexity: Large letters + small + digits + specials
# - Password age: 30 days
# - Enable encrypted password: Enabled <-- вот это обязательно в v2
# 4. Смотрим пароль для конкретной машины (только авторизованным)
Get-LapsADPassword -Identity "PC-FINANCE-01" -AsPlainText
# 5. Принудительная ротация после инцидента
Invoke-LapsPolicyProcessing # на машине
# или удалённо:
Reset-LapsPassword -Identity "PC-FINANCE-01"
Зачем это нужно:
Lateral movement через один скомпрометированный локальный пароль — классика пентестов и реальных атак. LAPS v2 с шифрованием и историей убирает этот вектор полностью. Пентестеры будут грустить, аудиторы — радоваться, а ты — спать спокойно.
Итог: Если у тебя больше 20 машин в домене и LAPS не настроен — это не техдолг, это открытая дверь. Закрой её сегодня, это займёт два часа.
#windows #laps #activedirectory #security #sysadmin #admin_future
👍1
🌐 Networking: WireGuard + wg-quick — это хорошо. WireGuard + netbird — это продакшн
Коллеги, WireGuard как замена OpenVPN уже давно не новость. Но я вижу, как большинство коллег до сих пор управляют им через wg-quick и ручное редактирование конфигов на каждом узле. Добавить новый хост — значит зайти на каждый пир, добавить PublicKey и AllowedIPs руками. В сети на 15 узлов это уже ад.
В 2026 году для mesh VPN на базе WireGuard есть нормальный инструментарий. Один из лучших — Netbird (self-hosted, open source, с management plane и ACL через UI или API).
Поднимаем self-hosted Netbird за 10 минут:
После этого все узлы видят друг друга через зашифрованный mesh, ACL настраиваются в веб-интерфейсе, новый хост добавляется за 30 секунд по setup key. Никаких правок конфигов на каждом пире.
Зачем это нужно:
Когда Богдан в 9 утра просит "срочно добавить новый сервер в VPN", ты генерируешь setup key в UI и скидываешь ему одну команду. Всё. Не надо помнить, какие PublicKey у каких нод, и не надо объяснять ему структуру wg-quick конфигов.
Итог: wg-quick — для домашней лаборатории и понимания основ. Для инфраструктуры от 5 узлов — нужен management plane. Иначе ты не строишь сеть, ты коллекционируешь конфиги.
#networking #wireguard #netbird #vpn #mesh #sysadmin #admin_future
Коллеги, WireGuard как замена OpenVPN уже давно не новость. Но я вижу, как большинство коллег до сих пор управляют им через wg-quick и ручное редактирование конфигов на каждом узле. Добавить новый хост — значит зайти на каждый пир, добавить PublicKey и AllowedIPs руками. В сети на 15 узлов это уже ад.
В 2026 году для mesh VPN на базе WireGuard есть нормальный инструментарий. Один из лучших — Netbird (self-hosted, open source, с management plane и ACL через UI или API).
Поднимаем self-hosted Netbird за 10 минут:
# На управляющем сервере (Ubuntu 24.04 LTS)
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/netbird_management_linux_amd64.tar.gz \
| tar -xz -C /usr/local/bin
# Используем официальный docker-compose (рекомендуемый путь)
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/docker-compose.yml
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/.env.example -O .env
# Правим .env: домен, TURN-сервер, OIDC-провайдер (или отключаем auth для лаборатории)
nano .env
docker compose up -d
# На каждом узле (Linux, Windows, macOS — клиент один и тот же)
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://your-netbird-domain:443 --setup-key YOUR_KEY
После этого все узлы видят друг друга через зашифрованный mesh, ACL настраиваются в веб-интерфейсе, новый хост добавляется за 30 секунд по setup key. Никаких правок конфигов на каждом пире.
Зачем это нужно:
Когда Богдан в 9 утра просит "срочно добавить новый сервер в VPN", ты генерируешь setup key в UI и скидываешь ему одну команду. Всё. Не надо помнить, какие PublicKey у каких нод, и не надо объяснять ему структуру wg-quick конфигов.
Итог: wg-quick — для домашней лаборатории и понимания основ. Для инфраструктуры от 5 узлов — нужен management plane. Иначе ты не строишь сеть, ты коллекционируешь конфиги.
#networking #wireguard #netbird #vpn #mesh #sysadmin #admin_future
🕵️♂️ Security: DPI переезжает в ваш смартфон. Как и зачем российские приложения ищут VPN
Коллеги, пока мы воевали с ТСПУ и маскировали трафик на серверах, регуляторы изящно сменили тактику. Цензура и DPI переезжают прямо на клиентские устройства.
К 15 апреля 2026 года Минцифры обязало российский бигтех (Яндекс, Сбер, VK, маркетплейсы) жестко ограничивать пользователей с включенным VPN. Не выполнишь — лишение IT-аккредитации. И маркетплейсы уже взяли под козырек: с 7 апреля Ozon и Wildberries начали резать загрузку каталогов при активном туннеле.
Как это выглядит под капотом (спойлер — это легализованное шпионское ПО):
Ребята из RKS Global декомпилировали 30 самых популярных ру-приложений для Android. Результаты аудита: 22 из 30 приложений целенаправленно ищут VPN, а 19 — молча отправляют этот статус на сервера (и далее товарищу майору).
Методы детекции, которые сейчас зашиты в ваш телефон:
— Чтение интерфейсов: Приложения (как мессенджер MAX) сканируют систему на наличие поднятых tun/ppp/tap адаптеров.
— Прямой запрос: Самокат и МегаМаркет через queryIntentServices("android.net.VpnService") тупо собирают список всех VPN-клиентов на устройстве.
— Скан соседей: Avito держит в манифесте блок queries на 200+ чужих пакетов. Он точно знает, стоят ли у вас клиенты конкурентов или запрещенные соцсети.
— Поведенческая биометрия: Банки (Т-Банк, Сбер, ВТБ) пишут каждое касание экрана (dispatchTouchEvent) с координатами и силой нажатия.
— Поиск инструментов: Яндекс Браузер целенаправленно ищет установленный Tor, а Яндекс Музыка сканирует систему на наличие Frida (инструмент динамического анализа), защищаясь от реверс-инжиниринга.
Как с этим жить инженеру?
Разделяй и властвуй. Идеальный сетап в 2026 году — это физически второй (старый) смартфон чисто под банки и маркетплейсы. Если телефон один, вас спасет только аппаратная виртуализация Android — Work Profile (через приложение Shelter).
Скрипт для параноиков. Проверяем через ADB, кто из приложений имеет системное право сканировать другие программы на вашем телефоне (тот самый QUERY_ALL_PACKAGES):
adb shell pm list packages --user 0 | sed 's/package://' | while read pkg; do adb shell dumpsys package $pkg | grep -q "android.permission.QUERY_ALL_PACKAGES" && echo "$pkg"; done
Зачем это нужно:
Чтобы понимать масштаб угрозы. Если приложение из этого списка вам не жизненно необходимо — сносите. Для оставшихся в живых: жестко отрезаем работу в фоне (Настройки — Батарея — Ограничено), отзываем доступ к контактам, логам звонков и локации.
Итог: Государство успешно делегировало цензуру частному бизнесу. Split tunneling больше не спасает — приложения видят поднятый tun0 на уровне системы. Поднимайте VPN-туннели аппаратно на домашних роутерах (MikroTik/Keenetic), чтобы телефон получал уже «чистый» Wi-Fi без локальных VPN-клиентов.
#security #vpn #android #privacy #sysadmin #admin_future
Коллеги, пока мы воевали с ТСПУ и маскировали трафик на серверах, регуляторы изящно сменили тактику. Цензура и DPI переезжают прямо на клиентские устройства.
К 15 апреля 2026 года Минцифры обязало российский бигтех (Яндекс, Сбер, VK, маркетплейсы) жестко ограничивать пользователей с включенным VPN. Не выполнишь — лишение IT-аккредитации. И маркетплейсы уже взяли под козырек: с 7 апреля Ozon и Wildberries начали резать загрузку каталогов при активном туннеле.
Как это выглядит под капотом (спойлер — это легализованное шпионское ПО):
Ребята из RKS Global декомпилировали 30 самых популярных ру-приложений для Android. Результаты аудита: 22 из 30 приложений целенаправленно ищут VPN, а 19 — молча отправляют этот статус на сервера (и далее товарищу майору).
Методы детекции, которые сейчас зашиты в ваш телефон:
— Чтение интерфейсов: Приложения (как мессенджер MAX) сканируют систему на наличие поднятых tun/ppp/tap адаптеров.
— Прямой запрос: Самокат и МегаМаркет через queryIntentServices("android.net.VpnService") тупо собирают список всех VPN-клиентов на устройстве.
— Скан соседей: Avito держит в манифесте блок queries на 200+ чужих пакетов. Он точно знает, стоят ли у вас клиенты конкурентов или запрещенные соцсети.
— Поведенческая биометрия: Банки (Т-Банк, Сбер, ВТБ) пишут каждое касание экрана (dispatchTouchEvent) с координатами и силой нажатия.
— Поиск инструментов: Яндекс Браузер целенаправленно ищет установленный Tor, а Яндекс Музыка сканирует систему на наличие Frida (инструмент динамического анализа), защищаясь от реверс-инжиниринга.
Как с этим жить инженеру?
Разделяй и властвуй. Идеальный сетап в 2026 году — это физически второй (старый) смартфон чисто под банки и маркетплейсы. Если телефон один, вас спасет только аппаратная виртуализация Android — Work Profile (через приложение Shelter).
Скрипт для параноиков. Проверяем через ADB, кто из приложений имеет системное право сканировать другие программы на вашем телефоне (тот самый QUERY_ALL_PACKAGES):
adb shell pm list packages --user 0 | sed 's/package://' | while read pkg; do adb shell dumpsys package $pkg | grep -q "android.permission.QUERY_ALL_PACKAGES" && echo "$pkg"; done
Зачем это нужно:
Чтобы понимать масштаб угрозы. Если приложение из этого списка вам не жизненно необходимо — сносите. Для оставшихся в живых: жестко отрезаем работу в фоне (Настройки — Батарея — Ограничено), отзываем доступ к контактам, логам звонков и локации.
Итог: Государство успешно делегировало цензуру частному бизнесу. Split tunneling больше не спасает — приложения видят поднятый tun0 на уровне системы. Поднимайте VPN-туннели аппаратно на домашних роутерах (MikroTik/Keenetic), чтобы телефон получал уже «чистый» Wi-Fi без локальных VPN-клиентов.
#security #vpn #android #privacy #sysadmin #admin_future
🐧 Linux: Bcachefs выгнали из ядра — и это хорошая новость для тех, кто понимает
Коллеги, если вы следите за файловой системой bcachefs — в сентябре 2025 года Линус Торвальдс окончательно выкинул весь код bcachefs из ядра, начиная с версии 6.18, за нарушения правил разработки. Теперь это внешний DKMS-модуль. Половина команды сразу решила: "раз выпилили — значит мёртвая". Не спешите.
Март 2026-й: вышел bcachefs 1.37 с поддержкой грядущего ядра Linux 7.0, и главное — erasure coding (аналог RAID с коррекцией ошибок) официально получил статус стабильного, сброшен experimental-тег. Это годами ждали. Помимо этого: автоматическое восстановление после некорректного завершения работы и поддержка устройств с битым flush/fua.
Что это означает на практике — собираем пул с erasure coding:
Зачем это нужно:
ZFS на Linux — всё ещё лицензионный компромисс. Btrfs RAID5/6 в дистрессе ест данные — и сообщество в глубоком отрицании. Bcachefs с erasure coding — это первая GPL-нативная альтернатива, которая делает это правильно. Для хранилища на Proxmox или bare-metal — смотреть обязательно.
Итог: Выгнали из ядра не потому что плохой, а потому что автор играл по своим правилам. Код при этом работает. В нашей профессии важно разделять политику и технологию.
#linux #bcachefs #filesystem #storage #sysadmin #admin_future
Коллеги, если вы следите за файловой системой bcachefs — в сентябре 2025 года Линус Торвальдс окончательно выкинул весь код bcachefs из ядра, начиная с версии 6.18, за нарушения правил разработки. Теперь это внешний DKMS-модуль. Половина команды сразу решила: "раз выпилили — значит мёртвая". Не спешите.
Март 2026-й: вышел bcachefs 1.37 с поддержкой грядущего ядра Linux 7.0, и главное — erasure coding (аналог RAID с коррекцией ошибок) официально получил статус стабильного, сброшен experimental-тег. Это годами ждали. Помимо этого: автоматическое восстановление после некорректного завершения работы и поддержка устройств с битым flush/fua.
Что это означает на практике — собираем пул с erasure coding:
# Устанавливаем DKMS-модуль (Ubuntu 24.04 / Debian 13)
apt install bcachefs-tools bcachefs-dkms linux-headers-$(uname -r)
# Форматируем пул из 4 дисков с erasure coding (аналог RAID 5)
# 3 диска данных + 1 диск паритета
bcachefs format \
--label=storage \
--erasure_code \
--replicas=1 \
/dev/sdb /dev/sdc /dev/sdd /dev/sde
# Монтируем (UUID рекомендуется для надёжности)
mount -t bcachefs /dev/sdb:/dev/sdc:/dev/sdd:/dev/sde /mnt/storage
# Проверяем статус пула
bcachefs fs usage /mnt/storage
# Смотрим здоровье устройств
bcachefs show-super /dev/sdb
Зачем это нужно:
ZFS на Linux — всё ещё лицензионный компромисс. Btrfs RAID5/6 в дистрессе ест данные — и сообщество в глубоком отрицании. Bcachefs с erasure coding — это первая GPL-нативная альтернатива, которая делает это правильно. Для хранилища на Proxmox или bare-metal — смотреть обязательно.
Итог: Выгнали из ядра не потому что плохой, а потому что автор играл по своим правилам. Код при этом работает. В нашей профессии важно разделять политику и технологию.
#linux #bcachefs #filesystem #storage #sysadmin #admin_future
🪟 Windows: SMB через порт 445 в 2026 году — это как ходить в интернет через telnet
Коллеги, признайтесь: у скольких из вас в DMZ или для удалённого офиса проброшен TCP 445 с каким-нибудь ACL "только для своих"? Я видел такое на аудите буквально в прошлом квартале, и это зрелище не для слабонервных.
Windows Server 2025 принёс кое-что важное для всех изданий, не только Azure Edition: SMB over QUIC — это SMB, инкапсулированный в QUIC-протокол и работающий через UDP 443 с TLS 1.3. Для удалённого пользователя это выглядит как обычная сетевая папка, но транспорт полностью зашифрован и firewall-friendly. Никакого VPN, никакого открытого 445-го.
Включаем через PowerShell (WAC для 2025 пока не поддерживает, только PS):
Зачем это нужно:
Всё SMB-соединение, включая аутентификацию и авторизацию, находится внутри TLS-туннеля и никогда не открыто на сетевом уровне.
Итог: TCP 445 — это наследие 1996 года. У вас есть Windows Server 2025 и три команды в PowerShell. Нет причин не закрыть этот вопрос сегодня.
#windows #smb #quic #security #windowsserver2025 #sysadmin #admin_future
Коллеги, признайтесь: у скольких из вас в DMZ или для удалённого офиса проброшен TCP 445 с каким-нибудь ACL "только для своих"? Я видел такое на аудите буквально в прошлом квартале, и это зрелище не для слабонервных.
Windows Server 2025 принёс кое-что важное для всех изданий, не только Azure Edition: SMB over QUIC — это SMB, инкапсулированный в QUIC-протокол и работающий через UDP 443 с TLS 1.3. Для удалённого пользователя это выглядит как обычная сетевая папка, но транспорт полностью зашифрован и firewall-friendly. Никакого VPN, никакого открытого 445-го.
Включаем через PowerShell (WAC для 2025 пока не поддерживает, только PS):
# 1. Убеждаемся что SMBv1 мёртв
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# 2. Включаем аудит — смотрим кто ещё не умеет шифрование
Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
# 3. Привязываем сертификат к SMB over QUIC
# (сертификат нужен с SAN = FQDN файл-сервера, можно Let's Encrypt)
$thumb = (Get-ChildItem Cert:\LocalMachine\My |
Where-Object {$_.Subject -like "*fileserver*"}).Thumbprint
Set-SmbServerCertificateMapping `
-Name "QuicCert" `
-Thumbprint $thumb `
-StoreName "My" `
-Force
# 4. Включаем QUIC-листенер на интерфейсе
New-SmbServerNetworkInterface `
-InterfaceAlias "Ethernet" `
-QuicListener $true
# 5. Проверяем — клиент должен видеть QUIC
Get-SmbConnection | Select ServerName, Dialect, TransportName
# TransportName = QUIC — победа
Зачем это нужно:
Всё SMB-соединение, включая аутентификацию и авторизацию, находится внутри TLS-туннеля и никогда не открыто на сетевом уровне.
Итог: TCP 445 — это наследие 1996 года. У вас есть Windows Server 2025 и три команды в PowerShell. Нет причин не закрыть этот вопрос сегодня.
#windows #smb #quic #security #windowsserver2025 #sysadmin #admin_future
👍1
🧠 Skills: Твоя инфраструктура работает. А ты — нет. О выгорании инженера
Коллеги, поговорим о том, о чём не принято говорить на конференциях между докладами про Kubernetes.
Выгорание — это не просто стресс. Это затяжное состояние полного умственного, физического и эмоционального истощения. И это, пожалуй, самая серьёзная и недооценённая проблема в профессии системного администратора.
Я видел это по-разному. Коллега, который держит на себе всю инфраструктуру потому что "он единственный кто понимает как это работает" — это Bus Factor = 1 и верный путь к выгоранию. Коллега, который берёт задачи из личного чата в 23:00 потому что неловко отказать — туда же. Знакомо?
Те, кто не выгорает, научились справляться со стрессом без саморазрушения, просить о помощи когда нужно, и поддерживать баланс между работой и жизнью за её пределами.
Практический алгоритм выхода из режима "я незаменим":
Зачем это нужно:
К 2026 году от администраторов ожидают больше uptime, больше безопасности и больше автоматизации — как правило, с той же командой и меньшим терпением. Чтобы работать в таких условиях годами, а не месяцами — нужно управлять собой с той же методичностью, с которой ты управляешь инфраструктурой.
Итог: Твои серверы мониторятся. Твой CPU-load отслеживается. А кто мониторит тебя? Настрой алерт. Себе.
#skills #burnout #sysadmin #teamwork #карьера #admin_future
Коллеги, поговорим о том, о чём не принято говорить на конференциях между докладами про Kubernetes.
Выгорание — это не просто стресс. Это затяжное состояние полного умственного, физического и эмоционального истощения. И это, пожалуй, самая серьёзная и недооценённая проблема в профессии системного администратора.
Я видел это по-разному. Коллега, который держит на себе всю инфраструктуру потому что "он единственный кто понимает как это работает" — это Bus Factor = 1 и верный путь к выгоранию. Коллега, который берёт задачи из личного чата в 23:00 потому что неловко отказать — туда же. Знакомо?
Те, кто не выгорает, научились справляться со стрессом без саморазрушения, просить о помощи когда нужно, и поддерживать баланс между работой и жизнью за её пределами.
Практический алгоритм выхода из режима "я незаменим":
Шаг 1 — ИНВЕНТАРИЗАЦИЯ НАГРУЗКИ
Фиксируй всё что делаешь 2 недели в любом трекере.
Цель: увидеть реальную картину, а не ощущение.
Шаг 2 — РАЗДЕЛЕНИЕ НА КАТЕГОРИИ
[A] Только я (требует моей экспертизы)
[B] Может делать обученный коллега
[C] Должно быть автоматизировано
[D] Не нужно делать вообще
Шаг 3 — ИЗБАВЛЕНИЕ ОТ КАТЕГОРИИ D
Гарантированно 20-30% задач там.
Просто перестать делать и посмотреть что случится.
Обычно — ничего.
Шаг 4 — АВТОМАТИЗАЦИЯ КАТЕГОРИИ C
Один скрипт, одна задача. Не "потом".
Сейчас. Это инвестиция, а не трата времени.
Шаг 5 — ДЕЛЕГИРОВАНИЕ КАТЕГОРИИ B
Задокументировать -> передать -> принять что будет сделано
не идеально, но достаточно хорошо.
Шаг 6 — ЖЁСТКИЕ ГРАНИЦЫ
Рабочий чат отключается в 19:00.
Это не грубость. Это профессиональная гигиена.
Зачем это нужно:
К 2026 году от администраторов ожидают больше uptime, больше безопасности и больше автоматизации — как правило, с той же командой и меньшим терпением. Чтобы работать в таких условиях годами, а не месяцами — нужно управлять собой с той же методичностью, с которой ты управляешь инфраструктурой.
Итог: Твои серверы мониторятся. Твой CPU-load отслеживается. А кто мониторит тебя? Настрой алерт. Себе.
#skills #burnout #sysadmin #teamwork #карьера #admin_future
❤5👍1
🐧 Linux: Ядро 7.0 вышло — и вот что из этого реально важно для продакшна
Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.
Три изменения, за которыми стоит следить:
Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.
Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.
Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.
Как проверить, что вы не сломаетесь при переходе:
Зачем это нужно:
Linux 7.0 станет ядром по умолчанию в Ubuntu 26.04 LTS и Fedora 44 — а это означает, что большинство корпоративных образов виртуальных машин через квартал-два будут именно на нём. Лучше понять изменения сейчас в лабе, чем разбираться с ними в продакшне.
Итог: XFS-самовосстановление и постквантовые подписи модулей — не хайп. Это инфраструктурные изменения, которые через год будут в каждом энтерпрайз-образе. Читайте changelog, а не только твиттер.
#linux #kernel #xfs #security #sysadmin #admin_future
Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.
Три изменения, за которыми стоит следить:
Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.
Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.
Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.
Как проверить, что вы не сломаетесь при переходе:
# Смотрим текущую версию и параметры компиляции
uname -r
cat /boot/config-$(uname -r) | grep -E "CONFIG_MODULE_SIG|CONFIG_RUST"
# Проверяем подписи установленных DKMS-модулей
dkms status
# Все модули должны пересобраться под новое ядро автоматически
# Для XFS — проверяем здоровье до обновления (на всякий случай)
xfs_info /dev/sda1
dmesg | grep -i xfs | grep -iE "error|corrupt|repair"
# После перехода на 7.0 — смотрим, что новый самохил XFS активен
dmesg | grep -i "xfs.*repair\|xfs.*heal"
# Ubuntu 26.04 LTS получит 7.0 из коробки (выход 23 апреля)
# На текущих системах — через mainline PPA для тестирования:
sudo add-apt-repository ppa:kernel-ppa/mainline
sudo apt update && apt list --upgradable | grep linux-image
Зачем это нужно:
Linux 7.0 станет ядром по умолчанию в Ubuntu 26.04 LTS и Fedora 44 — а это означает, что большинство корпоративных образов виртуальных машин через квартал-два будут именно на нём. Лучше понять изменения сейчас в лабе, чем разбираться с ними в продакшне.
Итог: XFS-самовосстановление и постквантовые подписи модулей — не хайп. Это инфраструктурные изменения, которые через год будут в каждом энтерпрайз-образе. Читайте changelog, а не только твиттер.
#linux #kernel #xfs #security #sysadmin #admin_future
👍1
🪟 Windows: dMSA в Server 2025 — Microsoft дала нам инструмент и сразу два способа им порезаться
Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.
Звучит хорошо. Но есть нюанс.
Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.
Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:
Зачем это нужно:
По данным Akamai, в 91% исследованных сред нашлись пользователи за пределами группы Domain Admins, у которых были права для проведения этой атаки. Если у вас Server 2025 DC в домене — проверьте, кто может создавать dMSA объекты, прямо сегодня. Это займёт 10 минут.
Итог: Microsoft сделала dMSA для защиты от Kerberoasting — и это правильно. Но разворачивать новую фичу в продакшн без аудита прав — всё равно что поставить бронедверь и забыть закрыть окно. Следите за патчем.
#windows #activedirectory #security #dmsa #kerberos #sysadmin #admin_future
Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.
Звучит хорошо. Но есть нюанс.
Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.
Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:
# Akamai выпустили скрипт для аудита — запускаем и смотрим кто может создавать dMSA
# Скачиваем с их GitHub:
# https://github.com/akamai/BadSuccessor
# Ручная проверка — кто имеет право создавать объекты типа msDS-DelegatedServiceAccount в OU
Import-Module ActiveDirectory
$OUs = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor
foreach ($OU in $OUs) {
$acl = Get-Acl "AD:$($OU.DistinguishedName)"
$acl.Access | Where-Object {
$_.ActiveDirectoryRights -match "CreateChild" -and
$_.ObjectType -eq [guid]"ce206244-5827-4a86-ba1c-1c0c386c1b64"
# ObjectType для msDS-DelegatedServiceAccount
} | Select-Object IdentityReference, ActiveDirectoryRights |
ForEach-Object {
[PSCustomObject]@{
OU = $OU.Name
Identity = $_.IdentityReference
Rights = $_.ActiveDirectoryRights
}
}
} | Format-Table -AutoSize | Export-Csv "dMSA_create_rights_audit.csv" -NoTypeInformation
# Включаем аудит событий dMSA — чтобы хотя бы видеть атаку
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
# Мониторим Event ID 5136 — изменения атрибута msDS-DelegatedMSAState
# и Event ID 4662 — изменения msDS-ManagedAccountPrecededByLink
# Эти два события вместе = сигнал возможной BadSuccessor-атаки
Get-WinEvent -LogName "Security" -FilterXPath `
"*[System[EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-DelegatedMSAState']]" |
Select TimeCreated, Message | Format-List
Зачем это нужно:
По данным Akamai, в 91% исследованных сред нашлись пользователи за пределами группы Domain Admins, у которых были права для проведения этой атаки. Если у вас Server 2025 DC в домене — проверьте, кто может создавать dMSA объекты, прямо сегодня. Это займёт 10 минут.
Итог: Microsoft сделала dMSA для защиты от Kerberoasting — и это правильно. Но разворачивать новую фичу в продакшн без аудита прав — всё равно что поставить бронедверь и забыть закрыть окно. Следите за патчем.
#windows #activedirectory #security #dmsa #kerberos #sysadmin #admin_future
🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.
Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.
#skills #documentation #runbook #sysadmin #teamwork #admin_future
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---
## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"
## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
$ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica
## Шаг 2 — Проверка репликации
$ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.
## Шаг 3 — Failover (только если мастер недоступен)
$ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.
## Шаг 4 — Проверка после failover
$ patronictl -c /etc/patroni/config.yml list
$ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)
## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)
## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni
Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.
Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.
#skills #documentation #runbook #sysadmin #teamwork #admin_future
🎓 Собеседование сисадмина. Выпуск #12: Kubernetes — то, что спрашивают в 2026 году
Коллеги! Продолжаем марафон. После выпуска про распределённые хранилища (Ceph, Longhorn) логичный следующий шаг — оркестрация. В 2026-м Kubernetes перестал быть "DevOps-штучкой" и стал стандартной частью инфраструктуры даже в небольших компаниях. А значит, сисадмин, который не понимает K8s, — это уже не сисадмин, это билет на понижение.
Три вопроса, на которых плывут даже те, кто "работает с кубером каждый день".
---
❓ Вопрос 1: «Pod завис в статусе CrashLoopBackOff. Ваши действия?»
❌ Ответ новичка: «Удалю pod и пересоздам, он же сам поднимется».
✅ Ответ инженера:
CrashLoopBackOff означает, что контейнер запускается, падает, Kubernetes пытается его поднять снова — и так по кругу. Задача: найти причину, а не перезапускать вслепую.
Алгоритм траблшутинга:
Ключевая мысль: Удалить и пересоздать pod — это лечить симптом, не болезнь. Kubernetes и сам это делает. Ваша работа — понять, почему падает.
---
❓ Вопрос 2: «В чём разница между Liveness Probe и Readiness Probe? Что будет, если их перепутать?»
❌ Ответ новичка: «Оба проверяют здоровье контейнера. Liveness — жив ли, Readiness — готов ли».
✅ Ответ инженера:
Определение правильное, но поверхностное. Интервьюер ждёт понимания последствий.
Liveness Probe — отвечает на вопрос "не завис ли процесс?". Если проверка провалилась — Kubernetes убивает контейнер и перезапускает его. Используется, чтобы выйти из дедлоков и зависаний.
Readiness Probe — отвечает на вопрос "можно ли слать трафик?". Если проверка провалилась — pod убирается из балансировки Service, но не перезапускается. Используется при старте, когда приложение ещё прогревается (warm-up, загрузка кэша).
Что будет если перепутать:
Pro-tip для собеса: Добавьте, что в 2026 году есть ещё Startup Probe — третий вид. Он запускается только при старте контейнера и блокирует Liveness/Readiness до тех пор, пока приложение не стартует успешно. Идеален для тяжёлых Java- и .NET-приложений с долгой инициализацией.
---
❓ Вопрос 3: «Kubernetes Secrets хранят пароли. Насколько они безопасны "из коробки"?»
❌ Ответ новичка: «Secrets зашифрованы, поэтому безопасны».
✅ Ответ инженера:
Это самая распространённая ошибка на собесах. Secrets "из коробки" — это НЕ шифрование.
Коллеги! Продолжаем марафон. После выпуска про распределённые хранилища (Ceph, Longhorn) логичный следующий шаг — оркестрация. В 2026-м Kubernetes перестал быть "DevOps-штучкой" и стал стандартной частью инфраструктуры даже в небольших компаниях. А значит, сисадмин, который не понимает K8s, — это уже не сисадмин, это билет на понижение.
Три вопроса, на которых плывут даже те, кто "работает с кубером каждый день".
---
❓ Вопрос 1: «Pod завис в статусе CrashLoopBackOff. Ваши действия?»
❌ Ответ новичка: «Удалю pod и пересоздам, он же сам поднимется».
✅ Ответ инженера:
CrashLoopBackOff означает, что контейнер запускается, падает, Kubernetes пытается его поднять снова — и так по кругу. Задача: найти причину, а не перезапускать вслепую.
Алгоритм траблшутинга:
# Шаг 1 — Смотрим текущие логи
kubectl logs <pod-name> -n <namespace>
# Если контейнер упал слишком быстро — логи уже улетели.
# Берём логи предыдущего запуска:
kubectl logs <pod-name> -n <namespace> --previous
# Шаг 2 — Описание pod: ищем Reason в Last State
kubectl describe pod <pod-name> -n <namespace>
# Смотрим секцию "Last State" и "Events"
# Причины бывают разные:
# OOMKilled -> контейнер убит за превышение лимита памяти
# Error (exit 1) -> приложение упало само (ошибка конфига/зависимость)
# RunContainerError -> не может стартовать (нет образа, нет прав на том)
# Шаг 3 — Если OOMKilled: смотрим лимиты и правим манифест
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'
# Временно поднимаем memory limit, чтобы убедиться в диагнозе:
# resources.limits.memory: 512Mi -> 1Gi
# Шаг 4 — Проверяем ConfigMap и Secret: существуют ли они в этом namespace?
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>
# Если приложение не может найти конфиг — оно упадёт с exit code 1
Ключевая мысль: Удалить и пересоздать pod — это лечить симптом, не болезнь. Kubernetes и сам это делает. Ваша работа — понять, почему падает.
---
❓ Вопрос 2: «В чём разница между Liveness Probe и Readiness Probe? Что будет, если их перепутать?»
❌ Ответ новичка: «Оба проверяют здоровье контейнера. Liveness — жив ли, Readiness — готов ли».
✅ Ответ инженера:
Определение правильное, но поверхностное. Интервьюер ждёт понимания последствий.
Liveness Probe — отвечает на вопрос "не завис ли процесс?". Если проверка провалилась — Kubernetes убивает контейнер и перезапускает его. Используется, чтобы выйти из дедлоков и зависаний.
Readiness Probe — отвечает на вопрос "можно ли слать трафик?". Если проверка провалилась — pod убирается из балансировки Service, но не перезапускается. Используется при старте, когда приложение ещё прогревается (warm-up, загрузка кэша).
Что будет если перепутать:
# ПЛОХОЙ пример: Liveness смотрит на /ready (страница прогрева)
# При старте приложению нужно 30 секунд на инициализацию БД.
# Liveness видит 503 -> убивает контейнер -> перезапускает -> снова 503
# -> бесконечный CrashLoopBackOff на старте.
# ПРАВИЛЬНАЯ конфигурация:
livenessProbe:
httpGet:
path: /healthz # Легкая проверка: "процесс жив?"
port: 8080
initialDelaySeconds: 10
periodSeconds: 15
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready # Тяжелая проверка: "готов принимать трафик?"
port: 8080
initialDelaySeconds: 20 # Даём время на прогрев
periodSeconds: 5
failureThreshold: 2
Pro-tip для собеса: Добавьте, что в 2026 году есть ещё Startup Probe — третий вид. Он запускается только при старте контейнера и блокирует Liveness/Readiness до тех пор, пока приложение не стартует успешно. Идеален для тяжёлых Java- и .NET-приложений с долгой инициализацией.
---
❓ Вопрос 3: «Kubernetes Secrets хранят пароли. Насколько они безопасны "из коробки"?»
❌ Ответ новичка: «Secrets зашифрованы, поэтому безопасны».
✅ Ответ инженера:
Это самая распространённая ошибка на собесах. Secrets "из коробки" — это НЕ шифрование.