Contrôle final : votre serveur passé au crible

Module 10: Rester en sécurité · Temps de lecture : 10 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez évaluer votre propre serveur à l'aide d'une checklist et d'un contrôle automatique depuis l'extérieur. Vous saurez quels points sont prioritaires, et vous disposerez d'un rythme de maintenance fixe et d'un court dossier serveur.

Notions clés : checklist, priorité, contrôle depuis l'extérieur, dossier serveur, rythme de maintenance (hebdomadaire, mensuel, trimestriel, annuel), date de fin de vie de la version, test de restauration

Des leçons séparées à un ensemble cohérent

Au fil de cette formation, vous avez configuré un serveur pas à pas : connexion sécurisée, droits, mises à jour, pare-feu, services, un site web en https, sauvegardes, surveillance et conteneurs. Dans cette dernière leçon, vous rassemblez tout sur une seule liste. Vous passez votre serveur en revue, vous laissez le programme de la formation l'examiner depuis l'extérieur, et vous définissez comment vous allez l'entretenir dans les années à venir.

Un serveur n'est jamais "terminé". Les logiciels vieillissent, les certificats expirent, les disques se remplissent, les versions arrivent en fin de vie (end of life). Un rythme régulier est donc aussi important que la configuration initiale.

La checklist, par ordre d'importance

Tout n'est pas aussi urgent. Parcourez la liste de haut en bas : les premiers blocs évitent la plupart des ennuis.

Bloc 1 : personne n'entre sans y être invité (modules 2, 3, 5)

• Connexion uniquement par clés ; PasswordAuthentication no et KbdInteractiveAuthentication no, vérifiés avec sudo sshd -T.
• Root ne se connecte pas avec un mot de passe ; vous travaillez en tant qu'utilisateur normal avec sudo.
• Les bases de données, caches et clusters de recherche écoutent sur 127.0.0.1 ; les ports 3306, 5432, 6379, 9200 et 27017 sont fermés depuis l'extérieur, en IPv4 comme en IPv6.
• Un pare-feu qui bloque par défaut tout le trafic entrant ; seuls les ports dont vous avez besoin sont ouverts.
• fail2ban tourne pour SSH (fail2ban-client status sshd).

Bloc 2 : les failles sont corrigées (module 4)

• Mises à jour de sécurité automatiques activées et vérifiées (journal, apt list --upgradable).
• Un plan pour les redémarrages ; /var/run/reboot-required ne reste pas là pendant des semaines.
• La version est encore prise en charge ; sa date de fin de vie figure dans votre agenda.

Bloc 3 : vous pouvez revenir en arrière (module 8)

• Des sauvegardes chiffrées hors du serveur, automatiques et surveillées.
• Un test de restauration effectué, et vous savez combien de temps prend une restauration.
• Vous savez comment créer un snapshot et ouvrir la console.

Bloc 4 : la façade est correcte (module 7)

• Les enregistrements A et AAAA pointent vers votre serveur ; le DNS inverse (PTR) renvoie vers le même nom.
• https avec un certificat valide renouvelé automatiquement ; http redirige vers https.
• HSTS et quelques en-têtes de sécurité ; un security.txt avec une adresse de contact fonctionnelle et une date d'expiration.

Bloc 5 : vous voyez ce qui se passe (modules 6, 8)

• Le journal est persistant ; vous pouvez lire les logs d'avant un redémarrage.
• Une surveillance depuis l'extérieur (accessibilité, certificat) et depuis l'intérieur (disque, services), avec des alertes qui arrivent bien.
• systemctl --failed est vide.

Bloc 6 : les conteneurs sous contrôle (module 9, si vous utilisez Docker)

• Les ports des conteneurs sur 127.0.0.1 ou derrière le reverse proxy ; pas de docker.sock dans les conteneurs qui n'en ont pas réellement besoin.
• Les volumes sont inclus dans la sauvegarde ; les images sont mises à jour régulièrement.
• Les secrets se trouvent dans des fichiers .env aux droits stricts, pas dans Git.

Le contrôle depuis l'extérieur

Une partie de cette liste peut être vérifiée depuis l'extérieur par le programme de la formation, exactement comme n'importe qui sur Internet voit votre serveur. L'exercice final (Z10.4) regroupe les contrôles des exercices précédents :

