Différences

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

Lien vers cette vue comparative

centralisation_logs [2019/06/18 18:42] (Version actuelle)
malethug création d'une page séparée pour la centralisation des logs
Ligne 1: Ligne 1:
 +# Centralisation des logs
  
 +Dans le cadre de la TX Sécurité P19, nous avons mis en place un mécanisme de centralisation des logs produits par le démon d'​audit `auditd`.
 +
 +## Objectif et approche utilisée
 +
 +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.
 +
 +**A terme, l'​authentification TLS devra être activée. Un exemple de mise
 +en place de celle-ci peut être trouvée [ici](https://​www.rsyslog.com/​using-tls-with-relp/​).**
 +
 +## Configuration
 +### Machines clientes
 +#### Dispatcher d'​auditd :
 +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. ​
 +
 +#### rsyslog sur les clients :
 +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.
 +
 +### Serveur de centralisation
 +
 +On configure enfin `monitoring` pour qu'il gère correctement les journaux lui
 +étant envoyés.
 +#### rsyslog sur le serveur :
 +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
 +}
 +```
 +
 +#### logrotate sur le serveur :
 +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.
 +Nous avons ajouté cette portion directement dans le fichier `logrotate.conf` car
 +c'est la méthode indiquée comme privilégiée dans la documentation de cet outil.
 +
 +## Extension à d'​autres service
 +Grâce à son approche modulaire, il est relativement facile d'​utiliser `rsyslog`
 +pour centraliser des logs produits par une grande diversité de services. Des
 +recherches avaient été réalisées en ce sens dans le passé à Picasoft, dont les
 +comptes rendus se trouvent [ici](monitoring:​service_rsyslog).
 +
 +Il semble que les personnes travaillant sur ce sujet avaient fait face à des
 +difficultés pour discriminer les logs en fonction du conteneur docker les ayant
 +produit. Il serait intéressant de reprendre leurs recherche pour avoir à
 +disposition une solution de centralisation globale.
  • centralisation_logs.txt
  • Dernière modification: 2019/06/18 18:42
  • par malethug