浅析红蓝对抗中攻击方基础设施的日志聚合和监控
导语：本文的作者将站在攻击方的角度，阐述用于攻击的基础设施的日志聚合和监控方案，目的在于能够在红蓝对抗中更好更快的对防御方做出反应。
在红蓝对抗中，已经证明，监控我们用于攻击所使用的基础设施与我们所实施的攻击一样重要。在防御方开始调查时快速隐藏攻击方意味着可以保持我们的交互式命令和控制（C2）会话与销毁我们的基础设施之间的差异。如果你已经阅读过史蒂夫和我写的红队基础设施Wiki文档，那么你就知道我们是热衷于使用大量分布式基础架构的忠实粉丝，并且在任何方面我们都会使用到重定向器。当我们拥有包含基础设施的资产多于20个时，监控就变得越来越困难。幸运的是，这个问题在很久以前就可以用rsyslog解决了。在这篇文章中，我们将介绍如何使用rsyslog监视分布式的攻击基础架构，来帮助我们实现更快的反应动作。
设计方案
Rsyslog遵循服务器/客户端架构。我们将配置专用的主机作为rsyslog服务器，接收日志信息并解析日志获取有意义的事件。我们的团队服务器和Web服务器将充当客户端并将其日志转发到日志服务器。
可以将Rsyslog配置为从许多不同的程序转发日志。实质上，如果工具能够输出有规律的格式化日志，则可以通过rsyslog将数据记录到中央服务器。在这篇文章中，我们将专注于使用Apache日志来说明这个概念。
这是攻防实验室的设置：
实验室设置
TLS设计注意事项
默认情况下，rsyslog是以明文协议传输的; 但是，它也支持SSL / TLS加密。使用TLS配置本文所描述的监控设置需要执行其他步骤，包括需要在转发日志的每个主机上生成计算机证书。你实际操作的设置步骤可能需要增加一些复杂性，也可能不需要。
以下是需要考虑的几个因素：
· 传输的数据有多敏感？只是web流量吗？
· 关于目标的任何元数据都不应泄露？
· 资产的生命周期如何？每次基础架构发布时，重新配置TLS可能是一项重大工作。
· 你能编写部署脚本吗？
· 如果日志记录服务器被黑客发现，你是否预料到这些攻击者可能会尝试发送虚假的日志内容？
有关使用TLS设置rsyslog的更多信息，请查看官方文档。
使用Syslog聚合日志
对于rsyslog的设置说明，Gary Rogers 的GitHub中有详细的介绍。本文中提供的步骤也是基于Gary的博文内容，但要满足我们的需求需要做一些修改。每个主机都需要设置; 日志服务器接收日志并且客户端（即我们的有效载荷服务器和Cobalt Strike团队服务器）将日志发送到日志记录服务器。在实际的操作设置中，日志记录服务器应独立于任何攻击基础架构，并且应充分加强防护以防止日志被篡改。
日志记录服务器设置
任何安装了rsyslog的*nix主机都可以使用此设置，但是本文的演示中，我们使用的是Debian 9主机。
默认情况下，rsyslog通过UDP发送消息。为了降低日志消息在传输过程中丢失的可能性，我们将在我们的设置中使用TCP来作为传输协议。这需要在端口514上启用TCP，并将下面这行内容添加到/etc/rsyslog.conf 文件中：
$ModLoad imtcp $InputTCPServerRun 514
接下来，我们需要设置在本地主机上采集访问和错误日志。将下面这行添加到同一个文件的底部：
local3.* /var/log/apache2/combined_error.log local4.* /var/log/apache2/combined_access.log
重新启动服务让应用更改生效：
service rsyslog restart
创建文件/var/log/apache2/combined_access.log和/var/log/apache2/combined_error.log。确保rsyslog可以写入文件。
日志记录客户端安装程序
在配置主机时，需要设置每个客户端。重定向器和有效载荷服务器的设置步骤与Cobalt Strike团队服务器的步骤略有不同。
有效载荷日志记录客户端
创建/etc/rsyslog.d/apache.conf文件并插入以下文本：
# Default Apache Error Log $InputFileName /var/log/apache2/error.log $InputFileTag apache-error-default: $InputFileStateFile stat-apache-error $InputFileSeverity info $InputFileFacility local3 $InputRunFileMonitor # Default Apache Access Log $InputFileName /var/log/apache2/access.log $InputFileTag apache-access-default: $InputFileStateFile stat-apache-access $InputFileSeverity info $InputFileFacility local4 $InputRunFileMonitor $InputFilePollInterval 1
如果你使用的不是基于Debian的发行版系统，则第4行和第12行会有所不同。这两行应该分别指向Apache错误和访问日志。
修改/etc/rsyslog.conf文件，并将以下文本添加到文件的底部：
$WorkDirectory /var/lib/rsyslog # where to place spool files $ActionQueueFileName fwdRule1 # unique name prefix for spool files $ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) $ActionQueueSaveOnShutdown on # save messages to disk on shutdown $ActionQueueType LinkedList # run asynchronously $ActionResumeRetryCount -1 # infinite retries if host is down local3.* @@192.168.10.11 #replace with rsyslog server local4.* @@192.168.10.11 #replace with rsyslog server
将最后两行的IP地址修改为你的rsyslog服务器的IP。
重启服务：
service rsyslog restart
Cobalt Strike团队服务器日志记录客户端
要将Cobalt Strike团队服务器的weblog活动日志发送到我们的rsyslog服务器，我们需要使用Aggressor这个脚本将weblog中命中的数据大致格式化为与Apache默认日志格式相匹配的日志文件。使用agscript在你的团队服务器上执行此脚本：
./agscript syslog-monitor /path/to/apache-style-weblog-output.cna
创建/etc/rsyslog.d/cobalt.conf文件并插入以下文本：
# Default Cobalt Web Log $InputFileName /var/log/cobaltstrike/weblog.log $InputFileTag cobalt-strike-weblog-default: $InputFileStateFile stat-apache-access $InputFileSeverity info $InputFileFacility local4 $InputRunFileMonitor $InputFilePollInterval 1
修改/etc/rsyslog.conf文件，并将以下文本添加到文件的底部：
$WorkDirectory /var/lib/rsyslog # where to place spool files $ActionQueueFileName fwdRule1 # unique name prefix for spool files $ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) $ActionQueueSaveOnShutdown on # save messages to disk on shutdown $ActionQueueType LinkedList # run asynchronously $ActionResumeRetryCount -1 # infinite retries if host is down local4.* @@192.168.10.11 #replace with rsyslog server
将第4行的日志路径修改为你的团队服务器上的weblog.log路径，并将最后一行的IP地址修改为你的rsyslog服务器的IP。
重启服务：
service rsyslog restart
演示
下面是配置的组合访问日志的演示：
日志记录示例
请注意，Apache日志记录的默认日志格式为：
[时间戳] [客户端主机名] [InputFileTag]：[Apache请求数据]
日志解析和监控
现在我们有数据流入了我们的rsyslog服务器，我们需要一种简单的方法从日志中提取有意义的事件数据。我们可以而且确实应该在攻击运行时审查原始日志，但我们没有理由忽视一些重要的事件。
在业内已经有很多种方法可以针对日志设置有效的告警。出于本文的目的，我们会演示如何设置Apache将我们的有效载荷托管日志发送到Papertrail，以便我们可以留意到防御方的探测行为。
Papertrail设置
我们首先需要一个Papertrail帐户。值得庆幸的是，Papertrail提供了相当不错的免费套餐！一旦我们登录后，我们就可以添加我们的第一个系统。设置步骤非常简单。Papertrail还为我们提供了将我们的rsyslog直接发送到云提供商的命令。我们首先需要按照上面的“客户端安装”部分来配置rsyslog获取Apache access.log。
Papertrail设置
一旦我们成功运行提供的安装脚本，我们的日志就会开始与Papertrail进行同步，我们会收到一条“Logs received from: our host”的提示。
通过日志同步，我们可以导航到Papertrail中的“事件”选项卡。在这里，我们将找到rsyslog转发到Papertrail实例的所有信息。屏幕底部有一个易于使用的搜索栏，我们可以在其中查询所有或特定的日志记录服务器。
在这里，我们搜索所有的“GET”请求来命中我们的重定向器。
值得注意的是，Papertrail会保留近两天的日志，然后将其归档。遗憾的是，归档日志无法在Papertrail中搜索到。但是，Papertrail通过允许我们根据你的查询设置警报来弥补这一点！Papertrail支持许多警报平台，如SMS，Slack，HipChat等。更多细节可以在这里找到。
让我们来看看针对我们的有效载荷的任何命中规则的示例告警。
首先，在搜索栏中执行搜索。搜索完成后，选择“保存搜索”。我们将在下面的窗口中看到提示。
创建Papertrail告警
为搜索输入一个吸引人的标题，然后选择“保存并设置告警”按钮。然后会跳转到一个选择告警平台的页面。
告警平台选择
对于这个设置，我们这里使用Slack，因为Slack非常棒。单击“Slack”图标，系统会提示我们输入Slack WebHook URI。输入URI后，选择你的时间间隔，然后选择“保存”。就是这样！我们完成了配置。一旦我们的警报触发，我们将在Slack通道中收到提示，如下图所示：
Slack告警示例
正如我们所看到的，当防御方的请求命中我们的有效载荷URI时，我们每分钟都会收到告警。虽然使用rsyslog和Papertrail，我们可以做的不止有效载荷命中检测这件事情。我们可以利用我们的想象来告警端口探测，SSH登录尝试，电子邮件日志等事情。我们可以使用rsyslog做很多事情，然后导入到Papertrail并设置告警。
总结
在本文中，我们介绍了如何使用rsyslog设置日志聚合以及如何创建有意义的告警来检测攻击基础架构的高价值操作。Rsyslog提供了一种简单的机制，可以将日志转发到集中式服务器或第三方日志聚合服务，如Papertrail。在整个评估过程中积极监控整个分布式的红队攻击基础架构，使我们能够更快的做出响应，并在开始销毁基础架构元素时更改攻击策略。
注：这篇文章由Steve Borosh（@ 424f424f）和Jeff Dimmock（@bluscreenofjeff）共同撰写。