☰

Proxy de uma página WordPress de outro subdomínio

tag-icon • tag-icon nginx wordpress subdomain
Proxy de uma página WordPress de outro subdomínio

Tenho um Nginx instalado em um servidor Ubuntu e instalei o WordPress no blog.example.com.

No WordPress criei uma página para galeria que pode ser acessada em blog.example.com/gallery.

Agora quando alguém acessar o arquivo gallery.example.comdeverá mostrar o conteúdo do arquivo blog.example.com/gallery. Como posso conseguir isso no Nginx?

Aqui está o que eu tentei na configuração do servidor nginx 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;
    }

Responder1

Configuração correta

Seu proxy está ao contrário! É um proxy de um caminho para um subdomínio; provavelmente para o mesmo nome de host em que o caminho está. Se estiver com server_name gallery.example.com, atualmente faz proxy de http://gallery.example.com/gallerypara http://gallery.example.com/.

Para torná-lo proxy de http://gallery.example.compara 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 negação de serviço com a configuração de proxy atual

A configuração incorreta 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;
    }
}

O detalhe de que essa configuração incorreta está no mesmo subdomínio do proxy torna-a interessante, já que alguém poderia realmente abusar desse tipo de configuração para negação de serviço acessando uma URL que causaria tantas conexões proxy internas quanto URLs /gallery. partes uma após a outra.

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 muitas dessas solicitações causa alta carga no servidor que pode continuar por muito tempo após o ataque ter sido interrompido, pois o Nginx ainda está tentando servir todas essas conexões proxy aninhadas. O Nginx também pode começar a ser exibido 502 Bad Gatewaypara 500 Internal Server Errorusuários legítimos.

Até mesmo registrar todas essas solicitações pode se tornar um problema:[alert] 1620#1620: *2748894 write() to "/var/log/nginx/access.log" was incomplete: 3421 of 4566 while logging request

Se este fosse um https://servidor, todos aqueles handshakes TLS teriam causado cargas ainda maiores.

Quantas conexões proxy podem ser causadas por uma única solicitação HTTP?

Olarge_client_header_bufferscontrola o comprimento máximo da linha de solicitação, por padrão, ou seja, 4 8k8.096 caracteres ASCII. Emborahttp2_max_field_sizeestá obsoleto, um teste rápido curlrevela que, por padrão, o Nginx pode servir URLs de até 11.157 caracteres em HTTP/2. Qualquer que seja o limite, seu proxy permitiria de 1011 a 1394 vezes /galleryna URL antes de dar o 414 Request-URI Too Largeerro.

Um limite deworker_connectionsprovavelmente será atingido primeiro se não for aumentado em relação ao padrão 512. Isso causaria um 500 Internal Server Errorerro e linhas de log contendo:

512 worker_connections are not enough while connecting to upstream

informação relacionada