TG咨询刚接触入侵检测与日志审计时，很多人会先安装一个安全工具，再把所有规则调到最高敏感度。但这样做往往带来两种结果：真正重要的事件被大量噪声淹没，或者日志根本没有保存到可供分析的位置。更稳妥的做法，是先明确保护对象、记录关键行为，再逐步增加检测范围。
误区一：装上工具就等于完成防护
入侵检测与日志审计依赖完整的数据来源。只安装主机代理，却没有收集登录、权限变更、进程启动和文件修改记录，检测能力仍然有限。例如，Linux服务器上的OpenSSH登录失败通常写入认证日志，Windows则可在“Windows日志—安全”中查看登录成功、失败和权限使用事件。两者的事件编号、字段和保存位置都不同，不能直接套用同一套规则。
更稳妥的做法
- 列出需要保护的主机、数据库和管理入口。
- 确认每类对象实际产生哪些日志，并记录保存路径、格式和时区。
- 先采集登录、账户、权限、进程和配置变更，再补充访问日志。
- 用一次测试登录、一次权限变更验证日志是否能被检索。
如果使用syslog集中转发，应同时检查网络连通性、转发端口、消息时间和接收端落盘情况。只显示“连接正常”并不代表事件已经完整保存。
误区二：把所有异常都当成入侵
入侵检测与日志审计的目标不是让告警数量越多越好。短时间内出现大量登录失败，可能是密码喷洒，也可能是管理员输错密码、自动化任务使用旧凭据，甚至是资产扫描。判断时至少要结合来源地址、目标账户、发生时间、后续是否登录成功，以及该账户是否执行了高风险操作。
例如，来自同一地址的多个账户失败后又成功登录，并紧接着执行提权或修改SSH配置，风险明显高于单个账户的两次失败。相反，来自公司出口地址的少量失败，且没有后续异常行为，可以先降级处理。规则应同时考虑次数、时间窗口、对象范围和行为结果，而不是只设置一个固定阈值。
误区三：只盯着单条日志，忽略事件链
单条日志通常只能说明“发生了什么”，不能说明“是否构成威胁”。入侵检测与日志审计更有价值的分析单位是事件链：例如账户登录成功、执行新的Shell进程、读取敏感目录、建立异常外联，多个动作在较短时间内连续出现，才需要优先调查。
可以使用SIEM关联不同主机和系统的事件；资源有限时，也可以先按主机、账户、源地址和时间排序，人工拼接上下文。Wazuh等主机安全平台能够结合规则进行检测，但规则仍需要根据实际资产调整。没有数据库的服务器，不必启用针对数据库审计的高噪声规则。
误区四：忽略时间同步，导致调查顺序错误
日志时间相差几分钟，甚至时区配置不一致，可能让一条攻击链看起来颠倒。入侵检测与日志审计开始前，应统一服务器和日志平台的时区显示，并使用可信的NTP时间源。排查时同时记录原始时间、接收时间和平台解析时间，避免把网络延迟误认为行为间隔。
可执行的检查步骤如下：
- 在Linux上查看系统时间、时区和时间同步状态。
- 在Windows上确认系统时间、时区及域环境的时间同步情况。
- 让测试主机生成一条已知事件，比较源端与平台显示的时间。
- 发现偏差后先修正时间，再重新分析相关告警。
误区五：告警发出后没有处置闭环
没有责任人、等级和验证步骤的告警，只会变成通知噪声。建议为高风险事件规定处理动作：先确认受影响主机和账户，再保留相关日志，必要时隔离主机或暂停账户，最后核查是否存在持久化配置和数据访问。
日志保留时间也应按用途区分。实时检索数据可保留数周，归档数据则视合规要求、磁盘容量和调查需求决定；涉及登录、权限和关键配置的记录，不宜因短期节省空间而立即删除。审计平台本身还要限制管理员权限，并记录谁查看、导出或删除了日志。
新手可采用的最小落地方案
- 选择少量关键主机，先覆盖账户登录、权限变化、进程启动和配置修改。
- 统一时间、主机命名和日志字段，保证后续可以关联。
- 设置少量高价值规则，例如异常来源登录成功后立即提权。
- 安排定期演练，验证告警是否能被发现、确认、处置和复盘。
- 根据误报原因调整规则，而不是单纯关闭告警。
真正有效的入侵检测与日志审计应当让事件可见、证据可查、责任可追踪。完成基础闭环后，再扩展到应用、数据库和云平台日志，通常比一开始全面铺开更容易维护。
常见问题
日志越多越安全吗？
不一定。无关日志过多会增加存储成本和误报，优先保证身份、权限、进程、配置和关键数据访问记录完整。
小型服务器需要部署SIEM吗？
不一定。主机数量较少时，可先使用集中日志、明确的检索规则和定期复核；当来源增多、需要跨主机关联时，再考虑SIEM。
发现异常登录后应立即删掉账户吗？
先保留证据并确认是否为误报。对高风险账户可临时禁用或限制访问，同时保留登录、命令和权限变化记录，避免破坏调查线索。
多久检查一次规则？
新系统上线、权限结构变化或出现误报时应及时检查；没有明显变化时，也建议至少按季度复核一次。
