Безопасна ли эта конфигурация nginx с настройкой прокси?

Безопасна ли эта конфигурация nginx с настройкой прокси?

Я настроил сервер Node/Express HTTPS / SSL, использующий LetsEncrypt для сертификатов, работающий на порту 3000. Он работает, и я могу получить к нему доступ через www.example.com:3000. Но я действительно хочу иметь возможность получить к нему доступ напрямую из www.example.com.

Мне удалось заставить это работать (см. мой код ниже), создав собственную конфигурацию nginx и запустив sudo systemctl restart nginx.

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        server_name _;                        // *

        location / {
                allow all;                    // *
        }
}

server {
    server_name www.example.com;

    listen [::]:443 ssl;
    listen 443 ssl;

    ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass  https://127.0.0.1:3000;

        allow all;                            // *
    }
}

Я адаптировал второй сервер из автоматически сгенерированного Certbot сервера при настройке своего сертификата.

Я полный новичок в конфигурационных файлах nginx. Может ли кто-нибудь дать совет по безопасности моей реализации? Я что-то упускаю? Мне интересно, в частности, о строках, которые я добавил // *. Заранее спасибо.

решение1

  • Убедитесь, что вы используете последнюю версию nginx.

  • Проверьте шифры SSL, которые вы включили.nginx- чтобы избежать атак с понижением версии, вам следует отключить некоторые устаревшие версии.

  • Вам действительно нужно, чтобы он был доступен как на порту 80, так и на порту 443? Если у вас нет особой потребности в незашифрованном HTTP, я бы полностью удалил первый блок и сделал второй блок вашим default server.

  • Все, что находится на известных публичных портах HTTP/HTTPS, будет регулярно сканироваться ботами из многих стран в поисках последних уязвимостей CVE.

    • Вам следует рассмотреть возможность размещения вашего приложения не в корне URL, а обратного прокси-сервера на пути и в чем-то вроде того, https://yourdomain.example.com/codewordгде " codeword" является чем-то уникальным и не связано ни с чем отдаленно связанным с общими или конкретными компьютерными/интернет-приложениями или концепциями администрирования. Например, https://yourdomain.example.com/adminили https://yourdomain.example.com/app скорее всего попадет под сканирование, но, https://yourdomain.example.com/kittensскорее всего, нет.

    • Вы можете рассмотреть возможность узнать больше о ngx_http_geoip_moduleиразрешает только ожидаемые страны.

    • Базовая HTTP-аутентификациятакже может использоваться для блокировки возможности запуска любого кода веб-приложения на вашем сервере без возможности сообщить nginx базовое имя пользователя/пароль аутентификации.

Связанный контент