Ein Webserver mit nginx

Modul 7: Domain, Webserver und https · Lesezeit: 12 Minuten

Lernziel: Nach dieser Lektion können Sie nginx installieren, eine Website und einen Reverse Proxy mit einem Server Block einrichten, eine Konfiguration sicher testen und neu laden sowie die Rechte Ihres Webroots richtig setzen.

Kernbegriffe: nginx, Server Block, sites-available und sites-enabled, conf.d, listen, server_name, root, index, try_files, Default Server, nginx -t, Reload, Reverse Proxy, proxy_pass, Host, X-Forwarded-For, X-Forwarded-Proto, Webroot, PHP-FPM

Was ein Webserver tut

Ein Webserver lauscht auf Port 80 (http) und 443 (https), nimmt Anfragen von Browsern entgegen und schickt etwas zurück: eine Datei von der Festplatte (eine statische Website) oder die Antwort eines Programms, das dahinter läuft (PHP, eine Node.js-App, ein Container). Im zweiten Fall nennt man den Webserver einen Reverse Proxy: Er steht vorne, kümmert sich um https und reicht die Anfrage an die Anwendung weiter, die nur auf 127.0.0.1 lauscht.

Unter Linux sind nginx und Apache die bekanntesten Webserver, und Caddy (Lektion 7.4) ist eine moderne Alternative, die Zertifikate selbst verwaltet. Diese Lektion verwendet nginx: Er ist in jeder Distribution enthalten, geht sparsam mit Arbeitsspeicher um und ist der Standard in vielen Anleitungen.

Installieren und ein erster Blick

anna@web1:~$ sudo apt install nginx
anna@web1:~$ systemctl status nginx
anna@web1:~$ curl -I http://localhost
HTTP/1.1 200 OK
Server: nginx/1.26.3
Content-Type: text/html

(Die Versionsnummer ist ein Beispiel.) Vergessen Sie die Firewall nicht: Port 80 und 443 müssen offen sein (Lektion 5.2). Rufen Sie jetzt http://192.0.2.10 auf, sehen Sie die Willkommensseite von nginx.

Die Konfiguration befindet sich in /etc/nginx/:

sites-available und sites-enabled sind eine Gepflogenheit von Debian und Ubuntu: So schalten Sie eine Website ein oder aus, indem Sie eine Verknüpfung anlegen oder entfernen, ohne die Datei zu löschen.

Eine erste Website

Legen Sie ein Verzeichnis für die Website und eine Testseite an:

anna@web1:~$ sudo mkdir -p /var/www/example.com
anna@web1:~$ echo '<h1>Het werkt</h1>' | sudo tee /var/www/example.com/index.html

Erstellen Sie dann einen Server Block: die Beschreibung einer einzelnen Website.

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

So lesen Sie ihn:

• listen 80; und listen [::]:80; lassen nginx auf IPv4 und IPv6 lauschen. Vergessen Sie die zweite Zeile, funktioniert Ihr AAAA-Record nicht (Lektion 7.1).
• server_name legt fest, für welche Namen dieser Block gilt. nginx prüft bei jeder Anfrage den Namen, den der Browser anfragt (den Host-Header), und wählt den passenden Block.
• root ist das Verzeichnis mit den Dateien, index die Datei, die bei einem Verzeichnis angezeigt wird.
• try_files versucht die angefragte Datei, dann ein Verzeichnis, und liefert sonst einen 404. Ohne eine solche Zeile kann eine fehlerhafte Konfiguration mehr anzeigen, als Sie möchten.
• Eigene Logdateien pro Website erleichtern die Suche erheblich (Lektion 6.2).

Aktivieren Sie die Website, entfernen Sie die Standardseite, testen Sie und laden Sie neu:

anna@web1:~$ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
anna@web1:~$ sudo rm /etc/nginx/sites-enabled/default
anna@web1:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
anna@web1:~$ sudo systemctl reload nginx
anna@web1:~$ curl -I http://example.com
HTTP/1.1 200 OK

Machen Sie nginx -t vor jedem Reload zur festen Gewohnheit. Bei einem Fehler nennt es Ihnen Datei und Zeile, und Ihre laufende Website bleibt unberührt. Starten Sie ohne Test neu, startet nginx bei einem Fehler nicht mehr, und alle Ihre Websites sind offline (Lektion 6.1).

Der Default Server: Was bekommt ein unbekannter Name?

Was passiert, wenn jemand Ihren Server mit einem Namen aufruft, der in keinem server_name steht, oder einfach mit der IP-Adresse? Dann wählt nginx den Default Server: den Block mit default_server hinter listen, oder sonst den ersten Block, auf den es gestoßen ist. Ohne weitere Überlegung ist das also eine Ihrer echten Websites.

Sauberer ist ein eigener Block, der solche Anfragen abweist:

# /etc/nginx/sites-available/000-default
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

444 ist ein besonderer Code von nginx: Die Verbindung wird ohne Antwort geschlossen. Scanner, die IP-Adressen abklappern, bekommen so nichts zu sehen. Für https (Port 443) funktioniert ein Default Server etwas anders, weil ein Zertifikat dazugehört; darauf kommen Sie in Lektion 7.3 zurück.

nginx als Reverse Proxy

Läuft eine Anwendung auf 127.0.0.1:3000 (Lektion 6.3) oder ein Container auf 127.0.0.1:3001 (Lektion 9.3), macht nginx diese nach außen erreichbar:

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

