Вопрос или проблема
Для соответствия требованиям PCI мы начали получать нижеуказанную ошибку:
Мы используем Nginx в качестве нашего веб-сервера. При доступе к веб-серверу, используя любое из наших доменных имен, у нас есть правильные значения server_name в конфигурации Nginx, и, таким образом, предоставляются правильные сертификаты. Безопасностной сканер также сканирует IP-адрес сервера напрямую и попадает в один из блоков server. Как мы можем либо предотвратить это, чтобы не попадаться, либо ответить подходящим образом так, чтобы у нас не было этой ошибки при сканировании на безопасность?
Я нашел идеи подобные этой, которые возвращают 404, но это не поможет, так как CN все равно не будет соответствовать IP-адресу.
Вот как выглядит блок сервера, который перехватывает запрос (на самом деле это перенаправление со старого домена на новый, но, как вы видите, он не явно указан как default_server в соответствии с документацией):
server {
listen 443 ssl;
server_name xxxx.de www.xxxx.de;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_certificate /xxxx/ssl-bundle.crt;
ssl_certificate_key /xxxx/xxxx.de.key;
return 301 https://www.yyyy.de;
}
Спасибо
Если вы хотите, чтобы клиенты, не поддерживающие SNI, по умолчанию получали что-то соответствующее, вам придется добавить явный default_server. Обратите внимание, что согласно документации Nginx, первый сервер используется как сервер по умолчанию:
Если ни одна из директив не имеет параметра default_server, то первым сервером с парой адрес:порт будет сервер по умолчанию для этой пары.
Существуют некоторые полу-подходящие коды состояния HTTP, чтобы сигнализировать о невозможности предоставить ответ для данного имени сервера, но простое отключение после представления пустого (без FQDN в CN) самоподписанного сертификата, скорее всего, обеспечит игнорирование сертификата инструментом проверки:
server {
listen 443 ssl default_server;
server_name _;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_certificate /etc/ssl/snakeoil.crt;
ssl_certificate_key /etc/ssl/private/snakeoil.key;
return 444;
# или даже лучше, в версии nginx 1.19.4 и выше:
# ssl_reject_handshake on;
}
Вариант ssl_reject_handshake on; предпочтителен, так как он создает соответствующий алерт протокола TLS – но еще не доступен в некоторых дистрибутивах.
Вам нужно добавить IP-адрес в качестве server_name вашего сервера http на порту 80 и затем использовать
return 301 https://site$request_uri;
Например:
server {
listen 80;
server_name xxxx.de www.xxxx.de 111.112.113.114;
return 301 https://www.yyyy.de$request_uri;
}
Правка:
Это не отвечает на ваш вопрос о запрете подключения, а скорее исправляет проблему, так что он должен правильно перенаправлять запрос на ваш сайт.
Ответ или решение
Для решения проблемы отказа Nginx от SSL/TLS-соединений, когда хост запрашивается через IP-адрес или не соответствует значению server_name, необходимо внести изменения в конфигурацию вашего веб-сервера. Это важный шаг для соблюдения стандартов PCI, так как большинство сканеров безопасности отмечают такие запросы как уязвимость.
Шаги для настройки Nginx
-
Создание блока сервера для IP-адреса:
Вам необходимо добавить серверный блок, который будет обрабатывать запросы, приходящие на IP-адрес. Это обеспечит возврат корректного статуса при попытке доступа по IP.server { listen 443 ssl default_server; server_name 111.112.113.114; # Замените на ваш IP-адрес ssl_protocols TLSv1.2 TLSv1.3; # Убедитесь, что используете современные протоколы ssl_certificate /path/to/snakeoil.crt; # Использование самоподписанного сертификата ssl_certificate_key /path/to/snakeoil.key; return 444; # Закрывает соединение без ответа }В этом примере используется статус
444, который разрывает соединение без ответа. Это максимально безопасный способ, так как не предоставляется никаких данных, которые могли бы быть воспринимаемы как уязвимость. -
Добавление блока по умолчанию для всех остальных запросов:
Следующим шагом будет добавление блока по умолчанию, который сможет обрабатывать любые запросы, когда Nginx не сможет найти соответствующийserver_name.server { listen 443 ssl default_server; server_name _; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate /path/to/snakeoil.crt; ssl_certificate_key /path/to/snakeoil.key; return 444; # Закрываем соединение }Использование
server_name _;позволяет охватывать все неявные запросы и ведет к тому, что все обращения по IP или без соответствия будут возвращены с кодом444. -
Настройка перенаправлений для HTTP:
Полезно также убедиться, что запросы HTTP перенаправляются на HTTPS. Для этого можно добавить следующий блок:server { listen 80; server_name xxxx.de www.xxxx.de 111.112.113.114; return 301 https://www.yyyy.de$request_uri; # Перенаправление на HTTPS }Это гарантирует, что все запросы, пришедшие по HTTP, будут перенаправлены, что улучшает безопасность вашего веб-сервера.
Усовершенствования безопасности
-
Использование
ssl_reject_handshake on;: Если на вашем сервере установлена версия Nginx 1.19.4 или выше, вы можете использовать эту директиву для завершения процесса рукопожатия TLS с ошибкой. Это обеспечит еще более надежное поведение для запросов, не соответствующихserver_name.server { listen 443 ssl default_server; server_name _; ssl_protocols TLSv1.2 TLSv1.3; ssl_certificate /path/to/snakeoil.crt; ssl_certificate_key /path/to/snakeoil.key; ssl_reject_handshake on; # Рекомендуемая настройка }
Заключение
Следуя данным инструкциям, вы сможете предотвратить прием SSL/TLS соединений по IP-адресу или несоответствующим доменным именам, что поможет устранить уязвимости и соблюсти требования PCI. Обязательно протестируйте конфигурацию на предмет ее корректности и эффективности перед развертыванием в продуктивной среде.