防火墙到底几代了?
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中也是类似的的，所有大数据流计算都相似，但速度一定不会快了，
但有一些场景我们还可以减法，比如分布式，故障恢复场景，还有Exactly Once等情况都是通用框架下的问题，但在防火墙安全领域的数据分析下是可以简化的。
还有语言实现层面，甚至硬件加速的方案，可以优化，尽量使单节点性能大幅提升，以我的经验，现在的硬件能力是可以支撑的。
我认为将一个通用流计算框架裁剪移植到防火墙里，也许是下下下一代防火墙上绕不开的关键特性，甚至是最关键特性。
最后
当然系统还有许多细节，比如状态存储的设计，灵活状态规则的定义，多状态表下决策的统一，柔性的处置机制，修正机制等等。
一个未来的产品，还有很多未来的因素，由于才疏学浅，可能一叶障目，仅出于最近几年的所学所思，供探讨。