防火墻發展到今天，雖然不斷有新的技術產生，但從網絡協議分層的角度，仍然可以歸為以下三類：1， 包過濾防火墻；2， 基于狀態檢測技術(Stateful-inspection)的防火墻；3， 應用層防火墻。這三類防火墻都是向前包容的，也就是說基于狀態檢測的防火墻也有一般包過濾防火墻的功能，而基于應用層的防火墻也包括前兩種防火墻的功能。在這里我將講講后面兩類防火墻的實現原理。先從基于狀態檢測的防火墻開始吧，為什么會有基于狀態檢測的防火墻呢?這就要先看看第一類普通包過濾防火墻的主要缺點，比如我們要允許內網用戶訪問公網的WEB服務，來看看第一類普通包過濾防火墻是怎樣處理的呢?那首先我們應該建立一條類似圖1所示的規則：
但這就行了嗎?顯然是不行的，因為這只是允許我向外請求WEB服務，但WEB服務響應我的數據包怎么進來呢?所以還必須建立一條允許相應響應數據包進入的規則。好吧，就按上面的規則加吧，在動作欄中我們填允許，由于現在數據包是從外進來，所以源地址應該是所有外部的，這里不做限制，在源端口填80，目標地址也不限定，這個這個目標端口怎么填呢?因為當我訪問網站時本地端口是臨時分配的，也就是說這個端口是不定的，只要是1023以上的端口都有可能，所以沒有辦法，那只有把這些所有端口都開放了，于是在目標端口填上1024-65535，這樣規則就如圖2所示了，實際上這也是某些第一類防火墻所采用的方法。
想一想這是多么危險的，因為入站的高端口全開放了，而很多危險的服務也是使用的高端口啊，比如微軟的終端服務/遠程桌面監聽的端口就是3389，當然對這種固定的端口還好說，把進站的3389封了就行，但對于同樣使用高端口但卻是動態分配端口的RPC服務就沒那么容易處理了，因為是動態的，你不便封住某個特定的RPC服務。上面說了這是某些普通包過濾防火墻所采用的方法，為了防止這種開放高端口的風險，于是一些防火墻又根據TCP連接中的ACK位值來決定數據包進出，但這種方法又容易導致DoS攻擊，何況UDP協議還沒有這種標志呢?所以普通包過濾防火墻還是沒有解決這個問題，我們仍然需要一種更完美的方法，這時就有了狀態檢測技術，我們先解釋什么是狀態檢測防火墻，還是來看看它是怎樣處理上面的問題的。同上面一樣，
首先我們也需要建立好一條類似圖1的規則(但不需要圖2的規則)，通常此時規則需要指明網絡連接的方向，即是進還是出，然后我在客戶端打開IE向某個網站請求WEB頁面，當數據包到達防火墻時，狀態檢測引擎會檢測到這是一個發起連接的初始數據包(由SYN標志)，然后它就會把這個數據包中的信息與防火墻規則作比較，如果沒有相應規則允許，防火墻就會拒絕這次連接，當然在這里它會發現有一條規則允許我訪問外部WEB服務，于是它允許數據包外出并且在狀態表中新建一條會話，通常這條會話會包括此連接的源地址、源端口、目標地址、目標端口、連接時間等信息，對于TCP連接，它還應該會包含序列號和標志位等信息。當后續數據包到達時，如果這個數據包不含SYN標志，也就是說這個數據包不是發起一個新的連接時，狀態檢測引擎就會直接把它的信息與狀態表中的會話條目進行比較，如果信息匹配，就直接允許數據包通過，這樣不再去接受規則的檢查，提高了效率，如果信息不匹配，數據包就會被丟棄或連接被拒絕，并且每個會話還有一個超時值，過了這個時間，相應會話條目就會被從狀態表中刪除掉。
就上面外部WEB網站對我的響應包來說，由于狀態檢測引擎會檢測到返回的數據包屬于WEB連接的那個會話，所以它會動態打開端口以允許返回包進入，傳輸完畢后又動態地關閉這個端口，這樣就避免了普通包過濾防火墻那種靜態地開放所有高端端口的危險做法，同時由于有會話超時的限制，它也能夠有效地避免外部的DoS攻擊，并且外部偽造的ACK數據包也不會進入，因為它的數據包信息不會匹配狀態表中的會話條目。 上面雖然是講的針對TCP(WEB服務)連接的狀態檢測，但這同樣對UDP有效，雖然UDP不是像TCP那樣有連接的協議，但狀態檢測防火墻會為它創建虛擬的連接。 相對于TCP和UDP來說，ICMP的處理要難一些，但它仍然有一些信息來創建虛擬的連接，關鍵是有些ICMP數據包是單向的，也就是當TCP和UDP傳輸有錯誤時會有一個ICMP數據包返回。對于ICMP的處理，不同的防火墻產品可能不同的方法，在ISA SERVER 2000中，不支持ICMP的狀態檢查，只能靜態地允許或拒絕ICMP包的進出。
從上面可以看出，基于狀態檢測的防火墻較好的解決了第一類普通包過濾防火墻的問題，為了更直觀的理解狀態檢測防火墻，我們還來看看一些實際例子，這些例子都是在ISA SERVER 2000上的表現。(1)感受會話超時的限制 還是舉一個能說明問題的例子，比如大家熟悉的QQ(QQ2003II)，為什么你一直不聊天和做其他動作仍然能夠收到從騰訊服務器上發來的廣告信息呢?肯定不是這個連接到騰訊服務器的QQ會話永不超時，其實你用sniffer軟件一看就知道了，這是因為QQ每到一分鐘時(但還沒到一分鐘)就會主動與騰訊服務器聯系一次，這種聯系對防火墻后的QQ是非常重要的，通常來說，對于UDP協議，會話超時都是一分鐘或小于一分鐘，另外windows 2000中UDP端口的NAT映射期也只有一分鐘，它在一分鐘之內聯系，這樣就會在防火墻狀態表中保持它的會話，不至于會話被刪除，想像一下，如果它不這樣聯系的話，一分鐘后這條會話被刪除，而剛好此時騰訊有個廣告要傳給你，那么你是不能收到的，當然其他從騰訊服務器上來的消息也不能收到，這是因為會話中已沒有了匹配的條目，而規則中又沒有靜態打開的入站端口。當然上面的分析是從用戶的角度來說的，從騰訊的角度來說，它也需要獲知用戶的連接狀態，所以也需要定時通信，這已不在我們的討論范圍之內了。除了QQ，MSN Messenger也是這樣的。
(2)動態地打開入站端口 首先我已在ISA SERVER 2000中的protocol rules下定義了一條允許所有客戶端訪問外部WEB網站的規則，如圖3，
注意上面只明確定義了出站的規則，沒有明確定義入站的規則，這是因為有狀態檢測技術起作用，我們用不著為上面的規則配套一條明確的入站規則。圖4是我在客戶端打開網頁時在ISA服務器上進行sniffer的結果，第一行是一個帶有SYN標志的初始化連接的數據包，本地端口是22870，第二行是對方回應的數據包，由于與第一行屬于同一個會話，防火墻已經為它動態地打開端口22870以便進入。
上面我們感受了狀態檢測防火墻的強大功能，但由于狀態檢測防火墻畢竟是工作在網絡層和傳輸層的，所以它仍然有一些不能解決的問題需要在應用層來進行解決，比如對于動態分配端口的RPC就必須作特殊處理；另外它也不能過濾掉應用層中特定的內容，比如對于http內容，它要么允許進，要么允許出，而不能對http內容進行過濾，這樣我們就不能控制用戶訪問的WEB內容，也不能過濾掉外部進入內網的惡意HTTP內容，另外，它也不能對用戶進行認證，為了解決這些問題，我們還必須把防火墻的過濾層次擴展到應用層，這就是應用層防火墻，不過這種稱呼似乎有點不準，也許叫應用層級的狀態檢測防火墻更合適，其實今天比較大型的商業防火墻都應該是這個級別的防火墻了，比如微軟的ISA SERVER 2000就是，在ISA中這種應用層的過濾就表現為應用程序過濾器(Application Filters)，下面來看看應用層防火墻的處理過程。
如前文所述，當數據包在網絡層和傳輸層通過檢查之后，它就被送到應用層繼續進行檢查，不同的應用協議送到不同的應用協議過濾器，比如是SMTP數據包，它就會送到SMTP過濾器，在ISA SERVER 2000中，該篩選器攔截并核對SMTP 電子郵件通信，保護郵件服務器免受攻擊。該篩選器識別不安全的命令并且可以篩選電子郵件信息的內容或者大小，在未經同意的電子郵件到達郵件服務器之前將其拒絕。只有匹配過濾器規則的數據包才會允許通過防火墻。
但應用層的過濾也有缺點，就是得針對每種應用協議開發一種過濾器，而對于一種具體的應用協議過濾器，它也是需要不斷發展的，因為應用協議在發展，再說還不斷有新的應用協議產生，并且由于數據包要經過應用層過濾器的再次檢查，這無疑會降低網絡傳輸效率。而對于使用動態端口協議的處理這種防火墻最頭痛的事情，即使在應用層上來解決也不是一件容易的事，RPC也許不是問題了，因為它使用了這么多年，各種防火墻對它都已經有了比較成熟的解決方案，比如ISA SERVER 2000中就有專門的RPC filter來對它進行處理，但對于一些比較新的且也使用動態端口的協議就不好辦了，比如用于即時通信中的SIP協議等諸多協議都要使用動態端口，由于沒有即時的過濾器推出，使用這些協議的網絡應用程序在防火墻后通常都會有連接故障，我想那些在防火墻后使用MSN Messenger的朋友一定深有體會(當使用除即時文字聊天和文件傳輸以外的功能時)，不過，現在也有了一種比較全面地來解決這種使用動態端口協議的方案，那就是在防火墻中添加UPnP協議的支持，這樣那些支持UPnP的網絡應用程序(如MSN Messenger 6.1)就能夠自動去發現防火墻并在防火墻上動態地打開端口，這樣就無需在防火墻上去進行進退兩難的手動配置。不過遺憾的是，雖然UPnP有效的解決了動態端口的問題，但它也帶來了新的安全問題，所以在安全性要求較高的網絡中是不適宜開啟UPnP功能的。可能也是由于安全原因吧，現在支持UPnP的防火墻還很少，據我所知，Kerio winroute firewall5和windows XP上的ICF是支持UPnP的。注：本文未探討另一類工作在應用層的防火墻，即代理服務器，也被稱做應用代理網關。
需求：
在一些特定的應用場景下，客戶需要同一子網的部分設備可以通過DHCP方式獲取到地址，另外部分設備不能通過DHCP獲取地址，需要手工配置。
拓撲說明：交換機作為DHCP SERVER，PC1 PC2作為客戶端接入交換機，地址配置為DHCP獲取方式。
配置原理：
由于DHCP協議采用UDP作為傳輸協議，主機發送請求消息到DHCP服務器的67號端口，DHCP服務器回應應答消息給主機的68號端口；這兩個端口是正常的DHCP服務端口，可以理解為一個發送，一個接收。
在指定端口，使用ACL匹配DHCP服務，用策略過濾掉
配置方法：
SW
sysname SW
vlan batch 10
dhcp enable
acl number 3000
rule 5 deny udp destination-port eq 68
rule 10 deny udp destination-port eq 67
//這兩條命令會自動變成
//rule 5 deny udp destination-port eq bootpc
//rule 10 deny udp destination-port eq bootps
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
dhcp select interface
interface GigabitEthernet0/0/1
port link-type access
port default vlan 10
interface GigabitEthernet0/0/2
port link-type access
port default vlan 10
traffic-filter inbound acl 3000
配置完成后，經測試PC1正常獲取IP地址，PC２無法通過DHCP獲取地址，手工配置同網段地址，訪問正常