Статья Проактивная и превентивная защита зашифрованных данных и средств шифрования в Linux

[stelthon]

Преамбула.

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

Итак, начнем.

Существует два основных вида шифрования перманентно хранимых данных в рамках файловых систем в linux. Мы рассматривает только программное шифрование:

1. Шифрование на уровне файловой системы.

При котором выборочно шифруются только определенные файлы или каталоги (например, /home/myuser). Однако шифрование на уровне файловой системы имеет вполне конкретные недостатки. Например, многие приложения кэшируют файлы в не зашифрованных частях пространства хранения данных, таких как раздел подкачки(swap), директории /tmp и /var, что соответственно может привести к утечкам данных. Для шифрования на уровне файловых систем было выбрано решение ecryptfs по причине его наибольшей распространенности и обкатанности.​

2. Блочное шифрование на уровне устройств.

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

Рассмотрим EcryptFS:

Рис 1. Общая архитектура EcryptFS.

Рис 2. Схема шифрования объекта (файла)

Система шифрования EcryptFS зашифровывает каждый файл по отдельности. Метаданные шифрования сохраняются в заголовке самого файла. Следовательно, как любой отдельный файл, так и директории целиком возможно беспрепятственно переносить между хостами. Это позволяет организовать систему прозрачного выделенного резервного копирования, когда переносятся и синхронизируются только те из зашифрованных файлов, которые были изменены, то есть фактически методом инкрементного копирования. Что делает ее так же весьма оптимальной с точки зрения производительности. Но то же самое время EcryptFS затрудняет использование функций дедупликации FS. Ведь в контексте работы с даной системой шифрования к каждому зашифрованному файлу применяется уникальная соль. А потому содержимое на первый взгляд идентичных файлов в зашифрованном виде всегда различно.
​

Инсталлируем программу в систему:

# apt-get install ecryptfs-utils ecryptfs-dkms

Создаем криптодиректорию ecryptfs:

Для swap раздела:

# sudo ecryptfs-setup-swap

Для текущего пользователя:

# ecryptfs-setup-private

Для определенного пользователя:

# ecryptfs-setup-private -u myuser

Пояснение: Далее достаточно ввести свой пароль, используемый для логина, и по новой аутентифицироваться в системе. Вот так просто. Первая команда отмонтирует, зашифрует и снова смонтирует swap раздел, изменив необходимые строки в /etc/fstab. Вторая и третья создают каталоги ~/.Private и ~/Private, расположенные предположительно в домашней директории пользователя myuser(если не указан другой пользователь или если программа была запущена без пользовательского параметра -u) и в которых будут храниться зашифрованные и расшифрованные файлы соответственно. При входе в систему будет задействован pam модуль pam_ecryptfs.so, который примонтирует первую(зашифрованную) директорию ко второй методом прозрачного шифрования данных. После же размонтирования, не зашифрованный ~/Private останется пуст, а вот зашифрованный ~/.Private будет содержать все файлы и уже в зашифрованном виде. По умолчанию используется алгоритм AES, но в ручном режиме можно задать другие варианты, перечень которых можно увидеть, изучив документацию.

Если вы не хотите, чтобы каталог ~/Private автоматически монтировался при входе в систему, просто добавьте параметр
--noautomount при запуске ecryptfs-setup-private. Точно так же, если вы не хотите, чтобы каталог ~/Private автоматически размонтировался после выхода из системы, укажите параметр --noautoumount. Но тогда вам придется вручную монтировать или размонтировать каталог ~/Private:​

# ecryptfs-mount-private ~/.Private ~/Private
# ecryptfs-umount-private ~/Private

Не возбраняется шифровать и весь домашний каталог целиком. Делается это так:

Для пользователя myuser:

# ecryptfs-migrate-home -u myuser

Если -u не указывать, будет создана криптодиректория для текущего пользователя.
Кстати, места на диске должно быть как минимум в 3 раза больше, чем данных в каталоге пользователя myuser на момент шифрования.​

Либо можно поступит следующим образом:

# mount -t ecryptfs /home/myuser /home/myuser

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

Отмонтировать криптораздел:

# ecryptfs-umount-private

Удалить зашифрованный каталог для текущего пользователя:

# ecryptfs-setup-private --remove

Для целевого пользователя:

# ecryptfs-setup-private --remove --user myuser

Радикальный метод удаления раздела:

# rm -rf /home/myuser/.Private

или более надежный способ:

# shred -u -n 3 /home/myuser/.Private

Удаляем только ключи:

# ecryptfs-recover-private

Вы можете использовать ecryptfs-add-passphrase для добавления пароля к вашему ключу:

# ecryptfs-add-passphrase --fnek

Будем считать, что с основами шифрования EcryptFS разобрались, при помощи одного из примеров выше создали зашифрованную директорию /home/myuser/.Private, все проверили, все работает.


Настало время разобраться с методом шифрованием уровня блочных устройств. Поехали!​

Создаем криптораздел и криптоконтейнер dmcrypt/luks:

Для шифрования разделов с данными вторым способом, то есть с применением блочного шифрования на уровне устройств, была выбрана утилита luks пакета dm-crypt(cryptsetup) по традиции, в виду широты своего функционала и относительной простой настройки. Глубоко вдаваться в теорию шифрования мы не будем, как и описывать все возможности cryptsetup(dm-crypt). Ограничимся лишь кратким описанием и практикой применения в рамках конкретной задачи.​

Рис 3. Заголовок и данные криптоконтейнера Luks/cryptsetup.

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

Установим необходимое ПО:

Вариант 1(классический):

# apt install cryptsetup

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

Вариант 2(более продвинутый в плане безопасности):

Открываем список репозиториев системы:

# vi /etc/apt/sources.list

Добавляем в него репозиторий kali linux:

deb http://http.kali.org/kali kali-rolling main contrib non-free

Затем выполняем update:

# apt update

Если выдало ошибку проверки ключей, выполняем ручную подпись репозитория:

# gpg --keyserver keyserver.ubuntu.com --recv-key ED444FF07D8D0BF6
# gpg --export --armor ED444FF07D8D0BF6 | sudo apt-key add -

Но могут быть нюансы с работой gpg, в последнее время этот инструмент по умолчанию пытается работать через сеть tor в том случае, если у вас установлен сам tor. Имейте это в виду. Кроме того, потенциально могут возникнуть осложнения в связи с разницей в версиях операционных систем, используемых библиотек, прикладных программ и актуальности и содержимого репозиториев целевого программного обеспечения.Теперь все должно быть нормально.​

Обновляем информацию о репозитории в системе, а так же сам cryptsetup:

# apt update
# apt install -y  cryptsetup cryptsetup-bin libcryptsetup12

Версия библиотеки в вашем случае может быть и другой.
Установку cryptsetup завершили. Разбираем то как это работает на практике.
Синтаксис запуска основной команды шифрования следующий:

# cryptsetup <options>  <operations>  <operations_params>

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

Рассмотрим основные операции, которые можно выполнить с помощью этой утилиты. Вот так выглядит весь процесс создания зашифрованного образа luks, который впоследствии монтируется к блочному устройству файлового раздела linux:​

1. # mkdir -p /home/lukspartition
2. # dd if=/dev/zero of=/home/luks.img bs=15M count=1000
3. # cryptsetup -y luksFormat /home/luks.img
4. # cryptsetup open /home/luks.img lukspartition
5. # cryptsetup resize lukspartition
6. # mkfs.ext4 -j /dev/mapper/lukspartition
7. # mount /dev/mapper/lukspartition /home/lukspartition

Если максимально кратко описать то что делается, то первая команда создает директорию в дереве каталогов linux в которую в дальнейшем будет смонтирован зашифрованный образ luks.img с файловой системой luks, который в свою очередь, создается второй командой, заполняющей его нулями, и который уже при помощи третьей команды luksFormat форматируется программой luks в специальный зашифрованный формат. Далее четвертая, luksOpen открывает зашифрованный образ путем расшифровки ключом и прикрепляет его к созданному этой же командой блочному устройству /dev/mapper/lukspartition. Пятая команда позволяет задать размер блочного криптоустройства, хотя данный пункт и необязателен, но бывает весьма полезен. Шестая команда накатывает файловую систему ext4 на зашифрованный образ через прикрепленное к нему блочное устройство, ну и наконец последняя, седьмая - монтирует блочное устройство в созданную в самом начале директорию lukspartition.​

Если мы по какой-либо причине захотим создать шифрованный образ более детализировано и гибко, пожалуйста, можно делать это с указанием дополнительных параметров согласно синтаксису команды:

# cryptsetup -c aes -s 256 luksFormat /dev/sda1

с - выбираем алгоритм шифрования. aes и так по умолчанию. (cписок доступных алгоритмов можно посмотреть тут: cat /proc/crypto)
s - длинна ключа

Все параметры и опции подробно разбирать не станем, если кому убдет интересно, для этого есть официальная документация. Единственное уточнение, вместо файлов-образов luks (таких как luks.img) одинаково успешно работает с блочными устройствами разделов и дисков. В данном случае, предположим что это /dev/sda1.​

Выяснить, является ли какой-либо раздел файловой системы в linux крипторазделом luks можно командой:

# cryptsetup isLuks -v /dev/sda1

Проверяем статус блочного устройства(список зашифрованных блочных устройств можно увидеть при помощи команды lsblk):

# cryptsetup -v status lukspartition

Проверяем заголовок luks:

# cryptsetup luksDump /dev/sda1

или в нашем случае:

# cryptsetup luksDump /home/luks.img

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

Рис 4. Часть служебной информации заголовка luks.
Смотрим слоты шифрования и наличие в них ключей:

# cryptsetup luksDump /home/luks.img | grep Slot

Рис 5. Слоты с ключами шифрования, хранящиеся в заголовке криптоконтейнера.

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

# umount /home/lukspartition
# cryptsetup close lukspartition (старый формат: cryptsetup luksClose lukspartition)

Для повторного монтирования нужно снова присоединить криптораздел к блочному устройству, а затем смонтировать этот раздел в свободную директорию:​

# cryptsetup open /home/luks.img lukspartition  (в старом формате: cryptsetup luksOpen /home/luks.img lukspartition)
# mount /dev/mapper/lukspartition /home/lukspartition

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

# dmsetup table --showkeys

Получаем приблизительно следующее:

Рис 6. Ключ шифрования luks.
​

Записываем ключ в текстовый файл:

# echo "706f441274a493a4b1e323fecfc5641eaa210e0ef2c6371de01cd103c8fadb8c" > keyfile.txt

Конвертируем его в бинарный формат представления:

# xxd -r -p keyfile.txt keyfile.bin

Записываем заново в слот со сменой пароля:

# cryptsetup luksAddKey /home/luks.img --master-key-file < (cat keyfile.bin)

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


Теперь пришло время посмотреть на проблему защиты данных с другой стороны. Проактивной. Предположим, чисто гипотетически, что принятые нами стандартные классические меры, несмотря на отчаянные усилия по обороне систем с данными не возымели успеха и взлом все-таки произошел. Ну вот не справились, злоумышленники таки нашли и проэксплуатировали неизвестную уязвимость в операционке или в сопуствующем прикладном ПО, в прошивках и так далее, и мы проиграли этап битвы в борьбе за доступ к нашим данным тем, кто страстно желал его получить. И что же делать, как быть в таком случае? Хвататься за голову, сдавать позиции, опускать руки? Нет! Однозначно нет, потому как даже в таком случае не все так ужасно и есть выход, одна из последних, но весьма отчаянных мер обороны, можно сказать последний резерв - по аналоги с армией Венка, пробивавшейся к Берлину весной 1945, в последние дни погибавшего Рейха в надежде остановить неминуемый его конец. Вот только в нашем случае мы отнюдь не Рейх, и армия наша(меры противодействия) никуда пробиваться не собирается, а тихо сидит в засаде в самом логове собственной системы-внутри хоста, выжидая подходящий момент чтобы испепелить врага изнутри. Правда к сожалению, пожертвовать придется и самими важными данными, а при определенных обстоятельствах жизнью всей системы вообще! Увы, это уже как получится. Но ведь в таких случаях сохранность, целостность данных и нескромпроментированный доступ к ним для нас гораздо важнее, чем целостность системы, которую впоследствии можно относительно легко восстановить.

Проактивная защита данных инфраструктуры:

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

1. Определить сами данные, подлежащие проактивной защите.
2. Обозначить красные линии обороны внутри системы, или проще сказать сигнальные точки с флажками.
3. Выбрать средства, обеспечивающие срабатывание триггеров при пересечении линий с флажками и выполнение задачи по удалению критических данных.

С определением местоположения данных мы уже разобрались в процессе их создания. Зашифрованные данные ecryptfs расположены в следующих местах:​

