Logrotate是一款Linux平台中用于管理日志的工具，它可以实现定期轮换、打包和删除日志文件。结合syslog服务，一些安全成本有限的企业可以自行建设日志存储服务器。在我们的威胁分析师职业生涯中，可能会遇到使用logrotate管理的日志文件。

而许多安全建设成熟度较高的企业已经开始使用SIEM系统（如splunk、ArcSight等）作为其日志管理仓库。SIEM的全称是Security Information and Event Management（安全信息和事件管理系统）。SIEM系统通常可以提供利用正则、分类导航的方式快速对日志进行检索的功能。更高级的SIEM系统允许分析师编写规则对威胁行为进行检测并能够产出安全告警。

具体使用商业软件还是开源软件，取决于安全建设的预算。如果预算充足，那么建设SIEM平台还需要考虑要采集哪些日志？这些日志会占用多少存储空间？这些日志要存储多久等问题。根据国内的情况，大部分企业都需要将日志存储超过180天以上以满足合规要求。然而这样造成了一种两极分化的情况，暴发户一样的企业无脑地将所有日志都存储在SIEM系统中，导致搜索速度和平台稳定性都越来越差。而承担不了大集群的企业则只保留了安全设备产生的告警日志。

从以往的经验看，如果是阻断类的安全设备产生的阻断告警日志，存储30天以上是比较正常的。而像HTTP请求、DNS请求、TLS握手数据、TCP会话数据每天的日志量巨大，在采集这些日志时我们就应该识别一些正常业务产生的日志直接过滤不进行存储，剩下的日志可以用于威胁狩猎使用，最好能够保留90天以上。

网络安全威胁情报，正如我们多次提到的那样，是关于攻击组织在网络空间中采取入侵行动的情报。除非您在某些政府情报部门工作，否则这意味着CTI是关于攻击组织在其他网络和系统上进行未经授权的入侵行为的信息，以及对其进行某种目的的攻击行为。这就是威胁情报的来源，而您最有价值的情报将是证明攻击组织正在对您的网络和系统进行入侵的证据。在现代入侵事件应急响应中，威胁情报分析师需要收集整个入侵事件中的数据，并对其进行分析，通常入侵事件的数据是由应急响应人员完成的，随着CTI的不断发展，应急响应和威胁情报分析的界限会越来越模糊。

现在让我们通过一个案例来学习情报分析的流程。某一天，身为Edison公司威胁分析师的你收到了来自FBI的一封邮件，他们声称你的企业网络中某些计算机与一个C2服务器IP建立了网络连接，需要进行排查。

这是很常见的外部通报，邮件中除了C2服务器的IP，未提供任何其他有价值的信息。一般情况下如果我们能够与通报方建立联系，在收到通报后就应该立刻联系他们以获取更多细节。

如果除IP地址外，我们没有其他信息，那回顾一下CoA模型，在发现阶段我们可以通过日志回溯。这个时候选择恰当的日志数据源就成为了首要任务。幸好，你的组织已经收集了NetFlow日志留存，我们可以在Netflow日志中进行回溯。

netflow数据通常来自于汇聚层或核心层的网络设备，有些组织也会使用argus服务器接收来自TAP交换机传送的流量并转换成netflow日志进行存储。AAS自动化分析系统通常以互联网出口设备的日志为数据源进行分析。

现在，我们通过申请授权，已经拿到了当前网络中最近7天的netflow日志，他们是网络工程师收集和整理的，每个gz包以24小时的范围进行打包。我们可以直接使用argus工具分析这些压缩包内的数据。我们在日志中搜索通报中的C2服务器IP，发现10.0.0.11这个内网IP与C2服务器IP发生过通信行为。根据目的端口80，我们假设这个C2服务器的恶意载荷是以HTTP协议作为隧道进行通信的。从时间上看，每小时的第18分钟和第25分钟会发起连接。从经验证看可能是恶意软件的心跳通信机制，或者恶意软件创建系统计划任务规律性执行。

• -nnn参数关闭了IP地址逆向解析，否则argus会展示IP地址对应的域名信息

