LINUX.ORG.RU

Сервер, шифрование отдельной директории, мало возможностей

 , ,


0

1

Добрый вечер уважаемые специалисты по криптованию всего!
Ну т.е. поздоровался с 99.9% тутошней аудитории же.

  • Имеется сервер далеко, где физического доступа нет
  • Систему переустановить возможности нет
  • Менять разметку HDD возможности нет
  • Останавливать сервер на длительное время возможности нет
  • Создавать криптованные контейнеры подходящего размера возможности нет, т.к. свободное место ограничено
  • Не имеет значения, что кто-то будет знать сколько зашифрованных файлов, какова их дата модификации, каков размер. Важно сохранить приватность содержимого самих файлов.

Хочется предотвратить доступ к файлам mysql базы (отдельная директория же) в случае физического изъятия HDD, т.е. избежать такой ситуации:

сервер остановлен, диск физически вынут, база утекла

Предположительно подходит encfs, т.к. он позволит быстро закриптовать директорию, где лежит база.
Какие есть (и почему) разумные альтернативы для encfs в данном случае?

encfs

Работает через FUSE, что создаст дополнительные тормоза. Лучше eCryptfs, т.к. она работает в ядре, это быстрее.

сервер остановлен, диск физически вынут, база утекла

Если у злоумышленника есть физический доступ, то шифрование директории ничем не поможет. Он скопирует данные с включённого сервера. Ведь всё необходимое для монтирования этой директории должно хранится на самом сервере. Не будешь же ты при каждом включении монтировать директорию руками?
UPD Даже если ключ не будет хранится на сервере или монтирование будет вручную при подключении через ssh, то это тоже мало чего даст. Злоумышленник может модифицировать систему (оставить для себя доступ), подождать, пока директория будет смонтирована, затем скопировать данные.

ls-h ★★★★ ()
Последнее исправление: ls-h (всего исправлений: 1)
Ответ на: комментарий от ls-h

Лучше eCryptfs

Спасибо, читаю

Не будешь же ты при каждом включении монтировать директорию руками?

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

Злоумышленник может модифицировать систему

Таким вопросом я не задавался. А каким образом это кто-то посторонний может сделать не выключая, чтобы я этого не понял (не заподозрил)?

Brillenschlange ()
Ответ на: комментарий от Brillenschlange

может сделать не выключая

Допустим, сервер выключится. Что дальше будешь делать? Полная переустановка всей системы? Мало ли что и где изменилось? Или многочасовые проверки всего и вся? А это просто сбой питания был, как окажется.

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

ls-h ★★★★ ()
Ответ на: комментарий от ls-h

Допустим, сервер выключится. Что дальше будешь делать?

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

А как тогда обстоят дела с хостингами, допустим, дедиков вообще везде? Как закриптовать диски изначально и быть полностью независимым от персонала хостинга, который имеет физический доступ?

Brillenschlange ()
Ответ на: комментарий от ls-h

Лучше задуматься о физическом перемещении сервера в другое место.

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

Ну и да, шифрованный раздел не защищает от несанкционированного доступа, а защищает от физического похищения.

Oleg_Iu ()
Ответ на: комментарий от Oleg_Iu

Поэтом чувствительные данные однозначно надо хранить на шифрованных разделах

Это очень хорошая теория, но в конкретном рассматриваемом случае нет возможности как-либо модифицировать разделы.

Какие еще могут быть варианты (кроме encfs и eCryptfs), подходящие под условия топика?

Brillenschlange ()
Ответ на: комментарий от Brillenschlange

Какие еще могут быть варианты (кроме encfs и eCryptfs), подходящие под условия топика?

Примонтировать по NFS свой домашнй (условно) ноут. Слить туда часть файлов, что бы освободить место, сделать LUKS disk image, и залить туда файлы, которые надо припрятать от органов. :)

Oleg_Iu ()
Ответ на: комментарий от Oleg_Iu

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

Я же не просто так старался писать условие задачи, а там, кроме прочего, написано:

Останавливать сервер на длительное время возможности нет

И кстати, каков будет плюс «сделать LUKS disk image» в конкретно заданной ситуации? В задаче 6 пунктов, последний вроде как сводит к минимуму различие в методах кроме, возможно, скорости. Или я что-то упускаю глобальное?

Brillenschlange ()
Ответ на: комментарий от Brillenschlange

А как тогда обстоят дела с хостингами, допустим, дедиков вообще везде? Как закриптовать диски изначально и быть полностью независимым от персонала хостинга, который имеет физический доступ?

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

Теоретически некоторые процессоры вроде AMD Epyc умеют в безопасность виртуалок настолько, что даже хост ничего там увидеть не сможет. На практике я не знаю, чтобы кто-то это использовал в хостинге.

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

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Я белую защищаю и прочие адреса-пароли для очистки совести. Везти на базу в азоте точно не будут, потому и есть пункт 6 условия задачи

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

Считается, что персонал входит в круг доверенных лиц. Если это не так, от такого врага защищаться сложно

А не придумали еще на такие случаи штуку типа «оно забутилось немножечко и ждёт по сети пароль для расшифровки /boot»?

Brillenschlange ()
Ответ на: комментарий от Brillenschlange

А не придумали еще на такие случаи штуку типа «оно забутилось немножечко и ждёт по сети пароль для расшифровки /boot»?

придумали, Mandos называется

linuxdoe ()
Ответ на: комментарий от Brillenschlange

А не придумали еще на такие случаи штуку типа «оно забутилось немножечко и ждёт по сети пароль для расшифровки /boot»?

boot не должен быть зашифрован, иначе ОС не загрузится, конечно если у тебя не стоит coreboot/libreboot тогда /boot может быть зашифрован, но Mandos работать не будет.

Т.к. тебе диск размечать нельзя, ничего менять нельзя, то даже Mandos не поможет.

linuxdoe ()
Ответ на: комментарий от vasily_pupkin

ext4 и 5.10, так что вроде как должно быть ок. Читаю про fscrypt.

@linuxdoe

придумали, Mandos называется

Прикольная штука вроде как, однако при очень беглом взгляде насторожило The password to this file system will be stored on another computer (henceforth known as the Mandos server) on the same local network. Почитаю потом внимательно, сейчас пока надо уложиться в условия задачи.

Brillenschlange ()

никогда такого не понимал - что мешает взять ещё сервер у этого же хостера, сделать там всё нормально, а потом на него перенести с этого. Если уж есть чего защищать, то уж можно немного потратиться и сделать по уму. Или это мамкин админ решил сделать, как у «бАльших дяденек»? (У бАльших дяденек шифрование разделов, кстати, запрещено, шифровать можно только на уровне программных продуктов.)

vtVitus ★★★★★ ()
Ответ на: комментарий от vtVitus

никогда такого не понимал

Никогда не поздно начать думать. Обдумайте это для начала.

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

По сути-то есть что сказать, тов. специалист-немамкин-админ?
Ну или хотя бы уж на худой свой конец расскажите поподробнее про бАльших дяденек, у которых шифрование разделов запрещено.

Brillenschlange ()
Ответ на: комментарий от Brillenschlange

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

vtVitus ★★★★★ ()

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

Особенная благодарность выражается, конечно же, последнему, и, как водится, самому умному советчику. Будь здоров, дружище, и не пропускай приём лекарств!

Brillenschlange ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей