En webserver med nginx

Modul 7: Domene, webserver og https · Lesetid: 12 minutter

Læringsmål: Etter denne leksjonen kan du installere nginx, sette opp et nettsted og en reverse proxy med en server block, teste og laste inn en konfigurasjon på en trygg måte, og gi webroot riktige rettigheter.

Nøkkelbegreper: nginx, server block, sites-available og 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

Hva en webserver gjør

En webserver lytter på port 80 (http) og 443 (https), tar imot forespørsler fra nettlesere og sender noe tilbake: en fil fra disken (et statisk nettsted), eller svaret fra et program som kjører bak den (PHP, en Node.js-app, en container). I det andre tilfellet kalles webserveren en reverse proxy: den står ytterst, tar seg av https og sender forespørselen videre til applikasjonen, som bare lytter på 127.0.0.1.

På Linux er nginx og Apache de mest kjente webserverne, og Caddy (leksjon 7.4) er et moderne alternativ som ordner sertifikater selv. Denne leksjonen bruker nginx: den finnes i alle distribusjoner, bruker lite minne og er standard i mange veiledninger.

Installer og ta en første titt

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

(Versjonsnummeret er et eksempel.) Ikke glem brannmuren: port 80 og 443 må være åpne (leksjon 5.2). Går du nå til http://192.0.2.10, ser du velkomstsiden til nginx.

Konfigurasjonen ligger i /etc/nginx/:

sites-available og sites-enabled er en vane fra Debian og Ubuntu: slik slår du et nettsted på eller av ved å lage eller fjerne en lenke, uten å slette filen.

Et første nettsted

Lag en mappe for nettstedet og en testside:

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

Lag så en server block: beskrivelsen av ett nettsted.

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

Les det slik:

• listen 80; og listen [::]:80; får nginx til å lytte på IPv4 og IPv6. Glemmer du den andre linjen, virker ikke AAAA-recorden din (leksjon 7.1).
• server_name sier hvilke navn denne blokken gjelder for. Ved hver forespørsel ser nginx på navnet nettleseren ber om (Host-headeren), og velger blokken som passer.
• root er mappen med filer, index filen som vises når noen ber om en mappe.
• try_files prøver den forespurte filen, deretter en mappe, og gir ellers en 404. Uten en slik linje kan en feil konfigurasjon vise mer enn du vil.
• Egne loggfiler per nettsted gjør feilsøking mye enklere (leksjon 6.2).

Slå på nettstedet, fjern standardnettstedet, test og last inn på nytt:

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

Gjør nginx -t til en fast vane før hver reload. Ved en feil forteller kommandoen deg hvilken fil og hvilken linje det gjelder, og nettstedet som kjører, blir ikke berørt. Starter du på nytt uten å teste, vil nginx med en feil ikke starte igjen, og alle nettstedene dine er nede (leksjon 6.1).

Default server: hva får et ukjent navn?

Hva skjer hvis noen ber om serveren din med et navn som ikke står i noen server_name, eller bare med IP-adressen? Da velger nginx default server: blokken med default_server etter listen, eller ellers den første blokken den kom over. Uten at du tenker over det, er det altså et av de ekte nettstedene dine.

Ryddigere er en egen blokk som avviser slike forespørsler:

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

444 er en spesiell kode i nginx: tilkoblingen lukkes uten svar. Skannere som går gjennom IP-adresser, får dermed ingenting å se. For https (port 443) fungerer en default server litt annerledes, fordi det hører et sertifikat til; det kommer vi tilbake til i leksjon 7.3.

nginx som reverse proxy

Kjører det en applikasjon på 127.0.0.1:3000 (leksjon 6.3) eller en container på 127.0.0.1:3001 (leksjon 9.3), gjør nginx den tilgjengelig utad:

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

De fire proxy_set_header-linjene er viktige. Uten Host vet ikke applikasjonen hvilket navn den besøkes under. Uten X-Forwarded-For ser applikasjonen hvert besøk komme fra 127.0.0.1 (proxyen) i stedet for den ekte adressen til den besøkende. Uten X-Forwarded-Proto tror applikasjonen at alt går over http, og lager noen ganger lenker eller informasjonskapsler for http, mens nettstedet ditt kjører på https. Mange applikasjoner har en innstilling for å stole på disse headerne ("trusted proxy"); legg bare inn 127.0.0.1 der, ellers kan enhver besøkende sende med en falsk adresse.

