1.1.3 狀態檢測與會話機制

前面介紹了安全策略的組成和配置方式，那么到達防火墻的流量是如何跟安全策略匹配的呢？在介紹匹配規則之前，我們首先介紹一下防火墻的狀態檢測和會話機制。

早期包過濾防火墻產品采取的是“逐包檢測”機制，即對防火墻收到的所有報文都根據包過濾規則逐一檢查，以決定是否放行該報文。如圖1-4所示，PC（Personal Computer，個人計算機）和Web服務器分別位于防火墻的兩側，其通信由防火墻控制。我們希望PC可以訪問Web服務器。

圖1-4　PC訪問Web服務器組網圖

當PC向Web服務器發起訪問時，防火墻上必須已經配置了序號為1的安全策略，允許符合此條件的報文通過防火墻。PC在訪問Web服務器時使用的源端口可能是1024~65535范圍內的任意一個端口。這個值是不確定的，所以這里設定為任意端口（any）。有了這條安全策略，PC發出的報文才能順利通過防火墻，成功到達Web服務器。然后，Web服務器返回的響應報文也要穿過防火墻，才能到達PC。在包過濾防火墻上，用戶還需要配置序號為2的安全策略，允許響應報文通過。同樣的，由于PC的端口號是不確定的，這里的目的端口只能設置為任意端口。

這就意味著，序號為2的安全策略開放了PC的所有端口。攻擊者只要偽裝成Web服務器，就可以暢通無阻地穿過防火墻，訪問PC上的任意服務。這必然帶來極大的安全風險。此外，采用包過濾機制，防火墻要逐個檢查每一個通過防火墻的報文，也嚴重影響了防火墻的轉發效率。

為了解決這個問題，“狀態檢測防火墻”應運而生。我們仍以圖1-4所示的組網為例，來看一下何謂“狀態檢測”。首先，我們還是要在防火墻上配置序號為1的安全策略，允許PC訪問Web服務器，當PC訪問Web服務器的報文到達防火墻時，防火墻檢測安全策略，允許該報文通過。其次，防火墻為本次訪問建立一個會話，會話中包含了本次訪問的源/目的IP地址和源/目的端口等信息。會話是通信雙方建立的連接在防火墻上的具體體現，代表雙方的連接狀態，一個會話就表示通信雙方的一個連接。防火墻上多個會話的集合就是會話表（session table）。

[sysname] display firewall session table
Current Total Sessions : 1
  http VPN:public --> public 10.1.1.10:2049-->10.1.2.10:80

從上面的會話表中，我們可以清楚地看到，防火墻上有一條HTTP（Hypertext Transfer Protocol，超文本傳送協議）會話，會話的源IP地址為10.1.1.10，源端口為2049，目的IP地址為10.1.2.10，目的端口為80。源地址、源端口、目的地址、目的端口和協議這5個元素是會話的重要信息，我們將這5個元素稱為“五元組”。這5個元素相同的報文即可被認為屬于同一條流，在防火墻上通過這5個元素就可以唯一確定一條連接。

當Web服務器回復給PC的響應報文到達防火墻時，防火墻會把響應報文中的信息與會話中的信息進行比對。如果響應報文中的信息與會話中的信息相匹配，并且該報文符合HTTP規范的規定，就認為這個報文屬于PC訪問Web服務器行為的后續報文，直接允許這個報文通過。PC和Web服務器之間的后續報文都將匹配會話表轉發，不再匹配安全策略。

采用狀態檢測機制以后，我們只需要為業務請求的發起方向配置安全策略，就不需要圖1-4中序號為2的安全策略了。當攻擊者偽裝成Web服務器向PC發起訪問時，攻擊者發出的報文不屬于PC訪問Web服務器行為的響應報文，無法匹配會話表。同時防火墻上也沒有開放Web服務器訪問PC方向的安全策略，防火墻不會允許這些報文通過。這樣，既保證了PC可以正常訪問Web服務器，也避免了大范圍開放端口帶來的安全風險。

狀態檢測防火墻使用基于連接狀態的檢測機制，將通信雙方之間交互的屬于同一連接的所有報文都作為整體的數據流來對待。在狀態檢測防火墻看來，同一個數據流內的報文不再是孤立的個體，而是存在聯系的。為數據流的第一個報文建立會話，數據流內的后續報文直接匹配會話轉發，不需要再檢查安全策略。這種機制極大地提升了安全性和防火墻的轉發效率。

會話表是防火墻轉發報文的重要依據，會話表中記錄的信息也是定位防火墻轉發問題的重要參考。在查看會話表的命令中使用verbose參數，可以看到會話的更多信息。

<sysname> display firewall session table verbose
   Current total sessions: 1
   HTTP VPN: public --> public ID: a387f35dc86d0ca3624361940b0
   Zone: trust --> untrust Slot: 11 CPU: 0 TTL: 00:15:00 Left: 00:14:51
   Recv Interface: XGigabitEthernet0/0/3 Rev Slot: 12 CPU: 0
   Interface: XGigabitEthernet0/0/4 NextHop: 10.1.2.1
   <--packets: 30003 bytes: 4,488,438 --> packets: 15098 bytes: 3,113,948
   10.1.1.10:2049 --> 10.1.2.10:80 PolicyName: No1
   TCP State: fin-1

會話表中記錄的關鍵信息如表1-2所示。

表1-2　會話表信息詳解

上述信息中有兩個重點信息需要說明一下，首先是會話的老化時間，即TTL。會話是動態生成的，但不是永遠存在的。如果長時間沒有報文匹配，就說明通信雙方已經斷開了連接，不再需要這個會話了。此時，為了節約系統資源，防火墻會在一段時間后刪除會話，該時間被稱為會話的老化時間。

老化時間的取值非常重要。如果某種業務會話的老化時間過長，就會一直占用系統資源，有可能導致其他業務的會話不能正常建立；會話的老化時間過短，有可能導致該業務的連接被防火墻強行中斷，影響業務運行。華為防火墻已經針對不同的協議，設置了默認的老化時間，如ICMP（Internet Control Message Protocol，互聯網控制報文協議）會話的老化時間是20秒，DNS會話的老化時間是30秒等。通常情況下采用這些默認值就可以保證各個協議正常運行。如果需要調整默認值，可以通過firewall session aging-time命令來設置。例如，將DNS會話的老化時間調整為20秒。

[sysname] firewall session aging-time service-set dns 20

其次是報文統計信息，會話中“←”和“→”這兩個方向上的報文統計信息非常重要，可以幫助我們定位網絡故障。通常情況下，如果我們查看會話時發現只有“→”方向有報文的統計信息，“←”方向上的統計信息都是0，那就說明PC發往Web服務器的報文順利通過了防火墻，而Web服務器回應給PC的報文沒有通過防火墻，雙方的通信是不正常的。有可能是防火墻丟棄了Web服務器回應給PC的報文，防火墻與Web服務器之間的網絡出現故障，或者Web服務器本身出現故障。這樣我們就縮小了故障的范圍，有利于快速定位故障。