TLS no encaminhamento do rsyslog com o driver gtls e quando vale a pena adicionar o RELP

O que é

O tutorial de TLS do rsyslog descreve drivers de stream de rede para o transporte criptografado de syslog: gtls (GnuTLS) e, desde o rsyslog 8.36, ossl (OpenSSL), que aceitam os mesmos parâmetros de modo e de modo de autenticação. Uma configuração mínima exige o certificado da CA nos dois lados, mais um certificado e uma chave no remetente e no receptor, organizados conforme o TLS Certificate Summary do rsyslog, que descreve o material X.509 necessário para cada papel. O arquivo da CA é definido de forma global (global(DefaultNetstreamDriverCAFile=...), além de DefaultNetstreamDriverCertFile/KeyFile). No lado do remetente, uma ação omfwd é estendida com StreamDriver="gtls", StreamDriverMode="1" (somente TLS) e StreamDriverAuthMode definido como x509/name (validação do certificado mais verificação do nome do par contra StreamDriverPermittedPeers="collector.example.org") ou x509/certvalid (qualquer certificado assinado pela CA confiável, modo que a documentação do driver considera fraco e não recomendado).

O RELP (Reliable Event Logging Protocol) é um transporte separado, fornecido pelos módulos omrelp/imrelp, descritos na documentação do rsyslog como os módulos de saída e de entrada do RELP. Diferentemente do omfwd simples sobre TCP ou TLS, o RELP confirma cada mensagem na camada de aplicação, de modo que o remetente sabe que a mensagem foi de fato processada pelo receptor, e não apenas aceita pela pilha TCP.

Por que importa

Um envio bem-sucedido por TCP simples significa apenas que os bytes foram entregues à pilha de rede. Se o rsyslog do coletor falhar ou o disco encher logo depois de aceitar a conexão, mensagens já "enviadas" podem ser perdidas sem que o remetente receba qualquer sinal. O TLS sobre TCP herda essa característica: a criptografia muda a confidencialidade e a autenticação, não a semântica de entrega. O RELP foi projetado justamente para eliminar essa lacuna.

Como aplicar

• Use TLS sempre que o tráfego de logs passar por uma rede que você não controla totalmente, mesmo dentro de um datacenter; prefira StreamDriverAuthMode="x509/name" com StreamDriverPermittedPeers indicando o nome do coletor, e trate x509/certvalid apenas como alternativa de contingência.
• Combine TLS com omrelp/imrelp (o próprio RELP pode rodar sobre TLS) quando a perda de mensagens durante uma falha do receptor for inaceitável, como em logs de auditoria e eventos relevantes para conformidade, e a complexidade adicional de um par de módulos extra nas duas pontas for aceitável.
• Para logs comuns de aplicações ou do sistema, nos quais a perda ocasional de uma mensagem durante uma falha é tolerável, TLS sobre TCP simples com uma fila assistida por disco no remetente costuma ser suficiente.
• Monitore a expiração dos certificados: desde o rsyslog 8.2012.0, StreamDriver.PermitExpiredCerts tem o padrão off, de modo que um certificado expirado faz o handshake TLS falhar; o encaminhamento para (os erros aparecem no log do próprio rsyslog) e as mensagens se acumulam na fila.

Armadilhas

• Deixar StreamDriverAuthMode sem definir (o padrão no omfwd depende do driver) ou usar anon, que, segundo a documentação do driver, não autentica o par e fica exposto a ataques man-in-the-middle.
• Supor que o TLS sozinho garante a entrega; ele não garante, e o RELP é a resposta documentada para essa lacuna específica.
• Esquecer que o RELP precisa de uma porta própria e de uma regra de firewall distinta da porta usada para syslog simples sobre TCP/TLS.