Реагування на рансомваре в ZFS: сценарій зі снапшотами, що рятує

Як виглядає рансомваре в ZFS (і чого не слід очікувати)

Рансомваре — це не однорідне явище. На рівні сховища воно зазвичай потрапляє в одну з цих категорій:

• Файлове шифрування: обходить дерево файлів і перезаписує файли (або створює зашифровані копії, після чого видаляє оригінали). На ZFS це переважно випадкові записи та інтенсивна метаданна активність.
• Поведінка «вивідника» (wiper): видалення, усікання, перезапис. Такий самий ефект: живий датасет стає сміттям.
• Атакувальник з украденими обліковими даними: найгірший випадок. Не потрібні складні шкідливі програми — вони заходять під вашою учеткою (або автоматизацією) і виконують руйнівні команди: видаляють снапшоти, руйнують датасети, зупиняють реплікацію.
• Компрометація гіпервізора/VM: шифрує всередині гостьової ОС. ZFS бачить великі записи в zvol або образах VM, а не окремі файли.
• Компрометація цілі бекапу: нападник б’є по системі, що зберігає «резервні копії», і шифрує їх теж. Якщо ваш ZFS — це ціль бекапу і до нього є запис з зараженого середовища, вітаю: ви зробили високопродуктивний self-own.

Sнапшоти ZFS найчастіше допомагають з першими двома сценаріями. Вони можуть допомогти при третьому, але тільки якщо видалення снапшотів обмежене, а реплікація має безпечну «проміжну» історію. Якщо атакувальники можуть видаляти снапшоти і їхні репліки, ваші снапшоти — лише заспокійлива історія, яку ви розповідаєте собі.

Коротка фраза, яку тримайте в голові, коли стає голосно: Надія — не стратегія. — перефразована ідея, яку часто приписують операційному керівництву. Сенс зрозумілий: надія не проходить аудитів і не відновлює дані.

Семантика снапшотів: чому це працює

Снапшоти ZFS — це знімки стану датасету у певний момент часу. Вони дешеві, бо ZFS використовує copy-on-write: нові записи виділяють нові блоки; існуючі блоки, на які посилається снапшот, залишаються на місці. Це основна перевага: рансомваре може перезаписувати живий датасет скільки завгодно; ваш снапшот все ще вказує на старі блоки.

Два застереження: снапшоти не магія й за замовчуванням не є незмінними. Якщо атакувальник (або неправильно налаштована автоматизація) може виконати zfs destroy pool/ds@snap, ваші «незмінні бекапи» перетворюються на «історичну цікавинку». Також: снапшоти зберігають корумпований, але консистентний стан. Якщо рансомваре чисто зашифрувало файли, снапшоти збережуть попередній стан, але лише якщо у вас є снапшот, створений до початку шифрування.

Рішення моделі загрози, що мають значення

• Припускайте компрометацію облікових даних, доки не доведено протилежне. Хост для відновлення не повинен довіряти зараженому хосту.
• Віддавайте перевагу «відновленню в інше місце» над відкатом на місці для критичних систем, коли це можливо. Це дає вам форензіку і знижує ризик повторної інфекції.
• Реплікація — це ваш «повітряний проміжок» тільки якщо вона не є безперервно записуваною та доступною для видалення з тієї самої контрольної площини.

Факти та історія, що змінюють підхід до реагування

Це не дрібниці. Це ті невеликі істини, від яких залежить, чи стане ваше відновлення тріумфом, чи матеріалом для розбору.

1. Снапшоти ZFS з’явилися давно і дивно залишаються недовикористаними. Sun представила ZFS у середині 2000-х з снапшотами як фічею першого класу, задовго до того, як «рансомваре» стало темою на рівні ради директорів.
2. Copy-on-write — і суперсила, і пастка продуктивності. Воно робить снапшоти дешевими, але тривалі випадкові перезаписи (привіт, рансомваре) можуть фрагментувати вільний простір і підвищити латентність.
3. Видалення снапшотів може бути дорогим. Руйнування великих старих снапшотів може спричинити інтенсивну роботу зі спейс-мапами і I/O — це важливо під час інциденту, коли ви прагнете швидко відновитися.
4. zfs send/receive — це машина часу для судової експертизи. Ви можете реплікувати інкрементний стан і реконструювати хронологію подій, а не лише відновлювати дані.
5. Оператори рансомваре перейшли до подвійног0 шантажу. Сучасні інциденти часто включають крадіжку даних плюс шифрування. Снапшоти вирішують шифрування; вони не відміняють ексфільтрацію.
6. Атакувальники навчилися цілитися в бекапи. Останнє десятиліття змушувало їх видаляти тіні, VSS, каталоги бекапів — і так, снапшоти ZFS, якщо до них можна дістатися.
7. Політики незмінності снапшотів існують, але це операційний вибір. На деяких платформах можна налаштувати утримання (holds), делеговані права або окремі адміністративні домени. Нічого з цього не відбувається автоматично; усе потребує дисципліни.
8. Шифрування може допомагати й заважати. Вбудоване шифрування ZFS захищає від крадіжки сирих дисків і може обмежити частину судової експертизи, але воно не зупинить рансомваре, що виконується від імені користувача з правами читання/запису.
9. Швидке відновлення потребує планування вільного простору. Найкращий снапшот світу марний, якщо ви не можете змонтувати, клонувати або отримати його, бо пул зайнятий на 95% і сердитий.

