пожалуйста ознакомтесь с статьями о принцыпах работы данного шифрования, и о методах взлома. При таком шифровании которое описано в статье, единственный способ взломать ваш ключ, это выдернуть оперативу сразу после выключения, заморозить ее, а потом считать ключ с ячеек памяти. Никакими другими атаками ваш ключ добыть не удастся
dd if=/home/test.avi of=/dev/null bs=50M
28+1 records in
28+1 records out
1468502016 bytes (1.5 GB) copied, 32.483 s, 45.2 MB/s
проц загружался примерно от 30 до 60% но при этом на сайте было 10-15 юзеров, заливающих и качающих музыку, такчто эксперемент не совсем чистый. ну и само железо там Sempron 2600+/2*256ddr1/80GB-2Mb… пока тестовое
к сожалению пока статистика не набралась, сервер только недавно поставили и не особо афишировали в процесе подгонки сайта и наполнения контентом. Ну и пока это делалось только для музыкального сервера… При попытках стрестеста(заход 100-200 чел одновременно) апач почти намертво вешал систему(дефолтный конфиг был и всего 512озу), но процес дешифровщика больше 5-15% процентов не сьедал. В общем наберется какаято статистика — дополню пост, или напишу новый
выбрать алгоритм aes512 или aes1024, прочитав как их правильно выставить в мануале cryptsetup. Но я надеюсь вы понимаете что даже AES128 практически нереально взломать даже на нынешних суперкомпьютерах
вы не внимательно читали) у меня также как у вас — винт шифруется Luksом, внутри шифроблока создана LVM на которой стоит система и хранятся данные. на флешке хранится образ initrd(маленький линукс, если не ошибаюсь selinux) он загружается в память, подключает зашифрованый винт с помощью ключа с флешки(можно вместо ключа поставить запрос пароля) и потом уже загружается система.
у меня настроены вебсервер/фтпсервер/база данных с описаниями контента и все это ведет логи в добавок к конфигам которые описывают ранее доступный сервер.
в датацентре можно не использовать флешку, а выделить всетаки на винте небольшой раздел для загрузочной системы который будет ключ брать с какогото сайта, расшифровывать винт и загружать основную ОС. естественно это сложнее реализовать, но не намного. В итоге если сервер выключили органы и забрали — сразу блокируете доступ к ключу и все сервер у них не включится. Но в любом случае прийдется доказывать что не верблюд. Думаю в датацентре оптимальнее поставить просто чистую систему-обманку, а потом вручную подключать шифрованый раздел на винте со всем необходимым — но работы конечно прийдется проделать не мало.
если так мыслить то орагны должны гонятся за миллионами пользователей которые прочитали статьи из серии «как обмануть закон, чтобы не пострадать от его неверного применения»
это решение полностью основано на системе шифрования которая используется в убунту, но оно руками настроено дополнительно для немного иных целей чем шифрование домашних папок пользователей.
а) естественно шифрование влияет на производительность, но не так сильно как все думают — в моем случае примерно 5-10% процессорного времени кушалось на шифрование. но это на старом и слабом проце, на современных думаю даже не почувствуете(конечно если это не высоконагруженый сервер).
б) а это уже ваша задача сделать так чтобы флешку не увидели и не забрали. можно конечно делать без флешки — выделить маленький раздел под загрузчик на винте, а вместо файла ключа использовать пароль — но тогда в явном виде будет то что система зашифрована. Тоесть, умышленное правонарушение если смогут доказать. Вообще хоть и можно построить очень гибкие и хитрые схемы загрузки, но 100% защиты не даст. К тому всегда остается человеческий фактор.
ключ можно выбирать любой длины самому. так как на самом деле шифруется винт совсем другим ключом, а пользовательський ключ только разблокирует к нему доступ(в служебной части шифрованого раздела). Почитайте описание LUKS.
На счет Hibernate — не проверял, но если подумать — уверен что работать не будет. для домашних машин лучше использовать шифрование домашнего каталога, или сделать криптоконтейнер с ценной инфой и хранить гдето на дропбоксе.
в убунту это тоже написано, файлы которые по логике граб2 надо править лежат тут /etc/grub.d, на их основании update-grub генерит grub.cfg. Но скрипты там как раз написаны с умом и они сами находят где находится корень и подставляют. в случае с обычными разделами вписываются UUIDы, ну а вот LVM прописало прямым путем
ну у нас в городе это решается довольно просто(естественно если вы не частное лицо), когда к вам приходит проверка — звоните адвокату и ищете понятых. когда адвокат приехал — демонстрируете всем что комп не работает, если будут всеравно забирать на «экспертизу» опечатываете комп полностью со своими подписями и требуете проведения экспертизы в вашем присутствии. Так вам не смогут подбросить никакого ДП и других прелестей… И еще сервер был и вдруг не стало, как они это докажут? А если докажут — ссылаетесь на то что это был общедоступный фтп, куда пользователи назаливали своей инфы, вы ее недавно увидели и форматнули все нафиг.
Но всеравно хотелось бы услышать мнение юристов.
на счет потери информации я не зря написал про RAID1,5,6 — если инфа ценная то стоит потратится на ее защитую
28+1 records in
28+1 records out
1468502016 bytes (1.5 GB) copied, 32.483 s, 45.2 MB/s
проц загружался примерно от 30 до 60% но при этом на сайте было 10-15 юзеров, заливающих и качающих музыку, такчто эксперемент не совсем чистый. ну и само железо там Sempron 2600+/2*256ddr1/80GB-2Mb… пока тестовое
load average: 0.45, 0.24, 0.12
б) а это уже ваша задача сделать так чтобы флешку не увидели и не забрали. можно конечно делать без флешки — выделить маленький раздел под загрузчик на винте, а вместо файла ключа использовать пароль — но тогда в явном виде будет то что система зашифрована. Тоесть, умышленное правонарушение если смогут доказать. Вообще хоть и можно построить очень гибкие и хитрые схемы загрузки, но 100% защиты не даст. К тому всегда остается человеческий фактор.
На счет Hibernate — не проверял, но если подумать — уверен что работать не будет. для домашних машин лучше использовать шифрование домашнего каталога, или сделать криптоконтейнер с ценной инфой и хранить гдето на дропбоксе.
Но всеравно хотелось бы услышать мнение юристов.
на счет потери информации я не зря написал про RAID1,5,6 — если инфа ценная то стоит потратится на ее защитую