防火墻到底幾代了?

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

防火墻雖然是個網(wǎng)絡(luò)設(shè)備，但其功能不需要與其他防火墻之間互聯(lián)互通，所以沒有“互聯(lián)”標(biāo)準(zhǔn)化的誕生。

[[339216]]

防火墻是在一個L2/L3網(wǎng)絡(luò)設(shè)備基礎(chǔ)上疊加不同的功能的軟件系統(tǒng)，“功能”的標(biāo)準(zhǔn)化最后只停留在了“營銷話術(shù)”，“第三方認(rèn)證評級”，“市場調(diào)查機構(gòu)”，“等保國標(biāo)”的手上。

但有一點不可否認(rèn)，相對上一代，下一代防火墻其實是“下一層”防火墻，將對網(wǎng)絡(luò)流量的認(rèn)知深入一層。

如果說ACL，五元祖的防火墻規(guī)則是第一代，那么相當(dāng)于3層，網(wǎng)絡(luò)層。

其下一代，狀態(tài)防火墻可以認(rèn)知TCP三次握手，位于4-5層，傳輸和會話層。

再下一代，UTM防病毒等認(rèn)知到了應(yīng)用數(shù)據(jù)，位于6-7層，應(yīng)用層。

那下下下一代呢，已經(jīng)超出網(wǎng)絡(luò)的層次了，那么合理的推論就是在，在以上幾代都檢查不出來的情況下，認(rèn)知對用戶業(yè)務(wù)的威脅。

所以下下下一代算是目前看到防火墻的終極形態(tài)了。

如何理解針對業(yè)務(wù)的威脅?

這個看起來是個玄學(xué)，因為這個層面上已經(jīng)沒有了協(xié)議的約束，所以是道“主觀題”，還是文科的。

“主觀題”在市場營銷上可謂隨意發(fā)揮，各種危機案例，駭人場景，人工智能，深度學(xué)習(xí)都上了。

但真正的工程角度，還是要把文科“主觀題”轉(zhuǎn)化給理科的“證明題”。

如何證明這道題目呢?既然我們知道主觀因素很多，那么人的因素增加大，理解業(yè)務(wù)的深度和廣度增大了。我們需要：

• 更加深入靈活的規(guī)則
• 更深更廣的數(shù)據(jù)支撐
• 更全面及時的情報
• 更智能的分析邏輯

所以最終這題關(guān)鍵考點“數(shù)據(jù)分析”。翻譯成“人話”就是“找規(guī)律，找不同”。

比如：張三總是半夜訪問，和正常人不同。李四像個機器人，每天都是固定模式讀圖。

工程與技術(shù)如何選擇?

大數(shù)據(jù)分析，機器學(xué)習(xí)，深度學(xué)習(xí)技術(shù)在過去10年有了一次越遷，技術(shù)層出不窮，但落地到安全場景是否合適?

拋開市場營銷不說，只談干貨。安全領(lǐng)域需求是主要分類“正常”與“不正常”的問題。

(1) 深度學(xué)習(xí)：基于神經(jīng)網(wǎng)絡(luò)技術(shù)，用于自然語言理解，圖形圖像視頻識別，語音識別場景，其都是人的感官模擬。

看過一些論文將網(wǎng)絡(luò)流特征弄成圖片，然后做圖像學(xué)習(xí)，感覺明顯畫蛇添足。雖然用了深度學(xué)習(xí)，其效果比傳統(tǒng)機器學(xué)習(xí)還差。

目前我才疏學(xué)淺，還沒認(rèn)知到基于流量的安全領(lǐng)域使用深度學(xué)習(xí)的必要場景，而且人因素最大，算力資源要求也最大。

(補充: NPL可用于URL參數(shù)注入分析場景)

(2) 機器學(xué)習(xí)/大數(shù)據(jù)分析：相比統(tǒng)計規(guī)則，機器學(xué)習(xí)相當(dāng)于在一定公式下進行最優(yōu)解查找，找到最合適的參數(shù)。方法也很多。

但也都需要“訓(xùn)練”過程，這個過程在防火墻設(shè)備中進行目前還不是很適合，因為需要人指導(dǎo)，但訓(xùn)練后的模型進行“預(yù)測”完全可以在防火墻中進行。

目前我覺得決策樹及其衍生模型，包括隨機森林，GBDT均適用于實時預(yù)測，可以使用的工程框架如 XGBoost 的 C++ 版本。

其可行性論文網(wǎng)上已經(jīng)有很多。

關(guān)鍵技術(shù)指標(biāo)在哪里?

首先防火墻都是以性能指標(biāo)為參照，實現(xiàn)相同功能下以硬件代價小(成本)性能高為競爭力。

