收集安全日志

正确选择公司的安全日志管理工具
公司在法规遵从方面的要求越来越严格，对安全日志的管理需求也越来越高，许多系统管理员都在寻找一种能高效管理安全日志的方法。安全日志在加强一致性、检测违反策略行为方面有很大的帮助。即使对于那些在这方面要求不高的公司来说，安全日志仍然是一种检测违反安全策略行为、黑客入侵行为最好的方法。Windows事件日志提供了全面的安全日志记录功能，但如何管理多个系统的日志常常是一个令系统管理员头疼的问题。
针对这个难题出现了许多解决方案。其中很多方案都是面向大型企业设计的，通常很贵；还有一些稍微便宜一些，适用于一些中小企业（Small-to-Midsized Business，SMB）。幸运的是，有一些免费工具可以填补这个缺口。
我们首先来看看有哪些标准可以用来评估并选择一个安全日志管理工具。我也会介绍一些免费或低价的安全日志管理工具，并演练一些安全日志管理最佳实践。

评估管理安全日志的需求
在开始测试安全日志管理工具之前，应该花一些时间考虑公司在安全日志数据收集方面的需求。可以按照以下5个主要步骤进行分析，得出安全日志数据收集的需求。这个过程中我会给出一些标准，通过这些标准可以判断哪个收集工具最适合我们的要求。

第1步：找出感兴趣的安全事件数据。Windows和其它系统会生成大量的安全数据。通常默认会记录日志的行为有：认证和授权操作的结果，例如用户登录和注销行为；对受限站点页面的访问；以及数据库和Internet访问等等。请考虑一下哪些数据是你真正需要的。你需要所有认证和授权相关的数据呢，还是只对失败的操作感兴趣？你需要所有登录和注销事件（例如，交互式、网络、服务、批处理）的数据呢，还是仅仅需要交互式登录的数据？
在这一步中，我建议大家以一种高级别而不是特定的方式进行思考——例如，考虑“失败的用户认证”，而不是“对Windows XP专业版桌面失败的交互式登录”——这样可以降低遗漏数据源的可能性。如果你并不能确定哪些安全事件数据是真正需要的，可以向业务决策者和其他人员寻求帮助，例如内部法律顾问或审计组，找出那些可以帮助提高一致性或发现违反策略的数据。

第2步：找出可用的安全日志及其格式。你可能会在环境中找到比原来想象更多的安全日志。对于初学者来说，每个Windows系统中都有一个事件日志。在UNIX和Linux系统中，很可能有一个名为Messages的文件（或类似的），这个文件包含了安全信息。微软IIS和IAS（Internet Authentication Service，Internet认证服务）也会生成包含安全信息的日志文件。这些日志可以以多种方式存储，包括文本、各种数据库兼容格式。可以使用MMC（微软管理控制台）的IIS和IAS管理单元来配置服务使用的日志格式。总的来说，使用文本文件格式更容易进行信息的搜索。
防火墙、无线接入点（AP）、路由和其它类似的设备，通常都会生成安全日志数据。如果通过这些设备直接向主机发送安全日志数据——与在主机上运行服务不同——要注意你使用的协议，确保日志管理系统能支持这些协议。这些设备使用的协议可能是syslog（或它的变种）或SNMP。还应该记录潜在资源的安全日志数据，即使在当前情况下这些数据不可用。例如，Web服务器或数据库可能会生成安全日志数据，即便我们没有对它们进行配置。

第3步：将最需要的安全数据和它的特定资源进行映射。如果需要通过管理安全日志来找到潜在的攻击行为（失败的认证尝试），那就要将提供这些数据的每个数据源都列出来。在这一步里还可能需要排除掉一些数据源。例如，如果你决定要在森林或域中记录用户登录和注销的活动，你应该在Windows安全事件日志中记录所有Windows XP和Windows Server系统的所有活动。或者，如果每个人都有一个域帐号，每个系统都是域的成员，并且资源都是集中管理的，你应该只在主要服务器和域控制器（Domain Controller，DC）上记录登录和注销的活动。
将高级别的数据需求和某些能提供这些数据的日志机事件映射起来。这一步可能是最复杂的，因为需要大家理解每个日志中哪些数据是有用的。

第4步：区分安全日志和事件平台。区分包含安全事件数据的安全日志和数据源所在的平台。大多数业务环境都是混合的，由很多系统组成，包括Windows、UNIX、Linux、Cisco系统，以及网络传输硬件和软件，例如，计数器、工作站以及服务器等等。对于每个平台，判断是否存在有用的安全日志，如果这些平台没有用SNMP、syslog或其它协议来生成日志，你需要确认你选择的日志管理方案能否在这些平台上正常运行。

