3. 流量特征提取：NetFlow基础、流量特征维度、特征工程方法
说实话，做僵尸网络检测这么多年，我最大的体会就是：你拿不到好的特征，再牛的算法也是白搭。流量特征提取，说白了就是把原始的网络报文，变成机器能理解的数字向量。这一步做扎实了，后面的事情就顺了。
我记得刚入行那会儿，有个老前辈跟我说过一句话，我一直记着：「你连流量长什么样都说不清楚，怎么抓僵尸？」嗯，今天我们就来聊聊怎么「说清楚」流量。
3.1 NetFlow基础：流量会话的「身份证」
NetFlow 是什么？你可以把它理解成网络流量的「通话记录」。它不关心每个报文里具体写了什么，只关心「谁在什么时候和谁说了什么协议的话，说了多久，说了多少」。我个人习惯把 NetFlow 记录看成一张表，每一行就是一个网络会话。
| 字段 | 含义 | 我的经验备注 |
|---|---|---|
| SrcIP | 源IP地址 | 内网IP还是外网IP？这个很关键 |
| DstIP | 目的IP地址 | 是不是已知的恶意IP段？ |
| SrcPort | 源端口 | 高位端口往往有猫腻 |
| DstPort | 目的端口 | 非标准端口要警惕 |
| Protocol | 协议类型（TCP/UDP/ICMP） | 僵尸网络偏爱UDP做心跳 |
| Packets | 会话总报文数 | 心跳包通常很小 |
| Bytes | 会话总字节数 | 结合报文数算平均包长 |
| StartTime | 会话开始时间 | 凌晨的活动更可疑 |
| Duration | 会话持续时间 | 长连接还是短连接？ |
| Flags | TCP标志位 | SYN Flood的特征就在这里 |
3.2 流量特征维度：从三个角度看流量
光有NetFlow原始字段还不够，我们需要从不同维度去「加工」这些数据。我一般把特征分成三个维度，你想想看，就像看一个人：看长相、看行为、看社交关系。
3.2.1 统计维度：算一算，比一比
这是最基础也是最有效的维度。说白了就是做加减乘除。我曾经在一个项目中，发现某个内网主机对外通信的平均包长只有64字节，而且每分钟一次，雷打不动。这就是典型的僵尸网络心跳特征。
- 平均包长：总字节数 / 总报文数。心跳包通常很小。
- 流速率：单位时间内新建的流数量。被控主机通常有规律地建连。
- 上下行比例：发送字节数 / 接收字节数。C2通信往往是下行远大于上行。
- 端口分散度：目的端口的种类数量。扫描行为通常端口很分散。
3.2.2 时序维度：看规律，找异常
僵尸网络最怕什么？怕规律被抓住。我见过太多案例，僵尸主机每隔30秒发一个心跳包，跟闹钟一样准时。这种周期性特征，在时序维度上一目了然。
避坑指南： 我曾经犯过一个错误——只统计了平均间隔时间，结果漏掉了一个使用「随机间隔+抖动」的僵尸网络。后来我加入了间隔时间的标准差作为特征，才把它揪出来。记住：均值+方差，两个都要看。
3.2.3 行为维度：谁和谁在说话
这个维度稍微高级一点。我们不光看单个主机，还要看主机之间的关系。比如：
- 连接度：一个IP在单位时间内连接了多少个不同的IP？
- 社区发现：哪些IP经常互相通信？形成小团体了吗？
- 角色识别：这个IP是「说话多的」还是「被找的」？
我记得有一次，一个客户的内网有200多台机器同时对外发起DNS查询，目标都是同一个域名。从单台机器看，每个都很正常。但从行为维度看，这200台机器同时「指向」同一个外部域名，这就非常可疑了。
3.3 特征工程方法：把原始数据变成「好特征」
特征工程，说白了就是「怎么让数据更好用」。我总结了三个最常用的方法，你在做僵尸网络检测时基本都会用到。
3.3.1 聚合统计：把时间窗口「切」开
NetFlow是一条一条的，但我们需要按时间窗口来聚合。我个人习惯用1分钟作为基础窗口。为什么是1分钟？因为大多数僵尸网络的心跳间隔在30秒到5分钟之间，1分钟刚好能覆盖。
# 伪代码示例：按1分钟窗口聚合特征
def aggregate_flows(flows, window_size=60):
features = []
for window_start in range(0, max_time, window_size):
window_flows = flows[window_start:window_start+window_size]
feature = {
'src_ip': window_flows[0].src_ip,
'window_start': window_start,
'flow_count': len(window_flows),
'avg_packet_size': mean([f.bytes/f.packets for f in window_flows]),
'unique_dst_ips': len(set([f.dst_ip for f in window_flows])),
'unique_dst_ports': len(set([f.dst_port for f in window_flows])),
'total_bytes': sum([f.bytes for f in window_flows]),
}
features.append(feature)
return features
3.3.2 归一化与离散化：让数据「公平」
不同特征的数值范围差别很大。比如「报文数」可能是0到10000，而「协议类型」只有几个取值。如果不做处理，数值大的特征会「吃掉」数值小的特征。
| 方法 | 适用场景 | 我的建议 |
|---|---|---|
| Min-Max归一化 | 数值范围已知且稳定 | 适合报文数、字节数 |
| Z-score标准化 | 数据分布近似正态 | 适合平均包长、间隔时间 |
| One-Hot编码 | 离散特征（协议、端口） | 协议类型用这个最稳 |
| 对数变换 | 长尾分布的数据 | 字节数经常用log处理 |
3.3.3 特征选择：少即是多
你可能会觉得特征越多越好，其实不是。特征太多会导致过拟合，而且计算开销大。我一般遵循「三步走」：
- 过滤法：先去掉方差接近0的特征（比如所有流都是TCP协议，那协议类型这个特征就没用）。
- 包裹法：用简单的模型（比如决策树）跑一遍，看哪些特征重要。
- 嵌入法：用L1正则化（Lasso）自动做特征选择。
嗯，这里要注意：特征选择不是一次性的。我每次上线新模型前，都会重新做一遍特征选择，因为网络环境在变，僵尸网络也在变。
3.4 本章知识体系总览
下面这张图是我自己总结的流量特征提取框架，你可以把它当成一个检查清单。每次做特征工程时，对照着看一遍，基本不会漏东西。