Mon site servi par nginx

" | sudo tee /var/www/mon-site/index.html # Configuration vhost sudo vim /etc/nginx/sites-available/mon-site ``` Contenu : ``` server { listen 80; server_name lab.example.local; root /var/www/mon-site; index index.html; access_log /var/log/nginx/mon-site.access.log; error_log /var/log/nginx/mon-site.error.log; location / { try_files $uri $uri/ =404; } } ``` Activez le vhost et désactivez le site par défaut : ```bash sudo ln -s /etc/nginx/sites-available/mon-site /etc/nginx/sites-enabled/ sudo rm /etc/nginx/sites-enabled/default # Vérifier la syntaxe avant reload sudo nginx -t # nginx: configuration file /etc/nginx/nginx.conf test is successful sudo systemctl reload nginx ``` Décryptage : `nginx -t` est un test à blanc indispensable. Sans lui, un reload sur configuration cassée prend nginx au piège. `reload` recharge sans couper les connexions actives, contrairement à `restart`. ```mermaid flowchart LR C[Client] --> U[ufw 80/443] U --> N[nginx] N --> V[vhost mon-site] V --> S[/var/www/mon-site] style C fill:#64748b,color:#fff,stroke:none style U fill:#3b82f6,color:#fff,stroke:none style N fill:#10b981,color:#fff,stroke:none style V fill:#f59e0b,color:#fff,stroke:none style S fill:#8b5cf6,color:#fff,stroke:none ``` Testez depuis votre hôte : `curl http://192.168.1.50/` doit renvoyer la page HTML. Si le vhost répond uniquement sur un nom DNS, ajoutez l'entrée à votre `/etc/hosts` local. ## Étape 2 — Certificat TLS avec Let's Encrypt En production, **HTTPS** n'est plus une option. Let's Encrypt délivre des certificats gratuits, automatisés, valables 90 jours, renouvelés automatiquement par certbot. ```bash # Installer certbot et son plugin nginx sudo apt install -y certbot python3-certbot-nginx # Lancer la procédure interactive (suppose un nom de domaine public) sudo certbot --nginx -d mon-site.example.com # Pour un lab purement local sans DNS public, utilisez un certificat auto-signé sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/ssl/private/lab.key \ -out /etc/ssl/certs/lab.crt \ -subj "/CN=lab.example.local" ``` Décryptage : `certbot --nginx` détecte automatiquement votre vhost, demande l'email et l'accord des conditions, obtient le certificat, modifie le vhost pour ajouter le bloc `listen 443 ssl`, et configure une redirection HTTP → HTTPS. La commande crée aussi un timer systemd qui renouvelle automatiquement avant expiration. Pour un environnement de lab sans domaine public, modifiez le vhost pour utiliser le certificat auto-signé : ``` server { listen 80; server_name lab.example.local; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name lab.example.local; ssl_certificate /etc/ssl/certs/lab.crt; ssl_certificate_key /etc/ssl/private/lab.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; root /var/www/mon-site; index index.html; } ``` Décryptage : `listen 443 ssl http2` active TLS et HTTP/2. `ssl_protocols TLSv1.2 TLSv1.3` désactive les vieilles versions vulnérables. `return 301` redirige HTTP vers HTTPS de manière permanente. > 🔑 **À retenir** — Sur certbot, le **renouvellement automatique** est armé par défaut via un timer systemd. Vérifiez avec `systemctl list-timers | grep certbot`. Sans cela, votre certificat expire silencieusement. ## Étape 3 — Headers de sécurité Quatre en-têtes HTTP minimaux durcissent une configuration nginx contre les attaques courantes. ``` add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; ``` Ajoutez ces directives **dans le bloc `server` HTTPS** de votre vhost. Effets respectifs : | En-tête | Protection | |---|---| | Strict-Transport-Security (HSTS) | Force le HTTPS pour 1 an | | X-Frame-Options | Bloque le clickjacking via iframe | | X-Content-Type-Options | Bloque le MIME sniffing | | Referrer-Policy | Limite la fuite via Referer | `always` force l'envoi même sur les réponses d'erreur (4xx, 5xx), où nginx omettrait l'en-tête par défaut. ```bash sudo nginx -t sudo systemctl reload nginx # Vérifier que les en-têtes sont présents curl -I https://lab.example.local/ -k # HTTP/2 200 # strict-transport-security: max-age=31536000; includeSubDomains # x-frame-options: SAMEORIGIN # x-content-type-options: nosniff # referrer-policy: strict-origin-when-cross-origin ``` Décryptage : `curl -I` récupère uniquement les en-têtes, `-k` accepte le certificat auto-signé. Pour un audit complet, utilisez en ligne **Mozilla Observatory** ou **SSL Labs** une fois le site exposé publiquement. ## Étape 4 — Limiter les requêtes (rate limiting) Un client malveillant peut tenter des milliers de requêtes par seconde — soit pour un déni de service, soit pour deviner un mot de passe. nginx propose **`limit_req`** pour rate-limiter par client. Dans `/etc/nginx/nginx.conf`, **dans le bloc `http`**, déclarez une zone : ``` http { # Zone de 10 Mo, 5 requêtes par seconde par IP limit_req_zone $binary_remote_addr zone=zone_par_ip:10m rate=5r/s; ... } ``` Décryptage : `$binary_remote_addr` clé la limite sur l'IP cliente. `10m` = espace mémoire de 10 Mo (≈ 160 000 IP suivies). `rate=5r/s` = 5 requêtes par seconde par IP. Dans le `server` HTTPS, **appliquez** la limite à une location sensible (ex. `/api/login`) : ``` location /api/login { limit_req zone=zone_par_ip burst=10 nodelay; proxy_pass http://backend_app; } ``` Décryptage : `burst=10` autorise un pic de 10 requêtes au-dessus de la moyenne, `nodelay` ne diffère pas les requêtes du burst (réponse immédiate ou refus). Les requêtes au-delà reçoivent un **HTTP 503**. Vous voyez ces refus dans `/var/log/nginx/error.log` : ``` 2026-04-30 14:22:11 [error] limiting requests, excess: 11.342 by zone "zone_par_ip", client: 203.0.113.42 ``` Pour confirmer le rate limit en test, lancez 50 requêtes rapides : ```bash for i in $(seq 1 50); do curl -s -o /dev/null -w "%{http_code}\n" https://lab.example.local/api/login -k done | sort | uniq -c # 10 200 # 40 503 ``` ## Étape 5 — Logs custom et observation Les logs par défaut de nginx (format `combined`) sont lisibles. Pour les analyses fines, adaptez le format pour **mesurer les latences**. Dans `/etc/nginx/nginx.conf`, dans le bloc `http` : ``` log_format mesure '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' 'rt=$request_time uct=$upstream_connect_time uht=$upstream_header_time'; ``` Puis dans le vhost : ``` access_log /var/log/nginx/mon-site.access.log mesure; ``` Décryptage : `$request_time` = durée totale de traitement par nginx (ms). `$upstream_connect_time` = temps de connexion au backend. `$upstream_header_time` = temps avant premier byte du backend. Ces trois métriques permettent de diagnostiquer où passe le temps quand une requête est lente. Pour un test interactif depuis votre hôte, installez `httpstat` qui découpe la latence en couches (DNS, TCP, TLS, TTFB) : ```bash # Sur votre hôte pip install httpstat httpstat https://lab.example.local/ # DNS Lookup TCP Connection TLS Handshake Server Processing Content Transfer # [ 12ms | 8ms | 34ms | 102ms | 4ms ] ``` Décryptage : la latence se décompose en cinq étapes. Si `Server Processing` domine, c'est l'application back-end. Si `TLS Handshake` domine, vous pouvez activer **TLS session resumption** ou OCSP stapling. Cette mesure granulaire est précieuse en optimisation. ## Étape 6 — Checklist finale | Vérification | Commande | |---|---| | Vhost actif | `ls /etc/nginx/sites-enabled/` | | Configuration valide | `sudo nginx -t` | | Service running | `systemctl is-active nginx` | | HTTPS répond | `curl -I https://lab.example.local/ -k` | | HSTS présent | `curl -I https://... \| grep -i strict` | | ufw autorise 80 et 443 | `sudo ufw status` | | certbot timer actif (si LE) | `systemctl list-timers \| grep certbot` | | logs custom alimentés | `sudo tail /var/log/nginx/mon-site.access.log` | Si toutes les vérifications passent, **prenez un snapshot VirtualBox** nommé `nginx-hardened`. Ce snapshot est un livrable réutilisable : vous pourrez le cloner pour tester la suite du curriculum sans repartir de zéro. ## 🏢 Cas concret Une **plateforme média** ouvre un nouveau service de diffusion vidéo. L'équipe SRE applique la procédure de ce TP en l'enrichissant : trois vhosts (front public, espace abonné, API), Let's Encrypt sur les trois, headers complets dont **Content-Security-Policy** restrictif, rate limit sur l'API à 100 requêtes/seconde par IP, logs custom envoyés à un agrégateur central via journald. Trois mois plus tard, un pic de trafic légitime fait passer 8000 requêtes/seconde sur l'API. Le rate limit absorbe les pics individuels (un bot mal configuré client mobile saturait à 200 req/s), tandis que les vrais utilisateurs passent normalement. Les logs custom permettent d'identifier le client buggé et de le contacter pour un correctif. Sans ces fondations posées au TP, l'incident aurait nécessité une intervention manuelle stressante. ## ⚠️ Pièges fréquents | Piège | Pourquoi ça arrive | Comment l'éviter | |---|---|---| | Reload sur config cassée | Pas de `nginx -t` avant | `nginx -t` systématique avant tout reload | | HSTS sans HTTPS valide | Activé trop tôt | Tester HTTPS d'abord, HSTS ensuite | | Limite trop basse en prod | Test sur faible trafic | Mesurer avant de fixer un seuil réaliste | | Certbot non automatisé | Renouvellement manuel | `systemctl list-timers \| grep certbot` | | Logs sans `body_bytes_sent` | Format minimal | Adopter format `mesure` ci-dessus | ## ✍️ À vous de jouer **Exercice 1** — Installez nginx, créez un vhost `mon-lab` qui sert `/var/www/mon-lab/index.html`, activez-le, vérifiez avec curl. Ajoutez les 4 headers de sécurité de la leçon et confirmez leur présence. **Exercice 2** — Configurez un rate limit de **3 requêtes par seconde** sur `/login` avec `burst=5`. Lancez 30 requêtes en boucle et comptez les 200 vs 503 reçus. **Exercice 3** *(optionnel)* — Si vous disposez d'un nom de domaine public et d'un serveur exposé, obtenez un certificat Let's Encrypt avec `certbot --nginx`. Vérifiez le timer de renouvellement automatique. ## 📌 En résumé - Un **vhost nginx** vit dans `/etc/nginx/sites-available/` et s'active par lien symbolique - **certbot** automatise Let's Encrypt et arme un timer systemd de renouvellement - Quatre **headers de sécurité** durcissent la configuration : HSTS, X-Frame, X-Content, Referrer - **`limit_req`** rate-limite par IP avec une zone partagée et un `burst` configurable - Les **logs custom** mesurant latence et upstream sont indispensables au diagnostic **🎓 La suite de votre parcours** Vous achevez 30 heures de pratique : un serveur Ubuntu installé de A à Z, des utilisateurs et permissions structurés, des services gérés par systemd, des journaux maîtrisés et un serveur web durci avec TLS et rate limiting. Vous avez maintenant les **réflexes d'un administrateur Linux junior opérationnel** — capable de livrer un serveur propre seul, de diagnostiquer un incident en quelques minutes et de comprendre ce qui se passe sous le capot des plateformes cloud modernes. Bravo. Cette base ne s'oublie pas. Pour transformer ces gestes manuels en automatismes scriptés, enchaînez avec **Bash Scripting et Automatisation Locale** (cours 2) : vous remplacerez les checklists du TP par des scripts versionnés et reproductibles. Pour comprendre comment vos serveurs communiquent entre eux, **Réseaux TCP/IP** (cours 5) vous donne les fondations indispensables avant de toucher à la virtualisation, au cloud ou à Kubernetes. Pour les profils plus orientés données, **Python pour Administration Système** (cours 14) ouvre la voie aux outils ops modernes, à l'API cloud et au monitoring custom. Quel que soit le chemin choisi, vous repartez avec un **socle Linux solide** — celui sur lequel reposent toutes les briques du curriculum *Administration Système et Cloud Computing*. Bonne suite.

Account

TP — configurer un serveur web nginx hardened

Ressources

Aucune ressource

Ressource

Your Cart

Complete Your Registration

Order Summary

Payment Information