第5步：决定你使用数据的方法。你要对安全数据进行实时分析呢——可能使用安全事件管理工具——还是仅仅先收集这些数据，稍后或仅在特别需要时再进行分析呢？如果存在多个系统，每个系统都运行了不同的OS并有一个安全日志，你可能会需要一个工具来收集所有这些数据，并对每个系统的日志进行配置和管理。
确定你需要哪些安全日志数据，这包括：日志在环境中的什么地方，需要如何处理日志。这之后将这些信息汇总到一张表中，如表1所示。这张表可以在我们评估使用何种安全日志收集工具时帮助我们进行决策，选择正确的产品来满足我们的要求：收集需要的事件，以恰当的格式导出，以便进行实时或批处理分析。

表1：安全日志数据收集

在选择管理工具之前，还有其它4个与安全日志和数据无关的问题。安全日志可能包含敏感信息，因此第一个问题是：在收集和传输数据时是否需要加密日志数据？第二个问题是：访问数据源时是否需要认证。如果数据源没有经过认证，攻击者可能以匿名的方式进行Dos攻击（Denial of Service，拒绝服务），或者至少可以使用伪造数据干扰系统，使得我们在寻找真实数据或所需的数据时就必须排除这些干扰，加大搜索数据的难度。第三个问题是：工具自身是否需要向中央收集服务器组件进行认证，以及服务器是否需要向工具进行认证？双向认证和加密技术的组合，可以保证工具向合法的服务器提供收集到的日志——日志中可能包含敏感信息——并且在传输过程中不会被人侦听。
最后，问问自己在传输和存储时是否有必要提供安全日志集成功能？如果无法保证数据的集成，那可能达不到外审人员的要求，或无法在法庭上使用。最好让这两个问题的答案都变成肯定的。

安全日志管理工具
现在有了标准，我们就可以开始评估管理工具了。有几款不错的工具可以下载来使用，它们或者是免费的，或者价格很低。我建议大家在选定工具并部署到生产环境之前，用它们分别在测试环境下进行试验。

提到安全日志管理工具，就不能不说syslog。它是UNIX系统中的一款日志收集工具，syslog从UNIX和Linux主机和应用（例如防火墙和路由）中捕获安全日志数据，但它和其它UNIX管理工具一样，有许多安全问题，包括缺少机密性、集成性和实用性。同样也有Windows版本的syslog。
RFC 3195为syslog定义了一种更新的标准，大家可以访问以下地址：http://www.ietf.org/rfc/rfc3195.txt。（RFC，Request for Comments，即请求注解，包含了关于Internet的几乎所有重要的文字资料。如果你想成为网络方面的专家，那么RFC无疑是最重要也是最经常需要用到的资料之一，所以RFC享有网络知识圣经之美誉。译者注。）还有一些其它被提议的扩展和标准，包括San Diego超级计算机中心（SDSC）Secure Syslog（http://security.sdsc.edu/software/sdscsyslog）和BalaBit IT Security的syslogng（http://www.balabit.com/products/syslog_ng）。所有这些扩展和标准的设计都是为了弥补原始syslog的缺陷。在选择产品时，你需要了解这些标准之间的差异，判断它们是否真正是与syslog兼容的。

如果你安装了微软的MOM 2005（Microsoft Operations Manager）（包括MOM 2005工作组版），那么你已经有了一个syslog服务器。你可以创建一个syslog数据提供者，通过它来创建和配置一个规则组，将syslog消息记录到MOM操作控制台。不幸的是，MOM 2005只支持经典的syslog，即存在安全问题的syslog。如果你可以等的话，即将到来的MOM新版本——MOM System Center 2007（目前还是Beta 2），将拥有Audit Collection特性（之前被称为Audit Collection System），它可以帮助我们加强Windows系统中用于集中分析的安全事件日志的安全性。
如果你没有MOM，或者你需要一个更高级别的安全性，你可以选择一款免费的syslog服务器产品，名为Kiwi Enterprises Syslog Daemon for Windows，可以在以下地址下载：http://www.kiwisyslog.com。它还有一个零售版，零售版拥有更多功能。Syslog Daemon允许syslog代理通过TCP或UDP进行连接，而原始的syslog则只能使用UDP。不管是免费版还是授权版，Syslog Daemon都没有解决syslog的安全性问题，所以syslog数据在网络中都是以明文传输的。但你可以使用Kiwi安全通道（Kiwi Secure Tunnel）来加密那些向syslog服务器传输的数据，不过免费版的软件只允许同时使用一个安全通道。

