Notes › _DIFFUSION

comment analyser un rapport lynis-report.dat `lynis-report.dat` est le fichier de résultats généré par Lynis, généralement situé dans `/var/log/lynis-report.dat`.

Il contient surtout des lignes au format clé-valeur, par exemple :

osdistro[]=Debian
hardening_index[]=72
warning[]=FILE-6310|Some files have incorrect permissions
suggestion[]=NETW-2705|Consider disabling unused network protocols

1. Afficher le rapport lisiblement

sudo less /var/log/lynis-report.dat

Rechercher les éléments importants :

sudo grep -E '^(hardening_index|warning|suggestion|osdistro|osname|os_version)' \
  /var/log/lynis-report.dat

Afficher uniquement les avertissements :

sudo grep '^warning' /var/log/lynis-report.dat

Afficher uniquement les suggestions :

sudo grep '^suggestion' /var/log/lynis-report.dat

2. Comprendre les principales lignes

• hardening_index : score global de renforcement, sur 100.
• warning : problème potentiellement important à examiner.
• suggestion : recommandation d’amélioration, pas forcément une vulnérabilité.
• osname, osdistro, os_version : système analysé.
• tests_executed : tests exécutés par Lynis.
• plugins_enabled : extensions ou plugins utilisés.
• warning[]=CODE|DESCRIPTION : code du test et explication.
• suggestion[]=CODE|DESCRIPTION : identifiant de recommandation et explication.

Le score est un indicateur de configuration, pas une note de sécurité absolue. Un score élevé ne garantit pas l’absence de vulnérabilités.

3. Extraire les codes et descriptions

Pour obtenir une lecture plus pratique :

sudo awk -F'[][]=|\\|' '
/^(warning|suggestion)/ {
    type=$1
    split($0, a, "\\|")
    print type ": " a[1] " - " a[2]
}' /var/log/lynis-report.dat

Selon la version de Lynis, la structure peut légèrement varier. Une méthode simple et robuste consiste à utiliser :

sudo grep -E '^(warning|suggestion)' /var/log/lynis-report.dat |
  sed 's/.*\[\]=//; s/|/ : /'

4. Relier les résultats aux tests Lynis

Le code, par exemple FILE-6310 ou NETW-2705, permet d’identifier le contrôle concerné. Pour obtenir davantage de contexte, relancez Lynis en mode audit :

sudo lynis audit system

Puis consultez directement la sortie affichée. Vous pouvez aussi lancer le test correspondant, si Lynis le permet :

sudo lynis show tests

et rechercher un code :

sudo lynis show tests | grep -i 'FILE-6310'

Les détails complémentaires peuvent également se trouver dans :

/var/log/lynis.log

5. Prioriser l’analyse

Examinez les résultats dans cet ordre :

1. Warnings, surtout ceux liés aux permissions, aux comptes, aux services réseau, au chiffrement et aux mises à jour.
2. Suggestions ayant un impact élevé, notamment celles concernant SSH, le pare-feu, l’authentification et la journalisation.
3. Contexte du serveur : une recommandation peut être pertinente sur un serveur exposé à Internet mais inutile sur une machine isolée.
4. Faux positifs ou choix opérationnels : ne modifiez pas automatiquement la configuration simplement pour augmenter le score.

Pour obtenir les fichiers et lignes concernés, utilisez aussi le journal :

sudo grep -iE 'FILE-6310|NETW-2705' /var/log/lynis.log

6. Comparer deux rapports

Après avoir corrigé certains points, conservez l’ancien rapport puis comparez les résultats :

diff -u ancien-lynis-report.dat /var/log/lynis-report.dat

Pour comparer uniquement le score :

grep '^hardening_index' ancien-lynis-report.dat
grep '^hardening_index' /var/log/lynis-report.dat

En pratique, le rapport lisible affiché par lynis audit system et le fichier lynis.log donnent souvent davantage de contexte que lynis-report.dat, qui sert surtout de fichier de résultats structuré.

