ZFS Readonly: трюк проти рансомвару, який можна розгорнути сьогодні

October 30, 2025 • February 3, 2026 • Читання: 5 хв • Views: 5

Було корисно?

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

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

Що насправді означає ZFS readonly (і чого це не означає)

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

Readonly діє на датасет, а не на ваші наміри

Коли ви встановлюєте readonly=on на датасеті:

Записи через монтуваний файловий простір блокуються (додатки бачитимуть помилки на кшталт «Read-only file system»).
Оновлення метаданих, що потребують запису (створення файлів, перейменування, chmod тощо) також не вдаються.
Ви все ще можете читати, переходити по каталогах і обчислювати контрольні суми; ZFS охоче віддає дані.

Чого це не означає:

Це не захищає снапшоти автоматично. Снапшоти мають власну історію безпеки.
Це не заважає привілейованому користувачеві переключити його назад у off.
Це не захищає від знищення на рівні пулу (наприклад, zpool destroy від root). Саме тому важлива роздільність обов’язків.
Це не блокує записи через інший шлях, який обходить змонтований файловий простір (наприклад, якщо ви реплікуєте датасет у нього, ви можете писати на рівні ZFS, а не через монтування).

Іншими словами: readonly — це міцний ремінь безпеки, але не телепорт. Він допомагає пережити типові аварії, але не варто навмисно врізатися в стіну.

Що рансомвар зазвичай робить з вашими файлами

Рансомвар на рівні файлів зазвичай:

Переліковує каталоги, часто використовуючи стандартні API, іноді з багатопотоковістю.
Читає файл, записує зашифровану версію (в кілька етапів або на місці), потім перейменовує.
Видаляє оригінали або обрізає їх.
Цілиться у файлові сервери по SMB/NFS, бо там зосереджені спільні дані і часто широкі права на запис.

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

Жарт на завершення: readonly — це як засклити ваші дані — люди можуть милуватися ними, але не можуть «прикрасити» їх малюнком від рансомвару.

Чому readonly працює проти рансомвару

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

Readonly зменшує радіус ураження

У продакшні дані рідко однорідні. У вас є:

Активні робочі набори (потрібні часті записи).
Довідкові дані (рідко змінюються, активно читаються).
Архіви (не повинні змінюватися).
Цілі резервних копій/реплік (в ідеалі — записати один раз у практиці).

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

Readonly — це миттєво, дешево та спостережувано

Контроли безпеки, що вимагають довгих проєктів, часто програють «терміновим бізнес-пріоритетам». ZFS readonly не належить до таких. Ви можете:

Увімкнути його одним зміною властивості.
Підтвердити командою zfs get і за реальною поведінкою додатків.
Моніторити спроби запису (додатки логуватимуть помилки; SMB/NFS клієнти скаржитимуться).

Ця спостережуваність важлива. У кількох інцидентах, які я бачив, перша серйозна підказка була «чому цей каталог раптово став лише для читання?». Насправді він не був «старим» readonly — система намагалася записувати сміття на високій швидкості і встрягала в захисні механізми. Ці обмежувачі перетворили катастрофу на гучну неприємність.

Readonly добре поєднується зі снапшотами — і саме їх ви будете використовувати

Readonly — це запобіжний контроль. Снапшоти — це контроль відновлення. Разом вони дозволяють сказати:

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

Якщо робити тільки снапшоти, рансомвар все ще може зашифрувати живу файлову систему і ви перейдете в режим відновлення. Якщо робити тільки readonly, ви можете заблокувати легітимні бізнес-зміни. Солідним підходом є продумане розташування датасетів так, щоб бути стриманим там, де безпечно, і гнучким там, де потрібно.

Цікаві факти та історичний контекст

Інженерія зберігання має довгу пам’ять. Декілька контекстних пунктів, які роблять ZFS readonly менш трюком і більше сучасною інкарнацією старих ідей:

ZFS з’явився на початку 2000-х у Sun Microsystems, побудований на ідеї, що файлову систему та менеджер томів слід робити однією системою, а не двома незручними сусідами.
Copy-on-write (CoW) — це суперсила ZFS: дані не перезаписуються на місці; нові блоки записуються, а вказівники оновлюються. Це робить снапшоти дешевими й консистентними.
Снапшоти існували до появи рансомвару як мейнстрім-агресора. Вони були розроблені для помилок адміністрування та консистентності, але чудово підходять для відновлення через відкат.
«Незмінність» не нова: WORM (write once, read many) сховища продаються десятиліттями для архівів відповідності. ZFS readonly — практичне наближення для багатьох датасетів.
Сучасний рансомвар еволюціонував з «екранів-замикачів» у шифрувальні програми-викупники, коли криптографія стала простішою в експлуатації, а бекапи — поширеними.
SMB-шари стали привабливою ціллю, бо концентрують спільні дані і успадковують широкі права: один скомпрометований користувач може доторкнутися до багато чого.
Ранні користувачі ZFS болісно дізналися, що «снапшоти існують» — не те саме, що «снапшоти в безпеці». Якщо зловмисник може знищити снапшоти, ви повертаєтесь до нульового пункту.
Операційне розділення обовʼязків старше за комп’ютери: людина, яка схвалює витрати, не повинна бути тією, що переводить кошти. Така сама логіка стосується того, хто може видаляти снапшоти або змінювати readonly.
«Офлайн-бекапи» раніше означали стрічки. Сьогодні часто це «репліка, яку не можна змінити з площини ідентичності продакшну». Readonly датасети — одна із частин цього пазлу.

Ще один жарт: рансомвар — єдине навантаження, яке чудово масштабується без підвищення продуктивності на атестації роботи.

Шаблони проєктування: де readonly вписується в реальне сховище

Readonly найбільш ефективний, коли ваші датасети віддзеркалюють реальність: що змінюється, що не повинно і що потрібно відновлювати швидко. Ви не посипаєте readonly як приправу; ви будуєте межі.

Шаблон 1: Розділення «активних» і «опублікованих» даних

Поширено в аналітиці та конвеєрах вмісту:

Активний датасет для інгесту: записуваний, використовується ETL або завантажувальними процесами.
Опублікований датасет: readonly, використовується читачами (BI-інструменти, веб-сервери, командами вниз по потоку).

Підвищення — це контрольована дія: снапшот або клон переноситься в простір опублікованого, потім блокується як readonly. Якщо рансомвар вразить вузол інгесту, інгест може постраждати, але опубліковане залишиться цілим.

Шаблон 2: Readonly репліки як «бідний варіант повітряного зазору»

Налаштуйте хост для бекапів/DR, що отримує реплікацію ZFS. На боці приймача тримайте датасети змонтованими readonly (або взагалі не монтуйте) і обмежте, хто може міняти властивості. Ціль стає «онлайн, але не просто записувана», що часто є операційним оптимумом.

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

Шаблон 3: Незмінні домашні директорії (обережно)

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

Але будьте чесні: для знаннєвих працівників домашні директорії — це активні дані. Не перетворюйте readonly на відмову в обслуговуванні продуктивності.

Шаблон 4: Захист ваших «відомо-хороших» точок відновлення

Більшість організацій мають директорію на кшталт /srv/releases, /srv/installers, /srv/golden або «річ, з якої ми перевстановлюємо, коли світ закінчується». Зробіть її окремим датасетом. Зробіть його readonly. Снапшотуйте. Реплікуйте. Якщо рансомвар вразить і ви не зможете безпечно перевстановити, ви відкриєте нові визначення «поганого дня».

Перевірка моделі загроз

Readonly найбільше допомагає проти:

Скомпрометованих облікових записів користувачів з доступом до файлових шарів.
Шкідливого ПО на прикладних серверах, що пише у спільні датасети.
Випадкових руйнівних скриптів (так, вони теж рахуються).

Readonly менше допомагає проти:

Компрометації root на самому сервері сховища.
Атакувальників з адміністративними правами ZFS, які можуть змінювати властивості або знищувати снапшоти.
Фізичного доступу та зловмисного модифікування ядра.

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

