背景:远程日志聚合被视为一种提高安全性的方法。通常,这可以解决入侵系统的攻击者可以编辑或删除日志以阻止取证分析的风险。我一直在研究常见日志工具中的安全选项。
但感觉有些不对劲。我看不出如何配置任何常见的远程记录器(例如 rsyslog、syslog-ng、logstash)来验证传入消息是否真正来自所谓的主机。如果没有某种策略约束,一个日志发起者可以代表另一个日志发起者伪造消息。
rsyslog 的作者似乎警告有关验证日志数据:
最后要提醒一句:transport-tls 保护发送者和接收者之间的连接。它不一定能防止消息本身存在的攻击。特别是在中继环境中,消息可能来自恶意系统,该系统将无效的主机名和/或其他内容放入其中。如果没有针对此类情况的配置,这些记录可能会出现在接收者的存储库中。-transport-tls 无法防止这种情况(但如果使用得当,它可能有帮助)。请记住,syslog-transport-tls 提供逐跳安全性。它不提供端到端安全性,也不会验证消息本身(仅验证最后一个发送者)。
所以后续的问题是:什么是好的/实用的配置(在您选择的任何常见日志工具中 - rsyslog,syslog-ng,logstash等)可以提供一定程度的真实性?
或者...如果没有人验证日志数据,那么为什么不?
--
(补充:在讨论/比较时,使用一些图表或术语可能会有帮助RFC 5424:第 4.1 节:示例部署场景——例如“发起者”与“中继者”与“收集者”)
答案1
这是一个很好的问题。
我使用 logstash 来完成类似您提议的事情。使用 logstash(或 logstash-forwarder)将日志发送到您的中央收集系统,添加 logstash 配置以向消息添加关键字段,其值是每个服务器独有的长随机字符串。
然后在接收端,您可以添加相应的规则来丢弃(或警告)特定主机的密钥与您期望的主机名不匹配的任何消息。
这并不是万无一失的,但这是朝着正确方向迈出的坚实一步。
答案2
正确的做法是使用带有机器客户端证书的 TLS。
rsyslog 自 2008 年左右开始这样做,并且有很好的说明:http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html
该过程非常简单,如下所示:
- 设置 CA
- 向所有需要记录日志的计算机颁发证书
- 配置 rsyslog 以使用该身份验证
然后,您的计算机就无法互相冒充,并且没有您的证书,任何人都无法登录到您的日志服务器。
我看到你已经发现了这一点,但你仍然担心他们的警告。我不会太担心这个。日志注入当然是一回事,但它有很多种,包括通过应用程序注入和注入日志记录过程。如果有人对您的应用程序软件进行日志注入攻击,经过身份验证的 rsyslog 将无法保护您,但没有什么可以保护您;只有修复应用程序才能解决这个问题。这只会保护您免受伪造日志的侵害。
其它注意事项可以通过不使用中继轻松缓解,但实际上这样做没什么道理。如果您没有中继,并且对 rsyslog 服务器中的 gtls 连接驱动程序使用 x509/name 选项,则应该不会遇到麻烦。
另请参阅 gtls 配置文档:http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html