Le programme n'exécute rien sur votre serveur, n'essaie aucun mot de passe et ne scanne aucun autre port. Chaque adresse ne peut être contrôlée que quelques fois par heure. Un résultat vert signifie : vu de l'extérieur, les erreurs les plus connues sont absentes. Il ne dit rien de ce qui se passe à l'intérieur de votre serveur ; c'est le reste de la checklist, que vous parcourez vous-même.

Le dossier serveur

Rédigez pour chaque serveur un court document, conservé hors du serveur (par exemple dans votre gestionnaire de mots de passe ou un dossier partagé) :

• nom, adresses IP, fournisseur, version et date de fin de vie ;
• ce qui tourne (services, conteneurs, sites web) et pourquoi ;
• quels ports sont ouverts et à quoi ils servent ;
• où se trouvent les sauvegardes, comment restaurer, date du dernier test ;
• quels secrets se trouvent sur le serveur (pas les secrets eux-mêmes, mais lesquels et où les remplacer) ;
• ce que vous avez volontairement fait autrement que la configuration standard (par exemple une suggestion de Lynis que vous avez ignorée, leçon 10.1) ;
• qui a accès (quelles clés figurent dans authorized_keys).

Ce dossier vaut de l'or en cas d'incident (leçon 10.3), lors d'une mise à niveau de version (leçon 4.3) et si quelqu'un d'autre reprend la gestion.

Un rythme de maintenance

Sans rythme, la vigilance se relâche. Voici un exemple pour un petit serveur ; adaptez-le à votre situation.

Inscrivez ces moments dans votre agenda. Une grande partie peut aussi être automatisée avec la surveillance de la leçon 8.3, mais un regard humain reste nécessaire.

En pratique

Que votre serveur soit chez WebOké ou chez un autre fournisseur : le fournisseur s'occupe du matériel, du réseau et de la possibilité de créer des snapshots et des sauvegardes, vous de tout ce qui se trouve à l'intérieur du serveur. Cette formation est de l'auto-assistance : personne ne surveille votre serveur à votre place. Avec cette checklist, le dossier et le rythme, vous avez cependant tout en main pour assurer cette gestion de manière autonome et rigoureuse.

Résumé

• Passez votre serveur en revue par blocs : personne n'entre sans y être invité, les failles sont corrigées, vous pouvez revenir en arrière, la façade est correcte, vous voyez ce qui se passe, les conteneurs sont sous contrôle.
• Le contrôle depuis l'extérieur examine les méthodes de connexion SSH, les ports de base de données, https, les en-têtes, security.txt et l'en-tête de votre conteneur ; le reste, vous le vérifiez vous-même.
• Tenez un dossier serveur, conservé hors du serveur.
• Travaillez avec un rythme fixe : hebdomadaire, mensuel, trimestriel et annuel.

Quiz

Exercice

Exercice Z10.4 : Exercice final : votre serveur vu de l'extérieur. Laissez le programme de la formation contrôler votre serveur depuis l'extérieur en une seule fois : les méthodes de connexion SSH pour votre nom d'utilisateur, les cinq ports de base de données, https et les en-têtes de votre site, votre security.txt, et l'en-tête X-Weboke-Cursus contenant votre code sur le nom où tourne votre conteneur. Remplissez en parallèle la checklist des blocs 1 à 6 pour ce que le programme ne peut pas voir.

Exercice O10.4 : Votre rythme de maintenance. Créez votre propre dossier serveur et votre rythme de maintenance : ce que vous faites chaque semaine, chaque mois, chaque trimestre et chaque année, puis inscrivez ces moments dans votre agenda.

Pour aller plus loin

• Sécuriser votre VPS : les cinq premières minutes
• HSTS et en-têtes de sécurité pour votre site web
• Stratégie de sauvegarde : la règle du 3-2-1 pour votre propre entreprise
• securitytxt.org (explications et générateur pour security.txt) : https://securitytxt.org/
• Le NCSC néerlandais, Établir une stratégie de sauvegarde (source néerlandaise, en néerlandais) : https://www.ncsc.nl/back-up/een-back-up-strategie-opstellen