Практичні завдання (команди + інтерпретація)

Усі наведенi нижче команди припускають OpenZFS на Linux з типовим пулом імені tank. Підлаштуйте імена під своє середовище. Головне — не точна рядок, а операційний намір і те, як виглядає «добре».

Завдання 1: Перелік датасетів і пошук очевидних кандидатів для readonly

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank                 3.41T  5.22T   192K  /tank
tank/home             610G  5.22T   610G  /home
tank/projects         1.20T  5.22T  1.20T /srv/projects
tank/releases          42G  5.22T   42G   /srv/releases
tank/backup-recv      1.55T  5.22T  1.55T /srv/backup-recv

Інтерпретація: tank/releases і tank/backup-recv — негайні кандидати для readonly. tank/home і tank/projects ймовірно активні і потребують іншої стратегії (снапшоти + квоти + права + можливо розділення на published/active).

Завдання 2: Перевірити поточний стан readonly по всьому пулу

cr0x@server:~$ sudo zfs get -r -o name,property,value,source readonly tank
NAME             PROPERTY  VALUE  SOURCE
tank             readonly  off    default
tank/home        readonly  off    default
tank/projects    readonly  off    default
tank/releases    readonly  off    default
tank/backup-recv readonly  off    default

Інтерпретація: Все записуване. Це нормально на старті, і саме через це рансомвар процвітає на файлових серверах.

Завдання 3: Встановити датасет у readonly

cr0x@server:~$ sudo zfs set readonly=on tank/releases
cr0x@server:~$ sudo zfs get -o name,property,value,source readonly tank/releases
NAME          PROPERTY  VALUE  SOURCE
tank/releases readonly  on     local

Інтерпретація: Властивість тепер встановлена локально. Існуючі процеси, що припускають можливість запису в /srv/releases, почнуть падати — це й має статися, але варто координувати зміну.

Завдання 4: Підтвердити поведінку реальною спробою запису

cr0x@server:~$ sudo touch /srv/releases/should-fail
touch: cannot touch '/srv/releases/should-fail': Read-only file system

Інтерпретація: Це режим відмови, який ви хочете під час спроби шифрування: гучний, миттєвий і не «успішно перезаписав ваші дані».

Завдання 5: Зробити безпечну операційну процедуру для «тимчасового дозволу записів»

Readonly не означає «встановив і забув», якщо іноді потрібно легітимно оновити датасет. Хитрість — створити відтворювану процедуру «вікна обслуговування», що залишає сліди.

cr0x@server:~$ sudo zfs snapshot tank/releases@before-maint-2025-12-24
cr0x@server:~$ sudo zfs set readonly=off tank/releases
cr0x@server:~$ sudo rsync -a --delete /staging/releases/ /srv/releases/
cr0x@server:~$ sudo zfs set readonly=on tank/releases
cr0x@server:~$ sudo zfs snapshot tank/releases@after-maint-2025-12-24

Інтерпретація: Ви створили дві чіткі точки відновлення. Якщо хост обслуговування був скомпрометований, ви можете відкотитися до @before-maint або проаналізувати відмінності між снапшотами.

Завдання 6: Загострити поведінку снапшотів за допомогою hold ( «прикріплення» снапшота)

Снапшот може бути знищений нападником з достатніми правами. ZFS надає «holds», щоб заборонити видалення до зняття hold.

cr0x@server:~$ sudo zfs snapshot tank/releases@golden
cr0x@server:~$ sudo zfs hold keep tank/releases@golden
cr0x@server:~$ sudo zfs holds tank/releases@golden
NAME                  TAG   TIMESTAMP
tank/releases@golden  keep  Wed Dec 24 10:02 2025

Інтерпретація: Навіть якщо хтось виконає zfs destroy tank/releases@golden, це не спрацює, доки hold не буде знято. Це не абсолютний захист від root на сервері сховища, але підвищує складність та запобігає випадковому видаленню.

Завдання 7: Побудувати реплікаційну ціль, яка за замовчуванням readonly

