信息安全基礎知識筆記04防火牆應用層報文過濾ASPF
上一節筆記已經介紹了防火牆在模擬器軟件eNSP拓撲搭建的基本方法，區域間轉發策略的配置以及如何查看會話表，以后的實驗均會在其基礎上進行。
本節筆記主要介紹防火牆的一種高級通信過濾機制 -- 應用層報文過濾ASPF。這是針對應用層的包過濾技術，即基於狀態的報文過濾。最后再簡單闡述防火牆的分片緩存，長連接的概念。
多通道協議技術
在理解ASPF技術前，首先我們需要知道什么叫多通道協議技術。
單通道協議技術：通信過程中只需占用一個端口的協議。如：WWW只需占用80端口。
多通道協議技術：通信過程中需占用兩個或兩個以上端口的協議。如+FTP被動模式下需占用21號端口以及一個隨機端口。
大部分多媒體應用協議（如H.323、SIP）、FTP、netmeeting等協議使用約定的固定端口來初始化一個控制連接，再動態的選擇端口用於數據傳輸。端口的選擇是不可預測的，其中的某些應用甚至可能要同時用到多個端口。
我們用文件傳輸協議（FTP）來舉個例子，簡單介紹一下這個應用層協議的實現原理。
FTP有主動連接（PORT）和被動連接（PASV）兩種工作方式。首先，兩種方式默認都是通過TCP 21端口來進行控制連接的。即建立一條傳輸命令的通道，該連接用於下達對文件進行上傳，下載等操作命令。
建立控制連接后，需要再建立一條用於傳輸數據的通道，而建立的方式分為主動和被動兩種。
主動方式（PORT）即客戶端打開一個隨機端口（x），並將該端口告知服務器端，最后由服務器端（使用端口TCP 20）向客戶端發起數據連接。
被動方式（PASV）即服務器端打開一個隨機端口（大於TCP 1024），並將該端口告知客戶端，最后由客戶端向服務器端發起數據連接。
假設現在內網中有一台主機（Trust區域）希望通過防火牆訪問外網的FTP服務器（Untrust區域），防火牆上只配置了一條允許Trust區域訪問Untrust區域（出方向）的安全策略。
如果此時建立數據連接的是主動方式，那么就需要處於Untrust區域的FTP服務器使用TCP 20端口訪問Trust區域的內網主機，但很明顯防火牆並沒有入方向的訪問策略，這樣就會導致無法正常建立FTP連接。
傳統的包過濾防火牆可以通過配置ACL過濾規則匹配單通道協議的應用傳輸，保障內部網絡不受攻擊，但只能阻止一些使用固定端口的應用，無法匹配使用協商出隨機端口傳輸數據的多通道協議應用，留下了許多安全隱患。
Tips：參考資料 FTP的基本原理
https://www.cnblogs.com/zylSec/p/14702823.html
應用層報文過濾技術ASPF
ASPF ( Application Specific Packet Filter) 是一種高級通信過濾，它檢查應用層協議信息並且監控連接的應用層協議狀態。對於特定應用協議的所有連接，每一個連接狀態信息都將被ASPF維護並用於動態的決定數據包是否被允許通過防火牆或丟棄。
（1）ASPF概述
① ASPF在session表的數據結構中維護着連接的狀態信息，並利用這些信息來維護會話的訪問規則。
ASPF保存着不能由訪問控制列表規則保存的重要的狀態信息。防火牆檢驗數據流中的每一個報文，確保報文的狀態與報文本身符合用戶所定義的安全規則。連接狀態信息用於智能的允許/禁止報文。當一個會話終止時，session表項也將被刪除，防火牆中的會話也將被關閉。
② ASPF可以智能的檢測“TCP的三次握手的信息”和“拆除連接的握手信息”。
通過檢測握手、拆連接的狀態檢測，保證一個正常的TCP訪問可以正常進行，而對於非完整的TCP握手連接的報文會直接拒絕。
③ ASPF是基於連接的。
ASPF將對UDP報文（UDP報文時無連接的）的源、目的IP地址、端口進行檢查，通過判斷該報文是否與所設定的時間段內的其他UDP報文相類似，而近似判斷是否存在一個連接。
④ 在普通的場合，一般使用的是基於ACL的IP包過濾技術，這種技術比較簡單，但缺乏一定的靈活性，在很多雜應用的場合普通包過濾是無法完成對網絡的安全保護的。例如對於類似於應用FTP協議進行通信的多通道協議來說，配置防火牆則是非常困難的。
ASPF使防火牆能夠支持一個控制連接上存在多個數據連接的協議，同時還可以在應用非常復雜的情況下方便的制訂各種安全的策略。ASPF監聽每一個應用的每一個連接所使用的端口，打開合適的通道讓會話中的數據能夠出入防火牆，在會話結束時關閉該通道，從而能夠對使用動態端口的應用實施有效的訪問控制。
Tips：以上提到的session表，即防火牆保存會話狀態的會話表。
（2）ASPF對多通道協議的支持
ASPF（Application Specific Packet Filter）是針對應用層的包過濾。
在多通道協議中（如FTP協議），控制通道和數據通道是分開的。數據通道是在控制報文中動態協商出來的，為了避免協商出來的通道不因其他規則的限制（如ACL）而中斷，需要臨時開啟一個通道，Servermap就是為了滿足這種應用而設計的一種數據結構。
FTP包含一個預知端口的TCP控制通道和一個動態協商的TCP數據通道，對於一般的包過濾防火牆來說，配置安全策略時無法預知數據通道的端口號，因此無法確定數據通道的入口，這樣就無法配置准確的安全策略。ASPF技術則解決了這一問題。ASPF檢測IP層之上的應用層報文信息，並動態地根據報文的內容創建和刪除臨時的servermap表項，以允許相關的報文通過。
還是用回這張拓撲圖，詳細配置省略。使用Trust區域的FTP client訪問Untrust區域的FTP server：
可以看到此時防火牆的會話表中，除了有FTP的控制通道產生的表項（從Trust區域到Untrust去取的出方向）外，還有數據通道產生的表項（從Untrust區域到Trust區域的入方向）。產生這樣表項的原因就是防火牆應用了ASPF技術。
同樣，我們通過命令查看生產的Server Map表項如下圖所示：
Server Map表項是對FTP控制通道中動態檢測過程中動態產生的。當報文通過防火牆時，ASPF將報文與指定的訪問規則進行比較。如果規則允許，報文將接受檢查，否則報文直接被丟棄。如果該報文是用於打開一個新的控制或數據連接，ASPF將動態的產生servermap表項，對於回來的報文當且僅當屬於一個已經存在的有效的連接，才會被允許通過防火牆。在處理回來的報文時，狀態表也需要更新。當一個連接被關閉或超時后，該連接對應的狀態表將被刪除，確保未經授權的報文不能隨便透過防火牆。因此通過ASPF技術可以保證在應用復雜的情況下，依然可以非常精確的保證網絡的安全。
Server-map是一種映射關系，當數據連接匹配了動態Server-map表項時，不需要再查找包過濾策略，保證了某些特殊應用的正常轉發。當然還有另一種情況是，當數據連接匹配Server-map表，會對報文中IP和端口進行轉換。
Server-map通常只是檢查首個報文，通道建立后的報文還是根據會話表來轉發。
（3）Server Map表的產生
目前，FW上生成Server-map表項共有如下幾種情況：
① 配置ASPF后，轉發FTP、RTSP等多通道協議時生成的Server-map表項。
② 配置ASPF后，轉發QQ/MSN、TFTP等STUN類型協議時生成的三元組Server-map表項。
③ 配置NAT服務器映射時生成的靜態Server-map。
④ 配置NAT No-PAT時生成的動態Server-map。
⑤ 配置NAT Full-cone時生成的動態Server-map。
⑥ 配置PCP時生成的動態Server-map。
⑦ 配置服務器負載均衡時生成的靜態Server-map。
⑧ 配置DS-Lite場景下NAT Server時生成的動態Server-map。
⑨ 配置靜態NAT64時生成的靜態Server-map。
多通道協議會由客戶端和服務器之間的控制通道動態協商出數據通道，即通信雙方的端口號是不固定的。而在配置ASPF功能后，設備檢測到控制通道的協商，根據關鍵報文載荷中的地址信息動態創建server-map表項，用於數據通道發起連接時進行查找。這個server-map表項包含了多通道協議報文中協商的數據通道的信息。
QQ/MSN等協議中，當用戶登錄之后，用戶的IP地址和端口就固定下來了，可是會向該用戶發起對話的另一方的IP地址和端口號是不固定的。通過配置STUN類型的ASPF，當QQ或者MSN等用戶連接服務器時，設備會記錄下用戶的IP地址和端口信息，並動態生成STUN類型的Server-map。
Tips：這個server-map表項中僅包含三元組信息，即通信一方的IP地址，端口號和協議號。這樣其他用戶可以直接通過該IP和端口與該用戶進行通信。
（4）端口識別對多通道協議的支持
端口識別是把非標准協議端口映射成可識別的應用協議端口。
試想實際工作中的例子：有時候網絡中的服務器不一定會使用標准規定的協議端口號。其會把監聽端口號改為一個非標准協議端口號。如下圖中例子。FTP Server偵聽的端口號從21改為31。
若防火牆制定以下安全策略：
且開啟了應用層的高級通信過濾ASPF技術（是的，命令就是這么簡單）：
若此時FTP Client通過主動方式（PORT）向FTP Server發起FTP連接，ASPF技術會面臨什么問題呢？我們可以按步驟分析：
Step 1：首先，FTP Client與FTP Server建立控制連接后，FTP Client會打開隨機端口，並告訴FTP Server可以通過連接這個隨機端口，來建立數據連接。一般正常情況下，FTP Server會使用端口TCP 20向FTP Client發起數據連接。
Step 2：打開了ASPF功能的防火牆，檢測到了FTP協議的控制連接的協商，其會生成一個Server Map表項，當FTP Server使用 ，其IP作為源地址發回建立數據連接的請求報文時，防火牆會給予放行。
詳細例子如下：當防火牆檢測到FTP Client（10.0.0.1）使用TCP 21端口向FTP Server（20.0.0.1）發起建立控制連接時，會在其會話表生成一個表項：
10.0.0.1:隨機端口 --> 20.0.0.1:21
防火牆根據ASPF技術檢測到其為多通道協議流量，還需要打開一條新的連接。則自動生成一個Server Map表項，用於匹配回程的流量。對於回程流量當且僅當屬於一個已經存在的有效的連接，才會被允許通過防火牆：
20.0.0.1 --> 10.0.0.1:隨機端口
如下圖所示：FTP服務器此時打開的監聽端口號為21。
使用FTP Client發起連接，可以正常訪問。
正是因為有了ASPF的映射關系，FTP Server才能向FTP Client傳輸數據，否則將會被防火牆拒絕。
Tips：這里必須選擇主動方式（PORT），才能看到實驗效果。若選擇被動方式（PASV）。則無論控制通道和數據通道連接的發起都是從Trust區域到Untrust區域的出方向的。
Step 3：若現在FTP Server監聽的端口改為TCP 31后，則FTP Client向FTP Server發起控制連接時使用的目的端口會改為TCP 31。
如下圖所示：若將FTP服務器監聽的端口號改為TCP 31。
則會顯示連接失敗，連接服務器超時。
此時查看防火牆的會話表，發現只有一條FTP Client（10.0.0.1）使用隨機端口訪問FTP Server（20.0.0.1）的TCP 31端口的會話。但防火牆並沒有將該會話識別為FTP流量，而只是單單識別為普通的TCP連接。如下圖所示：
因為FTP Server使用了非知名端口提供FTP服務，導致防火牆沒有識別這條會話流量來啟用ASPF技術。
Step 4：當用戶使用非知名端口提供知名應用服務時，可以配置端口映射功能（port-mapping）使防火牆能夠把該業務識別為知名應用，便於防火牆對該業務的數據進行准確的處理。
首先創建一條基本ACL（訪問控制列表）來匹配流量。
端口識別基於ACL進行，只有匹配某條ACL的報文，才會實施端口映射。端口映射在使用ACL過濾報文時，使用報文的目的IP地址去匹配基本ACL中配置的源IP地址。
Tips：端口映射只能使用基本ACL（編號2000～2999）。
然后配置端口映射（或端口識別）。
端口映射功能只對安全域間的數據流動生效，因此在配置端口映射時，也必須配置安全區域和安全域間。
如下圖所示：配置端口映射后，FTP Client就可以正常訪問FTP Server了。
此時可以在會話表看到，防火牆將該條流量識別為FTP流量，並在建立一條控制連接的基礎上，還生成了一條從FTP Server到FTP Client的數據連接。證明了現在可以正常建立FTP連接。
端口映射是對訪問某個特定IP地址（例如FTP服務器）的報文進行應用識別，因此在匹配基本ACL規則時，使用報文的目的地址去匹配ACL規則中定義的源地址。
Tips：關於端口映射需要注意的事項
① 配置端口映射時，一個應用可以配置多個映射端口，一個端口可以映射為多個應用。但是必須通過ACL進行區分，匹配不同ACL的報文使用不同的映射關系。
② 端口映射支持的應用層協議包括FTP、HTTP、RTSP、PPTP、MGCP、MMS、SMTP、H323、SIP、SQLNET。
分片緩存
分片緩存功能用來緩存先於首片分片報文到達的后續分片報文，避免分片報文被防火牆丟棄。
網絡設備在傳輸報文時，如果設備上配置的MTU（Maximum Transfer Unit）小於報文長度，則會將報文分片后繼續發送。
我們知道，狀態檢測防火牆是依據首包檢測機制進行過濾報文的，即防火牆除首包（如TCP的SYN包）可以生成會話表項外，其他數據包一律會予以丟棄。在理想情況下，各分片報文將按照固定的先后順序在網絡中傳輸。在實際傳輸過程中，可能存在首片分片報文不是第一個到達防火牆的現象，那么，就有可能發生非首片分片報文最先到達防火牆的情況，則防火牆予以丟棄。
為保證會話的正常進行，缺省情況下，防火牆支持分片緩存功能。設備會將非首片的分片報文緩存至分片散列表，等待首片到來建立會話后，將所有分片報文進行轉發。若在指定的時間內首片分片報文沒有到來，防火牆將丟棄分片緩存中的分片報文。
以下是實際應用中用到分片緩存功能的例子：
① 在VPN應用中(如IPSEC和GRE)，由於需要設備對分片報文進行重組后解密或者解封裝，設備才能進行后續處理，所以必須將設備配置成分片緩存狀態，完成原始報文重組之后，才可以進行相應的加密解密處理。
② 在NAT應用中，需要設備對分片報文進行重組后才能正常解析和轉換報文中的IP地址，所以也必須將設備配置成分片緩存狀態，才可以正常進行NAT。
分片報文直接轉發功能一般用在不進行NAT轉換的情況下。開啟該功能后，防火牆將收到的分片報文直接轉發出去，不創建會話表。
命令：Firewall session aging-time fragment interval (1-40000)
配置分片緩存老化時間。
命令：Firewall fragment-forward enable/disable
開啟/關閉分片報文直接轉發功能。
長連接
為什么需要長連接？
① 防火牆會話表老化機制
當一個TCP會話的兩個連續報文到達防火牆的時間間隔大於該會話的老化時間時，為保證網絡的安全性，防火牆將從會話表中刪除相應會話信息。這樣，后續報文到達防火牆后，防火牆將丟棄該報文，導致連接中斷。
② 會話老化機制給特殊業務帶來的問題
在實際的網絡環境中，某些特殊的業務數據流的會話信息需要長時間不被老化。
為了解決這一問題，防火牆支持在安全域間配置長連接功能，通過引用ACL定義數據流規則，為匹配ACL規則的特定報文的會話設置超長老化時間，確保會話正常進行。
Tips：關於長連接的必須知道的知識點
① 缺省情況下，長連接的老化時間為168小時（7*24小時）。
② 防火牆僅支持對TCP協議報文配置域間長連接功能。
③ 狀態檢測機制關閉時，非首包也可以建立會話表，所以此時不需使用長連接功能也可保持業務的正常運行。
命令：Firewall long-link aging-time time
配置長連接老化時間。
命令：Firewall interzone zone-name1 zone-name2
long-link acl-number { inbound | outbound }
開啟長連接功能。