防火墻相關(guān)知識之第二篇：淺談狀態(tài)檢測防火墻和應用層防火墻的原理（結合ISA SERVER）
防火墻相關(guān)知識之第一篇：防火墻的工作原理
http://www.winmag.com.cn/forum/itemdisplay.asp?boardid=14&id=429283(作者：Kevin Whistler)
--------------------------------------------------------------------------------
防火墻相關(guān)知識之第二篇：淺談狀態(tài)檢測防火墻和應用層防火墻的原理（結合ISA SERVER)
-------------------------作者：shukoshi------------------------------------
防火墻發(fā)展到今天，雖然不斷有新的技術(shù)產(chǎn)生，但從網(wǎng)絡(luò )協(xié)議分層的角度，仍然可以歸為以下三類(lèi)：
1， 包過(guò)濾防火墻；
2， 基于狀態(tài)檢測技術(shù)(Stateful-inspection)的防火墻；
3， 應用層防火墻。
這三類(lèi)防火墻都是向前包容的，也就是說(shuō)基于狀態(tài)檢測的防火墻也有一般包過(guò)濾防火墻的功能，而基于應用層的防火墻也包括前兩種防火墻的功能。在這里我將講講后面兩類(lèi)防火墻的實(shí)現原理。
先從基于狀態(tài)檢測的防火墻開(kāi)始吧，為什么會(huì )有基于狀態(tài)檢測的防火墻呢?這就要先看看第一類(lèi)普通包過(guò)濾防火墻的主要缺點(diǎn)，比如我們要允許內網(wǎng)用戶(hù)訪(fǎng)問(wèn)公網(wǎng)的WEB服務(wù)，來(lái)看看第一類(lèi)普通包過(guò)濾防火墻是怎樣處理的呢?那首先我們應該建立一條類(lèi)似圖1所示的規則：
但這就行了嗎?顯然是不行的，因為這只是允許我向外請求WEB服務(wù)，但WEB服務(wù)響應我的數據包怎么進(jìn)來(lái)呢?所以還必須建立一條允許相應響應數據包進(jìn)入的規則。好吧，就按上面的規則加吧，在動(dòng)作欄中我們填允許，由于現在數據包是從外進(jìn)來(lái)，所以源地址應該是所有外部的，這里不做限制，在源端口填80，目標地址也不限定，這個(gè)這個(gè)目標端口怎么填呢?因為當我訪(fǎng)問(wèn)網(wǎng)站時(shí)本地端口是臨時(shí)分配的，也就是說(shuō)這個(gè)端口是不定的，只要是1023以上的端口都有可能，所以沒(méi)有辦法，那只有把這些所有端口都開(kāi)放了，于是在目標端口填上1024-65535，這樣規則就如圖2所示了，實(shí)際上這也是某些第一類(lèi)防火墻所采用的方法。
想一想這是多么危險的，因為入站的高端口全開(kāi)放了，而很多危險的服務(wù)也是使用的高端口啊，比如微軟的終端服務(wù)/遠程桌面監聽(tīng)的端口就是3389，當然對這種固定的端口還好說(shuō)，把進(jìn)站的3389封了就行，但對于同樣使用高端口但卻是動(dòng)態(tài)分配端口的RPC服務(wù)就沒(méi)那么容易處理了，因為是動(dòng)態(tài)的，你不便封住某個(gè)特定的RPC服務(wù)。
上面說(shuō)了這是某些普通包過(guò)濾防火墻所采用的方法，為了防止這種開(kāi)放高端口的風(fēng)險，于是一些防火墻又根據TCP連接中的ACK位值來(lái)決定數據包進(jìn)出，但這種方法又容易導致DoS攻擊，何況UDP協(xié)議還沒(méi)有這種標志呢?所以普通包過(guò)濾防火墻還是沒(méi)有解決這個(gè)問(wèn)題，我們仍然需要一種更完美的方法，這時(shí)就有了狀態(tài)檢測技術(shù)，我們先不解釋什么是狀態(tài)檢測防火墻，還是來(lái)看看它是怎樣處理上面的問(wèn)題的。同上面一樣，首先我們也需要建立好一條類(lèi)似圖1的規則(但不需要圖2的規則)，通常此時(shí)規則需要指明網(wǎng)絡(luò )連接的方向，即是進(jìn)還是出，然后我在客戶(hù)端打開(kāi)IE向某個(gè)網(wǎng)站請求WEB頁(yè)面，當數據包到達防火墻時(shí)，狀態(tài)檢測引擎會(huì )檢測到這是一個(gè)發(fā)起連接的初始數據包(由SYN標志)，然后它就會(huì )把這個(gè)數據包中的信息與防火墻規則作比較，如果沒(méi)有相應規則允許，防火墻就會(huì )拒絕這次連接，當然在這里它會(huì )發(fā)現有一條規則允許我訪(fǎng)問(wèn)外部WEB服務(wù)，于是它允許數據包外出并且在狀態(tài)表中新建一條會(huì )話(huà)，通常這條會(huì )話(huà)會(huì )包括此連接的源地址、源端口、目標地址、目標端口、連接時(shí)間等信息，對于TCP連接，它還應該會(huì )包含序列號和標志位等信息。當后續數據包到達時(shí)，如果這個(gè)數據包不含SYN標志，也就是說(shuō)這個(gè)數據包不是發(fā)起一個(gè)新的連接時(shí)，狀態(tài)檢測引擎就會(huì )直接把它的信息與狀態(tài)表中的會(huì )話(huà)條目進(jìn)行比較，如果信息匹配，就直接允許數據包通過(guò)，這樣不再去接受規則的檢查，提高了效率，如果信息不匹配，數據包就會(huì )被丟棄或連接被拒絕，并且每個(gè)會(huì )話(huà)還有一個(gè)超時(shí)值，過(guò)了這個(gè)時(shí)間，相應會(huì )話(huà)條目就會(huì )被從狀態(tài)表中刪除掉。就上面外部WEB網(wǎng)站對我的響應包來(lái)說(shuō)，由于狀態(tài)檢測引擎會(huì )檢測到返回的數據包屬于WEB連接的那個(gè)會(huì )話(huà)，所以它會(huì )動(dòng)態(tài)打開(kāi)端口以允許返回包進(jìn)入，傳輸完畢后又動(dòng)態(tài)地關(guān)閉這個(gè)端口，這樣就避免了普通包過(guò)濾防火墻那種靜態(tài)地開(kāi)放所有高端端口的危險做法，同時(shí)由于有會(huì )話(huà)超時(shí)的限制，它也能夠有效地避免外部的DoS攻擊，并且外部偽造的ACK數據包也不會(huì )進(jìn)入，因為它的數據包信息不會(huì )匹配狀態(tài)表中的會(huì )話(huà)條目。
上面雖然是講的針對TCP(WEB服務(wù))連接的狀態(tài)檢測，但這同樣對UDP有效，雖然UDP不是像TCP那樣有連接的協(xié)議，但狀態(tài)檢測防火墻會(huì )為它創(chuàng )建虛擬的連接。
相對于TCP和UDP來(lái)說(shuō)，ICMP的處理要難一些，但它仍然有一些信息來(lái)創(chuàng )建虛擬的連接，關(guān)鍵是有些ICMP數據包是單向的，也就是當TCP和UDP傳輸有錯誤時(shí)會(huì )有一個(gè)ICMP數據包返回。對于ICMP的處理，不同的防火墻產(chǎn)品可能不同的方法，在ISA
SERVER
2000中，不支持ICMP的狀態(tài)檢查，只能靜態(tài)地允許或拒絕ICMP包的進(jìn)出。
從上面可以看出，基于狀態(tài)檢測的防火墻較好的解決了第一類(lèi)普通包過(guò)濾防火墻的問(wèn)題，為了更直觀(guān)的理解狀態(tài)檢測防火墻，我們還來(lái)看看一些實(shí)際例子，這些例子都是在ISA
SERVER
2000上的表現。
(1)感受會(huì )話(huà)超時(shí)的限制
還是舉一個(gè)能說(shuō)明問(wèn)題的例子，比如大家熟悉的QQ(QQ2003II)，為什么你一直不聊天和做其他動(dòng)作仍然能夠收到從騰訊服務(wù)器上發(fā)來(lái)的廣告信息呢?肯定不是這個(gè)連接到騰訊服務(wù)器的QQ會(huì )話(huà)永不超時(shí)，其實(shí)你用sniffer軟件一看就知道了，這是因為QQ每到一分鐘時(shí)(但還沒(méi)到一分鐘)就會(huì )主動(dòng)與騰訊服務(wù)器聯(lián)系一次，這種聯(lián)系對防火墻后的QQ是非常重要的，通常來(lái)說(shuō)，對于UDP協(xié)議，會(huì )話(huà)超時(shí)都是一分鐘或小于一分鐘，另外windows
2000中UDP端口的NAT映射期也只有一分鐘，它在一分鐘之內聯(lián)系，這樣就會(huì )在防火墻狀態(tài)表中保持它的會(huì )話(huà)，不至于會(huì )話(huà)被刪除，想像一下，如果它不這樣聯(lián)系的話(huà)，一分鐘后這條會(huì )話(huà)被刪除，而剛好此時(shí)騰訊有個(gè)廣告要傳給你，那么你是不能收到的，當然其他從騰訊服務(wù)器上來(lái)的消息也不能收到，這是因為會(huì )話(huà)中已沒(méi)有了匹配的條目，而規則中又沒(méi)有靜態(tài)打開(kāi)的入站端口。當然上面的分析是從用戶(hù)的角度來(lái)說(shuō)的，從騰訊的角度來(lái)說(shuō)，它也需要獲知用戶(hù)的連接狀態(tài)，所以也需要定時(shí)通信，這已不在我們的討論范圍之內了。除了QQ，MSN
Messenger也是這樣的。
(2)動(dòng)態(tài)地打開(kāi)入站端口
首先我已在ISA
SERVER
2000中的protocol
rules下定義了一條允許所有客戶(hù)端訪(fǎng)問(wèn)外部WEB網(wǎng)站的規則，如圖3，
注意上面只明確定義了出站的規則，沒(méi)有明確定義入站的規則，這是因為有狀態(tài)檢測技術(shù)起作用，我們用不著(zhù)為上面的規則配套一條明確的入站規則。圖4是我在客戶(hù)端打開(kāi)網(wǎng)頁(yè)時(shí)在ISA服務(wù)器上進(jìn)行sniffer的結果，第一行是一個(gè)帶有SYN標志的初始化連接的數據包，本地端口是22870，第二行是對方回應的數據包，由于與第一行屬于同一個(gè)會(huì )話(huà)，防火墻已經(jīng)為它動(dòng)態(tài)地打開(kāi)端口22870以便進(jìn)入。
上面我們感受了狀態(tài)檢測防火墻的強大功能，但由于狀態(tài)檢測防火墻畢竟是工作在網(wǎng)絡(luò )層和傳輸層的，所以它仍然有一些不能解決的問(wèn)題需要在應用層來(lái)進(jìn)行解決，比如對于動(dòng)態(tài)分配端口的RPC就必須作特殊處理；另外它也不能過(guò)濾掉應用層中特定的內容，比如對于http內容，它要么允許進(jìn)，要么允許出，而不能對http內容進(jìn)行過(guò)濾，這樣我們就不能控制用戶(hù)訪(fǎng)問(wèn)的WEB內容，也不能過(guò)濾掉外部進(jìn)入內網(wǎng)的惡意HTTP內容，另外，它也不能對用戶(hù)進(jìn)行認證，為了解決這些問(wèn)題，我們還必須把防火墻的過(guò)濾層次擴展到應用層，這就是應用層防火墻，不過(guò)這種稱(chēng)呼似乎有點(diǎn)不準，也許叫應用層級的狀態(tài)檢測防火墻更合適，其實(shí)今天比較大型的商業(yè)防火墻都應該是這個(gè)級別的防火墻了，比如微軟的ISA
SERVER
2000就是，在ISA中這種應用層的過(guò)濾就表現為應用程序過(guò)濾器(Application
Filters)，下面來(lái)看看應用層防火墻的處理過(guò)程。
如前文所述，當數據包在網(wǎng)絡(luò )層和傳輸層通過(guò)檢查之后，它就被送到應用層繼續進(jìn)行檢查，不同的應用協(xié)議送到不同的應用協(xié)議過(guò)濾器，比如是SMTP數據包，它就會(huì )送到SMTP過(guò)濾器，在ISA
SERVER
2000中，該篩選器攔截并核對SMTP
電子郵件通信，保護郵件服務(wù)器免受攻擊。該篩選器識別不安全的命令并且可以篩選電子郵件信息的內容或者大小，在未經(jīng)同意的電子郵件到達郵件服務(wù)器之前將其拒絕。只有匹配過(guò)濾器規則的數據包才會(huì )允許通過(guò)防火墻。
但應用層的過(guò)濾也有缺點(diǎn)，就是得針對每種應用協(xié)議開(kāi)發(fā)一種過(guò)濾器，而對于一種具體的應用協(xié)議過(guò)濾器，它也是需要不斷發(fā)展的，因為應用協(xié)議在發(fā)展，再說(shuō)還不斷有新的應用協(xié)議產(chǎn)生，并且由于數據包要經(jīng)過(guò)應用層過(guò)濾器的再次檢查，這無(wú)疑會(huì )降低網(wǎng)絡(luò )傳輸效率。而對于使用動(dòng)態(tài)端口協(xié)議的處理這種防火墻最頭痛的事情，即使在應用層上來(lái)解決也不是一件容易的事，RPC也許不是問(wèn)題了，因為它使用了這么多年，各種防火墻對它都已經(jīng)有了比較成熟的解決方案，比如ISA
SERVER
2000中就有專(zhuān)門(mén)的RPC
filter來(lái)對它進(jìn)行處理，但對于一些比較新的且也使用動(dòng)態(tài)端口的協(xié)議就不好辦了，比如用于即時(shí)通信中的SIP協(xié)議等諸多協(xié)議都要使用動(dòng)態(tài)端口，由于沒(méi)有即時(shí)的過(guò)濾器推出，使用這些協(xié)議的網(wǎng)絡(luò )應用程序在防火墻后通常都會(huì )有連接故障，我想那些在防火墻后使用MSN
Messenger的朋友一定深有體會(huì )(當使用除即時(shí)文字聊天和文件傳輸以外的功能時(shí))，不過(guò)，現在也有了一種比較全面地來(lái)解決這種使用動(dòng)態(tài)端口協(xié)議的方案，那就是在防火墻中添加UPnP協(xié)議的支持，這樣那些支持UPnP的網(wǎng)絡(luò )應用程序(如MSN
Messenger
6.1)就能夠自動(dòng)去發(fā)現防火墻并在防火墻上動(dòng)態(tài)地打開(kāi)端口，這樣就無(wú)需在防火墻上去進(jìn)行進(jìn)退兩難的手動(dòng)配置。不過(guò)遺憾的是，雖然UPnP有效的解決了動(dòng)態(tài)端口的問(wèn)題，但它也帶來(lái)了新的安全問(wèn)題，所以在安全性要求較高的網(wǎng)絡(luò )中是不適宜開(kāi)啟UPnP功能的?？赡芤彩怯捎诎踩虬?，現在支持UPnP的防火墻還很少，據我所知，Kerio
winroute
firewall5和windows
XP上的ICF是支持UPnP的。
注：本文未探討另一類(lèi)工作在應用層的防火墻，即代理服務(wù)器，也被稱(chēng)做應用代理網(wǎng)關(guān)。
