Von nginx und localhost
Diesen Beitrag schrieb ich 2 Jahre und 6 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Manchmal, wenn alles einfach rund läuft und es nichts feuerwehrartiges an den Maschinen zu erledigen gibt… dann lese ich anlasslos Logfiles; und das Deprimierende daran ist, dass ich eigentlich immer etwas Verfolgenswertes dabei finde. Die wirklich interessanten Dinge habe ich zumindest häufig auf diese Art aufgestöbert.
- Die Meldung im error.log
- Der Aufruf
- Ursächlich: eine falsche (besser: unvollständige) Konfiguration
- Fazit
Naja, und so war es auch an diesem Abend: ich war müde, drückte mich davor ins Bett zu gehen und stocherte in meinem Webserver herum.
Die Meldung im error.log
2022/03/12 19:46:54 [error] 987#987: *4417 open() "/data/www_data/html/GponForm/diag_Form" failed (2: No such file or directory),
client: a.b.c.d,
server: localhost,
request: "POST /GponForm/diag_Form?images/ HTTP/1.1",
host: "127.0.0.1:80"
Im ersten Moment stand ich zugegebenermaßen auf dem Schlauch: wie schafft es einer, von außen zu kommen und auf localhost zuzugreifen? Das Logfile war auch wirklich das von localhost, jede Domain hat ihr eigenes, und das Schlauchstehen verwandelte sich in Schrecken… was war da los?
Der Aufruf
Mit tatkräftiger Unterstützung von außen – vielen Dank nochmal 🥰 ohne hätte das deutlich länger gedauert – ließ es sich nach und nach eingrenzen.
printf "GET /GponForm/diag_Form?images/ HTTP/1.1\r\nUser-Agent: nc/0.0.1\r\nHost: 127.0.0.1:80\r\nAccept: */*\r\n\r\n" | nc 194.59.206.181 80
So konnte ich explizit und über alle nginx-Logs hinweg nach nc/0.0.1 grep-en und erhielt im error.log genau jene Ausgabe, durch die ich überhaupt erst aufmerksam geworden war; im access.log wurde folgendes protokolliert:
## im access.log
a.b.c.d - - [12/Mar/2022:22:40:22 +0100] "GET /GponForm/diag_Form?images/ HTTP/1.1" 404 146 "-" "nc/0.0.1"
Ursächlich: eine falsche (besser: unvollständige) Konfiguration
Wie vermutet war eine falsche beziehungsweise unvollständige Konfiguration der Grund dafür.
## /etc/nginx/websites/system/_localhost.cnf
server {
server_name localhost 127.0.0.1;
listen 80;
listen [::]:80;
root /data/www_data/html;
index index.html index.htm;
}
Ich nahm den Listener auf [::]:80 komplett heraus und band Port 80 konkret an 127.0.0.1.
## /etc/nginx/websites/system/_localhost.cnf
server {
server_name localhost 127.0.0.1;
listen 127.0.0.1:80;
root /data/www_data/html;
index index.html index.htm;
}
Ein erneutes Ausführen des oben genannten Aufrufs führt dann dazu, dass die an die IP des Servers gerichtete Anfrage, für die kein expliziter VHost definiert wurde, an die alphabetisch erste konfigurierte Domain des Webservers geleitet wird – und das ist derzeit eliteunsinn.de. Und dort erhält der Aufruf wie erwartet seinen 301 – die Welt ist schön.
## eliteunsinn.de/access.log:eliteunsinn.de
a.b.c.d - - [12/Mar/2022:22:46:46 +0100] "GET /GponForm/diag_Form?images/ HTTP/1.1" 301 162 "-" "nc/0.0.1"
Fazit
Zum Glück konnte nichts Wichtiges kompromittiert werden, denn die wichtigen Sachen sind ans VPN-Interface gebunden. Nur eine Kleinigkeit also, irgendwie, aber trotzdem mies und sollte nicht passieren. Aber wenn es mir passiert, passiert es vielleicht auch anderen – und für jene ist dieser Artikel 🤗
Hintergrundbild: Dekorative Glassplitter in Nahaufnahme, 2009, 1500x 1000px, Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