Die vier proxy_set_header-Zeilen sind wichtig. Ohne Host weiß die Anwendung nicht, unter welchem Namen sie aufgerufen wird. Ohne X-Forwarded-For sieht die Anwendung jeden Besuch von 127.0.0.1 (dem Proxy) kommen statt von der echten Adresse des Besuchers. Ohne X-Forwarded-Proto nimmt die Anwendung an, dass alles über http läuft, und erzeugt manchmal Links oder Cookies für http, obwohl Ihre Website über https läuft. Viele Anwendungen haben eine Einstellung, um diesen Headern zu vertrauen („trusted proxy“); tragen Sie dort nur 127.0.0.1 ein, sonst kann jeder Besucher eine gefälschte Adresse mitschicken.

Anwendungen, die Websockets verwenden (Live-Updates, wie Uptime Kuma), brauchen zwei weitere Zeilen: proxy_http_version 1.1; und das Weiterreichen von Upgrade und Connection. Die Dokumentation der Anwendung nennt meist genau, welche.

Rechte des Webroots

nginx führt seine Worker-Prozesse unter Debian und Ubuntu als Benutzer www-data aus. Dieser muss Ihre Dateien lesen können, sollte sie aber nicht schreiben können. Eine gute Aufteilung (Lektion 3.1):

anna@web1:~$ sudo chown -R anna:www-data /var/www/example.com
anna@web1:~$ sudo find /var/www/example.com -type d -exec chmod 750 {} \;
anna@web1:~$ sudo find /var/www/example.com -type f -exec chmod 640 {} \;

Sie (anna) verwalten die Dateien, die Gruppe www-data darf lesen, alle anderen nichts. Muss die Website irgendwo schreiben, etwa in ein Upload-Verzeichnis, geben Sie nur diesem Verzeichnis Schreibrechte für www-data. Niemals chmod 777 (Lektion 10.2). Erhalten Sie einen 403 Forbidden, sehen Sie im Fehlerlog der Website nach: Dort steht permission denied mit dem Pfad.

Einige weitere Gewohnheiten:

• Keine Geheimnisse im Webroot. Backups (site.zip), .env-Dateien und .git-Verzeichnisse gehören nicht hinein; landen sie doch versehentlich dort, sind sie abrufbar. Ein zusätzliches Sicherheitsnetz: location ~ /\. { deny all; } blockiert alle Dateien, die mit einem Punkt beginnen (außer dem, was Sie ausdrücklich erlauben, wie /.well-known/, siehe Lektion 7.3 und 7.4).
• Version verbergen. server_tokens off; in nginx.conf entfernt die Versionsnummer aus dem Server-Header und aus Fehlerseiten. Das ist keine echte Absicherung, gibt Scannern aber weniger Informationen.

PHP in Kürze

Für PHP-Websites (wie WordPress) kommuniziert nginx mit PHP-FPM, einem separaten Dienst. Unter Debian installieren Sie php-fpm und setzen im Server Block einen location ~ \.php$-Block mit include snippets/fastcgi-php.conf; und fastcgi_pass unix:/run/php/php8.4-fpm.sock; (die Versionsnummer unterscheidet sich je nach Release). Der WordPress-Kurs geht darauf näher ein.

Unter AlmaLinux und Rocky Linux

Dort gibt es kein sites-available: Sie legen jede Website als eigene Datei in /etc/nginx/conf.d/<naam>.conf ab. nginx läuft als Benutzer nginx statt www-data, und der Standard-Webroot ist /usr/share/nginx/html. SELinux erlaubt nginx standardmäßig keine Verbindung zu einer Anwendung hinter proxy_pass; schalten Sie das mit setsebool -P httpd_can_network_connect 1 frei. Dateien außerhalb der üblichen Verzeichnisse benötigen ein SELinux-Label (semanage fcontext und restorecon).

Zusammenfassung

• nginx liefert Dateien aus oder reicht Anfragen als Reverse Proxy an eine Anwendung auf 127.0.0.1 weiter.
• Ein Server Block pro Website in sites-available, aktiviert mit einer Verknüpfung in sites-enabled; lauschen Sie auf 80 und [::]:80.
• Immer nginx -t vor systemctl reload nginx.
• Ein eigener Default Server mit return 444 verhindert, dass ein unbekannter Name oder die bloße IP-Adresse eine Ihrer Websites anzeigt.
• Als Reverse Proxy reichen Sie Host, X-Forwarded-For und X-Forwarded-Proto weiter; der Webroot ist für www-data lesbar, nicht beschreibbar und frei von Geheimnissen.

Quiz

Aufgabe

Aufgabe O7.2: Ihre erste Website. Installieren Sie nginx (oder verwenden Sie Caddy aus Lektion 7.4) und erstellen Sie einen Server Block für eine (Sub-)Domain, die auf Ihren Server zeigt, mit listen für IPv4 und IPv6, eigenen Logdateien und einem eigenen Default Server. Testen Sie mit nginx -t, laden Sie neu und prüfen Sie mit curl -I über IPv4 und IPv6. Setzen Sie die Rechte des Webroots wie in der Lektion beschrieben. Füllen Sie die Checkliste aus und fügen Sie Ihren Server Block ein.

Weiterführende Informationen

• **Forbidden (403):** Sie haben keine Berechtigung, um auf / auf diesem Server zuzugreifen.
• nginx-Dokumentation, How nginx processes a request (server_name und Default Server): https://nginx.org/en/docs/http/request_processing.html
• nginx-Dokumentation, Beginner's Guide: https://nginx.org/en/docs/beginners_guide.html
• nginx-Dokumentation, ngx_http_proxy_module: https://nginx.org/en/docs/http/ngx_http_proxy_module.html