有几代防火墙？Siri：“抱歉，很难回答你的问题”。防火墙虽然是一种网络设备，但其功能并不需要与其他防火墙互联互通，因此没有“互联互通”的标准化。防火墙是在二层/三层网络设备的基础上叠加不同功能的软件系统。“功能”的标准化最终只是在“营销用语”、“第三方认证评级”、“市场调研机构”等国家标准的手中。但有一点是不可否认的。与以往相比generation，下一代防火墙其实就是“下一层”的防火墙，把对网络流量的理解加深了一层。如果说ACL，五元组的防火墙规则是第一代的，所以相当于layer3，网络层。其下一代状态防火墙可以识别TCP三向握手，位于第4-5层、传输层和会话层。下一代UTM防病毒等已识别应用程序数据，这位于6-7层，即应用层，至于下一代，已经超越了网络的层次，所以合理的推论是，在前几代检测不到的情况下，可以识别对用户服务的威胁。所以下一代n是我们目前看到的防火墙的终极形式。如何理解对业务的威胁？这个好像是玄学，因为没有这个层面的约定，所以是“主观题”，还是文科题。“主观题”在营销中大放异彩，各种危机案例、恐怖场景、人工智能、深度学习无所不包。但从真正的工程角度来看，还是需要将文科的“主观题”转化为理科的“证明题”。如何证明这个问题？自从知道有很多主观因素，人的因素就大大增加了，对业务的理解深度和广度都增加了。我们需要：更深入灵活的规则，更深更广的数据支持，更全面及时的情报，更智能的分析逻辑，所以本题的重点考点是“数据分析”。翻译成“人话”就是“找规律，找不同”的意思。例如：张三总是在半夜探访，这和正常人不一样。李斯就像一个机器人，每天按照固定的模式看图。工程技术如何选择？大数据分析、机器学习、深度学习技术在过去10年经历了飞跃，技术层出不穷，但在安全场景下实施是否合适？不谈营销，只说干货。安全域要求是“正常”和“异常”的主要分类问题。(1)深度学习：基于神经网络技术，用于自然语言理解、图形图像视频识别、语音识别等场景，都是人类感官模拟。看过一些论文，把网络流特征转成图片，然后做图像学习，好像画蛇添足。虽然使用了深度学习，但是效果比传统的机器学习要差。目前我只是受过一点教育，还没有体会到在基于流量的安全领域使用深度学习的必要场景，而且人的因素是最大的，对算力资源的需求也是最大的。（补充：NPL可用于URL参数注入分析场景）（2）机器学习/大数据分析：相对于统计规则，机器学习相当于在某个公式下搜索最优解，找到最合适的参数。有很多方法。但它也需要一个“训练”的过程。这个过程不太适合防火墙设备，因为它需要人的引导，但是可以在防火墙中对训练好的模型进行“预测”。目前我觉得决策树及其派生模型，包括随机森林，GBDT，适合做实时预测，工程化的框架可以用，比如XGBoost的C++版本。网上已经有很多可行性论文。关键技术指标在哪里？首先，防火墙以性能指标作为参考。同等功能下，低硬件成本（cost）和高性能才是竞争力。除了算法的领先，还需要架构的领先。无论是使用机器学习还是统计规则，都是基于从比过去大几个数量级的数据中提取特征。也就是说，“数据量”、“计算速度”和“灵活性”的能力都超过了上一代。但是，这三种关系是互斥的，需要相减。既然“数据分析”是关键，那我们就来看看目前的技术Hadoop生态。显然，它可以处理大量数据，但速度慢，成本高。后起之秀Spark/Flink解决了速度问题，但仍然基于Hadoop生态。它是一个灵活性较好的通用框架，但性能仍然太慢。然而，下一代防火墙仅限于固定输入的“数据分析”系统。显然，可以牺牲一些灵活性和数据量，但不能牺牲速度，因为防火墙嵌入在关键路径上。首先需要一个通用的深度分析引擎，可以灵活的从流量中提取业务领域。显然，当代的防火墙已经具备了。那么就需要一个通用的计算分析引擎，可以缓存大量的关键数据，然后按照规则进行计算。基于状态管理的流计算分析首先，这并不是什么新鲜事物。做过状态防火墙的都知道，流会话表（FlowSessionTable）是基于流或会话关系的状态管理。session从产生、状态转移到结束的过程，需要符合一定的规则。这个规则是由网络协议定义的，所有的检查都是基于这个状态叠加的。与业务风险相对应的是业务状态的管理。一般来说，正常人在网上完成一项业务的平均时间在30分钟以内。所以通常这个数据量只需要1小时就可以解决90%的场景，减少了数据量的问题。然后是会话密钥。在业务安全方面，可以使用传统的IP和FlowId，但更需要使用AppId、UserId、DeviceId、SessionId等业务维度键。这是一个开放的字段，但不会超过10种需要通用支持的类型，即从消息中任意位置解析出来的字段都可以作为这个状态的key。业务中也可以同时存在多个关键状态，需要聚合（AGG）关联（JOIN）或者合并（UNION）。第二个不确定因素是法律。这个商业规律不能预先定义。没有约定，只能事后分析。所以这里需要机器学习和人工分析能够指导这个规律，我们就不详细讨论了。这种状态管理的计算是速度和灵活性之间的权衡。比如流表状态管理，显然是为三层流量定制的状态管理，所以速度很快。但是在业务层面，不能牺牲字段和计算表达的灵活性，所以这里的功能类似于一个FlinkCEP系统。（很多安全公司用在云安全上）https://ci.apache.org/projects/flink/flink-docs-stable/dev/libs/cep.html底层由一个通用的状态计算决定，这个generalstate在Spark中可以抽象定义为一段代码的摘录，好像是这样，在Flink中也是类似的，所有的大数据流计算都差不多，但是速度不会更快，//AmappingfunctionthatmaintainsanintegerstateandreturnsaStringdefmappingFunction(key:String,value:Option[Int],state:State[Int]):Option[String]={//Checkifstateexistsif(state.exists){valexistingState=state.get//GettheexistingstatevalshouldRemove=...//决定是否删除stateif(shouldRemove){state.remove()//移除状态}else{valnewState=...state.update(newState)//设置新状态}}else{valinitialState=...state.update(initialState)//设置初始状态}...//returnsomething}但是有些场景我们也可以减去，比如分布式，故障恢复场景，和ExactlyOnce都是通用框架下的问题，但是在防火墙安全领域的数据分析下可以简化。还有语言实现层面，甚至是硬件加速方案，都可以通过优化，尽可能大幅提升单节点的性能。根据我的经验，目前的硬件能力是可以支持的。我认为，将一个通用的流计算框架裁剪移植到防火墙上，可能是下一代防火墙无法绕过的关键特性，甚至是最关键的特性。最后，当然这个系统还有很多细节，比如状态存储的设计，灵活状态规则的定义，多状态表下的统一决策，灵活的处置机制，修正机制等等。对于一个未来的产品，还有很多未来的因素。由于天赋和学习的欠缺，可能比较盲目，仅就自己近几年的所学所想，仅供讨论。
