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.

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:

sudo apt update
sudo apt upgrade

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

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:

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:

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:

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

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

sudo ufw allow in 80/tcp

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:

sudo apt install certbot curl

Agora que você instalou o certbot, execute o seguinte comando para registrar os certificados no client e no 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:

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:

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:

[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:

[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:

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:

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:

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.