Configuration de l'interconnexion Syslog

Lisez ce qui suit pour découvrir comment configurer l'interconnexion Syslog sur l'application LockSelf.

Seul le compte Administrateur peut effectuer cette action.

_______________________________________________________________________________________

Interconnexions:

_______________________________________________________________________________________

Interconnexion RSyslog

Pour toutes questions, merci de vous reporter à la FAQ .

Pré-requis pour l'interconnexion Syslog

Afin de pouvoir réaliser l'interconnexion Syslog, vous devrez préparer les pré-requis suivants : 

  • L'IP du serveur RSyslog
  • Le port du serveur RSyslog
  • Les certificats afin d'activer la TLS entre LockSelf et votre serveur RSyslog
    • Le certificat au format CRT
    • La clé privée relative au certificat
    • La chaine de certification ( certificats intermédiaire + CA Root )

Le mode d'authentification se fera via certificat et fingerprint. Il faudra également nous communiquer le fingerprint du serveur.

Si vous êtes en Cloud Privé, merci de transmettre ces éléments à votre interlocuteur pour les formations ou alors via le support.

Configurer le serveur RSyslog

Package relp pour Rsyslog

L'installation du package se fait comme suit en fonction de votre distribution et de votre gestionnaire de package:

# CentOS & RockyLinux : https://centos.pkgs.org/7/centos-x86_64/rsyslog-relp-8.24.0-55.el7.x86_64.rpm.html
c[_] > sudo yum install rsyslog-relp

# Ubuntu : https://packages.ubuntu.com/bionic/admin/rsyslog-relp
c[_] > sudo apt-get install rsyslog-relp

# Debian : https://packages.debian.org/stretch/rsyslog-relp
c[_] > sudo apt install rsyslog-relp

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-relp
c[_] > sudo apk add rsyslog-relp

Fichier de configuration du serveur:

La configuration qui suit est à adapter en fonction de l'organisation de votre configuration du serveur RSyslog. Nous conseillons toutefois d'ajouter cette configuration dans un nouveau fichier du dossier:

/etc/rsyslog.d/ en le nommant par exemple 1-lockself.conf.

# Load the RELP input module
module(load="imrelp" ruleset="<RULESET_NAME>")

# RELP input module configuration
input(type="imrelp" port="<PORT>"
tls="on"
tls.caCert="<INTERMEDIATE_AND_CA_CHAIN_PATH>"
tls.myCert="<CERTIFICATE_PATH>"
tls.myPrivKey="<PRIVATE_KEY_PATH>"
tls.authMode="<AUTH_MODE>"
tls.permittedpeer=["<PEER_IDENTIFICATOR_1>", "<PEER_IDENTIFICATOR_2>", ...]
)

# Ruleset exemple (output logs get from the RELP input module to '/var/log/relp_log' file)
ruleset (name="<RULESET_NAME>") { action(type="omfile" file="/var/log/relp_log") }
  • <RULESET_NAME> : Le nom de la 'ruleset' qui interprétera ce qui est reçu du module d'input RELP. Vous avez la possibilité d'exploiter autrement ce retour.
  • <PORT> : Le port sur lequel écoutera le module d'input RELP.
  • <INTERMEDIATE_AND_CA_CHAIN_PATH> : Le chemin vers le fichier contenant les certificats intermédiaires et le CA root.
  • <CERTIFICATE_PATH> : Le chemin vers le fichier contenant le certificat.
  • <PRIVATE_KEY_PATH> : Le chemin vers le fichier contenant la clé privée.
  • <AUTH_MODE> : Le mode d'authentification, peut être fingerprint ou name (documentation RSyslog)
  • <PEER_IDENTIFICATOR> : La valeur du champs du certificat qui sera utilisé pour autorisé les connexions si elle est valide, en fonction de votre <AUTH_MODE>
    • tls.authMode="fingerprint" : Le fingerprint SHA1 du certificat, sous la forme: "SHA1:<FINGERPRINT>" .
      Vous pouvez l'obtenir de la manière suivante avec Openssl:
      c[_] > openssl x509 -noout -fingerprint -sha1 -inform pem -in <certificate-file.crt>
    • tls.authMode="name" : Le DNS du serveur RSyslog, sous la forme: "mon.dns.com" ou "*.dns.com". Le DNS doit faire parti de DNS sécurisé par le certificats en tant que DNS principal ou dans les AltNames.

