Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:securite_serveur [08/06/2025 08:53] – [Lynis] Zatalyz
+++ pratique:informatique:securite_serveur [13/06/2025 11:56] (Version actuelle) – [Chiffrement des disques] Zatalyz
@@ Ligne 1: / Ligne 1: @@
 ====== Sécurité sur un serveur ======
 Je ne vais pas être exhaustive, la sécurité dépendant des modèles de menace, de l'infrastructure, et n'étant jamais parfaite. Je passe rapidement la configuration de base (ne pas pouvoir se co en "root", utiliser sudo, paramétrer SSH) : un bon système est une base.
@@ Ligne 15: / Ligne 16: @@
   * Monitoring et alertes
-==== Désactiver ce qui ne sert pas ====
+===== Désactiver ce qui ne sert pas =====
 Moins de trucs installés = moins de surface d'attaque.
@@ Ligne 23: / Ligne 24: @@
   * Supprimer les paquets inutiles, éviter d'installer les "suggérés" et questionner l
+===== Chiffrement des disques =====
+Faut-il chiffrer les disques de ses serveurs ? Cela dépend surtout du modèle de menace.
+Scénario :
+  * Accès physique à la machine ou accès à la commande de montage des disques à distance (mode rescue des hébergeurs). Donc un niveau de compromission assez élevé (ou une saisie de justice).
+  * Aucune chance que cela soit dans des attaques automatisées ?
+Contraintes techniques du chiffrement :
+  * Impact sur les performances (CPU), moins vrai au fil du temps (CPU plus puisssants, vérifier si support de AES-NI).
+  * Suivant le système des fichiers c'est plus ou moins facile à mettre en place de façon efficace, mais ça reste un détail.
+  * S'assurer que la swap aussi est chiffrée (encrypt-swap)
+  * Risque de ne plus pouvoir redémarrer la machine après une mise à jour du noyau si initramfs n'est pas régénéré proprement.
+  * Si le /boot n'est pas chiffré aussi, c'est une surface d'attaque.
+  * Sans accès physique à la machine, en cas de souci, rebooter en mode rescue sera sans doute bien complexe (mais le boot rescue doit rester possible avec la clé ?)
+Contraintes humaines :
+  * Gestion des clés. Si perdues, tout le contenu du disque l'est aussi.
+  * Il faut saisir la phrase de passe au démarrage. Il y a moyen d'automatiser mais cela fait une surface d'attaque. Sur des serveurs distants sans console physique, les méthodes pour déchiffrer le disque demandent du boulot.
+<del>Conclusion : il vaut mieux chiffrer les données sur le disque (pour les logiciels qui le supportent), et garder le chiffrement des disques durs pour les ordinateurs portables et les disques externes.</del>
+Cependant, il y a des témoignages où les autorités ont obtenu des dumps des disques durs auprès des datacenter, sans que les personnes ayant le serveur en aient été préalablement prévenu. Cela doit sans doute se glisser dans des interstices (suspicion que l'hébergeur soit de mèche avec le contenu illégal posté sur ses services), mais c'est gênant.
+En théorie aussi des disques durs décommissionnés sont effacés, mais est-ce qu'on peut faire complètement confiance à la compétence des autres ? Pour ces deux raisons, peut-être qu'il faut envisager de chiffrer quand même.
+===== Gestion des comptes et mots de passe =====
+Linux utilise PAM (Pluggable Authentication Modules) pour la gestion des méchanismes d'authentification. Il est possible d'ajouter des modules pour renforcer ces méchanismes, qui s'appliqueront dans divers scénarios. PAM gère en particulier :
+  * L'authentification
+  * La gestion des sessions
+  * Les contrôles d'accès
+  * La gestion des mots de passe.
+Il est possible de garder l'authentification de base, mais aussi de lier ça à d'autres types d'authentification. Par exemple le module pam_ldap.so permet de s'authentifier via un serveur LDAP.
+C'est une bonne façon de se bloquer l'accès à son propre serveur, donc on bidouille avec précaution (garder les fichiers par défauts en ''bak'', tester la reconnection avec une autre session avant de se déco de la première...).
+Quelques modules et modifications sur PAM permettent d'augmenter la sécurité.
+**libpam-pwquality** pour améliorer la qualité des mots de passe. Éditer après son installation :
+<code bash /etc/security/pwquality.conf>
+minlen = 12
+# Au moins 3 catégories (majuscule, minuscule, chiffre, symbole)
+minclass = 3
+# Au moins 1 chiffre
+dcredit = -1
+# Au moins 1 majuscule
+ucredit = -1
+</code>
+**libpam-passwdqc** (vérifier si ce n'est pas en conflit avec pwquality?)
+<code bash /etc/pam.d/common-password>
+# Bloquer les mots de passe faibles
+password requisite pam_passwdqc.so min=12,10,8,7,6 max=40 passphrase=1 enforce=users
+</code>
+  * ''min=12,10,8,7,6'' Longueurs minimales selon la complexité (de 1 à 4 classes de caractères) (TODO revoir avant de copier bêtement)
+  * ''max=40'' : Longueur maximale. Interdire de faire trop long évite qu'un mot de passe freeze la machine...
+  * ''passphrase=1'' : Autorise les longues phrases de passe
+  * ''match=4'' : Mots du dictionnaire requis pour une passphrase (si activée) (Gnih ? TODO)
+  * ''similar=deny'' : Rejette les mots de passe trop proches du précédent
+  * ''enforce=users'' : Applique la politique à tous les utilisateurs
+==== Fichier /etc/login.defs ====
+Quelques modifs sur ce fichier pourrait améliorer la sécurité (recommandations Lynis).
+<WRAP center round important 60%>
+Cette partie demande une validation par Tycho ET des expérimentations : choisir le bon chiffrement et voir si la machine supporte l'augmentation des rounds de hachage. Possible que ce ne soit plus avec login.defs aussi, mais avec /etc/pam.d/common-password (entre autre) et Yescrypt. Bref, la question me dépasse.
+</WRAP>
+<code bash /etc/login.defs>
+# Forcer l'utilisation de SHA-512 au lieu de l'algo par défaut (MD5/DES obsolètes)
+ENCRYPT_METHOD SHA512
+# Nombre minimal de rounds (itérations) pour le hachage
+SHA_CRYPT_MIN_ROUNDS 100000
+# Nombre maximal de rounds
+SHA_CRYPT_MAX_ROUNDS 100000
+# Longueur minimale des mots de passe
+PASS_MIN_LEN    12   # 12 caractères minimum
+</code>
+Forcez le re-hachage des mots de passe existants avec :
+<code bash># Applique PASS_MAX_DAYS/MIN_DAYS/WARN_AGE
+sudo chage -M 90 -m 7 -W 14 <utilisateur>
+# Et forcer le changement de mot de passe à la prochaine connexion
+sudo passwd -e <utilisateur> </code>
+Il est aussi possible de définir une durée de vie pour les mots de passe. Ce qui est bien MAIS qui demande d'avoir une automatisation en cas de nombreux serveurs VM, sinon c'est juste l'enfer. Je trouverais en réalité plus intéressant de gérer ça via LDAP et le module PAM associé.
+<code bash /etc/login.defs>
+# Durée de vie des mots de passe (en jours)
+# Force le changement après 3 mois
+PASS_MAX_DAYS 90
+# Délai minimal entre 2 changements
+PASS_MIN_DAYS 0
+# Avertir 2 semaines avant expiration
+PASS_WARN_AGE 14
+</code>
 ===== Journalisation et audit =====
 <WRAP center round todo 100%>
@@ Ligne 33: / Ligne 133: @@
 Surveillance des modifications : voir AIDE/Samhain/OSSEC/Autre ? Rkhunter est obsolète.
-Alertes de sécurités :
@@ Ligne 111: / Ligne 210: @@
 La proposition reste pertinente, bien sûr, et sera à faire pour réellement sécuriser un serveur, mais dans mon cas, je considère que le risque est si faible que je peux me concentrer sur d'autres choses.
 ==== Debsecan ====