Жарт №1 (коротко, по темі): Рансомваре — єдина робота, що раптово змушує всіх цінувати «нудну» інженерію зберігання. Це як несподіваний аудит, тільки з більшою кількістю лаяну.

Перша година: локалізувати, зберегти, вирішити

У першу годину ви не «відновлюєте». Ви купуєте опції.

1) Локалізуйте радіус ураження

Якщо шифрування триває, кожна хвилина важлива. Перекрийте шлях запису. Це може означати:

• Відключити SMB/NFS експорти від мережі.
• Зупинити прикладні сервіси, що записують у уражені датасети.
• Відключити компрометовані облікові записи або відкликати токени.
• Карантинізувати хост на комутаторі або фаєрволі.

Локалізація важливіша за винахідливість. Якщо ви не можете зупинити запис, ви не можете довіряти хронології.

2) Зберігайте докази, не уповільнюючи відновлення до повільної смерті

Вам потрібні докази, щоб відповісти на питання «як вони зайшли?» і «наскільки поширилося?», але не варто перетворювати це на ярмарок судової науки. Практичний компроміс:

• Зробіть новий снапшот уражених датасетів негайно (так, навіть якщо дані пошкоджені). Ви фіксуєте поточний стан для подальшого аналізу.
• Експортуйте логи (auth logs, SMB logs, application logs) з хоста.
• Якщо є реплікація, призупиніть її й скопіюйте поточний стан реплікації для подальшого перегляду; не перезаписуйте добру історію.

3) Визначте режим відновлення

Є три основні варіанти:

• Відкат на місці: швидко, ризиковано. Підходить для простих файлових шарів, якщо ви впевнені, що хост чистий і знаєте правильний снапшот.
• Клонувати снапшот і обслуговувати клон: безпечніше. Можете змонтувати клон спочатку лише для читання, перевірити, а потім переключити.
• Відновити на чисту систему в іншому місці: найбезпечніший варіант. Потребує більше часу й ємності, але знижує ризик реінфекції і зберігає компрометовану систему для розслідування.

Моє упередження: для всього, що виконує код (CI-сервери, аплікації з writable volumes, VM datastore), відновлюйте в інше місце. Для простих файлових шарів з нормальною ідентифікацією користувачів клон — золота середина.

Швидка діагностика (тріаж за вузьким місцем)

Це «що перевірити першим, другим, третім», коли всі дивляться на вас і треба припинити гадати.

Перше: чи атакувальник ще пише?

• Перевірте наявність стійких записів I/O та змін файлів в уражених датасетах.
• Підтвердьте, чи клієнти SMB/NFS ще підключені й активно змінюють дані.
• Рішення: якщо записи тривають, ізолюйте або зупиніть сервіси перед подальшими діями.

Друге: чи є у вас чисті снапшоти?

• Перерахуйте недавні снапшоти й перевірте, чи є хронологія, що охоплює період до підозрюваного шифрування.
• Перевірте, чи не видаляли снапшоти недавно (неочікувані прогалини).
• Рішення: якщо історія снапшотів відсутня, негайно перемикайтеся на реплікацію/офсайт чи альтернативні бекапи; не витрачайте час на планування відкату, який неможливий.

Третє: яке вузьке місце відновлення — CPU, диск, мережа чи місце?

• Місце: використання пулу та фрагментація; якщо майже повно, клон/receive може не встати.
• Диск: висока латентність, resilvering або помилки; відновлення на помираючому пулі — повільна трагедія.
• Мережа: реплікація чи відновлення через канали; вимірюйте пропускну здатність і втрати пакетів.
• CPU: шифрування/сжаття може обмежувати send/receive; перевірте, чи не обмежує процесор.
• Рішення: обирайте відкат vs клон vs відновлення-у-інше місце виходячи з обмежень. Якщо мало місця, відкат може бути єдиним варіантом; якщо хост під сумнівом, відновлюйте в інше місце, навіть якщо повільніше.

Четверте: перевірте чистоту, не реінфікуючи

• Монтуйте кандидати на відновлення (снапшоти/клони) спочатку лише для читання.
• Скануйте на відомі шаблони ransom note, нові розширення та нещодавно змінені виконувані файли/скрипти в загальних шляхах.
• Рішення: обирайте точку відновлення, де бізнес-дані цілі, а шкідливі артефакти відсутні (або принаймні зрозумілі).

Практичні завдання: команди, виводи, рішення (12+)

Це команди, які ви реально виконуєте, з реалістичними виводами та подальшими діями. Імена хостів і пулів — приклади; тримайте свої власні консистентні. Інцидент припускає участь пулу tank з датасетами tank/share та tank/vm.

Завдання 1: підтвердити стан пулу (не відновлюйте на тлі пожежі)

cr0x@server:~$ zpool status -x
all pools are healthy

Що це означає: Немає відомих помилок пристроїв або виконання resilver.

Рішення: Продовжуйте. Якщо бачите DEGRADED, FAULTED або resilvering, плануйте повільніше відновлення або відновлення на іншому обладнанні.