Vérifier que la syntaxe de la configuration est bonne

Pour vous assurer que la configuration RSyslog est bonne vous pouvez utiliser la commande suivante:

c[_] > rsyslogd -N1

# OR

c[_] > rsyslogd -c <path/to/configuration/file>

Appliquer la nouvelle configuration

Pour appliquer la nouvelle configuration vous pouvez soit relancer le service:

# CentOS & RockyLinux :
c[_] > sudo systemctl restart rsyslog.service

# Ubuntu : https://packages.ubuntu.com/bionic/admin/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Debian : https://packages.debian.org/stretch/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-relp
c[_] > sudo rc-service rsyslog restart

# OR
c[_] > sudo /etc/init.d/rsyslog restart

Troubleshooting

Dans le cas où la configuration ne semble pas être active, nous vous invitons à regarder les logs du service RSylog:

c[_] > journalctl -u rsyslog.service

Ou de lancer manuellement le serveur avec du debug pour avoir l'ensemble des logs:

c[_] > export RSYSLOG_DEBUG=debug; rsyslogd -d 

# OR

c[_] export RSYSLOG_DEBUG=debug; rsyslogd -d | grep <PORT>

Vérifier également les ports utilisés avec nstat et les règles de votre firewall avec ufw par exemple.

Organisation des logs

Par date, jour, heure ou autre

À la réception des logs sur le serveur RSyslog, vous voudrez peut-être organiser les logs par mois, jours, heures ou autres. Avec RSyslog vous avez la possibilité de rendre le nom du fichier de log dynamique grâce à des templates. 

# Templates
template (name="<TEMPLATE_NAME>" type="string" string="<TEMPLATED_DESTINATION_FILE_NAME>")

# Load the RELP input module
module(load="imrelp" ruleset="<RULESET_NAME>")

# RELP input module configuration
input(type="imrelp" port="<PORT>"
tls="on"
tls.caCert="<INTERMEDIATE_AND_CA_CHAIN_PATH>"
tls.myCert="<CERTIFICATE_PATH>"
tls.myPrivKey="<PRIVATE_KEY_PATH>"
tls.authMode="<AUTH_MODE>"
tls.permittedpeer=["<PEER_IDENTIFICATOR_1>", "<PEER_IDENTIFICATOR_2>", ...]
)

# Ruleset exemple (output logs get from the RELP input module to '<TEMPLATED_DESTINATION_FILE_NAME>' file)
ruleset (name="<RULESET_NAME>") { action(type="omfile" dynaFile="<TEMPLATE_NAME>") }
  • <TEMPLATE_NAME> : nom de la template, il sera appelé par la suite par notre module d'output.
  • <TEMPLATED_DESTINATION_FILE_NAME> : une string construit à partir de caractères et de timereported. Vous pouvez retrouver l'ensemble des variables extractable de timereported ici (de date-unixtimestamp à date-tzoffsdirection, ici timestamp est un alias de timereported). Par exemple <TEMPLATED_DESTINATION_FILE_NAME> peut être :
    /var/log/lockself/%timereported:::date-year%-%timereported:::date-month%-%timereported:::date-day%.log

    qui génèrera par exemple: /var/log/lockself/2023-04-06.log

Configurer un client RSyslog (On-Premises seulement)

Fichier de log LockSelf

Rajouter un point de montage dans le conteneur lockself-api-3

Peu importe la méthode de lancement choisie (docker run, docker compose, docker swarm), vous devrez rajouter le point de montage suivant : 

- <LOG_PATH_ON_HOST>:/usr/local/var/log/lockself/application.log

Le fichier "<LOG_PATH_ON_HOST>" peut être placé à n'importe quel endroit sur le host. Vous devrez donc modifier "<LOG_PATH_ON_HOST>" par le chemin d'accès choisit sur le host.

Activer l'interconnexion

Dans le fichier "env", vous devrez rajouter le paramètre : 

