🎓 Собеседование сисадмина. Выпуск №4: Виртуализация и Хранение данных

Привет, коллеги! Сегодня разберем три вопроса, на которых часто «плывут» даже опытные админы, привыкшие работать по инструкции, а не по логике.

❓ Вопрос 1: «Почему опасно держать снапшот (Snapshot) виртуальной машины дольше пары дней?»
❌ Ответ новичка: «Снапшот занимает много места на диске, и можно просто забыть, что он есть».
✅ Ответ инженера:

1. Производительность: Снапшот — это не копия ВМ, а дельта-файл. При наличии снапшота все новые записи идут в этот файл, а при чтении системе приходится проверять и основной диск, и все файлы цепочки снапшотов. Это создает огромную нагрузку на I/O.
2. Риск повреждения: Чем длиннее «цепочка» снапшотов, тем выше шанс, что при консолидации (удалении снапшота) произойдет ошибка, которая «убьет» файловую систему виртуалки.
3. Место: Снапшот растет непредсказуемо. Если внутри ВМ идет активная запись (например, обновление базы), снапшот может мгновенно забить всё свободное место на хранилище (LUN/Datastore), что приведет к остановке всех машин на этой полке.

❓ Вопрос 2: «В чем разница между Thin (Тонкими) и Thick (Толстыми) дисками? Что вы выберете для высоконагруженной БД?»
❌ Ответ новичка: «Тонкие диски экономят место, а толстые — нет. Для базы выберу толстые, потому что они надежнее».
✅ Ответ инженера:

Thin Provisioning: Место на физическом носителе выделяется только по мере записи данных. Плюс: экономия пространства. Минус: риск «Overprovisioning» (когда суммарный объем тонких дисков больше физического хранилища) и небольшая потеря производительности на операциях записи.
Thick Provisioning (Eager Zeroed): Весь объем резервируется и зануляется сразу. Плюс: максимальная производительность и отсутствие фрагментации на уровне гипервизора.
Выбор: Для высоконагруженной БД (SQL/Oracle/1С) — только Thick Provisioning Eager Zeroed. Это гарантирует отсутствие задержек при расширении файлов базы и исключает ситуацию, когда база падает из-за того, что на физической полке внезапно кончилось место.

❓ Вопрос 3: «Что такое Split-brain в кластере высокой доступности (HA) и как его предотвратить?»
❌ Ответ новичка: «Это когда два сервера работают одновременно. Предотвратить можно, настроив хороший мониторинг».
✅ Ответ инженера:

Split-brain — это состояние, когда узлы кластера теряют связь друг с другом (по сети Heartbeat), но при этом оба остаются живы. Каждый решает, что напарник «умер», и пытается одновременно захватить общие ресурсы (IP, диски). Это гарантированно ведет к повреждению данных.
Защита:
1. Quorum (Кворум): Использование нечетного количества узлов или «свидетеля» (Witness/Quorum Device). Ресурсы получает тот, кто видит большинство голосов.
2. STONITH / Fencing: Принцип «Пристрели другого в голову» (Shoot The Other Node In The Head). Если узел теряет связь, он через управляемую розетку (PDU) или IPMI физически выключает питание напарника, прежде чем забрать ресурсы.

💡 Золотое правило собеса: Помни, что Снапшот — это не бэкап. Это временная точка отката перед рискованной операцией. Если на вопрос «как вы делаете бэкапы» ты ответишь «делаю снапшоты раз в неделю» — собеседование для тебя закончится мгновенно.

Сохраняйте, коллеги! Это те знания, которые превращают «админа-кнопкотыка» в системного архитектора.

#собеседование_AF #virtualization #storage #snapshot #highavailability #proxmox #vmware #admin_future

🧠 Skills: Aurora шифрует ESXi. AI на разведке, но цель сдаёт обычный LDAP-запрос

Коллеги, разбор свежей тактики вымогателей, который напрямую касается каждого, кто держит виртуализацию — будь то VMware ESXi, vCenter или Proxmox.

📌 ФАКТЫ (по свежему отчёту Gambit Security)
Кампания Aurora Ransomware: две волны атак в 2026 году на бизнес в Европе, США и Израиле.