Завдання 2: перевірити ємність пулу та ризик фрагментації

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,cap,health
NAME  SIZE  ALLOC   FREE  FRAG  CAP  HEALTH
tank  54.5T  41.8T  12.7T   41%  76%  ONLINE

Що це означає: 76% заповнено, помірна фрагментація. Не чудово, але не фатально.

Рішення: Клони і receive мають працювати. Якщо CAP > 90%, очікуйте збоїв і першочергово робіть відкат або додавайте ємність.

Завдання 3: визначити, які датасети потерпають найбільше

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME        USED   AVAIL  REFER  MOUNTPOINT
tank        41.8T  11.9T   128K  /tank
tank/share   8.4T  11.9T   8.4T  /srv/share
tank/vm     31.2T  11.9T  31.2T  /srv/vm

Що це означає: tank/vm — дуже великий; якщо VM уражені, відновлення затягнеться переважно через нього.

Рішення: Розділіть інцидент: файлові шари можуть відновлюватися швидко; datastore VM потребуватиме окремого підходу (відновлення підмножини, пріоритизація критичних VM).

Завдання 4: спостерігати реальний I/O, щоб підтвердити активне шифрування

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        41.8T  12.7T    410   8120   32.1M  1.02G
  raidz2-0                  41.8T  12.7T    410   8120   32.1M  1.02G
    sda                         -      -     52   1015   4.0M  128M
    sdb                         -      -     51   1010   4.1M  127M
    sdc                         -      -     51   1012   4.0M  128M
    sdd                         -      -     51   1012   4.0M  128M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Інтенсивні стійкі записи. Якщо це не вікно звичної робочого навантаження, припускайте активне шифрування або масовий перезапис.

Рішення: Локалізуйте: вимкніть експорти, зупиніть сервіси, карантинізуйте хост. Не починайте відкат, поки записи тривають.

Завдання 5: перерахувати снапшоти і помітити прогалини

cr0x@server:~$ zfs list -t snapshot -o name,creation,used -s creation | tail -n 8
tank/share@auto-2025-12-26-0700  Fri Dec 26 07:00 2025   56M
tank/share@auto-2025-12-26-0800  Fri Dec 26 08:00 2025   60M
tank/share@auto-2025-12-26-0900  Fri Dec 26 09:00 2025   58M
tank/share@auto-2025-12-26-1000  Fri Dec 26 10:00 2025   62M
tank/share@auto-2025-12-26-1100  Fri Dec 26 11:00 2025   59M
tank/share@auto-2025-12-26-1200  Fri Dec 26 12:00 2025   61M
tank/share@auto-2025-12-26-1300  Fri Dec 26 13:00 2025   63M
tank/share@auto-2025-12-26-1400  Fri Dec 26 14:00 2025   65M

Що це означає: Регулярні годинні снапшоти є до 14:00. Добрий знак.

Рішення: Визначте, коли почалося шифрування; оберіть снапшот безпосередньо перед ним. Якщо є прогалина (відсутні години/дні), підозрюйте видалення снапшотів або збої автоматизації — переключайтесь на реплікацію/офсайт.

Завдання 6: зробіть «снапшот місця злочину» прямо зараз

cr0x@server:~$ zfs snapshot -r tank/share@incident-2025-12-26T1425Z
cr0x@server:~$ zfs list -t snapshot -o name,creation | grep incident | tail -n 2
tank/share@incident-2025-12-26T1425Z  Fri Dec 26 14:25 2025

Що це означає: Ви зафіксували поточний стан для подальшого аналізу.

Рішення: Збережіть його. Не видаляйте «погані» снапшоти під час реагування; вони знадобляться безпеці/юристам.

Завдання 7: перевірити утримання снапшотів (і додати, коли потрібно зберегти)

cr0x@server:~$ zfs holds tank/share@auto-2025-12-26-1200
NAME                          TAG   TIMESTAMP
tank/share@auto-2025-12-26-1200  -     -
cr0x@server:~$ zfs hold keep tank/share@auto-2025-12-26-1200
cr0x@server:~$ zfs holds tank/share@auto-2025-12-26-1200
NAME                          TAG   TIMESTAMP
tank/share@auto-2025-12-26-1200  keep  Fri Dec 26 14:28 2025

Що це означає: Hold запобігає випадковому видаленню цього снапшоту до явного зняття утримання.

Рішення: Поставте holds на кандидати «останньо відомо чисті» снапшоти перед маніпуляціями.

Завдання 8: підтвердити, що змінилося останнім часом (високосигнальний тріаж)

cr0x@server:~$ zfs diff -H tank/share@auto-2025-12-26-1200 tank/share@auto-2025-12-26-1400 | head
M	/srv/share/finance/Q4.xlsx
M	/srv/share/finance/Q4.xlsx.locked
+	/srv/share/READ_ME_NOW.txt
M	/srv/share/projects/roadmap.docx
M	/srv/share/projects/roadmap.docx.locked

Що це означає: Типові маркери рансомваре: нова записка з вимогою, перезаписані файли, нові розширення.

Рішення: Оберіть снапшот до появи цих артефактів. Якщо артефакти є у багатьох снапшотах, шифрування почалося раніше, ніж ви думали.

Завдання 9: безпечно оглянути снапшот, не змінюючи нічого

