Encaminhamento seguro de Syslog no SLES com rsyslog e TLS mútuo.

Para encaminhar logs de sistema do SUSE Linux Enterprise Server (SLES) com segurança, configure o rsyslog para enviar mensagens pela porta TCP 6514 protegida por TLS, verifique o nome do certificado do coletor e confirme a entrega com um evento de teste. O SLES 15 SP7 recebeu uma atualização opcional do rsyslog em 27 de março de 2026 que adicionou um módulo TLS OpenSSL; a configuração abaixo usa deliberadamente o gtlsmódulo GnuTLS ( ) já estabelecido.

Este procedimento abrange um remetente SLES 15 chamado <nome_do_remetente> sles01.example.nete um coletor rsyslog chamado <nome_do_coletor> logs.example.net. Substitua ambos os nomes e todos os caminhos de certificado pelos seus próprios valores. Ele usa TLS mútuo, portanto, o coletor autentica o remetente e o remetente autentica o coletor.

1. Verifique o rsyslog e o caminho de registro do SLES.

Em ambos os hosts, instale o daemon rsyslog e seu módulo GnuTLS a partir dos repositórios SUSE registrados. Instalações existentes podem já conter o primeiro pacote.

sudo zypper install rsyslog rsyslog-module-gtls
rpm -q rsyslog rsyslog-module-gtls
sudo systemctl enable --now rsyslog
rsyslogd -v

Revise /etc/rsyslog.confos trechos de código existentes /etc/rsyslog.d/antes de adicionar novas regras. Em particular, desative qualquer *.* @@hostregra de encaminhamento não criptografada mais antiga para o mesmo destino; caso contrário, as mensagens poderão seguir duas rotas, incluindo uma sem TLS.

O SLES utiliza systemd-journaldo journal para eventos, enquanto o rsyslog processa as entradas do syslog. Confirme se os eventos necessários chegam ao rsyslog através da configuração de entrada existente. A documentação do SUSE ForwardToSyslog=yestrata /etc/systemd/journald.confdo encaminhamento de journal para syslog; verifique sua implementação antes de alterá-la, pois habilitar leitores de journal separadamente pode criar eventos duplicados. Este procedimento encaminha mensagens já processadas pelo rsyslog, não todos os arquivos /var/logautomaticamente.

2. Prepare certificados confiáveis ​​para o servidor e o cliente.

Utilize uma autoridade de certificação (CA) controlada pela organização para emitir um certificado com o nome alternativo do assunto DNS logs.example.netpara o coletor e um certificado separado identificando sles01.example.neto remetente. Certifique-se de que os certificados sejam válidos para suas respectivas funções de servidor ou cliente TLS e que ambas as máquinas confiem na CA emissora. Siga o processo de infraestrutura de chave pública (PKI) da sua organização para geração e renovação de certificados; não reutilize uma chave privada em diferentes hosts.

Copie os arquivos apropriados por meio de um canal seguro aprovado pelo administrador. Neste exemplo, ambas as máquinas usam /etc/rsyslog.d/tls/ca.pem. O coletor também possui server-cert.peme server-key.pem; o remetente possui client-cert.peme client-key.pem.

sudo install -d -m 0750 /etc/rsyslog.d/tls
sudo chmod 0600 /etc/rsyslog.d/tls/*-key.pem
sudo chmod 0644 /etc/rsyslog.d/tls/ca.pem

Restrinja o acesso a certificados e chaves para a identidade do serviço rsyslog quando necessário. Não exponha chaves privadas em diagnósticos, histórico do shell, repositórios Git ou no fluxo de logs exportado. Confirme se o seu processo rsyslog consegue ler a sua chave antes de reiniciar o daemon.

3. Habilite um receptor TLS autenticado no coletor.

Em logs.example.net, adicione o seguinte como /etc/rsyslog.d/30-tls-listener.conf. Se imtcpjá estiver carregado em outro lugar, mantenha apenas uma declaração module-load. O conjunto de regras dedicado coloca as mensagens recebidas remotamente em um arquivo separado, em vez de misturá-las com as mensagens do sistema local.

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem"
)
module(load="imtcp")
ruleset(name="remote_tls") {
  action(type="omfile" file="/var/log/remote-tls.log")
}
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer="sles01.example.net"
  ruleset="remote_tls"
)

StreamDriver.Mode="1"Habilita o TLS x509/namee PermittedPeerrejeita clientes sem uma identidade de certificado aceita. O único nome permitido é intencional; a lista de pares aprovados é ampliada ao adicionar outros remetentes, em vez de enfraquecer a autenticação.

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload
sudo ss -ltn | grep ':6514'

Execute os comandos do firewall somente se o coletor usar o firewalld. Restrinja o tráfego TCP/6514 de entrada a redes de remetentes conhecidas usando o firewall do seu host ou o firewall upstream; abrir a porta não substitui a autenticação por certificado. Verifique também se nenhum listener de texto simples preexistente está exposto inadvertidamente.

4. Adicione encaminhamento TLS e uma fila limitada ao SLES

Verifique se sles01.example.neto diretório de trabalho do rsyslog existe e se o serviço tem permissão de escrita. O diretório mostrado aqui é apenas ilustrativo; mantenha um diretório já configurado, workDirectorycaso o seu pacote de instalação forneça um. Adicione este trecho como /etc/rsyslog.d/60-tls-forward.conf:

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client-key.pem"
)
*.* action(
  type="omfwd"
  target="logs.example.net"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  queue.type="LinkedList"
  queue.filename="tls_forward"
  queue.size="10000"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

As configurações TLS autenticam o coletor antes do envio. A fila de ações assistida por disco armazena mensagens em buffer durante interrupções curtas e tenta novamente uma ação de encaminhamento com falha, mas não é infinita nem garante a proteção contra todas as perdas de mensagens: o espaço em disco disponível, os limites da fila, o comportamento de encerramento do processo e a integridade do receptor ainda são fatores importantes. Verifique o diretório de trabalho efetivo do rsyslog e crie-o com a propriedade adequada antes de confiar no buffer de disco.

Valide e reinicie o remetente:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Se a validação da configuração falhar, não reinicie; corrija o primeiro erro relatado. Em uma implementação existente do rsyslog, as diretivas de certificado globais podem afetar outras ações TLS. Revise outras ações de saída e use parâmetros de certificado específicos para cada ação, caso elas exijam credenciais diferentes.

5. Verificar o recebimento e investigar uma falha na autenticação.

Primeiro, confirme se o coletor está escutando na porta TCP/6514 e se o remetente consegue alcançar o host através do firewall. Em seguida, execute o seguinte comando no remetente SLES:

logger -t sles-tls-check "TLS forwarding probe"

No coletor, procure o arquivo de log remoto configurado:

sudo grep 'TLS forwarding probe' /var/log/remote-tls.log
sudo journalctl -u rsyslog -n 50 --no-pager

A identificação do marcador /var/log/remote-tls.logconfirma que o caminho de encaminhamento em nível de aplicação funcionou para este teste. Isso não comprova que todos os arquivos de log específicos da aplicação estão sendo coletados. Para testar a autenticação de forma independente, utilize temporariamente um certificado diferente e não confiável ou um nome de servidor incompatível durante uma janela de manutenção controlada e confirme que a conexão TLS falha; restaure a configuração original imediatamente.

Se o marcador não aparecer, siga a ordem da falha:

• Sem ouvinte ou conexão recusada: verifique systemctl status rsyslogas regras de firewall TCP/6514 e do coletor.
• Falha no TLS ou no certificado: compare os SANs do certificado com PermittedPeeros de StreamDriverPermittedPeers; verifique a cadeia de CA, as datas de expiração, os relógios do sistema e as permissões da chave privada.
• Conectado, mas sem eventos: verifique se há entradas de journal/syslog duplicadas ou ausentes, ações de encaminhamento suspensas e capacidade da fila de disco. Analise journalctl -u rsyslogem ambos os hosts.

O método segue o guia oficial de registro de logs do sistema SLES 15 SP7 , o guia do cliente autenticado por certificado do rsyslog , a referência do listener imtcp e a referência de encaminhamento do omfwd . O aviso de atualização da SUSE de março de 2026 documenta a adição opcional do módulo OpenSSL. As configurações variam entre os service packs do SLES, portanto, valide-as em sua instalação do rsyslog antes de aplicar as alterações em produção.