OSSEC是一个很棒的FOSS HIDS，它可以很好地减少您需要签出的日志事件数量，使其成为可能管理的对象。

它支持您提到的所有日志源：http : //www.ossec.net/main/supported-systems

我们构建了一个内部应用程序，使我们能够快速“每日检查” OSSEC 在一天内发出的所有警报；我们通常只需不到 20 分钟的时间就可以宣布一切就绪或启动事件调查。对于一种环境，我们每天会收到约 70,000 个 OSSEC 警报，但大多数警报/事件是身份验证事件集群或向日志系统发送垃圾邮件的应用程序错误，例如：

既然你有 Splunk，你可以进行 Splunk + OSSEC 集成： http ://www.ossec.net/main/splunk-ossec-integration

前几天，我看到几个企业 SIEM 正在运行——我惊讶地发现他们显然没有详细说明异常或罕见日志事件的罐头报告。不寻常和罕见的事件通常是坏事的最佳指标，可以作为你追踪的事件的简短列表，直到线索变冷。

我们还使用Logwatch作为辅助日志分析器。

此功能通常在 SIM 或 SIEM 解决方案的帮助下实现。这些 CA、ArcSight、Loglogic、splunk 等有几个流行的供应商。

您可以收集日志、了解警报并根据规则的相关性采取行动。您可以从所有可能的来源、数据库、Unix、Windows、防火墙等收集日志。

方法通常因规模和位置而异，例如，企业的外围日志记录对于内部警报团队来说通常太多了，因此这通常外包给托管服务供应商之一，然后他们将传递相关警报。

对于较小的组织或特定主机日志记录，问题更易于管理，但是您仍然需要查看如何训练和调整警报过程。Splunk 和其他人将完成这项工作，但您需要计划在最初几周内需要照顾的资源量，对记录的环境进行任何升级或更改，攻击配置文件的任何更改，实际上是持续超过时间。

除此之外，通常的机制是同时使用基于签名和统计警报 - 签名速度很快，并且可以由服务提供商更新，因此需要很少的努力，但是需要创建它们，因此通常不会识别新的攻击类型，而统计警报会响应日志记录中的任何变化 - 因此，在您调整之前，您最终可能会因误报而超载。

从安全的角度来看（还有很多其他的事情值得检查日志），那么日志只会可靠地显示安全性按预期工作的位置。如果有人绕过了安全措施，那么日志可能不会检测到它/日志可能会受到损害-因此它们的用途有限。

此外，如果您可以构建机制来分析日志中的潜在违规行为，那么在大多数情况下，执行策略与等待违规发生一样容易。

日志分析不能替代基于主机的文件完整性检查器（例如 Lids、tripwire）

话虽如此，我建议在适当的情况下使用fail2ban。