cr0x@server:~$ ls -la /srv/share/.zfs/snapshot/auto-2025-12-26-1200 | head
total 12
drwxr-xr-x   9 root root    9 Dec 26 12:00 .
drwxr-xr-x  10 root root   10 Dec 26 14:00 ..
drwxr-xr-x  12 root root   12 Dec 20 09:10 finance
drwxr-xr-x  34 root root   34 Dec 24 17:03 projects

Що це означає: Снапшоти видимі через директорію .zfs (якщо включена та не прихована в налаштуваннях шарів).

Рішення: Використовуйте перегляд снапшотів для швидкої перевірки. Якщо на вашій платформі .zfs не відкрита, змонтуйте клон замість цього.

Завдання 10: клонувати снапшот для валідації тільки для читання

cr0x@server:~$ zfs clone -o mountpoint=/mnt/restore_share -o readonly=on tank/share@auto-2025-12-26-1200 tank/share-restore
cr0x@server:~$ zfs get -o name,property,value readonly,mountpoint tank/share-restore
NAME              PROPERTY    VALUE
tank/share-restore  readonly    on
tank/share-restore  mountpoint  /mnt/restore_share

Що це означає: Тепер у вас є клон, змонтований тільки для читання для валідації та сканування.

Рішення: Перевірте вміст і вибірково огляньте критичні директорії. Якщо чисто, плануйте переключення: або просунути клон, або rsync дані на чисту ціль.

Завдання 11: відкат на місці (тільки коли ви приймаєте ризик)

cr0x@server:~$ zfs rollback -r tank/share@auto-2025-12-26-1200
cr0x@server:~$ zfs list -o name,used,refer,mountpoint tank/share
NAME        USED  REFER  MOUNTPOINT
tank/share  8.1T  8.1T  /srv/share

Що це означає: Стан датасету повернуто до цього снапшоту; опція -r відкачує й нащадків.

Рішення: Використовуйте це лише коли ви зупинили доступ атакувальника і впевнені у виборі снапшоту. Відкат швидкий, але втрачає нові зміни. Домовтесь з бізнесом про прийнятний вік втрати даних.

Завдання 12: визначити, що займає простір (чому «df» бреше під час снапшотів)

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbydataset,usedbychildren tank/share
NAME        USED  USEDSNAP  USEDDATA  USEDCHILD
tank/share  8.4T     1.1T     7.3T       0B

Що це означає: Снапшоти закріплюють 1.1T блоків. Це не «марнотратство»; це ваша страховка.

Рішення: Не видаляйте снапшоти, щоб «звільнити місце» під час інциденту, якщо ви не підтвердили наявність поза машиною бекапів і не наближаєтесь до критичного відмови.

Завдання 13: перевірити стан реплікації (чи чистий та актуальний офсайт?)

cr0x@server:~$ zfs get -H -o value receive_resume_token tank/share
-
cr0x@server:~$ zfs list -t snapshot -o name -s creation -r tank/share | tail -n 3
tank/share@auto-2025-12-26-1200
tank/share@auto-2025-12-26-1300
tank/share@auto-2025-12-26-1400

Що це означає: Відсутній resume token — означає, що прийом не був перерваний з цього боку; ланцюг снапшотів існує локально.

Рішення: На цілі реплікації підтвердіть, що вона має снапшоти, створені до зараження, і що права на видалення обмежені. Якщо ціль «занадто синхронна», можливо, ви реплікували зашифровані дані — шукайте старі точки.

Завдання 14: виконати контрольований send/receive відновлення в новий датасет

cr0x@server:~$ zfs send -R tank/share@auto-2025-12-26-1200 | zfs receive -u tank/restored/share
cr0x@server:~$ zfs list -o name,mountpoint -r tank/restored
NAME                MOUNTPOINT
tank/restored        /tank/restored
tank/restored/share  /tank/restored/share

Що це означає: Ви відновили точку часу в окремому дереві датасетів, не перезаписуючи оригінал.

Рішення: Віддавайте перевагу цьому підходу, коли потрібна чітка ізоляція і є місце. Потім можна переключити експорти на відновлений датасет після валідації.

Завдання 15: підтвердити властивості датасету, що впливають на швидкість і коректність відновлення

cr0x@server:~$ zfs get -o name,property,value compression,recordsize,atime,sync tank/share
NAME       PROPERTY     VALUE
tank/share compression  lz4
tank/share recordsize   1M
tank/share atime        off
tank/share sync         standard

Що це означає: Ці налаштування впливають на продуктивність і поведінку навантаження. Для VM-подібного навантаження recordsize і sync особливо важливі.

Рішення: Не змінюйте ці налаштування під час інциденту, якщо не впевнені точно навіщо. «Тюнінг під час аварії» — хобі для людей, які люблять несподівані наслідки.

Завдання 16: перевірити ризики моделі прав (хто може видаляти снапшоти?)

cr0x@server:~$ zfs allow tank/share
---- Permissions on tank/share ---------------------------------------
Local+Descendent permissions:
user backupsvc create,destroy,mount,snapshot,send,receive
user appsvc   mount

Що це означає: Користувач backupsvc може видаляти снапшоти. Це високоцінний привілей.

Рішення: На етапі укріплення після інциденту прибрати destroy, якщо воно не потрібне, і розділити ролі для створення снапшотів і їх видалення.

