☰

Proxy una página de WordPress desde otro subdominio

tag-icon • tag-icon nginx wordpress subdomain
Proxy una página de WordPress desde otro subdominio

Tengo un Nginx instalado en un servidor Ubuntu y he instalado WordPress en blog.example.com.

En WordPress creé una página para la galería a la que se puede acceder desde blog.example.com/gallery.

Ahora, cuando alguien acceda, gallery.example.comdebería mostrar el contenido del archivo blog.example.com/gallery. ¿Cómo puedo lograr esto en Nginx?

Esto es lo que probé en la configuración del servidor nginx de blog.example.com.config:

   location /gallery {
        proxy_pass http://gallery.example.com/;
        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_set_header X-Forwarded-Proto $scheme;
    }

Respuesta1

Configuración correcta

¡Tu proxy está al revés! Es un proxy de una ruta a un subdominio; lo más probable es que sea el mismo nombre de host en el que se encuentra la ruta. Si es con server_name gallery.example.com, actualmente actúa como proxy de http://gallery.example.com/gallerya http://gallery.example.com/.

Para convertirlo en proxy de http://gallery.example.coma http://blog.example.com/gallery:

server {
    server_name gallery.example.com;    
    location / {
        proxy_pass http://blog.example.com/gallery;
        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_set_header X-Forwarded-Proto $scheme;
    }
}

Ataques de denegación de servicio con la configuración de proxy actual

La mala configuración completa:

server {
    server_name gallery.example.com;    
    location /gallery {
        proxy_pass http://gallery.example.com/;
        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_set_header X-Forwarded-Proto $scheme;
    }
}

El detalle de que esta configuración errónea se produce en el mismo subdominio al que se realiza el proxy lo hace interesante, ya que alguien podría abusar de este tipo de configuración para denegación de servicio al acceder a una URL que causaría tantas conexiones de proxy internas como /galleryURL existen. partes que se suceden unas a otras.

http://gallery.example.com/gallery/gallery/gallery/gallery/gallery/.../gallery
=> . . . 
=> http://gallery.example.com/gallery/gallery/gallery/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery/gallery
=> http://gallery.example.com/gallery/gallery
=> http://gallery.example.com/gallery
=> http://gallery.example.com/

Invocar muchas de estas solicitudes provoca una gran carga en el servidor que puede continuar mucho después de que se haya detenido el ataque, ya que Nginx todavía está intentando atender todas esas conexiones proxy anidadas. Nginx también podría empezar a mostrar 502 Bad Gateway& 500 Internal Server Errorpara usuarios legítimos.

Incluso registrar todas esas solicitudes podría convertirse en un problema:[alert] 1620#1620: *2748894 write() to "/var/log/nginx/access.log" was incomplete: 3421 of 4566 while logging request

Si se tratara de un https://servidor, todos esos apretones de manos TLS habrían provocado cargas aún mayores.

¿Cuántas conexiones proxy podrían ser causadas por una sola solicitud HTTP?

Ellarge_client_header_bufferscontrola la longitud máxima de la línea de solicitud, siendo el valor predeterminado, 4 8kes decir, 8096 caracteres ASCII. A pesar dehttp2_max_field_sizeestá obsoleto, una prueba rápida revela curlque, de forma predeterminada, Nginx podría ofrecer URL de hasta 11157 caracteres a través de HTTP/2. Cualquiera que sea el límite, su proxy permitiría de 1011 a 1394 veces /galleryen la URL antes de dar el 414 Request-URI Too Largeerror.

un límite deworker_connectionsEs probable que reciba el primer impacto si no se aumenta con respecto al valor predeterminado 512. Eso causaría 500 Internal Server Errorlíneas de registro de error que contienen:

512 worker_connections are not enough while connecting to upstream

información relacionada