One place for hosting & domains

      Logs

      Como centralizar logs com o Journald no Ubuntu 20.04


      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 Ubuntu 20.04.
      • Um usuário não-root com privilégios sudo em ambos os servidores. Siga o guia Initial Server Setup with Ubuntu 20.04 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, habilite o repositório universe do Ubuntu, pois o utilitário certbot reside no repositório universe. Se você já tiver o repositório universe habilitado, executar esses comandos não fará nada com seu sistema e é seguro executar:

      Client and Server

      • sudo apt install software-properties-common

      • sudo add-apt-repository universe

      • sudo apt update

      Em seguida, instale o certbot em ambos os hosts:

      Client and Server

      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 notificar você 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 CA do Let’s Encrypt 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

      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

      How To Centralize Logs With Journald on Debian 10


      Not using Debian 10?


      Choose a different version or distribution.

      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      System logs are an extremely important component of managing Linux systems. They provide an invaluable insight into how the systems are working and also how they are being used because, in addition to errors, they record operational information such as security events. The standard configuration for Linux systems is to store their logs locally on the same system where they occurred. This works for standalone systems but quickly becomes a problem as the number of systems increases. The solution to managing all these logs is to create a centralized logging server where each Linux host sends its logs, in real-time, to a dedicated log management server.

      A centralized logging solution offers several benefits compared with storing logs on each host:

      • Reduces the amount of disk space needed on each host to store log files.
      • Logs can be retained for longer as the dedicated log server can be configured with more storage capacity.
      • Advanced log analysis can be carried out that requires logs from multiple systems and also more compute resources than may be available on the hosts.
      • Systems administrators can access the logs for all their systems that they may not be able to log in to directly for security reasons.

      In this guide, you will configure a component of the systemd suite of tools to relay log messages from client systems to a centralized log collection server. You will configure the server and client to use TLS certificates to encrypt the log messages as they are transmitted across insecure networks such as the internet and also to authenticate each other.

      Prerequisites

      Before you begin this guide you’ll need the following:

      • Two Debian 10 servers.
      • A non-root user with sudo privileges on both servers. Follow the Initial Server Setup with Debian 10 guide for instructions on how to do this. You should also configure the UFW firewall on both servers as explained in the guide.
      • Two hostnames that point to your servers. One hostname for the client system that generates the logs and another one for the log collection server. Learn how to point hostnames to DigitalOcean Droplets by consulting the Domains and DNS documentation.

      This guide will use the following two example hostnames:

      • client.your_domain: The client system that generates the logs.
      • server.your_domain: The log collection server.

      Log in to both the client and server in separate terminals via SSH as the non-root sudo user to begin this tutorial.

      Note: Throughout the tutorial, command blocks are labeled with the server name (client or server) that the command should be run on.

      Step 1 — Installing systemd-journal-remote

      In this step, you will install the systemd-journal-remote package on the client and the server. This package contains the components that the client and server use to relay log messages.

      First, on both the client and server, run a system update to ensure that the package database and the system is current:

      Client and Server

      • sudo apt update

      • sudo apt upgrade

      Next, install the systemd-journal-remote package:

      Client and Server

      • sudo apt install systemd-journal-remote

      On the server, enable and start the two systemd components that it needs to receive log messages with the following command:

      Server

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

      • sudo systemctl enable systemd-journal-remote.service

      The --now option in the first command starts the services immediately. You did not use it in the second command because this service will not start until it has TLS certificates, which you will create in the next step.

      On the client, enable the component that systemd uses to send the log messages to the server:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Next, on the server, open ports 19532 and 80 in the UFW firewall. This will allow the server to receive the log messages from the client. Port 80 is the port that certbot will use to generate the TLS certificate. The following commands will open these ports:

      Server

      • sudo ufw allow in 19532/tcp

      • sudo ufw allow in 80/tcp

      On the client, you only need to open port 80 with this command:

      Client

      You have now installed the required components and completed the base system configuration on the client and server. Before you can configure these components to start relaying log messages you will register the Let’s Encrypt TLS certificates for the client and server using the certbot utility.

      Step 2 — Installing Certbot and Registering Certificates

      Let’s Encrypt is a Certificate Authority that issues free TLS certificates. These certificates allow computers to both encrypt the data that they send between them and also verify each other’s identity. These certificates are what allow you to secure your internet browsing with HTTPS. The same certificates can be used by any other application that wants the same level of security. The process of registering the certificate is the same no matter what you use them for.

      In this step, you will install the certbot utility and use it to register the certificates. It will also automatically take care of renewing the certificates when they expire. The registration process here is the same on the client and server. You only need to change the hostname to match the host where you are running the registration command.

      First, install certbot and the curl utility on both hosts:

      Client and Server

      • sudo apt install certbot curl

      Now you’ve installed certbot, run the following command to register the certificates on the client and server:

      Client and Server

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

      The options in this command mean as follows:

      • certonly: Register the certificate and make no other changes on the system.
      • --standalone: Use certbot’s built-in web server to verify the certificate request.
      • --agree-tos: Automatically agree to the Let’s Encrypt Terms of Service.
      • --email your-email: This is the email address that Let’s Encrypt will use to notify you about certificate expiry and other important information.
      • -d your_domain: The hostname that the certificate will be registered for. This must match the system where you run it.

      When you run this command you will be asked if you want to share the email address with Let’s Encrypt so they can email you news and other information about their work. Doing this is optional, if you do not share your email address the certificate registration will still complete normally.

      When the certificate registration process completes it will place the certificate and key files in /etc/letsencrypt/live/your_domain/ where your_domain is the hostname that you registered the certificate for.

      Finally, you need to download a copy of the Let’s Encrypt CA and intermediate certificates and put them into the same file. journald will use this file to verify the authenticity of the certificates on the client and server when they communicate with each other.

      The following command will download the two certificates from the Let’s Encrypt website and put them into a single file called letsencrypt-combined-certs.pem in your user’s home directory.

      Run this command on the client and server to download the certificates and create the combined file:

      Client and Server

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

      Next, move this file into the Let’s Encrypt directory containing the certificates and keys:

      Client and Server

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

      You’ve now registered the certificates and keys. In the next step, you will configure the log collection server to start listening for and storing log messages from the client.

      Step 3 — Configuring the Server

      In this step, you will configure the server to use the certificate and key files that you generated in the last step so that it can start accepting log messages from the client.

      systemd-journal-remote is the component that listens for log messages. Open its configuration file at /etc/systemd/journal-remote.conf with a text editor to start configuring it on the server:

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

      Next, uncomment all the lines under the [Remote] section and set the paths to point to the TLS files you just created:

      /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

      Here are the options you’ve used here:

      • Seal=false: Sign the log data in the journal. Enable this if you need maximum security; otherwise, you can leave it as false.
      • SplitMode=host: The logs from the remote clients will be split by host in /var/log/journal/remote. If you would prefer all the logs to be added to a single file set this to SplitMode=false.
      • ServerKeyFile: The server’s private key file.
      • ServerCertificateFile: The server’s certificate file.
      • TrustedCertificateFile: The file containing the Let’s Encrypt CA certificates.

      Now, you need to change the permissions on the Let’s Encrypt directories that contain the certificates and key so that the systemd-journal-remote can read and use them.

      First, change the permissions so that the certificate and private key are readable:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Next, change the group ownership of the private key to systemd-journal-remote’s group:

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

      You can now start systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Your log collection server is now running and ready to start accepting log messages from a client. In the next step, you will configure the client to relay the logs to your collection server.

      Step 4 — Configuring the Client

      In this step, you will configure the component that relays the log messages to the log collection server. This component is called systemd-journal-upload.

      The default configuration for systemd-journal-upload is that it uses a temporary user that only exists while the process is running. This makes allowing systemd-journal-upload to read the TLS certificates and keys more complicated. To resolve this you will create a new system user with the same name as the temporary user that will get used in its place.

      First, create the new user called systemd-journal-upload on the client with the following adduser command:

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

      These options to the command are:

      • --system: Create the new user as a system user. This gives the user a UID (User Identifier) number under 1000. UID’s over 1000 are usually given to user accounts that a human will use to log in with.
      • --home /run/systemd: Set /run/systemd as the home directory for this user.
      • --no-create-home: Don’t create the home directory set, as it already exists.
      • --disabled-login: The user cannot log in to the server via, for example, SSH.
      • --group: Create a group with the same name as the user.

      Next, set the permissions and ownership of the Let’s Encrypt certificate files:

      • 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

      Now, edit the configuration for systemd-journal-upload, which is at /etc/systemd/journal-upload.conf. Open this file with a text editor:

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

      Edit this file so that it looks like the following:

      /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

      Finally, restart the systemd-journal-upload service so it uses the new configuration:

      • sudo systemctl restart systemd-journal-upload.service

      Your client is now set up and running and is sending its log messages to the log collection server. In the next step, you will check that the logs are being sent and recorded correctly.

      Step 5 — Testing the Client and Server

      In this step, you will test that the client is relaying log messages to the server and that the server is storing them correctly.

      The log collection server stores the logs from the clients in a directory at /var/log/journal/remote/. When you restarted the client at the end of the last step it began sending log messages so there is now a log file in /var/log/journal/remote/. The file will be named after the hostname you used for the TLS certificate.

      Use the ls command to check that the client’s log file is present on the server:

      Server

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

      This will print the directory contents showing the log file:

      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'

      Next, write a log message on the client to check that the server is receiving the client’s messages as you expect. You will use the logger utility to create a custom log message on the client. If everything is working systemd-journal-upload will relay this message to the server.

      On the client run the following logger command:

      Client

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

      The -p syslog.debug in this command sets the facility and severity of the message. Setting this to syslog.debug will make clear it’s a test message. This command will record the message ### TEST MESSAGE from client.your_domain ### to the client’s journal, which systemd-journal-upload then relays to the server.

      Next, read the client’s journal file on the server to check that the log messages are arriving from the client. This file is a binary log file so you will not be able to read it with tools like less. Instead, read the file using journalctl with the --file= option that allows you to specify a custom journal file:

      Server

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

      The log message will appear as follows:

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

      Your log centralization server is now successfully collecting logs from your client system.

      Conclusion

      In this article, you set up a log central collection server and configured a client to relay a copy of its system logs to the server. You can configure as many clients as you need to relay messages to the log collection server using the client configuration steps you used here.



      Source link

      Forgot Your Password ?