Bannière
visitor@aschnoebelen.fr:~/2023/11/13/configurer-rsyslog-avec-tls$ login_

Configurer Rsyslog avec TLS

  Le 13 novembre 2023     Aurélien Schnoebelen     #debian#rsyslog  

Rsyslog est un logiciel libre permettant de transférer des logs sur le réseau. Dans cet article nous verrons comment le mettre en place, et comment le sécuriser avec TLS.

Pour notre démonstration, nous utiliserons deux machines Debian connectées sur un même réseau local. L’une d’elle, que je nommerai « rsyslog-server » jouera le rôle de serveur avec comme adresse IP 192.168.1.100 tandis que l’autre, que je nommerai « rsyslog-client« , jouera le rôle de client avec comme adresse IP 192.168.1.101.

Je ne le rappelle pas à chaque étape, mais il faudra être en Root (ou utiliser sudo) pour pouvoir lancer les commandes.

1. Installation

Sur le serveur comme sur le client, installez le logiciel rsyslog, puis activez le pour qu’il démarre automatiquement (normalement cette seconde étape n’est pas nécessaire) :

apt install rsyslog
systemctl enable rsyslog.service

2. Configuration basique

2.1. Sur le serveur

Éditez le fichier /etc/rsyslog.conf avec votre éditeur de fichier préféré (nano, vim…), et décommenter les deux lignes suivantes (en supprimant le #) :

module(load="imtcp")
input(type="imtcp" port="514")

Si vous souhaitez plutôt utiliser UDP, ce qui est moins demandeur en ressources système, vous pouvez décommenter les lignes suivantes à la place :

module(load="imudp")
input(type="imudp" port="514")

Mais dans la suite de cet article, nous allons configurer TLS pour sécuriser les échanges avec notre rsyslog-server ; je priviligierai donc la première solution (en TCP).

Une fois ces modifications effectuées, vous pouvez quitter le fichier et relancer rsyslog :

systemctl restart rsyslog.service

Vous pouvez vérifier que le serveur rsyslog est bien à l’écoute avec la commande netstat -npltu (que vous pouvez installer avec apt install net-tools) :

aurelien@rsyslog-server:~$ netstat -npltu
*Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      711/rsyslogd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      427/sshd: /usr/sbin
tcp6       0      0 :::514                  :::*                    LISTEN      711/rsyslogd
tcp6       0      0 :::22                   :::*                    LISTEN      427/sshd: /usr/sbin

2.2. Sur le client

Éditez le fichier /etc/rsyslog.conf avec votre éditeur de fichier préféré (nano, vim…), puis ajoutez la ligne suivante à la fin :

*.*   @@192.168.1.100:514

Si vous avez préféré choisir d’utiliser UDP à l’étape précédente, il faut mettre un seul @ au lieu de deux :

*.*   @192.168.1.100:514

Avec :

  • *.* : au format service.sévérité, signifie que l’on veut tous les messages.
  • Services :
    • auth : Evénements de sécurité ou d’authentification (comme SSH par exemple)
    • authpriv : Evénements relatifs aux contrôles d’accès
    • cron : Evénements relatifs aux tâches planifiées
    • daemon : Evénements des processus systèmes et applicatifs
    • kern : Evénements concernant les messages relatifs au noyau
    • mail : Evénements relatifs aux services mail
    • local7 : Evénements relatifs au boot
    • user : Evenements quand aucun service n’est spécifié
    • none : Rien
    • * : Tout
  • Sévérité :
    • emerg : Emergency, le système est inutilisable.
    • alert : Une action doit être prisé immédiatement
    • crit : Conditions critiques
    • err : Erreur
    • warning : Attention
    • notice : Fonctionnement normal mais info suffisemment importante pour être notifiée
    • info : Message informatif
    • debug : messages de débug
  • 192.168.1.100 : l’adresse du serveur ; cela peut être son adresse ip ou son nom de domaine

Redémarrez ensuite le service rsyslog :

systemctl restart rsyslog.service

2.3. Contrôler le bon fonctionnement

Sur le serveur, logs seront enregistrés par défaut dans /var/log/syslog. Pour contrôler le bon fonctionnement de notre installation, sur rsyslog-server tapez la commande tail -f /var/log/syslog. Puis sur rsyslog-client tapez systemctl restart sshd.service. Vous devriez voir apparaître, sur rsyslog-server, les lignes suivantes :

2023-11-13T10:19:20+01:00 rsyslog-client systemd[1]: Stopping ssh.service - OpenBSD Secure Shell server...
2023-11-13T10:19:20+01:00 rsyslog-client systemd[1]: ssh.service: Deactivated successfully.
2023-11-13T10:19:20+01:00 rsyslog-client systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
2023-11-13T10:19:20+01:00 rsyslog-client systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
2023-11-13T10:19:20+01:00 rsyslog-client systemd[1]: Started ssh.service - OpenBSD Secure Shell server.

Votre serveur Rsyslog est fonctionnel, à vous de sélectionner les logs à centraliser.

Dans les parties suivantes nous verrons comment sécuriser les échanges avec le serveur grâce à TLS, puis nous verrons également comment peaufiner la gestion des logs à envoyer.

3. Sécuriser Rsyslog avec TLS

3.1. Installation

Pour pouvoir sécuriser notre installation Rsyslog, il est nécessaire d’installer au préalable quelques outils car nous utiliserons gnutls. Tapez la commande suivante, toujours en Root, sur le serveur et sur le client :

apt install -y rsyslog-gnutls gnutls-bin gnutls-doc

3.2. Génération des clés sécurisées

Rsyslog peut utiliser le protocole TLS pour authentifier le client et le serveur et pour chiffrer leurs échanges. Le principe de fonctionnement est le suivant : chaque machine possède une paire de clés privée/publique qui lui est propre, et un certificat signé par une autorité de certification (CA) commune. Dans notre exemple cette CA sera générée par notre serveur.

3.2.1. Sur le serveur

3.2.1.1. Génération du certificat de l’Autorité de Certification (CA)

Tapez la commande suivante pour générer la clé privée de l’autorité de certification :

certtool --generate-privkey --outfile ca-key.pem --sec-param High

Cette clé sera utilisée par l’autorité de certification pour signer les certificats que nous générerons pour le serveur et pour le client.

Il faut ensuite générer un certificat associé à la clé privée que nous avons généré.

certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem

Le programme vous demande un certain nombre de choses, voici les réponses à apporter (Vous pouvez adapter en fonction de vos besoins. J’ai laissé des réponses vides pour accepter le choix par défaut) :

root@rsyslog-server:/etc/ssl/certs/rsyslog# certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Country name (2 chars): FR
State or province name:
Locality name:
Organization name:
Organizational unit name:
Common name: rsyslog-server
UID:
Enter the subject's domain component (DC):
This field should not be used in new certificates.
E-mail:
Enter the certificate's serial number in decimal (123) or hex (0xabcd)
(default is 0x76558c13c093e0b80f76d6345ec78884ff396762)
value:


Activation/Expiration time.
The certificate will expire in (days): 3650


Extensions.
Does the certificate belong to an authority? (y/N): y
Path length constraint (decimal, -1 for no constraint):
Is this a TLS web client certificate? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N):
Enter a dnsName of the subject of the certificate: rsyslog-server
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Will the certificate be used for signing (required for TLS)? (Y/n):
Will the certificate be used for data encryption? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for email protection? (y/N):
Will the certificate be used to sign other certificates? (Y/n): y
Will the certificate be used to sign CRLs? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        [...]

