日志管理与分析（五）–规划自己的日志分析系统

首发安全脉搏：https://www.secpulse.com/archives/110826.html

对广大IT工作者，尤其是运维和安全人员来说，“日志”是一个再熟悉不过的名词。

作为一名合格的安全人员，了解日志的概念，了解日志的配置和分析方法，是发现威胁、抵御攻击的重要技能，有了这方面的深刻认识，各种自动化安全解决方案才能真正地发挥效能。在前面的文章中，分别总结了

日志的来源与收集：https://www.secpulse.com/archives/110283.html

日志的分析工具及报告：https://www.secpulse.com/archives/110423.html

对日志系统的攻击：https://www.secpulse.com/archives/110454.html

PCI DSS以及ISO27001标准的日志的管理规程：https://www.secpulse.com/archives/110612.html

如果你打算购买一个商业化系统，本章介绍的内容一般由你的供应商处理。但是，你必须参与项目中的每个步骤，你要让供应商满足你的需求，是没有取巧的路可走的。如果你需要部署开源解决方案，本章也能给你提供些帮助。当然，哪些方案适合，取决于你在过程中所处的位置。不管你选择何种途径，在许多情况下都可以使用本章提供的指南。

题主并不是日志分析专家，只是借着学习后的总结分享出来，每个人在不同时机看的东西不一样，欢迎指正~

侯亮大神曾说：知识的最高的境界是分享，而在我看来，我们在分享的同时也是对自我认知的一个提升。

01

规划自己的日志分析系统

除了确定产品或者服务之外，你还需要理解产品的具体需求。

• 你应该考虑的因素有：能够定义精确并说明系统如何使用的场景。例如，作为用户，我想要提取一个报告，告诉我过去24小时windows服务器上的登录失败次数。

• 驱动因素:是什么驱动你启动这一项目，必要性还是政府法规或者其他目的？了解有助于为此分配的时间、金钱和资源。

• 解决的问题：部署一个日志分析系统能帮助你解决哪些问题？举个例子，你收集的信息类型，日志分析系统能够帮你进行简单的服务器或网络监控。

• 安全和依从性：这样的产品是否帮助你向审计人员、监管人员证明依从性？

1.1.1角色和职责

首先必须确定所有角色和职责，在项目规划和实施阶段，应该包含哪些人。这项功能帮助你了解到，企业中的哪些人可能是日志分析系统的用户。例如，程序员是日志记录系统的用户，因为他们编写的应用程序必须创建日志消息，用于诊断和故障排除目的。

表中是常见角色和职责的一个摘要：

角色	职责
日志分析系统管理员	做为这一角色，负责系统的维护和保养。这包括安装软件更新，配置日志收集器和其他任务。另一个任务是与组织的其他成员一起工作，理解他们对分析系统的需求。换言之，如何帮助其他人从系统中得到价值。
业务/产品负责人	对产品、特性集、应用程序负有责任的个人或者群体。这一群体通常对日志记录有自己的需求，但是他们可能不知道（或者不需要知道）有一个分析系统。帮助其他人了解自身需求的责任可能落在你的身上。
安全团队	安全团队通常负责配置安全设备上的日志记录，确保组织的安全态势
IT/开发经理	将日志记录标准做为影响整个组织的“必备”功能
IT支持团队/管理员/网络操作人员	该团队支持生产应用程序；他们可能有在应用程序表现异常时读取和分析日志文件的用例。
软件开发人员/程序员	通过使用库、API和日志记录功能、遵循日志记录标准。在开发人员需要跟踪应用程序问题等时候，日志分析系统对他们也很有用
事故响应团队	事故响应团队被视为日志分析系统的客户，他们将在事故响应和升级期间使用收集的日志
内部/外部审计人员	根据所在企业的业务类型，你可能必须应对审计人员。审计人员通常需要验证你正在收集某类日志，以便确定和各种法规的依从性。

 

1.1.2资源

资源可以帮助理解企业关于日志记录的需求，以及日志记录对环境的影响。规划阶段，你可以向自己提出这样的问题：

1. 你的现有员工，哪些人能够进行日志分析和监控？

2. 你的现有员工，哪些人能够进行日志分析系统的管理？

3. 你是24*7运营、只在规定时间内运营，还是混合模式？

4. 你是否需要构建一个安全运营中心（SOC），或者拥有一个虚拟SOC？虚拟SOC团队不是不间断地坐在那里一直盯着屏幕，而是使用警报来驱动响应、工作流等。

