防火墻到底幾代了?

Siri：“抱歉，很難回答你的問題”。

防火墻雖然是個網絡設備，但其功能不需要與其他防火墻之間互聯互通，所以沒有“互聯”標準化的誕生。

[[339216]]

防火墻是在一個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中也是類似的的，所有大數據流計算都相似，但速度一定不會快了，

// 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等情況都是通用框架下的問題，但在防火墻安全領域的數據分析下是可以簡化的。

還有語言實現層面，甚至硬件加速的方案，可以優化，盡量使單節點性能大幅提升，以我的經驗，現在的硬件能力是可以支撐的。

我認為將一個通用流計算框架裁剪移植到防火墻里，也許是下下下一代防火墻上繞不開的關鍵特性，甚至是最關鍵特性。

最后

當然系統還有許多細節，比如狀態存儲的設計，靈活狀態規則的定義，多狀態表下決策的統一，柔性的處置機制，修正機制等等。

一個未來的產品，還有很多未來的因素，由于才疏學淺，可能一葉障目，僅出于最近幾年的所學所思，供探討。