logInFile=1

Une fois ces deux étapes faites, relancer le conteneur lockself-api-3

Installer le package RELP pour Rsyslog

L'installation du package se fait comme suit en fonction de votre distribution et de votre gestionnaire de package:

# CentOS & RockyLinux : https://centos.pkgs.org/7/centos-x86_64/rsyslog-relp-8.24.0-55.el7.x86_64.rpm.html
c[_] > sudo yum install rsyslog-relp

# Ubuntu : https://packages.ubuntu.com/bionic/admin/rsyslog-relp
c[_] > sudo apt-get install rsyslog-relp

# Debian : https://packages.debian.org/stretch/rsyslog-relp
c[_] > sudo apt install rsyslog-relp

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-relp
c[_] > sudo apk add rsyslog-relp

Fichier de configuration du client RSyslog

La configuration qui suit est à adapter en fonction de l'organisation de votre configuration du client RSyslog. Nous conseillons toutefois d'ajouter cette configuration dans un nouveau fichier du dossier:

/etc/rsyslog.d/ en le nommant par exemple 1-lockself.conf.

# Load the file input module
module(load="imfile")

# Load the RELP output module
module(load="omrelp")

# Ruleset to output logs to RSyslog server
ruleset(name="lockselfSendLogsToServer") {
action(type="omrelp" target="<TARGET_IP>" port="<TARGET_PORT>"
tls="on"
tls.caCert="<INTERMEDIATE_AND_CA_CHAIN_PATH>"
tls.myCert="<CERTIFICATE_PATH>"
tls.myPrivKey="<PRIVATE_KEY_PATH>"
tls.authMode="<AUTH_MODE>"
tls.permittedpeer=["<PEER_IDENTIFICATOR_1>", "<PEER_IDENTIFICATOR_2>", ...] )
}

input(type="imfile"
File="<LOG_PATH_ON_HOST>"
Tag="lockself/application.log"
Ruleset="lockselfSendLogsToServer")
  • <TARGET_IP> : l'IP du serveur RSyslog.
  • <TARGET_PORT> : le port du serveur RSyslog
  • <INTERMEDIATE_AND_CA_CHAIN_PATH> : le chemin vers le fichier contenant les certificats intermédiaire et le CA root.
  • <CERTIFICATE_PATH> : le chemin vers le fichier contenant le certificat.
  • <PRIVATE_KEY_PATH> : le chemin vers le fichier contenant la clé privée.
  • <AUTH_MODE> : Le mode d'authentification, peut être fingerprint ou name (documentation rsyslog)
  • <PEER_IDENTIFICATOR> : La valeur du champs du certificat, qui sera utilisé pour autoriser les connexions, si elle est valide, en fonction de votre <AUTH_MODE>
    • tls.authMode="fingerprint" : Le fingerprint SHA1 du certificat, sous la forme: "SHA1:<FINGERPRINT>" .
      Vous pouvez l'obtenir de la manière suivante avec Openssl:
      c[_] > openssl x509 -noout -fingerprint -sha1 -inform pem -in <certificate-file.crt>
    • tls.authMode="name" : Le DNS du serveur rsyslog, sous la forme: "mon.dns.com" ou "*.dns.com". Le DNS doit faire parti de DNS sécurisé par le certificat en tant que DNS principal ou dans les AltNames.

Vérifier que la syntaxe de la configuration est bonne

Pour vous assurer que la configuration RSyslog est bonne, vous pouvez utiliser la commande suivante:

c[_] > rsyslogd -N1

# OR

c[_] > rsyslogd -c <path/to/configuration/file>

Appliquer la nouvelle configuration

Pour appliquer la nouvelle configuration vous pouvez soit relancer le service:

# CentOS & RockyLinux :
c[_] > sudo systemctl restart rsyslog.service

# Ubuntu : https://packages.ubuntu.com/bionic/admin/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Debian : https://packages.debian.org/stretch/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-relp
c[_] > sudo rc-service rsyslog restart

# OR
c[_] > sudo /etc/init.d/rsyslog restart

Troubleshooting

Dans le cas où la configuration ne semble pas être active, nous vous invitons à regarder les logs du service RSyslog:

c[_] > journalctl -u rsyslog.service

Ou de lancer manuellement le serveur avec du debug pour avoir l'ensemble des logs:

c[_] > rsyslogd -dn

FAQ:

Pourquoi avoir besoin de transmettre à LockSelf la paire de clés TLS ?

L'utilisation de la clé privée côté client RSyslog dans une configuration TLS peut être source de confusion, car typiquement, c'est le serveur qui présente un certificat (et sa clé privée associée) pour prouver son identité. Ici, avec un serveur configuré pour exploiter le protocol RELP et de la TLS, le client doit également présenter un certificat pour s'authentifier auprès du serveur pour exploiter l'authentification mutuelle (ou authentification bilatérale).

_______________________________________________________________________________________

 

Interconnexion Graylog

Pré-requis pour l'interconnexion Graylog

Afin de pouvoir réaliser l'interconnexion avec Graylog, vous devrez préparer les pré-requis suivants : 

  • L'IP du Graylog
  • Le port du Graylog
  • Les certificats afin d'activer l'authentification par TLS entre LockSelf et Graylog: 
    • Le certificat au format CRT / PEM
    • La clé privée relative au certificat
    • La chaine de certification ( certificat intermédiaire + CA Root )

Si vous êtes en Cloud Privé, merci de transmettre ces éléments à votre interlocuteur pour les formations ou alors via le support.

Créer l'Input dans Graylog

L'input permet de configurer Graylog pour recevoir les logs envoyés par le Client Syslog.

Pour créer l'input Graylog, rendez-vous sur le panneau d'accès puis dans System Inputs

Screenshot 2023-11-03 at 13.39.41.png

Cliquez sur le champs Select Input , puis choisissez entre Syslog TCP ensuite cliquez sur Launch new input . Le protocol est utilisé ici car il permet une authentification mutuelle entre Graylog et le client Syslog.

Screenshot 2023-11-03 at 14.02.06.png

Dans la popup de configuration:

Screenshot 2023-11-03 at 14.07.11.png

  • Global / Node : Libre à vous de choisir et de définir la node Graylog sur laquelle sera l'input ou alors de le mettre au global.
  • Title : Le nom de l'Input (Exemple: LockSelf).
  • Bind address : L'adresse sur laquelle l'input attendra la réception des logs.
  • Port : Le port sur lequel le client Syslog enverra les logs.
  • TLS cert file : Le chemin sur le host du Graylog vers le certificat TLS.
  • TLS private key file : Le chemin sur le host du Graylog vers la clé correspondante au certificat.
  • Enable TLS : À cocher.
  • TLS key password : Le mot de passe de la clé (si nécessaire).
  • TLS client authentication : Sélectionner `required`.
  • TLS Client Auth Trusted Certs : Le chemin vers un ensemble: certificat intermédiaire et CA.

Une fois l'ensemble des champs remplis comme vous le souhaitez, cliquez sur Launch Input.

Screenshot 2023-11-03 at 15.05.26.png

Dans le cas où l'Input affiche 0 Running, cliquer sur Start input pour lancer l'input.

Screenshot 2023-11-03 at 15.13.33.png

L'Input Graylog est prêt à recevoir des logs provenant d'un client Syslog (en TCP).

Configurer un client RSyslog (On-Premises seulement)

Fichier de log LockSelf

Rajouter un point de montage dans le conteneur lockself-api-3

Selon la méthode de déploiement choisie (docker run, docker compose, docker swarm), vous devrez rajouter le point de montage suivant : 

- <LOG_PATH_ON_HOST>:/usr/local/var/log/lockself/application.log

Le fichier "<LOG_PATH_ON_HOST>" peut être placé à n'importe quel endroit sur le host. Vous devrez donc modifier "<LOG_PATH_ON_HOST>" par le chemin d'accès choisit sur le host.

Activer l'interconnexion

Dans le fichier "env", vous devrez rajouter le paramètre : 

logInFile=1

Une fois ces deux étapes faites, relancer le conteneur lockself-api-3

Installer le package GNUTLS pour Rsyslog

L'installation du package se fait comme suit en fonction de votre distribution et de votre gestionnaire de package:

# CentOS & RockyLinux : https://centos.pkgs.org/7/centos-x86_64/rsyslog-gnutls-8.24.0-55.el7.x86_64.rpm.html
c[_] > sudo yum install rsyslog-gnutls

# Ubuntu : https://packages.ubuntu.com/focal/rsyslog-gnutls
c[_] > sudo apt-get install rsyslog-gnutls

# Debian : https://packages.debian.org/buster/rsyslog-gnutls
c[_] > sudo apt install rsyslog-gnutls

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-tls
c[_] > sudo apk add rsyslog-tls

La configuration qui suit est à adapter en fonction de l'organisation de votre configuration du client RSyslog. Nous conseillons toutefois d'ajouter cette configuration dans un nouveau fichier du dossier:

/etc/rsyslog.d/ en le nommant par exemple 1-lockself.conf.

# Load the file input module 
module(load="imfile")

# Define TLS informations for gnutls
global(
DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="<INTERMEDIATE_AND_CA_CHAIN_PATH>"
DefaultNetstreamDriverCertFile="<CERTIFICATE_PATH>"
DefaultNetstreamDriverKeyFile="<PRIVATE_KEY_PATH>"
)

ruleset(name="lockselfSendLogsToGraylog") {
action(
type="omfwd"
target="<TARGET_IP>"
port="<TARGET_PORT>"
protocol="tcp"
StreamDriver="gtls"
StreamDriverMode="1"
StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="<TARGET_IP>"
ResendLastMSGOnReconnect="on" # https://www.rsyslog.com/doc/v8-stable/configuration/modules/omfwd.html#resendlastmsgonreconnect
queue.filename="fwdRule1" # To understand queue configuration: https://www.rsyslog.com/doc/master/concepts/queues.html
queue.type="LinkedList"
queue.maxDiskSpace="256m"
queue.saveOnShutdown="on"
action.resumeRetryCount="-1"
action.resumeInterval="30"
)
}

input(type="imfile"
File="<LOG_PATH_ON_HOST>"
Tag="lockself/application.log"
Ruleset="lockselfSendLogsToGraylog")
  • <TARGET_IP> : l'IP du Graylog.
  • <TARGET_PORT> : le port du Graylog.
  • <INTERMEDIATE_AND_CA_CHAIN_PATH> : le chemin vers le fichier contenant les certificats intermédiaires et le CA root. (Le même fichier que TLS Client Auth Trusted Certs)
  • <CERTIFICATE_PATH> : le chemin vers le fichier contenant le certificat. (Le même fichier que TLS cert file)
  • <PRIVATE_KEY_PATH> : le chemin vers le fichier contenant la clé privée. (Le même fichier que TLS private key file)

Vérifier que la syntaxe de la configuration est bonne

Pour vous assurer que la configuration RSyslog est bonne, vous pouvez utiliser la commande suivante:

c[_] > rsyslogd -N1

# OR

c[_] > rsyslogd -c <path/to/configuration/file>

Appliquer la nouvelle configuration

Pour appliquer la nouvelle configuration vous pouvez soit relancer le service:

# CentOS & RockyLinux :
c[_] > sudo systemctl restart rsyslog.service

# Ubuntu : https://packages.ubuntu.com/bionic/admin/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Debian : https://packages.debian.org/stretch/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-relp
c[_] > sudo rc-service rsyslog restart

# OR
c[_] > sudo /etc/init.d/rsyslog restart

Troubleshooting

Dans le cas où la configuration ne semble pas être active, nous vous invitons à regarder les logs du service RSyslog:

c[_] > journalctl -u rsyslog.service

Ou de lancer manuellement le serveur avec du debug pour avoir l'ensemble des logs:

c[_] > rsyslogd -dn

_______________________________________________________________________________________

 

Interconnexion Sekoia

Pré-requis pour l'interconnexion Sekoia

Afin de pouvoir réaliser l'interconnexion avec Sekoia, vous devrez préparer les pré-requis présents dans la documentation de Sekoia.

Configurer un client RSyslog (On-Premises seulement)

Fichier de log LockSelf

Rajouter un point de montage dans le conteneur lockself-api-3

