☰

Proxying einer WordPress-Seite von einer anderen Subdomain

tag-icon • tag-icon nginx wordpress subdomain
Proxying einer WordPress-Seite von einer anderen Subdomain

Ich habe Nginx auf einem Ubuntu-Server installiert und WordPress darauf blog.example.com.

Ich habe auf WordPress eine Seite für die Galerie erstellt, auf die von aus zugegriffen werden kann blog.example.com/gallery.

Wenn jetzt jemand darauf zugreift, gallery.example.comsollte der Inhalt von angezeigt werden blog.example.com/gallery. Wie kann ich dies in Nginx erreichen?

Folgendes habe ich in der Nginx-Serverkonfiguration versucht 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;
    }

Antwort1

Richtige Konfiguration

Ihr Proxy ist falsch herum! Es handelt sich um einen Proxy von einem Pfad zu einer Subdomäne; höchstwahrscheinlich zum gleichen Hostnamen, auf dem sich der Pfad befindet. Wenn es mit ist server_name gallery.example.com, wird derzeit ein Proxy von http://gallery.example.com/galleryzu gesendet http://gallery.example.com/.

So machen Sie es zum Proxy von http://gallery.example.comnach 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;
    }
}

Denial-of-Service-Angriffe mit der aktuellen Proxy-Konfiguration

Die komplette Fehlkonfiguration:

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;
    }
}

Das Detail, dass sich diese Fehlkonfiguration auf derselben Subdomäne befindet, zu der auch der Proxy führt, macht die Sache interessant, da jemand diese Art von Setup tatsächlich für einen Denial-of-Service-Angriff missbrauchen könnte, indem er auf eine URL zugreift, die so viele interne Proxy-Verbindungen verursachen würde, wie /galleryURL-Teile aufeinander folgen.

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/

Das Aufrufen vieler solcher Anfragen führt zu einer hohen Belastung des Servers, die noch lange nach dem Stoppen des Angriffs anhalten kann, da Nginx immer noch versucht, alle diese verschachtelten Proxy-Verbindungen zu bedienen. Nginx könnte auch beginnen, 502 Bad Gateway& 500 Internal Server Errorfür legitime Benutzer anzuzeigen.

Sogar das Protokollieren all dieser Anfragen könnte zum Problem werden:[alert] 1620#1620: *2748894 write() to "/var/log/nginx/access.log" was incomplete: 3421 of 4566 while logging request

Wenn dies ein https://Server gewesen wäre, hätten all diese TLS-Handshakes zu noch höheren Belastungen geführt.

Wie viele Proxy-Verbindungen können durch eine einzelne HTTP-Anfrage verursacht werden?

Derlarge_client_header_bufferssteuert die maximale Länge der Anfragezeile, standardmäßig 4 8kalso 8096 ASCII-Zeichen. Obwohlhttp2_max_field_sizeist veraltet, ein kurzer Test curlzeigt, dass Nginx standardmäßig URLs mit bis zu 11157 Zeichen über HTTP/2 bereitstellen kann. Was auch immer die Grenze ist, Ihr Proxy würde 1011 bis 1394 Zeichen /galleryin der URL zulassen, bevor der 414 Request-URI Too LargeFehler ausgegeben wird.

Eine Grenze vonworker_connectionswird wahrscheinlich zuerst getroffen, wenn der Standardwert nicht erhöht wird 512. Dies würde zu einer 500 Internal Server ErrorFehlermeldung und zu Fehlerprotokollzeilen führen, die Folgendes enthalten:

512 worker_connections are not enough while connecting to upstream

verwandte Informationen