Как правильно заблокировать страницу администратора в Joomla с использованием прокси Nginx?

Содержание

Вопрос или проблема
Ответ или решение
Оптимизированная конфигурация Nginx
Пояснения
Альтернативный метод: Использование .htaccess
Заключение

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

Я хочу, чтобы только некоторые сети имели доступ к странице администрирования Joomla (“/administrator”). Для этого я сделал нижеуказанную конфигурацию. Она работает. Я хотел бы знать, является ли это наилучшей конфигурацией.

proxy_intercept_errors не работает для правила “/administrator”. Отображается страница ошибки 403 по умолчанию.

examplesite.conf:

server {
    listen              443 ssl http2;
    server_name         examplesite.com;

    proxy_intercept_errors on;
    include /usr/share/nginx/html/nginx-errors-ptbr/nginx-errors.conf;

    # SSL
    ssl_certificate     /etc/nginx/ssl/examplesite.bundle.crt;
    ssl_certificate_key /etc/nginx/ssl/examplesite.key;

  
    # логирование
    access_log          /var/log/nginx/examplesite.access.log;
    error_log           /var/log/nginx/examplesite.error.log warn;


    # Разрешить /administrator только для определенных IP
    location /administrator {
         allow 192.168.0.0/24;
         allow 192.168.1.0/24; 
         deny all;
         proxy_pass http://192.168.2.20:8080;
         include    examplesite/proxy.conf;
    }


    # обратный прокси
    location / {
        proxy_pass http://192.168.2.20:8080;
        include    examplesite/proxy.conf;
    }
}
 
# HTTP редирект
server {
    listen      80;
    server_name examplesite.com;
    return      301 https://examplesite.com$request_uri;
}

proxy.conf:

proxy_http_version                 1.1;
proxy_cache_bypass                 $http_upgrade;

# Заголовки прокси
proxy_set_header Upgrade           $http_upgrade;
proxy_set_header Connection        $connection_upgrade;
proxy_set_header Host              $host;
proxy_set_header X-Real-IP         $remote_addr;
proxy_set_header Forwarded         $proxy_add_forwarded;
proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host  $host;
proxy_set_header X-Forwarded-Port  $server_port;

# Таймауты прокси
proxy_connect_timeout              60s;
proxy_send_timeout                 60s;
proxy_read_timeout                 60s;

Проблема с proxy_intercept_errors для /administrator, вероятно, возникает из-за того, что Nginx не перехватывает ошибки для проксируемых запросов, если они не возвращаются с сервера на заднем плане. В случае deny all Nginx сам генерирует ошибку 403, а не получает ее от сервера на заднем плане, что может препятствовать перехвату этой ошибки через proxy_intercept_errors.

Попробуйте явно указать страницу ошибки для этого случая в блоке /administrator. Также можете показать содержимое конфигурации /usr/share/nginx/html/nginx-errors-ptbr/nginx-errors.conf?

Судя по порту 8080, вы используете Apache в качестве сервера на заднем плане. Если это так, вы также можете настроить блокировку с помощью файла .htaccess.

Для .htaccess это правило будет переписано следующим образом:

<Directory "/path/to/directory/administrator">
Require ip 192.168.0.0/24
Require ip 192.168.1.0/24
Require all denied
</Directory>

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

Чтобы правильно заблокировать доступ к странице администратора Joomla ("/administrator") с использованием прокси Nginx, вы можете рассмотреть следующие шаги и рекомендации. Учитывая уже предложенную конфигурацию, мы можем улучшить её, чтобы избежать ошибки 403 и использовать правильные страницы ошибок.

Оптимизированная конфигурация Nginx

server {
    listen              443 ssl http2;
    server_name         examplesite.com;

    proxy_intercept_errors on;
    include /usr/share/nginx/html/nginx-errors-ptbr/nginx-errors.conf;

    # SSL
    ssl_certificate     /etc/nginx/ssl/examplesite.bundle.crt;
    ssl_certificate_key /etc/nginx/ssl/examplesite.key;

    # logging
    access_log          /var/log/nginx/examplesite.access.log;
    error_log           /var/log/nginx/examplesite.error.log warn;

    # Разрешить доступ к /administrator только для определенных IP
    location /administrator {
         allow 192.168.0.0/24;
         allow 192.168.1.0/24; 
         deny all;

         # Перенаправление для обработки ошибок 403
         error_page 403 /custom_403.html;  # Задайте свой путь к кастомной ошибке 403
         proxy_pass http://192.168.2.20:8080;
         include examplesite/proxy.conf;
    }

    # Реверс-прокси
    location / {
        proxy_pass http://192.168.2.20:8080;
        include examplesite/proxy.conf;
    }

    # Настройка для страницы ошибки 403
    location = /custom_403.html {
        internal;
        root /usr/share/nginx/html;  # Убедитесь, что путь к файлу верный
    }
}

# Переадресация HTTP-запросов на HTTPS
server {
    listen      80;
    server_name examplesite.com;
    return      301 https://examplesite.com$request_uri;
}

Пояснения

Ошибка 403: Ошибка 403 генерируется Nginx, когда IP-адрес не попадает в разрешенные диапазоны. Чтобы отобразить настраиваемую страницу ошибки, используйте директиву error_page 403 /custom_403.html; и создайте файл custom_403.html в указанной директории.
Обработка ошибок: proxy_intercept_errors on; позволяет Nginx перехватывать ошибки из обратного прокси. Однако, в случае с 403, это не сработает, так как ошибка генерируется Нginx, а не бэкендом. Поэтому важно обрабатывать 403 на уровне веб-сервера.
Конфигурация прокси: Ваша конфигурация для proxy.conf выглядит хорошо, и вы можете оставить её без изменений, так как она обеспечивает корректную обработку заголовков и таймаутов.

Альтернативный метод: Использование .htaccess

Если ваш бэкенд работает на Apache, вы также можете задуматься о конфигурации ограничений direktiv на уровне .htaccess:

<Directory "/path/to/directory/administrator">
    Require ip 192.168.0.0/24
    Require ip 192.168.1.0/24
    Require all denied
</Directory>

Этот способ создает дополнительные уровень защиты на уровне приложений и работает независимо от Nginx.

Заключение

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