Как обеспечить шифрование nfsroot при загрузке бездисковых серверов?

Простите за оффтопик, но, какого размера должен быть паяльник?

Если у вас nfs, ну так доделайте kerberos+nfs. Используйте rootfs, которую можно хоть в интернет выкладывать, монтируйте его в режиме «только чтение», а важные части монтируйте с шифрованием через kerberos+nfs. Вам нужно только решить как передавать на сервера кейтабы для получения тикета kerberos.

Не получится. Если использовать «публичный» rootfs, то откуда брать ключи для расшифровки важных частей.
Можно, конечно, встроить всю rootfs в initramfs, но это лишний расход ОЗУ. Также не получится сделать дедупликацию директорий (в основном /usr) для нескольких серверов.
Основательно прошерстив сеть, обнаружил что pivot_root всё же не останавливает процессы при смене корня (согласно документации). По switch_root не нашел такой информации, но учитывая что он удаляет старый корень, скорее всего процессы он останавливает.
Кто подскажет pivot_root сохранит процесс туннеля при переключении корня на nfsroot?

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

Т.е. имхо можно скажем делать в качестве ключа связку из данных железа и выхлопа ps при загрузке, и скажем чексуммы пары важных бинарников (при апдейте будет ппц, но апдейт вообще вручную надо делать для таких систем). Но в любом случае если у человека есть немного мозга, то он в итоге распарсит полученную цепочку действий и додумается как ее обойти.

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

Возможно, имеет смысл подойти с другой стороны? Через нетфильтр организовать временное окно для создание новых подключений по порту nfs? Насколько я помню, после подключения он уже не разрывает соединение, соотв. ctstate NEW на этом порту у него появляться не должен. Естественно, на этом сервере не должно быть других экспортов nfs кроме рутфс (блокировать то будем порт сервера nfs для всех экспортов).

Т. е. создать систему, в которой не зная пароля админа сервера вы не можете в неурочное время запустить бездисковые сервера. Вряд ли, даже имея физический доступ, кто-то полезет экспериментировать с серверами, когда рядом бегает админ...

Но это исключительно «мысли вслух», сам ничего подобного я не делал у себя. :-)

Вряд ли, даже имея физический доступ, кто-то полезет экспериментировать с серверами, когда рядом бегает админ

а если админ рядом не бегает? удаленный филиал, облако, колок. Но идея здравая. Хотя имхо если рядом нет админа, то главное - чтоб сервер начал всеми своими лампами/почтами/смс-шлюзами кричать что что-то не так.

Но идея правда здравая. Хотя если сеть - самоорганизующийся кластер с возможностью любой ноды начать интеграцию с любой другой, а не только с центрального мастера...

Главная цель - защитить данные, если злоумышленник (конкурент) целенаправленно желает их получить. Предполагается что он получил доступ к сети (посредством свободного rj45 в стене). Получив максимум информации (пароли, ключи), он планирует остановить работу предприятия изъяв сервера (в сговоре с правоохранительными органами). После изъятия серверов он может спокойно работать с данными (базы клиентов, технологические разработки, ключи клиент-банка).

Таким образом:
1. Выключение серверов при изъятии обеспечивается физическими датчиками на дверях серверной и шкафа. Не будем вдаваться в подробности, тут каждый обеспечивает физическую безопасность как хочет. Сервера изымут, если захотят - факт.
2. Сеть защищается с помощью туннеля (ipsec\openvpn). В том числе NFS.
3. Загрузка серверов (kernel, initramfs) защищается сертификатами с помощью iPXE.
4. В initramfs происходит подключение к сети (запуск ipsec/openvpn демона) и монтирование nfsroot.
Но при смене корня фс с помощью switch_root, все процессы убиваются, в том числе демон туннеля.

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

согласен с каждым пунктом. но стяжки и газовый ключ проще и надежнее.

Ну будет вам, мы же не в 90-х давно. Обычно, в таких случаях («в сговоре с правоохранительными органами») на админа заводят уголовное дело... и все «решается» мирно, тихо и незаметно.

