Как стать автором
Обновить

Комментарии 44

Жаль, что сервер не может сам стартовать без ввода ключа. А вводить ключ удалённо — это подвергать его риску утечки + надо как-то удостовериться, что ключ попадает на твою машину, а не на подставную.
Можно. Просто, после перезагрузки сервер сам может подключаться к «серверу ключей» по защищенному ssh соединении и разлочит самого себе. Или же послать какой-то уникальный идентификатор по тому же ssh, и «сервер ключей» подключится и разлочит его. Для этого нужно поднять сетевой интерфейс еще до запроса на ввод пароля. Я уже такое дела, может добавлю на сайт подробности.
> после перезагрузки сервер сам может подключаться к «серверу ключей» по защищенному ssh соединени
Но ведь это будет делать незашифрованная логика сервера. А значит, туда может иметь доступ злоумышленник. И ключ попадёт к нему.

> Или же послать какой-то уникальный идентификатор по тому же ssh, и «сервер ключей» подключится и разлочит его.
Что мешает злоумышленнику, получившему доступ к незашифрованной части сервера, наблюдать за процессом отсылки «уникального идентификатора» и получения ключа? Ключ он опять же получит.
Да, это не безопасные варианты — можно использовать в экспериментальных целях.
Если же сервер удаленный — просто получаешь нотификацию, от сервера «разлоч меня». И, так как секретный ключ для подключения есть только у тебя, — уже сам решай подключиться и разлочить или проверить не стащили ли жесткие диски и пробуют их считать.

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

Т.е. решения проблемы нет, я правильно понимаю?
Зачем тогда вообще всё это шифрование диска удалённой машины?
> И, так как секретный ключ для подключения есть только у тебя, — уже сам решай…
Твой сервер изъяли или чудесным образом заменили initramfs — тебе приходит запрос на разлочки.
Ты понял, что что-то с сервером и твоя совесть говорит тебе — «не разлочуй, убедись что все в порядке, свяжись с дата-центром. Если это подстава, то ты сейчас разлочиш службам или хакерам свой диск»

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

И это отличное и надежное решение, только недоработанное. Кому нужно будет — тот придумает выход.
> Ты понял, что что-то с сервером
Но как? Как я это понял? Кто мешает злоумышленнику не дать мне этого понять?

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

От кого же оно тогда вообще защищает? От воров, которые крадут сервера и быстро убегают из датацентра, а потом боятся вернуться? Я о таких не слышал.

> И это отличное и надежное решение, только недоработанное.
Мне кажется, или это взаимоисключающие понятия?

> Кому нужно будет — тот придумает выход.
В чём ценность описанного в статье подхода? В ссылке на ваш сайт? Про luks и cryptsetup мы и так знали.
> Ты понял, что что-то с сервером
Но как? Как я это понял? Кто мешает злоумышленнику не дать мне этого понять?

Потому, что пришел запрос на разлочку, это не трудно было понять… И написано же —
свяжись с дата-центром.


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

От кого же оно тогда вообще защищает? От воров, которые крадут сервера и быстро убегают из датацентра, а потом боятся вернуться? Я о таких не слышал.


Что за бред?! О чем речь?! Если бы Вы хоть раз пользовались этим методом защиты дисков Вы бы знали, что диски дешифруются при старте системы. Если сервер выключить и включить — нужно вводить ключ, и потом, после разлочки, уже авторизоваться.
Если кто-то в дата-центре, при включенном сервере, подключился и подобрал пароль рута или админа — тогда понятное дело, что все напрасно. Но что это за дата-центр такой?!

> > Кому нужно будет — тот придумает выход.
В чём ценность описанного в статье подхода? В ссылке на ваш сайт? Про luks и cryptsetup мы и так знали.

Очевидно — защита ценной информации на локальном или удаленном сервере. Но в Вашем случаи оно не подходит — ведь все знают логин и пароль к Вашему серверу в дата-центре…

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