Selon la méthode de déploiement choisie (docker run, docker compose, docker swarm), vous devrez rajouter le point de montage suivant : 

- <LOG_PATH_ON_HOST>:/usr/local/var/log/lockself/application.log

Le fichier "<LOG_PATH_ON_HOST>" peut être placé à n'importe quel endroit sur le host. Vous devrez donc modifier "<LOG_PATH_ON_HOST>" par le chemin d'accès choisi sur le host.

Activer l'interconnexion

Dans le fichier "env", vous devrez rajouter le paramètre : 

logInFile=1

Une fois ces deux étapes faites, relancer le conteneur lockself-api-3

Télécharger le CA de Sekoia:

Télécharger le certificat d'autorité (CA) de Sekoia et l'ajouter à l'emplacement choisi (<SEKOIA_CERTIFICATE_PATH> ) sur le serveur (par exemple: /etc/rsyslog.d/Sekoia-io-intake.pem).

Installer le package GNUTLS pour Rsyslog

L'installation du package se fait comme suit en fonction de votre distribution et de votre gestionnaire de package:

# CentOS & RockyLinux : https://centos.pkgs.org/7/centos-x86_64/rsyslog-gnutls-8.24.0-55.el7.x86_64.rpm.html
c[_] > sudo yum install rsyslog-gnutls

# Ubuntu : https://packages.ubuntu.com/focal/rsyslog-gnutls
c[_] > sudo apt-get install rsyslog-gnutls

# Debian : https://packages.debian.org/buster/rsyslog-gnutls
c[_] > sudo apt install rsyslog-gnutls

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-tls
c[_] > sudo apk add rsyslog-tls

La configuration qui suit est à adapter en fonction de l'organisation de votre configuration du client RSyslog. Nous conseillons toutefois d'ajouter cette configuration dans un nouveau fichier du dossier:

/etc/rsyslog.d/ en le nommant par exemple 1-lockself.conf.

# Load the file input module 
module(load="imfile")
module(load="immark" interval="180") # provides --MARK-- message capability

# Define TLS informations for gnutls
$DefaultNetstreamDriverCAFile <SEKOIA_CERTIFICATE_PATH>

template(
name="RFC5424fmt"
type="string"
string="<%pri%>1 %timegenerated:::date-rfc3339% %hostname% %app-name% %procid% LOG [SEKOIA@53288 intake_key=\"<YOUR_INTAKE_KEY>\"] %msg%\\n"
)

ruleset(name="sendToLogServer") {
action(
type="omfwd"
protocol="tcp"
target="intake.sekoia.io"
port="10514"
TCP_Framing="octet-counted"
StreamDriver="gtls"
StreamDriverMode="1"
StreamDriverAuthMode="x509/name"
StreamDriverPermittedPeers="intake.sekoia.io"
Template="RFC5424fmt"
)
}

input(
type="imfile"
File="<LOG_PATH_ON_HOST>"
Tag="lockself/application.log"
Ruleset="sendToLogserver"
)

Vérifier que la syntaxe de la configuration est bonne

Pour vous assurer que la configuration RSyslog est bonne, vous pouvez utiliser la commande suivante:

c[_] > rsyslogd -N1

# OR

c[_] > rsyslogd -c <path/to/configuration/file>

Appliquer la nouvelle configuration

Pour appliquer la nouvelle configuration vous pouvez soit relancer le service:

# CentOS & RockyLinux :
c[_] > sudo systemctl restart rsyslog.service

# Ubuntu : https://packages.ubuntu.com/bionic/admin/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Debian : https://packages.debian.org/stretch/rsyslog-relp
c[_] > sudo systemctl restart rsyslog.service

# Alpine : https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog-relp
c[_] > sudo rc-service rsyslog restart

# OR
c[_] > sudo /etc/init.d/rsyslog restart

Troubleshooting

Dans le cas où la configuration ne semble pas être active, nous vous invitons à regarder les logs du service RSyslog:

c[_] > journalctl -u rsyslog.service

Ou de lancer manuellement le serveur avec du debug pour avoir l'ensemble des logs:

c[_] > rsyslogd -dn

Mise à jour