25 апреля 2010 в 18:02

Мечта параноика или Еще раз о шифровании

В свете последних событий с torrents.ru и активизации государственных группировокорганов по борьбе с пиратством, думаю многие задумались как же обезопасить себя или свой сервер на случай если придут нежданные «гости». Вот и мне подвернулась задача защитить локальный медиасервер от посягательств, проведя пару дней за гугленнием и чтением мануалов/howto — мне удалось это реализовать. Скажу сразу, статей по шифрованию очень много, но в основном они рассчитаны на шифрование только определенных разделов, либо устарели/содержат много ошибок.

ЦЕЛИ:

  1. Весь винт(винты) должны быть надежно зашифрованы
  2. На винтах не должно быть абсолютно никакой разбивки, так как будто это новый(или стертый) винт
  3. ОС должна стоять на зашифрованных разделах
  4. Должна быть возможность увеличения дискового пространства, путем добавления новых винтов
  5. Загрузка системы без ввода ключа от шифрованных данных


ТЕОРИЯ:


Для начала вкратце объясню теорию как это все будет работать: загрузчик системы и ключ доступа будут храниться на небольшом(<50Mb) разделе флешки, при включении загрузчик разблокирует доступ к шифрованному винту, загружает ядро, подключает виртуальные разделы(LVM), далее происходит обычная загрузка системы.
В качестве операционной системы был выбран Ububtu Server 9.10, но реализовать эту задачу можно на любой UNIX-like системе. Сразу оговорюсь, в самом инсталляторе есть возможность шифрования системы на этапе установки, но там нельзя реализовать пункты 1 и 2 из списка выше потому будем действовать в ручную.
Нам понадобится:
  1. Образ Ubuntu Server 9.10
  2. LiveCD дистрибутив. Я взял обычный Ubuntu Desktop CD, так как он умеет работать с шифрованными разделами «из коробки».
  3. Флешка которая будет использоваться для загрузки системы
  4. Базовый знания по *nix системам
  5. Прямые руки


ЭТАП 1. Подготовка флешки и жесткого диска


А) Разбивка флешки на разделы и создание ключа
Подключаем флешку к компьютеру на котором будет шифроваться винт и загружаемся с LiveCD. Наша задача создать на нашей флешке 2 раздела: первый займет почти все пространство и будет отформатирован в FAT16,FAT32,NTFS(на ваш выбор), второй раздел делаем в конце флешки на 50MB и форматируем в ext2. Такая разбивка не случайна — благодаря начальному разделу флешка будет полностью функциональна в любой ОС. Также в windows второй раздел будет недоступен — что является плюсом, если ваша флешка попадет не в те руки. Для создания разделов я воспользовался графической утилитой GParted(была на LiveCD), но никто не мешает вам воспользоваться fdisk. После создания разделов примонтируем их в системе:
sudo su
mkdir /mnt/flash /mnt/boot
mount /dev/sdb1 /mnt/flash
mount /dev/sdb2 /mnt/boot

Теперь создадим файл-ключ с помощью которого будем шифровать винт и сделаем его дубликат (на всякий случай):
dd if=/dev/random of=/mnt/boot/mykey bs=1 count=256
cp /mnt/boot/mykey /mnt/flash/

Б) Подготовка винта для шифрования
Для начала нам нужно забить наш винт полностью случайными данными. Это делается для того чтобы невозможно было определить в каких секторах находятся ваши данные и сколько места они занимают, грубо говоря весь винт открытый в HEX-редакторе, должен выглядеть равномерно забитым несвязным мусором, вне зависимости от количества вашей информации. Существует 2 стандартных способа сделать это, оба они медленные, так что запаситесь терпением.
Первый способ. Случайная информация берется из псевдогенератора случайных чисел и пишется на винт блоками по 2MB. Скорость генерации данных на Core Quad Q6600 составила всего 6Mb/сек, так что тестовый винт на 80Гиг заполнился за 4 часа.
sudo dd if=/dev/urandom of=/dev/sda bs=2M

Второй способ лично я не проверил так как нашел уже после подготовки винта. В нем используется программа проверки винта на BAD-блоки. О скорости данного способа и «качестве» рандомданных сказать ничего не могу.
sudo /sbin/badblocks -c 10240 -s -w -t random -v /dev/sda


Теперь, когда поверхность диска заполнена, пора его зашифровать. Для этого воспользуемся технологией LUKS.
sudo cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 luksFormat /dev/sda /mnt/boot/mykey

Вас предупредят об уничтожении данных, для подтверждения нужно написать YES(большими буквами). Подключаем шифрованный диск:
sudo cryptsetup -d=/mnt/boot/mykey luksOpen /dev/sda drivespace

Вводим пароль и получаем новое блочное устройство /dev/mapper/drivespace. С полученным устройством можно работать как с обычным винтом.
В) Создание виртуальной разбивки на разделы(LVM)
Можно создать обычные разделы и отформатировать их, но такой способ не позволит в будущем расширять наши разделы(придется добавлять новые) поэтому воспользуемся технологией LVM. Вкратце она позволяет в любой момент добавить новые винты в пул и расширить логические разделы на добавленное свободное место. Мой LiveCD загрузился без нужных пакетов поэтому сначала устанавливаем их, а потом создаем из нашего расшифрованного винта физический раздел и делим его на логические.
sudo su
apt-get install lvm2
pvcreate /dev/mapper/drivespace
vgcreate vg /dev/mapper/drivespace
lvcreate -L1G -nswap vg
lvcreate -L3G -nroot vg
lvcreate -l 100%FREE -ndata vg

Теперь у нас есть еще 3 блочных устройства /dev/mapper/vg-swap /dev/mapper/vg-root /dev/mapper/vg-data. Форматируем их в нужные ФС.
sudo su
mkswap /dev/mapper/vg-swap
mkfs.ext4 /dev/mapper/vg-root
mkfs.xfs /dev/mapper/vg-data

Все! Наш винт готов к переносу ОС на него. Для подготовки системы нам понадобятся UUIDы винта и разделов потому сохраним их в файл на флешке
ls -l /dev/disk/by-uuid >/mnt/flash/uuid.txt

ЭТАП 2. Подготовка операционной системы


А) Установка системы
Устанавливать нашу ОС нужно либо на отдельный винт, либо на втором компьютере(вирт. машине). Перед установкой подключаем нашу флешку. Установку лучше делать в минимальной конфигурации, настройки выбираете под свои нужды. Единственный важный момент — нужно указать чтобы /boot устанавливался на второй раздел флешки сразу же(чтобы потом не переносить) и убедится что загрузчик Grub будет поставлен на флешку.
Б) Установка дополнительных пакетов, изменение настроек
После завершения установки нам нужно добавить в систему пакеты для поддержки шифрования и LVM и подправить некоторые конфиги. Устанавливаем пакеты(при подключеном инете):
sudo apt-get -y install cryptsetup lvm2
Правим конфиг GRUB. В Ubuntu используется GRUB2, потому правим /boot/grub/grub.cfg. Ищем menuentry «Ubuntu, Linux 2.6.31-14-server» и чуть ниже меняем
linux   /vmlinuz-2.6.31-14-server root=UUID=9a651089-88fa-46d6-b547-38d3e10d4e67 ro   quiet splash

на
linux   /vmlinuz-2.6.31-14-server root=/dev/mapper/vg-root ro   quiet splash

Правим /etc/fstab
proc            /proc           proc    defaults        0       0
UUID=eb7f5e37-b957-43dd-8af6-3c8983670df5       /boot           ext2    defaults        0       2
/dev/mapper/vg-root       /               ext4    errors=remount-ro 0       1
/dev/mapper/vg-data      /home           xfs     defaults        0       1
/dev/mapper/vg-swap       none            swap    sw              0       0

Для /boot точку монтирования указываем в виде UUID второго раздела флешки(можно взять с файла на флешке или посмотреть заново в системе), это нужно чтобы система всегда монтировала правильный раздел независимо от количества подключенных флешек/винтов.
Правим /etc/crypttab
drivespace   UUID=090d14c1-e3c8-48e7-b123-6d9b8b2e502b       /boot/mykey      luks,cipher=aes-cbc-essiv:sha256

