Différences

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

--- pratique:informatique:securite_serveur [06/06/2025 13:40] – 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.
   * Désactiver les modules noyaux inutiles ? (les lister ?)
   * Désactiver les services inutiles
-    * Lister : ''sudo systemctl list-unit-files --state=enabled''
+    * Lister : ''<nowiki>sudo systemctl list-unit-files --state=enabled</nowiki>''
   * 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 34: / Ligne 133: @@
 Surveillance des modifications : voir AIDE/Samhain/OSSEC/Autre ? Rkhunter est obsolète.
-Alertes de sécurités :
 ===== Analyses =====
-Alternative à Rkhunter ? Repérer les signatures de trucs foireux.
+<WRAP center round todo 60%>
+Alternative à Rkhunter ? Repérer les signatures de trucs foireux. Lynis [[https://cisofy.com/lynis/controls/FINT-4350/|préconise]] AIDE, Samhain ou Tripwire ; voir comment chacun fonctionne.
+</WRAP>
 ==== Logwatch ====
@@ Ligne 76: / Ligne 177: @@
 Des recommendations et conseils sont présents à la fin de l'analyse, suivant ce qui a été détecté. Moralité je vais pouvoir encore améliorer ma doc...
+=== Retours ===
+== Réseau, promiscuité, bridge et hyperviseur ==
+Sur Xen, depuis l'hyperviseur, on peut avoir ces alertes :
+<code>
+  ! Found promiscuous interface [NETW-3015]
+    - Details  : enp2s0
+    - Solution : Determine if this mode is required or whitelist interface in profile
+      https://cisofy.com/lynis/controls/NETW-3015/
+  ! Found promiscuous interface [NETW-3015]
+    - Details  : vif1.0
+    - Solution : Determine if this mode is required or whitelist interface in profile
+      https://cisofy.com/lynis/controls/NETW-3015/
+  ! Found promiscuous interface [NETW-3015]
+    - Details  : vif2.0
+    - Solution : Determine if this mode is required or whitelist interface in profile
+      https://cisofy.com/lynis/controls/NETW-3015/
+</code>
+C'est normal qu'en mode bridge, on aie une "promiscuité". Mais chaque VM est dans son propre réseau (vif1, vif2) et si j'ai bien compris, ne pourra pas "sniffer" les communications des autres VM et de l'hyperviseur, même si elle est compromise. D'ailleurs, Lynis exécuté sur une VM ne donne pas cette alerte.
+== Password sur Grub ==
+La recommandation n'est pas de demander un mot de passe pour démarrer la machine (ce serait le bordel sur serveur). Mais quand on est en phase de démarrage, si on choisit d'éditer le boot, il faut alors renseigner le mot de passe. Cela évite qu'un attaquant bypass des protections à ce moment. Cependant dans mon modèle de menace, cela semble plus générateur d'ennuis que d'autres choses :
+  * Mes serveurs sont dans des zones relativement sécurisées (chez moi ou datacenter) par rapport au niveau de risque. Mon modèle de menace étant la malveillance non ciblée (bots). Si un cambrioleur pique mon serveur, ce n'est pas un boot avec mot de passe qui l'empêchera d'accéder au disque...
+  * Par contre j'ai déjà eu quelques fois à dépanner un serveur qui déconne, et dans ce cas, bidouiller Grub facilement a été utile. Si j'avais eu un mot de passe à entrer, il aurait fallu que je retrouve "où" je l'avais mis et que j'arrive à le taper en qwerty.
+  * Par ailleurs, un mot de passe n'est utile que si par ailleurs le disque est chiffré. Cf le chapitre correspondant.
+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 ====
@@ Ligne 86: / Ligne 221: @@
 </WRAP>
+Est-ce utile de l'avoir ?
+Un système assez "nu" va déjà lister de nombreuses alertes, beaucoup n'étant pas critiques dans notre modèle de menaces. Ce flot important n'aide pas à repérer ce sur quoi on peut agir. Tenir son système à jour est souvent la seule réponse...
+On peut cependant essayer de filtrer un peu.
+<code>debsecan --suite bookworm --format report | grep -E "high|critical"</code>
+  * ''--suite bookworm'' : nécessaire d'indiquer le nom de code de la version debian actuelle, pour filtrer.
+  * ''--format report'' pour avoir sur la même ligne le nom de la CVE et les mots-clés adaptés. Encore faut-il que ce soit précisé dans les premiers mots.
-Est-ce utile de l'avoir ? Il y a énormément de failles, beaucoup n'étant pas forcément
+En l'état, vu le système des CVE et le manque d'outil adapté pour filtrer, il semble difficile d'utiliser Debsecan au quotidien.