AI в роли Co-pilot злоумышленника: оператор использовал Cursor Agent (на базе Claude Sonnet) для автоматизации рутины — генерации конфигов proxychains/VPN, парсинга выдачи Nmap и NetExec, разведки Active Directory, NTLM relay и атак на AD CS.

Операционная дисциплина: атакующий осознанно выставил агенту жесткие рамки — никаких DCSync, без локаута аккаунтов, без регистрации новых машин в домене. Задача — нулевой шум в SIEM.

Как находили виртуализацию: самописный модуль NetExec (esxi_finder.py) вытягивал список хостов через стандартные LDAP-запросы, опрашивал порты 443 и 902, а затем по TLS-сертификату однозначно детектировал гипервизоры и vCenter.

Удар: Linux-бинарник шифровальщика с флагом -esxi тушит виртуальные машины через штатный esxcli и зашифровывает диски (ChaCha20 + RSA-4096).

💡 В ЧЁМ СУТЬ

ИИ здесь не взламывает квантовым алгоритмом — он просто снимает рутину и ускоряет рекогносцировку. Архитектурная дыра ровно та же, что и 5 лет назад: гипервизоры видны из пользовательского сегмента или привязаны к общему AD. Если порт виден наружу, его найдут и без нейросетей.

🛠 АУДИТ БЕЗОПАСНОСТИ
1. Проверяем хост ESXi (по SSH):

Bash

# Проверить, активен ли Lockdown Mode
vim-cmd -U dcui vimsvc/auth/lockdown_is_enabled

# Ограничение белых списков IP для SSH и веб-морды
esxcli network firewall ruleset allowedip list --ruleset-id sshServer
esxcli network firewall ruleset allowedip list --ruleset-id webAccess

# Блокировка запуска неподписанных бинарников (дропает чужой шифровальщик)
esxcli system settings encryption get

# Ревизия локальных учетных записей
esxcli system account list

2. Сканируем из пользовательского сегмента (быстрый smoke-тест):

Bash

nmap -Pn -p 443,902,8006 <подсеть_гипервизоров>
# Порты должны быть отфильтрованы в глухую! (8006 — для Proxmox VE)

🛡 БАЗОВЫЙ ЧЕКЛИСТ ЗАЩИТЫ ГИПЕРВИЗОРОВ
Изолированный Out-of-Band / Management VLAN: интерфейсы управления ESXi, vCenter и Proxmox VE не должны маршрутизироваться в клиентские подсети. Доступ — строго через выделенный Jump-хост с MFA.

Никакого прямого членства в Active Directory: гипервизорам не место в корпоративном домене. Если ESXi все еще там — срочно проверяйте группу ESX Admins и закрывайте дыру CVE-2024-37085.

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

Неизменяемые (Immutable) бэкапы: резервные копии должны лежать в изолированном пуле (WORM/S3 Object Lock/air-gapped), к которому нет и не может быть доступа с доменными учетками.

Гипервизор — самая дорогая и желанная точка отказа в инфраструктуре. Одна команда — и ложится всё предприятие разом. Проектируйте доступ к нему так, словно злоумышленник уже захватил доменную рабочую станцию.

#skills #esxi #vmware #proxmox #ransomware #virtualization #sysadmin #admin_future

🖥 Proxmox запускает поддержку 24/7 с 19 октября. Закрыт главный аргумент «против» в корпоративе

Коллеги, четверг. Новость для всех, кто ведёт проекты миграции с VMware vSphere и регулярно слышит от CTO или службы безопасности вопрос: «А кому мы будем звонить в 3 часа ночи, когда упадёт прод?».

📌 ФАКТЫ
Старт круглосуточного SLA: с 19 октября Proxmox Server Solutions официально запускает сервис поддержки 24/7 для всей линейки корпоративных продуктов: Proxmox Virtual Environment (PVE), Proxmox Backup Server (PBS) и Proxmox Datacenter Manager.

Конец австрийскому таймзону: ранее официальный вендорский саппорт работал строго в бизнес-часы по Вене (CET), а для ночных дежурств приходилось искать сторонних локальных интеграторов.

Тарифные уровни:

Premium Subscription: режим 24/7 доступен сразу с 19 октября. Безлимитное число тикетов, первичное время реакции — до 2 часов, прямая эскалация инженерам разработки ядра.