Вижу 2 неплохих варианта против давления на админа:
1 - не держать админа в офисе (работа на дому или в другом офисе на другом конце города), приезжает только если нужно обслуживать железо. Вообще не оформлять.
2 - если и держать рядом, то в штате называть бухгалтером или менеджером каким-то. Ну и убрать из его обязанностей эникейство всякое, чтобы коллеги не сдали.

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

А что если использовать разделение секрета? Я бы сказал, что это вообще единственный верный способ. Чтобы не было никакого админа/рута/..., который бы мог всё единолично без ведома. А чтобы несколько человек было ответственно (пусть и без глубокого знания, просто для контроля).

Какой туннель возможно поднять в initramfs?

Абсолютно любой, хоть openvpn. initramfs - это точно такая же ФС, как и любая другая. В общем-то, в неё можно вообще весь линукс положить и пользоваться как обычной ФС без перехода на другую ОС в процессе загрузки. Лично я бы рекомендовал использовать ipsec (возможно с nat-t) + NFS из-за высокой производительности, простоты настройки и минимальных задержек. Что касается kerberos и NFS-шифрования, то открещивайтесь всеми руками: там не весь поток шифруется, при определённом ответе сервера можно внезапно перейти в незашифрованный режим, а сам керберос - это просто ппц адское творение, не говоря уже его интеграции с NFS.

Отдельно выделяется слабый (мало жрущий электричества) сервер (atom какой-то) с полностью зашифрованным rootfs (/boot раздел с ключем находится на извлекаемой после загрузки флешке), на котором хранятся ядра, initramfs и ключи бездисковых серверов. Также на нём установлен web-сервер который передаёт ядро только при наличии клиентского сертификата. Вся сеть завёрнута в шифрованый туннель (ipsec или openvpn).

А почему бездисковые? Можете поставить диски без LUKS-заголовков, их вместе с initrd перевадать. Если кто-то будет анализировать диски, то там будет белый шум, ничего не докажут. Ещё есть такая штука, как TPM. И вот перед тем, как давать доступ к LUKS-ключам или NFS удалённым серверам, не мешало бы в созданном зашифрованном канале, попросить удалённый сервер нам что-нибудь подписать при помощи TPM. Это значительно повысит безопасность.

А что если использовать разделение секрета? Я бы сказал, что это вообще единственный верный способ. Чтобы не было никакого админа/рута/..., который бы мог всё единолично без ведома. А чтобы несколько человек было ответственно (пусть и без глубокого знания, просто для контроля).

Ага. Называется зашифрованный ключ+пароль от него. Умеют все современные системы шифрования.

3. Загрузка серверов (kernel, initramfs) защищается сертификатами с помощью iPXE.

TPM обязательно, если такая паранойя.

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

IPSec может работать на уровне ведра, а вообще свитчрут делать не обязательно, можно сделать просто chroot.

Предполагается что он получил доступ к сети (посредством свободного rj45 в стене)

Идиотизм. IPSec + VPN&Radius.

Не получится. Если использовать «публичный» rootfs, то откуда брать ключи для расшифровки важных частей.

Пфф, используйте curl + https или вообще поднимайте из initramfs sshd и подключайтесь туда с деплой-сервера.

Кто подскажет pivot_root сохранит процесс туннеля при переключении корня на nfsroot?

Тупо не убивайте процесс и всё. Если он не открывает дескрипторы файлов, то ему пофиг будет. Или chroot для основной ФС.

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

man TPM. Такой взрослый, но такой глупый.

Т.е. имхо можно скажем делать в качестве ключа связку из данных железа и выхлопа ps при загрузке, и скажем чексуммы пары важных бинарников (при апдейте будет ппц, но апдейт вообще вручную надо делать для таких систем). Но в любом случае если у человека есть немного мозга, то он в итоге распарсит полученную цепочку действий и додумается как ее обойти.

Банально можно сделать не больше одно-двух загрузок одного сервера на дню, иначе вручную. Или ожидать, пока админ не даст подтверждение на пришедшую смс о том, что один из серверов хочет запуститься.

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

А зачем серверу ядер окукливаться? Пусть просто ожидает подтверждения от админа при n попытках бута одного сервера и всё. Если его потушат, то он, в любом случае, зашифрован.

man TPM. Такой взрослый, но такой глупый.

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