Installer et sécuriser Nginx sur Ubuntu

Configurer Nginx, un site, UFW, HTTPS, les permissions et les vérifications tout en conservant l’accès distant.

Installer et sécuriser Nginx sur Ubuntu

Configurer Nginx, un site, UFW, HTTPS, les permissions et les vérifications tout en conservant l’accès distant.

Prérequis et DNS

Utilisez Ubuntu Server à jour et sudo. Pour HTTPS, example.com doit pointer vers l’adresse publique. Ne publiez www ou AAAA que si ces accès fonctionnent. Gardez une deuxième session SSH et un accès de secours ; contrôlez A/AAAA avec dig.

Installation et contrôle

Installez le paquet Ubuntu puis vérifiez service, syntaxe et réponse HTTP locale. Un HTTP 200 local ne prouve pas l’accès public.

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

Pare-feu UFW

Autorisez le vrai port SSH avant UFW. OpenSSH dans l’exemple correspond au profil standard ; pour un port personnalisé, utilisez NUMÉRO/tcp. Nginx Full ouvre TCP 80/443. Testez une nouvelle session SSH sans fermer l’ancienne. Vérifiez aussi le pare-feu du fournisseur et IPv6.

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

Dossier et permissions

Le site statique utilise un dossier appartenant à l’administrateur, groupe www-data, dossiers 750 et fichiers 640. Vérifiez la traversée de tous les dossiers parents. Les applications dynamiques exigent leurs propres règles ; évitez chown -R généralisé et 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

Bloc HTTP

Créez /etc/nginx/sites-available/example.com. Commencez avec example.com seulement ; ajoutez www si DNS et certificat le couvrent. La règle des fichiers cachés peut toucher /.well-known/ : testez le challenge HTTP et laissez le plugin Nginx créer l’exception ou ajoutez une location explicite pour le challenge.

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

Activation et test

Créez le lien symbolique s’il manque, lancez nginx -t avant reload et testez Host localement. Désactivez le site par défaut seulement après avoir vérifié son inutilité. Corrigez toute erreur de syntaxe avant le rechargement.

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

Certificat HTTPS

Suivez les instructions Certbot actuelles. Snap est pris en charge ; appeler /snap/bin/certbot évite un lien en conflit avec une installation existante. example.com doit être publiquement joignable sur le port 80. L’exemple ne demande que ce nom. Certbot peut modifier le bloc serveur ; testez redirection, certificat et renouvellement à blanc.

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

En-têtes et limites

server_tokens off masque la version sans garantir la sécurité. Adaptez les en-têtes à l’application et vérifiez l’héritage add_header dans les locations. SAMEORIGIN peut empêcher une intégration voulue. 8m est indicatif. N’activez HSTS qu’après des tests HTTPS et sous-domaines, sans preload au début.

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;

Proxy inverse facultatif

Remplacez la location / statique par ce bloc ; deux locations identiques ne conviennent pas. Le backend devrait écouter sur 127.0.0.1:8080 s’il n’est pas public. Ne faites confiance aux en-têtes transférés que depuis le proxy prévu ; testez redirections, WebSockets et délais.

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

Maintenance et journaux

Mettez à jour système et application ; évaluez unattended-upgrades selon vos procédures. Examinez journaux, espace et nginx -t. Un 403 peut venir des permissions ou d’un index absent ; un 502 d’un backend indisponible. Testez avant chaque reload.

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

Contrôles finaux

Vérifiez SSH après UFW, DNS/IPv6, ports publics, permissions, nginx -t, HTTPS et renouvellement à blanc. Adaptez upload, en-têtes et proxy au site. Sauvegardez la configuration et surveillez le service.

Sources officielles

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/ .

Partager

Quelle est votre réaction ?

Aimer Aimer 0
Je n'aime pas Je n'aime pas 0
Amour Amour 0
Drôle Drôle 0
En colère En colère 0
Triste Triste 0
Waouh Waouh 0