На хості-приймачі бекапів ви можете реалізувати політику: дані приходять через zfs receive, але змонтований вигляд readonly.

cr0x@backup:~$ sudo zfs create -o mountpoint=/srv/backup-recv tank/backup-recv
cr0x@backup:~$ sudo zfs set readonly=on tank/backup-recv
cr0x@backup:~$ sudo zfs get -o name,property,value tank/backup-recv
NAME             PROPERTY  VALUE
tank/backup-recv readonly  on

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

Завдання 8: Реплікувати снапшоти (send/receive) так, щоб відновлення було справжнім

cr0x@prod:~$ sudo zfs snapshot tank/projects@replica-001
cr0x@prod:~$ sudo zfs send -w tank/projects@replica-001 | ssh backup sudo zfs receive -u tank/backup-recv/projects

Інтерпретація: Параметр -u отримує без монтування, що є недооціненою гігієною безпеки. Немонтовані бекапи не можуть бути випадково переглянуті або змінені процесами, і не стають частиною щоденного простору імен.

Завдання 9: Перевірити реплікацію і встановити отриманий датасет readonly

cr0x@backup:~$ sudo zfs list -t snapshot tank/backup-recv/projects | tail -n 3
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
tank/backup-recv/projects@replica-001        0B      -  1.20T  -
cr0x@backup:~$ sudo zfs set readonly=on tank/backup-recv/projects
cr0x@backup:~$ sudo zfs get readonly,mounted,mountpoint tank/backup-recv/projects
NAME                      PROPERTY    VALUE    SOURCE
tank/backup-recv/projects readonly    on       local
tank/backup-recv/projects mounted     no       -
tank/backup-recv/projects mountpoint  /tank/backup-recv/projects  default

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

Завдання 10: Швидко відкотитися після події шифрування (коли ви впевнені)

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

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation tank/projects | tail -n 5
tank/projects@hourly-2025-12-24-08:00  Wed Dec 24 08:00 2025
tank/projects@hourly-2025-12-24-09:00  Wed Dec 24 09:00 2025
tank/projects@hourly-2025-12-24-10:00  Wed Dec 24 10:00 2025
tank/projects@hourly-2025-12-24-11:00  Wed Dec 24 11:00 2025
tank/projects@hourly-2025-12-24-12:00  Wed Dec 24 12:00 2025
cr0x@server:~$ sudo zfs rollback -r tank/projects@hourly-2025-12-24-10:00

Інтерпретація: Це повертає датасет до стану снапшота, і -r також відкотить залежні клони/снапшоти при потребі. Робіть так лише коли підтвердили масштаб компрометації і готові втратити зміни після обраного часу снапшота.

Завдання 11: Якщо відкат занадто руйнівний — змонтуйте снапшот для читання і скопіюйте

cr0x@server:~$ sudo mkdir -p /mnt/projects-restore
cr0x@server:~$ sudo mount -t zfs tank/projects@hourly-2025-12-24-10:00 /mnt/projects-restore
cr0x@server:~$ sudo rsync -a /mnt/projects-restore/ /srv/projects/
cr0x@server:~$ sudo umount /mnt/projects-restore

Інтерпретація: Це повільніше, але безпечніше для часткових відновлень та розслідувань. Можна селективно відновити, не відмотуючи всю хронологію датасету.

Завдання 12: Виявляти підозрілий тиск на запис за допомогою метрик ZFS та ОС

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.41T  5.22T    220   4100   25.3M  620M
  raidz2    3.41T  5.22T    220   4100   25.3M  620M
    sda         -      -     40    690   4.3M  102M
    sdb         -      -     42    710   4.5M  104M
    sdc         -      -     46    680   4.8M  101M
    sdd         -      -     45    705   4.7M  105M

Інтерпретація: Раптовий сплеск записів з великою кількістю дрібних операцій узгоджується з масовою перезаписом/шифруванням файлів. Це не доказ, але привід перевірити журнали SMB, списки процесів і недавній «червоний» churn файлів.

