Repo01 в том же домене, что FS01: вынести backup из зоны поражения DA

Короткий ответ

Если учётка Domain Admins продакшена (или локальный админ рабочей станции с украденным DA) может войти на backup.contoso.example, VBR01 или смонтировать \\backup.contoso.example\Repo01 на запись, копии уже в зоне поражения. Изолируйте: отдельный identity store или как минимум отдельные учётки без DA; сеть репозитория не с клиентских VLAN; immutable/offsite, куда DA не дотягивается. Не «укрепить антивирусом шару» как единственную меру.

В инциденте сначала не чинить вслепую, потом restore из незатронутой копии.

Симптомы и как отличить

Типичная картина:

• на Repo01 файлы .vbk с чужим расширением или 1 KB;
• Veeam консоль открывается украденным DA, job Disabled, точки Deleted;
• PBS root с той же парольной политикой, что «Passw0rd»;
• WSB target — папка на том же FS, который шифруют.

Отличия:

Возможные причины

1. VBR01 и Repo01 — члены contoso.example, админят те же люди, что DC.
2. Share доступен из пользовательских сетей.
3. Одна учётка backup = DA.
4. Нет immutable, нет offsite.
5. RDP/VPN админов на backup-хост с тех же ПК, что почта.
6. PBS/PVE в том же домене и с теми же локальными паролями.
7. Backup copy «в облако» ключом, лежащим на том же VBR01.
8. Редкий: партнёрский доступ с Full к шаре.

Диагностика

1. Карта досягаемости

Таблица: кто (учётка, группа) может Read/Write/Delete на Repo01, админить VBR01, root PBS, IAM bucket. Если в таблице есть Domain Admins или персональные админы 1С — провал изоляции.

Get-SmbShareAccess -Name 'Repo01'
Get-LocalGroupMember -Group 'Administrators'

На VBR01 — Users and Roles Veeam + локальные админы Windows.

2. Сеть

С рабочей станции VLAN: открывается ли \\backup.contoso.example\Repo01? Если да — ransomware дойдёт без AD. Firewall должен резать SMB до backup-сети со всех, кроме VBR01/proxy.

3. Целостность копий

Предполагайте компрометацию online-репо. Verify offline копии. Не запускайте exe с Repo01.

4. Логи входа

Успешные входы на backup.contoso.example / VBR01 с необычных хостов до шифрования. Это не полная IR-методика, но решает, жива ли ещё учётка.

Решение

Сценарий A. Инцидент уже идёт

1. Изолировать прод и backup-сеть по IR-плану.
2. Не логиниться DA на backup.
3. Объявить, какие копии считать dirty (online SMB) vs clean (immutable expired-after-attack, tape, object lock).
4. Restore в чистое железо/гипервизор, не в заражённый LAN. См. изоляцию VM.
5. Пароли backup-учёток считать скомпрометированными.

Сценарий B. Срочная изоляция (ещё не шифровали backup)

• Снять Repo01 с клиентских VLAN (ACL на L3).
• Убрать DA из локальных админов backup-хостов.
• Запретить интерактивный вход персональным админам на VBR01.
• Включить/починить immutable.
• Завести отдельные учётки.

Сценарий C. Архитектура «недоступно DA»

Практичный минимум для SMB-магазина:

1. Linux hardened repo вне домена, VLAN только VBR01+proxy.
2. Backup copy в object lock / другой ЦОД.
3. VBR01 не раздаёт DA; консоль с jump-хоста backup-зоны.
4. PBS: отдельный realm или локальные пользователи, MFA на root.

Не нужен сразу новый лес всем. Нужен разрыв: украденный DA не равен root на repo.

Сценарий D. Ключи облака на VBR01

Вынести ключи в отдельный vault, IAM без delete lock. Компрометация VBR01 не должна давать DeleteObject на locked объекты.

WSB: target не на том же сервере, что данные, и не с Everyone. Лучше Veeam/PBS с изоляцией, WSB как доп. слой не спасает от DA.

Как проверить, что проблема устранена

Стол атаки (на стенде или чеклист):

• DA продакшена не входит на repo, не монтирует шару, не SSH root.
• С клиентского VLAN SMB 445 на repo = deny.
• Delete точки внутри immutable period = deny.
• Есть копия вне этой зоны (offsite/lock).

Документ подписан: «DA не админ backup».

Если не помогло

• После ACL шара всё ещё видна через старый VPN split — закройте маршруты и split-tunnel к backup.contoso.example, не только SMB-правило на одном коммутаторе.
• Veeam Enterprise Manager в интернете с DA — уберите публикацию; консоль только с jump в backup-VLAN.
• Immutable есть, ключ lock лежит в том же менеджере паролей, что DA — это один секрет: вынесите ключи репозитория в отдельный vault с другим ACL.
• PBS joined AD для «удобства» — разjoin или отдельный аккаунт без групп DA; иначе Kerberos-тикет админа 1С открывает prune.
• Реплика VM на второй хост в том же домене не замена изоляции: ransomware с DA остановит реплику и сотрёт оба диска. Смотрите точки Daily-VMs на носителе, куда DA не входит.

Проверка досягаемости с «чужой» учётки: создайте тестового пользователя только в Domain Admins (на стенде) и убедитесь, что SMB 445 к Repo01 и SSH на hardened отклоняются. Если стенда нет — разберите ACL и маршрут на бумаге с сетевиком, не откладывайте «пока не припрёт».

Не отключайте immutability «временно для удобства админов». Не давайте временный RDP на VBR01 с заражённого ПК «посмотреть job».

Профилактика

• Регулярный контроль: матрица доступов backup vs прод.
• Мониторинг новых членов Administrators на backup.contoso.example.
• Учения ransomware: дойти ли до копий за 30 минут от DA.
• 3-2-1 и offsite обязательны, изоляция не заменяет третью копию.

FAQ

Достаточно ли вывести VBR01 из домена?

Сильный шаг, но шара Repo01 на файловике в домене всё ещё убивается DA. Изолируйте данные копий, не только консоль.

Может ли LAPS на backup-хосте заменить изоляцию?

LAPS помогает от одинаковых локальных паролей, не от DA с сети.

Антивирус на репозитории?

Дополнительно, не вместо изоляции. On-access иногда портит backup; исключения документируйте.

Admin Forest / Red Forest?

Хорошо, если потянете. Для SME часто хватает hardened+object lock+сеть. Не откладывайте простые разрывы годами ради «правильного леса».

WSB на USB в сейфе?

Воздух есть, автоматического RPO нет. Как один слой — да, как единственный ночной backup — нет.

После атаки «просто восстановить VBR01 из backup»

Только если точка до компрометации и на чистом хосте. Иначе вернёте бэкдор вместе с консолью.