Auditd me depasse un peu: need help

Tags: #<Tag:0x00007fc7033d3908>

Bonjour

Pour finaliser la mise ne place de mon PC pro sous Debian (cf Processus de création d'une distribution et aspects de sécurité - #20 par Zargos), j’essaye de configurer auditd.
Mais j’avoue que la multiplicité des possibilités de ce programme me dépasse.

J’ai trouvé un tutoriel qui fournit un script de règles de 800 lignes. Est ce que quelqu’un a le courage de regarder? Configuring AuditD in Linux. Linux AuditD instructions with and… | by Boris Osepov | Medium

Pendant ce temps je regarde Lynis comme conseillé par @Zargos

800 lignes c’est beaucoup.
J’ai 127 lignes de conf et ce’st déjà pas mal.

audit.rules.txt (2,4 Ko)

Dans le fichier joint supprimer l’extension .txt et c’est un fichier tar.gz fait avec tar zcvf. Les règles dedans (plusieurs fichiers) sont ceux recommandés par CIS Workbench Debian 12

Merci @Zargos , ton aide m’est précieuse

1 J'aime

Pourriez-vous nous transmettre le lien exact du fichier de script de règles ? Celui fourni sur la page communiquée dans votre post initial est un lien mort.

@vbreton
C’est https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules
Il manque le s sur l’adresse de la page web

Merci

Non, car à priori ce sont des règles visant à vérifier l’intégrité de certains fichiers essentiels et on a vite fait d’en atteindre plusieurs centaines.

Mais un cerytain nombre sont nulle et non avenue, car searvant éventuellement à pallier à des choses qui n’ont pas été faite.
Un exemple, d’ès le début:

# Package Manager (APT/YUM/DNF)
-w /etc/yum/pluginconf.d/ -p wa -k package_man
-w /etc/apt/apt.conf.d/ -p wa -k package_man
-w /etc/dnf/plugins/dnfcon.conf -p wa -k package_man

On est pas sensé utiliser YUM avec APT. Donc je rajoute bien que la qualité de ces règles laissent à désirer.
Autre exemple à peine plus loin:

-w /usr/local/lib/systemd/ -p wa -k systemd

Inutile car ce n’est pas sensé exister. et il n’y a aucune raison sérieuse pour que ça existe.
Ou encore

-w /usr/sbin/modinfo -p x -k T1547_Boot_or_Logon_Autostart_Execution

A quoi sert-il de surveiller ça alors que de toute façon c’est utilisé massivement par le système?
C’est comme surveiller l’ampoule pour s’assurer que la lumière s’allume.

Certains systèmes ou organismes utilisent encore bien plus de règles et la qualité de ces règles ne laissent pas à désirer car libre à chacun d’utiliser YUM à la place d’Apt. Cela peut être du à des raisons historiques d’un projet par exemple. Ce qui serait plutôt à remettre en question éventuellement, c’est leur faible nombre car on a vite fait d’atteindre quelques centaines de fichier à surveiller sur un serveur traditionnel.

On parle d’un PC. Pas d’un serveur, ou d’"un système central. Un PC n’a qu’un seul outil de packaging.

Plus on, met de règle plus on a de faux positif. Surtout sur la surveillance des fichiers.

Autant utiliser aide dans ce cas.

Un PC peut faire partie d’une infrastructure sécurisée, gérée ou supervisée par un serveur ! Et rien n’empêche d’ajouter en locale un autre outil de packaging ! C’est d’ailleurs fréquemment le cas avec Python.

Absolument faux, car la vérification de l’intégrité des fichiers ce n’est pas la recherche de virus ! Dans ce cas, les faux positifs concernent principalement les fichiers temporaires aussi il convient d’être vigilant sur ce point. De là, à mettre moins de règles c’est une aberration car ça ne va pas dans le sens de la sécurité. Un faux positif devant être analysé et abouti généralement à la modification ou à l’ajout de règles, à la modification de l’application concernée, à la modification de son paramétrage, voir à sa recompilation dans certains cas.

Parfaitement ! Enfin presque car il est trop connu et c’est donc un peu comme conseiller Norton Antivirus sous W$ comme antivirus qui a été victime de son succès , en d’autres termes la cible privilégiée de personnes mal intentionnées. En matière d’intégrité du système, certains outils peu connus sont par définition plus efficaces car moins analysés pour être détournés.

En fait pour résumer, c’est pas qu’il y ait trop de règles, c’est qu’elles n’ont pas été établies avec le recul ou le sérieux nécessaire. Il y en a plus à ajouter qu’à retirer !

Audit et AIDE sont complémentaire. Il n’est pas avisé de vouloir le boulot de l’un avec l’autre.
Audit et Aide sont également connus aujourd’hui.
Aide a pour lui l’avantage de ne pas figurer dans le grub.
Audit a pour lui l’avantage de figurer dans le grub.

Le premier est un contrôle d’intégrité, l’autre un audit.
Pour audit les recommandations seraient:

  • Assurez-vous que les modifications apportées à la portée de l’administration du système (sudoers) sont collectées
  • Assurez-vous que les actions d’un autre utilisateur sont toujours enregistrées
  • Assurez-vous que les événements qui modifient le fichier journal sudo sont collectés
  • Assurez-vous que les événements qui modifient la date et l’heure sont collectés
  • Assurez-vous que les événements qui modifient l’environnement réseau du système sont collectés
  • Assurez-vous que l’utilisation des commandes privilégiées est collectée
  • Assurez-vous que les tentatives d’accès aux fichiers infructueuses sont collectées
  • Assurez-vous que les événements qui modifient les informations des utilisateurs/groupes sont collectés
  • Assurez-vous que les événements de modification des autorisations de contrôle d’accès discrétionnaire sont collectés
  • Assurez-vous que les montages de système de fichiers réussis sont collectés
  • Assurez-vous que les informations d’initiation de session sont collectées
  • Assurez-vous que les événements de connexion et de déconnexion sont collectés
  • Assurez-vous que les événements de suppression par les utilisateurs sont collectés
  • Assurez-vous que les événements qui modifient les contrôles d’accès obligatoires du système sont collectés
  • Assurez-vous que les tentatives réussies et infructueuses d’utiliser la commande chcon sont collectées
  • Assurez-vous que les tentatives réussies et infructueuses d’utiliser la commande setfacl sont collectées
  • Assurez-vous que les tentatives réussies et infructueuses d’utiliser la commande chacl sont collectées
  • Assurez-vous que les tentatives réussies et infructueuses d’utiliser la commande usermod sont collectées
  • Assurez-vous que le déchargement de chargement et la modification du module du noyau sont collectés
  • Assurez-vous que la configuration de l’audit est immuable
  • Assurez-vous que la configuration en cours d’exécution et sur le disque est la même

Pour AIDE les règles par défaut de Debian son déjà bien complètes.

C’est l’inverse ! Audit pour l’audit et help pour le contrôle d’intégrité.

Oui, ce qui expliquerait qu’Audit a des règles ne concernant pas normalement l’état du poste (comme par exemple avec yum). De là à les supprimer, d’un point de vue sécurité ce n’est pas conseillé. J’aurais même tendance à rajouter des règles pour plus de sécurité. Si c’est pour un audit visant à vérifier le minimum requis, ok on peut retirer des règles sinon pour un audit de sécurité, non.

Bonjour

Je progresse avec auditd.

Il fonctionne, j’ai paramétré Anacron pour m’envoyer les logs tous les jours en utilisant les paquets mail et msmtp.

Mais j’ai déja des centaines de lines de log en utilisant les paramètres de @Zargos que je ne comprends qu’à moitié. D’autant qu’auditd compte le temps universel depuis le 1 janvier 1970, donc difficile de convertir en une date que je comprenne rien qu’à la lecture.

Je suis en train de regarder pour faire une rotation archivage des logs pour ne garder en clair que les deux derniers jours.

Est ce qu’on est censé lire ces logs tous les matins?
Je suppose que oui.

Bonne journée

Non en fait. Normalement on met en place du reporting qui fait du tri.
Voir on met en place un SOC/SIEM pour présenter un dashboard résultant de ces logs.
Là où on peut trier, c’est déjà sur tout ce qui est DENIED. Mais là aussi on peut en fait avoir beaucoup de faux positif si on a mal configuré AppArmor par exemple en mettant en ENFORCED quelque chose qui aurait du être en COMPLAIN.
Mais de toutes façon, on a toujours des logs dans les deux cas.

Il faut utiliser aureport pour faire des rapport permettant de synthétiser les logs.

Voici par exemple le rapport des échecs (failed) sur les 4 derniers mois:

~# aureport --failed

Failed Summary Report
======================
Range of time in logs: 09/04/2025 14:15:22.460 - 09/08/2025 18:21:46.895
Selected time for report: 09/04/2025 14:15:22 - 09/08/2025 18:21:46.895
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 4
Number of authentications: 0
Number of failed authentications: 22
Number of users: 2
Number of terminals: 10
Number of host names: 3
Number of executables: 18
Number of commands: 113
Number of files: 4305
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 472
Number of anomaly events: 60
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of integrity events: 5753
Number of virt events: 6
Number of keys: 3
Number of process IDs: 420
Number of events: 6963