如果你需要从UNIX和Linux主机及应用（例如防火墙和路由）中捕获安全日志数据，那么在环境中部署一个syslog服务器非常不错，不过它无法从IIS和IAS日志、服务器和应用生成的安全日志、Windows安全事件日志中收集数据。一种解决方案是部署代理，由代理来收集这些安全日志数据源，并将它们中转到一个中央syslog服务器中。LogLogic的Project Lasso（http://www.loglogic.com/logforge/#）能捕获Windows安全事件日志和几种其它Windows事件日志。Project Lasso使用syslog-ng协议将安全日志数据发送到中央日志服务器。
Syslogng并不提供客户端或服务器端认证或加密，但它使用TCP而不是UDP在网络中传输消息（如果你需要加密通信或添加认证，可以使用第三方工具或IPsec）。
另外一款不错的基于syslog的工具是InterSect Alliance的System iNtrusion Analysis and Reporting Environment（SNARE），可以在以下地址下载：http://www.intersectalliance.com/projects/index.html。SNARE支持多种平台和应用，包括Windows、Microsoft ISA Server、IIS、Apache、IBM Lotus Notes，以及许多UNIX和Linux系统。支持这么多的平台使得SNARE部署起来非常容易，SNARE的远程管理特性更提高了它的易用性。SNARE同样也使用代理来收集日志，并将日志汇总到服务器。不过，SNARE使用的是经典的syslog，仍然会产生我前面描述的安全问题，可能不适用于你的环境。
微软提供了一款名为Event-CombMT的工具，用以收集和集中分析Windows安全事件日志。另外一款流行的Windows事件日志工具是Log-Parser。新的Windows PowerShell提供了Get-EventLog命令行工具集。
在将来的文章中，我会介绍一些比免费工具提供更多特性的产品，这些产品比较适合中小企业（SMB）使用。

评论：Syslog是一种工业标准协议，可用来记录设备的日志。在UNIX系统，路由器、交换机等网络设备中，系统日志（System Log）记录系统中任何时间发生的大小事件。管理员可以通过查看系统记录，随时掌握系统状况。UNIX的系统日志是通过syslogd这个进程记录系统有关事件记录，也可以记录应用程序的运作事件。通过适当的配置，还可以实现运行syslog协议的机器间通信，通过分析这些网络行为日志，可以追踪掌握与设备和网络有关的问题和状况。
Syslog协议提供了一种传递方式，允许一个设备通过网络把事件信息传递给事件信息接收者（也称之为日志服务器）。由于每个进程、应用程序和操作系统都或多或少地被独立完成，在syslog信息内容会有一些不一致的地方。因此，协议中并没有任何关于信息的格式或内容的假设。这个协议就是简单地被设计用于传送事件信息，但是内容是否已经接收到不会被通知。Syslog协议和进程最基本原则就是简单，在协议的发送者和接收者之间不要求有严格的相互协调。事实上，syslog信息的传递可以在接收器没有被配置甚至没有接收器的情况下开始。反过来，在没有被清晰配置或者定义的情况下，接收器也可以接收到信息。（译者）

最佳实践
不管你选择哪种安全日志管理方案，以下的一些最佳实践可以尽可能地保证所管理的安全日志数据是有用的。

首先，要保证日志的存储安全。我建议使用一个专门的服务器，并限制该服务器的交互式登录和网络登录。

第二，保证每个会生成安全日志的系统上的时钟与一个可靠的时钟源进行同步。这个问题有很多种解决方案供选择，从最贵的（专门的时间服务器，它通过无线电与相关的时钟进行同步）到最便宜的（使用一个程序，从基于Internet的网络时间协议——Network Time Protocol，NTP——服务器进行同步，例如time.windows.com）。如果系统时钟没有进行同步，要将各个系统的事件进行关联会非常困难甚至是不可能的。

第三，经常检查你所做的决定是否全面，收集的安全日志数据是否足以满足安全策略需求。同样，无论何时你重新配置了环境，或向环境中添加了新的配置，要考虑这个改变与安全日志管理策略是否存在冲突。

第四，计算出收集日志数据所需要的存储空间。需要计算出每天收集数据的大小，以及需要将这些数据保留多久。如果在保存期中你要遵守一致性需求，可能会有将日志备份到长期存储媒介中的需求，例如磁带或CD-R光盘，并清除掉那些不再需要实时在线的旧日志。要考虑到最坏的情况，保证安全日志数据不会由于存储问题而不小心丢失。
最后，要定期检查你的日志收集系统，保证日志的收集是正常的。创建一系列测试，生成一些有代表性的安全日志数据，然后通过这些数据来检验日志的收集和管理过程是否正常。如果等到出现安全问题之后再去查询收集得来的日志，来判断发生了什么问题，结果发现这些日志并没有被正确收集而丢失了，没有比这更糕的情况了。
如果你选择了一种基于经典syslog的安全日志管理工具，我建议在监视服务器和中央日志服务器间创建一个单独的网络。可以使用物理或虚拟网络。这个网络上传输的数据仅仅是那些和管理相关的，安全日志管理通信应该仅限于这个网络中。这些实践可以解决潜在的机密性和实用性问题（但不能解决完整性问题）。
美国国家标准和技术学会（National Institute of Standards and Technology，NIST）——美国商务部（US Department of Commerce）的一部分——最近发布了NIST特殊公告800-92的草案，“计算机安全日志管理指南”（Guide to Computer Security Log Management）。在指南中能找到一些我上面描述的最佳实践。尽管指南是为联邦机构使用而设计的，你仍然可以在自己的公司中使用指南和800系列中的其它特殊公告。
可以访问以下地址获取这个指南：http://csrc.nist.gov。