packetbeat+wazuh实现企业内网探针型蜜罐实施落地

背景

为什么要使用蜜罐？

目前企业在内网安全建设上采取的措施：EDR(XDR),内网流量检测设备(NTA，内网防火墙等)，honeypot蜜罐，组件起到互补的作用：

目前EDR的能力主要落在主机本身上，无论是哪家产品，能力无非包括：

1. 日志进程的采集分析
2. 依赖包漏洞库对比分析
3. 文件完整性检测
4. 系统调用，安全策略监控
5. 及时响应能力

流量检测设备大多部署在每个VPC的边界，用于对VPC进出口流量进行分析和拦截

但同样的，他们存在着以下的问题：

1.EDR分析及告警大多是基于规则的，这就意味着存在被未知攻击及手段绕过的可能性

2.流量检测设备难以对VPC内部的流量进行检测，存在着流量层面检测的盲点

综上，在一台机器沦陷或被取得控制权限后，蜜罐对于探测攻击者横向移动路径，以及发现未知手段等途径带来的机器和流量异常，起着不可或缺不可替代的作用

为什么要使用探针？

传统蜜罐无论是高交互或者是低交互蜜罐，都是在内网极度缺乏信息采集能力和防御手段下的无奈之举

一方面我们在已经拥有EDR强大的命令行，进程等的采集能力后，机器操作者的一举一动我们是完全可以在源日志内找到的，这点我们也在上个话题中说到，我们只是担心操纵者手法过于精巧地绕过规则无法触发告警，无法使安全分析师们发现被攻击的情况，所以我们并不需要使用交互式蜜罐去给攻击者画像，使用探针捕获异常来补全基于规则检测组件的检测能力即可

另一方面蜜罐也是一种应用，也有被识破被拿下的风险，而且交互越多，实际上危险程度也就越大，但探针由于并没有使用什么危险服务和开放端口，反而很安全

为什么要使用packetbeat作为探针蜜罐

事实上为了捕获内网环境中扫描等异常流量，以zeek,suricata为首的NTA看似是一个很好的探针选择，可是这边就要提到一个成本问题了，行业内普遍认为内网间东西向流量是南北向流量的4倍大小左右，如果需要部署足够多的蜜罐点以便增大发现异常流量的话，相对比较重的NTA的成本就成为了一个很大的制约点

反而packetbeat作为ELK族的轻量级采集器组件，即便是配置最低的实例，安装packetbeat也绰绰有余，也不用担心packetbeat能采集到流量的信息过少，下面是packetbeat采集到的一条日志信息：

{
 "@timestamp": "2021-06-08T23:59:56.468Z",
 "@metadata": {
  "beat": "packetbeat",
  "type": "_doc",
  "version": "7.10.1"
 },
 "status": "OK",
 "destination": {
  "ip": "ip1",
  "bytes": 56
 },
 "product": "Honeypot",
 "path": "ip1",
 "related": {
  "ip": ["ip2", "ip1"]
 },
 "ecs": {
  "version": "1.5.0"
 },
 "client": {
  "ip": "ip2",
  "bytes": 56
 },
 "network": {
  "zone": "internal",
  "bytes": 112,
  "type": "ipv4",
  "transport": "icmp",
  "direction": "inbound",
  "community_id": "community_id"
 },
 "host": {
  "name": "name"
 },
 "agent": {
  "name": "name",
  "type": "packetbeat",
  "version": "7.10.1",
  "hostname": "hostname",
  "ephemeral_id": "ephemeral_id",
  "id": "id"
 },
 "provider": "Honeypot",
 "icmp": {
  "request": {
   "message": "EchoRequest(0)",
   "type": 8,
   "code": 0
  },
  "response": {
   "message": "EchoReply(0)",
   "type": 0,
   "code": 0
  },
  "version": 4
 },
 "server": {
  "ip": "ip1",
  "bytes": 56
 },
 "event": {
  "category": ["network_traffic", "network"],
  "type": ["connection"],
  "kind": "event",
  "dataset": "icmp",
  "duration": 31000,
  "start": "2021-06-08T23:59:56.468Z",
  "end": "2021-06-08T23:59:56.468Z"
 },
 "type": "icmp",
 "source": {
  "bytes": 56,
  "ip": "ip2"
 }
}

也就是常说的流量五元组信息，但对于分析师们去判断攻击路径和扫描路径已经足够用了

这也就是我们在内网安全建设的一个思想，蜜罐只是一个辅助手段，真正的分析主力还是在机器本身上进行采集收集数据源分析的EDR

架构设计

老规矩，先上架构图

大致介绍一下数据流传输的路径：

1.在各VPC子网内申请honeypot机器(在条件允许情况下，要在一个子网段申请两台不连续的IP增大检测面)

2.在honeypot机器上安装使用pcap检测模式的packetbeat，配置日志以轮询方式记录本地

3.通过机器上wazuh-agent已收集packetbeat日志，发送给manager集群

4.在woker节点对日志进行处理，比如标记重点服务器，drop掉zabbix，堡垒机等正常交互通信，发送心跳数据包等正常流量数据

5.通过filebeat采集wazuh日志数据发送给ELK处理展示等

接下来谈下各组件的配置：

packetbeat

ELK beat族的采集器之一，用于采集流量信息，我们使用pcap流量捕获方式，使用libpcap库对包括嗅探以内的所有流量进行捕获收集

packetbeat默认使用pcap，所以默认安装即可，但需要修改output方式，默认为吐入ES，我们需要注释掉，然后配置让日志落地到本地：

/etc/packetbeat/packetbeat.yml

# ------------------------------ File Output -------------------------------
output.file:
  path: "/var/logs/packetbeat"
  filename: packetbeat.log
  rotate_every_kb: 102400

参数详解：

1.path指定日志文件所在目录路径

2.filename指定生成日志文件名称默认为packetbeat

3.rotate_every_kb是每个文件的最大大小，超过后将轮询，默认是10M，我这里改成了100M

4.number_of_files目录下报存的最大文件数，默认是7个，超过后会删除最旧的文件

5.permissions文件创建的权限，默认为0600

wazuh

主流开源EDR之一，无数公司企业使用或者二次开发，或作为事件实时分析处理引擎等，具有强大的日志采集和分析能力

packebeat日志是标准的json格式，无需自定义解码器，需先在honeypot组配置中加载日志采集规则：

/var/ossec/etc/shared/honeypot/agent.conf

<agent_config>
    <!-- honeypot日志检测 -->
    <localfile>
      <log_format>json</log_format>
      <location>/var/logs/packetbeat/packetbeat.log</location>
    </localfile>
  </agent_config>

配置packetbeat自定义规则：

/var/ossec/etc/rules/local_packetbeat_log.xml

<var name="trustip">DNS服务器IP|Zabbix服务器IP|堡垒机IP</var>
<group name="packetbeat,log">
    <rule id="113500" level="2">
        <decoded_as>json</decoded_as>
        <match negate="yes">$trustip</match>
        <field name="@metadata.beat">packetbeat</field>
        <description>packetbeat messages.</description>
    </rule>
</group>