Standard Subscription: поддержка 24/7 появится чуть позже, в Q4 2026.

Basic Subscription: SLA остаётся в прежних рамках (рабочие часы).

Глобальная экспансия: учреждено американское подразделение Proxmox North America Inc., обеспечивающее перекрытие смен по модели follow-the-sun.

🛠 ПРОВЕРКА ГОТОВНОСТИ НОД К ОБРАЩЕНИЮ В TAC
При ночной аварии время идёт на минуты — данные для сервисной заявки должны собираться мгновенно:

Bash

# 1. Проверяем валидность лицензионного ключа и активный уровень подписки
pvesubscription get

# 2. Выгружаем точные версии установленных пакетов ядра и гипервизора
pveversion -v | head -5

# 3. Контролируем репозитории: enterprise-репозиторий должен быть активен без ошибок
ls -la /etc/apt/sources.list.d/

# 4. Снятие полного диагностического слепка ноды (базовый артефакт для любого тикета)
pvereport > /root/pvereport-$(hostname).txt

💡 В ЧЁМ СУТЬ

Наличие контракта 24/7 снимает формальный барьер у топ-менеджмента, но не отменяет законов физики: оно не заменяет локальный кворум Corosync, кластерный High Availability и отработанный план Disaster Recovery.

Дежурный инженер вендора в Вене или США в первую очередь запросит вывод

pvereport

и системные журналы. Снимите и сохраните эталонный отчет

pvereport

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

#proxmox #virtualization #support #vmware #enterprise #ha #sysadmin #admin_future

🙈 Уязвимость «низкой» критичности в ESXi использовали как zero-day. Её задача — чтобы логи ничего не видели

Коллеги, есть CVE, мимо которых обычно проходят со словами «Low, проблемы с логами, когда-нибудь потом». Китайская APT-группировка рассудила иначе.

📌 ФАКТЫ
CVE-2026-41709 — недостаточное логирование критических событий в гипервизоре VMware ESXi (баг позволял совершать привилегированные действия в обход стандартных журналов аудита)

Группировка Warp Panda (китайский кибершпионаж по классификации CrowdStrike) эксплуатировала этот дефект как zero-day в начале 2026 года для скрытного закрепления в инфраструктуре

Типовая цепочка атаки: пробив внешнего периметра → закрепление на сервере vCenter → деплой кастомных ESXi-бэкдоров (BRICKSTORM, SharpStorm) → кража облачных токенов сессий и регистрация своих MFA-устройств в корпоративном тенанте M365

Broadcom выпустила патч в июле 2026 года. 28 октября уязвимость официально внесена в каталог эксплуатируемых угроз CISA KEV со строгим дедлайном устранения для госсектора до 11 ноября

🛠 ВЫВОДИМ ЛОГИ ESXi НА ВНЕШНИЙ СЕРВЕР
Хранить аудит только локально в /var/log на самом хосте виртуализации — подарок злоумышленнику. Настраиваем отправку в SIEM/Syslog:

Bash

# 1. Проверяем текущую версию гипервизора и билд
vmware -vl

# 2. Смотрим текущий таргет syslog
esxcli system syslog config get

# 3. Направляем поток событий на удалённый коллектор/SIEM
esxcli system syslog config set --loghost='tcp://siem.local:514'
esxcli system syslog reload

# 4. Открываем системный порт для syslog во встроенном файрволе ESXi
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true

😅 ЖИЗНЕННОЕ
Атакующий на скомпрометированном хосте ESXi ведёт себя точь-в-точь как кот, стащивший со стола сосиску: первым делом заметает следы и прикрывает миску лапой. Если журналы не улетают на внешний сервер в момент записи, то при разборе инцидента в локальных логах останутся только «перезагрузка демона» и звенящая пустота.

💡 В ЧЁМ СУТЬ

Рейтинг Low по шкале CVSS отражает лишь сложность или изолированный импакт уязвимости, но не её ценность в реальной цепочке компрометации (Kill Chain). Для APT-группы баг, ослепляющий SOC и стирающий таймлайны, стоит десятка шумных эксплойтов.

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

#vmware #esxi #logging #siem #apt #юмор #sysadmin #admin_future