Plus facile à lire avec un fond crème, une teinte, plus de contraste ou un texte plus grand ? Choisissez vos couleurs et votre texte, une fois pour toutes les pages.

Leçon gratuite

Livrer un serveur web aux réglages sûrs

Après cette leçon: Je peux relire les réglages d’un serveur web avec une liste de contrôle.

Leçon de 55 min5 commandesLab de durcissement d’un serveur web : corriger une configuration nginx faible et la vérifier avec curl

La boulangerie qui en disait trop

Une boulangerie met son site en ligne. Personne ne pirate rien. Pourtant, n’importe qui voit quel logiciel elle utilise, lit un fichier de sauvegarde et liste un dossier avec les noms de ses fournisseurs.

Les réglages étaient ceux livrés avec le logiciel. Des réglages sûrs sont le premier travail de celui qui met un serveur en ligne.

À la fin de cette leçon

Remarque

Je peux relire les réglages d’un serveur web avec une liste de contrôle.

Mots-clés

MotCe que ça veut direExemple
Durcissementchanger des réglages pour qu’un système en dise et en permette moins
En-têteune ligne d’informations qui voyage avec une réponse web
Code de statutle nombre qui dit comment une requête s’est passée404
Réglage par défautle réglage utilisé quand personne n’en a choisi un
Surface d’attaquetout ce qu’un inconnu peut atteindre
Rechargementfaire relire ses réglages à un serveur, sans l’arrêter

Les cellules que les étudiants remplissent restent vides dans cet aperçu.

Un serveur répond avec plus qu’une page

Chaque réponse d’un serveur web porte un code de statut et des en-têtes. Le code dit comment cela s’est passé : 200 a marché, 404 introuvable, 405 méthode refusée.

Les en-têtes peuvent en dire trop. Chaque information apprise par un inconnu agrandit un peu votre surface d’attaque.

Votre labo a le serveur web d’une boulangerie, nommé web. Ces trois commandes regardent seulement ce qu’il dit.

Lire les en-têtes d’une réponse

Commande
curl -s -I http://web

Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.

Demander une page qui n’existe pas

Commande
curl -s -o /dev/null -w "%{http_code}\n" http://web/introuvable

Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.

Essayer une méthode qu’un site statique refuse

Commande
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE http://web/

Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.

Une revue compare les réglages à une liste

Pour durcir un serveur, lisez ses réglages ligne par ligne et posez toujours les mêmes questions. En dit-il trop ? En permet-il trop ? Garde-t-il une trace ?

Un réglage par défaut est écrit pour que le serveur démarre facilement, pas pour qu’il soit sûr. Le tableau liste des risques courants.

Exemple travaillé : une liste de contrôle

RéglageRisqueChoix plus sûr
Anciennes versions du protocoleDes failles connues restent exploitablesN’autoriser que les récentes
Aucune limite de taille d’envoiUn utilisateur remplit le disqueFixer une limite adaptée
Journal désactivéPersonne ne voit ce qui s’est passéGarder les journaux
N’importe quel site appelle l’APID’autres sites lisent vos donnéesNommer les sites autorisés

Les cellules que les étudiants remplissent restent vides dans cet aperçu.

Les réglages d’une librairie à relire

Code: bash
server {
    listen 443 ssl;
    server_name livres.exemple.fr;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    client_max_body_size 0;
    access_log off;
    add_header Access-Control-Allow-Origin *;
    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Une erreur fréquente

Attention

On croit souvent que cacher le numéro de version rend un serveur sûr. Cela ne cache qu’un indice. Un inconnu peut encore essayer toutes les failles connues. Cachez l’indice, mais mettez aussi le logiciel à jour et retirez ce qui n’a rien à faire là.

Tester un changement, puis recharger

nginx refuse un mauvais fichier au rechargement, mais le prochain redémarrage échoue. On teste donc le fichier d’abord. nginx a un test qui lit les réglages et dit s’ils sont valides.

Ensuite seulement, on recharge : le serveur en marche relit ses réglages sans perdre un visiteur.

Un script de contrôle change chaque règle de la liste en réussite ou en échec : une machine peut ainsi refaire la revue. Le labo en a un, à vous de l’utiliser après la leçon.

Tester les réglages, sans rien changer

Commande
docker exec web nginx -t

Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.

Demander quelle version tourne

Commande
docker exec web nginx -v

Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.

Pour aller plus loin

Après le devoir, ajoutez une septième règle à votre analyser_config : client_max_body_size avec une taille au-dessus de 100m donne limite-envoi-elevee. Une taille finit par k ou par m.

Écrivez deux tests à vous, l’un pour client_max_body_size 500m; et l’autre pour client_max_body_size 2m;. Vérifiez que seul le premier donne un constat.

À propos de ce labo et de sa source: Lab de durcissement d’un serveur web : corriger une configuration nginx faible et la vérifier avec curl

Vous enseignez à une classe ? Proposez ce module à vos étudiants avec un guide de l'enseignant, des devoirs corrigés et un laboratoire pour chaque étudiant.