> свяжись с дата-центром.
Т.е. датацентру мы доверяем?
Тогда повторяю свой вопрос: от кого мы шифруем данные?

> Что за бред?! О чем речь?! Если бы Вы хоть раз пользовались этим методом защиты дисков Вы бы знали,
> что диски дешифруются при старте системы. Если сервер выключить и включить — нужно вводить ключ,
> и потом, после разлочки, уже авторизоваться.
Спасибо, кэп!

> Если кто-то в дата-центре, при включенном сервере, подключился и подобрал пароль рута или админа —
> тогда понятное дело, что все напрасно. Но что это за дата-центр такой?!
Имея физический доступ к серверу пароль рута можно сменить.
А датацентр обычный российский. Впускает всех встречных-поперечных, которые покажут соответствующую ксиву или автомат. Бандитов, короче.

> Очевидно — защита ценной информации на локальном или удаленном сервере.
Чё-то пока не видно защиты. От кого можно таким образом защитить данные? От вышеописанных мной воров серверов?

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

> свяжись с дата-центром.
Т.е. датацентру мы доверяем?
Тогда повторяю свой вопрос: от кого мы шифруем данные?

> Что за бред?! О чем речь?! Если бы Вы хоть раз пользовались этим методом защиты дисков Вы бы знали,
> что диски дешифруются при старте системы. Если сервер выключить и включить — нужно вводить ключ,
> и потом, после разлочки, уже авторизоваться.
Спасибо, кэп!

> Если кто-то в дата-центре, при включенном сервере, подключился и подобрал пароль рута или админа —
> тогда понятное дело, что все напрасно. Но что это за дата-центр такой?!
Имея физический доступ к серверу пароль рута можно сменить.
А датацентр обычный российский. Впускает всех встречных-поперечных, которые покажут соответствующую ксиву или автомат. Бандитов, короче.

> Очевидно — защита ценной информации на локальном или удаленном сервере.
Чё-то пока не видно защиты. От кого можно таким образом защитить данные? От вышеописанных мной воров серверов?

> Но в Вашем случаи оно не подходит — ведь все знают логин и пароль к Вашему серверу в дата-центре…
Ещё раз: пароль от рута не является проблемой при наличии физического доступа к серверу.


С таким подходом доверять нельзя никому и все данные всех пользователей мира на серверах дата-центров под угрозой…
С подходом, как у Вас, доверять надо всем без исключения. =)))

И Вы так и не ответили на вопрос, который я задал раза уже три: от кого защищает такой подход к защите данных? Конкретные кейсы можете привести?
Данный подход используется для защиты дисков в облаках (Secure Cloud). К ним относится тот же TrendMicro.
И я еще хочу узнать как Вы получите пароль рута без перезагрузки сервера?!
> Но в Вашем случаи оно не подходит — ведь все знают логин и пароль к Вашему серверу в дата-центре…
Ещё раз: пароль от рута не является проблемой при наличии физического доступа к серверу.
Даже можно поступить иначе.
У меня есть удаленный зашифрованный сервер с настроенной разлочкой.
Вы работаете в дата-центре.
Напишите, пошагово, как вы сможете скопировать или даже посмотреть что находится на моем сервере, и тогда проясним вопрос с защитой.
Это, наверное, особое умение, не отвечать на вопрос:
Я спросил несколько раз: от кого защищаемся?
Вы отвечаете: защищаем диски в облаках.

> И я еще хочу узнать как Вы получите пароль рута без перезагрузки сервера?!

Почему без-то? Очень даже С. Вот так: habrahabr.ru/post/54103/

> Напишите, пошагово, как вы сможете скопировать или даже посмотреть что находится
> на моем сервере, и тогда проясним вопрос с защитой.