Is the above information ok? (y/N): y


Signing certificate...

Note : en production, le Common Name doit avoir pour valeur le nom complet de la machine (FQDN).

Le certificat d’autorité est généré.

3.2.1.2. Génération du certificat

Tapez la commande suivante pour générer la clé privée :

certtool --generate-privkey --outfile rsyslog-server-key.pem --sec-param High

Générez ensuite la demande de signature de certificat qui permettra ensuite de générer le certificat associé à cette clé :

certtool --generate-request --load-privkey rsyslog-server-key.pem --outfile rsyslog-server-certificat-request.pem

Comme précédemment, voici le retour complet de la commande avec les réponses à apporter et à adapter :

root@rsyslog-server:/etc/ssl/certs/rsyslog# certtool --generate-request --load-privkey rsyslog-server-key.pem --outfile rsyslog-server-certificat-request.pem
Generating a PKCS #10 certificate request...
Country name (2 chars): FR
State or province name:
Locality name:
Organization name:
Organizational unit name:
Common name: rsyslog-server
UID:
Enter the subject's domain component (DC):
Enter a dnsName of the subject of the certificate: rsyslog-server
Enter an additional dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE ciphersuites)? (Y/n):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for email protection? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Is this a TLS web client certificate? (y/N): y
Is this a TLS web server certificate? (y/N): y