Завдання 13: Аудит того, хто може змінювати властивості ZFS (делегація)

Якщо ваша операційна модель дозволяє, делегуйте обмежені права ZFS замість широкого доступу root.

cr0x@server:~$ sudo zfs allow tank/releases
---- Permissions on tank/releases ---------------------------------------
Local+Descendent permissions:
user backupop create,mount,snapshot,send,receive

Інтерпретація: Делегування може зберегти функціональність оператора бекапів без передачі ключів для знищення світу. Якщо всі — root, readonly — це прикрий валик, а не бар’єр.

Завдання 14: Зробити наслідування readonly для всього піддерева

cr0x@server:~$ sudo zfs set readonly=on tank/archive
cr0x@server:~$ sudo zfs create tank/archive/2024
cr0x@server:~$ sudo zfs get readonly tank/archive/2024
NAME              PROPERTY  VALUE  SOURCE
tank/archive/2024 readonly  on     inherited from tank/archive

Інтерпретація: Наслідування запобігає «ми забули заблокувати новий датасет». У продакшні ворог — часто не злоба, а дрейф.

Завдання 15: Підтвердити видимість для клієнтів через NFS/SMB (швидка перевірка)

З боку сервера ви можете перевірити прапори монтування. Точний вивід залежить від дистрибутива і налаштувань.

cr0x@server:~$ mount | grep '/srv/releases'
tank/releases on /srv/releases type zfs (ro,xattr,posixacl)

Інтерпретація: Ви хочете бачити ro. Якщо вказано rw, ви не досягли readonly на рівні монтування, незалежно від того, що ви вважали встановленим.

Три міні-історії з корпоративного життя

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

Компанія мала охайну теорію: «NAS в безпеці, бо лише файловий сервер може писати в нього». На дошці це було правдою. Файловий сервер експортував SMB-шари, користувачі підключали диски, а бекенд зберігання був «внутрішнім». Люди люблять слово «внутрішній». Воно звучить як зачинені двері. Зазвичай це — ширма.

Одного понеділка молодший адміністратор повідомив, що проектний шар «поводиться дивно». Файли не відкривалися. Служба підтримки помітила хвилю тикетів: файли Excel не завантажувалися, PDF показували помилки, а «в кожній папці з’явився новий файл з інструкціями». Звичайний інцидентний ритм почався — ізоляція, комунікація, триаж. Потім хтось поставив питання, яке ніхто не хоче ставити: «А бекапи в порядку?»

Бекапи існували. Вони також були змонтовані у режимі запису на тому самому файловому сервері, бо «так простіше відновити». Шкідливому ПО байдуже, що простіше відновити. Йому важливо — що простіше знищити. Рансомвар приземлився на робочій станції, захопив сесію користувача, перемістився латерально з кешованими обліковими даними і використав SMB як призначено: швидке аутентифіковане файлове API. Він зашифрував шар, а потім расслаблено зайшов у змонтований шлях бекапу і зробив те саме.

Хибним припущенням було не «у нас є бекапи». Хибним — «бекапи в безпеці, бо вони бекапи». Бекапи безпечні лише тоді, коли їх важче змінити, ніж продакшн-дані. Після постмортему (того, що читається як повість жахів) вони перебудували ціль бекапу як репліку ZFS, отриману в немонтовані датасети і позначену readonly. Відновлення стало трохи менш зручним. Виживання стало значно зручнішим.

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

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

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

Через три місяці їх вразив руйнівний скрипт, навіть не рансомвар: конвеєрний job з помилковою змінною шляху, що вирішився в корінь шару. Він почав чистити «старі файли». Почистив майже все. Команда потягнулася до снапшотів і виявила… небагато. Консолідований дизайн датасету означав, що природних кордонів не було. Сервісний обліковий запис pipeline мав права всюди, бо «йому потрібно доступатися до медіа». З меншим числом датасетів було менше можливостей застосувати різні політики, і з меншим числом снапшотів було менше точок відновлення.

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

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

Операційний урок: розклад даних — це розклад безпеки. Якщо ви прибираєте межі, щоб спростити, ви також прибираєте місця для захисних елементів.

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