• -r参数指定需要读取的文件

使用nslookup命令，我们发现这个源IP其实是网络内部的代理服务器。那么综合我们现在已有的信息分析，存在以下两种可能（为了容易表达，这里使用了C2服务器IP这个名词，但实际上我们其实还无法确信这个情报是准确的）：

• 一种是代理服务器被植入了恶意软件，这个恶意软件可能创建了2个进程或计划任务，周期性与C2服务器IP进行通信。

• 另一种可能是内网有2台主机被植入了恶意软件，而这台主机需要通过代理服务器才能访问互联网。并且一台主机上的恶意软件是某小时第18分钟启动的，每1小时进行心跳通信，另一台主机的恶意软件是某小时的第25分钟启动的，每1小时进行心跳通信。

那现在影响这两种可能性的关键点就在于代理服务器，据你了解，Edison公司使用Squid作为代理服务器，且在互联网出口限制只有Squid代理服务器的源IP能够访问互联网的80端口，因此内网的终端想访问互联网必须在本机配置代理。这是一种防御恶意软件使用非正常端口进行通信的有效措施，然而很多企业没能这样做。

按照合规要求，Edison公司必须留存1年的代理服务器日志，现在你申请到了最近一周的代理服务器日志。Squid是一款流行的开源缓存代理服务器，具有高度可配置的日志格式和易于扩展的功能，不仅仅限于简单的缓存和HTTP优化。Squid的日志以每个HTTP事务终止时的每行文本记录的形式存储。

现在我们在与netflow日志同一时间的Squid日志中搜索C2服务器IP的信息，我们发现在同一时刻，是内网的两台主机在请求C2服务器IP的HTTP资源，这也印证了我们之前猜想的第二种可能。

注：截图中对URL地址进行了缩略展示，完整的URL是

http://89.34.237.11/fjerk/afx,jsp?v1=UHgE/1tmeuonBGaXJOBt+HpZM8BkRHfhRxCE/yANZZcqBWPuIXVhnlUPbdx+XiPHhttp://89.34.237.11/fjerk/r712.asp?param=VnkQ/T51G5cjBAb+Ig0Axn1TONhgFxn7M2OHnCkEb+pSdmCfVOZlmCUNPC53WDKP

关于Squid服务器日志格式配置，可参考：https://wiki.squid-cache.org/Features/LogFormat

关于HTTP的响应码，可参考：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

现在我们使用之前提到过的杀伤链、钻石模型和CoA矩阵对已有数据进行整理。我们已经知道有2台内网主机在外联攻击者的C2服务器基础设施，这已经属于远程控制阶段。我们也通过CoA的发现Discovery验证了C2服务器IP的情报，

有没有发现，除了C2服务器IP信息，还有URL这个关键特征我们没有用到，我们在查看代理日志中发现2台内网主机请求C2服务器的HTTP URL是不完全相同的，我们提取他们的共同之处，那就是URI：/fjerk。基于这个URI，我们扩展了已有的情报，继续进行CoA中的发现Discovery步骤。

在代理日志中检索关键字"/fjerk"，我们发现还有一个URL类似但目的IP不同的访问行为，来自内网主机192.168.12.4。这样我们不仅扩展了通报中的情报信息，并且发现了新的疑似失陷的内网主机。

至此我们从通报中的C2服务器IP成功发现了一些可能存在问题的内网主机，我们来观察一下这个过程中情报的生命周期。首先我们从外部通告中得到了一个IoC：89.23.237.11，我们使用这个IoC在netflow日志和squid日志进行检索，定位到了疑似失陷的内网主机，此时情报进入成熟状态（Mature），我们通过检索出的URL，提取到新的特征"/fjerk/"，扩展了已经掌握的情报并再次进行检索，此时情报为工具化状态（Utilized），通过扩展的IoC，我们又发现了新的C2服务器IP：104.224.166.148，这个新的IoC重新回归初始纰漏状态（Revealed），我们需要再使用这个IoC进行检索，以便发现新的失陷主机。