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

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

Alertes de sécurités :

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.

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