Фінансова організація мала звичку, що здавалася майже старомодною: кожного кінця місяця вони «запечатували» датасет попереднього місяця. Це був окремий ZFS датасет на період обліку з передбачуваним іменем і чеклістом у ранбуку. Після закриття періоду датасет встановлювався в readonly, снапшотовувався і реплікувався на вторинну систему. Команда робила це як годинник, навіть коли ніхто не дивився.

Потім стався інцидент. Скомпрометований обліковий запис робочої станції почав шифрувати великий масив спільних папок. Це було швидко, агресивно і, як більшість рансомварів, байдуже до бізнес-календарів. Файловий сервер «загорівся». Моніторинг показав різкий підйом записних IOPS і латентності. Користувачі повідомляли про помилки доступу до файлів. Командир інциденту розпочав знайомий танець: ізолювати кінцеві точки, відключити акаунти, заблокувати SMB-сесії, зберегти докази.

Коли пил осів, погані новини були реальні: кілька активних датасетів були частково зашифровані. Гарні новини були діагностичні: усі запечатані датасети місяць-кінець були недоторканими. Не тому, що нападники були ввічливі, а тому, що ці датасети були readonly і шкідливе ПО не могло їх перезаписати. Дані місяця-кінець — те, що могло спричинити регуляторний хаос, якби були втрачені — були цілі і миттєво придатні до використання. Вони все ще мали безлад, але він був обмеженим.

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

Операційний урок: нудні рутинні практики рятують у критичний момент. Не тому, що вони красиві, а тому що вони відтворювані під стресом.

Швидкий план діагностики

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

Перше: підтвердити, чи спостерігається тиск на запис, метаданний churn чи фактичне примусове readonly

Перевірте I/O пулу: чи більшість — записи? Чи операції дрібні й численні?

cr0x@server:~$ sudo zpool iostat -v tank 1 3

Інтерпретація: Масові операції запису + висока пропускна здатність вказують на перезапис/шифрування або масове копіювання. Високі опси з низькою пропускною здатністю можуть бути метаданним churn (шторми перейменувань, дрібні файли).

Перевірте, чи цільові датасети readonly як очікувалося (і чи це унаслідування, чи локально):

cr0x@server:~$ sudo zfs get -r -o name,property,value,source readonly tank/projects tank/releases

Інтерпретація: Якщо «захищений» датасет показує readonly=off з джерелом local, коли ви очікували inherited або on, можливо, стався дрейф або зміна під час обслуговування.

Перевірте прапори монтування, щоб упевнитися, що ОС дотримується readonly:

cr0x@server:~$ mount | egrep '/srv/releases|/srv/backup-recv'

Інтерпретація: Ви повинні бачити ro для readonly датасетів. Якщо ні — вважайте їх «не захищеними».

Друге: ідентифікуйте датасет і клієнта, відповідального (або щонайменше корельованого)

Знайдіть, який датасет «гарячий»:

cr0x@server:~$ sudo zfs list -o name,used,refer,quota,reservation,mountpoint -S used | head

Інтерпретація: Швидкий ріст може вказувати на зашифрування, що створює нові файли, або на роботу, що скидає дані несподівано.

Перевірте статистику I/O по датасетах (Linux):

cr0x@server:~$ sudo zpool iostat -r -w tank 1 5

Інтерпретація: Шукайте тривалу записну пропускну здатність, несумісну зі звичними бізнес-патернами.

Корелюйте з SMB/NFS сесіями (приклади; ваші команди можуть відрізнятися):

cr0x@server:~$ sudo smbstatus -p | head
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
4123    jdoe         domain users  10.10.14.27 (ipv4:10.10.14.27:51234)      SMB3_11           -                    partial

Інтерпретація: Невелика кількість клієнтів, що завдають великої шкоди, — звичайна річ. Якщо ви бачите робочу станцію, яка не повинна торкатися шару — це зацепка.

Третє: вирішіть, чи ви у режимі «інцидент безпеки», чи «помилка продуктивності»

