# Auditd me depasse un peu: need help

**URL:** <https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396>\
**Category:** Support Debian\
**Tags:** securité\
**Created:** [Août 7, 2025, 7:20 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396 "2025-08-07T19:20:51Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Anonymous23](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@Anonymous23](https://www.debian-fr.org/u/Anonymous23)\
**Post date:** [Août 7, 2025, 7:20 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/1 "2025-08-07T19:20:51Z")

</div>

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](https://www.debian-fr.org/t/processus-de-creation-dune-distribution-et-aspects-de-securite/91335/20)), 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](https://medium.com/@boristheblade1/configuring-auditd-in-linux-6d1f6e100079)

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

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 7, 2025, 9:16 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/2 "2025-08-07T21:16:09Z")

</div>

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

[audit.rules.txt](https://www.debian-fr.org/uploads/short-url/pc1cx3p1XcWcdF20DPJmL7nMk4O.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

---

<div class="post-metadata">

**Author:** ![Anonymous23](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@Anonymous23](https://www.debian-fr.org/u/Anonymous23)\
**Post date:** [Août 8, 2025, 9:21 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/3 "2025-08-08T09:21:42Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\
**Post date:** [Août 8, 2025, 9:58 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/4 "2025-08-08T09:58:33Z")

</div>

> [@Anonymous23](#):
>
> J’ai trouvé un tutoriel qui fournit un script de règles de 800 lignes.

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.

---

<div class="post-metadata">

**Author:** ![Anonymous23](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@Anonymous23](https://www.debian-fr.org/u/Anonymous23)\
**Post date:** [Août 8, 2025, 10:37 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/5 "2025-08-08T10:37:03Z")

</div>

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

Merci

---

<div class="post-metadata">

**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\
**Post date:** [Août 8, 2025, 10:44 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/6 "2025-08-08T10:44:16Z")

</div>

> [@Zargos](#):
>
> 800 lignes c’est beaucoup.

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.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 8, 2025, 12:33 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/7 "2025-08-08T12:33:59Z")

</div>

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:

```auto
# 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:

```auto
-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

```auto
-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.

---

<div class="post-metadata">

**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\
**Post date:** [Août 8, 2025, 5:06 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/8 "2025-08-08T17:06:50Z")

</div>

> [@Zargos](#):
>
> A quoi sert-il de surveiller ça alors que de toute façon c’est utilisé massivement par le système?

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.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 8, 2025, 5:09 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/9 "2025-08-08T17:09:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\
**Post date:** [Août 8, 2025, 6:51 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/10 "2025-08-08T18:51:22Z")

</div>

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.

> [@Zargos](#):
>
> Plus on, met de règle plus on a de faux positif. Surtout sur la surveillance des fichiers.

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.

> [@Zargos](#):
>
> Autant utiliser aide dans ce 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 !

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 8, 2025, 9:29 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/11 "2025-08-08T21:29:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\
**Post date:** [Août 8, 2025, 11:18 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/12 "2025-08-08T23:18:49Z")

</div>

> [@Zargos](#):
>
> Le premier est un contrôle d’intégrité, l’autre un audit.

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

> [@Zargos](#):
>
> Audit et AIDE sont complémentaire.

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.

---

<div class="post-metadata">

**Author:** ![Anonymous23](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@Anonymous23](https://www.debian-fr.org/u/Anonymous23)\
**Post date:** [Août 9, 2025, 2:33 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/13 "2025-08-09T14:33:22Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 9, 2025, 4:20 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/14 "2025-08-09T16:20:46Z")

</div>

> [@Anonymous23](#):
>
> Est ce qu’on est censé lire ces logs tous les matins?  
> Je suppose que oui.

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.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 9, 2025, 4:22 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/15 "2025-08-09T16:22:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Août 9, 2025, 4:24 UTC](https://www.debian-fr.org/t/auditd-me-depasse-un-peu-need-help/91396/16 "2025-08-09T16:24:49Z")

</div>

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

```auto
~# 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

```

En relisant le man de auditctl, j’ai remarqué ce point ci-dessous pour les règles avec -w:

> -w path  
> Place a watch on path. If the path is a file, it’s almost the same as using the -F path option on a syscall rule. If the watch is on a directory, it’s almost  
> the same as using the -F dir option on a syscall rule. The -w form of writing watches is for backwards compatibility and is deprecated due to poor system per‐  
> formance. Convert watches of this form to the syscall based form. The only valid options when using a watch are the -p and -k.

il semble donc que ces règles doiven être évitée pour des raisons de performances et être transformées en appel en règle syscall

Je vais revoir les configurations actuelles pour modifier le cas échéant et je ferais un retour .