Стратегії відновлення: відкат, клон і «відновити в інше місце»

Стратегія A: відкат на місці (найшвидше, але різкі краї)

Відкат — це молот. Він також спасіння, коли бізнес втрачає швидко й у вас є добре зрозумілий датасет (наприклад, файловий шар) та надійний графік снапшотів.

Використовуйте коли:

• Висока впевненість, що вектор компрометації локалізовано (облікові дані змінено, експорти вимкнено, шкідливе ПЗ видалено).
• Ви готові втратити зміни після вибраного снапшоту.
• Датасет не містить шляхів виконання коду, які можуть бути повторно запущені (наприклад, спільні скрипти, що виконуються серверами).

Уникайте коли:

• Підозрюєте, що хост досі скомпрометований.
• Датасет — це VM datastore або база даних, де відкати можуть порушити консистентність додатків.
• Потрібна судова експертиза за зашифрованим станом і ви не можете перезаписувати докази.

Стратегія B: клонувати снапшот і переключитись (безпечніше, все ще швидко)

Клон дозволяє перевірити й обслуговувати чисті дані, не руйнуючи поточний датасет. Ви також можете зберегти «заражений» датасет для розслідування. Операційно можна змінити mountpoint, експорти або SMB-шари, щоб вказувати на клон.

Зауважте: клон споживає місце в міру дивергенції. Якщо ви будете обслуговувати клон тижнями, він стане «продакшеном», а оригінал — «те, що колись видалимо». Того дня часто так і не настає, а заповнення пулу потихеньку зростає. Плануйте прибирання.

Стратегія C: відновити в інше місце (серйозний крок)

Відновлення на окремий хост/пул, коли ви не довіряєте системі, що постраждала. Це стандарт для datastore VM, баз даних і всього, що пов’язане з привілейованою автоматизацією.

Операційні переваги:

• Чиста контрольна площина: нові SSH-ключі, нові облікові дані, нові експорти.
• Знижений ризик реінфекції: атакувальники часто зберігаються в оригінальному середовищі.
• Паралельна робота: одна команда відновлює, інша — проводить форензіку на компрометованому хості.

Витрати:

• Ємність і час. Потрібне місце для receive та валідації.
• Пропускна здатність мережі може стати вузьким місцем.

Жарт №2 (коротко, по темі): Єдина річ страшніша за відновлення з бекапів — це виявити, що ваші бекапи займались «інтерпретативним танцем» замість реплікації.

Три корпоративні історії з практики

Міні-історія 1: інцидент через хибне припущення

Середня компанія експлуатувала файловий шар на ZFS для відділів. Вони пишалися щогодинними снапшотами. Служба підтримки могла відновлювати файли, переглядаючи .zfs/snapshot. Це здавалося сучасним. Але все було побудовано на одному припущенні: «лише адміністратори можуть видаляти снапшоти».

Під час фішингової компрометації атакувальник потрапив на Windows-станцію і згодом отримав облікові дані сервісного акаунта, який виявився використовуваним для «самообслуговування відновлень». Цей акаунт мав значно більше прав, ніж ім’я натякало. Він міг створювати снапшоти, монтувати їх і — тому що хтось не хотів розбиратись із скриптами утримання — видаляти.

Атакувальнику не потрібні були спеціальні знання ZFS. Він знайшов історію shell і скрипти автоматизації, після чого виконав кілька команд ZFS, щоб знищити ланцюг снапшотів перед шифруванням живого шару. Шифрування було голосним; видалення снапшотів — тихим.

Відновлення було можливе, але не з локальних снапшотів. Команда змушена була тягнути дані з старшої офсайт-копії, яка реплікувалася щотижня (не щогодини), відновлювати терабайти через обмежений канал і відповідати на неприємне питання: «Тож що ми втратили?»

Виправлення було простим і принизливим: делеговані права розділили. Створення снапшотів і реплікація були відокремлені від видалення снапшотів, а на найближчих щоденних точках поставили holds. Також перестали відкривати .zfs користувачам і замінили самообслуговування на контрольований робочий процес. Система стала трохи менш зручною, але значно більш живучою.

Міні-історія 2: оптимізація, що повернулась бумерангом

Інша організація хостила образи VM на ZFS. Вони хотіли вищої продуктивності для найжвавішого навантаження і зробили високоагресивні тюнінг-зміни: більший recordsize, пом’якшене sync у деяких місцях і зменшений графік снапшотів «щоб зменшити накладні витрати». Все це було виправдане бенчмарками і кількома приємними графіками.

Потім рансомваре влучило на jump host, який мав доступ до мережі управління VM. Атакувальник не шифрував файли на ZFS-хості; він шифрував всередині гостьових систем. Сховище зафіксувало шторм випадкових записів по великих zvol. Зменшений графік снапшотів означав, що остання чиста точка для кількох критичних VM була давно.

Тюнінг продуктивності зробив відновлення гіршим. Через менше снапшотів намагалися реплікувати великі образи з останньої доброї точки. Мережеве з’єднання стало вузьким місцем, а процесорні накладні витрати від стиснення/шифрування на стороні send додали проблем. Відновлення були правильними, але настільки повільними, що порушили внутрішні цілі відновлення.

