Шифрование диска VPS с помощью LUKS

Шифрование — не универсальная настройка приватности. Оно отвечает ровно на один вопрос: может ли кто-то прочитать эти блоки без ключа? Всё остальное — знает ли кто-то, что вы арендовали сервер, можно ли привязать трафик к вам, может ли суд что-либо потребовать, — находится за пределами этого вопроса.

На VPS LUKS действительно защищает от следующего:

• Списанное и вышедшее из строя оборудование. NVMe-накопители заменяют. Гарантированное стирание неисправного устройства возможно не всегда — иногда оно уже настолько нерабочее, что контроллер вообще не принимает команды, а покидает стойку оно всё равно.
• Офлайн-образ. Том, скопированный при выключенном сервере — во время изъятия, миграции, ошибки — это шифротекст, и он остаётся шифротекстом.
• Резервные копии и снапшоты, покидающие сервер. Всё, что покидает машину, покидает её зашифрованным, если снято с блочного уровня ниже вашего контроля, и должно шифроваться на стороне клиента, если снято выше него.
• Остаточные блоки. Когда вы уничтожаете сервер, лежащие в основе экстенты рано или поздно используются повторно. Шифрование превращает эти остатки в шум, а не в данные.

Оно не защищает работающую машину. Пока ваш сервер включён, мастер-ключ находится в памяти ядра, и любой, кто способен снять дамп этой памяти, прочитает ваш диск независимо от парольной фразы. На арендованной инфраструктуре это оператор гипервизора. Мы говорим об этом в нашем уведомлении о конфиденциальности и повторим здесь: ни одна функция шифрования диска ни у одного провайдера, включая нас, этого не меняет, а любой провайдер, утверждающий обратное, описывает маркетинг, а не криптографию.

Прежде чем открывать терминал, выберите модель. Они сильно различаются по трудозатратам, и большинству людей нужна первая.

1. Зашифрованный том с данными. Система загружается как обычно, без шифрования; одно дерево каталогов — maildir, база данных, архив — находится внутри контейнера LUKS, который вы открываете вручную после каждой загрузки. Десять минут работы, режим восстановления не нужен, и вы не рискуете сами себя запереть снаружи. Если вас волнует один набор данных, а не вся машина целиком, остановитесь на этом варианте: вы получаете большую часть пользы почти без хрупкости остальной схемы. Именно этот подход мы рекомендуем на странице про анонимный почтовый сервер.

2. Зашифрованный корневой том с удалённой разблокировкой. Всё, кроме /boot, зашифровано, и при каждой загрузке initramfs останавливается и ждёт, пока вы не подключитесь по SSH и не введёте парольную фразу. Именно эту модель дальше выстраивает всё остальное руководство. В первый раз она стоит около часа, а затем — одна SSH-команда при каждой перезагрузке; и это единственная модель, при которой под защитой оказываются ещё и логи, кэши пакетов, история команд оболочки и swap — то есть места, куда данные утекают без чьего-либо осознанного решения.

3. Зашифрованный корневой том, который разблокируется сам через контролируемый вами сервер ключей. То же самое, что модель 2, но Clevis получает материал для разблокировки от сервера Tang на машине в другой юрисдикции, поэтому перезагрузки проходят без участия человека. Компромисс здесь чёткий, и его стоит понимать: теперь сервер может расшифровать сам себя, пока ваш сервер ключей это разрешает, а значит, вы не убрали секрет, а лишь переместили его — но взамен получили удалённый выключатель. Подробнее — дальше.

Многие хостинг-провайдеры рекламируют «шифрование данных в состоянии покоя» как галочку в списке функций. Стоит уточнить, что обычно скрывается за этой фразой, — потому что за ней стоят две совершенно разные вещи.

Шифрование с ключом, который хранит провайдер, защищает только от кражи накопителя и больше ни от чего. Если провайдер может загрузить ваш сервер, ничего у вас не спрашивая, значит, он может и расшифровать ваш сервер, ничего у вас не спрашивая, — как и любой, кто способен принудить этого провайдера. Это реальная защита от кражи и чисто декоративная — от судебного запроса.

