网络安全尤其强调可审计性，因此，网络运营者必须认真实施日志保留6个月这一被《网络安全法》所规定的法律义务。
笔者一直在强调合法依规执行日志收集和留存工作的重要性和关键性，比如在《网络安全日志收集甲方基础实践》中就重点强调了日志留存的要求。
本文涉及知识点包括：Syslog 日志收储服务、Windows 操作系统、事件查看器、组策略、注册表等。
在网络安全等级保护测评要求中，提出了很多必须要设置的日志输出和留存要求。
在笔者的角度认为，被测评的单位除了按等保测评具体要求设置Windows服务器的日志输出和留存之外，还应该更全面地设置日志输出，实现最大的可审计性，充分做到履职尽责，不留死角。
但由于 Windows 的事件日志有自己独有的体系，不兼容 Syslog 协议，无法简单地直接发送给基于 Syslog 协议实现的日志集中收储管理服务去接收、存储。
所以具体到 Windows 服务器操作系统的系统日志如何确保合规留存，值得反复探讨和找出最佳实践。
一、需要保留哪些日志
日志留存首先要解决的是如何在服务器本机留存充足的事件日志信息，这是日志留存实践的底线。
Windows 系统中很多日志输出设置默认是关闭的，部分可以通过相关功能的设置操作开启，另一些则只能通过组策略开启。从设置的可靠性而言，能用组策略去开启的就应该通过组策略去开启设置。
1、审核策略和高级审核策略配置
无论是等保测评或是CIS安全措施，组策略中的审核策略都是必须的开启的。审核策略也有两类设置，另一类称为高级审核策略配置。高级审核策略配置的选项会覆盖之前的审核策略，所以不需要两者都设置，且一般建议设置高级审核策略配置。
每一分类下均有若干个具体审核事件设置：
这些设置如果全部开启，有可能导致事件日志泛滥，这取决于服务器上运行的后台服务软件情况。需要进行观察并在发生泛滥时适当关闭部分审核策略。
2、高级安全 Windows Defender 防火墙日志的设置
开启防火墙日志设置是CIS安全措施所建议的，而对于等保测评则没有明确要求。防火墙日志也可能导致事件日志泛滥，也同样需要观察决定如何开启。
需要注意的是日志设置的具体文件名。每一项日志设置在开启时都会给出同一个日志文件名，从最佳实践角度，应修改日志文件名加上对应的配置文件范围。比如对于专用配置文件，就在文件名上加上private：
3、管理模版中的日志选项
在随后的管理模版中存在大量的日志选项，基本上可以通过筛选功能直接筛选出来：
列出筛选内容后，按实际需要决定设置哪些项目。鉴于每一项都有说明，这里就不一一介绍了。
从经验而言，建议对涉及用户、防火墙、浏览器的日志项目都开启，并顺道检查一下相关的其他设置是否也要开启。
完成配置后，可以通过复制组策略配置文件或者使用secedit命令导出组策略设置的方式进行备份，而且也可直接用于其它服务器的设置，减少工作量。采取文件复制备份时，组策略配置文件位于：
C:WindowsSystem32GroupPolicy
secedit用于备份组策略设置的方法网络上有介绍，这里就不重复了。
4、IIS日志
IIS的日志需要在安装IIS服务时勾选相关的角色服务：
随后，通过IIS管理器的日志功能进行配置：
可以选择对服务器或网站进行记录，并可选记录格式等设置：
从以上设置可见IIS的WEB日志和Windows本身的事件日志完全是两回事。另外，IIS日志默认就是按天滚动，并且长期保留：
所以在IIS日志的处置上反而是要考虑如何定期清理超过保留时长不再需要的日志。一般都是通过写定期清理的批处理脚本通过任务计划程序每天运行一次。
5、开机引导日志
这个设置比较特殊，位于“系统配置”功能的“引导”页面：
勾选后，Windows就会在启动期间对加载的驱动程序进行记录，日志文件位于：
c:windowsntbtlog.txt
该选项还可以通过命令行工具bcdedit.exe进行开启和关闭，命令及参数如下：
bcdedit /set {current} bootlog Yes或No
其中的{current}是标识符的默认情况，可以通过不加参数运行bcdedit查看：
二、如何保证本机留存日志的时长
1、通过事件日志查看器配置主要日志属性
在之前的基础实践中，我们已经知道Windows操作系统在事件日志的属性配置界面上，只提供了以空间和文件数量为条件的日志滚动设置，没有提供按时间为条件的日志滚动，例如如下的典型设置界面。
启动事件日志查看器。通过查看器，可以修改事件日志的保留设置。
重点是设置其中的“应用程序”、“安全”和“系统”这3个事件日志分类的保留设置。
一律设置日志的最大大小为允许的最大值，并且在日志满时存档不覆盖。
不过，这样的设置结果是系统管理员必须定期进行检查、转移或清理日志，否则很可能会日志泛滥而导致存储空间耗尽，服务器挂起。
2、使用组策略安全协议扩展配置按天滚动主要日志
如果计算机加入了域，组策略安全协议扩展提供了事件日志按天滚动覆盖的设置（扩展配置：AuditLogRetentionPeriod和RetentionDays），但这些设置不会在本地策略中显示，对没有加入域的计算机无效。
系统管理员可以按要求的格式编写日志滚动策略配置文件并通过命令行工具secedit.exe配置。
网上有不少的Windows安全基线配置教程，都包括了这一设定。下面的内容是生成配置文件和应用的脚本，保存为随意名字的cmd脚本后执行即可：
@echo off
echo [version] >logcfg.inf
echo signature="$CHICAGO$" >>logcfg.inf
REM 设置系统日志
echo [System Log] >>logcfg.inf
REM 设置系统日志文件最大8192KB，允许范围自64到4194240。
echo MaximumLogSize=8192 >>logcfg.inf
REM 设置按天滚动
echo AuditLogRetentionPeriod=1 >>logcfg.inf
REM 设置滚动天数
echo RetentionDays=180 >>logcfg.inf
REM 设置限制GUEST访问应
echo RestrictGuestAccess=1 >>logcfg.inf
REM 设置安全日志
echo [Security Log] >>logcfg.inf
REM 设置安全日志文件最大8192KB，允许范围自64到4194240。
echo MaximumLogSize=8192 >>logcfg.inf
REM 设置按天滚动
echo AuditLogRetentionPeriod=1 >>logcfg.inf
REM 设置滚动天数
echo RetentionDays=180 >>logcfg.inf
REM 设置限制GUEST访问安全日志
echo RestrictGuestAccess=1 >>logcfg.inf
REM 设置应用程序日志
echo [Application Log] >>logcfg.inf
REM 设置应用程序日志文件最大8192KB，允许范围自64到4194240。
echo MaximumLogSize=8192 >>logcfg.inf
REM 设置按天滚动
echo AuditLogRetentionPeriod=1 >>logcfg.inf
REM 设置滚动天数
echo RetentionDays=180 >>logcfg.inf
REM 设置限制GUEST访问应用程序日志
echo RestrictGuestAccess=1 >>logcfg.inf
REM 应用设置
secedit /configure /db logcfg.sdb /cfg logcfg.inf /log logcfg.log
REM 删除设置文件
del logcfg.inf
其中要注意的是，日志文件的最大大小应能容纳1天内产生的日志，否则达到上限时就会丢弃新事件，所以这也少不了有个观察过程，又或者干脆设置一个更大的值。
执行过程很简单，比如保存为logaudit.cmd，在管理员权限下成功执行时的输出如下：
可以用如下的secedit命令导出设置进行检查：
secedit /export /db logcfg.sdb /cfg logcfg_export.inf /areas SECURITYPOLICY /log logcfg_export.log
命令执行后产生logcfg_export.inf配置文件和logcfg_export.log导出过程记录文件，可以检查其中的内容判断设置是否有效。
如果懂编写批处理，可以把批处理最后的删除操作注释掉，把inf文件保留下来，复制到系统或用户的安全模版目录，然后就可以用管理控制台mmc添加安全模版功能后打开模版查看，大致如下，这里也不详细说了：
系统模版位置：
C:WINDOWSSECURITYTEMPLATES
用户模版位置：
C:Users用户名DocumentsSecurityTemplates
打开后查看：
说明内容还是很详细的：
3、其它日志
对于归类到“应用程序和服务日志”大类下的其它细分类型的事件日志按自己需要进行设置即可。比如服务器启用了IIS，那就应该对应地启用IIS相关日志。这些日志大部分的产生量都很少，所以默认的保留设置都可以保留很久，注意还是要以观察结果为准。
三、如何发送日志到独立的 Syslog 日志存储管理服务
只是本机存储肯定是不足够的，但对于Windows服务器来说，重点是需要找到独立第三方、允许用户自行配置的系统日志收集代理程序，这样可以从根本上解决收集什么日志和如何转换格式的问题，才能和自己配置的Syslog日志存储服务器对接实现日志转储。
免费或者开源的支持Windows服务器操作系统的日志收集代理工具并不多，而且很多都已经多年没更新。经过多番寻找和测试，发现NXLog Community Edition （社区版）这个日志收集器是个可以用的工具，下载地址在：
https://nxlog.co/downloads/nxlog-ce#nxlog-community-edition
该社区版工具基于 NXLog Public License （https://nxlog.co/nxlog-public-license）也就是该公司自己制订的开源许可证发行，其主要内容和常见开源许可证没有什么明显不同，对于普通用户来说，重点就是可商用。
软件不仅支持从Windows的事件日志采集信息，还能支持从其它日志源采集并格式化形成日志；不仅能把信息转化为syslog日志，还支持输出为CSV，W3C，GELF，JSON，XML以及KVP等格式，也可以直接保存为自有的二进制格式，可以方便地和各种日志存储服务或者SIEM平台对接。
工具安装包的安装过程是非常简单，安装完之后并没有提供配置界面并且会立即启动其后台服务。由于按软件的文档指引，需要系统管理员去手工修改软件的配置文件，所以我们要先停了nxlog服务：
配置文件在安装目录的conf目录中，比如：
C:Program Filesnxlogconfnxlog.conf
配置文件的格式是apache conf格式，如下图：
如果安装时选择了自定义安装目录，则需要在修改配置文件中的ROOT目录定义，比如安装到C盘根目录的nxlog目录下，就要如下修改定义：
define ROOT C:nxlog
从熟悉Windows操作系统目录结构体系的系统管理员角度看，该软件的配置文件和日志文本输出默认都放在安装目录下的子目录内的设计是不适合的。按我自己的习惯，会作如下修改：
1、配置文件、缓存文件等运行期间可能会修改的文件应该放在C:ProgramData内的子目录下
2、日志文本输出应该在C盘之外的分区建立专门的存放目录
配置文件默认是没有启用任何输入输出，需要取消掉相应的注释行从而启用输入输出模块，这在配置文件的最后有个EXAMPLE段落，取消注释后如下图：
完成配置文件的修改后，重新启动nxlog服务，然后就可以在Syslog日志服务器的一端用WireShark抓包观察有无接收到nxlog日志收集器发送过来的日志信息，抓包时可以使用过滤表达式排除干扰：
host nxlog日志收集器的IP地址 and udp and port 514
正常情况下就能观察到发送过来的日志信息了：
确认Windows系统事件日志的转储有效后，还可以进一步地考虑Windows系统内的其它日志是否需要通过该收集器转储，比如在前面提到的防火墙日志和IIS日志，这些日志内容都是以文本日志方式直接存储的。安全管理员和系统管理员可以根据nxlog的文档指引，协同确定和配置要收集的日志：
https://docs.nxlog.co/userguide/index.html
https://docs.nxlog.co/ce/current
四、购买使用专门设计的日志存储产品
最后简单介绍一下专门的日志存储产品。
对于预算充足的甲方，一般可以选择采购专用的日志存储管理设备。此类设备本质上依然是基于Syslog协议实现日志收集，并提供了对日志内容的查询和分析功能。
由于Windows事件日志信息不能直接按Syslog协议格式发送给日志存储管理设备接收，因此，此类设备都会提供一个厂家自行设计的日志收集代理程序。该程序需要安装在Windows服务器上，以后台任务方式运行，自动监控Windows事件日志的产生，并将新增的日志信息在转换为Syslog格式后，按设定的网络配置发送给日志存储管理设备集中保存。
这个解决办法实施起来比较简单，采购、安装、运行三部曲奏完就基本没别的事可干了。但需要指出的是，厂家的日志收集代理程序是有选择地收集日志的。其所收集的具体日志分类、事件级别是否能由用户控制，取决于日志收集代理程序的设计是否有为用户提供配置功能。
如果我们需要100%无差别地收集所有的Windows事件日志，又或者需要按自己的实际情况有针对性地收集特定事件日志的话，这个方法不一定能实现。
原创文章，作者：guozi，如若转载，请注明出处：https://www.sudun.com/ask/89809.html
