Antecedentes : a agregação remota de logs é considerada uma maneira de melhorar a segurança. Geralmente, isso lida com o risco de que um invasor que comprometa um sistema possa editar ou excluir logs para frustrar a análise forense. Pesquisei opções de segurança em ferramentas de log comuns.
Mas algo parece errado. Não consigo ver como configurar qualquer um dos registradores remotos comuns (por exemplo, rsyslog, syslog-ng, logstash) para autenticar que uma mensagem recebida realmente se origina do suposto host. Sem algum tipo de restrição de política, um originador de log pode forjar mensagens em nome de outro originador de log.
O autor do rsyslog parece avisar sobre a autenticação de dados de log :
Uma última palavra de cautela: transport-tls protege a conexão entre o remetente e o destinatário. Ele não protege necessariamente contra ataques presentes na própria mensagem. Especialmente em um ambiente de retransmissão, a mensagem pode ter sido originada de um sistema malicioso, que colocou nomes de host inválidos e / ou outro conteúdo nele. Se não houver provisionamento para essas coisas, esses registros podem aparecer no repositório dos receptores. -transport-tls não protege contra isso (mas pode ajudar, se usado corretamente). Lembre-se de que o syslog-transport-tls fornece segurança salto a salto. Ele não fornece segurança de ponta a ponta e não autentica a mensagem em si (apenas o último remetente).
Portanto, a pergunta a seguir é: o que é uma configuração boa / prática (em qualquer ferramenta de log comum de sua escolha - rsyslog, syslog-ng, logstash etc.) que fornece alguma autenticidade?
Ou ... se ninguém autentica os dados do log, por que não ?
-
(Além: Ao discutir / comparando, ele pode ajudar a usar alguns diagramas ou terminologia de RFC 5424: Secção 4.1: Exemplos de situações de implantação - por exemplo, "remetente" vs "retransmissão" vs "colector")