quelle conclusion pour cette analyse

sudo grep -E '^(hardening_index|warning|suggestion|osdistro|osname|os_version)' \
  /var/log/lynis-report.dat

os_version=13
suggestion[]=DEB-0280|Install libpam-tmpdir to set $TMP and $TMPDIR for PAM sessions|-|-|
suggestion[]=DEB-0810|Install apt-listbugs to display a list of critical bugs prior to each APT installation.|-|-|
suggestion[]=DEB-0831|Install needrestart, alternatively to debian-goodies, so that you can run needrestart after upgrades to determine which daemons are using old versions of libraries and need restarting.|-|-|
suggestion[]=DEB-0880|Install fail2ban to automatically ban hosts that commit multiple authentication errors.|-|-|
suggestion[]=BOOT-5122|Set a password on GRUB boot loader to prevent altering boot configuration (e.g. boot in single user mode without password)|-|-|
suggestion[]=BOOT-5180|Determine runlevel and services at startup|-|-|
suggestion[]=BOOT-5264|Consider hardening system services|Run '/usr/bin/systemd-analyze security SERVICE' for each service|-|
suggestion[]=PROC-3612|Check the output of ps for dead or zombie processes|-|-|
suggestion[]=AUTH-9230|Configure password hashing rounds in /etc/login.defs|-|-|
suggestion[]=AUTH-9262|Install a PAM module for password strength testing like pam_cracklib or pam_passwdqc or libpam-passwdqc|-|-|
suggestion[]=AUTH-9282|When possible set expire dates for all password protected accounts|-|-|
suggestion[]=AUTH-9284|Look at the locked accounts and consider removing them|-|-|
suggestion[]=AUTH-9286|Configure minimum password age in /etc/login.defs|-|-|
suggestion[]=AUTH-9286|Configure maximum password age in /etc/login.defs|-|-|
suggestion[]=AUTH-9328|Default umask in /etc/login.defs could not be found and defaults usually to 022, which could be more strict like 027|-|-|
suggestion[]=FILE-6310|To decrease the impact of a full /home file system, place /home on a separate partition|-|-|
suggestion[]=FILE-6310|To decrease the impact of a full /var file system, place /var on a separate partition|-|-|
suggestion[]=USB-1000|Disable drivers like USB storage when not used, to prevent unauthorized storage or data theft|-|-|
suggestion[]=STRG-1846|Disable drivers like firewire storage when not used, to prevent unauthorized storage or data theft|-|-|
suggestion[]=NAME-4028|Check DNS configuration for the dns domain name|-|-|
suggestion[]=PKGS-7346|Purge old/removed packages (4 found) with aptitude purge or dpkg --purge command. This will cleanup old configuration files, cron jobs and startup scripts.|-|-|
suggestion[]=PKGS-7370|Install debsums utility for the verification of packages with known good database.|-|-|
warning[]=PKGS-7392|Found one or more vulnerable packages.|-|-|
suggestion[]=PKGS-7392|Update your system with apt-get update, apt-get upgrade, apt-get dist-upgrade and/or unattended-upgrades|-|-|
suggestion[]=PKGS-7394|Install package apt-show-versions for patch management purposes|-|-|
suggestion[]=PKGS-7410|Remove any unneeded kernel packages|6 kernels|text:validate dpkg -l output and perform cleanup with apt autoremove|
suggestion[]=PKGS-7420|Consider using a tool to automatically apply upgrades|-|-|
suggestion[]=NETW-3200|Determine if protocol 'dccp' is really needed on this system|-|-|
suggestion[]=NETW-3200|Determine if protocol 'sctp' is really needed on this system|-|-|
suggestion[]=NETW-3200|Determine if protocol 'rds' is really needed on this system|-|-|
suggestion[]=NETW-3200|Determine if protocol 'tipc' is really needed on this system|-|-|
suggestion[]=FIRE-4513|Check iptables rules to see which rules are currently not used|-|-|
suggestion[]=HTTP-6710|Change the HTTPS and SSL settings for enhanced protection of sensitive data and privacy|-|-|
suggestion[]=HTTP-6712|Check your nginx access log for proper functioning|-|-|
suggestion[]=HTTP-6716|Check your nginx error_log statements and disable debug mode|-|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|AllowTcpForwarding (set YES to NO)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|ClientAliveCountMax (set 3 to 2)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|LogLevel (set INFO to VERBOSE)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|MaxAuthTries (set 6 to 3)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|MaxSessions (set 10 to 2)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|TCPKeepAlive (set YES to NO)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|X11Forwarding (set YES to NO)|-|
suggestion[]=SSH-7408|Consider hardening SSH configuration|AllowAgentForwarding (set YES to NO)|-|
suggestion[]=DBS-1884|Configure the 'requirepass' setting for Redis|/etc/redis/redis.conf|text:configure 'requirepass' setting in /etc/redis/redis.conf|
suggestion[]=DBS-1886|Use the 'rename-command CONFIG' setting for Redis|/etc/redis/redis.conf|text:configure 'rename-command CONFIG' in /etc/redis/redis.conf|
suggestion[]=PHP-2376|Change the allow_url_fopen line to: allow_url_fopen = Off, to disable downloads via PHP|-|-|
suggestion[]=LOGG-2154|Enable logging to an external logging host for archiving purposes and additional protection|-|-|
suggestion[]=LOGG-2190|Check what deleted files are still in use and why.|-|-|
suggestion[]=BANN-7126|Add a legal banner to /etc/issue, to warn unauthorized users|-|-|
suggestion[]=BANN-7130|Add legal banner to /etc/issue.net, to warn unauthorized users|-|-|
suggestion[]=ACCT-9622|Enable process accounting|-|-|
suggestion[]=ACCT-9626|Enable sysstat to collect accounting (no results)|-|-|
suggestion[]=ACCT-9628|Enable auditd to collect audit information|-|-|
suggestion[]=FINT-4350|Install a file integrity tool to monitor changes to critical and sensitive files|-|-|
suggestion[]=TOOL-5002|Determine if automation tools are present for system management|-|-|
suggestion[]=FILE-7524|Consider restricting file permissions|See screen output or log file|text:Use chmod to change file permissions|
suggestion[]=HOME-9304|Double check the permissions of home directories as some might be not strict enough.|-|-|
suggestion[]=KRNL-6000|One or more sysctl values differ from the scan profile and could be tweaked||Change sysctl value or disable test (skip-test=KRNL-6000:<sysctl-key>)|
suggestion[]=HRDN-7222|Harden compilers like restricting access to root user only|-|-|
suggestion[]=HRDN-7230|Harden the system by installing at least one malware scanner, to perform periodic file system scans|-|Install a tool like rkhunter, chkrootkit, OSSEC, Wazuh|
hardening_index=66