1. Бандит в фуражке и с ментовской ксивой приходит в датацентр и махая ксивой получает физический доступ к вашей машине с зашифрованным диском.
2. Бандит получает рута с перезагрузкой сервера без сети.
3. Бандит изучает сервер и находит, что один раздел зашифрован. Тогда он подменяет /sbin/cryptsetup своей прогой, которая записывает в файл всё, что ей передают, а так же запускает оригинальный cryptsetup, передавая туда эти данные, чтоб жертва не заметила подмены.
4. Бандит подключает сеть и запускает сервер опять.
5. Сервер загружается, поднимается сеть, он оповещает вас о том, что ему нужна разлочка.
6. Вы смотрите, что там происходит в датацентре: саппорт говорит, что у них пропадало электричество или ещё какая фигня. Короче раз в полгода такое стабильно происходит хотя бы с одной вашей машиной в среднем датацентре, если у вас там пара десятков машин.
7. Не увидя признаков опасности вы командуете серверу с ключами разлочить атакуемый сервер.
8. Он коннектится туда по ssh и делает что-нить такое: cat ~/misc/keys/backup.key | ssh server 'sudo /sbin/cryptsetup luksOpen /dev/sdb data --key-file=-'
9. Поскольку cryptsetup подменян, он ваш ключик положит в отдельный файл для бандита, а так же вызовет оригинальный cryptsetup, который разлочит вам сервер.
10. Сервер разлочен и запущен, вы радуетесь, что восстановили его работу, а бандит:
а) шарится по вашему разлоченному разделу;
б) либо вырубает сервер и забирает его вместе с ключом.
Можно защититься.

Сервер на первой стадии грузится с boot, а там один только sh, wget, sshd, tar/bzip2.

Заходим в sh по ssh, скачиваем в wget некий файлик httрs://11.22.33.44/my-setup.tar.bz2
распаковываем в RAMDISK, а там другой sh (желательно вообще экзотику типа zsh или csh), cryptsetup, модули ядра для шифрования, и т.п.

Снимаем SHA256 раздела boot. Если не совпадает с тем, что мы видели в последний раз — восстанавливаем из бекапа и ещё раз перезагружаем сервер. Таким образом убираем все очевидные закладки.

Монтируем криптораздел утилитами из нашего архива, удаляем их, чтобы было непонятно, чем это всё монтируется. Продолжаем загрузку.
Когда сервер в руках у злоумышленника, он может подменить логику, которая считает sha256 раздела boot. Ок, если ты её притащишь извне на этапе разлочки, то опять же злоумышленник может подменить и её прям в реалтайме.

Конечно, для этого ему нужно знать, как у тебя всё устроено, и придётся понаблюдать за процессом загрузки. Но это лишь усложняет его работу, а не делает её невозможной.
Может, но не с первого раза. И даже не со второго (если у тебя в запасе N трюков).
Тут ты понимаешь, что пахнет жаренным, и меняешь хостера.

Злоумышленник может полностью виртуализировать boot, чтобы чтение-запись шли на отдельный раздел где-то на usb-stick, а загружалось всё с его модифицированного. Для этого ему надо будет внести изменения в ядро. Но исходников, с которых компилилось текущее ядро, у него нет, он возьмёт канонический linux нужной версии. А в исходниках, с которых ты компилишь, можно поменять одно из сообщений «Loaded bla-bla OK» на «Loaded bla-bla ok» и, просматривая dmesg, ты будешь знать, твоё ядро или нет.

Кроме того, можно залить новый boot не совпадающий со старым, а например поменять там рутовый пароль. Если перезагрузился, а пароль подходит старый — подмена произошла.

Да и не думаю, что среднестатистический бандит, увидев загрузившуюся пустую систему (в которую ты должет залить свои утилиты шифрования с домашней машины для продолжения загрузки) вообще что-нибудь поймёт и у него возникнет разумный и сверх-осторожный план действий.
Бандиты могут нанимать it-специалистов. It-специалисты могут быть бандитами, особенно в этой стране.
Но это всё детали.
То, что ты описываешь, лишь усложняет работу злоумышленника. А шифрование должно делать её либо невозможной, либо астрономически дорогой — настолько, что ни у кого вообще в мире даже теоретически не может быть столько ресурсов на данный момент времени.

