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.

Tout ce qui suit est pour Debian Stable.

Checklist rapide. Configuration de :

• Gestion des utilisatrices (groupes Sudoers). Pas de compte “root” facile d'accès.
• SSH
• Pare-feu (nftables)
• Paramétrer l'envoi de mails depuis le serveur (msmtp ou autre)
• Journalisation et audit
• Fail2ban/Reaction
• Backup
• Monitoring et alertes

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
• Supprimer les paquets inutiles, éviter d'installer les “suggérés” et questionner l

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.

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.

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.

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 :

/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  

libpam-passwdqc (vérifier si ce n'est pas en conflit avec pwquality?)

/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

• 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

Quelques modifs sur ce fichier pourrait améliorer la sécurité (recommandations Lynis).

/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

Forcez le re-hachage des mots de passe existants avec :

# 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> 

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é.

/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

• Paramétrer rsyslog (non je n'aime pas journald), logrotate
• Envoyer les logs à un serveur central (TODO : voir quel logiciel j'utilise pour ça).

Surveillance des modifications : voir AIDE/Samhain/OSSEC/Autre ? Rkhunter est obsolète.

sudo apt install logwatch

Logwatch n'est pas un outil qui va agir, par contre il analyse les logs et en rends un rapport plus digeste. Si, vraiment plus digeste, ça permet de voir les bots.

C'est donc utile pour améliorer ses filtres. Une fois msmtp configuré (ou autre solution d'envoi de mail), créer le dossier pour Logwatch :

sudo mkdir /var/cache/logwatch

Et le paramétrer

sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/
sudo nano /etc/logwatch/conf/logwatch.conf

Dans mon cas je permet surtout l'envoi du rapport par mail, mais à adapter si besoin (entre autre l'émetteur/Récepteur), et la quantité de détails (à adapter au fil des filtres…) :

/etc/logwatch/conf/logwatch.conf

Output = mail
Detail = 5

Pour MailTo on peut déclarer plusieurs adresses mails, séparées par un espace :

MailTo = mail1@moi.net mail2@moi.net 

Et un coup de cron journalier (sur root) :

15 1 * * * /usr/sbin/logwatch >/dev/null 2>&1 #logwatch

Lynis aide à auditer son système. Il ne fait rien seul, mais il aide à voir là où on est pas forcément top. Simplement sudo apt install lynis.

Pour voir la liste des options :

sudo lynis

Pour un check du systeme, en root :

lynis audit system

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…

Sur Xen, depuis l'hyperviseur, on peut avoir ces alertes :

 
  ! 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/

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.

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.

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.

debsecan --suite bookworm --format report | grep -E "high|critical"

• –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.

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.