下下下一代防火墙关键技术漫谈

防火墙到底几代了?

Siri：“抱歉，很难回答你的问题”。

防火墙虽然是个网络设备，但其功能不需要与其他防火墙之间互联互通，所以没有“互联”标准化的诞生。

[[339216]]

防火墙是在一个L2/L3网络设备基础上叠加不同的功能的软件系统，“功能”的标准化最后只停留在了“营销话术”，“第三方认证评级”，“市场调查机构”，“等保国标”的手上。

但有一点不可否认，相对上一代，下一代防火墙其实是“下一层”防火墙，将对网络流量的认知深入一层。

如果说ACL，五元祖的防火墙规则是第一代，那么相当于3层，网络层。

其下一代，状态防火墙可以认知TCP三次握手，位于4-5层，传输和会话层。

再下一代，UTM防病毒等认知到了应用数据，位于6-7层，应用层。

那下下下一代呢，已经超出网络的层次了，那么合理的推论就是在，在以上几代都检查不出来的情况下，认知对用户业务的威胁。

所以下下下一代算是目前看到防火墙的终极形态了。

如何理解针对业务的威胁?

这个看起来是个玄学，因为这个层面上已经没有了协议的约束，所以是道“主观题”，还是文科的。

“主观题”在市场营销上可谓随意发挥，各种危机案例，骇人场景，人工智能，深度学习都上了。

但真正的工程角度，还是要把文科“主观题”转化给理科的“证明题”。

如何证明这道题目呢?既然我们知道主观因素很多，那么人的因素增加大，理解业务的深度和广度增大了。我们需要：

更加深入灵活的规则
更深更广的数据支撑
更全面及时的情报
更智能的分析逻辑

所以最终这题关键考点“数据分析”。翻译成“人话”就是“找规律，找不同”。

比如：张三总是半夜访问，和正常人不同。李四像个机器人，每天都是固定模式读图。

工程与技术如何选择?

大数据分析，机器学习，深度学习技术在过去10年有了一次越迁，技术层出不穷，但落地到安全场景是否合适?

抛开市场营销不说，只谈干货。安全领域需求是主要分类“正常”与“不正常”的问题。

(1) 深度学习：基于神经网络技术，用于自然语言理解，图形图像视频识别，语音识别场景，其都是人的感官模拟。

看过一些论文将网络流特征弄成图片，然后做图像学习，感觉明显画蛇添足。虽然用了深度学习，其效果比传统机器学习还差。

目前我才疏学浅，还没认知到基于流量的安全领域使用深度学习的必要场景，而且人因素最大，算力资源要求也最大。

(补充: NPL可用于URL参数注入分析场景)

(2) 机器学习/大数据分析：相比统计规则，机器学习相当于在一定公式下进行最优解查找，找到最合适的参数。方法也很多。

但也都需要“训练”过程，这个过程在防火墙设备中进行目前还不是很适合，因为需要人指导，但训练后的模型进行“预测”完全可以在防火墙中进行。

目前我觉得决策树及其衍生模型，包括随机森林，GBDT均适用于实时预测，可以使用的工程框架如 XGBoost 的 C++ 版本。

其可行性论文网上已经有很多。

关键技术指标在哪里?

首先防火墙都是以性能指标为参照，实现相同功能下以硬件代价小(成本)性能高为竞争力。

除了算法的领先，需要在架构上领先。无论使用机器学习，还是统计规则，都要在比过去大几个数量级的数据下提取特征为基础的。

也就是“数据量”与“计算速度”还有“灵活性”的能力要超过上一代。而这三者关系却是互斥的，需要做减法。

既然是“数据分析”是关键，我们看看现在有的技术Hadoop生态，显然可以处理大数据量，但是速度慢，成本高。

后起之秀 Spark / Flink 解决速度问题，但还是基于Hadoop生态，是一个通用框架，灵活性上更好，性能还是太慢。

而下下下一代防火墙被限定在一个固定输入的“数据分析”系统下，显然灵活性可以牺牲一些，数据量也可以牺牲一些，但速度绝对不能妥协，因为防火墙是嵌入在关键路径上的。

首先需要一个通用的深度解析引擎，能灵活将业务字段从流量中提取，显然当代防火墙都已经具备。

然后需要一个通用的计算分析引擎，能够缓存大量的关键数据，然后根据规则进行计算。

基于状态管理的流计算分析

首先这个不是新东西，做过状态防火墙的都知道，流表(Flow Session Table)就是基于流或会话关系的状态管理。

从会话产生，状态变迁到结束的过程，需要符合一定规律，这个规律是网络协议定义的，所有的检查都是基于这个状态进行叠加的。

对应到业务风险就是对业务状态的管理，一般来说正常人在线完成一个业务的平均值为30分钟以内。所以通常这个数据量只需要1个小时即可解决90%的场景，数据量的问题被减掉了。

然后是会话的key，在业务安全层面上，可以使用传统的IP，FlowId，但更需要使用的是AppId，UserId，DeviceId，SessionId这种业务维度的key，这是一个开放字段，但不会超过10种，需要通用支持，也就是从报文任意位置解析出来的字段，都可以作为这个状态的key。

业务中也可以同时有很多key的状态，需要进行聚合(AGG)关联(JOIN)或合并(UNION)。

第二个不确定就是规律，这个业务规律是无法事先定义的，没有协议，只能事后分析产生，所以机器学习和人工分析在这里需要能指导这个规律，具体不展开讲。

这个状态管理的计算也就是速度与灵活性的取舍，比如还是流表状态管理，这个显然是针对3层流量定制的状态管理，所以速度快。

但业务层面没法牺牲字段和计算表达的灵活性了，所以这里的功能和一个Flink CEP系统相似。(已经不少安全公司在云安全上使用了)

https://ci.apache.org/projects/flink/flink-docs-stable/dev/libs/cep.html

其底层就是一个通用的状态计算决定的，这个通用状态可以抽象定义为

摘抄 Spark 中的一段代码，看起来就是这么回事，Flink中也是类似的的，所有大数据流计算都相似，但速度一定不会快了，

// A mapping function that maintains an integer state and returns a String 
    def mappingFunction(key: String, value: Option[Int], state: State[Int]): Option[String] = { 
      // Check if state exists 
      if (state.exists) { 
        val existingState = state.get  // Get the existing state 
        val shouldRemove = ...         // Decide whether to remove the state 
        if (shouldRemove) { 
          state.remove()     // Remove the state 
        } else { 
          val newState = ... 
          state.update(newState)    // Set the new state 
        } 
      } else { 
        val initialState = ... 
        state.update(initialState)  // Set the initial state 
      } 
      ... // return something 
    }