И ты так и не ответил на мой вопрос. Стесняешься что ли?
А это не мне был вопрос ))

Могу предположить, что защищаемся от конкурентов, у которых есть длинные лапы в органах/у персонала хостинга. И которые падки до коммерческой тайны.
> А это не мне был вопрос ))

Прошу прощения +))

> Могу предположить, что защищаемся от конкурентов, у которых есть длинные лапы в органах/у персонала хостинга.
> И которые падки до коммерческой тайны.

Вот чё-то как-то не получается.
Вот чё-то как-то не получается.

Что не получается?
То, что ты описываешь, лишь усложняет работу злоумышленника

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

Если есть только одна попытка, ничего не выйдет.
Есть только одна попытка (на самом деле штуки три-пять за месяц, не меньше), только если мы согласны всё время переезжать из одного датацентра в другой. Это накладывает большие ограничения:

1. Мы не можем выбрать один датацентр, нам придётся перебирать все, пока они не кончатся. Хорошие, плохие, очень плохие, все.
Бизнес такого не терпит, если у вас на этих серверах бизнес-критикал что-то. А раз мы шифруем, то скорее всего это именно так.
2. Сами по себе переезды отнимают кучу времени, делают недоступным сервисы и всё такое прочее.

Короче, это ад ваще.

Шифрование должно давать 100% гарантию того, что никто не получит доступ к данным и мы от этого шифрования мало что потеряем!
Я рассматриваю случай, когда злоумышлненники в датацентре — форс-мажорный случай, а не в порядке вещей. Например, я располагаюсь в Новосибирске, а хостинг у меня в Киеве (подходящий попался). Бандиты нашли связи в Киеве, но не факт, что в Москве или в Нюрнберге у них тоже есть связи.

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

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

> Бандиты нашли связи в Киеве, но не факт, что в Москве или в Нюрнберге у них тоже есть связи.

И что, бежать от бандитов в Нюрнберг? А если бизнес-требования таковы, что сервер должен быть в Москве? (довольно частое явление, т.к. большинство российской аудитории в Москве, а пинг очень важен).
1. Ага, поломка HDD тоже форс-мажор, иначе бы вопрос о бекапах не стоял бы. А бекап нужен тогда, когда диск уже сломался, т.е. в контексте резервирования данных поломка диска — не форс-мажор.

2. Если доступ к данных лишних людей = потеря проекта, то временно можно и Нюрнберг переехать. Даст время на продумывание архитектуры, когда критичные данные далеко, а статика и некритичная логика в Москве.
> т.е. в контексте резервирования данных поломка диска — не форс-мажор.

Именно. И бекап — отличное рабочее решение. В отличие от.

> 2. Если доступ к данных лишних людей = потеря проекта, то временно можно и Нюрнберг переехать.

А шифрование тогда зачем?
Возможно, что у конкурентов нет связей в Москве, но есть в Нюрнберге, что тогда?
По аналогии с бекапами: мы не знаем, какой диск сломается, но если сломается любой (рабочий или резервный), мы знаем, как восстановиться. Но если всегда ломаются абсолютно все диски, бекап не помогает. Однако, это маловероятная ситуация.
Выходит, что сразу ехать в hetzner, но без шифрования — это как купить дорогой, но надёжный HDD, и полагаясь на него, не делать бекапы.

Когда как российский хостинг — обычный серверный HDD. Тоже хорош, но вероятность проблем выше (но это не значит, что они будут).
Это всё понятно.
Вопрос весь в том, что во всей этой проблеме шифрование практически не помогает.
Собственно, откуда он узнает, что ты считаешь SHA? Ему надо логировать sh-сессию. А в ней только запуск ksh (или busybox, что больше нравится). Вот ты и оторвался. В следующий раз он знает, что ты заходишь в другой shell, нужны какие-то дейсвия по его подмене. Затем он узнает, что ты считаешь SHA (а в другой раз, возможно, будешь считать MD5). И т.д… Позиции неравны, у бандита всего 2-3 попытки. Его модифицировнный boot с подменёнными файлами ты также может скачать себе и смотреть, какие файлы подменены. Тогда будет сразу очевидно, насколько серьёзно пытаются взломать
НЛО прилетело и опубликовало эту надпись здесь
Интересная штука. Но, на сколько я понимаю, она просто не даёт автоматически разшифровать диск сервера, если тот подозрительно долго находился в оффлайне.
Однако, много ли времени надо, чтоб скопировать /boot-раздел для его изучения? Он обычно совсем немного весит.
НЛО прилетело и опубликовало эту надпись здесь
И чем грозит «разбор полётов»?
Хостер скажет: извините, уборщица задела шнур УПС.