Післяінцидентний розбір був не про те, що ZFS «повільний». Він був про оптимізацію для стійкого стану з ігноруванням режиму відмови. Вони повернули частіші снапшоти для VM-датасетів, відокремили «тюнінг продуктивності» від «дизайну відновлення» і ввели жорсткі вимоги до точок відновлення для tier-0 систем. Графіки steady-state покращились. Але важливіше те, що наступний інцидент завершиться відновленням, а не перемовинами.

Міні-історія 3: нудна, але правильна практика, що врятувала день

Регульована компанія використовувала ZFS для департаментських шарів і невеликого аналітичного кластера. Їхня політика снапшотів була нудна: знімки кожні 15 хвилин протягом 24 годин, щогодини протягом тижня, щодня протягом місяця. Реплікація йшла на офсайт під іншим адміністративним доменом, а права на видалення снапшотів не делегувалися продакшен-автоматизації.

Вони також виконували квартальний drill відновлення. Не макетну вправу. Реальне відновлення репрезентативного датасету на чистий хост з хронометром і чек-листом. Інженери це ненавиділи, як і чищення зубів: знаєш, що правильно, але все одно неприємно.

Коли рансомваре влучило через заражену робочу станцію, файловий шар постраждав. Вони швидко локалізували доступ, клонували останній чистий снапшот у карантинний монтувальний пункт і перевірили відсутність артефактів. Перемикання зайняло години, а не дні.

Офсайт-реплікація була тихим героєм. Навіть якби атакувальник видалив локальні снапшоти, офсайт мав старші точки, захищені політикою та правами. Звіт про інцидент все одно був болісним, але відновлення пройшло за процедурою. Ніякої імпровізації, ніяких нічних подвигів, ніякого «ми думаємо, що в нас все».

Що їх врятувало — не геній. Це було відмовлення трактувати снапшоти як фічу і натомість ставитись до них як до продукту з вимогами: збереження, захист і тестові відновлення.

Укріплення снапшотів, щоб наступного разу було нудно

Частота снапшотів: підлаштуйте під поведінку рансомваре

Рансомваре часто діє швидко, але не завжди. Інколи воно шифрує агресивно, інколи повзає, щоб уникнути виявлення. Ваш графік снапшотів має припускати, що ви можете помітити інцидент із запізненням.

• Tier 0 (спільні бізнес-дані): кожні 15 хвилин протягом 24 годин, щогодини протягом 7 днів, щодня протягом 30 днів — адекватна база.
• VM datastores: часті снапшоти корисні, але не ведуть особистої узгодженості додатків. Використовуйте їх як crash-consistent точки і поєднуйте з гостьовими бекапами для критичних баз даних.
• Домашні директорії: велика зміна даних; узгодьте очікування щодо утримання, щоб уникнути вибуху використання простору снапшотами.

Захищайте снапшоти від видалення (тут живуть дорослі)

Оборона переважно про те, хто що може робити. Снапшоти вразливі, якщо права на їх видалення лежать у тому ж пулі облікових записів, що й щоденні операції.

• Використовуйте holds на щоденних/тижневих «якірних» снапшотах, особливо на цільових реплікаціях.
• Розділяйте привілеї: створення снапшотів і реплікація — звична операція; видалення снапшотів має бути рідкісним і захищеним.
• Розділяйте адміністративні домени: цілі реплікації не повинні приймати інтерактивні логіни облікових записів продакшен-адмінів, якщо це можна уникнути.
• Зробіть ціль бекапу нудною і ощадливою: мінімум пакетів, мінімум сервісів, суворі правила фаєрволу, за можливості read-only експорти.

Дизайн реплікації: навмисно створіть «проміжок на помилку»

Якщо ви реплікуєте щохвилини і також миттєво поширюєте видалення, ви побудували pipeline високої доступності для катастроф. Додайте навмисне тертя:

• Затримуйте руйнівні дії: політики утримання та видалення на цілі мають бути незалежні від джерела.
• Тримайте довше збереження офсайт: ціль — місце, де ви зберігаєте історію, яка може знадобитись.
• Розгляньте pull-based реплікацію: ціль ініціює pull з джерела, використовуючи обмежені облікові дані, а не джерело, що штовхає у ціль з широкими правами.

Тестові відновлення: припиніть обманювати себе

Снапшоти — не бекап, поки ви не можете їх відновити під стресом. Проводьте drill. Заміряйте час. Підтверджуйте вміст. Документуйте кроки. Покладіть чек-лист там, де його знайде людина о 3-й ранку, яка не будувала систему.

Типові помилки: симптом → корінь → виправлення

1) «Ми відкатили, але користувачі все ще бачать зашифровані файли»

Симптом: Після відкату деякі директорії все ще містять файли з розширенням .locked або записки з вимогою.

Корінь: Ви відкатили неправильний датасет (або неправильний снапшот), або користувачі дивляться інший шлях експорту (DFS namespace, мапінг SMB), або клієнтська офлайн-кеш пам’яті.

Виправлення: Підтвердіть mountpoints датасетів і налаштування шарів; перевірте вибір снапшоту за допомогою zfs diff. Очистіть або скиньте клієнтські кеші за потреби. Переконайтесь, що ви не відновили тільки дочірній датасет, поки батько залишився інфікованим.

2) «Відкат не вдається з помилкою ‘dataset is busy’»