5. 你对事故响应有何计划？

6. 你在日志分析系统的构建上有何种预算？

7. 你在长期运行和维护系统（硬件升级、网络升级、人员升级等）上有何种预算？

   
   

对这些问题的回答，有助于更好地理解项目和最终实施所需要的资源。如果你计划建立24*7的运营中心，需要考虑如下因素：

1. 你需要雇佣新员工，还是合理安排内部员工？

2. 你的办公室里是否有场所可以安置24*7运营中心？

3. 你的电力容量是否足以供应24*7中心？

4. 你是否有预算购买运营所需的硬件和软件？

5. 你的事故响应和升级规程是怎么样的？

6. 你负责生成哪些类型报告（例如交给管理层的报告）

1.1.3目标

在项目的筹划期、进行期和后期，设置目标都很关键。目标可以帮助你知道自己的进度，甚至有些目标可能是标志着项目可交付成果的里程碑。下面是一组日志分析系统规划中的目标和里程碑。

• 目标1--规划之前

• 目标2--利益相关方确认

• 目标3--需求收集

• 里程碑1--项目规划建设

• 目标4--日志分析工具评估

• 目标5--日志分析工具选择

• 目标6--硬件需求收集

• 里程碑2--硬件和软件采购

• 目标7--软件部署

• 目标8--构建运营中心

• 目标9--为运营中心配备人员

• 目标10--定义事故响应和升级规程

• 里程碑3--资产投产

1.1.4选择日志记录的系统和设备

规划过程中有一个关键的点是，确定用于评估和选择日志记录的系统和设备的可重复性过程。其中有种方法是为设备指定一个关键程度。例如，防火墙的关键程度高于工作站。下面是选择日志数据源过程的一个示例：

1. 关键性：你必须理解日志数据源对环境的关键性。它是企业中主要的Web服务器吗？它是包含公司机密的关键研究与开发服务器吗？遭到入侵就会威胁你的生存的系统应该排名靠前。不同的日志源也可能对你的企业有不同的关键性。例如，DNS服务器关键性可能低于信贷处理服务器。

2. 验证：一旦识别了数据源，你必须召集利益相关方，验证这个数据源确实是关键资产，需要纳入日志分析系统。

3. 事故响应：最后，你需要围绕指定日志数据源遭到入侵时，事故处理和响应如何进行，确立一个工作流。发生事故时，你必须联系谁？在遭到入侵的主服务器上进行调查时，该系统有没有热备份供你进行故障切换？

选择日志分析系统时，对于开源、商业化或者托管服务有不同的考虑。

1.2.1开源软件

日志分析的开源选项多种多样，研究这些工具时更重要的一些考虑因素：

1. 更新频率：社区和核心开发团队对该项目是否进场投入？如果你在几个月或者更长的时间没有看到活动数据，这可能是一个衰亡的项目。

2. 成本：有人会说，开源意味着“免费”。这bu一定，开源项目可能以多种形式给你带来成本。你一般需要花费更多的精力去获得、学习和部署开源解决方案。

3. 许可证：开源应用程序与何种许可证发行，往往值得注意。它所使用的许可证可能会限制部署软件的方式，甚至规定你的定制软件和该工具集成的方式。

4. 支持：许多开源工具提供你可以购买的支持合同，包括电子邮件支持和其他特性。有些工具甚至在工具的“免费”版本之外，提供增强的付费版本。增强版本通常有某种程度的支持。

5. 功能：确保你完全理解该工具能做和不能做的事情。如果你首先定义需求，就能更好地评估日志分析工具。

6. 文档：显而易见。如果应用程序只有一个README文本文件作为文档，就一般不会是一个好的方案。

7. 社区：有时候是关键的特性。你肯定希望了解开源工具是否有某种社区的支持。社区一般以留言板的形式推送，你可以在那里获得该应用程序的帮助和支持。

8. 可扩展性：如果你希望扩展日志分析系统（可能采用自定义脚本、程序等），就可能需要了解平台的可扩展性。它有没有API和其他集成点？如果平台支持这种扩展，在出现问题时有谁来支持？

9. 功能：需要考虑和研究的功能包括：

• 支持的日志获取方式（syslog、原始文件、Checkpoint的OPSECAPI等）

• 是否易于维护和保养（例如，是否容易添加新设备源的支持？）

