Права доступа к файлам, созданным openssl для веб-сервера https (lighttpd)

Я создал следующие файлы для своего веб-сервера lighttpd для соединений https:

$ ls -al /etc/lighttpd/ssl
drwxr-xr-x 2 root  root  4096 Oct 21 12:51 .
drwxr-xr-x 4 root  root  4096 Oct 20 16:04 ..
-rw-r--r-- 1 http  http  1663 Oct 20 15:49 server.crt
-rw-r--r-- 1 root  root  1062 Oct 20 15:48 server.csr
-rw------- 1 root  root  1704 Oct 20 15:48 server.key
-rw-r----- 1 alarm http  3367 Oct 20 16:02 server.pem
-rw------- 1 root  root  1751 Oct 20 15:48 rootCA.key
-rw-r--r-- 1 root  root  1330 Oct 20 15:48 rootCA.pem
-rw-r--r-- 1 root  root    41 Oct 20 15:49 rootCA.srl

где server.* мои очевидные файлы веб-сервера и rootCA.* файлы - это файлы моего центра сертификации (CA), которые я использовал для создания самозаверяющего сертификата ( https://alexanderzeitler.com/articles/Fixing-Chrome-missing_subjectAltName-selfsigned-cert-openssl/). Чтобы lighttpd использовал мой сертификат (crt), мне нужно было создать файл в формате pem, но я сделал:

sudo cat server.crt server.key > server.pem сделать файл в формате pem. Я установил свой файл rootCA.pem в Chrome (чтобы он распознавал CA и не жаловался на то, что веб-сайт "не защищен").

Так что мои вопросы

  1. мои права доступа к файлам в порядке безопасности или я должен изменить права доступа владельца / группы и файла на что-то другое?
  2. Как насчет прав доступа к каталогу /etc/lighttpd/ssl?
  3. Где я должен был сделать sudo cat server.crt server.key > server.pem Команда выше, добавив мой server.key к файлу pem, разве это не выставляет мой закрытый ключ, делая это server.pem файл читается по http?

Мой server.pem должен быть доступен для чтения на моем сервере lighttpd, поскольку пользователь, запускающий lighttpd, имеет значение "http".

Источник

2 ответа

Возможно, он еще не получил никаких ответов, потому что это сложная проблема, и нет единого правильного ответа.

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

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

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

  1. Получить корневой ключ там. Ключи CA не должны храниться в системах, подверженных воздействию внешнего мира. В данном случае это ваш собственный CA, а не публичный, но это базовая гигиена ключей PKIX.

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

  3. Этот каталог может также принадлежать root.http и иметь значение 750 (доступный для записи в корневой каталог, доступный для чтения http-группы, без мировых разрешений). Наиболее вероятные векторы атаки - через HTTP-сервер, но есть и другие; может также отговорить некоторых из них, блокируя чтение / обход мира.

Относительно вашего последнего вопроса: я никогда не использовал lighttpd, но некоторые серверы поддерживают процесс ввода ключей, при котором сервер читает ключ при запуске, а затем отбрасывает разрешения таким образом, чтобы он впоследствии не мог его прочитать. Например, сервер может запускаться с правами суперпользователя (как это должно быть в UNIX/Linux, если он хочет привязаться к портам 80 и 443), затем читает файл ключа и затем устанавливает setuid на http (или любой другой). Другие могут иметь возможность для чтения ключа из канала или аналогичного.

С помощью lighttpd также возможно, чтобы он считывал ключ из временной копии, которую процедура запуска удаляет после запуска сервера.

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

Мне нравится книга Ивана Ристича по пуленепробиваемым SSL и TLS, доступная на feistyduck.com, за советы по использованию SSL/TLS в целом и с HTTPS в частности. Для веб-серверов он в первую очередь обсуждает Apache, но большая часть материала широко применима.

Я надеюсь, что это полезно.

Источник

root:root, chmod 400. И в идеале ваши корневые CA-файлы не должны размещаться на вашем веб-сервере, в противном случае компрометация сервера также скомпрометирует ваши полномочия root.

https://redmine.lighttpd.net/projects/1/wiki/docs_ssl Разрешения Будьте осторожны, чтобы ваш файл.pem был закрытым! Lighttpd читает все pemfiles при запуске, прежде чем сбросить привилегии. Поэтому лучше сделать файл pem, принадлежащий пользователю root и доступным для чтения только пользователю root: $ chown root:root /etc/lighttpd/ssl/example.org.pem $ chmod 400 /etc/lighttpd/ssl/example.org.pem

Источник
Другие вопросы по тегам