下下下一代防火墙关键技术漫漫长谈
发布时间：2022-02-16 09:50:36 所属栏目：安全 来源：互联网
导读：防火墙到底几代了?Siri：抱歉，很难回答你的问题。防火墙虽然是个网络设备，但其功能不需要与其他防火墙之间互联互通，所以没有互联标准化的诞生。 防火墙是在一个L2/L3网络设备基础上叠加不同的功能的软件系统，功能的标准化最后只停留在了营销话术，第三方
|
防火墙到底几代了?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层流量定制的状态管理，所以速度快。 （编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