La conclusion principale est que le serveur Debian 13 présente un

niveau de durcissement moyen, avec un score Lynis de 66/100. La configuration comporte plusieurs mesures de sécurité déjà en place, mais des améliorations importantes restent nécessaires.

Le point le plus critique est :

warning[]=PKGS-7392|Found one or more vulnerable packages

Cela signifie qu’au moins un paquet installé est identifié comme vulnérable. Il faut traiter ce point en priorité, car il peut exposer directement le système ou les services hébergés.

sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt list --upgradable

Après la mise à jour, il est recommandé de redémarrer les services concernés, voire le serveur si le noyau ou des bibliothèques critiques ont été mis à jour :

sudo needrestart

Les autres résultats sont principalement des suggestions de renforcement, et non nécessairement des failles avérées. Les priorités sont les suivantes :

1. Mettre à jour les paquets vulnérables
   • Traiter PKGS-7392.
   • Installer needrestart.
   • Supprimer les anciens noyaux et paquets inutiles après vérification.
   • Supprimer les configurations de paquets désinstallés.
2. Renforcer SSH Lynis recommande notamment :
   • réduire MaxAuthTries de 6 à 3 ;
   • limiter MaxSessions ;
   • désactiver X11Forwarding ;
   • désactiver AllowTcpForwarding et AllowAgentForwarding si inutiles ;
   • ajuster ClientAliveCountMax ;
   • passer LogLevel à VERBOSE.

   Avant toute modification, conserver une session SSH ouverte et tester la nouvelle configuration :

   sudo sshd -t
   sudo systemctl reload ssh
   