/home/myuser/.Private
Местонахождение ключей ecryptfs:
/home/myuser/.ecryptfs/wrapped-passphrase

С luks все тоже предельно понятно. Данные криптоконтейнера:

/home/luks.img
либо /dev/sda1 в случае если в качестве криптоконтейнера используется не файл-образ, а раздел.
Ключи расположены там же, в заголовке криптообраза либо криптораздела.

С триггерами чуть сложнее, так как здесь мы изначально имеем весьма широкий спектр критериев согласно которому мы можем устанавливать те или иные ограничители в контексте работы системы, определяющие степени критичности для оценки состояния целостности данных и привилегий доступов к ним. Для примеров в нашей статье мы возьмем некоторые наиболее простые варианты, которые нетрудно будет модифицировать под индивидуальные нужды при условия понимания того как они реализуются и применяются. Будем использовать штатные инструменты регистрации и реагирования операционной системы: udevd и dbus, которые в своем базовом исполнении предназначены для выполнения функций системной автоматизации различных компонент. А в нашем случае, они будут настроены на целенаправленную защиту от вторжений в качестве триггеров для ликвидации угроз в случае реагирования системы на определенные события.

Что касаемо инструментов применяемых непосредственно в удалении служебной информации и иных данных, то тут все совсем просто. Используем srm, эта утилита, как более надежная альтернатива rm или dd позволяет затирать данные в несколько проходов минимизируя возможность их восстановления с носителя. Но опять таки, в вашем случае и при вашем желании можно использовать любой инструмент, на свой страх и риск.

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

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

Поехали:

Триггер первый.

Используем UDEV. Если совсем кратко, то это система инициализации чего угодно в ответ на события, связанные с работой аппаратного обеспечения системы. Грубо говоря, udev можно настроить таким образом, изменении статуса любой характеристики любого аппаратного модуля системы, автоматически производились заранее определенные пользователем действия. Итак, создадим условие в механизме udevd, при котором любое подключение к порту usb инициирует удаление всех ключей шифрования всех имеющихся криптоконтейнеров, созданных нами ранее.
​

Создаем файл /etc/udev/rules.d/99-usb.rules со следующим содержимым:

SUBSYSTEMS=="usb", ACTION=="add", RUN+="/home/myuser/removedata.sh '$env{ID_SERIAL}' '$links' '$devnode'"

А можно чуть более детализировать, заставляя реагировать только на блочные устройства:

SUBSYSTEM=="block", SUBSYSTEMS=="usb", ACTION=="add", RUN+="/home/myuser/removedata.sh '$env{ID_SERIAL}' '$links' '$devnode'"

или реализовать таргетинг посредством детализации конкретного устройства по конкретным идентификаторам оборудования:

ATTR{idVendor}=="0480", ATTR{idProduct}=="a00d", ACTION=="add", RUN+="/home/myuser/removedata.sh '$env{ID_SERIAL}' '$links' '$devnode'"

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

Содержимое файла /home/myuser/removedata.sh:

#!/bin/bash
(cryptsetup close lukspartition && cryptsetup erase /home/luks.img) ;
(ecryptfs-umount-private ~/Private && srm /home/myuser/.ecryptfs/wrapped-passphrase)

После создания скрипта и правила реагирования(их может быть сколько угодно) делаем его исполняемым, а затем перезагрузим службу udev:​

# chmod +x /home/myuser/removedata.sh
# udevadm control --reload-rules && udevadm trigger

То есть, в случае подключения любого устройства на шину usb все имеющиеся ключи шифрования удаляются из мест их хранения, включая заголовки криптоконтейнеров, а доступ ко всем криптоконтейнерам немедленно прекращается. Но предварительно нужно не забыть сделать копию ключей чтобы после устранения угроз возможно было восстановить доступ к криптохранилищам. Для ecryptfs надо просто скопировать /home/myuser/.ecryptfs/wrapped-passphrase в безопасное место. А вот для luks это необходимо сделать это следующим образом:​

Сделать дамп ключа:

# cryptsetup luksDump --dump-master-key /home/luks.img

Команда luksHeaderBackup сначала cоздает резервную копию заголовка luks, а luksHeaderRestore его восстанавливает(в подходящий для этого момент):

# cryptsetup luksHeaderBackup --header-backup-file luksheader.back /home/luks.img
# cryptsetup luksHeaderRestore --header-backup-file luksheader.back /home/luks.img