• 关联（是否支持基于规则、统计等）

• 报告（有哪些现成的报告，是否容易创建新的报告？）

1.2.2商业化软件

在软件业的许多不同的细分市场中，商业化软件总是与企业级解决方案联系在一起。这种关联依然没错，但在日志记录和日志分析中“细节是魔鬼”。在考虑商业化日志分析系统时，一定需要考虑：

1. 成本：最基础的考虑因素。商业化日志分析系统根据网络的大小、计划留存的数据等各不相同。

2. 支持模式：商业化解决方案的支持是确保你从平台中获得最大价值的关键。你必须了解支持模式的各个方面，了解它与你的业务需求（如正常运行时间、周转时间等）是否保持一致。

3. 专业服务：大部分商业化供应商提供某种专业服务，帮助你安装和设置软件。这通常需要额外付费，换言之，它不是免费的。

4. 可扩展性：和开源软件类似，你应该确定产品的可扩展性。

托管安全性服务提供商（MSSP）

MSSP为构建和部署自己的日志分析提供了一个替代品。其吸引力主要来自组织，不需要担心人员的招聘和培训，软硬件的部署和维护以及其他琐事。MSSP的明显好处之一是，它们有训练有素、经过认证的分析人员。这对于没有同样专业性的客户来说是巨大的优势。研究MSSP时需要考虑的一个因素如下：

1. 功能：需要研究的MSSP功能不同于现场日志分析系统。以前提到的大部分功能都由MSSP维护，所以更应该关心的功能包括客户门户的实用性。该门户是你用于搜索日志消息、运行报告、响应事故和工作单等的主要界面。

2. 分析和事故响应：需要考虑的因素之一，是MSSP如何进行分析和事故响应。你的关键业务必须确保MSSP与你的目标相一致。

3. 专业服务：MSSP提供的专业服务，特别是需要现场事故响应的时候起到很重要的作用。这些服务通常需要附件成本，超出了常规服务的费用。

4. 数据保存：确保你理解日志数据保存的时间。你可能必须符合与保存相关的某些监管原则。你可能需要至少一年，甚至更久。

5. 云日志：之后我们会详细介绍云日志的主题。基本要点是，提供者在其数据中心提供一个环境，你可以将日志转发给它们。这种方法不需要在现场有特殊的硬件。这对于某些组织可能很立项，但是对其他组织就不一定了。不同的依从性和法规可能禁止某些组织以这种方式运营。

6. 服务水平协议：MSSP提供服务水平协议。在MSSP的环境中，SLA规定了分析、事故响应和升级的低限和高限，通常在你签署的合同中列明。

7. 使用数据以保护数据：因为MSSP监控大量客户的安全性，在某个客户检测到威胁和入侵时，创建保护并应用到所有客户。这是所有客户都能获益的强大工具。

 

策略定义处理一组规程的创建，你将把这些规程作为例行程序的一部分。下面将简单描述较为常用和必要的策略，需要在规划日志分析系统时加以考虑。定期和经常审核你的策略，以确保它们与组织的需求和需要一致，也是很关键的。

1.3.1 日志记录策略

最直接的关注点是，为组织定义一个日志记录策略。日志记录策略包括：

• 覆盖日志事件类型（登录/注销、资源、防火墙接受/拒绝、ips/ids警报等）和细节的足够日志记录。

• 日志聚合和保存（1年等）。

• 日志保护（确保日志不被篡改）。

• 日志审核

日志记录策略，定义日志数据应该捕捉哪些属性供以后审核、升级和响应。日志记录策略还需要扩展到应用程序。例如，如果你有定制的应用程序，有必要和应用程序利益相关方一起定义哪些信息应该记录，并使之可用于日志记录系统。

1.3.2 日志文件轮转

日志文件轮转是另一个需要定义的策略。随着你所监控的日志文件的增加，本地系统上的磁盘会被堆满。磁盘满时，应用程序可能就无法正常运行。甚至让你丢失关键的日志数据。所以，可以按照如下方法，开发一个全组织的日志文件轮转策略：

• 基于时间：根据时间范围轮转日志文件，也就是说，按照分钟、小时等。

• 最大化实用性：这里的关键是使系统对用户有用。需要采取平衡的措施：轮转的日志需要保留足够长的时间以确保其实用性，同时又不能影响整个系统。