Applikasjoner som bruker websockets (live-oppdateringer, som Uptime Kuma), trenger to linjer til: proxy_http_version 1.1; og videresending av Upgrade og Connection. Dokumentasjonen til applikasjonen sier som regel nøyaktig hvilke.

Rettigheter for webroot

På Debian og Ubuntu kjører nginx arbeidsprosessene sine som brukeren www-data. Den må kunne lese filene dine, men skal ikke kunne skrive til dem. En god inndeling (leksjon 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 {} \;

Du (anna) forvalter filene, gruppen www-data får lese, resten ingenting. Må nettstedet skrive et sted, for eksempel i en mappe for opplastinger, gir du bare den mappen skriverettigheter for www-data. Aldri chmod 777 (leksjon 10.2). Får du en 403 Forbidden, ser du i feilloggen til nettstedet: der står permission denied med stien.

Noen andre gode vaner:

• Ingen hemmeligheter i webroot. Sikkerhetskopier (site.zip), .env-filer og .git-mapper hører ikke hjemme der; havner de der ved et uhell, kan hvem som helst hente dem. Et ekstra sikkerhetsnett: location ~ /\. { deny all; } blokkerer alle filer som begynner med punktum (unntatt det du uttrykkelig tillater, som /.well-known/, se leksjon 7.3 og 7.4).
• Skjul versjonen. server_tokens off; i nginx.conf fjerner versjonsnummeret fra Server-headeren og feilsidene. Det er ingen ekte sikkerhet, men det gir skannere mindre informasjon.

PHP, kort fortalt

For PHP-nettsteder (som WordPress) snakker nginx med PHP-FPM, en egen tjeneste. På Debian installerer du php-fpm og legger inn en location ~ \.php$-blokk med include snippets/fastcgi-php.conf; og fastcgi_pass unix:/run/php/php8.4-fpm.sock; i server block (versjonsnummeret varierer fra utgivelse til utgivelse). WordPress-kurset går nærmere inn på dette.

På AlmaLinux og Rocky Linux

Der finnes ingen sites-available: du legger hvert nettsted som en egen fil i /etc/nginx/conf.d/<naam>.conf. nginx kjører som brukeren nginx i stedet for www-data, og standard webroot er /usr/share/nginx/html. SELinux lar som standard ikke nginx koble seg til en applikasjon bak proxy_pass; slå det på med setsebool -P httpd_can_network_connect 1. Filer utenfor de vanlige mappene trenger en SELinux-etikett (semanage fcontext og restorecon).

Sammendrag

• nginx serverer filer eller sender forespørsler som reverse proxy videre til en applikasjon på 127.0.0.1.
• Én server block per nettsted i sites-available, slås på med en lenke i sites-enabled; lytt på 80 og [::]:80.
• Alltid nginx -t før systemctl reload nginx.
• En egen default server med return 444 hindrer at et ukjent navn eller den nakne IP-adressen viser et av nettstedene dine.
• Som reverse proxy sender du videre Host, X-Forwarded-For og X-Forwarded-Proto; webroot kan leses av www-data, ikke skrives til, og inneholder ingen hemmeligheter.

Quiz

Oppgave

Oppgave O7.2: Det første nettstedet ditt. Installer nginx (eller bruk Caddy fra leksjon 7.4), og lag en server block for et (under)domene som peker til serveren din, med listen for IPv4 og IPv6, egne loggfiler og en egen default server. Test med nginx -t, last inn på nytt, og kontroller med curl -I over IPv4 og IPv6. Sett rettighetene for webroot slik som i leksjonen. Fyll ut sjekklisten og lim inn server block.

Les mer

• Forbidden (403): Du har ikke tilgang til / på denne serveren
• nginx-dokumentasjon, How nginx processes a request (server_name og default server): https://nginx.org/en/docs/http/request_processing.html
• nginx-dokumentasjon, Beginner's Guide: https://nginx.org/en/docs/beginners_guide.html
• nginx-dokumentasjon, ngx_http_proxy_module: https://nginx.org/en/docs/http/ngx_http_proxy_module.html