下下下一代防火墙关键技术漫谈 – 作者:23donge

防火墙到底几代了?

Siri:“抱歉,很难回答你的问题”。

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 更加深入灵活的规则

  • 更深更广的数据支撑

  • 更全面及时的情报

  • 更智能的分析逻辑

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

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

工程与技术如何选择?

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

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

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

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

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

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

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

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

目前我觉得决策树及其衍生模型,包括随机森林,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

其底层就是一个通用的状态计算决定的,这个通用状态可以抽象定义为 <key, state, ttl>

摘抄 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
    }

但有一些场景我们还可以减法,比如分布式,故障恢复场景,还有Exactly Once等情况都是通用框架下的问题,但在防火墙安全领域的数据分析下是可以简化的。

还有语言实现层面,甚至硬件加速的方案,可以优化,尽量使单节点性能大幅提升,以我的经验,现在的硬件能力是可以支撑的。

我认为将一个通用流计算框架裁剪移植到防火墙里,也许是下下下一代防火墙上绕不开的关键特性,甚至是最关键特性。

最后

当然系统还有许多细节,比如状态存储的设计,灵活状态规则的定义,多状态表下决策的统一,柔性的处置机制,修正机制等等。

一个未来的产品,还有很多未来的因素,由于才疏学浅,可能一叶障目,仅出于最近几年的所学所思,供探讨。

来源:freebuf.com 2020-08-21 22:08:47 by: 23donge

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论