Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

auditd [2019/06/13 19:41]
cbarrete créée
auditd [2019/06/18 18:44] (Version actuelle)
malethug Déplacement de la centralisation vers une page séparée
Ligne 143: Ligne 143:
  
 - `dispatcher = /​sbin/​audispd` : on souhaite que la centralisation des logs soit - `dispatcher = /​sbin/​audispd` : on souhaite que la centralisation des logs soit
-  faite par le plugin `rsyslog` d'​`audispd`+  faite par le plugin `syslog` d'​`audispd`
 - `action_mail_acct = root` : les mails envoyés par auditd sont par défaut à - `action_mail_acct = root` : les mails envoyés par auditd sont par défaut à
   destination de `root`. On pourra plus tard mettre en place une centralisation   destination de `root`. On pourra plus tard mettre en place une centralisation
Ligne 161: Ligne 161:
 `audit=1` comme paramètre au noyau afin de pouvoir auditer les processus `audit=1` comme paramètre au noyau afin de pouvoir auditer les processus
 éventuellent lancés avant `auditd` lui-même. éventuellent lancés avant `auditd` lui-même.
- 
  
 ### Centralisation ### Centralisation
- +Les informations relative ​à la centralisation ​des logs peuvent être retrouvées ​[ici](centralisation_logs).
-Il est très important que les journaux soient centralisés car ils seront +
-principalement utilisés pour des analyses post-mortem. Or, on n'a pas de +
-garantie d'​intégrité sur les journaux d'un hôte compromis, donc on souhaite les +
-conserver sur un hôte plus sûr (`monitoring`). +
- +
-auditd permet d'​utiliser Kerberos pour cela, mais cette solution est très +
-lourde, compliquée ​à mettre en place et à maintenir. Nous avons plutôt décidé +
-d'​utiliser `rsyslog` car il est déjà présent sur tous les hôtes et permettra de +
-centraliser d'​autres journaux que ceux produits par auditd. Il s'agit d'​une +
-solution mature et très capable, permettant notamment de discriminer les +
-journaux en fonction de leur hôte d'​origine. +
- +
-La mise en place de ce système se fait en plusieurs étapes : il faut rediriger +
-les journaux d'​auditd vers rsyslog, configurer rsyslog pour qu'il envoie ses +
-journaux sur `monitoring` et configurer `monitoring` pour qu'il gère +
-correctement ces journaux et les tourne de façon appropriée. +
- +
-On commence par appliquer ​la configuration suivante à +
-`/​etc/​audisp/​plugins.d/​syslog.conf` sur chacun ​des clients: +
- +
-``` +
-active = yes +
-direction = out +
-path = builtin_syslog +
-type = builtin +
-args = LOG_INFO +
-format = string +
-``` +
-Cela active le plugin `audisp` passant les journaux d'​auditd à rsyslog sur +
-chaque client. On configure ensuite rsyslog dans `/​etc/​rsyslog.d/​client.conf` +
-pour qu'il envoie ses journaux à `monitoring` : +
- +
- +
-``` +
-###########################################​ +
-# Log centralization client configuration # +
-###########################################​ +
-module(load="​omrelp"​) ​  # provides RELP output for log centralization +
- +
-# Forward auditd and audispd ​logs to a distant host +
-if ($programname == "​auditd"​ or $programname == "​audispd"​) then { +
-    action(type="​omrelp"​ +
-        target="​monitoring.picasoft.net"​ +
-        port="​20514"​ +
-        tls="​on"​ +
-        # For tls authentication +
-    #     ​tls.caCert="/​path/​to/​cert"​ +
-    #     ​tls.myCert="/​path/​to/​cert"​ +
-    #     ​tls.myPrivKey="/​path/​to/​key"​ +
-    #     ​tls.authmode="​name"​ +
-    #     ​tls.permittedpeer=["​monitoring.picasoft.net"​] +
-+
-+
-``` +
- +
-On remarquera que l'​authentification TLS n'a pas encore été mise en place car +
-nous attendions encore les certificats nécessaires. +
- +
-On configure enfin `monitoring` pour qu'il gère correctement les journaux lui +
-étant envoyés. On commence par rajouter la configuration suivante à +
-`/​etc/​rsyslog.d/​server.conf` pour que les journaux entrant soient ségrégés en +
-fonction de l'​hôte dont ils proviennent : +
- +
-``` +
-module(load="​imrelp"​ ruleset="​relp"​  # provides RELP input for log centralization +
-                                       # and bind it to ruleset relp (see below) +
-input(type="​imrelp"​ port="​20514"​ +
-    tls="​on"​  +
-# For tls authentication:​ +
-#     ​tls.caCert="/​path/​to/​cert"​  +
-#     ​tls.myCert="/​path/​to/​cert"​  +
-#     ​tls.myPrivKey="/​path/​to/​key"​ +
-#     ​tls.authMode="​name"​  +
-#     ​tls.permittedpeer=["​pica02.picasoft.net",​ "​pica01.picasoft.net",​ "​pica01-test.picasoft.net"​] +
-)  +
- +
-# Places the right log in the right file +
-ruleset (name="​relp"​) { +
-    if $source == "​pica01-test"​ then { +
-        action(type="​omfile"​ +
-            file="/​var/​log/​pica01-test.log"​)  +
-        stop +
-    } +
-    if $source == "​pica01"​ then { +
-        action(type="​omfile"​ +
-            file="/​var/​log/​pica01.log"​)  +
-        stop +
-    } +
-    if $source == "​pica02"​ then { +
-        action(type="​omfile"​ +
-            file="/​var/​log/​pica02.log"​)  +
-        stop +
-    } +
-    stop +
-+
-``` +
- +
-Puis on rajoute la configuration suivant à `/​etc/​logrotate.conf` pour déterminer +
-le comportement des rotations : +
- +
-``` +
-/​var/​log/​pica01-test.log +
-/​var/​log/​pica01.log +
-/​var/​log/​pica02.log +
-+
-    # keep log files for 30 days +
-    maxage 30 +
-    # Rotate them when they are larger than 10M +
-    size 10M +
-    missingok +
-    notifempty +
-    compress +
-    delaycompress +
-    sharedscripts +
-    postrotate +
-            invoke-rc.d rsyslog rotate > /dev/null +
-    endscript +
-+
-``` +
- +
-Cette configuration supprime les journaux plus vieux qu'un mois, car on suppose +
-qu'un problème nécessitant une enquête sera découvert avant cela. Par ailleurs, +
-ne pas supprimer les journaux lorsqu'​ils occupent une taille trop importante +
-permet d'​éviter qu'un attaquant les supprime en effectuant de nombreux appels à +
-`execve` depuis un shell.+
  
 ## Utilisation ## Utilisation
  • auditd.txt
  • Dernière modification: 2019/06/18 18:44
  • par malethug