3. Sécuriser Redis Les recommandations DBS-1884 et DBS-1886 indiquent que Redis doit être vérifié. Il faut notamment déterminer s’il est accessible uniquement localement ou depuis le réseau. Si Redis est utilisé, son accès doit être protégé par authentification et filtrage réseau. Toute modification doit être validée selon la version de Redis et l’application qui l’utilise.

4. Renforcer l’authentification Lynis recommande :
   • une politique de mots de passe plus robuste ;
   • des durées minimale et maximale des mots de passe ;
   • un umask plus restrictif, par exemple 027 ;
   • l’expiration des comptes inutilisés ;
   • l’installation d’un module de contrôle de complexité ;
   • éventuellement fail2ban contre les tentatives répétées de connexion.

5. Vérifier le réseau et le pare-feu Les protocoles dccp, sctp, rds et tipc doivent être désactivés s’ils ne sont pas nécessaires. Il faut également vérifier les règles inutilisées du pare-feu et confirmer que seuls les ports indispensables sont exposés.

6. Améliorer la supervision et la traçabilité L’installation de auditd, d’un outil d’intégrité des fichiers et l’envoi des journaux vers un serveur externe amélioreraient la détection des modifications et des incidents.

7. Renforcer les services web Pour Nginx et PHP :
   • vérifier la configuration TLS ;
   • surveiller les journaux d’accès et d’erreur ;
   • désactiver le mode debug ;
   • envisager allow_url_fopen = Off si l’application ne l’utilise pas.

Une formulation possible pour un rapport serait :

L’audit Lynis du serveur Debian 13 obtient un score de durcissement de 66/100, ce qui correspond à un niveau de sécurité intermédiaire. Un avertissement critique concerne la présence d’un ou plusieurs paquets vulnérables et doit être traité en priorité par une mise à jour du système. Les principales pistes d’amélioration concernent le durcissement de SSH, la sécurisation de Redis, la politique d’authentification, la configuration du pare-feu, la réduction des services et protocoles inutiles ainsi que l’amélioration de la journalisation et de la surveillance. Les recommandations Lynis doivent toutefois être validées selon le rôle du serveur afin d’éviter de désactiver une fonctionnalité nécessaire. Une nouvelle analyse devra être réalisée après correction des points prioritaires.

Pour affiner la conclusion, il manque surtout le détail du paquet vulnérable et le contexte des services réellement utilisés. Les commandes suivantes permettent de commencer la vérification :

sudo apt list --upgradable
sudo systemctl --type=service --state=running
sudo ss -tulpn
sudo systemctl status redis nginx ssh
sudo lynis audit system

Le score de 66 ne doit donc pas être interprété comme « 66 % de sécurité ». Le résultat le plus important est l’avertissement sur les paquets vulnérables, suivi des configurations SSH, Redis, du pare-feu et des comptes utilisateurs.

---

Plusieurs points: - Les protocoles `dccp`, `sctp`, `rds` et `tipc` ? - Comment désactiver ces protocoles, UFW ? - sudo needrestart , aucun service concerné - NGINX PHP, mode debug et allow_url_fopen = Off ?

1. Protocoles dccp, sctp, rds et tipc

Ce sont des protocoles réseau rarement nécessaires sur un serveur web classique :

• DCCP : transport adapté aux flux avec contraintes de délai, comme certains flux multimédias.
• SCTP : utilisé notamment dans certaines infrastructures télécoms et signalisation réseau.
• RDS : Reliable Datagram Sockets, principalement utilisé dans certains environnements spécialisés, notamment Oracle ou InfiniBand.
• TIPC : communication entre processus ou nœuds d’un cluster.