тут указываем UUID от нашего шифрованного винта(смотрим его в файле на флешке)
В) Изменение initrd
Подготавливаем initrd для работы с шифрованием и LVM. В файле /etc/initramfs-tools/modules добавляем:
dm_mod
dm_crypt
sha256
aes_generic

Создаем файл /etc/initramfs-tools/hooks/cryptokeys с таким скриптом:
PREREQ=""

prereqs()
{
        echo "$PREREQ"
}

case $1 in
prereqs)
        prereqs
        exit 0
        ;;
esac

if [ ! -x /sbin/cryptsetup ]; then
        exit 0
fi

. /usr/share/initramfs-tools/hook-functions
mkdir ${DESTDIR}/etc/console
cp /boot/mykey ${DESTDIR}/etc/console
copy_exec /sbin/cryptsetup /sbin

Он скопирует наш файл-ключ в необычное место внутри образа initrd, чтобы лишний раз флешку не монтировать. Создаем файл /etc/initramfs-tools/scripts/local-top/cryptokeys со скриптом:
PREREQ="udev"

prereqs()
{
        echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac
modprobe -b dm_crypt
modprobe -b aes_generic
modprobe -b sha256

while ! /sbin/cryptsetup -d=/etc/console/mykey luksOpen /dev/disk/by-uuid/090d14c1-e3c8-48e7-b123-6d9b8b2e502b drivespace; do
       echo "Try again..."
done

Он выполнится в процессе загрузки initrd, загрузит нужные модули ядра и будет пытаться открыть наш зашифрованный винт с UUID=090d14c1-e3c8-48e7-b123-6d9b8b2e502b. (Цикл был сделан для случая с парольной фразой вместо ключа). Вам нужно вписать сюда свой UUID от зашифрованного винта.
Теперь выполняем:

sudo chmod +x /etc/initramfs-tools/hooks/cryptokeys
sudo chmod +x /etc/initramfs-tools/scripts/local-top/cryptokeys
sudo update-initramfs -u -k all

Г) Упаковка системы для переноса
Смонтируем наш раздел с корневой фс в отдельную папку и упакуем на первый раздел флешки:
mkdir /mnt/root && mount /dev/sda1 /mnt/root && cd /mnt/root
tar cfjv /mnt/flash/systembackup.tar.bz2 .  #НЕ ПРОПУСТИТЕ ТОЧКУ В КОНЦЕ СТРОКИ

Теперь можно переносить систему.

ЭТАП 3. Перенос системы


Тут все просто: подключаем нашу флешку с бекапом, загружаемся с LiveCD, подключаем шифрованный винт, устанавливаем пакет поддержки LVM, монтируем виртуальный корневой раздел(возможно сначала придется выполнить vgscan и vgmknodes чтобы система увидела разделы), монтируем флешку и распаковываем архив с системой.
sudo su
mkdir /mnt/flash 
mount /dev/sdb1 /mnt/flash
cryptsetup -d=/mnt/flash/mykey luksOpen /dev/disk/by-uuid/090d14c1-e3c8-48e7-b123-6d9b8b2e502b drivespace
apt-get install lvm2
#vgscan && vgchange -a y && vgmknodes vg  #Выполняем если система не увидела виртуальные разделы
mkdir /mnt/root
mount /dev/mapper/vg-root /mnt/root
mkdir /mnt/root/home
mount /dev/mapper/vg-home /mnt/root/home
cp /mnt/flash/systembackup.tar.bz2 /mnt/root && cd /mnt/root  #переносим архив на винт, для ускорения распаковки
tar xfvj systembackup.tar.bz2

Ну вот и все, перезагружаем компьютер и загружаемся с флешки. Если все сделано правильно, то через несколько секунд вы увидите надпись Key slot 0 unlocked, значит ваш винт расшифровался и подключился, после этого пойдет стандартная загрузка системы.

Примечания, источники


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

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

Обязательно сделайте копию своего ключа, чтобы не потерять доступ к своим данным. Также неплохой идеей будет добавить второй ключ в виде пароля(как это сделать можно прочитать в документации LUKS/cryptsetup). Организация устойчивого к сбоям хранилища на основе RAID1,5,6 также будет не лишней при хранении ценной инфы.

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

LUKS Википедия
LVM
EncryptedFilesystemHowto5 — самая полезная из найденных мной статей, практически все делалось по ней.
UPD Внес исправление в команду шифрования винта. За замечание спасибо ITpower
@FeNUMe
карма
35,0
рейтинг 0,1
Пользователь
Самое читаемое Разработка

