Так, а вот это очень интересный сценарий. Конечно, сначала злоумышленник должен как-то узнать, как именно у меня всё устроено, что требует как минимум ребута сервера и какое-то время на изучение / снятие дампа раздела. Но если эту операцию представить как перебой со связью/питанием в ДЦ, можно и попасться...
Очевидным выходом будет использование двойного шифрования (вложенного туннеля), но именно в сценарии с initramfs это, подозреваю, не очень просто настроить. А вот я, кстати, от такой атаки, вроде, защищён, т.к. скрипт расшифровки дёргаю только через VPN.
Во-первых, в этом нет никакой логики, т.к. сервера в "нейтральных" государствах точно так же позволяют обойти блокировки РФ, а борется РКН именно с этим.
Во-вторых, мой собственный опыт постоянно работающих VPN-туннелей (WG и Amnezia-WG) внутри РФ, из РФ в Нидерланды, Швецию и Турцию показывает, что WG внутри РФ блокируется очень эпизодически, а вот трансграничные VPN - довольно часто, но совершенно рандомно. От одного провайдера к одному и тому же зарубежному серверу блок, от другого в то же самое время всё работает отлично, а на следующий день и первый оживает как ни в чём не бывало. Каких-то преимуществ у "нейтральной" Турции при этом я не заметил.
Ну и, кстати, мне кажется мифом существование каких-то вечных чёрных списков IP, попавшихся на использовании VPN. Ровно по той причине, что третий год с полдюжины российских статических IP совершенно в открытую устанавливаю WG-соединения с зарубежными серверами, в случае неудачи откатываюсь на AWG или обходной маршрут (OSPF в mesh-сети из VPN-туннелей "все со всеми" рулит) - и всё продолжает работать (или не работать) совершенно рандомно, как написал выше.
Каждый файл лежит на большом диске и на одном из двух маленьких.
Только это уже не RAID1. В RAID1 все диски содержат полностью идентичные данные, на то он и mirror.
Вот я и говорю: ZFS это что-то на богатом.
Поглядел на свои HDD, самые старые из которых ещё с 2008 года крутятся в режиме 24/365... ну да, наверное :)
Скорее уж проблема с ZFS на совсем древнем железе в её аппетите к RAM. На самом старом моём сервере, где RAM 6 Gb и больше не поставить, ZFS непозволительно много памяти кушает, не остаётся для приложений. Но он у меня сейчас под видеонаблюдение отведён, там надёжное хранение данных особо ни к чему, ну навернётся архив записей, начнём писать заново с нуля, - так что там вообще аппаратный RAID0.
Но перечисленное можно сделать и на LVM
Самый главный первый пункт плюс-минус делается разве что через dm-integrity. Сам не пробовал, но отзывы про скорость этого решения не радуют. Ну и восстанавливать в случае чего ZFS, где все фичи из коробки, изрядно проще, чем многослойный пирог из lvm, dm-integrity, шифрования и собственно ФС под этим всем.
Потом принести диск на 5Tb, добавить в этот RAID1, получить полезную площадь 3Tb. [...] Принести диск на 8Tb, подключить, получить полезную площадь 8Tb.
Это как это Вы на RAID1 получите полезную ёмкость больше самого маленького диска (диски на 1 Tb и 2 Tb ведь Вы ещё не удалили)? Ну и в целом, я на домашних серверах RAID'ы (изначально аппаратные, потом какое-то время LVM, BTRFS, последние годы ZFS) держу уже лет 20, и ни разу не возникало мысли такой зоопарк заводить :) Не то, что одинаковый объём, но и модели дисков всегда старался в одном массиве держать одинаковые (ну или хотя бы похожие, если точно одинаковых уже не купить).
Так что я так и не пойму, что это за возможности и удобства даёт ZFS кроме встроенного шифрования и кеширования.
Прежде всего, контроль целостности данных на уровне ФС и возможность делать scrub.
Ну и снэпшоты для бекапа штука крайне полезная. И zfs send/receive. И встроенная поддержка в proxmox.
В BTRFS основное из этого списка тоже есть, но у меня с ней (и не только у меня) немного негативный опыт в плане надёжности. Возможно, эти проблемы уже неактуальны, но "осадочек остался"...
Нет... вся эта ветка комментов началась с того, что я задумался, не добавить ли по рецепту автора шифрование корневой ФС гипервизора к уже имеющемуся у меня шифрованию той ФС на этом гипервизоре, где лежат тома с данными виртуалок. Если бы гипервизор был не мой собственный, а хостера - этот вопрос был бы лишён смысла.
Надёжная защита же VDS на стороннем гипервизоре - задача, IMHO, изначально безнадёжная ровно по той причине, про которую Вы написали. Так что для чувствительных данных - или арендуем/размещаем/сами у себя держим физический сервер, или держим VDS в той юрисдикции, где наши данные никому не нужны (и надеемся избежать/обойти блокировки) :)
Ну в случае с VDS и смысла говорить о целесообразности шифрования ФС гипервизора нет, так что я исключительно про физические сервера, которые, однако, могут быть размещены в стороннем ДЦ.
В debian есть такая засада, что обновления zfsutils-linux встают без перезагрузки, а обновления модуля zfs в ядре её требует, поэтому иногда в период между очередным обновлением zfsutils-linux и последующим ребутом часть утилит оказывается частично неработоспособной (не помню, что конкретно у меня не работало, но помню, что не сразу догадался о причине). Но на работоспособность самой ФС, если не осуществлять с ней никаких манипуляций, это не сказывалось.
В ubuntu, подозреваю, и это не проблема, ибо есть бесплатный (до 5 машин, но никто не мешает завести несколько учёток) kernel livepatch в Ubuntu Pro.
есть возможность как минимум сдампить память процесса qemu, где будет ключ шифрования
Вы, по-моему, путаете два случая:
а) когда мы контролируем физический сервер-гипервизор;
б) когда гипервизор под контролем стороннего лица (провайдера), а наша только виртуалка.
Я рассматриваю исключительно случай "а". И чтобы что-то сдампить (экзотические способы с заморозкой чипов памяти вынесем за скобки, это надо сильно постараться, чтобы ради тебя так заморочились :), надо сначала на этот гипервизор залогиниться рутом, что без ребута даже при физическом доступе задача, хм... нетривиальная, а после ребута память будет девственно чиста. Ну и вообще самый вероятный риск - изъятие сервера с последующим исследованием в ЭКЦ.
Где-то между простым изъятием и заморозкой памяти по степени замороченности (и вероятности возникновения) стои́т та самая подмена скрипта разблокировки. Но чтобы она сработала, нужно два условия. Во-первых, пользователь не должен ничего заподозрить по факту ребута (а тут, очевидно, будет не просто ребут, а и простой сервера на время манипуляций, необходимых для исследования механизма защиты и последующей подмены файлов). Во-вторых, скрипт разблокировки не должен предварительно, до передачи пароля/ключа, на стороне клиента проверять целостность своей серверной части и бинарника /usr/sbin/zfs (ну или образа initramfs в целом, если используем её). Вот это "во-вторых", пожалуй, однозначно стóит реализовать. Можно даже не изобретать велосипед в самом скрипте, а параллельно поставить какой-нибудь filestat_exporter и настроить алерты на изменение CRC задействованных в процессе расшифровки скриптов/бинарников.
трафик на сервер внутри страны привлекает меньше внимания, чем прямой канал за границу
Но Вы-то как раз и выбрали прямой канал за границу... Вы реально думаете, что РКН делает различия между серверами в "нейтральных" и "недружественных" странах?
Ну при невозможности расшифровать тома виртуалок у админа гипервизора, вроде, тоже не особо много возможностей. Но вот какие следы жизнедеятельности виртуалок могли остаться в не зашифрованной части, это да, неочевидная тема...
За наводку на dropbear-initramfs спасибо, как-то раньше этот вариант мимо меня проходил. Сейчас шифрую только ZFS, где хранятся тома виртуалок, и после перезагрузки сервера скриптом через SSH удалённо расшифровываю/монтирую эту ФС и запускаю виртуалки. На самóм гипервизоре, вроде, скрывать нечего :) Но Ваш вариант надёжнее.
У меня десяток постоянно работающих WG-туннелей внутри страны (дом/квартира/офисы/сервер в ДЦ связаны в mesh-сеть), так что статистика есть. Отваливаются достаточно регулярно. Благо, настроил через OSPF автоматический fallback на Amnezia-WG, вот с ней проблем внутри РФ, три раза тьфу, не наблюдалось.
А мне бы вот очень хотелось несколько VPN одновременно с нормальной маршрутизацией... Есть личная инфраструктура, есть две работы (на обеих всё решаю и настраиваю сам, но всё равно хотелось бы разнести), но из-за ограничения Андроида на один VPN одновременно приходится держать общую точку входа во все эти частные сети, что, мягко говоря, неправильно.
Возьмите в руки плату. Я не увидел на ней никаких защит от ESD
Выяснял у них этот вопрос буквально на днях, кстати. У меня не линолеум, а открытая прокладка кабелей по земле, ещё более актуально. На встроенных входах и портах RS485 защита есть (TVS-диоды, самовосстанавливающиеся предохранители), на входах модулей нет. Плохо, что это не очевидно из документации и нет понятных инструкций "для чайников", что нужно дополнительно сделать при каких внешних условиях. Но для более или менее продвинутого пользователя логично про такие вещи самому подумать и подстраховаться.
Ну вот кстати с Овеном зря автор так написал. Чем они хороши - тем, что все цены на все модификации, кроме совсем уж заказных под спец. нужды, всегда на оф. сайте. Правда, для личных нужд почти весь их ассортимент можно найти на Авито в 2-3 раза дешевле :)
Я тоже выбрал Wirenboard, прежде всего потому, что с бекграундом в администрировании линукс-серверов и программировании на ЯП общего назначения (а не языках ИЭК, бррр...) в него элементарно просто вкатиться. На Arduino/ESP32/STM/т.п. ещё дешевле, но требует определённого бекграунда уже в электронике, ну и трудозатраты несопоставимы.
Вообще с юридической точки зрения печать не нужна примерно никогда (есть исключения, типа судебных доверенностей и некоторых форм отчётности, но и они медленно, но верно выпиливаются из закона). А вот на практике печать, как ни удивительно, очень часто выступает заменителем доверенности. Как минимум две больших сети магазинов строительных товаров и инструмента выдают товар по заказам юр. лиц при наличии доверенности ИЛИ печати. Что совершенный бред с т.зр. закона, но, видимо, они оценили риски как приемлемые.
Это я уже сам догадался и отредактировал свой комментарий :)
Так, а вот это очень интересный сценарий. Конечно, сначала злоумышленник должен как-то узнать, как именно у меня всё устроено, что требует как минимум ребута сервера и какое-то время на изучение / снятие дампа раздела. Но если эту операцию представить как перебой со связью/питанием в ДЦ, можно и попасться...
Очевидным выходом будет использование двойного шифрования (вложенного туннеля), но именно в сценарии с initramfs это, подозреваю, не очень просто настроить. А вот я, кстати, от такой атаки, вроде, защищён, т.к. скрипт расшифровки дёргаю только через VPN.
Вроде пробовал (давно), грустно всё равно, да и смысла особого нет на данной конкретной машине.
Думаю, это не более чем совпадение.
Во-первых, в этом нет никакой логики, т.к. сервера в "нейтральных" государствах точно так же позволяют обойти блокировки РФ, а борется РКН именно с этим.
Во-вторых, мой собственный опыт постоянно работающих VPN-туннелей (WG и Amnezia-WG) внутри РФ, из РФ в Нидерланды, Швецию и Турцию показывает, что WG внутри РФ блокируется очень эпизодически, а вот трансграничные VPN - довольно часто, но совершенно рандомно. От одного провайдера к одному и тому же зарубежному серверу блок, от другого в то же самое время всё работает отлично, а на следующий день и первый оживает как ни в чём не бывало. Каких-то преимуществ у "нейтральной" Турции при этом я не заметил.
Ну и, кстати, мне кажется мифом существование каких-то вечных чёрных списков IP, попавшихся на использовании VPN. Ровно по той причине, что третий год с полдюжины российских статических IP совершенно в открытую устанавливаю WG-соединения с зарубежными серверами, в случае неудачи откатываюсь на AWG или обходной маршрут (OSPF в mesh-сети из VPN-туннелей "все со всеми" рулит) - и всё продолжает работать (или не работать) совершенно рандомно, как написал выше.
RAID - это не бэкап...
Только это уже не RAID1. В RAID1 все диски содержат полностью идентичные данные, на то он и mirror.
Поглядел на свои HDD, самые старые из которых ещё с 2008 года крутятся в режиме 24/365... ну да, наверное :)
Скорее уж проблема с ZFS на совсем древнем железе в её аппетите к RAM. На самом старом моём сервере, где RAM 6 Gb и больше не поставить, ZFS непозволительно много памяти кушает, не остаётся для приложений. Но он у меня сейчас под видеонаблюдение отведён, там надёжное хранение данных особо ни к чему, ну навернётся архив записей, начнём писать заново с нуля, - так что там вообще аппаратный RAID0.
Самый главный первый пункт плюс-минус делается разве что через dm-integrity. Сам не пробовал, но отзывы про скорость этого решения не радуют. Ну и восстанавливать в случае чего ZFS, где все фичи из коробки, изрядно проще, чем многослойный пирог из lvm, dm-integrity, шифрования и собственно ФС под этим всем.
Это как это Вы на RAID1 получите полезную ёмкость больше самого маленького диска (диски на 1 Tb и 2 Tb ведь Вы ещё не удалили)?
Ну и в целом, я на домашних серверах RAID'ы (изначально аппаратные, потом какое-то время LVM, BTRFS, последние годы ZFS) держу уже лет 20, и ни разу не возникало мысли такой зоопарк заводить :) Не то, что одинаковый объём, но и модели дисков всегда старался в одном массиве держать одинаковые (ну или хотя бы похожие, если точно одинаковых уже не купить).
Прежде всего, контроль целостности данных на уровне ФС и возможность делать scrub.
Ну и снэпшоты для бекапа штука крайне полезная. И zfs send/receive. И встроенная поддержка в proxmox.
В BTRFS основное из этого списка тоже есть, но у меня с ней (и не только у меня) немного негативный опыт в плане надёжности. Возможно, эти проблемы уже неактуальны, но "осадочек остался"...
Нет... вся эта ветка комментов началась с того, что я задумался, не добавить ли по рецепту автора шифрование корневой ФС гипервизора к уже имеющемуся у меня шифрованию той ФС на этом гипервизоре, где лежат тома с данными виртуалок. Если бы гипервизор был не мой собственный, а хостера - этот вопрос был бы лишён смысла.
Надёжная защита же VDS на стороннем гипервизоре - задача, IMHO, изначально безнадёжная ровно по той причине, про которую Вы написали. Так что для чувствительных данных - или арендуем/размещаем/сами у себя держим физический сервер, или держим VDS в той юрисдикции, где наши данные никому не нужны (и надеемся избежать/обойти блокировки) :)
Ну в случае с VDS и смысла говорить о целесообразности шифрования ФС гипервизора нет, так что я исключительно про физические сервера, которые, однако, могут быть размещены в стороннем ДЦ.
В debian есть такая засада, что обновления zfsutils-linux встают без перезагрузки, а обновления модуля zfs в ядре её требует, поэтому иногда в период между очередным обновлением zfsutils-linux и последующим ребутом часть утилит оказывается частично неработоспособной (не помню, что конкретно у меня не работало, но помню, что не сразу догадался о причине). Но на работоспособность самой ФС, если не осуществлять с ней никаких манипуляций, это не сказывалось.
В ubuntu, подозреваю, и это не проблема, ибо есть бесплатный (до 5 машин, но никто не мешает завести несколько учёток) kernel livepatch в Ubuntu Pro.
Вы, по-моему, путаете два случая:
а) когда мы контролируем физический сервер-гипервизор;
б) когда гипервизор под контролем стороннего лица (провайдера), а наша только виртуалка.
Я рассматриваю исключительно случай "а". И чтобы что-то сдампить (экзотические способы с заморозкой чипов памяти вынесем за скобки, это надо сильно постараться, чтобы ради тебя так заморочились :), надо сначала на этот гипервизор залогиниться рутом, что без ребута даже при физическом доступе задача, хм... нетривиальная, а после ребута память будет девственно чиста. Ну и вообще самый вероятный риск - изъятие сервера с последующим исследованием в ЭКЦ.
Где-то между простым изъятием и заморозкой памяти по степени замороченности (и вероятности возникновения) стои́т та самая подмена скрипта разблокировки. Но чтобы она сработала, нужно два условия. Во-первых, пользователь не должен ничего заподозрить по факту ребута (а тут, очевидно, будет не просто ребут, а и простой сервера на время манипуляций, необходимых для исследования механизма защиты и последующей подмены файлов). Во-вторых, скрипт разблокировки не должен предварительно, до передачи пароля/ключа, на стороне клиента проверять целостность своей серверной части и бинарника /usr/sbin/zfs (ну или образа initramfs в целом, если используем её). Вот это "во-вторых", пожалуй, однозначно стóит реализовать. Можно даже не изобретать велосипед в самом скрипте, а параллельно поставить какой-нибудь filestat_exporter и настроить алерты на изменение CRC задействованных в процессе расшифровки скриптов/бинарников.
Но Вы-то как раз и выбрали прямой канал за границу... Вы реально думаете, что РКН делает различия между серверами в "нейтральных" и "недружественных" странах?
Ну при невозможности расшифровать тома виртуалок у админа гипервизора, вроде, тоже не особо много возможностей. Но вот какие следы жизнедеятельности виртуалок могли остаться в не зашифрованной части, это да, неочевидная тема...
За наводку на dropbear-initramfs спасибо, как-то раньше этот вариант мимо меня проходил. Сейчас шифрую только ZFS, где хранятся тома виртуалок, и после перезагрузки сервера скриптом через SSH удалённо расшифровываю/монтирую эту ФС и запускаю виртуалки. На самóм гипервизоре, вроде, скрывать нечего :) Но Ваш вариант надёжнее.
У меня десяток постоянно работающих WG-туннелей внутри страны (дом/квартира/офисы/сервер в ДЦ связаны в mesh-сеть), так что статистика есть. Отваливаются достаточно регулярно. Благо, настроил через OSPF автоматический fallback на Amnezia-WG, вот с ней проблем внутри РФ, три раза тьфу, не наблюдалось.
А мне бы вот очень хотелось несколько VPN одновременно с нормальной маршрутизацией... Есть личная инфраструктура, есть две работы (на обеих всё решаю и настраиваю сам, но всё равно хотелось бы разнести), но из-за ограничения Андроида на один VPN одновременно приходится держать общую точку входа во все эти частные сети, что, мягко говоря, неправильно.
Выяснял у них этот вопрос буквально на днях, кстати. У меня не линолеум, а открытая прокладка кабелей по земле, ещё более актуально. На встроенных входах и портах RS485 защита есть (TVS-диоды, самовосстанавливающиеся предохранители), на входах модулей нет. Плохо, что это не очевидно из документации и нет понятных инструкций "для чайников", что нужно дополнительно сделать при каких внешних условиях. Но для более или менее продвинутого пользователя логично про такие вещи самому подумать и подстраховаться.
Ну вот кстати с Овеном зря автор так написал. Чем они хороши - тем, что все цены на все модификации, кроме совсем уж заказных под спец. нужды, всегда на оф. сайте. Правда, для личных нужд почти весь их ассортимент можно найти на Авито в 2-3 раза дешевле :)
Я тоже выбрал Wirenboard, прежде всего потому, что с бекграундом в администрировании линукс-серверов и программировании на ЯП общего назначения (а не языках ИЭК, бррр...) в него элементарно просто вкатиться. На Arduino/ESP32/STM/т.п. ещё дешевле, но требует определённого бекграунда уже в электронике, ну и трудозатраты несопоставимы.
Вообще с юридической точки зрения печать не нужна примерно никогда (есть исключения, типа судебных доверенностей и некоторых форм отчётности, но и они медленно, но верно выпиливаются из закона).
А вот на практике печать, как ни удивительно, очень часто выступает заменителем доверенности. Как минимум две больших сети магазинов строительных товаров и инструмента выдают товар по заказам юр. лиц при наличии доверенности ИЛИ печати. Что совершенный бред с т.зр. закона, но, видимо, они оценили риски как приемлемые.