Симптоми перекриваються. Шифрування спочатку виглядає як проблема продуктивності. Помилки продуктивності іноді виглядають як рансомвар (високі IOPS, багато файлових операцій). Різниця — чи змінюється вміст даних несподівано і чи записи відкидаються через примусове readonly.

Швидкі відмінності:

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

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

Поширені помилки (симптоми + виправлення)

Помилка 1: «Readonly на датасеті означає, що снапшоти в безпеці»

Симптом: Ви встановили readonly=on, почуваєтеся впевнено, а потім виявляєте, що снапшоти зникли після інциденту.

Чому так: Видалення снапшотів не блокується датасетом readonly. Якщо нападник має адміністративний доступ до ZFS, він може знищити снапшоти або змінити властивості.

Виправлення: Використовуйте holds для ключових точок відновлення, обмежуйте права адміністрування ZFS і реплікуйте на ціль, де вхідні облікові дані нападника не існують.

Помилка 2: Увімкнення readonly для датасету з активним станом додатка

Симптом: Додатки починають падати з «Read-only file system», бази даних відмовляються стартувати, CI-пайплайни ламаються.

Чому так: Хтось застосував контроль без картування потоків даних.

Виправлення: Розділіть датасети: помістіть змінний стан додатка в записуваний датасет; опублікуйте артефакти в окремому readonly датасеті. Якщо необхідно тримати один датасет, не використовуйте readonly — застосуйте снапшоти і права замість нього.

Помилка 3: Припущення, що readonly поширюється всюди без перевірки наслідування

Симптом: Новостворений датасет під захищеним деревом записуваний.

Чому так: Він був створений в іншому місці і переміщений, або хтось локально встановив readonly=off на дочірньому датасеті, переважаючи наслідування.

Виправлення: Аудит з zfs get -r readonly і зверніть увагу на source. Для важливих дерев впровадьте стандарти через ранбуки і перевірки.

Помилка 4: Змонтовані репліки бекапів, які доступні та записувані з продакшн-ідентичностей

Симптом: Бекапи шифруються разом із продакшн-даними.

Чому так: Зручність: адміністратори монтують датасети бекапів, щоб відновлення було простим копіюванням файлів. Шкідливе ПО любить зручність.

Виправлення: Отримуйте репліки з zfs receive -u, тримайте їх за замовчуванням немонтованими і надавайте відновлення через контрольовані робочі процеси mount/clone.

Помилка 5: «Ми просто вимкнемо readonly під час деплойментів» без процесу

Симптом: Readonly залишається вимкненим після поспішної зміни, і ніхто не помічає до пізніше.

Чому так: Люди погано пам’ятають повернути замки під час пожеж.

Виправлення: Використовуйте скриптовану процедуру обслуговування, яка робить снапшот до/після і явно ставить readonly назад. Регулярно аудитуйте дрейф властивостей.

Помилка 6: Плутанина між файловими дозволами та ZFS readonly

Симптом: Користувач все ще може змінювати файли, хоча «ми заблокували», або легітимні записи падають несподівано.

Чому так: POSIX-дозволи/ACL і ZFS readonly — різні шари. Один контролює, хто може писати; інший контролює, чи хто-небудь взагалі може писати.

Виправлення: Використовуйте дозволи для нормального контролю доступу, а readonly — для цілей незмінності. Не намагайтеся замінити одне іншим.

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

Симптом: Додаток «лише читає», але все одно падає на readonly датасеті.

Чому так: Багато «читачів» пишуть кеші, лок-файли, тимчасові файли або оновлюють timestamps на місці.

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

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

Покроково: Впровадити readonly безпечно в продакшні (без руйнувань)

