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.

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.

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