Como exportar logs do sistema SLES para um servidor Syslog remoto com segurança

A maneira mais segura e prática de exportar logs de sistema do SUSE Linux Enterprise Server (SLES) para um coletor syslog remoto é usar o rsyslog sobre TCP com TLS, validar o certificado do coletor pelo nome e atribuir uma fila própria à ação de encaminhamento. O syslog via UDP puro é simples, mas não oferece confidencialidade nem autenticação entre pares. O TCP puro melhora o comportamento de entrega, mas ainda deixa o conteúdo dos logs exposto durante a transmissão.

Este guia utiliza o driver de fluxo de rede GnuTLS ( gtls) e a sintaxe moderna de ações do rsyslog. O procedimento destina-se a sistemas SLES 15 SP7, cujo Guia de Administração foi atualizado em 1º de outubro de 2026. Sempre verifique os pacotes e a versão do rsyslog instalados no seu host antes de copiar uma configuração literalmente. A documentação oficial do rsyslog recomenda o uso de TCP com TLS para implementações modernas e uma fila de ações para encaminhamento TCP.

Referências oficiais: Documentação do SUSE Linux Enterprise Server 15 SP7 , documentação do rsyslog omfwd , configuração do cliente TLS do rsyslog e RFC 5425: Mapeamento de transporte TLS para Syslog .

Referência rápida

Antes de configurar o encaminhamento

Você precisa do nome de domínio totalmente qualificado (FQDN) do coletor remoto, da porta TCP em que ele está escutando e do certificado da autoridade certificadora (CA) que assina o certificado do coletor. Para TLS mútuo, você também precisa de um certificado de cliente e uma chave privada para a máquina SLES. O certificado do coletor deve ser válido para o nome de host configurado no rsyslog, preferencialmente por meio de um Nome Alternativo do Assunto (SAN). Não resolva uma incompatibilidade de nomes desativando a verificação de certificado.

O coletor remoto já deve estar configurado para aceitar syslog TLS. Este artigo se concentra no remetente SLES, pois a configuração do receptor varia entre rsyslog, syslog-ng, dispositivos SIEM e serviços de registro gerenciados. Se um firewall separar os sistemas, permita que o host SLES inicie conexões TCP com o coletor na porta configurada. Uma política padrão do firewalld com estado geralmente não exige a abertura de uma porta de entrada no remetente SLES.

Passo 1: Confirme se o rsyslog está instalado e identifique a versão atual.

Comece verificando a versão do pacote e do daemon. Isso evita confusão quando exemplos antigos usam diretivas que não são suportadas pela versão compilada no seu servidor.

rpm -q rsyslog
rsyslogd -v
systemctl status rsyslog --no-pager

Se o rsyslog não estiver instalado, instale-o a partir dos repositórios SLES habilitados. Mantenha o sistema atualizado através do processo normal de atualização do SUSE antes de expor uma conexão de registro de logs de longa duração.

Passo 2: Instale o módulo rsyslog do GnuTLS

No SLES, o driver de rede TLS é fornecido separadamente. Instale o módulo GnuTLS e mantenha o pacote base do rsyslog presente:

sudo zypper install rsyslog rsyslog-module-gtls

Você pode confirmar se os arquivos vieram do pacote esperado com o comando `ls -l` rpm -ql rsyslog-module-gtls. Os nomes dos pacotes são específicos da distribuição, portanto, não copie nomes de pacotes de guias voltados para Debian ou RHEL.

Etapa 3: Coloque a CA e as credenciais do cliente em local seguro.

Utilize certificados emitidos pela sua organização ou plataforma de registro de logs. Para um sistema de produção, evite criar uma nova Autoridade Certificadora (CA) privada no host que envia os logs. Um ambiente de laboratório pode usar uma CA de teste, mas os certificados de confiança para produção devem seguir o processo de Infraestrutura de Chaves Públicas (PKI) da sua organização.

Crie um diretório de propriedade do root, copie os arquivos e restrinja a chave privada. Substitua os nomes de arquivo de exemplo pelos caminhos fornecidos pela sua equipe de PKI:

