网络安全 频道

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

  防火墙到底几代了?

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

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

  防火墙是在一个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中也是类似的的,所有大数据流计算都相似,但速度一定不会快了,

  1. // A mapping function that maintains an integer state and returns a String 
  2.     def mappingFunction(key: String, value: Option[Int], state: State[Int]): Option[String] = { 
  3.       // Check if state exists 
  4.       if (state.exists) { 
  5.         val existingState = state.get  // Get the existing state 
  6.         val shouldRemove = ...         // Decide whether to remove the state 
  7.         if (shouldRemove) { 
  8.           state.remove()     // Remove the state 
  9.         } else { 
  10.           val newState = ... 
  11.           state.update(newState)    // Set the new state 
  12.         } 
  13.       } else { 
  14.         val initialState = ... 
  15.         state.update(initialState)  // Set the initial state 
  16.       } 
  17.       ... // return something 
  18.     } 

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

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

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

  最后

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

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

0
相关文章