Що робити, якщо до твого хостера прийшли

кдпв — Reuters

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

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

Модель погроз

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

Незалежно від сценарію розвитку подій, ваше основне завдання — зробити атаку надто складною і дорогою. Зазвичай є три основні варіанти загрози.

Офіційний

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

Зрідка, якщо дуже треба, представники правоохоронних органів приїжджають до ЦОДу особисто. Наприклад, коли у вас виділений сервер і дані звідти можна забрати тільки фізично.

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

Більше того, у більшості країн не можна просто так взяти і висмикнути обладнання, що працює. Наприклад, у Росії до кінця 2018 року, згідно зі статтею 183 КПК України, частина 3.1, гарантувалося, що при виробництві виїмки, вилучення електронних носіїв інформації провадиться за участю фахівця. За клопотанням законного власника вилучених електронних носіїв інформації або власника інформації, що на них міститься, фахівцем, який бере участь у виїмці, у присутності понятих з вилучених електронних носіїв інформації здійснюється копіювання інформації на інші електронні носії інформації.

Потім, на жаль, цей пункт із статті прибрали.

Таємний та неофіційний

Це вже територія діяльності спеціально навчених товаришів із NSA, FBI, MI5 та інших трилітерних організацій. Найчастіше законодавство країн передбачає вкрай широкі повноваження для таких структур. Більше того, майже завжди є законодавча заборона на будь-яке пряме та опосередковане розголошення самого факту співпраці з подібними силовими відомствами. У Росії є аналогічні правові норми.

У разі подібної загрози вашим даним їх майже напевно витягнуть. При цьому, крім простого вилучення, можуть використовуватися весь неофіційний арсенал бекдорів, уразливостей нульового дня, вилучення даних з оперативної пам'яті вашої віртуальної машини та інші радості. Хостер при цьому буде зобов'язаний максимально допомагати спеціалістам силових структур.

Несумлінний співробітник

Не всі люди однаково гарні. Хтось з адмінів ЦОДу може вирішити підзаробити та продати ваші дані. Далі розвиток подій залежить від його повноважень та доступів. Найнеприємніше, що адміністратор з доступом до консолі віртуалізації має повний контроль за вашими машинами. Завжди можна зняти снапшот разом з усім вмістом оперативної пам'яті і далі його вивчати неквапливо.

VDS

Отже, у вас є віртуальна машина, яку вам видав хостер. Як ви можете організувати шифрування, щоб убезпечити себе? Насправді, ніяк. Більш того, навіть чужий dedicated-сервер може виявитися в результаті віртуальною машиною, в яку прокинуті необхідні пристрої.

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

Плюс, у момент, коли віртуальна машина запущена та виконує якісь дії, всі зашифровані томи перебувають у доступному стані, інакше ОС просто не зможе з ними працювати. Це означає, що маючи доступ до консолі віртуалізації, ви завжди можете зняти снапшот машини, що працює, і витягти всі ключі з оперативної пам'яті.

Багато вендори робили спроби організувати апаратне шифрування RAM для того, щоб навіть хостер не мав доступу до цих даних. Наприклад, технологія Intel Software Guard Extensions, яка організовує області у віртуальному адресному просторі, захищені від читання та запису ззовні цієї області іншими процесами, включаючи ядро ​​операційної системи. На жаль, ви не зможете повноцінно довіритись цим технологіям, так як ви будете обмежені своєю віртуальною машиною. До того ж вже існують готові приклади. успішної атаки на цю технологію. І все ж, шифрування віртуальних машин не таке безглуздо, як може здатися.

Шифруємо дані на VDS

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

• Якщо на запит хостер передасть “холодний” образ вашої віртуальної машини, то ви у відносній безпеці. Це найчастіший сценарій.
• Якщо хостер віддасть повний снапшот машини, що працює, то все досить погано. Всі дані будуть змонтовані у системі у відкритому вигляді. Крім того, з'явиться можливість поритися в RAM у пошуках приватних ключів тощо.

За замовчуванням, якщо ви розгорнули ОС з ванільного образу, хостер не має root доступу. Завжди можна примонтувати носій із rescue-образом та поміняти пароль від root, зробивши chroot в оточення віртуальної машини. Але це вимагатиме перезавантаження, що буде помічено. Плюс всі примонтовані зашифровані розділи будуть закриті.

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

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

Замовляємо машину

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

Класичний dm-crypt всього розділу не злетів. За замовчуванням диск віддається одним шматком, з root на весь розділ. Зменшувати розділ з ext4 на примонтованому root – це практично гарантована цегла замість файлової системи. Я скуштував) Бубен не допоміг.

Створюємо криптоконтейнер

Тому не будемо шифрувати розділ повністю, а використовуємо файлові криптоконтейнери, а саме аудит і надійний VeraCrypt. Для наших цілей цього достатньо. Для початку витягуємо та встановлюємо пакет із CLI-версією з офіційного сайту. Можете заразом перевірити підпис.