Lynis recommande de vérifier s’ils sont nécessaires, mais leur présence ne constitue pas automatiquement une vulnérabilité. Sur un serveur Nginx/PHP standard, ils sont généralement inutiles.

Vérifiez d’abord s’ils sont chargés :

lsmod | grep -E '^(dccp|sctp|rds|tipc)'

Vous pouvez également vérifier les sockets associés :

sudo ss -A dccp,sctp

Si aucun service n’en dépend, vous pouvez les désactiver.

Désactivation immédiate

sudo modprobe -r dccp sctp rds tipc

Un module utilisé ne pourra pas être retiré. Dans ce cas, identifiez d’abord le service qui l’utilise.

Désactivation persistante

Créez un fichier de configuration :

sudo nano /etc/modprobe.d/disable-unused-protocols.conf

Ajoutez :

blacklist dccp
blacklist sctp
blacklist rds
blacklist tipc

Pour empêcher également le chargement indirect d’un module :

install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false

Rechargez l’initramfs :

sudo update-initramfs -u

Puis redémarrez si nécessaire et vérifiez :

lsmod | grep -E '^(dccp|sctp|rds|tipc)'

Ne désactivez pas ces protocoles si le serveur utilise une application de cluster, une infrastructure télécoms, Oracle/InfiniBand ou une autre application qui les requiert.

2. Est-ce lié à UFW ?

Non, pas directement.

UFW filtre les connexions réseau, mais ne désactive pas les modules noyau. Vous pouvez bloquer des ports ou des protocoles avec UFW, mais le protocole restera disponible dans le noyau.

Voir les règles actuelles :

sudo ufw status numbered

Voir les ports en écoute :

sudo ss -tulpn

Exemple pour limiter les services exposés :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Attention : avant d’activer UFW à distance, autorisez d’abord SSH avec le bon port. Sinon, vous risquez de perdre l’accès au serveur.

Pour bloquer explicitement certains protocoles IP avec UFW, on peut utiliser des règles avancées, mais ce n’est généralement pas nécessaire si les modules sont désactivés. La méthode modprobe est plus appropriée pour empêcher leur utilisation au niveau du système.

3. sudo needrestart indique qu’aucun service n’est concerné

C’est un résultat positif. Cela signifie généralement qu’aucun service actif n’utilise encore d’anciennes bibliothèques après les mises à jour récentes.

Vous pouvez confirmer avec :

sudo needrestart

Si le résultat indique qu’aucun redémarrage n’est nécessaire, il n’y a pas d’action immédiate à effectuer.

Cela ne signifie toutefois pas que tous les paquets sont à jour. Vérifiez séparément :

sudo apt update
apt list --upgradable

Le redémarrage du serveur peut encore être nécessaire si le noyau a été mis à jour :

test -f /var/run/reboot-required && echo "Redémarrage recommandé"

4. Nginx, PHP et le mode debug

Dans le résultat Lynis :

HTTP-6716|Check your nginx error_log statements and disable debug mode

Lynis vous demande de vérifier que Nginx ne fonctionne pas en mode journalisation trop détaillée ou en mode debug.

Recherchez les paramètres concernés :

sudo grep -RniE 'debug|error_log' /etc/nginx

Une configuration normale peut ressembler à :

error_log /var/log/nginx/error.log warn;

Les niveaux Nginx vont globalement du moins détaillé au plus détaillé :

emerg
alert
crit
error
warn
notice
info
debug

En production, utilisez généralement warn ou error, selon vos besoins :

error_log /var/log/nginx/error.log warn;

Testez toujours la configuration avant de la recharger :

sudo nginx -t
sudo systemctl reload nginx

Il faut également vérifier le mode debug de PHP. Selon l’installation, cherchez :

sudo grep -RniE 'display_errors|display_startup_errors|error_reporting|log_errors|xdebug.mode' \
  /etc/php /etc/nginx