Симптом: ZFS відмовляє у відкаті через активні монтування.

Корінь: Процеси досі тримають відкриті файли, або датасет експортується через NFS/SMB, або jail/container його використовує.

Виправлення: Зупиніть сервіси, зніміть експорти та відмонтуйте при потребі. Використовуйте клони або receive-elsewhere, якщо не можете безпечно зупинити все.

3) «Ми не можемо клонувати або прийняти: немає місця»

Симптом: Операції клонування/receive відмовляють; пул майже повний.

Корінь: Високий CAP або утримання снапшотів закріплює великі обсяги даних, плюс ефект записового підсилення від інциденту.

Виправлення: Додайте ємність (найкраще), перемістіть неважливі датасети, або виконайте відкат на місці (якщо безпечно). Уникайте масових видалень снапшотів під час пікового I/O; це може погіршити продуктивність.

4) «Ціль реплікації теж має зашифровані дані»

Симптом: Офсайт-снапшоти містять артефакти рансомваре.

Корінь: Реплікація відбулась після зараження; збереження занадто коротке; видалення синхронізувалося; немає захищених опорних точок.

Виправлення: Тримайте довше збереження на цілі, використовуйте holds, розділяйте політики видалення і розгляньте відкладену або pull-based реплікацію. Під час інциденту зупиніть реплікацію, щоб не перезаписати добру історію.

5) «Відновлення надто повільне»

Симптом: Пропускна здатність send/receive значно нижча за очікування.

Корінь: Обмеження CPU (шифрування/сжаття), вузьке місце мережі, фрагментація пулу або конкурентні завдання (scrub, resilver, активні шкідливі записи).

Виправлення: Заміряйте: перевірте iostat, навантаження CPU, пропускну здатність лінка. Призупиніть неважливі завдання. Відновлюйте на інший пул, якщо оригінал перевантажений або нездоровий.

6) «Снапшоти зникли, але ніхто не визнає видалення»

Симптом: Ланцюг снапшотів відсутній; логи неясні.

Корінь: Надмірно привілейована автоматизація або скомпрометований сервісний акаунт виконав руйнівні команди, або скрипт утримання спрацював некоректно.

Виправлення: Аудит делегованих прав і автоматизації. Заблокуйте видалення. Ставте holds на опорні точки. Централізуйте логування адміністративних дій ZFS і подій автентифікації; налаштуйте оповіщення на видалення снапшотів.

7) «Ми відновили, а потім знову інфікувались»

Симптом: Шифрування відновлюється після повернення в експлуатацію.

Корінь: Ви відновили дані, але не довіру. Компрометовані облікові дані, персистентне шкідливе ПЗ або відкриті експорти залишилися.

Виправлення: Поміняйте облікові дані перед переключенням, відновіть або перебудуйте компрометовані хости і поступово відновлюйте доступ. Розглядайте відновлення як зміну з контролем, а не як магічну кнопку «скасувати».

Чек-листи / покроковий план

Чек-лист реагування на інцидент (з точки зору сховища/оператора)

1. Локалізація: вимкніть SMB/NFS експорти або фільтруйте їх; зупиніть додатки з інтенсивним записом; ізолюйте компрометовані кінцеві точки.
2. Заморожування: зробіть снапшот @incident-* уражених датасетів для доказів.
3. Перевірте стан: zpool status, ємність, помилки. Якщо пул нездоровий, плануйте відновлення в інше місце.
4. Зупиніть реплікацію: призупиніть завдання, щоб не реплікувати зашифрований стан поверх доброї історії.
5. Знайдіть останній відомо чистий снапшот: використовуйте zfs diff, перевірте вміст, шукайте артефакти рансомваре.
6. Захистіть його: застосуйте zfs hold до кандидатів снапшотів.
7. Оберіть режим відновлення: відкат, клон і переключення, або відновлення в інше місце.
8. Валідація в карантині: змонтуйте клон тільки для читання; проскануйте на артефакти; підтвердіть, що критичні файли відкриваються коректно.
9. Переключення: перенаправте експорти/mounts; поступово відновіть доступ; моніторьте записи і логи автентифікації.
10. Укріплення після відновлення: поміняйте ключі, відкоригуйте zfs allow, впровадьте політики збереження, захистіть ціль.
11. Документуйте хронологію: часи снапшотів, вибрану точку відновлення, вік втрати даних, вжиті дії.
12. Проведіть drill відновлення пізніше: так, пізніше. Але заплануйте його, поки всі ще пам’ятають.

Чек-лист переключення відновлення (на основі клонування)

1. Створіть клон з останнього відомо чистого снапшоту, змонтуйте тільки для читання.
2. Перевірте структуру директорій, контрольні суми критичних файлів і відсутність очевидних артефактів рансомваре.
3. Створіть записуваний клон (або просуньте workflow), якщо потрібно подавати дані активно.
4. Оновіть SMB/NFS експорти, щоб вказувати на mountpoint клона (або атомарно поміняйте mountpoints, де можливо).
5. Поверніть сервіс для невеликої пілотної групи спочатку.
6. Спостерігайте I/O, помилки автентифікації і патерни створення нових файлів принаймні один бізнес-цикл.
7. Лише потім вирішіть, що робити з інфікованим датасетом: зберегти для форензіки, заархівувати або знищити після затверджень.

