Nginx-Server unter Ubuntu installieren und absichern

Nginx mit Website, UFW, HTTPS, Rechten, Headern, Updates und Prüfungen einrichten, ohne Fernzugriff zu verlieren.

Nginx-Server unter Ubuntu installieren und absichern

Nginx mit Website, UFW, HTTPS, Rechten, Headern, Updates und Prüfungen einrichten, ohne Fernzugriff zu verlieren.

Voraussetzungen und DNS

Nutzen Sie aktualisiertes Ubuntu Server und sudo. Für HTTPS muss example.com auf die öffentliche IP zeigen. Veröffentlichen Sie www und AAAA nur bei funktionierender Erreichbarkeit. Halten Sie eine zweite SSH-Sitzung und Wiederherstellungszugang bereit; prüfen Sie A/AAAA mit dig.

Installation und Prüfung

Installieren Sie das Ubuntu-Paket und prüfen Sie Dienst, Syntax und lokale HTTP-Antwort. Lokales HTTP 200 beweist keine externe Erreichbarkeit.

sudo apt update
sudo apt upgrade
sudo apt install nginx
sudo systemctl enable --now nginx
sudo nginx -t
curl -I http://127.0.0.1

UFW-Firewall

Erlauben Sie vor UFW die tatsächlich benutzte SSH-Portnummer. OpenSSH im Beispiel gilt für den Standard; für einen anderen Port NUMMER/tcp freigeben. Nginx Full öffnet TCP 80/443. Testen Sie nach Aktivierung eine neue SSH-Verbindung und lassen Sie die alte offen. Prüfen Sie Provider-Firewall und IPv6.

sudo ufw status verbose
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status verbose

Verzeichnis und Rechte

Das statische Beispiel nutzt Eigentum des Adminbenutzers, Gruppe www-data, Verzeichnisse 750 und Dateien 640. Prüfen Sie Durchgangsrechte sämtlicher Elternverzeichnisse. Dynamische Anwendungen benötigen eigene Regeln. Vermeiden Sie pauschales chown -R und 777.

sudo install -d -o "$USER" -g www-data -m 750 /var/www/example.com/public
printf '%s
' '<!doctype html><title>Example</title><h1>It works</h1>' | tee /var/www/example.com/public/index.html >/dev/null
chmod 640 /var/www/example.com/public/index.html

HTTP-Serverblock

Erstellen Sie /etc/nginx/sites-available/example.com. Beginnen Sie nur mit example.com; www erst mit passendem DNS und Zertifikat. Die Regel für versteckte Dateien kann /.well-known/ treffen: testen Sie die HTTP-Challenge und lassen Sie das Nginx-Plugin die Ausnahme vornehmen oder definieren Sie eine ausdrückliche Challenge-Location.

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    root /var/www/example.com/public;
    index index.html;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
    location / { try_files $uri $uri/ =404; }
    location ~ /\. { deny all; }
}

Aktivieren und testen

Erstellen Sie den Symlink, sofern nicht vorhanden. Vor Reload nginx -t ausführen und den Host lokal testen. Entfernen Sie die Default-Site erst, wenn sie nicht benötigt wird. Bei Testfehlern nicht neu laden.

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t && sudo systemctl reload nginx
curl -I -H 'Host: example.com' http://127.0.0.1

HTTPS-Zertifikat

Folgen Sie der aktuellen Certbot-Anleitung. Snap wird unterstützt; /snap/bin/certbot verhindert einen Konflikt mit vorhandenen Links. Port 80 muss für example.com öffentlich erreichbar sein. Das Beispiel beantragt nur diesen Namen. Certbot kann die Serverkonfiguration ändern. Prüfen Sie Redirect, Zertifikat und dry-run.

sudo snap install --classic certbot
sudo /snap/bin/certbot --nginx -d example.com
sudo nginx -t && sudo systemctl reload nginx
curl -I https://example.com
sudo /snap/bin/certbot renew --dry-run

Header und Grenzen

server_tokens off verbirgt die Versionsnummer, ersetzt aber keine Absicherung. Wählen Sie Header passend zur Anwendung und beachten Sie die Vererbung von add_header in Locations. SAMEORIGIN kann gewolltes Einbetten verhindern. 8m ist nur ein Beispiel. HSTS erst nach Tests aller betroffenen HTTPS-Namen, zunächst ohne Preload.

server_tokens off;
add_header X-Content-Type-Options nosniff always;
add_header Referrer-Policy strict-origin-when-cross-origin always;
add_header X-Frame-Options SAMEORIGIN always;
client_max_body_size 8m;

Optionaler Reverse Proxy

Ersetzen Sie die statische location / durch dieses Beispiel; zwei identische Locations sind ungültig. Das Backend sollte nach Möglichkeit nur auf 127.0.0.1:8080 lauschen. Vertrauen Sie Forwarded-Headern nur vom vorgesehenen Proxy; testen Sie Redirects, WebSockets und Timeouts.

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

Wartung und Logs

Aktualisieren Sie System und Anwendung; prüfen Sie unattended-upgrades im Rahmen der Wartung. Kontrollieren Sie Site-Logs, Journal, Plattenplatz und nginx -t. 403 kann an Rechten oder fehlendem Index liegen, 502 am Backend. Vor Reload immer testen.

sudo tail -f /var/log/nginx/example.com.error.log
sudo journalctl -u nginx --since '1 hour ago'
df -h
sudo nginx -t

Abschlussprüfung

Prüfen Sie SSH nach UFW, DNS/IPv6, öffentliche Ports, Rechte, nginx -t, HTTPS und Renewal-Dry-Run. Passen Sie Uploads, Header und Proxy der Anwendung an. Sichern Sie Konfiguration und überwachen Sie Dienste.

Offizielle Quellen

Nginx: https://nginx.org/en/docs/ ; Certbot: https://certbot.eff.org/instructions?ws=nginx&os=snap ; UFW: https://documentation.ubuntu.com/server/how-to/security/firewalls/ .

Teilen

Was ist Ihre Reaktion?

Gefällt mir Gefällt mir 0
Gefällt mir nicht Gefällt mir nicht 0
Liebe Liebe 0
Lustig Lustig 0
Wütend Wütend 0
Traurig Traurig 0
Wow Wow 0