Асимметрично зашифрованная файловая система

Я провел некоторые исследования, кодировку и документацию; вот ссылка на сценарий использования...

https://github.com/S0AndS0/Perinoid_Pipes/blob/master/Documentation/Paranoid_Pipes_Scenario_One.md

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

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

Потому что журналы записываются на несколько строк за раз, делая одну сторону зашифрованной файловой системы немного поверх kill, и вне моих навыков, вместо этого сценарий автоматизирует установку определенного типа файла (mkfifo), который действует как именованная трубка, и набор правил сценария, которые слушают действия по записи в именованный трубный файл. Эта пара файлов затем генерирует третий файл, тот, который вы запрашивали, зашифрованный приложенный файл журнала, который хост не может прочитать. Операции сценария похожи на echo 'log message' | gpg -a -r email@host.domain >> server.log, выполняемый для каждого действия в журнале, но с именованным каналом вместо |, а логика сценария обрабатывает gpg'ing и добавляемый к файлу. Использование именованных каналов вместо анонимных каналов означает, что только выходной путь сервиса, генерирующего журнал, должен быть обновлен, чтобы использовать путь именованного канала вместо стандартного файла для использования шифровальных задач.

Обратите внимание, что есть и другие возможности, которые могут быть полезны уже запеченные в , которые позволяют шифровать и отправлять лог-файлы по электронной почте, когда они достигают заданного пользователем размера, эти возможности отделены друг от друга, чтобы позволить программе IDS/IPS разобрать лог-файлы или сделать отправленные лог-файлы еще более сложными для просмотра, когда они объединены с шифрованием на запись.

Редактирование/обновление: вы, возможно, захотите проверить сокращенный быстрый старт для другого вопроса, который был более общим по охвату, но достаточно похожим, чтобы гарантировать включение в ответ на этот вопрос.

https://security.stackexchange.com/a/138877/82480

Edit/Update: похоже, что ссылки в markdown на GitHub очень специфичны для браузера, так что вот копия сценария один из вышеперечисленных ссылок.

Настраиваемый сценарий использования для веб-сервера

• Скачайте и скопируйте сценарий в ${PATH} dir

```

git clone https://github.com/S0AndS0/Perinoid_Pipes
cd Perinoid_Pipes
cp Paranoid_Pipes.sh /usr/local/sbin/
chown ${USER}:${USER} /usr/local/sbin/Paranoid_Pipes.sh
chmod 700 /usr/local/sbin/Paranoid_Pipes.sh

````

• Покажите доступные опции командной строки и их текущие значения.

```

Paranoid_Pipes.sh --help

```

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

```

Paranoid_Pipes.sh --copy-save-yn='yes'\
 --copy-save-name="/jailer_scripts/website_host/Web_log_encrypter.sh"\
 --copy-save-ownership="notwwwuser:notwwwgroup"\
 --copy-save-permissions='100'\
 --debug-level='6'\
 --listener-quit-string='sOmErAnDoM_sTrInG_wItHoUt_SpAcEs_tHaT_iS_nOt_NoRmAlY_rEaD'\
 --log-level='0'\
 --named-pipe-name="/jailed_servers/website_host/var/log/www/access.log.pipe"\
 --named-pipe-ownership='notwwwuser:wwwgroup'\
 --named-pipe-permissions='420'\
 --output-parse-name="/jailed_logs/website_host/www_access.gpg"\
 --output-parse-recipient="user@host.domain"\
 --output-rotate-actions='compress-encrypt,remove-old'\
 --output-rotate-check-requency='25000'\
 --output-rotate-max-bites='8388608'\
 --output-rotate-recipient="user@host.domain"\
 --output-rotate-yn='yes'\
 --output-save-yn='yes'\
 --disown-yn='yes' --help

````

Обратите внимание, что если серверное приложение не находится в chroot-тюрьме, вы захотите изменить пути к файлам для именованного канала и копии скрипта, потому что выше предполагалось, что некоторая форма сегрегации файловой системы уже была реализована. Удалите --help сверху, чтобы сценарий выполнял действия вместо печати текущих значений опций командной строки.

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

Копия скрипта (сохраненная в --copy-save-name file path) - это то, что делает magic, прослушивая действия по записи в свой родственный ему именованный трубный файл, он проталкивает зарегистрированные строки через GnuPG и добавляет результаты (используя открытый ключ для --output-parse-recipient для начального шифрования) к файлу, указанному опцией командной строки --output-parse-name.

Результирующий зашифрованный лог-файл отслеживается на размер файла, и когда этот размер и счетчик записи достаточно велики, лог-файл перезашифровывается с использованием открытого ключа для -выходного-вращающегося-получателя и перемещается/переименовывается.

Если ваш сервер может отправлять электронную почту, то измените опции --output-rotate-rateactions, чтобы включить email в качестве действительного действия, и в конце концов дважды зашифрованные лога будут переданы.

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