Комментарии (198)

  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
      • +2
        к сожалению в гугле ничего другого подходящего по смыслу, размеру и нормальному виду не нашел(
        • НЛО прилетело и опубликовало эту надпись здесь
          • +2
            в статье убунту как пример. основной смысл шифрование винта в nix системах.
            • НЛО прилетело и опубликовало эту надпись здесь
              • +24
                Тогда уж лучше так



                :)
      • 0
        Тоже сразу в глаза бросились виндовые мотивы… подумал что еще одна статья из серии пароль на флешку c FAT32… всетаки картинка совсем не отображает содержание статьи, предлагаю поменять на вот эту img.brajeshwar.com/security.jpg
  • 0
    если не хотите морочиться с подобной натройкой у убу есть alternate диск, с которого можно установить подобную вещь из коробки, через текстовое меню. только вот я не помню, ам был вариант с созданием ключа или просто создание пасс-фразы
    но если руки не совсем прямые, то стоит поэксперементировать с ручным созданием/удалением разделов в LVM и подключением криптоконтейнера.
    • +1
      вы невнимательно читали, я же написал что убунту умеет шифрование и LVM из коробки, но там нужно сначала создать физический раздел на винте а потом уже в нем логический с шифрованием. и еще как я не крутил настройки мне не удалось там выбрать шифрование для раздела куда я ставлю корень системы. именно по этим причинам пришлось постаратся руками. вообще хоть текста много написано, но на самом деле это все просто делается в течении максимум часа.
      • +1
        Зачем шифровать раздел с корнем системы?
        • 0
          наверное для того чтобы нельзя было определить что за софт там используется, да и логи чтобы не увидели. Вот представьте вы провайдер небольшой локальной сетки, чтобы конкурировать с крупными провайдерами вам кроме качества и низких цен нужно как можно больше разных удобных сетевых сервисов(видеокаталог, музкаталог, софт, игры итд), но копирасты не спят и могут прийти к вам в любой момент. В этом случае даже если у вас будут зашифрованы сами нелицензионные данные, то по разным логам и службам которые крутятся на сервере можно будет всеравно доказать что вы всетаки виновны. А в случае с полностью шифрованым винтом: флешку выдернули, ресет нажали и все — проверке и понятым показываете нерабочий комп. Кстати еще интересная особенность(может ктото незнает) серверные nix ос прекрасно могут работать без видеокарты — еще один способ показать что комп не рабочий.
          • 0
            Тогда проще раздел /var зашифровать. Что интересного можно найти в /bin или /usr, скажем? Зато работа с шифрованного раздела будет медленнее, причем намного.
            • +4
              я тоже думал что будет медленней, но желание заказчика… а на деле оказалось практически без потерь как в скорости так и в загруженности проца, даже на sempron 2600+@1.6GHz. Вот теперь даже задумался о переводе домашнего NAS+seedbox на шифрованые разделы — хотя домой врядли придут, но чем черт не шутит.
            • 0
              Факт наличия данных можно найти.

              Пустой винт — это пустой винт. Вопросов ноль.
              Шифрованный винт — это уже другое дело. Вопросы будут, спасибо, если без применения физической силы.
      • +6
        дааа, твое кунгфу сильнее )))
      • +4
        достаточно сделать один раздел /boot не шифрованым, а все остальное пространство засунуть в шифрованый раздел с тем же LVM.
        • +1
          так все умные люди и делают. намного проще
        • 0
          А так же будет видно что что-то там есть? Ну так то проще конечно.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    > Создание виртуальной разбивки на разделы (LVM)

    Ничего особо виртуального в LVM нет.

    > правим /boot/grub/grub.cfg

    Потом, когда приходт время, обновляем ядро, конфиг генерируется заново, и мы снова правим…

    см. /etc/default/grub
    • –1
      в том то и дело что нет. специально проверял — после переноса с виртуалки на реальную машину, делал update-grub он и прописал эти настройки.(изначально я делал все на UUIDах). Также уже обновлял систему(включая ядро) и grub остался правильный, и initrd правильно пересобрался со всеми настройками. Вобще систему настраивал на максимальную переносимость и обновляемость.например, спокойно можно винт и флешку перетыкнуть в другой комп и все будет работать.

      Я понимаю что в LVM ничего виртуального, но целью статьи не было описывать данную технологию, поэтому постарался обьяснить самыми простыми словами. Согласитесь для тех кто незнаком с LVM понятия физические и логические разделы значат немного другие вещи.
      • 0
        > в том то и дело что нет

        Не знаю как там в Ubuntu (может быть и сделали какую-то логику для переноса пользовательских изменений), а у меня в Debian в grub.cfg написано капсом «DO NOT EDIT THIS FILE».
        • +1
          в убунту это тоже написано, файлы которые по логике граб2 надо править лежат тут /etc/grub.d, на их основании update-grub генерит grub.cfg. Но скрипты там как раз написаны с умом и они сами находят где находится корень и подставляют. в случае с обычными разделами вписываются UUIDы, ну а вот LVM прописало прямым путем
  • +2
    Интересная статья, но, если что то упадет, велика вероятность потери сразу всей информации, да и есть нюансы:
    — не всегда флешку выдернуть можно, а если сервер был и вдруг не стало, возникает много вопросов, которые могут привести к использованию «службами»
    -декрипторов использующих методы ректотермального криптоанализа :)
    • +3
      ну у нас в городе это решается довольно просто(естественно если вы не частное лицо), когда к вам приходит проверка — звоните адвокату и ищете понятых. когда адвокат приехал — демонстрируете всем что комп не работает, если будут всеравно забирать на «экспертизу» опечатываете комп полностью со своими подписями и требуете проведения экспертизы в вашем присутствии. Так вам не смогут подбросить никакого ДП и других прелестей… И еще сервер был и вдруг не стало, как они это докажут? А если докажут — ссылаетесь на то что это был общедоступный фтп, куда пользователи назаливали своей инфы, вы ее недавно увидели и форматнули все нафиг.
      Но всеравно хотелось бы услышать мнение юристов.

      на счет потери информации я не зря написал про RAID1,5,6 — если инфа ценная то стоит потратится на ее защитую
      • 0
        > вы ее недавно увидели и форматнули все нафиг.

        Только проблема в том, что LUKS виден — у формата есть незашифрованные служебные структуры и он обнаруживается на ура:

        % file /tmp/testluks
        /tmp/testluks: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: c352822e-0e91-44c8-b547-cf33b15


        Следовательно, опасность терморектального криптоанализа возрастает во много раз.

        Поэтому лучше использовать raw шифрование, тогда действительно зашифрованные данные будут выглядеть как просто случайный набор байтов и не подкопаешься.
        • 0
          Если мне не изменяет память, LUKS это унифицированный формат хранения ключей на диске который сделали для стандартизации существовавшего ранее зоопарка. До того как он появился люди хранили ключи в определённом секторе диска (или раздела) и руками выставляли смещение для расположения файловой системы. Поищите старые howto по dmcrypt или loop-aes.
          • 0
            Для тех, кто завладеет диском, разница примерно как между бетонной стеной и бронированной дверью с 33 замками. За первой может быть что-то и есть (а может и нет ничего). За второй — абсолютно точно что-то ценное.
  • 0
    В виндах под большинство требований подойдет TrueCrypt. Сам его юзаю для шифрования дистрибутивов софта.
    • +1
      А зачем шифровать дистрибутив софта?
      • +3
        наверное варезные дистрибутивы
      • 0
        Все труднонаходимое, что закрывают на рутрекере валяется там одной кучей, особо места не жрет.
  • +1
    Я вот тут (http://open-life.org/blog/paranoia/750.html) описывал практически идентичное решение для десктопов. В нём пофиксена работа с хибернейтом, а в вашем случае хибернейт работает? (Понятно, что серверам оно не надо, но если использовать на домашней машине/ноуте...)

    Единственное, что меня во всей этой теме не устраивает, так это максимальный размер ключа — 256 байт. Ведь эврестический анализатор какой-нить такой ключ относительно легко расшифрует. Как бы вот заюзать ключ эдак на 64 Мб?

    P.S.: сам пользуюсь таким шифрованием около 4-х месяцев — полёт нормальный.
    Единственное, при интенсивном чтении/записи соответствующий процесс ест немало ресурсов (до трети моего celeron'а 1.4 ГГц), а для серверов это серьёзный затык.

    Вот бы сделать тупой шифровальщик, который тупо шифрует xor'ом, но используя ключ произвольной длинны…
    • 0
      ключ можно выбирать любой длины самому. так как на самом деле шифруется винт совсем другим ключом, а пользовательський ключ только разблокирует к нему доступ(в служебной части шифрованого раздела). Почитайте описание LUKS.
      На счет Hibernate — не проверял, но если подумать — уверен что работать не будет. для домашних машин лучше использовать шифрование домашнего каталога, или сделать криптоконтейнер с ценной инфой и хранить гдето на дропбоксе.
      • 0
        Сколько не искал, нигде не нашёл упоминания, как настраивать длину мастер-ключа. Ткните пальцем, плиз.
        • 0
          AES256 — шифрование по алгоритму AES 256битным ключем.
          • 0
            Дык это я понимаю.

            Мне-то интересно, как бы сделать ключ по-больше.
            • +1
              выбрать алгоритм aes512 или aes1024, прочитав как их правильно выставить в мануале cryptsetup. Но я надеюсь вы понимаете что даже AES128 практически нереально взломать даже на нынешних суперкомпьютерах
              • –8
                Ну так 1024 бита — тоже мало. Хочется несколько метров.
                • +4
                  пожалуйста ознакомтесь с статьями о принцыпах работы данного шифрования, и о методах взлома. При таком шифровании которое описано в статье, единственный способ взломать ваш ключ, это выдернуть оперативу сразу после выключения, заморозить ее, а потом считать ключ с ячеек памяти. Никакими другими атаками ваш ключ добыть не удастся
                  • +1
                    В общем, из того, что я нашёл, интересно вот что:
                    на данный момент есть теоретическая атака на aes128, 192, 256 за примерно 2^100 итераций, что слишком много для нынешних вычислительных мощностей даже с учётом таких технологий, как CUDA.

                    Так что я более-менее спокоен теперь.
      • 0
        а вот я себе на буке это дело настроил.
        /boot — не шифрованый 300 метров, все остальное шифровано.
        второй мецсяц пошел — гибернатиться как положено, единственно — иногда дважды )) (уснул, будишь — снова усыпает, приходиться снова будить). ниодной ошибки.
        кстати, сделано нативным альтернатовским инсталятором.
    • +5
      Эвристический анализатор [в моей криптографии?]??
      Что я упустил в развитии тайнописи?

      64 Мб?
      У вас похоже, не просто детское порно, а прям порно-с-эмбрионами.
      И, думаю, 256 — байт, это не ключ, а passphrase, как PGP.

      Тупой шифровальщик?
      Вы описали шифр Шеннона, разновидность Вижинера с бесконечным ключом.
      Это хоть и тупой, но самый сильный метод, хотя и экономически неэффективный.
      • 0
        > Эвристический анализатор [в моей криптографии?]??

        Возможно, «эвристический» — неверное слово.
        Этот как Уотерхауз в Криптономиконе шифры взламывал.
        Я имел в виду, что когда злоумышленник предполагает, что в конкретном куске зашифрованных данных лежит какая-то стандартная комбинация байт (типа заголовка jpeg-файла или типичных имён файлов (home, .profile,..) или начало таблицы прав доступа пользователей mysql), то теоретически можно вычислять часть ключа или весь ключ. Например, если мы шифруем просто xor'ом, то зная часть зашифрованных данных мы можем получить ключ тем же xor'ом. Так вот, чем больше ключ, тем больше зашифрованных данных надо знать. Знать 64Мб подряд идущих данных.

        > Это хоть и тупой, но самый сильный метод, хотя и экономически неэффективный.
        Почему экономически неэффективный? 64Мб хранить в памяти мне не дорого.
        • 0
          для этого и делается запись всего винта рандомными данными, чтобы нельзя никак было определить где инфа, а где муссор.
          • 0
            Ну и что? Где конкретно физически находится известный злоумышленникам блок данных, им тоже не известно. Но он там есть, и представляет опасность даже если занято 0.00001% на этом разделе.

            Если злоумышленники получат таким образом ключ, они смогут увидеть раздел так, как его вижу я.
            А я тоже не знаю, где у меня физически на винте мусор, а где данные.
            • +1
              Именно для этого в криптосистемах для дисков применяются разные алгоритмы смешения криптотекстов. Например блок может использовать криптотекст предыдущего для модификации исходного открытого текста. Посмотрите про CBC и XTS например.

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

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

              Поэтому 64 мегабайтный ключ не имеет смысла, а только замедлит работу, ведь придется шифровать по 64 (возможно меньше или больше) мегабайта за раз.
              • 0
                Извините, верно так:
                Для защиты от обращения ключа по известному ОТКРЫТОМУ тексту применяют множество раундов шифрования и перемешивание ключевой информации.
              • –2
                > Поэтому 64 мегабайтный ключ не имеет смысла, а только замедлит работу,
                > ведь придется шифровать по 64 (возможно меньше или больше) мегабайта за раз.

                А вот если шифровать xor'ом, то не придётся, ибо это побитовая операция =)
                • 0
                  Хе, ну тогда наверное проще использовать стойкие алгоритмы ведь так? :)
          • 0
            Тогда лучше было бы забивать случайной информацией уже после зашифрования, тогда бы шифр выдал вам случайную последовательность еще лучших характеристик.

            А /dev/random является криптостойким генератором случайных последовательностей?
        • +1
          Для этого используется ...-cbc-essiv:sha256
          en.wikipedia.org/wiki/Disk_encryption_theory#ESSIV
  • +7
    Аааа капут, 2 года назад заморочался по подобной технологией для своей организации

    На виртуалках эксперементы проводил, но в энтерпрайз так и не ввёл. А тут не статья, а просто подарок :)
    Спасибо.
  • 0
    есть пару вопросов, (а) шифрование влияет на производительность (и как)? (б) ключ находится на флешки, и по приходу заберут и флешку и комп, и к чему это?
    • 0
      а) естественно шифрование влияет на производительность, но не так сильно как все думают — в моем случае примерно 5-10% процессорного времени кушалось на шифрование. но это на старом и слабом проце, на современных думаю даже не почувствуете(конечно если это не высоконагруженый сервер).
      б) а это уже ваша задача сделать так чтобы флешку не увидели и не забрали. можно конечно делать без флешки — выделить маленький раздел под загрузчик на винте, а вместо файла ключа использовать пароль — но тогда в явном виде будет то что система зашифрована. Тоесть, умышленное правонарушение если смогут доказать. Вообще хоть и можно построить очень гибкие и хитрые схемы загрузки, но 100% защиты не даст. К тому всегда остается человеческий фактор.
      • 0
        После загрузки системы флэшку можно выдернуть?
        • +1
          да естественно можно выдернуть, она нужна только когда вы загружаете систему, либо проводите обновление некоторых пакетов
      • 0
        > можно конечно делать без флешки — выделить маленький раздел под загрузчик на винте

        PXE. Я так понимаю груб и вся кухня занимает в пределах нескольких метров, так что особых проблем, даже по сети из удалённого ДЦ, быть не должно.
        • 0
          Именно PXE здесь не катит — потому что работает через бродкасты. Из локалки — да, можно, а из удаленного ДЦ — нет. Ну или прямой кабель до ДЦ кинуть :)
          • 0
            В ЦОДе может и не один сервер стоять.
  • +7
    Я не понял, зачем следует шифровать ОС. Ну стоит линукс и стоит. Можно ещё для паранойи невинный home положить с профилем хомячка.

    Вся ценная инфа — в home. Настоящий home шифруется, монтируется при логине/авторизационном токене.

    Кстати, исходя из общей паранойи хранить токен на едином носителе — чревато. Изымут, и что дальше? Куда интереснее хранить две половинки токена: одна на флеше, вторая в www и в зашифрованном (обычным симметричным алгоритмом с паролем) на той же флеше. При загрузке половинка ключа берётся с флешки, половинка из интернета (ака халявный сайт где-нибудь за бугром). Если сайт умер — половинка есть в зашифрованном виде. Если флешку изъяли, то удалить сайт можно пост-фактум изъятия техники.
    • 0
      а логи? а своп? а кеши днс? нее…
      • 0
        А кто мешает вместо /var/log сделать симлинк на что-нить вида /path/to/my/crypted/volume/var/log и тд.?

        Своп тоже нормально засовывается в криптоконтейнер.
        • +1
          Что такого крамольного можно найти в /var у обычной машины?

          (не поленился, пошарился в var у себя)

          /var/backups — только жутко системное и никому не нужное (aptitude, dpkg, shadow/passwd)
          /var/cache/ — из всего нашёл только кеш hal'а (злобный милиционер может прочитать список втыкавшейся переферии).
          /var/games. Это уже серьёзно — тут хранятся общесистемные рекорды. Милиционер, узнав, что его рекорд в клоцки детский лепет по сравнению с подозреваемым, разумеется, вкатает ему за это 10 лет без права переписки.
          /var/lib,lib64 — обычная система
          /var/mail — для пользователей, у которых нет локального MTA это нафиг не сдалось. Остальные сами знают, что с этим делать.
          /var/run с пачкой pid'ов — секретно.
          /var/spool — аналогично
          /var/tmp — ну, пожалуй, тут серьёзнее. У меня там оказалось аж три crashlog'а от оперы.
          /var/www на обычных системах пустой.
          Остаётся /var/log.

          apache2, apt, cana, cups, dbconfig-common, fsck, gdm, installer, mysql, news, sysstat, unattented upgrades, xen, Xorg, atop, messages, system, dmesg, mail.log, kern.log, faillog, ppp-connect-error, user.log, uucp.log.

          Ничего крамального. С тем же успехом можно содержимое mbr прятать.
          • +3
            Как минимум, можно уже найти следы присутствия криптосистемы. А это уже пол шага к терморектальному криптоанализу. Одно дело когда морду кирпичом («новый винт и все тут. покупали с рук, так что видимо предыдущий владелец забил шумом для надежности»), и совсем другое когда явно видно что открытая часть — это только верхушка айсберга
            • 0
              Мы говорим про ректоанализ или про общение с правоохранительными органами? При всём моём недоверии к сотрудникам, я всё-таки полагаю, что наличие средств шифрации не сделает их агрессивнее. Если у них возникла задача сделать плохо, то они это сделают куда более простыми методами, чем доказательство нарушения авторских прав, наличие цп, экстремистских материалов и прочие мелочи (достаточно «найти» сколько-то грамм известных веществ в системном блоке).

              Если же по какой-то причине сотрудники не имеют злых намерений (такое иногда бывает), то криптосистема не вызовет никаких особых проблем. Ну да, порнушку с последней пьянки с своим участием храню. Нет, показывать не хочу. Остальное с адвокатом.
              • 0
                а вы знаете в наших-то кпз/сизо — бьют-с… иногда даже слоников вызывают…
      • 0
        Логи системные. И ничего интересного в них нет. Ну ругнётся там пару раз ядро на shrinking window и что? Кеш DNS, это что-то новенькое. Не подскажете, и в каком это файле хранится кеш DNS. Если вы хотели сказать про кеш браузера, то он, обычно (хоть и в нарушение стандартов) хранится в ~. Своп… ну, в теории он есть. На практике, никто не мешает вам его выключить. Благо, что на современных машинах своп — лишь защита от мгновенной смерти программ при появлении memory leak (пока свопится, всё тормозится и есть время прибить нужное, а не первое попавшееся oom killer'у). Жить можно и без свопа.

        В принципе, перед тем как шифровать, нужно решить, что шифровать, от кого, и какая от этого шифрования польза. А так же напрячься и поставить себя на место противника и попытаться придумать, как это обойти.
  • –2
    Зачем такая сложная система? Тем более шифрование системных файлов неприятно скажется на скорости работы. В Ubuntu уже есть встроенное, отлаженное, простое и надёжное шифрование домашних папок пользователя. Мне кажется, это гораздо более практичное решение. (Для параноика нужно только swap ещё шифровать)
    • +1
      это решение полностью основано на системе шифрования которая используется в убунту, но оно руками настроено дополнительно для немного иных целей чем шифрование домашних папок пользователей.
    • 0
      +1. Какой смысл шифровать систему? У вас порнографический bind или нелицензионный vi?
      • +1
        у меня настроены вебсервер/фтпсервер/база данных с описаниями контента и все это ведет логи в добавок к конфигам которые описывают ранее доступный сервер.
        • 0
          Я так понимаю, что выносить надо только контент. Если сайт серьезный (а иначе какой смысл шифроваться), то видео и аудио и так должно быть вынесно на отдельный сервер для распределения нагрузки. Его и тогось — на шифровку.

          Но допускаю, что кому-то надо вообще все шифровать. Хотя такой сценарий с трудом представляется.
          • 0
            намного легче отвертется показав полностью нерабочий комьютер, чем рабочий но с шифрованым контентом(за шифрование могут пришить умышленное нарушение)
            • 0
              В этом смысле, вероятно, да. Другое дело, что шифрованое содержание не определяется как шифроконтейнер (трукрипт, по крайней мере), а видится как своп.
              • –1
                при использовании trucrypt нельза зашифровать весь винт с системой(
                • 0
                  Ну-ну-ну. Не надо так бросаться словами. Виндовый шифруется, линуксовый — нет.
                  • 0
                    я не бросаюсь словами. просто натыкался на такую информацию в одной из статей о trucrypt, возможно там была устаревшая информация, я не проверял — решил использовать встроеные средства.
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
      • –2
        вы не внимательно читали) у меня также как у вас — винт шифруется Luksом, внутри шифроблока создана LVM на которой стоит система и хранятся данные. на флешке хранится образ initrd(маленький линукс, если не ошибаюсь selinux) он загружается в память, подключает зашифрованый винт с помощью ключа с флешки(можно вместо ключа поставить запрос пароля) и потом уже загружается система.
        • +2
          initrd не маленький линукс
          www.opennet.ru/base/sys/initrd_intro.txt.html
          • –1
            я просто люблю все упрощать:) иначе получается сильно много текста
  • +2
    Осталось представителям оганов прочитать статью (наверняка у них не только дураки работают), потребовать от администрации Хабра список всех, кто добавил статью в закладки и заявиться к ним ища в первую очеред ключевую флэшку. А потом можно впаять заодно ещё нелицензированное использование стойкого шифрования.
    • 0
      если так мыслить то орагны должны гонятся за миллионами пользователей которые прочитали статьи из серии «как обмануть закон, чтобы не пострадать от его неверного применения»
    • +1
      Так что флэшку лучше замаскировать, например вот так:
      www.temm.ru/ru/section.php?docId=4375
    • 0
      Лицензии нужны только организациям, ЕМНИП.
    • 0
      >>А потом можно впаять заодно ещё нелицензированное использование стойкого шифрования.
      Не понял, как за это могут засудить? я что не имею право шифровать свои данные?
      • +2
        нет, ибо вы нарушаете конституционное право ФСБ рыться в ваших файлах
      • 0
        нет, из-за копирайта на фразу пароля
    • 0
      Использование шифрования не лицензируется. Продавать — это да, требуется сертификат.

      Кстати, меня умиляют шифрующие с помощью флешки. На нормальную криптографическую смарт-карту их жаба душит? Там пин-код, если что, защита какая-никакая.
      • 0
        Смарт карта это уже подозрительно в случае «нового» компа с «чистыми» винтами.
      • 0
        Отныне и вовеки веков — запрещено. И продавать и использовать. Всем. Правда, не понятно, какое за это наказание кроме общественного порицания.
        • 0
          Нет наказания, нет запрета. (в любом случае, жду пруфлинков, причём, желательно, не на президента Грузии Украины).
  • 0
    Статья отличная. Но возник вопрос такой. Если ставить свой сервер в чужом датацентре — насколько реально поднять (автоматически или удаленно руками) такой сервер при перезагрузке? Понятное дело что не охота втыкать туда флешку, а если и втыкать, то она не должна содержать ключа.
    • +1
      в датацентре можно не использовать флешку, а выделить всетаки на винте небольшой раздел для загрузочной системы который будет ключ брать с какогото сайта, расшифровывать винт и загружать основную ОС. естественно это сложнее реализовать, но не намного. В итоге если сервер выключили органы и забрали — сразу блокируете доступ к ключу и все сервер у них не включится. Но в любом случае прийдется доказывать что не верблюд. Думаю в датацентре оптимальнее поставить просто чистую систему-обманку, а потом вручную подключать шифрованый раздел на винте со всем необходимым — но работы конечно прийдется проделать не мало.
      • 0
        Ой, да что вы «немало».

        Делается правильная система. В смысле, реально рабочая. Кладётся в шифрованный контейнер. Контейнер кладётся в минимально необходимую для загрузки/подключения систему. А дальше подключаем, чрут, и работаем. Всех делов-то. Линукс, однако.

        PS Извращенцы могут поднять xencloud с ipsec шифрованием транспорта до storage repository, ha и live migration для уносимой спецслужбами виртуалки. (миграция 1-2с на обычном десктопоподобном железе).
    • +1
      Думаю что никак. Более того, хорошенько настроив и стартанув сервак с флэшки, саму флэшку луше где-нибудь на даче (причём желательно не своей) закопать. :-)

      В принципе можно поднять сеть таких серваков и развернуть на них распределённую ФС с избыточностью (такую, что при выпадении нескольких узлов, данные не теряются). В результате каждый сервак после изъятия будет становиться «кирпичом», пока не будет загружен с надёжно спрятанной флэшки, а система целиком будет функционировать.

      При этом злоумышленники в форме могут попытаться устроить ловушку, специально отключив сервер и ожидая когда вы приедете с флэшкой его перезагружать. Поэтому выпавший сревак лучше не перезагружать, а просто забирать через какое-то время, форматировать и пускать в дело под другую задачу или продавать.
    • 0
      есть в инте множество мануалов по тому, как настроить dropbox для предварительной загрузки ssh, чтобы можно было ввессти пароль на криптораздел для дальнейшей загрузки (после успешной операции этот ssh убивается)
      • 0
        тоесть busybox + dropbear///
  • 0
    Если рассматривать все это применительно именно к медиасерверу (тяжелый контент) и предположить что он дует в максимуме гигабит, т.е. читает по 100Мб в секунду с дисков (на самом деле минимум в 1,5 раза больше) — сколько CPU потребуется для расшифровки?
    • 0
      к сожалению пока статистика не набралась, сервер только недавно поставили и не особо афишировали в процесе подгонки сайта и наполнения контентом. Ну и пока это делалось только для музыкального сервера… При попытках стрестеста(заход 100-200 чел одновременно) апач почти намертво вешал систему(дефолтный конфиг был и всего 512озу), но процес дешифровщика больше 5-15% процентов не сьедал. В общем наберется какаято статистика — дополню пост, или напишу новый
      • 0
        мне кажется тут гораздо интереснее получить чистую цифру — сделать копирование чего пожирнее в /dev/null и посмотреть на скорость чтения и на CPU. Сделайте, плиз. :)
        • 0
          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… пока тестовое

          load average: 0.45, 0.24, 0.12
        • –1
          для нагруженых серверов лучше правильно подбирать железо, современные процы от интела(i5,i7) поддерживают апаратное шифрование AES ускорить процесс и разгрузить процессор.
          • –1
            Да только софта исспользующего эти инструкции пока минимум.
            • 0
              буквально весь :)
      • 0
        truecrypt обещает ~150 МБ сек при 100% загрузке одного ядра Core1Duo (1,8 ГГц).
  • 0
    когда прибегают маски-шоу все флешки тоже изымают и вообще все, что могут найти, так что не забудьте держать молоток на готове, чтобы ее вовремя уничтожить
    • –1
      в случаях с нарушением копирайта у нас маскишоу не прибегают. обычные менты, следователи, понятые…
    • +1
      Личные вещи не изымаются. Флешка может сойти за личную вещь. Но тут от ситуации много зависит.
      • 0
        Какие личный вещи? Реальный пример, пришли с автоматами, всем сказали поднять руки вверх, ничего не трогать и выйти из помещения. У вас другие маски шоу?
        • 0
          Ну вообще то да. Пока не приедет адвокат никто даже пальцем не дотронется ни до чего. Вот вы привели пример — и что у всех изъяли все мобильные телефоны или всетаки вернули? И рылись в личных вещах — в сумочках сотрудниц, например? Потому что, насколько я знаю, «руки вверх» — это всетаки чтобы сотрудники побыстрому бумажки не поели и к рубильникам не бросались.
      • 0
        Изымаются все носители информации, включая мобильные телефоны.
  • +1
    немного не в тему: интересная статья про популярную систему шифрования TrueCrypt (популярную в основном для альтернативной О$)
    theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html
    • 0
      В этой вещи один момент меня зацепил больше всего — должен быть позволен бут со сторонних девайсов — ведь штука прокручивается за счёт бутания машины-жертвы с «зловредного» носителя.
      У меня, например, бут разрешён только с харда, и BIOS setup под паролем. Такчто полюбому чтоб такую штуку провернуть надо вскрывать системник.
      • 0
        ну да, смысл в том что если у вас, например, украдут ноутбук, то сделать это будет вполне возможно
        • 0
          Мы кажется друг друга не поняли. Суть их Evil Made кита в том, что злобная програмка внедряется в загрузчик, и потом когда вы вводите пароль она его записывает или пересылает по сети.

          «All the attacker needs to do is to sneak into the user’s hotel room and boot the laptop from the Evil Maid USB Stick. After some 1-2 minutes, the target laptop’s gets infected with Evil Maid Sniffer that will record the disk encryption passphrase when the user enters it next time. As any smart user might have guessed already, this part is ideally suited to be performed by hotel maids, or people pretending to be them.

          So, after our victim gets back to the hotel room and powers up his or her laptop, the passphrase will be recorded and e.g. stored somewhere on the disk, or maybe transmitted over the network (not implemented in current version).»

          Тоесть если ваш ноут украдут чтоб открыть и внедрить злобную програмку, то потом его надо будет вернуть, дать вам ввести пароль, и тогда снова украсть (-:

          В принципе про защиту бута и/или БИОСа паролем там тоже есть:
          «Q: I've disabled boot from USB in BIOS and my BIOS is password protected, am I protected against EM?
          No. Taking out your HDD, hooking it up to a USB enclosure case and later installing it back to your laptop increases the attack time by some 5-15 minutes at most. A maid has to carry her own laptop to do this though.»

          Но, как видно отсюда, корпус для этого таки нужно вскрыть.
          Автор явно считает что злоумышленнику ничего не стоит вскрыть системник, но это может быть совсем не так просто (на некоторые системники можно замочек повесить например), и, кстати, совсем непросто если это ноут а не десктопный комп (спасибо вам что вспомнили о ноутах (-: ).
          • 0
            > Evil Made
            Прошу прощения, Evil Maid конечно-же
          • 0
            да, действительно нужно потрудиться :)
            но это вполне реально

            представляю себе горничную-хакера в гостинице, с отверткой вскрывающей ноутбук :)

            • 0
              Ну теоретически да (-:
              Я недавно апгрейдил хард в МакБук Про — мне понадобились 3 или 4 вида+размера отвёрток (одна крестовая, и вроде бы три разных размера Torx), подробная инструкция с фото, минут 40 времени и крепкие нервы (-:

              Системник с замочком вообще не знаю как так открыть чтоб потом не было заметно. Хотя признаю — замки обычно никто не вешает, такчто скорее всего evil maid легко преуспеет с десктопным ПК.
  • 0
    Можно кстати установить некий сервер ключей в интернете с управлением конкретными ключами. Сервер будет обслуживать сразу несколько серверов. Т.к. ключ используется только при загрузке — думаю проблем из-за этого не должно быть. Домен для сервера ключей и сам сервер ключей — естественно где-то забугром.
    В случае чего — смена имени сервера + обновление информации на подконтрольных серверах, кроме проблемного сервера.
    Так же можно на сервере сделать некую ловушку — по определённым криетриям окружающей сети делать какую-нибудь бяку.
  • –1
    Точно-точно!!! А после изъятия подать в суд на возмещение материального ущерба — типа брали сервер нормально функционирующий, а вернули нерабочий!!!
  • –8
    Пффф, ваша криптозащита легко взламывается… паяльником.
    • 0
      Блин, вот почему в топики про криптографию всегда набегает народу, которому надо одно — покритиковать.

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

      Это, наверное, какое-то психологическое отклонение — откритиковать всё, что можно.
      • +4
        Это какой то комплекс, связанный с применением инородных предметов ректально. Науке еще предстоит разобраться в этом вопросе. Британские ученые, думаю, раньше или позже придут нам на помощь и разъяснят суть явления.
    • –4
      Вы имеете в виду технологию ректальной термокриптографии? Ну так от этого никто не защищен.
  • 0
    По-моему мнению шифровать ВСЁ это плохая затея. Нужно шифровать только то что представляет ценность. Так или иначе придется отвечать на вопрос почему это у вас тут всё зашифровано…

    Тут более интересует вопрос в флешкой… приходят органы с маски шоу. и что? забирают сервер с флешкой, сомневаюсь что кто-то успеет выдернуть флешку и съесть :). дальше экспертиза, суд, Колыма. Тут нужно usb over ethernet решение, чтобы девайс стоял у ответственного или в не очень заметном месте.
    • 0
      Ну я бы аккуратно механически пристегул флешку к стойке. Типа как-только сервер пошевелили (собственно попытались вынуть) флешка выдернулась и всем отбой.

      >Так или иначе придется отвечать на вопрос почему это у вас тут всё зашифровано…
      Ничего не знаю. В настройках серверов не разбираюсь. Настраивал какой-то умный мужик с фриланса за пиво. Телефон его потерял.
      • 0
        Они по-вашему ее не заметят? Если даже стойка будет закрытая, то как пить дать найдут.

        >Ничего не знаю. В настройках серверов не разбираюсь. Настраивал какой-то >умный мужик с фриланса за пиво. Телефон его потерял.
        Думаю услышите фразу: «Ну, хорошо. Пойдемте повспоминаете в изоляторе я вам там как раз кампанию собрал».
        • 0
          замуровать ее в стену, в розетку или на фальшь-потолок закинуть. когда нужно- берется удлинитель, втыкается в комп и в розетку и грузится. вряд ли маски-шоу будут ломать стены. к тому же саму флешку можно повесить где угодно, не обязательно в той же розетке, ее можно даже за пределы офиса вытащить и где-нибудь среди проводов в электрошкафу приделать.
      • 0
        «А как же Вы тогда включаете сервер?» — спросят пытливые следователи.
        «А мы его не выключаем» — ловко попытаетесь выкрутиться Вы, но вряд ли Вам поверят.

        У меня другой вариант:
        Берём сервер, на нём создаём один большой файл, в котором у нас будет зашифрованный раздел.
        Рядом с ним скрипт, который скачивает из специального места в интернете ещё один скрипт, который содержит и команду монтирования зашифрованного раздела, и ключ.
        Т.о. если бандиты из органов изымут сервер, они не смогут понять, что в системе есть зашифрованные данные. А огромный файл вполне может быть базой данных — вполне обычное дело для серверов. И в ней могут даже лежать вполне настоящие данные в начале, в конце и в нескольких местах посередине (шифровальный блок будет знать, что эти куски надо игнорировать). А данные эти вполне могут быть даже завязаны на какую-то бизнес-логику фейковую, но это уже для совсем параноиков. Ну и здесь доп.оверхед на две ФС — ту, в которой лежит наш файл, и ту, которая в криптоконтейнере.
    • 0
      > забирают сервер с флешкой, сомневаюсь что кто-то успеет выдернуть флешку и съесть :)
      Где-то слышал что у Демоноида была так устроена защита: данные постоянно шифруются на ходу, флешка с ключём вставлена сзади в сервер — когда его достают она вытягивается сама собой, и данные шифруются уже не ключём а мусором, тоесть убиваются фактически. И когда сервер изымали, всё так и произошло.
      Надо будет погуглить пруф.
      • 0
        интересно, как она была вставлена =)
      • 0
        То есть типа сервер не выключают перед изъятием? Хм.
    • 0
      Ответ: там лежит интимное видео с моим участием. Показывать не буду. До свидания.
    • +2
      Как раз наоборот, лучше шифровать всё, чтобы меньше было вопросов «почему зашифровано».

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

        P.S. Замки они от честных людей. если не ошибаюсь самая «криптостойкая» дверь по самому защищенному классу должна продержаться 2 минуты 21 секунду.
  • –2
    Подобное шифрование спасет только от хороших людей.
    А у плохих людей криптоанализ сами знаете какой…

    • +1
      Грамотно выстроенная система от взлома терморектальным перебором спасает. От самого перебора не спасает, но от вскрытия — вполне.
  • 0
    ИМХО в качестве примера лучше приводить не torrents.ru (который с другим именем жив и здравствует), а примеры, когда маски-шоу выносят сервера из ДЦ, например как в случае с infostore.org и т.п.
    • 0
      я думаю о всех инцендентах все хабровчане давно прочитали и вкурсе, а торрентс упомянул только потому что с него начались активные обсуждения, а потом и действия властей
      • 0
        ну убили домен и… все. на этом действия властей заканчиваются. торренты продолжают раздаваться, ущерб минимален.
  • +2
    Я, кстати, представил картину — приходят следаки — стоит несколько стоек — куча серверов стоит, шуршит все, мигает лампочками. Изымают, а вместо серверов кирпичи.
    На вопрос — чего происходит владельцы скромно понурив голову и слегка шаркая ногой отвечают:
    — Ну это… сломалось чего то наверно.
    • 0
      Как говорил как-то мой преподаватель: «В случае если к тебе пришли из органов, главное быстро рассказать им всё пока тебя не сделали овощем». Из нескольких случаев встречи с представителями оных охотно ему верю.
      Терморектальный криптоанализ в действии.
      Ну и не знаю как сейчас, но раньше на исспользование шифрования нужно было получать разрешение у СБУ. Уже само его исспользование без разрешения было наказуемым.
      • 0
        пруфлинк на закон, пожалуйста.
        • 0
          Там непонятная ситуация — с одной стороны использование криптографических систем должно лицензироваться, с другой четко не прописано кем именно и зачем. Насколько я знаю, практики применения этой статьи к кому либо нет. А вот разговоры о законе возникают в каждой статье о шифровании.
          • +1
            Ответственности за использование криптографии без разрешения братьев наших больших нет? (За использование SSL, chap при dialup'е и т.д.) Тогда о чём разговор? У нас пока что разрешено всё, что не запрещено.
        • 0
          Пожалуйста:

          zakon.rada.gov.ua/cgi-bin/laws/main.cgi?nreg=505%2F98
          У К А З
          ПРЕЗИДЕНТА УКРАЇНИ

          Про Положення про порядок здійснення
          криптографічного захисту інформації в Україні


          Засоби криптографічного захисту службової інформації та
          криптосистеми з відповідного дозволу можуть перебувати і в
          недержавній власності.

          14. У разі порушення вимог щодо порядку здійснення
          криптографічного захисту інформації суб'єкти підприємницької
          діяльності, установи, організації посадові особи та громадяни
          несуть відповідальність згідно із законодавством України. ( Пункт

          Я не уверен на этот ли указ ссылались СБУшники когда зашла речь о шифровании или существует ещё что-то, но от них посыл был следующий, чтобы шифровать что-либо нужно получить от них разрешение и копию ключей им оставить иначе могут пришить криминал.
          • 0
            Ничего не понимаю. Не по-русски написано.
            • 0
              Автор топика просил ссылки на Украинское законодательство. Для России ищите, я слабо ориентируюсь в ваших источниках.
          • 0
            Ага вот здесь vi-leghas.ua/content/view/239/2/
            Что подпадает под лицензирование.
            «алгоритми з довжиною криптографічного ключа, що перевищує 56 біт для симетричних алгоритмів, або 512 біт для асиметричних алгоритмів обміну (розподілу) ключами, або 112 біт для алгоритмів по еліптичній кривій „
  • +1
    Статья отличная, небольшая поправка от меня:

    >Случайная информация берется из псевдогенератора случайных чисел и пишется на винт блоками по 2MB. Скорость генерации данных на Core Quad Q6600 составила всего 6Mb/сек, так что тестовый винт на 80Гиг заполнился за 4 часа.

    При работе с dd, везде советуют, чтобы ускорить в разы заполнение винта, выставить bs равный кешу диска — 8, 16, 32 Мб.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Извиняюсь. По первому предложению есть достоверные ссылки по теме?
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Вот и написали бы статью! Очень хочется «статей» по теме почитать.
    • 0
      см. мой комментарий ниже :)
  • 0
    Дарю идею.
    Кроме локального ключа для шифрование системного раздела использовать ключ, получаемый с другого сервера по IP и используемый для шифрования данных. Ясен перец второй сервер должен физически располагаться за пределами страны. Ясен перец, что файл ключа сервер должен отдавать по SSL и только одному единственному IP, а для всех остальных прикидываться валенком и не отвечать на ping. В случае ахтунга, второй сервер форматируем и кто бы вам что ни говорил — вы уже никаким боком не сможете расшифровать данные. Могут правда припаять вставление палок в колёса следствию, но для этого нужно доказать, что второй сервер принадлежит вам же, а умные люди его регистрируют в аФрике и не на себя.
    Итого:
    1) Шифрованный системый раздел с ключём на флэшке (или паролем), или вообще без шифрования.
    2) Шифрованный раздел со всеми данными с ключйм на другой компьютере, доступном по интернет.
    3) PROFIT и абсолютная криптостойкость даже к ректальному термокриптоанализу (будет больно, но бесполезно).
    • 0
      ах да. раздел с данными шифруем так, чтобы не было никаких заголовков (всякого рода truecrypt таковое умеют) и тогда ещё придётся доказать, что вот этот раздел не просто куча мусора, а зашифрованный контейнер.
      И получать по IP нужно не просто ключь а ещё скрипт, подклющий зашифрованный раздел (ясен перец, что скрипт класть на RAM-диск). Тогда на компьютере вообще нет никаких доказтельств присутсвия шифрованного раздела (покажите мне этот где и как раздел подключается!).
    • 0
      Да, и совсем уж маньяки могут на скрытом разделе держать целиком вторую систему и пускать её из под первой. Тогда в первой загрузочной системе будет только ядро и вообще никаких следов присутствия чего-либо полезного, включая логи, скрипты и библиотеки.
    • 0
      И на конец хит сезона!
      Второй компьютер (который ключ хранит), вообще не должен никому ничего отдавать! Компьютер с зашифрованным содержим лишь просто стучится хитрым HTTPS запросом на наш чудо-сервер (принимаются только запрыс с одного конкретного IP). Наш чудо-сервер в ответ лезет на сервер с зашифрованным содержимым по SSH, создаёт там RAM-диск, кладёт туда скрипты и ключи для шифрованного раздела и подключает шифрованный раздел.
      Ничего никак доказать не возможно в принципе. Если компьютер изъять, то на нём не будет ничего кроме единственного wget по дурацкому URL, который работать не будет (ибо IPO не тот). Вменяемый же хозяин при первых признаках шухера, запрещает чудо-серверу обрабатывать запросы от защищаемого сервера и всё — никто никак никаким боком не сможет доказать факт наличия присутствия каких-либо данных на защищаемом сервере.
      • 0
        чудо-сервер с ключами обучаем отключаться по получению сообщения от SMS-email шлюза. Одна СМС и данных нет.
        • 0
          и не просто отключаться но и потом заходить на защищаемый сервер по SSH и делать там shutdown. сугубо на случай маски-шоу и понятых — сервер неожиданно выключается сам по себе, а после включения чист и невинен, как слеза младенца.
  • 0
    Для сокрытия самого факта шифрования, дабы уберечься от терморектального криптоанализа
    полезно на диске сделать mbr, поставить туда венду и прочий фейк. Тогда при отсутствии флэшки сервер будет грузиться в венду. А то что в корзине стоит «пустой» винт — ну дык под замену.
    • 0
      А USB разъем сделать как розетку RG-45 а флеха в свиче.
    • 0
      Вообще-то можно определить и доказать что диск реально использовался не так уж и давно. Правда врядли в постсоветском пространстве будут этим заниматься.
      • 0
        ну не диск — раздел создай на нем под «мои картинки» для той же винды. а остальное место пусть будет «пустым». Да и цель — не доказать, а сокрыть от органов сам факт шифрования.
        • 0
          Можно определить что в «пустое» место активно производилась запись. Таким образом скрыть факт шифрования не очень то получится. При чем я не очень уверен, но уничтожение доказательств вроде похуже будет чем дача неправдивых показаний (если вас обвиняют по криминальному делу то вы вообще вправе наплести три короба, это будет называться «линия защиты»).
          • 0
            тут дело как раз в том, чтобы ни у кого не возникало идеи смотреть куда и что активно или не активно писалось. Поставьте винду XP с левой бухгалтерией, и никто ничего не будет проверять.
  • 0
    Если кому интересно, то вот более вменяемое описание предлагаемого мною решения:
    sap-ru.habrahabr.ru/blog/92022/
    Уж не знаю достойно ли это публикации на главную.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Подскажите пожалуйста, после этапа:
    «sudo cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 -d=/mnt/boot/mykey luksFormat /dev/sda
    Вас предупредят об уничтожении данных, для подтверждения нужно написать YES(большими буквами).»
    У меня после YES мне высвечивает «Enter LUKS passphrase: » потом подтверждение
    Что я должен ввести?
    • 0
      Enter LUKS passphrase:
      вас просят ввести пароль который вы хотите поставить на раздел. в моем же примере указан ключ -d=/mnt/boot/mykey который заменяет пароль.(возможно вы пропустили эту команду или ключ у вас не существует) Естественно можно оставить и парольную защиту — тогда при загрузке система будет вас спрашивать пароль. А можно сделать несколько ключей/паролей — технология LUKS предусматривает 8 ячеек под ключи/пароли
      • 0
        Дело в том что команда — sudo cryptsetup -d=/mnt/boot/mykey luksOpen /dev/sda drivespace
        идет уже после YES, как я могу ввести эту команду, если мне просят ввести Enter LUKS passphrase:?!
        • 0
          всеже вы не внимательны:
          sudo cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 -d=/mnt/boot/mykey luksFormat /dev/sda
          команда шифрует весь винт ключем -d=/mnt/boot/mykey, именно на это этапе уничтожаются данные и вводится YES

          sudo cryptsetup -d=/mnt/boot/mykey luksOpen /dev/sda drivespace
          команда подключает наш зашифрованый винт как блочное устройство /dev/mapper/drivespace. для подключения используется ключ -d=/mnt/boot/mykey
          • 0
            Я ввел команду, как вы и писали, sudo cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 -d=/mnt/boot/mykey luksFormat /dev/sda -> YES -> а потом мне Enter LUKS passphrase:, которого нету в описании
            • 0
              данный файл у вас в системе существует /mnt/boot/mykey?
              • 0
                Нашел такой файл (еще не вводил Enter LUKS passphrase:)

                PS Большое спасибо, что отвечаете на мои глупые вопросы!
                • 0
                  это файл-ключ который вы должны были создать на флешке еще на первом этапе. назвать его можно как угодно. его мы указываем програме шифрования, если его не существует или он у вас в другом месте находится то программа естественно будет предлагать шифрование паролем, а не файлом ключем.
              • 0
                Все таки хочу довести до конца. Вот видео goo.gl/GTwe
                Где я напортачил?
                • 0
                  мой косяк. вам нужно выполнить команду sudo cryptsetup -h=sha256 -c=aes-cbc-essiv:sha256 -s=256 luksFormat /dev/sda /mnt/boot/mykey. Сейчас поправлю в статье. Просто я сначала делал с доступом по паролю, а потом добавлял ключ — вот и спутал синтаксис. Спасибо за замечание.
                  • 0
                    Не ужели один я попробывал статью в действии :)
                    • 0
                      думаю все или сами прочитали cryptsetup --help или добавили статью в закладки до случая когда это понадобится.
                      • 0
                        После sudo cryptsetup -d=/mnt/boot/mykey luksOpen /dev/sda drivespace не попросило пароль
                        • 0
                          потому что тут уже синтаксис верный. не понимаю зачем разработчики сделали такое отличие
                          • 0
                            Мне не совсем понятно это — Единственный важный момент — нужно указать чтобы /boot устанавливался на второй раздел флешки сразу же(чтобы потом не переносить).
                            Как это? Поподробней на каком этапе установки
                            • 0
                              может перейдем в хабрапочту или аську? а то вложенность коментов уже слишком большая)

                              При установке системы есть этам когда нужно выбрать как разбить винт и куда систему ставить. Вот там надо выбрать ручную разбивку и указать в свойствах разделов что к ним будет монтироватся. Тоесть вам нужно зайти в свойства второго раздела на флешке и указать точку монтирования /boot
                              • 0
                                В хабрапочту. Аська стирается постоянно, а историю жаль. Ценная инфа.

                                На последок, для всех, Вы не против если я выложу лог терминала?
                                • +1
                                  конечно не против. всетаки это все писалось для помощи другим людям и если вы считаете что лог будет полезен — почемубы его не выложить.

                                  Ну и естественно я писал статью по памяти после сделаной работы, с некоторыми изменениями — потому в ней вполне могут быть такие вот ошибки как вышла с синтаксисом команды. Потому рад что вы проверили все и этим помогли исправить ошибку.
  • 0
    Может кто подскажит:
    Подошел уже к самому концу

    root@yakovubuntu-desktop:/home/yakovubuntu# sudo update-initramfs -u ALL
    update-initramfs: Generating /boot/initrd.img-2.6.31-14-generic
    root@yakovubuntu-desktop:/home/yakovubuntu# mkdir /mnt/root && mount /dev/mapper/vg-root /mnt/root && cd /mnt/root
    mount: специальное устройство /dev/mapper/vg-root не существует

    Кто-то уже пробывал на практике?
  • 0
    Насколько я понимаю, Live CD пишет какие-то временные файлы на диск. Получается, что полностью поверхность диска случайными данными заполнена не будет? Или нужен какой-то LiveCD, который целиком в памяти может работать?
    • 0
      livecd ничего на диск не пишут
      • 0
        Я запускаю Fedora с Live CD и вижу размер корневого раздела 3 Гб, а памяти всего 2 Гб. Это как возможно?
        • 0
          честно говоря федоровский ливсд пробовал давно и не помню его особенностей. возможно он у вас свап раздел как вирт память подхватывает? Но чтобы убедится что он ничего не пишет на винт — просто отключите винт(хотябы в биосе) и увидите что ливсд будет работать как и раньше.
  • 0
    Посмею сказать, что хауту нерабочий… :(
    Сделал всё по нему с убунтой 12.04 — при запуске отрабатывает initrd, начинает грузить систему и ядро паникует не находя рутовый раздел. Решил, что косяк в версии (мало ли что там каноники поменяли) и стал пробовать с указанной в статье 9.10 — абсолютно тоже самое… :(
    Строгое соответствие статье проверил несколько раз, со своей стороны ошибку практически исключаю.
    Когда руки уже совсем опустились (а секретный сервер-то нужен, учитывая нынешние реалии Рунета) — просто сделал всё стандартными средствами альтернейт-установщика. Фиг с ней, с маскировкой под новый винт. Виден только /boot/, а на всё остальное такой парольчик стоит, что проще на Луну слетать чем его подобрать.
    Но если автор поможет воплотить в жизнь эту реализацию — буду премного благодарен!

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

Интересные публикации