nginx refuxing соединение SSL

Я обычно - поклонник "Одного пользователя для чего-либо, что открывает сокет слушания в сети" - Один для Apache, один для Почты, один для DNS, и т.д.

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

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

Расширение далее аргумента в пользу помещения каждого Apache в chroot (или тюрьма, если Вы в системах BSD) может быть сделано еще для большей безопасности, но теперь Вы говорите о дополнительном дисковом пространстве, так как каждому chroot/jail будет нужно все программное обеспечение, требуемое выполнять сайт, который это содержит (и потребность обновить это программное обеспечение для каждого сайта, а не всего одну основную копию на сервере, когда патчи выходят), плюс требование RAM точно так же, как, когда у Вас были отдельные экземпляры пользователей/апача.
Это смягчает все кроме ошибки ОС/ядра, которая позволяет пользователям убежать из chroot (который становится аргументом в пользу выполнения каждого сайта на отдельном физическом сервере - который затем становится argment для того, чтобы разделить сайты на различные VLAN/подсети, и т.д.),


Как со всеми рисками, Вы не можете устранить его: можно только смягчить его вниз к допустимому уровню на основе потенциального вреда/стоимости компромисса, вероятности компромисса и стоимости каждого уровня смягчения.
За мои деньги, за некритическое, не Электронную коммерцию, совместно использованную, размещая среду, основное "Один пользователь для Apache, один для DNS, один для почты, и т.д." система поддержки достаточно. Если существует потребность в безопасности, кроме того выравниваются, Ваши пользователи должны серьезно рассматривать свои собственные аппаратные средства.

-2
задан 9 April 2014 в 01:06
1 ответ
listen 80 ssl;

Порт 80 предназначен для HTTP. Порт 443 предназначен для HTTPS. Это должно быть примерно так:

listen 80;
listen 443 ssl;

Ваш браузер, вероятно, пытается установить соединение с портом 443, как и должно. Поскольку вместо этого Nginx по ошибке прослушивает порт 80, в соединении отказано.

1
ответ дан 5 December 2019 в 21:27

Теги

Похожие вопросы