Шифрование с ключом, который храните вы, — это единственный вариант, имеющий смысл, и он по своей конструкции делает необслуживаемую перезагрузку невозможной. Это не недостаток, который стоило бы устранить, — это и есть то свойство, ради которого всё затевается.

Мы предоставляем только второй вариант, без предварительной настройки, и решение остаётся за вами. То немногое, что храним мы, — задокументировано и ограничено: пароли root на серверах хранятся зашифрованными по AES-256-CBC на уровне строк базы данных, мы не ведём логи потоков трафика и не снимаем копии пакетов, а подписанное уведомление о неполучении судебных предписаний публикуется по расписанию. Ничто из этого не заменяет ваш собственный ключ — это лишь то немногое, за что в ответе мы.

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

Шифр. aes-xts-plain64 с 512-битным ключом — это значение по умолчанию, и оно же правильный выбор: 512 бит — это два 256-битных ключа, то есть фактически AES-256 в режиме XTS, а AES-NI есть на каждом процессоре, который используем мы. На машине без аппаратного ускорения AES вы предпочли бы xchacha20,aes-adiantum-plain64, но это не наше оборудование — и, вероятно, не ваше.

Получение ключа. LUKS2 по умолчанию использует Argon2id, который намеренно требователен к памяти. cryptsetup при форматировании прогоняет тест производительности вашей машины и выбирает объём памяти исходя из видимого ему ОЗУ — и вот здесь кроется ловушка, из-за которой чаще всего появляются обращения вида «мой зашифрованный сервер не загружается»: у initramfs доступной памяти меньше, чем у уже запущенной системы, и если вы отформатировали том в среде восстановления с большим объёмом ОЗУ, чем у целевого тарифного плана, разблокировка при загрузке может завершиться сбоем или быть принудительно остановлена. Задайте значение явно. Один гигабайт памяти для Argon2 — серьёзная нагрузка для атакующего и вполне посильная для тарифа S1 с 4 ГБ:

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory указывается в КиБ, поэтому 1048576 — это 1 ГиБ. После форматирования проверьте, что именно попало в заголовок, командой cryptsetup luksDump /dev/vda2 — раздел слота ключа выводит объём памяти и число итераций, которые будут использоваться, и один раз прочитать это дешевле, чем столкнуться с неудачной загрузкой.

Парольная фраза. Argon2 покупает время против слабой парольной фразы, но не спасает её. Используйте diceware-фразу минимум из шести слов. Это единственный секрет во всей системе, и никакая функция получения ключа не компенсирует плохо выбранную фразу.

Загрузка Linux с зашифрованным корнем сталкивается с проблемой курицы и яйца: ядро и initramfs должны загрузиться раньше, чем что-либо сможет запросить парольную фразу, — а сами они лежат на диске, который вы как раз пытаетесь разблокировать. Стандартное решение — небольшой незашифрованный раздел /boot, где хранятся ядро, initramfs и загрузчик. Всё остальное отправляется внутрь LUKS.

Затем initramfs останавливается и запрашивает парольную фразу. На ноутбуке вы просто вводите её. А на сервере в трёх тысячах километров от вас нужно одно из двух:

• Консоль. У каждого сервера в панели управления есть консоль noVNC, и она работает — но нажатия клавиш проходят через нашу инфраструктуру, а именно её ваш ключ и должен исключить из круга доверия. Годится для разового восстановления, но не как постоянная практика.
• SSH-сервер внутри initramfs. dropbear-initramfs весит около 200 КБ, поднимает сеть, слушает выбранный вами порт, принимает один из ваших публичных ключей и сразу переносит вас в приглашение разблокировки. Парольная фраза шифруется от начала до конца — от вашего ноутбука до initramfs. Это и есть правильный ответ.