除了算法的領(lǐng)先，需要在架構(gòu)上領(lǐng)先。無論使用機器學(xué)習(xí)，還是統(tǒng)計規(guī)則，都要在比過去大幾個數(shù)量級的數(shù)據(jù)下提取特征為基礎(chǔ)的。

也就是“數(shù)據(jù)量”與“計算速度”還有“靈活性”的能力要超過上一代。而這三者關(guān)系卻是互斥的，需要做減法。

既然是“數(shù)據(jù)分析”是關(guān)鍵，我們看看現(xiàn)在有的技術(shù)Hadoop生態(tài)，顯然可以處理大數(shù)據(jù)量，但是速度慢，成本高。

后起之秀 Spark / Flink 解決速度問題，但還是基于Hadoop生態(tài)，是一個通用框架，靈活性上更好，性能還是太慢。

而下下下一代防火墻被限定在一個固定輸入的“數(shù)據(jù)分析”系統(tǒng)下，顯然靈活性可以犧牲一些，數(shù)據(jù)量也可以犧牲一些，但速度絕對不能妥協(xié)，因為防火墻是嵌入在關(guān)鍵路徑上的。

首先需要一個通用的深度解析引擎，能靈活將業(yè)務(wù)字段從流量中提取，顯然當(dāng)代防火墻都已經(jīng)具備。

然后需要一個通用的計算分析引擎，能夠緩存大量的關(guān)鍵數(shù)據(jù)，然后根據(jù)規(guī)則進行計算。

基于狀態(tài)管理的流計算分析

首先這個不是新東西，做過狀態(tài)防火墻的都知道，流表(Flow Session Table)就是基于流或會話關(guān)系的狀態(tài)管理。

從會話產(chǎn)生，狀態(tài)變遷到結(jié)束的過程，需要符合一定規(guī)律，這個規(guī)律是網(wǎng)絡(luò)協(xié)議定義的，所有的檢查都是基于這個狀態(tài)進行疊加的。

對應(yīng)到業(yè)務(wù)風(fēng)險就是對業(yè)務(wù)狀態(tài)的管理，一般來說正常人在線完成一個業(yè)務(wù)的平均值為30分鐘以內(nèi)。所以通常這個數(shù)據(jù)量只需要1個小時即可解決90%的場景，數(shù)據(jù)量的問題被減掉了。

然后是會話的key，在業(yè)務(wù)安全層面上，可以使用傳統(tǒng)的IP，F(xiàn)lowId，但更需要使用的是AppId，UserId，DeviceId，SessionId這種業(yè)務(wù)維度的key，這是一個開放字段，但不會超過10種，需要通用支持，也就是從報文任意位置解析出來的字段，都可以作為這個狀態(tài)的key。

業(yè)務(wù)中也可以同時有很多key的狀態(tài)，需要進行聚合(AGG)關(guān)聯(lián)(JOIN)或合并(UNION)。

第二個不確定就是規(guī)律，這個業(yè)務(wù)規(guī)律是無法事先定義的，沒有協(xié)議，只能事后分析產(chǎn)生，所以機器學(xué)習(xí)和人工分析在這里需要能指導(dǎo)這個規(guī)律，具體不展開講。

這個狀態(tài)管理的計算也就是速度與靈活性的取舍，比如還是流表狀態(tài)管理，這個顯然是針對3層流量定制的狀態(tài)管理，所以速度快。

但業(yè)務(wù)層面沒法犧牲字段和計算表達(dá)的靈活性了，所以這里的功能和一個Flink CEP系統(tǒng)相似。(已經(jīng)不少安全公司在云安全上使用了)

https://ci.apache.org/projects/flink/flink-docs-stable/dev/libs/cep.html

其底層就是一個通用的狀態(tài)計算決定的，這個通用狀態(tài)可以抽象定義為

摘抄 Spark 中的一段代碼，看起來就是這么回事，F(xiàn)link中也是類似的的，所有大數(shù)據(jù)流計算都相似，但速度一定不會快了，

// 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 
    } 

但有一些場景我們還可以減法，比如分布式，故障恢復(fù)場景，還有Exactly Once等情況都是通用框架下的問題，但在防火墻安全領(lǐng)域的數(shù)據(jù)分析下是可以簡化的。

還有語言實現(xiàn)層面，甚至硬件加速的方案，可以優(yōu)化，盡量使單節(jié)點性能大幅提升，以我的經(jīng)驗，現(xiàn)在的硬件能力是可以支撐的。

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

最后

當(dāng)然系統(tǒng)還有許多細(xì)節(jié)，比如狀態(tài)存儲的設(shè)計，靈活狀態(tài)規(guī)則的定義，多狀態(tài)表下決策的統(tǒng)一，柔性的處置機制，修正機制等等。

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