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

Question

Я создал следующие файлы для своего веб-сервера 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 (чтобы он распознавал центр сертификации и не жаловался на то, что веб-сайт «не защищен»).

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

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

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

Answer 1

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

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

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

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

1. Получить корневой ключ там. Ключи 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, но большая часть материала широко применима.

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

Answer 2

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