wget https://launchpad.net/veracrypt/trunk/1.24-update4/+download/veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
dpkg -i veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb

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

veracrypt -t -c ~/my_super_secret

Тепер давайте встановимо Nginx, примонтуємо контейнер і заллємо в нього секретну інформацію.

mkdir /var/www/html/images
veracrypt ~/my_super_secret /var/www/html/images/
wget https://upload.wikimedia.org/wikipedia/ru/2/24/Lenna.png

Трохи виправимо /var/www/html/index.nginx-debian.html, щоб отримати потрібну сторінку і можна перевіряти.

Підключаємося та перевіряємо

Контейнер примонтований, дані доступні та віддаються.

А ось тут машина після перезавантаження. Дані надійно лежать у ~/my_super_secret.

Якщо дуже потрібно і хочеться хардкору, то можна зашифрувати всю ОС, щоб при перезавантаженні вона вимагала підключення по ssh та введення пароля. Цього також буде достатньо у сценарії простого вилучення “холодних даних”. Ось інструкція з використанням dropbear та віддаленим шифруванням дисків. Хоча у випадку VDS це складно та надмірно.

Голий метал

Не так просто поставити власний сервер у датацентр. Чужий dedicated може виявитися віртуальною машиною, куди прокинуті всі пристрої. Але щось цікаве щодо захисту починається тоді, коли у вас з'являється можливість розмістити в датацентрі свій довірений фізичний сервер. Тут вже можна на повне зростання використовувати традиційний dm-crypt, VeraCrypt або будь-яке інше шифрування на ваш вибір.

Треба розуміти, що з реалізації тотального шифрування сервер зможе самостійно піднятися після ребута. Потрібно буде піднімати з'єднання до локального інтерфейсу IP-KVM, IPMI або іншого аналога. Після чого ми вручну вводимо майстер-ключ. Схема виглядає так собі з погляду безперервності і стійкості до відмови, але особливих альтернатив тут немає, якщо дані настільки цінні.

NCipher nShield F3 Hardware Security Module

М'якший варіант передбачає, що дані зашифровані, а ключ знаходиться безпосередньо в самому сервері в спеціальному HSM (Hardware Security Module). Як правило, це дуже функціональні пристрої, які не тільки забезпечують апаратну криптографію, але й мають механізми виявлення спроби фізичного злому. Якщо хтось почне колупати ваш сервер болгаркою, то HSM із незалежним джерелом живлення скине ключі, які зберігає у своїй пам'яті. Атакуючого дістанеться зашифрований фарш. При цьому перезавантаження може відбуватися автоматично.

Видалення ключів - набагато швидший і гуманніший варіант, ніж активація термітної шашки або електромагнітного розрядника. За такі пристрої вас дуже довго битимуть сусіди по стійці в датацентрі. Тим більше, що у разі використання TCG Opal 2 шифрування на самих носіях ви практично не відчуваєте жодного верхівки. Все це відбувається прозоро для ОС. Щоправда, при цьому треба довіряти умовному Samsung та сподіватися, що там чесний AES256, а не банальний XOR.

При цьому не слід забувати, що всі зайві порти повинні бути відключені фізично або тупо залиті компаундом. Інакше ви даєте можливість атакуючим провести DMA-атаки. Якщо у вас є PCI Express або Thunderbolt, що стирчить назовні, включаючи USB з його підтримкою - ви вразливі. Атакуючий зможе через ці порти провести атаку та отримати прямий доступ до пам'яті з ключами.

У дуже витонченому варіанті атакуючий зможе провести cold boot атаку. При цьому він просто заливає хорошу порцію рідкого азоту у ваш сервер, грубо витягує заморожені планки пам'яті та знімає з них дамп з усіма ключами. Часто для проведення атаки досить звичайного спрею, що охолоджує, і температури в районі -50 градусів. Є й більш обережний варіант. Якщо ви не відключили завантаження із зовнішніх пристроїв, то алгоритм атакуючого буде ще простіше:

1. Заморозити планки пам'яті без відкриття корпусу
2. Підключити свою завантажувальну флешку
3. Спеціальними утилітами зняти дані з оперативної пам'яті, які пережили перезавантаження завдяки заморожуванню.

Розділяй і володарюй

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

Або можна розглянути зовсім чистий варіант - End-to-End шифрування. Звичайно, це виходить за межі ТЗ і не передбачає виконання обчислень на стороні віддаленої машини. Тим не менш, це цілком прийнятний варіант, якщо йдеться про зберігання та синхронізацію даних. Наприклад, це дуже зручно реалізовано в тому ж Nextcloud. При цьому синхронізація, версіонування та інші плюшки серверної частини нікуди не подінуться.

Разом

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

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

Більш менш надійний варіант - використання свого залізного сервера.

А хостеру все одно доведеться так чи інакше довіряти. У цьому тримається вся промисловість.

Джерело: habr.com