防火墻到底幾代了?

Siri：“抱歉，很難回答你的問(wèn)題”。

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

[[339216]]

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

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

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

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

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

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

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

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

這個(gè)看起來(lái)是個(gè)玄學(xué)，因?yàn)檫@個(gè)層面上已經(jīng)沒(méi)有了協(xié)議的約束，所以是道“主觀題”，還是文科的。

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

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

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

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

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

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

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

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

拋開(kāi)市場(chǎng)營(yíng)銷(xiāo)不說(shuō)，只談干貨。安全領(lǐng)域需求是主要分類(lèi)“正常”與“不正常”的問(wèn)題。

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

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

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

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

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

但也都需要“訓(xùn)練”過(guò)程，這個(gè)過(guò)程在防火墻設(shè)備中進(jìn)行目前還不是很適合，因?yàn)樾枰酥笇?dǎo)，但訓(xùn)練后的模型進(jìn)行“預(yù)測(cè)”完全可以在防火墻中進(jìn)行。

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

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

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

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

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

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

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

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

而下下下一代防火墻被限定在一個(gè)固定輸入的“數(shù)據(jù)分析”系統(tǒng)下，顯然靈活性可以犧牲一些，數(shù)據(jù)量也可以犧牲一些，但速度絕對(duì)不能妥協(xié)，因?yàn)榉阑饓κ乔度朐陉P(guān)鍵路徑上的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后

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

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