One place for hosting & domains

      Debian

      Cómo centralizar los registros con Journald en Debian 10


      El autor seleccionó Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas, así como sobre cómo se utilizan porque, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para sistemas Linux es almacenar sus registros localmente en el mismo sistema donde se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema, ya que aumenta el número de sistemas. La solución para administrar todos estos registros es crear un servidor de registro centralizado donde cada host Linux envíe sus registros en tiempo real a un servidor de administración de registros específico.

      Una solución de registro centralizada ofrece varias ventajas en comparación con el almacenamiento de registros en cada host:

      • Reduce la cantidad de espacio de disco necesaria en cada host para almacenar archivos de registro.
      • Los registros pueden mantenerse más tiempo, ya que el servidor de registro específico puede configurarse con más capacidad de almacenamiento.
      • Pueden realizarse análisis de registro avanzados que requieren registros de varios sistemas y también más recursos informáticos de los que pueden estar disponible en los hosts.
      • Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que quizás no acceden directamente por razones de seguridad.

      En esta guía, configurará un componente de la serie de herramientas systemd para transmitir mensajes de registro desde los sistemas de cliente a un servidor de recopilación de registros centralizado. Configurará el servidor y el cliente para que utilicen certificados TLS para cifrar los mensajes de registro, ya que se transmiten a través de redes inseguras como Internet y también para autenticarse.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      • Dos servidores Debian 10.
      • Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Debian 10 para obtener instrucciones sobre cómo hacerlo. También debería configurar el firewall UFW en ambos servidores como se explica en la guía.
      • Dos nombres de host que apuntan a sus servidores. Un nombre de host para el sistema cliente que genera los registros y otro para el servidor de compilación de registros. Descubra cómo apuntar nombres de host a DigitalOcean Droplets consultando la documentación sobre dominios y DNS.

      Esta guía utilizará los dos nombres de host siguientes:

      • client.your_domain: el sistema de cliente que genera los registros.
      • server.your_domain: el servidor de compilación de registro.

      Inicie sesión tanto en el cliente como en el servidor en terminales independientes a través de SSH como en el usuario sudo no root para empezar este tutorial.

      Nota: a lo largo de la tutorial, se etiquetan los bloques de comandos con el nombre de servidor (cliente o servidor) en el que debería ejecutarse el comando.

      Paso 1: Instalar systemd-journal-remote

      En este paso, instalará el paquete systemd-journal-remote en el cliente y en el servidor. Este paquete contiene los componentes que utilizan el cliente y el servidor para transmitir los mensajes de registro.

      Primero, tanto en el cliente como en el servidor, ejecute una actualización de sistema para garantizar que la base de datos de paquetes y el sistema estén actualizados:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      A continuación, instale el paquete systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      En el servidor, habilite e inicie los dos componentes systemd que necesita para recibir mensajes de registro con el siguiente comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      La opción --now en el primer comando inicia los servicios de inmediato. No lo utilizó en el segundo comando, ya que este servicio no se iniciará hasta que tenga certificados TLS, lo que creará en el siguiente paso.

      En el cliente, habilite el componente que systemd utiliza para enviar los mensajes de registro al servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      A continuación, en el servidor, abra los puertos 19532 y 80 en el firewall UFW. Esto permitirá al servidor recibir los mensajes de registro del cliente. El puerto 80 es el puerto que certbot utilizará para generar el certificado TLS. Los siguientes comandos abrirán estos puertos:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      En el cliente, solo deberá abrir el puerto 80 con este comando:

      Client

      Ahora ha instalado los componentes necesarios y ha completado la configuración del sistema base en el cliente y en el servidor. Antes de que pueda configurar estos componentes para que empiecen a retransmitir los mensajes de registro, registrará los certificados TLS Let’s Encrypt para el cliente y el servidor usando la utilidad certbot.

      Paso 2: Instalar certificados de registro y Certbot

      Let’s Encrypt es una Autoridad de certificados que emite certificados TLS gratuitos. Estos certificados permiten a los ordenadores cifrar los datos que envían entre ellos y también verificar la identidad de cada uno. Estos certificados le permiten proteger su navegación en Internet con HTTPS. Cualquier otra aplicación que quiera el mismo nivel de seguridad, puede usar los mismos certificados. El proceso de registro del certificado es el mismo sin importar para lo que los use.

      En este paso, instalará la utilidad certbot y la usará para registrar los certificados. También automáticamente se ocupará de renovar los certificados cuando expiren. El proceso de registro aquí es el mismo en el cliente y en el servidor. Solo deberá cambiar el nombre de host para que coincida con el host donde está ejecutando el comando de registro.

      Primero, instale certbot y la utilidad curl en ambos hosts:

      Client and Server

      • sudo apt install certbot curl

      Ahora que ha instalado certbot, ejecute el siguiente comando para registrar los certificados en el cliente y en el servidor:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Las opciones de este comando significan lo siguiente:

      • certonly: registra el certificado y no se realizan otros cambios en el sistema.
      • --standalone: se utilizar el servidor web integrado de certbot para verificar la solicitud de certificado.
      • --agree-tos: se aceptan de forma automática los Términos de uso de Let’s Encrypt.
      • --email your-email: esta es la dirección de correo electrónico que Let’s Encrypt usará para notificarle sobre la expiración del certificado y otra información importante.
      • -d your_domain: el nombre de host para el que se registrará el certificado. Esto debe coincidir con el sistema donde lo ejecuta.

      Cuando ejecute este comando, se le preguntará si quiere compartir la dirección de correo electrónico con Let’s Encrypt para que puedan enviarle por correo electrónico noticias y otra información sobre su trabajo. Hacerlo es opcional; si no comparte su dirección de correo electrónico, el registro de certificados se completará de forma normal.

      Cuando se complete el proceso de registro de certificado, colocará el certificado y los archivos de clave en /etc/letsencrypt/live/your_domain/ donde your_domain es el nombre de host para el que registró el certificado.

      Por último, deberá descargar una copia de los certificados CA Let’s Encrypt y de nivel intermedio y ponerlos en el mismo archivo. journald usará este archivo para verificar la autenticidad de los certificados en el cliente y en el servidor cuando se comuniquen unos con otros.

      El siguiente comando descargará los dos certificados desde el sitio web Let’s Encrypt y los pondrá en un solo archivo llamado letsencrypt-combined-certs.pem en el directorio de inicio de su usuario.

      Ejecute este comando en el cliente y en el servidor para descargar los certificados y crear un archivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      A continuación, mueva este archivo al directorio Let’s Encrypt que contiene los certificados y las claves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Ahora ha registrado los certificados y las claves. En el siguiente paso, configurará el servidor de compilación de registro para que empiece a escuchar y almacenar los mensajes de registro del cliente.

      Paso 3: Configuración del servidor

      En este paso, configurará el servidor para que utilice el certificado y los archivos de clave que generó en el último paso, de forma que pueda comenzar a aceptar los mensajes de registro del cliente.

      systemd-journal-remote es el componente que escucha los mensajes de registro. Abra su archivo de configuración en /etc/systemd/journal-remote.conf con un editor de texto para empezar a configurarlo en el servidor:

      • sudo nano /etc/systemd/journal-remote.conf

      A continuación, elimine todas las líneas de la sección [remoto] y establezca las rutas para que apunten a los archivos TLS que acaba de crear:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Aquí están las opciones que ha utilizado:

      • Seal=false: firma los datos de registro en el diario. Habilítelo si necesita una máxima seguridad; de lo contrario, puede dejarlo como false.
      • SplitMode=host: los registros de los clientes remotos se dividen host en /var/log/journal/remote. Si prefiere que se añadan todos los registros a un solo archivo configúrelo a SplitMode=false.
      • ServerKeyFile: el archivo de clave privada del servidor.
      • ServerCertificateFile: el archivo de certificado del servidor.
      • TrustedCertificateFile: el archivo que contiene los certificados Let’s Encrypt CA.

      Ahora, deberá cambiar los permisos en los directorios Let’s Encrypt que contienen los certificados y la clave para que systemd-journal-remote los pueda leer y usar.

      Primero, cambie los permisos para que el certificado y la clave privada se puedan leer:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      A continuación, cambie la propiedad de grupo de la clave privada al grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ahora puede iniciar systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Ahora se está ejecutando su servidor de compilación de registro y está listo para comenzar a aceptar mensajes de registro de un cliente. En el siguiente paso, configurará el cliente para que envíe los registros a su servidor de compilación.

      Paso 4: Configurar el cliente

      En este paso, configurará el componente que transmite los mensajes de registro al servidor de compilación de registro. Este componente se llama systemd-journal-upload.

      La configuración predeterminada para systemd-journal-upload es la que utiliza un usuario temporal que solo existe mientras se está ejecutando. Esto permite que systemd-journal-upload lea los certificados TLS y las claves más complicadas. Para resolverlo, creará un nuevo usuario de sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

      Primero, cree el nuevo usuario llamado systemd-journal-upload en el cliente con el siguiente comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Estas opciones al comando son:

      • --system: crea el nuevo usuario como un usuario de sistema. Esto le da al usuario un número UID (Identificador de usuario) inferior a 1000. Normalmente, los UID superiores a 1000 se dan a las cuentas de usuario con las que un humano iniciará sesión.
      • --home /run/systemd: establece /run/systemd como el directorio de inicio de este usuario.
      • --no-create-home: no crea el conjunto de directorio de inicio, puesto que ya existe.
      • --disabled-login: el usuario no puede iniciar sesión en el servidor a través de SSH, por ejemplo.
      • --group: crea un grupo con el mismo nombre que el usuario.

      A continuación, establezca los permisos y la propiedad de los archivos de certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Ahora, edite la configuración para systemd-journal-upload, que está en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este archivo de forma que tenga el siguiente aspecto:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Por último, reinicie el servicio systemd-journal-upload para que utilice la nueva configuración:

      • sudo systemctl restart systemd-journal-upload.service

      Ahora su cliente está configurado y ejecutado, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que los registros se están enviando de forma correcta.

      Paso 5: Probar el cliente y el servidor

      En este paso, probará que el cliente está enviando mensajes de registro al servidor y que el servidor los almacena correctamente.

      El servidor de compilación de registro almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reinició el cliente e al final del último paso, comenzó a enviar mensajes de registro, de forma que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo se llamará como el nombre de host que utilizó para el certificado TLS.

      Utilice el comando ls para comprobar que el archivo de registro del cliente está presente en el servidor:

      Server

      • sudo ls -la /var/log/journal/remote/

      Esto imprimirá el contenido del directorio que muestra el archivo de registro:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      A continuación, escriba un mensaje de registro en el cliente para comprobar que el servidor está recibiendo los mensajes del cliente como se espera. Usará la utilidad logger para crear un mensaje de registro personalizado en el cliente. Si todo está funcionando, systemd-journal-upload transmitirá este mensaje al servidor.

      En el cliente ejecute el siguiente comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      El -p syslog.debug en este comando establece la instalación y la gravedad del mensaje. Configurar esto a syslog.debug aclarará que es un mensaje de prueba. Este comando grabará el mensaje ### TEST MESSAGE from client.your_domain ### al diario del cliente, que systemd-journal-upload transmitirá al servidor.

      A continuación, lea el archivo de diario del cliente en el servidor para comprobar que los mensajes de registro están llegando desde el cliente. Este archivo es un archivo de registro binario de forma que no podrá leerlo con herramientas como less. En su lugar, lea el archivo usando journalctl con la opción --file= que le permite especificar un archivo de diario personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      El mensaje de registro aparecerá como se muestra:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ahora su servidor de centralización de registro está recopilando correctamente los registros de su sistema de cliente.

      Conclusión

      En este artículo, configuró un servidor de compilación central de registro y configuró un cliente para que transmitiera una copia de sus registros de sistema al servidor. Puede configurar tantos clientes como necesite para transmitir los mensajes al servidor de compilación de registro usando los pasos de configuración del cliente que utilizó aquí.



      Source link

      Comment centraliser les journaux avec Journald sur Debian 10


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Les journaux système sont un élément extrêmement important de la gestion des systèmes Linux. Ils fournissent un aperçu inestimable du fonctionnement des systèmes et de leur utilisation car, en plus des erreurs, ils enregistrent des informations opérationnelles telles que les événements de sécurité. La configuration standard des systèmes Linux consiste à stocker leurs journaux localement sur le même système que celui où ils ont été créés. Cela fonctionne pour les systèmes autonomes, mais devient rapidement un problème lorsque le nombre de systèmes augmente. La solution pour gérer tous ces journaux est de créer un serveur de journalisation centralisé où chaque hôte Linux envoie ses journaux, en temps réel, à un serveur de gestion de journaux dédié.

      Une solution de journalisation centralisée offre plusieurs avantages par rapport au stockage des journaux sur chaque hôte :

      • Cela réduit la quantité d’espace disque nécessaire sur chaque hôte pour stocker les fichiers journaux.
      • Les journaux peuvent être conservés plus longtemps, car le serveur de journaux dédié peut être configuré avec une plus grande capacité de stockage.
      • Il est possible d’effectuer une analyse avancée des journaux qui nécessite des journaux provenant de plusieurs systèmes et également plus de ressources de calcul que celles qui peuvent être disponibles sur les hôtes.
      • Les administrateurs de systèmes peuvent accéder aux journaux de tous leurs systèmes auxquels ils ne peuvent pas se connecter directement pour des raisons de sécurité.

      Dans ce guide, vous allez configurer un composant de la suite d’outils systemd pour relayer les messages de journal des systèmes clients vers un serveur de collecte de journaux centralisé. Vous allez configurer le serveur et le client pour qu’ils utilisent des certificats TLS afin de crypter les messages du journal lorsqu’ils sont transmis sur des réseaux non sécurisés tels qu’Internet, et également pour qu’ils s’authentifient mutuellement.

      Conditions préalables

      Avant de commencer ce guide, vous aurez besoin des éléments suivants :

      • Deux serveurs Debian 10.
      • Un utilisateur non root avec des privilèges sudo sur les deux serveurs.  Suivez le guide Configuration initiale du serveur avec Debian 10 pour savoir comment procéder. Vous devez également configurer le pare-feu UFW sur les deux serveurs comme expliqué dans le guide.
      • Deux noms d’hôtes qui pointent vers vos serveurs. Un nom d’hôte pour le système client qui génère les journaux et un autre pour le serveur de collecte des journaux. Apprenez comment faire pointer les noms d’hôtes vers DigitalOcean Droplets en consultant la documentation Domaines et DNS.

      Ce guide utilisera les deux exemples de noms d’hôtes suivants :

      • client.your_domain : Le système client qui génère les journaux.
      • server.your_domain : Le serveur de collecte des journaux.

      Connectez-vous au client et au serveur dans des terminaux séparés via SSH en tant qu’utilisateur non root sudo pour commencer ce tutoriel.

      Note : tout au long du tutoriel, les blocs de commande sont étiquetés avec le nom du serveur (client ou serveur) sur lequel la commande doit être exécutée.

      Étape 1 — Installation de systemd-journal-remote

      Au cours de cette étape, vous installerez le paquet systemd-journal-remote sur le client et le serveur. Ce paquet contient les composants que le client et le serveur utilisent pour relayer les messages du journal.

      Tout d’abord, sur le client et le serveur, lancez une mise à jour du système pour vous assurer que la base de données de paquets et le système sont à jour :

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      Ensuite, installez le paquet systemd-journal-remote :

      Client and Server

      • sudo apt install systemd-journal-remote

      Sur le serveur, activez et lancez les deux composants systemd dont il a besoin pour recevoir les messages de journal avec la commande suivante :

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      L’option --now de la première commande permet de démarrer les services immédiatement. Vous ne l’avez pas utilisé dans la deuxième commande, car ce service ne démarrera pas tant qu’il ne disposera pas de certificats TLS, que vous créerez à l’étape suivante.

      Sur le client, activez le composant que systemd utilise pour envoyer les messages de journal au serveur :

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Ensuite, sur le serveur, ouvrez les ports 19532 et 80 dans le pare-feu UFW. Cela permettra au serveur de recevoir les messages de journal du client. Le port 80 est le port que certbot utilisera pour générer le certificat TLS. Les commandes suivantes permettent d’ouvrir ces ports :

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      Sur le client, il suffit d’ouvrir le port 80 avec cette commande :

      Client

      Vous avez maintenant installé les composants nécessaires et terminé la configuration du système de base sur le client et le serveur. Avant de pouvoir configurer ces composants pour commencer à relayer les messages du journal, vous devez enregistrer les certificats Let’s Encrypt TLS pour le client et le serveur à l’aide de l’utilitaire certbot.

      Étape 2 — Installation de Certbot et enregistrement de certificats

      Let’s Encrypt est une autorité de certification qui délivre des certificats TLS gratuits. Ces certificats permettent aux ordinateurs à la fois de crypter les données qu’ils s’envoient entre eux et de vérifier l’identité de chacun. Ce sont ces certificats qui vous permettent de sécuriser votre navigation sur Internet avec HTTPS. Les mêmes certificats peuvent être utilisés par toute autre application qui souhaite le même niveau de sécurité. La procédure d’enregistrement du certificat est la même, quelle que soit l’utilisation que vous en ferez.

      Au cours de cette étape, vous installerez l’utilitaire certbot et l’utiliserez pour enregistrer les certificats. Il se chargera également de renouveler automatiquement les certificats lorsqu’ils arriveront à expiration. La procédure d’enregistrement est ici la même sur le client et sur le serveur. Il vous suffit de changer le nom d’hôte pour qu’il corresponde à celui de l’hôte sur lequel vous exécutez la commande d’enregistrement.

      Tout d’abord, installez certbot et l’utilitaire curl sur les deux hôtes :

      Client and Server

      • sudo apt install certbot curl

      Maintenant que vous avez installé certbot, exécutez la commande suivante pour enregistrer les certificats sur le client et le serveur :

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Les options de cette commande signifient ce qui suit :

      • certonly : enregistrer le certificat et ne faire aucune autre modification dans le système.
      • --standalone : utiliser le serveur web intégré de certbot pour vérifier la demande de certificat.
      • --agree-tos : accepter automatiquement les conditions d’utilisation du service Let’s Encrypt.
      • --email your-email : il s’agit de l’adresse électronique que Let’s Encrypt utilisera pour vous informer de l’expiration du certificat et d’autres informations importantes.
      • -d your_domain : le nom d’hôte pour lequel le certificat sera enregistré. Il doit correspondre au système dans lequel vous l’exécutez.

      Lorsque vous exécutez cette commande, il vous sera demandé si vous souhaitez partager l’adresse électronique avec Let’s Encrypt afin qu’ils puissent vous envoyer des bulletins d’actualités et d’autres informations sur leur travail. Cette opération est facultative. Si vous ne communiquez pas votre adresse électronique, l’enregistrement du certificat se déroulera quand même normalement.

      Lorsque le processus d’enregistrement du certificat sera terminé, il placera le certificat et les fichiers clés dans /etc/letsencrypt/live/your_domain/your_domain est le nom d’hôte pour lequel vous avez enregistré le certificat.

      Enfin, vous devez télécharger une copie de l’AC Let’s Encrypt et des certificats intermédiaires, puis les placer dans le même fichier. journald utilisera ce fichier pour vérifier l’authenticité des certificats sur le client et le serveur lorsqu’ils communiquent entre eux.

      La commande suivante permet de télécharger les deux certificats sur le site web Let’s Encrypt et de les placer dans un seul fichier appelé letsencrypt-combined-certs.pem dans le répertoire personnel de votre utilisateur.

      Exécutez cette commande sur le client et le serveur pour télécharger les certificats et créer le fichier combiné :

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Ensuite, déplacez ce fichier dans le répertoire Let’s Encrypt contenant les certificats et les clés :

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Vous avez maintenant enregistré les certificats et les clés. Dans l’étape suivante, vous configurerez le serveur de collecte de journaux pour qu’il commence à écouter et à stocker les messages des journaux du client.

      Étape 3 — Configuration du serveur

      Au cours de cette étape, vous configurerez le serveur pour qu’il utilise les fichiers de certificats et de clés que vous avez générés à la dernière étape afin qu’il puisse commencer à accepter les messages de journal du client.

      systemd-journal-remote est le composant qui écoute les messages de journal. Ouvrez son fichier de configuration à l’adresse /etc/systemd/journal-remote.conf avec un éditeur de texte pour commencer à le configurer sur le serveur :

      • sudo nano /etc/systemd/journal-remote.conf

      Ensuite, décommentez toutes les lignes sous la section [Remote] et définissez les chemins d’accès aux fichiers TLS que vous venez de créer :

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Voici les options que vous avez utilisées ici :

      • Seal=false : signer les données du journal dans le journal. Activez cette option si vous avez besoin d’une sécurité maximale ; sinon, vous pouvez la laisser comme false.
      • SplitMode=host : les journaux des clients distants seront répartis par hôte dans /var/log/journal/remote. Si vous préférez que tous les journaux soient ajoutés dans un seul fichier, réglez celui-ci sur SplitMode=false.
      • ServerKeyFile : le fichier de clé privée du serveur.
      • ServerCertificateFile: le fichier de certificat du serveur.
      • TrustedCertificateFile: le fichier contenant les certificats AC Let’s Encrypt.

      Maintenant, vous devez modifier les autorisations sur les répertoires de Let’s Encrypt qui contiennent les certificats et la clé afin que le systemd-journal-remote puisse les lire et les utiliser.

      Tout d’abord, modifiez les autorisations afin que le certificat et la clé privée soient lisibles :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ensuite, changez la propriété du groupe de la clé privée pour celle du groupe de systemd-journal-remote :

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Vous pouvez maintenant lancer systemd-journal-remote :

      • sudo systemctl start systemd-journal-remote.service

      Votre serveur de collecte de journaux est maintenant en cours d’exécution et prêt à commencer à accepter les messages de journaux d’un client. Dans l’étape suivante, vous configurerez le client pour qu’il transmette les journaux à votre serveur de collecte.

      Étape 4 — Configuration du client

      Au cours de cette étape, vous configurerez le composant qui relaie les messages du journal au serveur de collecte des journaux. Ce composant s’appelle systemd-journal-upload.

      La configuration par défaut de systemd-journal-upload fait qu’il a recours à un utilisateur temporaire qui n’existe que pendant le déroulement du processus. Il est donc plus compliqué d’autoriser systemd-journal-upload à lire les certificats et les clés TLS. Pour résoudre ce problème, vous créerez un nouvel utilisateur système portant le même nom que l’utilisateur temporaire qui sera utilisé à sa place.

      Tout d’abord, créez le nouvel utilisateur appelé systemd-journal-upload sur le client avec la commande adduser suivante :

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Ces options de commande sont :

      • --system : créer le nouvel utilisateur en tant qu’utilisateur système. Elle donne à l’utilisateur un numéro UID (User Identifier) inférieur à 1000. Les UID de plus de 1 000 sont généralement attribués à des comptes utilisateurs avec lesquels un humain se connectera.
      • --home /run/systemd : définir /run/systemd comme le répertoire d’origine de cet utilisateur.
      • --no-create-home : ne pas créer le répertoire d’origine, car il existe déjà.
      • --disabled-login : l’utilisateur ne peut pas se connecter au serveur (via SSH, par exemple).
      • --group : créer un groupe portant le même nom que l’utilisateur.

      Ensuite, définissez les autorisations et la propriété des fichiers de certificat Let’s Encrypt :

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Maintenant, modifiez la configuration pour systemd-journal-upload, qui se trouve dans /etc/systemd/journal-upload.conf. Ouvrez ce fichier avec un éditeur de texte :

      • sudo nano /etc/systemd/journal-upload.conf

      Modifiez ce fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Enfin, redémarrez le service systemd-journal-upload afin qu’il utilise la nouvelle configuration :

      • sudo systemctl restart systemd-journal-upload.service

      Votre client est maintenant configuré, en cours d’exécution et envoie ses messages au serveur de collecte de journaux. Dans l’étape suivante, vous vérifierez que les journaux sont correctement envoyés et enregistrés.

      Étape 5 — Test du client et du serveur

      Au cours de cette étape, vous vérifierez que le client relaie les messages de journaux au serveur et que le serveur les stocke correctement.

      Le serveur de collecte des journaux stocke les journaux des clients dans le répertoire /var/log/journal/remote/. Lorsque vous avez redémarré le client à la fin de la dernière étape, il a commencé à envoyer des messages de journaux ; il y a donc maintenant un fichier journal dans /var/log/journal/remote/. Le fichier sera nommé d’après le nom d’hôte que vous avez utilisé pour le certificat TLS.

      Utilisez la commande ls pour vérifier que le fichier journal du client est présent sur le serveur :

      Server

      • sudo ls -la /var/log/journal/remote/

      Cela permet d’imprimer le contenu du répertoire contenant le fichier journal :

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      Ensuite, écrivez un message de journal sur le client pour vérifier que le serveur reçoit les messages du client comme prévu. Vous utiliserez l’utilitaire logger pour créer un message de journal personnalisé sur le client. Si tout fonctionne correctement, systemd-journal-upload transmettra ce message au serveur.

      Sur le client, exécutez la commande logger suivante :

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Le -p syslog.debug de cette commande définit la facilité et la gravité du message. Si vous réglez ce paramètre sur syslog.debug, vous verrez qu’il s’agit d’un message de test. Cette commande enregistre le message ### TEST MESSAGE from client.your_domain ### dans le journal du client, que systemd-journal-upload transfère au serveur.

      Ensuite, lisez le fichier journal du client sur le serveur pour vérifier que les messages du journaux arrivent bien en provenance du client. Ce fichier est un fichier journal binaire, vous ne pourrez donc pas le lire avec des outils comme less. Lisez plutôt le fichier en utilisant journalctl avec l’option --file= qui vous permet de spécifier un fichier journal personnalisé :

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Le message du journal apparaîtra comme suit :

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Votre serveur de centralisation des journaux recueille maintenant avec succès les journaux de votre système client.

      Conclusion

      Dans cet article, vous avez mis en place un serveur central de collecte de journaux et configuré un client pour qu’il transmette une copie de ses journaux système au serveur. Vous pouvez configurer autant de clients que nécessaire pour relayer les messages au serveur de collecte de journaux en exécutant les étapes de configuration des clients que vous avez réalisées ici.



      Source link

      Como centralizar logs com o Journald no Debian 10


      O autor selecionou o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      Os logs de sistema são um componente extremamente importante no gerenciamento de sistemas Linux. Eles fornecem uma visão valiosa sobre como os sistemas estão funcionando e também como eles estão sendo usados, porque, além de erros, eles registram informações operacionais como eventos de segurança. A configuração padrão para sistemas Linux é para armazenar seus logs localmente no mesmo sistema onde eles ocorreram. Isso funciona para sistemas standalone, mas rapidamente torna-se um problema à medida que o número de sistemas aumenta. A solução para gerenciar todos esses logs é criar um servidor de logs centralizado onde cada host Linux envia seus logs, em tempo real, para um servidor de gerenciamento de logs dedicado.

      Uma solução de log centralizada oferece vários benefícios em comparação com o armazenamento de logs em cada host:

      • Reduz a quantidade de espaço em disco necessária em cada host para armazenar arquivos de log.
      • Os logs podem ser retidos por mais tempo, pois o servidor de log dedicado pode ser configurado com mais capacidade de armazenamento.
      • Análise de log avançada pode ser realizada, o que requer logs a partir de vários sistemas e também mais recursos de computação do que podem estar disponíveis nos hosts.
      • Os administradores de sistemas podem acessar os logs para todos os seus sistemas nos quais eles talvez não consigam efetuar login diretamente por questões de segurança.

      Neste guia, você irá configurar um componente do conjunto de ferramentas systemd para retransmitir mensagens de log de sistemas cliente a um servidor de coleta de log centralizado. Você irá configurar o servidor e o cliente para usar certificados TLS para criptografar as mensagens de log à medida que elas são transmitidas por redes inseguras, como a internet e também para autenticar um ao outro.

      Pré-requisitos

      Antes de iniciar este guia, será necessário o seguinte:

      • Dois servidores Debian 10.
      • Um usuário não-root com privilégios sudo em ambos os servidores. Siga o guia Initial Server Setup with Debian 10 para instruções sobre como fazer isso. Você também deve configurar o firewall UFW em ambos os servidores, conforme explicado no guia.
      • Dois nomes de host que apontam para seus servidores. Um nome de host para o sistema client que gera os logs e outro para o server de coleta de log. Saiba como apontar nomes de host para os Droplets da DigitalOcean consultando a documentação de Domínios e DNS.

      Este guia irá usar os seguintes dois nomes de host de exemplo:

      • client.your_domain: O sistema cliente que gera os logs.
      • server.your_domain: O servidor de coleta de log.

      Faça login tanto no cliente quanto no servidor em terminais separados via SSH como o usuário sudo não-root para iniciar este tutorial.

      Nota: ao longo do tutorial, os blocos de comando são rotulados com o nome do servidor (client ou server) em que o comando deve ser executado.

      Passo 1 — Instalando o systemd-journal-remote

      Neste passo, você irá instalar o pacote systemd-journal-remote no client e no server. Este pacote contém os componentes que o client e o server usam para transmitir as mensagens de log.

      Primeiro, tanto no client quanto no server, execute uma atualização de sistema para garantir que o banco de dados de pacotes e o sistema estejam atualizados:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      Em seguida, instale o pacote systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      No server, habilite e inicie os dois componentes systemd que ele precisa para receber mensagens de log com o seguinte comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      A opção --now no primeiro comando inicia os serviços imediatamente. Você não o usou no segundo comando, porque este serviço não irá iniciar até que ele tenha certificados TLS, que você irá criar no próximo passo.

      No client, habilite o componente que o systemd usa para enviar as mensagens de log para o servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Em seguida, no servidor, abra as portas 19532 e 80 no firewall UFW. Isso permitirá ao servidor receber as mensagens de log do cliente. A porta 80 é a porta que o certbot irá usar para gerar o certificado TLS. Os seguintes comandos irão abrir essas portas:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      No cliente, você só precisa abrir a porta 80 com este comando:

      Client

      Agora, você instalou os componentes necessários e concluiu a configuração básica do sistema no cliente e no servidor. Antes de configurar esses componentes para começar a retransmitir mensagens de log, você registrará os certificados TLS Let’s Encrypt para o client e o server usando o utilitário certbot.

      Passo 2 — Instalando o Certbot e registrando certificados

      O Let’s Encrypt é uma Autoridade de Certificação que emite certificados TLS gratuitos. Esses certificados permitem que os computadores criptografem os dados que eles enviam entre eles e também verificam a identidade um do outro. Esses certificados são o que lhe permite proteger sua navegação na Internet com HTTPS. Os mesmos certificados podem ser usados por qualquer outra aplicação que queira o mesmo nível de segurança. O processo de registro do certificado é o mesmo, independentemente para o que você o utilize.

      Neste passo, você irá instalar o utilitário certbot e usá-lo para registrar os certificados. Ele também irá cuidar automaticamente de renovar os certificados quando eles expirarem. O processo de registro aqui é o mesmo no client e no server. Você só precisa alterar o nome do host para corresponder ao host onde você está executando o comando de registo.

      Primeiro, instale o certbot e o utilitário curl em ambos os hosts:

      Client and Server

      • sudo apt install certbot curl

      Agora que você instalou o certbot, execute o seguinte comando para registrar os certificados no client e no server:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      As opções neste comando significam o seguinte:

      • certonly: registrar o certificado e não fazer nenhuma outra alteração no sistema.
      • --standalone: usar o servidor Web embutido do certbot para verificar a solicitação de certificado.
      • --agree-tos: concordar automaticamente com os Termos de Serviço do Let’s Encrypt.
      • --email your-email: este é o endereço de e-mail que o Let’s Encrypt irá usar para notificá-lo sobre a expiração do certificado e outras informações importantes.
      • -d your_domain: o nome de host para o qual o certificado será registrado. Isso deve corresponder ao sistema em que você o executa.

      Ao executar este comando, você será perguntado se você deseja compartilhar o endereço de e-mail com o Let’s Encrypt para que eles possam enviar a você notícias e outras informações sobre seu trabalho. Fazer isso é opcional, se você não compartilhar seu endereço de e-mail o registro de certificado ainda irá completar normalmente.

      Quando o processo de registro de certificado for concluído, ele irá colocar o certificado e os arquivos de chave em /etc/letsencrypt/live/your_domain/ onde your_domain é o nome de host para o qual você registrou o certificado.

      Por fim, você precisa baixar uma cópia do Let’s Encrypt CA e certificados intermediários e colocá-los no mesmo arquivo. O journald irá usar este arquivo para verificar a autenticidade dos certificados no client e no server quando eles se comunicam um com o outro.

      O comando a seguir irá baixar os dois certificados do site do Let’s Encrypt e colocá-los em um único arquivo chamado letsencrypt-combined-certs.pem no diretório home do seu usuário.

      Execute este comando no client e no server para baixar os certificados e criar o arquivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Em seguida, mova este arquivo para o diretório do Let’s Encrypt que contém os certificados e chaves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Agora, você registrou os certificados e as chaves. No próximo passo, você irá configurar o server de coleta de logs para iniciar a escuta e armazenar mensagens de log do client.

      Passo 3 — Configurando o servidor

      Neste passo, você irá configurar o server para usar o certificado e os arquivos de chave que você gerou no último passo para que ele possa começar a aceitar mensagens de log do client.

      O systemd-journal-remote é o componente que faz a escuta para as mensagens de log. Abra seu arquivo de configuração em /etc/systemd/journal-remote.conf com um editor de texto para iniciar a configuração dele no server:

      • sudo nano /etc/systemd/journal-remote.conf

      Em seguida, descomente todas as linhas sob a seção [Remote] e defina os caminhos para apontar para os arquivos TLS que você acabou de criar:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Aqui estão as opções que você usou aqui:

      • Seal=false: assine os dados de log no journal. Habilite isso se você precisar de segurança máxima; caso contrário, você pode deixá-lo como falso.
      • SplitMode=host: os logs dos clientes remotos serão divididos por host em /var/log/journal/remote. Se você preferir que todos os logs sejam adicionados a um único arquivo defina isso como SplitMode=false.
      • ServerKeyFile: o arquivo de chave privada do servidor.
      • ServerCertificateFile: o arquivo de certificado do servidor.
      • TrustedCertificateFile: o arquivo que contém os certificados Let’s Encrypt CA.

      Agora, você precisa alterar as permissões nos diretórios do Let’s Encrypt que contêm os certificados e a chave para que o systemd-journal-remote possa lê-los e usá-los.

      Primeiro, altere as permissões para que o certificado e a chave privada sejam legíveis:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Em seguida, mude a propriedade do grupo da chave privada para o grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Agora, você pode iniciar o systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Seu server de coleta de log agora está em execução e pronto para começar a aceitar mensagens de log de um client. No próximo passo, você irá configurar o client para retransmitir os logs para seu server de coleta.

      Passo 4 — Configurando o cliente

      Neste passo, você irá configurar o componente que retransmite as mensagens de log para o servidor de coleta de log. Este componente é chamado systemd-journal-upload.

      A configuração padrão para o systemd-journal-upload é que ele usa um usuário temporário que só existe enquanto o processo está em execução. Isso torna mais complicada a permissão para o systemd-journal-upload ler os certificados TLS e as chaves. Para resolver isso, você irá criar um novo usuário de sistema com o mesmo nome que o usuário temporário que será usado em seu lugar.

      Primeiro, crie o novo usuário chamado systemd-journal-upload no client com o seguinte comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Essas opções para o comando são:

      • --system: cria o novo usuário como um usuário do sistema. Isso dá ao usuário um número UID (User Identifier) abaixo de 1000. UID’s acima de 1000 são geralmente dados a contas de usuário que um humano irá usar para fazer login.
      • --home /run/systemd: define /run/systemd como o diretório home para este usuário.
      • --no-create-home: não cria o conjunto de diretório home, uma vez que ele já existe.
      • --disabled-login: o usuário não pode fazer login no servidor via SSH, por exemplo.
      • --group: cria um grupo com o mesmo nome que o usuário.

      Em seguida, defina as permissões e a propriedade dos arquivos de certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Agora, edite a configuração para o systemd-journal-upload, que está em /etc/systemd/journal-upload.conf. Abra este arquivo com um editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este arquivo para que ele fique como o seguinte:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Por fim, reinicie o serviço systemd-journal-upload para que ele use a nova configuração:

      • sudo systemctl restart systemd-journal-upload.service

      Seu client agora está configurado e funcionando e está enviando suas mensagens de log para o servidor de coleta de log. No próximo passo, você irá verificar se os logs estão sendo enviados e gravados corretamente.

      Passo 5 — Testando o cliente e o servidor

      Neste passo, você irá testar se o client está retransmitindo mensagens de log para o server e se o server está armazenando-as corretamente.

      O servidor de coleta de log armazena os logs dos clientes em um diretório em /var/log/journal/remote/. Quando você reiniciou o client no final do último passo, ele começou a enviar mensagens de log, dessa forma há agora um arquivo de log em /var/log/journal/remote/. O arquivo será nomeado após o nome do host usado para o certificado TLS.

      Use o comando ls para verificar se o arquivo de log do client está presente no server:

      Server

      • sudo ls -la /var/log/journal/remote/

      Isso irá imprimir o conteúdo do diretório mostrando o arquivo de log:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      Em seguida, escreva uma mensagem de log no client para verificar se o server está recebendo as mensagens do client como você espera. Você irá usar o utilitário logger para criar uma mensagem de log personalizada no client. Se tudo estiver funcionando, o systemd-journal-upload irá retransmitir esta mensagem ao server.

      No client execute o seguinte comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      O -p syslog.debug neste comando define a facilidade e a severidade da mensagem. Definir isso para syslog.debug irá tornar claro que ela é uma mensagem de teste. Este comando irá gravar a mensagem ### TEST MESSAGE from client.your_domain ### no journal do cliente, que o systemd-journal-upload então retransmite para o server.

      Em seguida, leia o arquivo de journal do client no server para verificar se as mensagens de log estão chegando do client. Este arquivo é um arquivo de log binário, portanto você não será capaz de lê-lo com ferramentas como o less. Em vez disso, leia o arquivo usando o journalctl com a opção --file= que lhe permite especificar um arquivo de journal personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      A mensagem de log irá aparecer da seguinte forma:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Seu servidor de centralização de log agora está coletando logs com sucesso a partir do seu sistema cliente.

      Conclusão

      Neste artigo, você configurou um servidor central de coleta de logs e configurou um cliente para retransmitir uma cópia dos logs de sistema ao servidor. Você pode configurar quantos clientes você precisar retransmitir mensagens ao servidor de coleta de log usando os passos de configuração do cliente que você usou aqui.



      Source link