Триггер второй.

Альтернативным вариантом реагирования выбрана системная шина DBUS. Позволяет делать примерно то же самое что и UDEV, только в качестве пускового механизма здесь выступает механизм межпроцессного взаимодействия(IPC) Linux. DBUS позволяет приложениям операционной системы взаимодействовать друг с другом, отправляя сообщения через специальную программную шину.Теперь давайте предположим, что нам необходимо удалить ключи шифрования в случае перезагрузки сети.​

Используем dbus-monitor:

#!/bin/bash
dbus-monitor --system "sender=org.freedesktop.NetworkManager, path=/org/freedesktop/NetworkManager, member=StateChanged" | \
sed -u -n 's/   uint32 70/network is restart/p' | while read -r line ;
do
(cryptsetup close lukspartition && cryptsetup erase /home/luks.img) ;
(ecryptfs-umount-private ~/Private && srm /home/myuser/.ecryptfs/wrapped-passphrase)
done

Помещаем в автозагрузку(без systemd):

chmod +x /etc/init.d/removedata.sh

Делаем ссылку на скрипт:

# cd /etc/rc2.d
# ln -s /etc/init.d/removedata.sh  /etc/rc2.d/

Теперь наш скрипт будет запускать dbus-монитор автоматически и необходимые данные будут успешно удалены.


Вот второй вариант(с применением systemd):

Создайте файл службы systemd, который будет отслеживать события D-Bus и запускать наш скрипт:

# vi /etc/systemd/system/network_monitor.service:

Содержимое файла сервис-юнита:

[Unit]
Description=Device Monitor


[Service]
Type=simple
ExecStart=/usr/bin/dbus-monitor --system "sender=org.freedesktop.NetworkManager, path=/org/freedesktop/NetworkManager, member=StateChanged" | sed -u -n 's/   uint32 70/network is restart/p' | while read line; do /etc/init.d/removedata.sh ; done


[Install]
WantedBy=multi-user.target

Содержимое скрипта /etc/init.d/removedata.sh:

#!/bin/bash
(cryptsetup close lukspartition && cryptsetup erase /home/luks.img) ;
(ecryptfs-umount-private ~/Private && srm /home/myuser/.ecryptfs/wrapped-passphrase)

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


Ну и напоследок, установим упомянутую ранее специальную функцию Nuke с секретным паролем для системы luks, но несколько другим способом, нежели это было сделано путем установки cryptsetup из отдельного репозитория kali. И в случае ввода такого пароля, например при начальной загрузке системы, либо при ручном монтировании криптораздела в файловую систему, доступ к зашифрованным данным будет моментально прекращен. Фактически будут стерты все ключи заголовка dmcrypt:​

Устанавливаем нужное нам ПО:

# apt install cryptsetup-nuke-password

Затем вводим команду инициализации специального пароля:

# dpkg-reconfigure cryptsetup-nuke-password

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

Рис 7. Установка ключа и пароля для удаления заголовка и ключей шифрования данных luks.


Вводим пароль, запоминаем и после установки пароля вводим следующую команду:

# update-initramfs -u

Хотя в большинстве случаев, данный этап инициируется автоматически после создания пароля на удаление.

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

Для повышения безопасности рекомендуется разбить диск на разделы и отделить файлы операционной системы от файлов пользователя, сторонних программ и временных файлов. Этого можно добиться, отключив SUID/SGID-доступ (nosuid) и запретив выполнение исполняемых файлов (noexec) на разделе с операционной системой.

В дополнение так же рекомендую сделать следующее:

Правим свой .bashrc:

alias rm='srm'

Сохраняем, и теперь вместо rm каждый раз будет выполняться более надежный srm-)

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

Спасибо за внимание-)


Автор(stelthon): https://xss.pro/members/376546
Специально для xss.pro

 

[keklick1337]

alias rm=’srm’

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

 

[stelthon]

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

Это не прикол и конечно не ГПТ( в отличие от некоторых-), команда полностью рабочая. Когда писал-все делал и проверял и все прекрасно выполняется, возможно на некоторых терминалах распознается иначе, хотя возможно что при переносе из одного источника информации в своих архивах в статью поменялось форматировании текста. Такое бывает когда различная раскладка используется. И вы не смущайтесь, смело задавайте вопросы.

А за замечание спасибо, поправил кавычки.