Vous pouvez désormais générer le certificat du serveur rsyslog grâce à sa clé privée, et à la demande de signature générée précédemment. Nous utiliserons dans cette commande 3 fichiers : le certificat de la CA (ca.pem), la clé privée de la CA (ca-key.pem) et la demande de signature du certificat (rsyslog-server-certificat-request.pem).

certtool --generate-certificate --load-request rsyslog-server-certificat-request.pem --outfile rsyslog-server-certificat.pem  --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem

Comme précédemment, voici le retour complet de la commande avec les réponses à apporter :

root@rsyslog-server:/etc/ssl/certs/rsyslog# certtool --generate-certificate --load-request rsyslog-server-certificat-request.pem --outfile rsyslog-server-certificat.pem  --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (123) or hex (0xabcd)
(default is 0x7ef932c610d91c272068571cecdf2d04601a8b6e)
value:


Activation/Expiration time.
The certificate will expire in (days): 365


Extensions.
Do you want to honour all the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: rsyslog-server
Enter an additional dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Will the certificate be used for signing (DHE ciphersuites)? (Y/n):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Will the certificate be used for data encryption? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for email protection? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        [...]

Is the above information ok? (y/N): y


Signing certificate...

3.2.2. Sur le client

Les étapes sont sensiblement identiques, avec quelques échanges de fichiers. En effet, il faudra envoyer la demande de signature du certificat sur le serveur pour générer le certificat signé, et renvoyé ce certificat avec le certificat de la CA sur le client. Je vais donc reprendre ici les étapes pas à pas pour générer ces fichiers.

Générez la clé privée du client :

certtool --generate-privkey --outfile rsyslog-client-key.pem --sec-param High

Générez ensuite la demande de signature de certificat qui permettra ensuite de générer le certificat associé à cette clé :

certtool --generate-request --load-privkey rsyslog-client-key.pem --outfile rsyslog-client-certificat-request.pem

Comme précédemment, voici le retour complet de la commande avec les réponses à apporter et à adapter :

root@rsyslog-client:/etc/ssl/certs/rsyslog# certtool --generate-request --load-privkey rsyslog-client-key.pem --outfile rsyslog-client-certificat-request.pem
Generating a PKCS #10 certificate request...
Country name (2 chars): FR
State or province name:
Locality name:
Organization name:
Organizational unit name:
Common name: rsyslog-client
UID:
Enter the subject's domain component (DC):
Enter a dnsName of the subject of the certificate: rsyslog-client
Enter an additional dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE ciphersuites)? (Y/n):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for email protection? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Is this a TLS web client certificate? (y/N): y
Is this a TLS web server certificate? (y/N): y

Pour générer le certificat du client signé par la CA, il faut envoyer le fichier rsyslog-client-certificat-request.pem sur le serveur. Dans cet exemple je travaille dans le répertoire /etc/ssl/certs/rsyslog.

scp ./rsyslog-client-certificat-request.pem root@192.168.1.100:/etc/ssl/certs/rsyslog/

Sur le serveur, vous pouvez maintenant générer le certificat du client, signé par la CA.

certtool --generate-certificate --load-request rsyslog-client-certificat-request.pem --outfile rsyslog-client-certificat.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem

Comme précédemment, voici le retour complet de la commande avec les réponses à apporter :

root@rsyslog-server:/etc/ssl/certs/rsyslog# certtool --generate-certificate --load-request rsyslog-client-certificat-request.pem --outfile rsyslog-client-certificat.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (123) or hex (0xabcd)
(default is 0x37b30ce6afe6a90f84dcf20d11114a78dbcd674e)
value:


Activation/Expiration time.
The certificate will expire in (days): 365


Extensions.
Do you want to honour all the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: rsyslog-client
Enter an additional dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate:
Will the certificate be used for signing (DHE ciphersuites)? (Y/n):
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n):
Will the certificate be used for data encryption? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for email protection? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        [...]

Is the above information ok? (y/N): y


Signing certificate...

Enfin, toujours sur le serveur, tapez les commandes suivantes pour renvoyer le certificat du client et le certificat de la CA sur le client :

scp ./rsyslog-client-certificat.pem root@192.168.1.101:/etc/ssl/certs/rsyslog/
scp ./ca.pem root@192.168.1.101:/etc/ssl/certs/rsyslog/

Vous avez désormais tous les fichiers nécessaires pour configurer TLS sur Rsyslog, ce que nous verrons dans la partie suivante.

3.2.3. Récapitulatif :

3.2.3.1. Les étapes
  1. Générer la clé privée de la CA, puis son certificat.
  2. Générer la clé privée.
  3. Générer la demande de signature du certificat associée à la clé privée générée précédemment.
  4. Générer le certificat correspondant à la demande de signature du certificat, à la clé privée de la CA et au certificat de la CA
  5. Pour le client, répéter les étapes 2 à 4 en adaptant au client.
3.2.3.2. Les fichiers obtenus

Sur le serveur :

  • ca-key.pem : clé privée de la CA
  • ca.pem : certificat de la CA
  • rsyslog-server-key.pem : Clé privée du serveur
  • rsyslog-server-certificat-request.pem : Demande de signature de certificat (pour la CA) du serveur
  • rsyslog-server-certificat.pem : le certificat signé par la CA du serveur

Sur le client :

  • ca.pem : Certificat de la CA
  • rsyslog-client-key.pem : Clée privée du client
  • rsyslog-client-certificat-request.pem : Demande de signature de certificat (pour la CA) du client
  • rsyslog-client-certificat.pem : le certificat signé par la CA du client

3.3. Configurer TLS

3.3.1. Sur le serveur

Éditez le fichier /etc/rsyslog.conf avec votre éditeur de fichier préféré (nano, vim…). Comme je l’ai indiqué au début, j’ai paramétré mon serveur pour être en écoute sur le port TCP pour pouvoir utiliser TLS. Si vous avez choisi UDP je vous invite à revoir le début de cet article. Modifiez l’entrée module(load="imtcp") comme suit :

module(
    load="imtcp"
    StreamDriver.Name="gtls"
    StreamDriver.Mode="1"
    StreamDriver.Authmode="x509/name"
  PermittedPeer="192.168.1.101"
)

Notez que PermittedPeer permet d’autoriser une liste de client à se connecter sur le serveur, identifiés par leur adresse ip ou par leur nom. Il prend soit un identifiant unique comme ici, soit un array d’identifiants pour autoriser plusieurs clients. Exemple : PermittedPeer=["192.168.1.101","192.168.1.102","anon.ym"]

Modifiez ensuite l’entrée input(type="imtcp" port="514") comme suit pour écouter sur le port 6514 au lieu du 514 :

input(type="imtcp" port="6514")

Enfin, sous :

############################
##### GLOBAL DIRECTIVES ####
############################

Rajoutez :

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/ssl/certs/rsyslog/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/ssl/certs/rsyslog/rsyslog-server-certificat.pem"
    DefaultNetstreamDriverKeyFile="/etc/ssl/certs/rsyslog/rsyslog-server-key.pem"
)

Adaptez les chemins à ce que vous avez obtenu en générant les clés et les certificats dans les parties précédentes.

Enfin, redémarrez le service rsyslog :

systemctl restart rsyslog.service

3.3.2. Sur le client

Éditez le fichier /etc/rsyslog.conf avec votre éditeur de fichier préféré (nano, vim…). Sous :

############################
##### GLOBAL DIRECTIVES ####
############################