Здесь есть две детали, на которых люди спотыкаются. У Dropbear в initramfs свой собственный хост-ключ, поэтому его отпечаток отличается от отпечатка вашего обычного SSH-демона, — это ожидаемо и не является атакой «человек посередине»; он заслуживает отдельного файла known_hosts, а не привычки не глядя вводить yes. И имя интерфейса должно быть верным: виртуальные сетевые карты virtio в Debian 13 обычно называются ens3 или enp1s0, а не eth0. Проверьте его командой ip -br link, прежде чем писать конфигурацию, — ошибка здесь означает initramfs без сети и поездку к консоли.

Если машина должна возвращаться в строй самостоятельно — после обновления ядра, перезагрузки хоста, сбоя питания — ввод парольной фразы вручную не подходит. Clevis привязывает слот ключа LUKS к внешней политике, а Tang — это крошечный сервер обмена ключами, реализующий простейшую полезную такую политику.

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

При загрузке initramfs выполняет обмен по протоколу McCallum-Relyea с Tang и восстанавливает ключ так, что сервер Tang никогда не узнаёт ни сам ключ, ни парольную фразу. Свойства этой схемы стоит сформулировать точно:

• VPS расшифровывает себя только пока может достучаться до Tang. Выключите Tang или смените его ключи — и следующая загрузка застрянет намертво. Это настоящий удалённый выключатель — необычное и полезное свойство.
• Tang не должен находиться в публичном интернете. Открывайте к нему доступ через WireGuard или в виде скрытого сервиса Tor; сторону туннеля мы разбираем в руководстве по WireGuard.
• Разместите Tang в другой юрисдикции, чем данные. Наши страницы юрисдикций существуют именно для такого разделения.
• Держите парольную фразу в ещё одном слоте ключа. Clevis — это уровень удобства, а не единственный способ попасть внутрь.

Отдавайте себе отчёт в том, что вы построили: необслуживаемая машина хранит собственный ключ через посредника, поэтому противник, который захватит работающий VPS или сможет достучаться до вашего сервера Tang, получит данные. Это реальное ослабление по сравнению с парольной фразой, которая хранится только у вас в голове. Выбирайте эту схему, когда доступность важнее последней капли секретности, а не по умолчанию.

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

• Swap. Всё, что находится в оперативной памяти, может быть выгружено на диск — ключи, тела сообщений, расшифрованные буферы. Если swap находится внутри зашифрованного тома в виде файла подкачки, он под защитой. Отдельный раздел подкачки — нет, если только вы не добавите его в /etc/crypttab со случайным ключом, который меняется при каждой загрузке: cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256. На VPS файл подкачки проще, и предпочитать раздел нет никаких причин.
• /tmp. Смонтируйте его как tmpfs (tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0), чтобы он вообще не касался диска. Заодно и быстрее.
• Гибернация. Записывает содержимое всей оперативной памяти, включая ваш мастер-ключ, на устройство подкачки. Не включайте её. На наших образах она по умолчанию отключена.
• Незашифрованный /boot. Ядра, образы initramfs и конфигурация GRUB доступны для чтения и, что важнее, для записи — любому, у кого есть офлайн-доступ к диску. LUKS даёт вам конфиденциальность, а не целостность загрузки. Если ваша модель угроз включает вмешательство в загрузчик, одно только шифрование этого не поймает — фиксируйте хеши /boot после каждого обновления ядра и проверяйте их извне, либо сознательно принимайте этот пробел.
• Существующие снапшоты и старые тома. Шифрование, включённое сегодня, никак не помогает образу, снятому вчера. Если сервер хоть раз работал незашифрованным с данными, которые вам важны, считайте эти данные раскрытыми и обновите всё, что из них производно.

Накладные расходы достаточно малы, чтобы не быть решающим фактором, — но они не равны нулю. Измеряйте, а не гадайте:

cryptsetup benchmark

На наших узлах EPYC aes-xts с 512-битным ключом показывает несколько гигабайт в секунду на ядро — с большим запасом выше того, что вообще может потребовать один том NVMe. Реально проявляющаяся стоимость — это задержка и нагрузка на процессор при мелких случайных записях, а не пропускная способность.

На NVMe важны два флага LUKS2 — там очереди задач dm-crypt в ядре добавляют задержку, а не убирают её. Задайте их и закрепите в заголовке:

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

Третий флаг, --allow-discards, пропускает TRIM к нижележащему устройству. Он сдерживает усиление записи на протяжении всей жизни тома ценой того, что становится видно, какие блоки не используются, — а это раскрывает примерный размер и структуру ваших данных любому, кто читает диск напрямую. Включайте его для сервера общего назначения; оставляйте выключенным, если сам факт, что том заполнен на 3%, для вас чувствителен. Универсально правильного ответа здесь нет — есть только решение, которое стоит принять осознанно.

Заголовок LUKS занимает примерно 16 МБ в начале раздела и хранит зашифрованные копии мастер-ключа. Повредите его — опечатка в dd, инструмент разметки, который «услужливо» перезаписывает начало устройства — и всё, что находится за ним, потеряно безвозвратно. Службы восстановления не существует. У нас нет копии.

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

О резервной копии заголовка стоит сказать две вещи. Во-первых, она так же чувствительна, как и сам диск: в ней содержатся слоты ключей, поэтому старый заголовок, восстановленный уже после смены парольной фразы, охотно примет старую фразу обратно. Храните её так же, как храните парольную фразу, и уничтожайте устаревшие копии при каждой смене. Во-вторых, LUKS2 даёт вам 32 слота ключей — используйте как минимум два, а запасным сделайте длинную случайную парольную фразу, хранящуюся не там же, где основная. Это предотвращает скучный, но частый сценарий отказа: вы меняете парольную фразу, дважды одинаково ошибаетесь при вводе — и обнаруживаете это не при следующем входе, а только при следующей перезагрузке.

Позаботьтесь и о пути назад. Режим восстановления загружает сервер с нашего ISO-образа с уже добавленными вашими SSH-ключами, не трогая зашифрованный том, а значит, вы можете выполнить cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt и починить сломанный crypttab или неисправный initramfs, не потеряв данные. Проверьте это один раз осознанно, пока всё ещё в порядке.

Самое полезное, что может сделать такое руководство, — обозначить собственные границы.

• Оно не защищает работающий сервер. Мастер-ключ находится в памяти ядра с момента разблокировки и до выключения. Доступ к памяти на уровне гипервизора сводит его на нет. Шифрование памяти — AMD SEV-SNP и аналогичные технологии — единственная технология, которая существенно это меняет, а мы сегодня её не предоставляем; провайдер, утверждающий, что ваша работающая виртуальная машина непрозрачна для него без SEV, ошибается или лжёт.
• Оно не делает вас анонимным. У зашифрованного диска в Zürich всё равно есть IP-адрес, история платежей и SSH-сессия, начавшаяся откуда-то. Это отдельная проблема, и мы разобрали типичные провалы в материале об ошибках, которые вас деанонимизируют.
• Оно не меняет того, что может предписать суд. Юрисдикция определяет принуждение; шифрование определяет читаемость. В некоторых юрисдикциях вас лично могут обязать раскрыть парольную фразу. Наше руководство о юридических запросах описывает, что мы делаем, а что — нет.
• Оно не переживёт утраченную парольную фразу. Так задумано, и это стоит повторить: обращение в поддержку с просьбой помочь приходит примерно раз в месяц, и ответ всегда один и тот же.
• Оно не подтверждает подлинность цепочки загрузки. Конфиденциальность — это не целостность. /boot доступен для чтения и изменения в офлайне.

Что оно действительно делает — так это убирает целый класс уязвимостей: всё, что происходит с диском, пока он не работает, а это большая часть того, что вообще с дисками происходит. Это стоит потраченного часа. Сочетайте это с регистрацией без KYC, оплатой через Monero и осознанно выбранной юрисдикцией — каждый слой закрывает свой сбой. Ни один из них не закрывает их все.