基于狀態檢測防火墻的“穿越”誤區

■ 湖北 楊華

編者按：在使用防火墻設備時難免會存在一些誤區，就比如本文所討論的ICMP協議數據包的“穿越”問題。本文對一些相關概念問題進行簡要的解析。

防火墻技術在網絡運維中占有重要的份量，也是一個專業網絡工程師必備的技能。但有些人由于對一些基本概念掌握不夠細致，在應用環境中，會產生一些誤區，多走不少彎路。本文針對初學者中比較常見的基于狀態檢測的流量穿越誤區進行剖析探討。

實驗環境

實驗環境包括EVE網絡模擬器，一臺防火墻ASA，兩臺三層交換機SW3-1與SW3-2，通過SW3-1模擬內網，SW3-2模擬外網，ASA上進行基本配置，內網訪問外網進行NAPT翻譯。如圖1所示。

實驗目的

通過本次實驗來驗證狀態防火墻，數據流量主動從高安全級別（inside或turst）到低安全級別（outside or untrust）是可以正常連接的（基于連接狀態檢測）。反之則會禁止，除非通過訪問策略放行。

實驗內容

在SW3-1通過Telnet遠程登錄到SW3-2上，可以正常訪問。

SW3-1#TELNET 200.0.0.1 //連接成功

圖1 實驗環境模擬圖

Trying 200.0.0.1 ...Open

User Access Verifi cation

Password:

ASA-5520# sh xlate//NAPT翻譯成功

1 in use,1 most used

TCP PAT from inside:192.168.1.1/18148 to out side:200.0.0.10/52167

原理分析

根據防火墻的訪問規則，從SW3-1出去到SW3-2的數據包是可以正常通行的，但回來的數據包是從低級別到高級別，不是應該被防火墻阻止的嗎？

這在之前的包過濾防火墻是這樣的，若要放行，需要配置大量的訪問控制策略，但在狀態檢測防火墻中它會檢測出去的數據流量連接狀態，發現它是一個從高級別發起到低級別的數據包，而且監控到連接信息，就會認定它是安全，回來時就默認放行了。

故障現象

對于初學者來講，能完成以上實驗配置，并分析其原理，應該非常成功了。但對于一個網絡工程師，怎么會放通過Ping去測試一下連通性這個下意識的動作呢？

通過發送SW3-1#ping 200.0.0.1之后發現，結果大失所望了，竟然不通。

通過抓包分析，在防火墻上ICMP數據已成功進行NAPT翻譯：

ASA-5520# sh xlate

2 in use,2 most used

ICMP PAT from inside:192.168.1.1/1 to outside:200.0.0.10/8154

但是回來的數據包被阻止了，通過輸入“debug icmp”，看不到回來的數據包了，這與上面的實驗結論是相背的。筆者開始分析是否防火墻上進行ICMP的過濾，但通過檢測并沒有。

原來，狀態檢測是基于TCP/UDP的連接來進行識別的，TCP默認是監控的，有狀態化信息，記錄源IP及目的IP、源端口及目的端口等信息，形成映射。所以回包的時候會對比這些映射信息，符合條件就放行了。而ICMP數據包并沒有通過TCP/UDP去承載，出去的時候ASA沒有記錄狀態化信息，沒有形成映射，所以回包的時候沒法對比，默認就丟掉了。

故障排除

對于一個優秀的網絡工程師來講，沒有什么解決不了的問題，雖然它并不影響實驗結果。該問題可以通過兩個方法來解決。

1.增加訪問控制策略

定義策略：access-list icmp_out extended permit icmp any any

策略應用：access-group icmp_out in int outside

2.增加狀態檢測監控協議數據包

ASA(config)# policymap global_policy //默認ASA有的global_policy

ASA(config-pmap)#class inspection_default//默認監控

ASA(config-pmap-c)#inspect icmp //增加icmp監控

ASA-5520# sh run | in inspect //再次顯示默認的監控列表

class-map inspection_default

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

……

inspect icmp

從以上監控列表不難看出，TCP和UDP是例外的，不在該范圍之內。FTP是動態應用，雖然有TCP的22、23端口，但是它的流量都是臨時產生的，FTP必須有用戶名和密碼的登錄。這就是動態的交互，也就是TCP上有特殊字段會被標記的，標記部分沒有告知ASA放行的話，ASA是不識別的，所以FTP比較特殊，這里仍讓能看到FTP的檢測。

技術延伸

細心的朋友會發現ICMP在做NAPT翻譯時，居然有對應的端口，眾所周知ICMP數據包本身是沒有端口號的。

經過反復實驗，筆者發現了其中的玄機。原來NAPT的端口轉換是為了區分inside local地址。

對于有端口的應用來說，一般轉換為較大的端口號從而避免和常用端口沖突。而對于一些沒有端口號的應用（比如ICMP）來說，所謂端口號僅僅是為了區分不同ICMP包，可以理解為就是特定的數字標記，不具有任何其他意義。通過不斷的Ping下去，端口號會一直增加，一個echo_request的端口數字對應一個echo_replay端口數字，和四層包頭的端口號沒有任何關系。

通過使用“SW3-1#ping 200.0.0.1”命令，筆者試著進行了兩次數據包的連接測試，結果如下：

ASA-5520# sh xlate

ICMP PAT from inside:192.168.1.1/3 to outside:200.0.0.10/45184

ICMP PAT from inside:192.168.1.1/2 to outside:200.0.0.10/56735

ASA在進行NAPT時，如果發現IP包頭中協議號為1，就會知道是ICMP的包，而不用考慮四層端口號，直接用一個端口數字標記轉換即可。

當然，不同的設備廠商可能有不同的處理機制，讓NAT通過一些特殊的字段來識別。

例如，在ICMP中有Iden tifier和Sequence Number，identifier用來辨別不同的Ping流程。比如我們啟動兩個控制臺窗口，分別輸入Ping命令，就會運行兩個不同的Ping進程。這兩個Ping進程就依靠不同的identifier來區分。而一次Ping過程不止發送一個數據包，如果一次發送多個數據包，那么同一個Ping流程內就用sequence number把不同的數據包給區分開來，這個字段一般都是遞增的。

實驗心得

不同廠商的防火墻設備可能有不同的處理機制，為了方便用戶，可能隱藏了一些我們未知的技術細節，比如上面的ICMP協議數據包的監控。