• 及时转移到长期存储：这里的思路是，日志保留在源系统上的时间长度要足以用于审核。根据系统的繁忙程度，这一时间大概是几小时。

1.3.3 日志数据收集

数据收集是日志分析系统中最重要的部分。没有这一功能，你就无法用日志分析系统实现目标。首先，应该了解环境中哪些设备应该配置为生成日志数据。举个例子，你的激光打印机能够生成日志数据，但这并不意味着你会捕获它。日志数据收集的策略需要根据环境进行调整，比方说，你可能只需从外部防火墙和IDSIPS系统中获取日志消息，也可能需要收集来自网络中每个防火墙、IPS、服务器和桌面电脑的日志记录。但无论如何，你应该确保每3至6个月审核这个策略，确保组织的需求与你的数据收集策略相符。

1.3.4 保存/存储

日志的保存是许多法规的要求，我们知道的日志保存，实际上由三部分组成：日志存储、可访问性和日志销毁。强调，绝不要用syslog服务器作为日志保存系统。同时还要注意的是如何确定保存所需的存储容量。

我们并不一定要采用大型服务器和磁盘列阵。你所选择的日志分析解决方案可能支持分布式存储模型，在这种模型下，接收日志数据的系统节点也可能作为保存点。在评估日志分析系统的时候，也要记得考虑这一点。

1.3.5 响应

下一篇文章将会详细介绍事故响应，本次暂不更新。

日志分析系统分部署很大程度上取决于网络的规模，以及你从网络的哪些部分收集日志。

1. 基本模型

2. 日志服务器和日志收集器

3. 日志服务器和具有长期存储的日志收集器

4. 分布式部署

1.4.1 基本模型

基本部署模型是你可以使用的最简单模式。它由单个日志服务器组成，多个设备向其发送日志。

如图，在这种模型下，你可以将日志记录到日志服务器，以进行日志审核。这当然不是最理想的情况，但是在条件不足的情况下或许是最佳的选择。

1.4.2 日志服务器和日志收集器

较常见的一种部署模式是将日志收集器分布到网络中有战略意义的位置。这些系统从他们所在的设备中收集日志。这些日志收集器可能是网络中的特殊部分（可能是一个入口点），你应该确保捕捉防火墙日志。日志收集器将把日志转发到集中日志服务器。

图中，通过日志收集器向日志服务器发送日志。且需要注意，日志服务器本身也可以作为日志收集器。根据你所选择的日志分析系统，这种部署的配置细节将是特定于供应商的。日志服务器作为审核日志、分析日志等工作的集中位置。日志收集器可以看作日志的临时备份，但是不能完全信赖。

1.4.3 日志服务器和具备长期存储的日志收集器

在这个模型中，我们可以添加长期存储

日志服务器写入某种长期存储。同样，配置是供应商特定的。

具有长期存储的基本日志服务器部署

1.4.4 分布式部署

你使用分布在整个环境中的日志收集器收集日志，这些日志收集器会将日志汇聚到一个或者多个日志服务器。在层次化模型中，你可以让多个日志服务器将日志积累到一个集中日志服务器，提供环境的视图。在日志服务器级别进行自动化分析的情况下，考虑分布式分析方案，这样可以减少单一服务器完成这种任务的需求，减少了服务器负载并缓解该单一故障点。

扩展是日志分析系统管理额重要部分。下面是用于协助的一些通用技巧。

1. 了解你的环境。为了扩展，你需要掌握进出网络的设备。确保你和利益相关方举行每周会议，审核部署新设备的计划。确保你的分析系统中包含合适的设备日志记录，对于最大化这种部署的实用性是至关重要的。

2. 确定你知道网络中的哪些日志数据更为优先。举例，防火墙日志可能比来自打印机的日志更重要。

3. 理解环境何时饱和。在日志审核中，如果你注意到日志数据是几个小时前的，就可能碰到了问题。如果你采用分布式部署，应该调查日志收集器和日志服务器，看看为什么它们落在后面。为什么服务器有很高的CPU负载？它遇到了I/O问题吗？这些情况都是数据容量增加的信号。这可能是恶意活动的特征，也可能你需要引入新的日志收集器，将日志数据转移到新的服务器。

 

上面介绍了规划、策略定义、软件选择、部署和扩展。这些都是选择和部署一个日志分析系统的方法和原因的重要部分。

本文始发于微信公众号（LemonSec）：日志管理与分析（五）–规划自己的日志分析系统