Дальше два варианта
1. Скопирует раздел /boot
Нужно после каждого инцидента менять ключ mandos (в принципе, чем тогда это отличается от ручной расшифровки?)

2. Подложит в boot трояна. Так, что при смене ключа либо ключ утечёт, либо в расшифрованной системе будет жить backdoor, позволяющий делать root-сессию.
Нужен весь вышеописанный геморой с проверкой идентичности загрузочной среды.
НЛО прилетело и опубликовало эту надпись здесь
Если после каждого инцидента менять хостинг, авто-расшифровка не нужна. Инциденты такие редкие, что надёжнее руками всё проверить и расшифровать. Если хостинг мы не меняем, атакующему не требуется «всезнание», за N попыток он взломает защиту.
НЛО прилетело и опубликовало эту надпись здесь
Поскольку это стандартное решение, стандартно и ломается.

Вставляем флешку в сервер, нажимаем reset. Нажимаем F8 и выбираем загрузку с флешки.
Загрузчик флешки анализирует boot, вытаскивает оттуда ключ mandos, передаёт его на сервер mandos, расшифровывает основной диск и продолжает загрузку. По времени это полностью укладывается в обычное время перезагрузки, и даже происходит быстрее, потому что делается не shutdown сервера по всем правилам, а hard reset.

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

А в чём проблема, если всё open-source? Копипасти куски кода, которые читают ключ и взаимодействуют с сервером.
Опять же, можно установить mandos на свои машины и потренироваться на разных версиях, пока флешка не станет достаточно универсальной.

и которая грузится быстрее, чем та-же минута

В любом случае в timeout-е mandos, должен быть запас времени на shutdown, а мы делаем reset и это время выигрываем.

найдете систему без пароля на биосе, на которой разрешены загрузки с чего-либо, кроме дисков

Здесь вскрытие корпуса. И либо обнуление БИОСА, загрузка тогда со всего подряд будет разрешена, либо перетыкаем boot HDD на другой шлейф, а свой ставим на его место.

Кстати, на серверах обычно вынуть HDD можно без вскрытия корпуса. Вообще халява: выключаем сервер, достаём винт (винты, если raid), переставляем их в соседний сервер, они подцепляются, прога потрошит boot, формирует запрос к mandos, получаем ключ, дампим и расшифровываем криптораздел.

А конфигурацию железа и рейдов можно узнать, сделав reset и записав на видео
1. активность HDD LED всех винтов — будет понятно, кто в рейде и отдельно ли boot
2. записать на скоростную камеру нового айфона (120fps) всё, про происходит на экране — от биоса (узнаем конфиги raid, если он аппаратный) до лога dmesg — будет просто море инфы.

Поскольку перезагрузка без задержек, mandos выдаст ключ, а владельцу можно сказать: сбой, шальной электрон пролетел из космоса в процессор.
Спасибо да мануал. Но все же, какой смысл шифровать бинарники? Это ж не конфидициальная информация, да и производительность дисковой подсистемы сразу падает. К тому же удаленная перезагрузка уже не поканает. Лучший вариант — складывать все в домашний каталог и его же и шифровать, а расшифровываться файло будет при логине пользователя. А различного рода веб проекты можно запущать из отдельного шифрованного контейнера.
Бинарники легко подменить, а внедрить вредоносный код в stage1 не каждый сможет.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории