chore: update

This commit is contained in:
Nuxgrid
2026-07-22 20:50:40 +02:00
parent 224fa9c3cb
commit 07883f7e51
2 changed files with 138 additions and 0 deletions
@@ -26,5 +26,38 @@
<location>/var/log/syslog</location> <location>/var/log/syslog</location>
</localfile> </localfile>
<!-- ── Unattended-upgrades (patchs de sécurité auto) ───────────────── -->
<localfile>
<log_format>syslog</log_format>
<location>/var/log/unattended-upgrades/unattended-upgrades.log</location>
</localfile>
<!-- ── auditd (regles CIS 6.2.3.x deployees via ansible/hardening) ─── -->
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
</agent_config> </agent_config>
<!-- ── Logs backend Go (prod-mln) ────────────────────────────────── -->
<!-- "command" (pas full_command) = chaque ligne de docker logs → event séparé -->
<!-- Chaque ligne [GIN] devient son propre event → decoder peut extraire srcip/url/status -->
<agent_config name="prod-mln">
<localfile>
<log_format>command</log_format>
<command>docker logs --since 65s gestion-backend 2>&1</command>
<alias>backend</alias>
<frequency>60</frequency>
</localfile>
</agent_config>
<!-- ── Logs backend Go (pre-prod-mln) ───────────────────────────── -->
<agent_config name="pre-prod-mln">
<localfile>
<log_format>command</log_format>
<command>docker logs --since 65s gestion-backend 2>&1</command>
<alias>backend</alias>
<frequency>60</frequency>
</localfile>
</agent_config>
@@ -0,0 +1,105 @@
<!-- ═══════════════════════════════════════════════════════════════════
Règles d'audit CIS 6.2.3.x — IDs 100900-100930
Regles deployees par ansible/hardening/playbook-audit-rules-*.yml
(surveillance sudo, surveillance omnex, et regles CIS restantes).
Objectif : ne faire remonter dans le dashboard QUE les evenements
qui indiquent un probleme de securite potentiel (level >= 4, seuil
de <log_alert_level> dans ossec.conf). Le reste (chaque commande
sudo, chaque commande omnex, chmod/chown routiniers, montages
Docker, deletions de fichiers, sessions login normales) continue
d'etre capture dans /var/log/audit/audit.log sur chaque host
(consultable via `ausearch -k <cle>`) mais reste sous le seuil
d'alerte generique (level 3, rule 80780+) donc invisible du
dashboard — c'est le comportement voulu, pas un oubli.
Cles VOLONTAIREMENT laissees au niveau generique (pas de regle ici) :
user_emulation, omnex_actions, perm_mod, mounts, session, logins,
delete — activite routiniere d'administration, pas un signal de
securite en soi. Consultable via ausearch si besoin d'investiguer.
-->
<group name="audit,">
<!-- 6.2.3.1 — Modification de /etc/sudoers ou /etc/sudoers.d
Signal fort : quelqu'un modifie qui a le droit d'utiliser sudo. -->
<rule id="100900" level="12">
<if_sid>80700</if_sid>
<field name="audit.key">^scope$</field>
<description>Audit: /etc/sudoers modifie — changement de perimetre administrateur</description>
<group>audit_security,gdpr_IV_35.7.d,</group>
</rule>
<!-- 6.2.3.3 — Modification du fichier de log sudo (technique anti-forensique) -->
<rule id="100901" level="12">
<if_sid>80700</if_sid>
<field name="audit.key">^sudo_log_file$</field>
<description>Audit: /var/log/sudo.log modifie — possible tentative d'effacement de traces</description>
<group>audit_security,gdpr_IV_35.7.d,</group>
</rule>
<!-- 6.2.3.8 — Modification des fichiers d'identite (passwd/shadow/group/pam) -->
<rule id="100902" level="10">
<if_sid>80700</if_sid>
<field name="audit.key">^identity$</field>
<description>Audit: fichier d'identite systeme modifie (passwd/shadow/group/pam)</description>
<group>audit_security,gdpr_IV_35.7.d,</group>
</rule>
<!-- 6.2.3.4 — Changement de date/heure systeme (technique anti-forensique classique) -->
<rule id="100903" level="8">
<if_sid>80700</if_sid>
<field name="audit.key">^time-change$</field>
<description>Audit: horloge systeme modifiee</description>
<group>audit_security,</group>
</rule>
<!-- 6.2.3.5 — Changement d'environnement reseau (hostname, /etc/hosts, netplan...) -->
<rule id="100904" level="8">
<if_sid>80700</if_sid>
<field name="audit.key">^system-locale$</field>
<description>Audit: configuration reseau systeme modifiee (hostname/hosts/netplan)</description>
<group>audit_security,</group>
</rule>
<!-- 6.2.3.14 — Modification de la politique AppArmor (desactivation possible d'un control de securite) -->
<rule id="100905" level="10">
<if_sid>80700</if_sid>
<field name="audit.key">^MAC-policy$</field>
<description>Audit: politique AppArmor modifiee — possible desactivation d'un controle de securite</description>
<group>audit_security,</group>
</rule>
<!-- 6.2.3.15-17 — Usage de chcon/setfacl/chacl (commandes rares, manipulation de contexte/ACL) -->
<rule id="100906" level="8">
<if_sid>80700</if_sid>
<field name="audit.key">^perm_chng$</field>
<description>Audit: commande chcon/setfacl/chacl executee — manipulation de contexte ou d'ACL</description>
<group>audit_security,</group>
</rule>
<!-- 6.2.3.18 — Usage de usermod (modification de compte via commande, possible escalade) -->
<rule id="100907" level="8">
<if_sid>80700</if_sid>
<field name="audit.key">^usermod$</field>
<description>Audit: commande usermod executee — modification de compte utilisateur</description>
<group>audit_security,</group>
</rule>
<!-- 6.2.3.19 — Chargement/dechargement de module noyau (technique rootkit classique) -->
<rule id="100908" level="12">
<if_sid>80700</if_sid>
<field name="audit.key">^kernel_modules$</field>
<description>Audit: module noyau charge/decharge — signal potentiel de rootkit</description>
<group>audit_security,</group>
</rule>
<!-- 6.2.3.7 — Tentative d'acces fichier refusee (EACCES/EPERM) : quelqu'un a essaye et echoue -->
<rule id="100909" level="6">
<if_sid>80700</if_sid>
<field name="audit.key">^access$</field>
<description>Audit: tentative d'acces fichier refusee (permissions insuffisantes)</description>
<group>audit_security,</group>
</rule>
</group>