日志记录和日志分析对于保护基础架构至关重要，尤其是当我们考虑常见漏洞时。本文基于我在FOSDEM'19的LightningShow《 Let's use centralized log collection to make incident response teams happy 》，目的是提高对日志缺失安全问题的认识，提供一种规避风险的方法，提倡更多的安全实践（利益声明：我工作对于NXLog）。为什么要收集日志？为什么要集中记录？相反，日志是写入磁盘的仅追加记录序列。在现实生活中，日志可以帮助您在尝试查找异常源时调查基础架构问题。当您有多个异构系统使用自己的日志和自己的标准和格式时，挑战就来了，并且您想要一种可靠的方式来接收和处理它们。这通常是以元数据为代价的。集中式日志记录解决方案需要通用性，而这种通用性通常会剥夺许多开源日志记录工具提供的丰富元数据。日志记录和监控不充分的安全风险开放Web应用程序安全项目(OWASP)是一个非营利组织，为行业贡献了许多杰出的项目，包括许多专注于软件安全的工具。OWASP定期报告应用程序开发人员和维护人员面临的最危险的安全挑战。在最新版本《 10 项最严重的 Web 应用程序安全风险 》中，OWASP将日志记录和监控添加到列表中。OWASP警告以下情况会导致不良的日志记录、检测、监控和主动响应：重要的可审计性事件，例如登录、登录失败和大量事务未被记录。警告和错误事件无法生成，生成的日志信息不充分或不清晰。日志信息仅存储在本地。对于实时或近实时的主动攻击，应用程序无法检测、处理和报警。这可以通过集中日志记录（例如，不仅在本地存储日志）和构建日志数据以供进一步分析（例如，在警报仪表板和安全套件中）来缓解。例如，假设DNS查询指向一个名为hacked.badsite.net的恶意网站。通过DNS监控，管理员可以监控并主动分析DNS请求和响应。DNS监控的有效性依赖于足够的日志记录和收集来识别潜在问题，以及结构化DNS日志的结果以供进一步分析。2019-01-29Time(GMT)SourceDestinationProtocol-Info12:42:42.112898SOURCE_IPxxx.xx.xx.xDNSStandardquery0x1de7Ahacked.badsite.net您可以在NXLog社区版中自己尝试这个示例，以及其他示例和代码片段。（再次：我为NXLog工作）要点：非结构化数据与结构化数据花点时间考虑日志数据格式很重要。例如，让我们考虑以下日志消息：debug1:FailedpasswordforinvaliduseramyfromSOURCE_IPportSOURCE_PORTssh2此日志包含预定义的结构，例如元数据键(debug1)前面的冒号但是，其余日志字段是非结构化字符串（FailedpasswordforinvaliduseramyfromSOURCE_IP端口SOURCE_PORTssh2）。因此，即使消息采用人类可以轻松阅读的格式，也不是计算机可以轻松解析的格式。非结构化事件数据具有局限性，包括难以解析、搜索和分析日志。重要的元数据通常以自由字符串的形式作为非结构化数据字段，如上例所示。日志管理员在尝试标准化/规范化日志数据和集中日志源时遇到了这个问题。下一步做什么确保除了集中式和结构化日志之外还收集了正确的日志数据-Sysmon、PowerShell、Windows事件日志、DNS调试日志、ETW、内核监控、文件完整性监控、数据库日志、外部云日志等。选择合适的工具和流程来收集、总结和帮助理解数据。希望这能为您提供一个从不同日志源集中收集日志的起点：将日志发送到仪表板、监控软件、分析软件和外部源，如安全信息和事件管理(SIEM)套件。