Чек-лист укріплення після інциденту (стійкість снапшотів)

1. Розділіть делеговані права ZFS: приберіть можливість видаляти снапшоти у рутинних акаунтів.
2. Встановіть holds на опорні снапшоти (щоденні/тижневі) на реплікаційному цілі.
3. Розділіть політики утримання між джерелом і ціллю; не пропагуйте видалення бездумно.
4. Централізуйте логування адміністративних команд і подій автентифікації; налаштуйте оповіщення про видалення снапшотів.
5. Зменшіть шляхи запису: принцип найменших привілеїв для шарів, окремі адміністраторські мережі, MFA де можливо.
6. Плануйте тестові відновлення і вимірюйте RTO/RPO на реальних обсягах даних.

Поширені запитання

1) Чи є снапшоти ZFS «незмінними» бекапами?

Ні. Снапшоти — це стійкі точки в часі, але не незмінні за замовчуванням. Якщо хтось може виконати zfs destroy над ними, їх можна видалити. Використовуйте holds, розділення привілеїв і офсайт-реплікацію під іншим адміністративним доменом, якщо хочете практичну незмінність.

2) Що обрати: відкат чи клон?

Клонити, коли можливо; відкат — коли треба. Клони зберігають докази і дозволяють валідувати перед переключенням. Відкат швидший і простіший, але втрачає нові зміни і може поновити ризик, якщо хост досі скомпрометований.

3) Як зрозуміти, який снапшот чистий?

Використовуйте комбінацію: хронологію інциденту (коли з’явилися симптоми), zfs diff між снапшотами і безпосередній огляд read-only клона або дерева снапшотів. Шукайте записки з вимогою, нові розширення і масові патерни модифікації файлів.

4) Що, якщо рансомваре зашифрувало диски VM (zvol), а не файли?

Ви все одно можете відкотити або відновити датасет zvol, але точка відновлення має передувати шифруванню. Очікуйте великих переносів даних і повільнішої валідації. Для критичних баз поєднуйте відновлення ZFS з рівнем додатків (transaction logs, консистентні бекапи).

5) Чи зупинить рансомваре вмикання шифрування ZFS?

Ні. Шифрування ZFS захищає дані у спокої і може зменшити деякі сценарії крадіжки, але рансомваре з легітимним доступом все ще може читати/писати й шифрувати файли всередині датасету.

6) Чи можуть атакувальники видаляти снапшоти через SMB/NFS?

Прямо через файлові операції — ні. Але якщо вони скомпрометували облікові дані, що мають shell/API доступ до ZFS-хоста — або автоматизацію, що керує снапшотами — вони можуть виконати видалення командою ZFS. Ваш ризик — це ідентичність і привілеї, а не сам протокол SMB.

7) Чи варто лишати .zfs/snapshot для самообслуговування?

Це зручно, але часто призводить до зловживань (люди трактують снапшоти як кошик для видалених файлів). Якщо залишаєте, обмежте доступ і суворо контролюйте права на видалення снапшотів. Багато середовищ краще працюють з контрольованим робочим процесом відновлення.

8) Чому звільнити місце стало важче після інциденту?

Тому що снапшоти фіксують блоки. Після масових перезаписів «старі» чисті дані все ще посилюються снапшотами, а «нові» зашифровані дані займають додаткове місце. Це очікувано. Планування ємності має включати запас для інцидентів, а не лише steady-state зростання.

9) Чи безпечно видаляти зашифрований датасет після відновлення?

Технічно — так, але операційно — можливо ні. Отримайте затвердження від безпеки/юридичного відділу, якщо інцидент потребує звітності. Якщо потрібна форензіка, збережіть зашифрований стан (або його снапшот) із ізоляцією і контрольованим доступом.

10) Яке найкраще одне покращення, якби треба було зробити тільки одне?

Захистіть офсайт-снапшоти від видалення компрометованими продакшен-обліковими даними. Це означає окремий адміністративний домен, holds на опорних точках і ретеншн, який не може бути «очищений» атакувальником.

Наступні кроки, які можна зробити сьогодні

Коли влучає рансомваре, снапшоти ZFS можуть перетворити інцидент, що кидає кар’єру в прірву, на поганий день з чек-листом. Але тільки якщо ви проклали шлях заздалегідь: чисті точки відновлення, захищена історія і рутини відновлення, що не залежать від героїв.

Зробіть наступне:

1. Аудитуйте zfs allow на критичних датасетах. Приберіть можливість видалення снапшотів з рутинних акаунтів і автоматизації, яка цього не потребує.
2. Додайте holds до щоденних/тижневих опорних снапшотів на реплікаційному цілі.
3. Запишіть свій метод вибору «останньо відомо чистого» (хронологія + zfs diff + валідація read-only клона).
4. Проведіть drill відновлення на репрезентативному датасеті. Заміряйте час. Занотуйте кроки. Виправте те, що здивувало.
5. Зафіксуйте заздалегідь, коли ви робитимете відкат vs клон vs відновлення в інше місце. Під час інциденту — не час винаходити філософію.

Рансомваре — інженерна проблема в злочинному костюмі. Розв’язуйте її інженерією: обмеження, поділ обов’язків і протестовані шляхи відновлення.