Pour un serveur de production, les principes habituels sont :

display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log

La configuration peut se trouver dans un fichier tel que :

/etc/php/8.2/fpm/php.ini
/etc/php/8.3/fpm/php.ini
/etc/php/8.4/fpm/php.ini

La version exacte dépend de votre installation. Identifiez-la avec :

php -v
systemctl list-units --type=service | grep -E 'php.*fpm'

Après modification :

sudo php-fpm8.2 -t
sudo systemctl reload php8.2-fpm

Adaptez 8.2 à votre version. Si Xdebug est installé en production, vérifiez également :

php -m | grep -i xdebug

et, si nécessaire :

xdebug.mode = off

5. allow_url_fopen = Off

Cette recommandation concerne PHP :

PHP-2376|Change the allow_url_fopen line to:
allow_url_fopen = Off

Lorsque allow_url_fopen est activé, certaines fonctions PHP comme fopen() ou file_get_contents() peuvent ouvrir des URL distantes, par exemple :

file_get_contents("https://example.org/data.json");

Cela peut augmenter le risque de requêtes HTTP inattendues ou contribuer à des attaques SSRF si une application utilise une URL fournie par l’utilisateur sans validation.

Vérifiez la valeur active :

php -i | grep allow_url_fopen

Pour PHP-FPM, vérifiez plutôt la configuration réellement utilisée par FPM :

sudo grep -Rni 'allow_url_fopen' /etc/php

Dans le fichier php.ini de FPM, définissez :

allow_url_fopen = Off

Puis rechargez PHP-FPM :

sudo systemctl reload php8.2-fpm

Adaptez la version.

Attention : désactiver cette option peut casser une application qui télécharge volontairement des ressources distantes avec fopen() ou file_get_contents(). Il faut donc vérifier le code ou les fonctionnalités de l’application avant de l’appliquer.

Une solution préférable dans certaines applications est d’utiliser explicitement cURL, avec :

• une liste d’hôtes autorisés ;
• des délais d’attente ;
• une validation stricte des URL ;
• une interdiction des adresses privées et locales ;
• un filtrage des redirections.

Conclusion pratique

Dans votre cas, l’ordre de traitement raisonnable est :

1. identifier et corriger le ou les paquets vulnérables ;
2. vérifier les services et ports exposés ;
3. durcir SSH ;
4. confirmer que Redis est protégé ou uniquement accessible localement ;
5. désactiver les quatre protocoles uniquement s’ils ne sont pas nécessaires ;
6. vérifier les niveaux de logs Nginx et PHP ;
7. passer allow_url_fopen à Off après validation de l’application ;
8. relancer Lynis pour mesurer l’évolution.

---

Lynis ne devrait pas les citer car je n'ai aucun protrocole `dccp`, `sctp`, `rds` et `tipc` en place, lsmod renvoie rien Oui, c’est normal : Lynis ne dit pas que ces protocoles sont actifs. La recommandation `NETW-3200` signifie simplement qu’il a détecté que les modules noyau correspondants pourraient être disponibles et vous demande de vérifier s’ils sont réellement nécessaires.

Le résultat de :

lsmod | grep -E '^(dccp|sctp|rds|tipc)'

ne renvoie rien, ce qui indique qu’ils ne sont actuellement pas chargés. Vous pouvez confirmer qu’aucun socket de ces types n’est utilisé :

sudo ss -A dccp,sctp

Si cette commande ne renvoie rien non plus, aucune connexion DCCP ou SCTP n’est active. Pour RDS et TIPC, vérifiez également les modules disponibles :

find /lib/modules/$(uname -r) -type f \
  | grep -E '/(dccp|sctp|rds|tipc)(\.ko|\.ko\.)'

Il faut distinguer trois situations :

• Module chargé : le protocole est actuellement disponible dans le noyau.
• Module présent mais non chargé : il peut éventuellement être chargé plus tard.
• Module absent : il n’est pas disponible pour le noyau courant.

Vérifiez aussi si les modules peuvent être chargés manuellement :