Класифікуйте датасети за поведінкою: active-write, published-read, archive, backup target.
Розділіть датасети там, де кордони неясні: не боріться з реальністю; створіть контрольні точки.
Виберіть один низькоризиковий датасет (наприклад, releases, installers, archives) і запустіть пілот readonly.
Зробіть снапшот перед зміною, щоб відкат був тривіальним.
Увімкніть readonly і перевірте на трьох рівнях: властивість ZFS, прапори монтування і поведінка клієнтів.
Оновіть ранбуки: як робити планові записи (режим обслуговування), хто погоджує і як знову замкнути.
Встановіть очікування моніторингу: помилки запису повинні сповіщати, але не викликати пейджинг всього офісу.
Додайте утримання снапшотів для критичних точок відновлення там, де доречно.
Побудуйте реплікаційну ціль, що отримує снапшоти немонтованими; позначте її readonly де можливо.
Обмежте, хто може перемикати readonly і хто може знищувати снапшоти; використовуйте делегацію, якщо це відповідає організації.
Тестуйте відновлення щоквартально: змонтуйте снапшот, скопіюйте або клон і перевірте, чи додатки читають.
Аудит дрейфу щомісяця: readonly, статус монтування, наявність снапшотів, свіжість реплікації.

Операційний чекліст: «Запечатати» датасет після публікації

Створіть снапшот з іменем події/часу.
Перевірте, що споживачі читають з правильного монтування.
Встановіть readonly=on.
Утримайте (hold) снапшот запечатування, якщо це ключова точка відновлення.
Реплікуйте на бекап/DR.
Занотуйте ім’я снапшота і статус реплікації в системі тикетів/журналі змін.

Операційний чекліст: Підозра на рансомвар у файлових шарах

Ізолюйте: відріжте SMB/NFS доступ для підозрілих клієнтів; деактивуйте підозрілі акаунти.
Збережіть: зробіть негайні снапшоти уражених датасетів (так, навіть якщо вони частково зашифровані).
Оцініть: ідентифікуйте найраніший «хороший» снапшот; перевірте цілісність снапшота і статус реплікації.
Вирішіть: відкат або селективне відновлення. Відкат швидкий; селективне відновлення безпечніше для часткового відновлення.
Відновіть: відновіть дані; поміняйте облікові дані; перевірте кінцеві точки; поновіть доступ поетапно.
Загартуйте: перемістіть довідкові й архівні дані в readonly датасети; забезпечте незмінність бекапів.

FAQ

1) Чи означає ZFS readonly те саме, що «імунітетне сховище»?

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

2) Якщо я встановлю датасет readonly, чи можу я все ще реплікувати в нього з допомогою zfs receive?

Зазвичай так. zfs receive працює на рівні ZFS, а не через змонтований файловий шлях. Readonly блокує звичайні файлові записи через монтування; він не обов’язково блокує адміністративні оновлення датасету, як отримання стріму. Протестуйте це у своєму середовищі і вважайте права реплікації привілейованою здатністю.

3) Чи захистить мене readonly, якщо сам сервер сховища скомпрометовано?

Не надійно. Якщо атакувальник має root і адміністративні можливості ZFS на хості сховища, він часто може переключити readonly назад у off і знищити снапшоти. Ваш захист тоді залежить від контролів поза цим хостом: окремі цілі бекапу, розділення доступу і, можливо, офлайн-копії.

4) Чи варто робити весь пул readonly?

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

5) Як робити легітимні оновлення в readonly датасеті?

Створіть процедуру обслуговування: снапшот, тимчасово встановіть readonly в off, виконайте контрольовані записи, знову встановіть readonly, зробіть ще один снапшот. Ключ — відтворюваність і аудит, а не геройські дії.

6) У чому різниця між readonly і налаштуванням дозволів/ACL для заборони запису?

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

7) Чи може рансомвар видаляти снапшоти з машини клієнта?

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

8) Чи варто монтувати репліки бекапів взагалі?

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

9) Чи впливає readonly на продуктивність?

Безпосередній вплив мінімальний. Більша історія продуктивності — архітектура, яку ви забезпечуєте: менше записів, менше оновлень метаданих і менше churn на захищених датасетах. Під час атаки readonly може покращити стан, заважаючи успішним руйнівним пікам запису (хоча спроби запису все одно споживатимуть ресурси).

10) Який найважливіший супутній контроль для readonly?

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

Висновок

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

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