nginx открытый обратный прокси

Вопрос или проблема

Доказательством того, что мы каким-то образом настроили обратный прокси nginx, который действует как открытый прокси, являются логи.

Лог-файлы показывают, что совпадающие запросы обрабатываются следующим conf файлом:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

access_log      /var/log/nginx/access.p.log;
error_log       /var/log/nginx/error.p.log;

proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_buffers           8 32k;
proxy_buffer_size       64k;
proxy_http_version      1.1;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect          off;
proxy_set_header        Upgrade         $http_upgrade;
proxy_set_header        Connection      $connection_upgrade;

server {
    listen          80;
    server_name     ~first.*\.second\.com;

    location / {
        resolver                172.16.1.1 172.16.1.2;
        proxy_pass              http://$host;
        proxy_read_timeout      7200s;
    }
}

server {
    listen          443;
    server_name     ~first.*\.second\.com;
    ssl             on;

    location / {
        resolver                172.16.1.1 172.16.1.2;
        proxy_pass              https://$host;
        proxy_read_timeout      7200s;
    }
}

Верхний файл conf выглядит следующим образом:

user nginx;
worker_processes 8;
pid /var/run/nginx.pid;

events {
    worker_connections 4096;
    # multi_accept on;
}

http {

    ##
    # Основные настройки
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # Настройки логирования
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Настройки Gzip
    ##

    gzip on;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Конфигурация nginx-naxsi
    ##
    # Уберите комментарии, если вы установили nginx-naxsi
    ##

    #include /etc/nginx/naxsi_core.rules;

    ##
    # Конфигурация nginx-passenger
    ##
    # Уберите комментарии, если вы установили nginx-passenger
    ##

    #passenger_root /usr;
    #passenger_ruby /usr/bin/ruby;

    ##

    include /etc/nginx/conf.d/*.conf;
    #include /etc/nginx/sites-enabled/*;
}

Что здесь вызывает эту проблему?

Есть документ на как nginx обрабатывает запросы. В частности, это означает, что если у вас есть только один блок сервера, то все запросы будут направляться туда, независимо от заголовка Host.

В вашем случае вы хотите обрабатывать только запросы, которые соответствуют вашим хостам, и игнорировать остальные. Таким образом, вам нужно объявить другой блок сервера, который будет обрабатывать все несоответствующие запросы.

Это должно выглядеть примерно так:

server {
    listen 80 default_server;
    listen 443 default_server;
    return 403;
    # или return 444; чтобы просто закрыть соединение без ответа.
}

server {
    listen 80;
    server_name ~first.*\.second\.com;
    ....
}

server {
    listen 443 ssl;
    server_name ~first.*\.second\.com;
    ....
}

Ответ или решение

Ваша конфигурация Nginx действительно может вызвать проблемы с открытым обратным прокси, так как она не ограничивает доступ к серверу для ненадежных источников. Давайте разберем конфигурацию и выясним, как это исправить.

Проблема конфигурации

На данный момент у вас есть серверные блоки, которые слушают порты 80 и 443 и обрабатывают запросы для имен хостов, соответствующих шаблону ~first.*.second.com. Однако если запрос приходит с другим именем хоста, он будет обрабатываться по умолчанию по первой конфигурации сервера, что может привести к незапланированному доступу к вашим ресурсам.

Решение

Вам необходимо добавить серверные блоки по умолчанию, которые будут обрабатывать все входящие запросы, не соответствующие вашим более специфичным конфигурациям. Эти блоки могут просто возвращать ошибку 403 (доступ запрещен) или 444 (закрыть соединение без ответа).

Вот пример исправленной конфигурации:

server {
    listen 80 default_server;
    listen 443 default_server ssl;
    return 403;  # Или используйте return 444; для закрытия соединения без ответа.
}

server {
    listen 80;
    server_name ~first.*\.second\.com;

    location / {
        resolver 172.16.1.1 172.16.1.2;
        proxy_pass http://$host;
        proxy_read_timeout 7200s;

        # Дополнительные настройки, если необходимо
    }
}

server {
    listen 443 ssl;
    server_name ~first.*\.second\.com;

    location / {
        resolver 172.16.1.1 172.16.1.2;
        proxy_pass https://$host;
        proxy_read_timeout 7200s;

        # Дополнительные настройки, если необходимо
    }
}

Разъяснение

  1. Серверные блоки по умолчанию: Эти блоки определяют, что делать с любыми запросами, которые не соответствуют вашей конфигурации ~first.*\.second\.com. Это предотвратит несанкционированный доступ и сделает ваш сервер менее восприимчивым к злоупотреблениям.

  2. 426-сертификаты SSL: При использовании протокола HTTPS в конфигурации SSL необходимо указать свои сертификаты. Убедитесь, что вы добавили соответствующие директивы ssl_certificate и ssl_certificate_key.

  3. Проверка конфигурации: После внесения изменений обязательно проверьте конфигурацию Nginx на наличие ошибок с помощью команды:

    nginx -t
  4. Перезапуск Nginx: Если проверка прошла успешно, перезапустите службу Nginx, чтобы изменения вступили в силу:

    systemctl restart nginx

Заключение

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

Оцените материал
Добавить комментарий

Капча загружается...