Rajoutez :

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/ssl/certs/rsyslog/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/ssl/certs/rsyslog/rsyslog-client-certificat.pem"
    DefaultNetstreamDriverKeyFile="/etc/ssl/certs/rsyslog/rsyslog-client-key.pem"
)

Adaptez les chemins à ce que vous avez obtenu en générant les clés et les certificats dans les parties précédentes.

Si vous avez ajouté des règles, il faudra remplacer la destination (par exemple la partie en @@192.168.1.100) par :

action(
    type="omfwd"
    protocol="tcp"
    target="192.168.1.100"
    port="6514"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="192.168.1.100"
)

Notez que StreamDriverPermittedPeers permet d’autoriser la connexion au(x) pairs listés (cf la configuration du serveur avec l’équivalent PermittedPeer).

Par exemple, avec *.* @@192.168.1.100:514 que nous avions configuré précédemment, cela donne :

*.*   action(
    type="omfwd"
    protocol="tcp"
    target="192.168.1.100"
    port="6514"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="192.168.1.100"
)

Enfin, redémarrez le service rsyslog :

systemctl restart rsyslog.service

Pour contrôler le bon fonctionnement, vous pouvez effectuer de nouveau les actions réalisées précédemment dans Configuration basique -> Contrôler le bon fonctionnement

Vous pouvez également lancer la commande suivante pour écouter ce qu’il se passe entre les deux postes (si tcpdump n’est pas installé : apt install tcpdump) :

tcpdump -i <nom-de-la-carte-réseau> tcp port 6514 -X -s 0 -nn

3.4. Notes concernant le mode d’authentification

Dans les configurations du serveur et du client nous avons configuré AuthMode="x509/local". Voici la liste des modes d’authentications supportées par Rsyslog :

  • anon : mode anonyme, il n’y a pas besoin d’authentifier les pairs. C’est le mode le moins sécurisé, utile pour une tester rapidement. Notez que, selon la doc officielle (je n’ai pas testé), il n’y aurait pas besoin de certificats dans ce mode de fonctionnement.
  • x509/fingerprint : les pairs sont authentifiés par une empreinte à renseigner dans StreamDriverPermittedPeers et PermittedPeer.
  • x509/certvalid : les pairs ne sont authentifiés que par leurs certificats
  • x509/name : les pairs sont authentifiés et par leurs certificats, et par leur nom à renseigner dans StreamDriverPermittedPeers et PermittedPeer (ce que nous avons choisi).

4. Peaufinage de la configuration

4.1. Enregistrer les logs dans un répertoire dédié par host

Editez le fichier /etc/rsyslog.conf et rajoutez après :

################
##### RULES ####
################

Les valeurs :

$template syslog,"/var/log/clients/%fromhost%/syslog.log"
*.* ?syslog

Ainsi les données de <host> seront sauvegardées dans /var/log/clients/<host>/syslog.log

4.2. Récupérer les logs d’un fichier

Editez le fichier /etc/rsyslog.conf. Avant :

############################
##### GLOBAL DIRECTIVES ####
############################

Rajoutez les lignes suivantes :

module(load="imfile")
input(type="imfile" file="<fichier-log-à-ajouter>" tag="<tag-du-fichier>" severity="<sévérité>")

Le tag est un nom arbitraire que vous pouvez choisir pour repérer le log dans le fichier.

5. Ressources

  • https://www.rsyslog.com/doc/v8-stable/genindex.html : Documentation de rsyslog
  • https://www.rsyslog.com/doc/master/tutorials/tls.html : La doc officielle pour la sécurisation avec TLS
  • https://www.linuxtricks.fr/wiki/rsyslog-centralisation-des-logs-sous-linux & https://www.linuxtricks.fr/wiki/syslog-les-journaux-systeme-sous-linux : Linuxtricks, attention cependant au niveau de la configuration car la dernière version de rsyslog n’utilise plus ce format (marqué comme déprécié sur le site officiel).
  • https://connect.ed-diamond.com/Linux-Pratique/lphs-047/basez-votre-supervision-sur-des-logs-de-qualite-avec-rsyslog : Surtout pour la création des clés. Cependant même remarque que pour linuxtricks vis à vis de rsyslog.conf.