for m in dccp sctp rds tipc; do
    if modinfo "$m" >/dev/null 2>&1; then
        echo "$m : module disponible"
    else
        echo "$m : module absent"
    fi
done

Si les modules sont absents ou non chargés et qu’aucune application ne les utilise, il n’y a pas de problème opérationnel à corriger. Vous pouvez simplement documenter la recommandation comme suit :

Les protocoles DCCP, SCTP, RDS et TIPC ne sont pas utilisés sur le serveur. Aucun module correspondant n’est chargé et aucune socket associée n’a été détectée. La recommandation Lynis est donc considérée comme non applicable dans le contexte actuel.

Si modinfo confirme que les modules existent et que vous souhaitez empêcher leur chargement futur, vous pouvez les mettre sur liste noire :

sudo tee /etc/modprobe.d/disable-unused-protocols.conf >/dev/null <<'EOF'
blacklist dccp
blacklist sctp
blacklist rds
blacklist tipc
EOF

Puis :

sudo update-initramfs -u

Les lignes install ... /bin/false sont plus strictes :

install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false

Elles peuvent empêcher explicitement leur chargement, mais ne sont pas nécessaires dans votre cas si les modules ne sont pas chargés et que ces protocoles ne sont pas utilisés. La meilleure conclusion est donc : aucune action requise, mais recommandation à documenter comme non applicable, sauf exigence particulière de votre politique de sécurité.

---

Les modules sont simplement dans la librairie kernel /lib/modules/ Oui, c’est exactement le cas le plus courant. Les fichiers présents dans `/lib/modules/$(uname -r)/` sont seulement des modules disponibles sur le disque pour le noyau courant. Ils ne sont pas actifs tant qu’ils ne sont pas chargés.

Vous pouvez le confirmer avec :

lsmod | grep -E '^(dccp|sctp|rds|tipc)'

Si aucune ligne n’est affichée :

• aucun de ces modules n’est chargé ;
• aucun de ces protocoles n’est actuellement actif par l’intermédiaire de ces modules ;
• Lynis détecte leur disponibilité potentielle, pas leur utilisation réelle.

Vous pouvez vérifier précisément leur présence :

for m in dccp sctp rds tipc; do
    if modinfo "$m" >/dev/null 2>&1; then
        echo "$m : module disponible mais non chargé"
    else
        echo "$m : module absent"
    fi
done

Vérifiez aussi les sockets réseau :

sudo ss -A dccp,sctp

et les modules chargés avec leurs dépendances :

lsmod | grep -E 'dccp|sctp|rds|tipc'

Dans ce contexte, la conclusion d’audit peut être :

Les modules DCCP, SCTP, RDS et TIPC sont présents dans l’arborescence /lib/modules, mais aucun n’est chargé par le noyau. Aucun service ou socket utilisant ces protocoles n’a été détecté. La recommandation Lynis NETW-3200 est donc préventive et peut être considérée comme non applicable, sous réserve qu’aucune application métier ne nécessite ces protocoles.

Si vous devez appliquer une politique de durcissement stricte, vous pouvez empêcher leur chargement futur :

sudo tee /etc/modprobe.d/disable-unused-protocols.conf >/dev/null <<'EOF'
blacklist dccp
blacklist sctp
blacklist rds
blacklist tipc
EOF

sudo update-initramfs -u

Ensuite, contrôlez la configuration :

cat /etc/modprobe.d/disable-unused-protocols.conf

Il n’est généralement pas nécessaire de supprimer physiquement les fichiers .ko dans /lib/modules. Les supprimer peut compliquer les mises à jour du noyau et produire des incohérences dans la base des modules.

Après une nouvelle analyse Lynis, la recommandation peut éventuellement rester affichée : Lynis peut continuer à signaler la présence des modules disponibles, même lorsqu’ils sont blacklistés. Dans ce cas, conservez la vérification et la justification dans le dossier d’audit plutôt que de chercher à faire disparaître artificiellement la suggestion.