1. 日志分析

1.1. 要调查安全问题，通常需要查看来自不同供应商和不同设备的多种日志

1.2. 一旦了解了如何读取日志，在多个供应商产品的日志之间切换就会变得更容

1.3. 许多工具可以自动执行日志聚合，例如SIEM（Security Information Event Management，安全信息和事件管理）解决方案

1.4. 很多时候这不是数量的问题而是质量的问题

1.5. 确保你拥有能够智能地采集和处理数据的工具，当需要进行手动调查时，你只需关注它已经过滤的内容

1.6. 在网络安全中没有万能的策略

1.7. 基础知识非常重要，因为它将帮助你快速吸收新的挑战经验，并应用安全原则来补救威胁

2. 数据关联

2.1. 大多数组织将使用某种SIEM解决方案将其所有日志集中到一个位置，并使用自定义查询语言在整个日志中进行搜索

2.2. 需要知道如何在不同的事件、日志和工件中穿梭，以执行更深入的调查

2.3. 从SIEM获得的数据有助于发现威胁、威胁行为者，以及缩小受威胁系统的范围

• 2.3.1. 需要找到根本原因并根除威胁

2.4. 每次执行数据分析时，重要的是要考虑如何将难解之谜的各部分结合起来

2.5. 工作方式

• 2.5.1. 调查人员开始检查操作系统日志中的危害迹象
• 2.5.2. 在此通信期间，发起了从外部网站到内部Web服务器的回调(callback)，那么需要查看Web服务器日志文件
• 2.5.3. 调查人员通过检查此Web服务器中的IIS日志来继续数据关联过程

2.6. 访问哪些日志、查找哪些信息，以及最重要的，如何在情景中查看所有这些数据，都存在一个逻辑

3. Windows日志

3.1. 在Windows操作系统中，最与安全相关的日志可以通过事件查看器访问

3.2. Windows\System32\winevt\Logs获取单个文件

3.3. 操作系统中的日志分析不一定局限于操作系统提供的日志信息，尤其是在Windows中

3.4. 在Windows 10中，还可以使用OneDrive日志(C:\Users\＜USERNAME＞\AppData\Local\Microsoft\OneDrive\logs)

3.5. 要解析Windows预读文件，Windows-Prefetch-Parser的Python脚本

3.6. Windows存储用户模式崩溃转储文件的位置

• 3.6.1. C:\Users\＜username＞\AppData\Local\CrashDumps
• 3.6.2. 崩溃转储文件是可用于识别系统中潜在恶意软件的重要资料
• 3.6.3. 在转储文件中暴露的一种常见攻击类型是代码注入攻击
• 3.6.3.1. 恶意软件主要使用此技术来访问数据，并隐藏自己或阻止被移除
• 3.6.3.2. 合法软件开发人员有时可能出于非恶意原因使用代码注入技术
• 3.6.4. WinDbg
• 3.6.4.1. 需要适当的技能来浏览转储文件以确定崩溃的根本原因
• 3.6.5. 即时在线崩溃分析
• 3.6.5.1. osronline
• 3.6.6. 将此日志（崩溃发生的当天）与事件查看器中提供的其他信息（安全和应用程序日志）相关联，以验证是否正在运行可能已获得此应用程序访问权限的可疑进程
• 3.6.6.1. 需要执行数据关联以获得有关特定事件及其罪魁祸首的更多有形信息

4. Linux日志

4.1. auth.log

• 4.1.1. 位于/var/log下
• 4.1.2. 包含所有与身份验证相关的事件
• 4.1.3. 注意调用root用户的事件，这主要是因为该用户不应该以如此高的频率使用
• 4.1.4. RedHat和CentOS将在/var/log/secure中存储类似的信息

4.2. 如果只想检查失败的登录尝试，请使用var/log/faillog中的日志

5. 防火墙日志

5.1. 防火墙日志的格式因供应商而异，但是无论使用哪种平台，都会有一些核心字段

• 5.1.1. 谁发起的通信（源IP）？
• 5.1.2. 该通信的目的地（目的地IP）在哪里？
• 5.1.3. 哪种类型的应用程序正在尝试到达目的地（传输协议和端口）？
• 5.1.4. 防火墙是允许还是拒绝该连接？

5.2. Check Point和NetScreen防火墙日志之间的一个重要区别是它们记录有关传输协议的信息的方式

5.3. 通过利用iptables将Linux计算机用作防火墙

• 5.3.1. iptables.log

5.4. 如果需要查看Windows防火墙，请查看C:\Windows\System32\LogFiles\Firewall处的pfirewall.log日志文件

5.5. 防火墙日志是收集有关传入和传出流量信息的好地方

6. Web服务器日志

6.1. Web服务器日志也可以提供有关用户活动的有价值的见解

6.2. 特别注意具有与SQL数据库交互的Web应用程序的Web服务器

6.3. IIS Web服务器日志文件位于\WINDOWS\system32\LogFiles\W3SVC1，它是可以使用记事本打开的.log文件

• 6.3.1. 使用Excel或Microsoft Log Parser打开此文件并执行基本查询
• 6.3.2. 在查看IIS日志时，请密切注意cs-uri-query和sc-status字段
• 6.3.3. 如果使用Log Parser，则可以针对日志文件执行查询，以快速确定系统是否遭受SQL注入攻击

6.4. Apache日志文件

• 6.4.1. 访问日志文件位于/var/log/apache2/access.log
• 6.4.2. 格式也非常易于阅读
• 6.4.2.1. 在Linux中使用cat命令
• 6.4.2.2. 使用apache-scalp工具

7. AWS日志

7.1. 如果资源位于AWS(Amazon Web Services)上，并且需要审核平台的整体活动，则需要启用AWS CloudTrail

• 7.1.1. 启用此功能后，AWS账户中发生的所有活动都将记录在CloudTrail事件中
• 7.1.2. 事件是可搜索的，并在AWS账户中保留90天

7.2. 如果使用Microsoft Sentinel作为SIEM平台，则可以使用Microsoft Sentinel的AWS Data Connector将以下日志以流的方式传输到Microsoft Sentinel工作区

• 7.2.1. Amazon Virtual Private Cloud(VPC)—产生的VPC流量日志
• 7.2.2. Amazon GuardDuty—威胁检测发现的安全日志
• 7.2.3. AWS CloudTrail—记录和监控服务生成的管理和数据事件日志

7.3. 使用Log Analytics KQL(Kusto Query Language)调查AWS CloudTrail日志

8. Azure Activity日志

8.1. Microsoft Azure还具有平台日志记录功能，能够可视化Azure中发生的订阅级别事件

• 8.1.1. 从Azure资源管理器(Azure Resource Manager，ARM)操作数据到服务运行状况事件更新
• 8.1.2. 日志也会存储90天，并且默认启用此日志

8.2. 如果使用Microsoft Sentinel作为SIEM平台，则可以使用原生Azure Activity日志连接器从Azure平台接收数据

8.3. 使用Log Analytics KQL调查Azure Activity日志

9. Google Cloud Platform日志

9.1. 谷歌云平台(Google Cloud Platform，GCP)是重要参与者

9.2. 问题

• 9.2.1. 谁做了什么？
• 9.2.2. 什么时候完成的？
• 9.2.3. 在哪里完成的？

9.3. 使用Microsoft Sentinel，你可以获取GCP身份和访问管理(Identity and Access Management，IAM)日志，它可以用来查看管理活动（审核日志），其中包括管理写(admin write)操作，以及数据访问(data access)审核日志，其中包括管理读(admin read)操作