sudo install -d -m 0755 /etc/rsyslog.d/certs
sudo install -m 0644 ca.pem /etc/rsyslog.d/certs/ca.pem
sudo install -m 0644 sles-client.crt /etc/rsyslog.d/certs/sles-client.crt
sudo install -m 0600 sles-client.key /etc/rsyslog.d/certs/sles-client.key
sudo chown root:root /etc/rsyslog.d/certs/*

Inspecione o certificado da Autoridade Certificadora (CA) e o certificado do cliente em vez de confiar nos nomes dos arquivos:

openssl x509 -in /etc/rsyslog.d/certs/ca.pem -noout -subject -issuer
openssl x509 -in /etc/rsyslog.d/certs/sles-client.crt -noout -subject -issuer -dates

A documentação do cliente TLS rsyslog alerta explicitamente que a chave privada da máquina deve ser protegida. Se outro usuário conseguir ler a chave privada, esse usuário poderá se passar pelo cliente de registro de logs.

Etapa 4: Configure o encaminhamento TLS com verificação do nome do servidor.

Crie um ambiente de instalação dedicado, como este /etc/rsyslog.d/60-remote-tls.conf. Manter o encaminhamento remoto separado da configuração do fornecedor facilita a revisão e o rollback.

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/sles-client.crt"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/sles-client.key"
)

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
    queue.type="linkedList"
)

StreamDriverMode="1"É importante ressaltar: escolher apenas um driver compatível com TLS não é suficiente em configurações onde o modo padrão é TCP simples. StreamDriverAuthMode="x509/name"Em seguida, o sistema verifica o certificado remoto e confirma se a identidade do servidor corresponde à do servidor autorizado. Sempre que possível, utilize o nome exato do coletor no certificado em vez de um curinga amplo.

A ação acima encaminha todas as mensagens que a recebem. Se você deseja encaminhar apenas recursos ou prioridades selecionadas, adicione um filtro antes da ação. Por exemplo, um ambiente com foco em segurança pode encaminhar eventos de autenticação e daemon, enquanto retém localmente os logs de depuração de aplicativos de alto volume. A filtragem deve ser orientada por necessidades de retenção, resposta a incidentes e conformidade, e não pela suposição genérica de que todas as mensagens devem sair do host.

Etapa 5: Valide, reinicie, envie um evento de teste e verifique a entrega.

Valide a configuração completa do rsyslog antes de reiniciar o serviço. Esta é a maneira mais rápida de detectar erros de sintaxe e referências de módulos ausentes.

sudo rsyslogd -N1

Se a validação for bem-sucedida, reinicie o rsyslog e envie uma mensagem de teste exclusiva:

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
logger -t sles-tls-test "remote syslog TLS test $(date -Is)"
sudo journalctl -u rsyslog -n 50 --no-pager

No coletor, procure pela tag sles-tls-teste pelo nome do host do remetente. Uma aparição remota bem-sucedida comprova que a mensagem chegou ao coletor, mas isso por si só não comprova que a verificação de certificado foi configurada corretamente. A verificação mais robusta é manter a x509/nameverificação remota habilitada e confirmar que não há erros de handshake TLS ou de nome do par no log do serviço rsyslog.

Se a conexão falhar, teste a resolução de DNS para logs.example.com, confirme se a porta TCP 6514 está acessível, verifique as datas de validade do certificado e confirme se o certificado do coletor contém o nome DNS esperado. Confirme também se o coletor confia na Autoridade Certificadora (CA) que emitiu o certificado do cliente SLES quando o TLS mútuo estiver habilitado.

Lista de verificação para resolução de problemas

• Conexão recusada: o coletor não está escutando no endereço/porta configurado ou um firewall está rejeitando a conexão.
• Tempo limite excedido: o roteamento, as ACLs de rede ou um firewall estão descartando tráfego silenciosamente.
• A verificação do certificado falhou: o arquivo da CA está incorreto, incompleto, expirado ou a cadeia de certificados do servidor está incompleta.
• Incompatibilidade de nome do par: o nome target/ StreamDriverPermittedPeersnão corresponde à identidade do certificado do coletor.
• Permissão negada na chave: o caminho da chave ou as permissões não permitem que o processo rsyslog leia o arquivo na configuração do serviço SLES.
• As mensagens são interrompidas durante uma falha: revise o design e a capacidade da fila de ações. A documentação upstream do omfwd recomenda especificamente uma fila para encaminhamento TCP, para que um destino indisponível não bloqueie o processamento normal.

Notas de segurança que são fáceis de passar despercebidas

Não substitua a validação de certificado por TLS anônimo, a menos que você compreenda completamente as desvantagens. A criptografia sem autenticação do servidor ainda pode expor os registros a um ataque man-in-the-middle ativo. Da mesma forma, não abra a porta TCP 6514 de entrada no remetente SLES apenas porque o destino usa essa porta; o encaminhamento é uma conexão de cliente de saída.

Proteja as chaves privadas do cliente como credenciais, rotacione os certificados antes que expirem e use um nome de host para o coletor que permaneça estável mesmo com alterações de endereço IP. Se precisar de garantias de entrega mais robustas do que o encaminhamento TCP/TLS normal, a documentação do rsyslog indica o RELP como uma alternativa projetada para entrega confirmada. Essa é uma escolha de projeto distinta da criptografia de transporte.

Verificação final

Uma implementação correta deve atender a quatro condições observáveis: a validação da configuração do rsyslog deve retornar sucesso, o serviço deve permanecer ativo após a reinicialização, o coletor deve receber o evento de teste exclusivo e o log do remetente não deve apresentar erros de confiança TLS ou de nome do par. Após essas verificações serem aprovadas, documente as datas de expiração do certificado e a dependência do coletor remoto para que manutenções futuras não interrompam silenciosamente o registro centralizado.