CiscoPIX防火墻高級協(xié)議處理與攻擊防衛(wèi)

除了個別的例外情況，高級協(xié)議處理是通過一種稱為“fixupprotocol(協(xié)議修補)”的機制來實現(xiàn)的。fixupprotocol命令不是以真正的代理方式運行，而是以一種“了解應用的代理(applicationawareagent)”方式來運行。在大多數(shù)情況下，fixupprotocol的操作是通過監(jiān)視一個應用的控制信道，來防止出現(xiàn)違背協(xié)議的事件，并讓PIX防火墻能夠動態(tài)響應協(xié)議的合法需要，通過在ASA中產(chǎn)生一個臨時的例外事例來安全地打開一條向內(nèi)的連接。當不再需要這個例外事例時，fixupprotocol功能會將它關(guān)閉。

PIXOS的每個新版本都會帶來新的并經(jīng)過改進的協(xié)議處理功能。需要著重指出的是，PIX防火墻只可以對屬于運行在PIX防火墻上的PIXOS的一部分的fixup協(xié)議執(zhí)行這些操作。Fixup協(xié)議不是用戶可定義的，或用戶可編程的。Fixup功能允許我們啟用或禁止對所支持協(xié)議的處理，并決定在什么端口(標準的或非標準的)上進行操作。

9．1對高級協(xié)議處理的需求現(xiàn)在，幾乎每個企業(yè)都在將Internet用于商業(yè)交易。對于這些企業(yè)，為了保證他們內(nèi)部網(wǎng)絡的安全，使網(wǎng)絡免受來自Internet的潛在威脅，他們必須采用防火墻，將他們受信任的內(nèi)部網(wǎng)絡與不被信任的Intemet分離開來。雖然防火墻可以幫助保護企業(yè)的內(nèi)部網(wǎng)絡，使它免受來自外部的威脅，但是在具體實現(xiàn)中也會遇到一些挑戰(zhàn)。

在安裝防火墻之前，企業(yè)用來與外部資源進行通信的一一些協(xié)議和應用現(xiàn)在可能會被防火墻阻擋。許多流行的協(xié)議和應用需要對連接進行協(xié)商，以動態(tài)分配源和目的端口或IP地址。此外，讓事情進一步復雜化的是，一些應用將源或目的IP地址信息嵌入到網(wǎng)絡層(第3層)之上。

一個好的防火墻必須能在網(wǎng)絡層以上的層中檢查數(shù)據(jù)包，并根據(jù)協(xié)議或應用的需要執(zhí)行下列操作：為通過防火墻的合法客戶端／服務器連接，安全地打開和關(guān)閉經(jīng)過協(xié)商的端口或IP地址。在一個數(shù)據(jù)包內(nèi)部，使用與網(wǎng)絡地址翻譯(NAT)相關(guān)的IP地址事例。在一個數(shù)據(jù)包內(nèi)部，使用與端口地址翻譯(PAT)相關(guān)的端口事例。檢查數(shù)據(jù)包，查看是否有惡意的應用濫用的跡象。通過使用CiscoSecurePIX防火墻的fixupprotocolprotocol命令，我們可以為這些應用提供安全的通道。下面的將要介紹的是，用于標準的和被動的文件傳送協(xié)議(FTP)、rsh(遠程命令解釋程序)和SQL*Net的特定fixupprotocolprotocol命令是如何運行的，以及如何配置它們。

9．1.1標準模式的FTP

標準模式的FTP(也稱為經(jīng)典模式的FTP)使用兩條信道進行通信。當防火墻后面的一個客戶端從它的主機發(fā)起一條FTP連接時，它就從它的一個高序列端口(TCP源端口>1023)到外部服務器上的目標TCP端口2l，打開一條標準的TCP信道。這條連接被稱為“控制信道”。當這個客戶端從服務器請求數(shù)據(jù)時，它告訴服務器將數(shù)據(jù)發(fā)送到一個給定的高序列端口。服務器對請求進行確認，并從它自己的端口20到客戶端指定的那個高序列端口，發(fā)起一條向內(nèi)的連接。這條連接被稱為“數(shù)據(jù)信道”(端口20FTP—DATA)。

在過去，對于向外的FTP連接，如果不永久地打開從外部服務器端15120到內(nèi)部客戶端的連接，就很難允許這種向內(nèi)的連接通過防火墻到達客戶端上指定的端口。而如果不加區(qū)別地打開這樣的連接通道，就會產(chǎn)生一個巨大的潛在安全漏洞，因為它允許來自Internet上任何主機的TCP源端口是20的任何向內(nèi)的數(shù)據(jù)流，而不管它們的意圖是什么!例9-1和圖9.1顯示了TCP的三次握手過程，以及FTP控制信道(TCP端口21)的建立。注意，在跟蹤的第二部分中，F(xiàn)TP服務器198．10．2．51(ftp．cisco．corn)用源端口20和一個隨機的高位端IZl1066(由客戶端選擇)，對FTP—DATA信道進行初始化。例9·1sniffer跟蹤顯示了經(jīng)典模式的FTP例9·1sniffer跟蹤顯示了經(jīng)典模式的FTP#Setupconnectiontodestinationport21forcontrolchannel[10．10．2．51][198．133．219．27]TCP：：D=2lS：1065SYNSEQ=1763920874LEN=0[198．133．219．27][10．i0．2．51]TCP：D=1065S=2lSYNACK=1763920875SEQ=2208726475LEN=0[10．10．2．51][198．133．219．27]TCP：：D：21S=1065ACK=2208726476#FTPservernegotiatesFTP—DATAchannelwithTCPsourceport20[10．10．2．51][198．133．219．27]FTP：：CPORT=1065LIST[198．133．219．27][10．10．2．51]TCP：：D=1066S=20SYNSEQ：2209373687LEN：0[10．10．2．51][198．133．219．27]TCP：D=20S=1066SYNACK=2209373688SEQ=1765279364LEN：0[198．133．219．27][10．10．2．51]TCP：：D=1065S=21ACK=1763920967[198．133．219．27][10．10．2．51]TCP：：D=1066S=20ACK=1765279365[198．133．219．27][10．10．2．51]FTP：RPORT：1065150ASCIImodedataconnectionfor／bin／1S．[198．133．219．27][10．10．2．51]FTP：：RPORT=1066TextData

Cisco安全PIX防火墻使用fixupprotocolftp命令，來安全地啟用FTP—DATA連接所需要的例外事項。對于向外的和向內(nèi)的連接，Cisco安全PIX防火墻采用下列方式來處理FTP連接：向外的連接——當客戶端請求數(shù)據(jù)時，PIX打開一個臨時的內(nèi)向管道，來允許來自服務器的數(shù)據(jù)信道。在發(fā)送完數(shù)據(jù)之后，這個管道被立即拆除。向內(nèi)的連接——如果存在一條管道允許到內(nèi)部網(wǎng)絡中的FTP服務器的向內(nèi)的連接，并且如果隱含允許所有向外的’rcP數(shù)據(jù)流，那么就不需要特殊的處理，這是因為FTP服務器是從內(nèi)部發(fā)起FTP數(shù)據(jù)信道的連接。如果存在一條管道允許到內(nèi)部網(wǎng)絡中的FTP服務器的向內(nèi)的：FTP控制連接，并且如果沒有隱含允許所有向外的’FCP數(shù)據(jù)流，那么PIX防火墻將打開一條臨時的管道，用于來自FTP服務器的數(shù)據(jù)信道。在發(fā)送完數(shù)據(jù)之后，這條管道被拆除。

9．1．2被動模式的FTP

被動模式的FTP也使用兩條信道進行通信?？刂菩诺赖墓ぷ鞣绞脚c標準FTP連接中的一樣，但是建立數(shù)據(jù)信道的方式有些不同。當向服務器請求數(shù)據(jù)時，客戶端詢問服務器是否接受PASV方式的連接。如果服務器接受PASV連接方式，它就向客戶端發(fā)送一個用于數(shù)據(jù)信道的高位端口號。然后，客戶端從它自己的高位端口到服務器指定的端口，發(fā)起這條數(shù)據(jù)連接。因為是由客戶端發(fā)起．FTP的命令和數(shù)據(jù)連接，所以早期的防火墻可以很容易地支持這種方式，而不會讓內(nèi)部的客戶端暴露于攻擊之下。圖9．2顯示了采用被動模式FTP，在客戶端和服務器之間的事務處理過程。大多數(shù)web瀏覽器缺省使用被動模式FTP。

對于被動模式的FTP數(shù)據(jù)流，PIX防火墻采用下列方式，處理向外的與向內(nèi)的PASV連接向外的PASV連接——如果隱含允許所有向外的。TCP數(shù)據(jù)流，就不需要特殊的處理，因為客戶端是從內(nèi)部發(fā)起。FTP命令和數(shù)據(jù)信道連接。如果沒有隱含允許所有向外的’TCP數(shù)據(jù)流，PIx防火墻需要打開一條臨時的管道，用于來自客戶端的數(shù)據(jù)信道。在發(fā)送完數(shù)據(jù)之后，這條管道被拆除。向內(nèi)的PASV連接——如果存在一條管道，允許到內(nèi)部網(wǎng)絡中的PVI‘P服務器的內(nèi)向FTP控制連接，那么PIX防火墻將打開一條臨時的、向內(nèi)的管道，用于由客戶端發(fā)起的數(shù)據(jù)信道。在發(fā)送完數(shù)據(jù)之后，這條管道被拆除。

9.1.3fixupprotocolFTP命令fixupprotocolftp命令的語法如下所示：fixupprotocolftpport

[-port

][strict]nofixupprotocolftpport

[-port

]clearfixupprotocolftp

這里的port

[-port

]是PIX防火墻將為FTP連接進行檢查的單個端口或端口范圍。缺省情況下，啟用fixupprotocolftp21命令，PIX防火墻為TCP控制信道數(shù)據(jù)流檢查端口21的連接。如果我們讓FTP服務器使用端口21以外的端口，我們就需要使用fixupprotocolftpport-number·命令，讓PIX防火墻為FTP數(shù)據(jù)流檢查這些非標準的端口。strict選項使fixupprotocolftp命令要求，在允許執(zhí)行一條新命令之前，每個FTP請求都必須被確認，從而防止web瀏覽器在FTP請求中嵌入命令。任何包含嵌入命令的FTP數(shù)據(jù)包都會被丟棄。例9-2顯示了fixupprotocolftp命令和它的no形式的使用，使用這些命令為FTP配置和刪除標準與非標準的端口。

fixupprotocolftp命令讓PIX防火墻在指定端口上，為FTP數(shù)據(jù)流執(zhí)行下列操作：·在數(shù)據(jù)包凈載中執(zhí)行NAT或PAT；·為FTP數(shù)據(jù)信道連接動態(tài)地創(chuàng)建管道；·記錄FTP命令(當啟用系統(tǒng)日志，并且日志記錄級別是調(diào)試級別的時候)。使用這條命令的no形式，禁止在指定端口上為FTP連接檢查數(shù)據(jù)流，如例9-2所示。

如果對于一個給定的端口，沒有啟用fixupprotocolftp命令，那么：·在那個端口上，向外的標準FTP將不能正常工作；·只要向外的數(shù)據(jù)流沒有被明確拒絕，那么在那個端口上，向外的被動vrP將能夠正常工作?！と绻嬖谝粭l到內(nèi)部FTP服務器的管道，那么在那個端口上，向內(nèi)的標準FTP將能夠正常工作；·在那個端口上，向內(nèi)的被動FTP將不能正常工作。使用沒有任何參數(shù)的clearfixupprotocolftp命令，將使PIx防火墻清除以前所有的fixupprotocolftp命令指定，并將端口21設置回缺省的情況。

9．1．4遠程命令解釋程序(rsh)

運行在UNIx或Windows主機上的rsh守護進程(daemon)(端口監(jiān)控程序)提供了遠程執(zhí)行命令的功能，這些功能具有根據(jù)來自信任主機的特權(quán)端口號進行認證的能力。在典型情況下，rsh守護進程檢查發(fā)出請求的客戶端的源IP地址和源端口。源端口應該是在512到1023的范圍之內(nèi)；否則，rsh服務應該終止連接。然后，rsh端口監(jiān)控程序?qū)⑾蚩蛻舳藱C器上的指定端口創(chuàng)建第二條連接，用于“標準錯誤輸出(standarderroroutput)”。rsh端口監(jiān)控程序隨后通過檢查“／etc／hosts．equiv”和“～／．rhosts”文件，驗證主機／客戶端名字。如果驗證失敗，將終止連接，并返回一條診斷消息。

警告：許多掃描工具會尋找配置不當?shù)膔sh服務，將其作為獲取對我們的主機進行非授權(quán)訪問能力的第一步。因為現(xiàn)在也具有可用的rsh的windows端口，所以不能再將它認為只是UNIX系統(tǒng)的安全漏洞。使用rsh最安全的方法是禁止來自我們網(wǎng)絡外部的內(nèi)向rsh連接。圖9—3顯示了在客戶端和服務器之間，用于rsh的事務處理。

fixupprotocolrsh命令讓PIX防火墻用下列方式來保證rsh請求的安全：向外的連接——當從服務器發(fā)送標準的錯誤消息時，PIX防火墻為這條信道打開一條臨時的、向內(nèi)的管道。一旦這條管道不再需要，它就會被拆除。向內(nèi)的連接——如果存在一條管道，允許到rsh服務器的內(nèi)向連接，并且如果隱含允許所有向外的’FCP數(shù)據(jù)流，那么就不需要進行特殊的處理，這是因為服務器是從內(nèi)部發(fā)起標準錯誤信道連接。如果存在一條管道，允許到內(nèi)部網(wǎng)絡中的rsh服務器的內(nèi)向連接，并且如果沒有隱含允許所有向外的’I‘CP數(shù)據(jù)流，那么PIX防火墻為來自服務器的標準錯誤信道打開一條臨時的管道。在發(fā)送完消息之后，這條管道將被拆除。

fixupprotocolrsh命令

fixupprotocolrsh命令的語法如下所示：

fixupprotocolrshport[-port]nofixupprotocolrshport[-port]clearfixupprotocolrsh

這里的port[-port]是：PIX防火墻將為rsh連接進行檢查的單個端口或端口范圍。缺省情況下，PIX防火墻為rsh數(shù)據(jù)流檢查到端口514的連接。如果我們讓rsh服務器使用端口514以外的端口，我們就需要使用fixupprotocolrshport命令，讓PIX防火墻為rsh數(shù)據(jù)流檢查這些其他的端口，如例9—3所示。

fixupprotocolrsh命令讓PIx防火墻在指定端口上，為用于rsh數(shù)據(jù)流的rsh標準錯誤連接動態(tài)地創(chuàng)建管道。使用這條命令的no形式，禁止在指定端口上為rsh連接檢查數(shù)據(jù)流。如果對于一個給定端口，沒有啟用fixupprotocolrsh命令，那么：

·在那個端口上，向外的rsh將不能正常工作；

·如果存在一條到內(nèi)部服務器的管道，那么在那個端口上，向內(nèi)的rsh將能夠正常工作。使用沒有任何參數(shù)的clearfixupprotocolrsh命令，將使PIX防火墻清除以前所有的fixupprotocolrsh命令指定，并將端口514設置回缺省的情況。

9．1．5SQL冰NetSQI*Net用來查詢遠端SQL數(shù)據(jù)庫。雖然該協(xié)議是由Oracle公司為Oracle數(shù)據(jù)庫開發(fā)的，但是當它用來查詢其他廠商的SQL數(shù)據(jù)庫時，也同樣工作得很好。在為SQI*Net的安全提供保障時，需要考慮的主要問題是，雖然它只將一個TCP端口用于通信，但是那個端口可以被重新定向到一個不同的端口，而且更常見的是，還同時被重定向到一臺不同的輔助服務器上。當客戶端開始一條SQI*Net，連接時，它從它的一個高位端口到服務器上的端口1521，打開一個標準的TCP信道。然后，服務器開始將客戶端重新定向到一個不同的端口或IP地址。這個客戶端拆除初始的TCP連接，并使用被重新定向的端口建立第二條連接。注意：雖然fixupprotocolsqlnet命令檢查的缺省端口是1521，Oracle向IANA(Internet號碼分配管理局)注冊了TCP和UDP端口66。我們可能需要向我們的配置增加fixupprotocol66來支持我們具體的實現(xiàn)方式。圖9—4顯示了在客戶端和服務器之間，用于SQL*Net連接的事務處理。對于SQL*Net數(shù)據(jù)流，PIX防火墻按照下列方式進行處理：向外的連接——如果隱含允許所有向外的TCP數(shù)據(jù)流，就不需要特殊的處理，因為客戶端是從內(nèi)部發(fā)起所有的TCP連接。如果沒有隱含允許所有向外的TCP數(shù)據(jù)流，那么PIX防火墻需要在服務器和客戶端之間打開一條管道，用于被重新定向的信道。向內(nèi)的連接——如果存在一條管道，允許到內(nèi)部網(wǎng)絡中的SQL*Net服務器的內(nèi)向SQL*Net連接，那么PIX防火墻將打開一條向內(nèi)的管道，用于被重新定向的信道。fixupprotocolsqlnet命令fixupprotocolsqlnet命令的語法如下所示：fixupprotocolsqlnetport[-port]nofixupprotocolsqlnetport[-port]clearfixupprotocolsqlnet這里的port[-port]是PIX防火墻將為SQL*Net連接進行檢查的單個端口或端口范圍。缺省情況下，PIx防火墻為SQL*Net數(shù)據(jù)流檢查到端口1521的連接。如果我們讓SQL*Net服務器使用端口1521以外的端口，我們就需要使用fixupprotocolsqlnetport命令，讓PIX防火墻為SQL*Net數(shù)據(jù)流檢查這些其他的端口，如例9-4所示。fixupprotocolsqlnet命令讓PIX防火墻在指定端口上，為SQL*Net數(shù)據(jù)流執(zhí)行下列操作：

·在數(shù)據(jù)包凈載中執(zhí)行NAT；

·為SQL*Net被重新定向的連接動態(tài)地創(chuàng)建管道。使用這條命令的no形式來禁止在指定端口上為SQL*Net連接檢查數(shù)據(jù)流。如果對于一個給定端口，沒有啟用fixupprotocolsqlnet命令，那么將發(fā)生下列情況：

·只要向外的數(shù)據(jù)流沒有被明確禁止，那么在那個端口上，向外的SQL*Net將能夠正常工作；

·在那個端口上，向內(nèi)的被動SQI．木Net將不能正常工作。使用沒有任何參數(shù)的clearfixupprotocolsqlnet命令，將使PIX防火墻清除以前所有的fixupprotocolsqlnet命令指定，并將端口1521設置回缺省的情況。9．2多媒體支持多媒體應用向防火墻提出了一個巨大的挑戰(zhàn)，這是因為客戶端可能在TCP上發(fā)送請求，在TCP或UDP上得到響應，使用動態(tài)端口，還可能為源和目的地使用相同的端口，等等。每種應用的運行方式也不相同。要想實現(xiàn)對所有多媒體應用的支持，僅使用一種安全手段是非常困難的。下面是多媒體客戶端應用的兩個實例：

RealAudio客戶端向TCP端口7070發(fā)送初始的連接請求。RealAudio服務器用客戶端機器上從UDP端口6970到7170范圍中的多個UDP數(shù)據(jù)流進行應答。

CUseeMe客戶端從TCP端口7649向TCP端口7648發(fā)送初始的連接請求。CuseeMe數(shù)據(jù)報的特別之處是，它在包頭和數(shù)據(jù)凈載中都包含了合法的IP地址，并從UDP端口7648向UDP端口7648發(fā)送應答。

Cisco安全PIX防火墻為安全的多媒體連接動態(tài)地打開和關(guān)閉UDP端口。這樣就顯著地降低了由于開放一段很大的端口范圍所帶來的安全風險，并減少了對應用軟件的客戶端進行重新配置的需要。而且，PIX防火墻在使用NAT或不使用NAT功能時都能支持多媒體應用。如果防火墻不能同時支持NAT功能和多媒體應用，它就會限制只有擁有注冊IP地址的用戶才能使用多媒體應用，或者需要將內(nèi)部IP地址暴露給Internet。如果不能對多媒體應用支持NAT功能，這通常會要求多媒體應用提供商加入到防火墻廠商的專有聯(lián)盟，來獲得產(chǎn)蒯之間的相互兼容性。9．2．1實時流協(xié)議(RTSP)

實時流協(xié)議(RealTimeStreamingProtocol，RTSP)是在RFC2326中描述的，它是一種實時音頻和視頻傳送協(xié)議，用于很多種常見的多媒體應用。它使用一條TCP信道，有時還要兩條附加的UDP信道。RTSP應用使用眾所周知的端口554，通常是TCP，很少是UDP。RFC2326只需要TCP，所以PIX防火墻只支持TCP。這條TCP信道是控制信道，并根據(jù)在客戶端上配置的傳輸模式，被用來協(xié)商其他兩條UDP信道。第一條UDP信道是數(shù)據(jù)連接，可以使用下列任一種傳輸模式：

·實時傳輸協(xié)議(Real—TimeTransportProtocol，RTP)。

·Real數(shù)據(jù)傳輸協(xié)議(RealDataTransportProtocol，RDT)(由RealNetworks公司開發(fā)的協(xié)議)。第二條UDP信道是另一條控制信道，它可以使用下列任一種模式：

·RTP控制協(xié)議(RTPControlProtocol，I汀CP)。

·UDP重新發(fā)送(UDPResend)RTSP也是只支持TCP模式。這種模式只包含一條TCP連接，這條連接被用于控制和數(shù)據(jù)信道。因為這種模式只包含一條固定的標準TCP連接，所以不需要PIX防火墻進行任何特殊處理。

PIX防火墻支持下列RTSP應用：

·CiscoIP/TV

·AppleQuickTime4

·RealNetworks

·RealAudio

·RealPlayer

·RealServer注意，不支持RDT組播模式。一、RTP模式在標準RTP模式中，RTSP使用下列三條信道：·TCP控制信道——從客戶端發(fā)起，到服務器的標準TCP連接?！TP數(shù)據(jù)信道——單工(單向)UDP會話，用于媒體傳送，它從服務器到客戶端使用RTP數(shù)據(jù)包格式。客戶端的端口總是一個偶數(shù)編號的端口。·RTCP報告——雙工(雙向)UDP會話，用來向客戶端提供同步信息，向服務器提供數(shù)據(jù)報丟失信息。RTCP端口總是RTP數(shù)據(jù)端口的下一個連續(xù)的端口。圖9-5顯示了在用于RTSP的標準RTP模式中，客戶端和服務器之間的通信。對于標準RTP模式的：RTSP數(shù)據(jù)流，PIx防火墻按照下列方式進行操作：·向外的連接——在客戶端和服務器協(xié)商完傳輸模式和用于會話的端口之后，PIX防火墻打開臨時的內(nèi)向管道，用于RTP數(shù)據(jù)信道和來自服務器的：RTCP報告信道。·向內(nèi)的連接——如果存在一條管道，允許到RTSP服務器的內(nèi)向RTSP連接，而且如果隱含允許所有向外的UDP數(shù)據(jù)流，就不需要特殊的處理，因為服務器是從內(nèi)部發(fā)起數(shù)據(jù)和報告信道連接。如果存在一條管道，允許到內(nèi)部網(wǎng)絡中的RTSP服務器的內(nèi)向RTSP連接，而且如果沒有隱含允許所有向外的UDP數(shù)據(jù)流，那么PIX防火墻需要打開臨時的管道，用于來自服務器的數(shù)據(jù)和報告信道。二、ReaINetworks公司的RDT模式在RealNetworks公司的RDT模式中，RTSP使用下列三條信道：·TCP控制信道——從客戶端發(fā)起，到服務器的標準TCP連接?！JDP數(shù)據(jù)信道——單工(單向)UDP會話，用于媒體傳送，它從服務器到客戶端使用標準UDP數(shù)據(jù)包格式。·UDP重新發(fā)送——單工(單向)LJDP會話，用于客戶端請求服務器重新發(fā)送丟失的數(shù)據(jù)包。圖9-6顯示了在用于RTSP的。RealNetworks公司RDT模式中，客戶端和服務器之間的通信。對于RealNetworks公司RDT模式的RTSP數(shù)據(jù)流，PIX防火墻按照下列方式進行操作：·向外的連接——如果隱含允許向外的UDP數(shù)據(jù)流，而且在客戶端和服務器協(xié)商完傳輸模式和用于會話的端口之后，PIX防火墻將打開一個臨時的內(nèi)向管道，用于來自服務器的UDP數(shù)據(jù)信道。如果沒有隱含允許向外的UDP數(shù)據(jù)流，而且在客戶端和服務器協(xié)商完傳輸模式和用于會話的端口之后，PIX防火墻會打開一個臨時的內(nèi)向管道，用于來自服務器的UDP數(shù)據(jù)信道，還打開一個臨時的外向管道，用于源自客戶端的U：DP重新發(fā)送信道。·向內(nèi)的連接——如果存在一個管道，允許到RTSP服務器的內(nèi)向：RTSP連接，而且如果隱含允許所有向外的UDP數(shù)據(jù)流，PIX防火墻就需要打開一個臨時的外向管道，用于源自服務器的UDP數(shù)據(jù)信道。如果存在一個管道，允許到RTSP服務器的內(nèi)向連接，而且如果沒有隱含允許所有向外的TCP數(shù)據(jù)流，那么PIX防火墻需要打開臨時的管道，用于分別來自服務器和客戶端的UDP數(shù)據(jù)信道和UDP重新發(fā)送信道。缺省情況下，PIX防火墻不檢查用于RTSP連接的任何端口。為了讓PIX防火墻檢查用于RTSP數(shù)據(jù)流的特定端口，比如標準端口554，可以使用fixupprotocolrtsp命令。

fixupprotocolrtsp命令讓PIX防火墻在指定端口上，為用于RTSP數(shù)據(jù)流的RTSPUDP信道動態(tài)地創(chuàng)建管道。

fixupprotocolrtsp命令的語法如下所示：fixupprotocolrtspport

[-port]nofixupprotocolrtspport

[-port]clearfixupprotocolrtsp這里的port

[-port]是PIX防火墻將為RTSP連接進行檢查的單個端口或端口范圍。使用這條命令的no形式，禁止在指定端口上為RTSP連接檢查數(shù)據(jù)流，如例9—5所示。如果對于一個給定端口，沒有啟用fixupprotocolrtsp命令，那么在那個端口上向內(nèi)的或向外的RTSP都將不能正常工作。注意：為了支持CiscoIP／Tv，需要用fixupprotocolrtsp命令，為TCP端口8554和缺省的TCP端口554，配置RTSPfixup協(xié)議。使用沒有任何參數(shù)的clearfixupprotocolrtsp命令，將使PIX防火墻清除以前所有的fixupprotocolrtsp命令指定。9．2．2H．323H．323相對其他協(xié)議更加復雜，因為它為一個“呼叫”使用兩條TCP連接和幾個UDP會話。(只有一條TCP連接使用一個眾所周知的端口；所有其他端口是通過協(xié)商使用的，因此都是臨時的。)而且，對于防火墻來說，流的內(nèi)容比現(xiàn)有其他協(xié)議更加難以理解，這是因為H．323使用抽象語法符號(AbstractSyntaxNotation，ASN．1)，對數(shù)據(jù)包進行編碼。H．323內(nèi)所支持的其他協(xié)議和標準有：

·H-225——注冊、接納和狀態(tài)(Registration，Admission，andStatus，RAS)。

·H_225——呼叫信令。

·H．245——控制信令。

·TPKT頭標。

·Q．931消息。

·抽象語法符號(ASN．1)(PIX防火墻OS5．2)支持的H．323版本如下：

·H．323V1。

·H．323v2(PIX防火墻OS5．2)。PIX防火墻支持的H．323應用包括：．

·Cisco多媒體會議管理。

·MicrosoftNetMeeting。

·Intel視頻電話。

·CuseeMeNetworks。

——MeetingPOint。

——CUseeMePro。

·V0calTec。

——IntemetPhone。

——Gatekeeper。fixupprotocolh323命令缺省情況下，PIX防火墻為H．323數(shù)據(jù)流檢查到端口1720的連接。如果我們讓H．323服務器使用端口1720以外的端口，我們就需要使用fixupprotocolh323port命令，讓PIX防火墻為H．323數(shù)據(jù)流檢查這些非標準的端口。fixupprotocolh323命令的語法如下所示：fixupprotocolh323port[-port]nofixupprotocolh323port[-port]clearfixupprotocolh323這里的port[-port]是PIX防火墻將為H.323連接進行檢查的單個端口或端口范圍。例9-6顯示了fixupprotocolh323命令和它的no形式的典型使用，使用這些命令為H.323數(shù)據(jù)流增加和刪除標準與非標準的端口。fixupprotocolh323命令讓PIX防火墻在指定端口上，為H.323數(shù)據(jù)流執(zhí)行下列操作：

·在數(shù)據(jù)包凈載中執(zhí)行NAT；

·為TCP或UDP信道動態(tài)地創(chuàng)建管道。使用這條命令的no形式，可以禁止在指定端口上為H．323連接檢查數(shù)據(jù)流。如果對于一個給定的端口，沒有啟用“fixupprotocolh323’’命令，那么在那個端口上，向外的或向內(nèi)的H．323連接都將不能正常工作。使用沒有任何參數(shù)的“clearfixupprotocolh323”命令，將使PIX防火墻清除以前所有的“fixupprotocolh323’’命令指定，并將端口1720設置回缺省的情況。9．3攻擊防衛(wèi)本節(jié)討論PIX防火墻的攻擊防衛(wèi)特性，使用它們可以降低被下列方式攻擊的風險：通過電子郵件、域名系統(tǒng)(DNS)、碎片、認證、授權(quán)和審計(AAA)，以及SYN風暴的攻擊。9．3．1郵件防衛(wèi)郵件防衛(wèi)(MailGuard)提供了一種機制，來保護從外部到一臺電子郵件服務器的簡單郵件傳送協(xié)議(SimpleMailTransferProtocol，SMTP)連接。郵件防衛(wèi)允許將一臺郵件服務器應用于由PIX提供保護的網(wǎng)絡中，而不會將服務器暴露給對某些郵件服務器常見的安全問題。切記，Cisco建議將郵件服務器放置在一個DMZ接口上，而不要將它置于內(nèi)部網(wǎng)絡。在一臺郵件服務器上，只允許RFC821的4.5.1小節(jié)中指定的SMTP命令。這些命令是：HELO、MAIL、RCPT、DATA、RSET、NOOP和QUIT。當PIX防火墻發(fā)現(xiàn)一條SMTP命令不在上述命令中時，PIX防火墻向遠端設備代理發(fā)送一個響應“500命令不可識別(500commandunrecognized)"，并在數(shù)據(jù)包到達被保護的郵件服務器之前，丟棄這些數(shù)據(jù)包。郵件防衛(wèi)并不能解決所有問題。雖然它可以對連接執(zhí)行代理操作，限制能夠到達我們的郵件服務器的SMTP消息類型，并能夠隱藏S．MTP標題(因為標題會指明被保護郵件服務器的類型和版本)，但是郵件防衛(wèi)并不能完全保護我們的郵件服務器，使它免受所有已知攻擊的侵害。即使受到郵件防衛(wèi)的保護，我們的郵件服務器也需要被正確地配置，并針對已知的漏洞及時打上補丁。MicrosoftExchange服務器的某些配置可能需要使用郵件防衛(wèi)不允許的一些命令。在這種情況下，必須用nofixupprotocolsmtp25命令，來禁止使用郵件防衛(wèi)。在缺省情況下，PIX防火墻為SMTP數(shù)據(jù)流檢查端口25的連接。如果我們讓SMTP服務器使用端口25以外的端口，我們就需要使用fixupprotocolsmtpport-number命令，讓PIX防火墻為SMTP數(shù)據(jù)流檢查這些非標準的其端口。fixupprotocolsmtp命令的語法如下所示：fixupprotocol

smtpport

[-port]nofixupprotocolsmtpport

[-port]clearfixupprotocolsmtp

這里的port

[-port]是PIX防火墻將為SMTP連接進行檢查的單個端口或端口范圍。使用這條命令的no形式，可以禁止在指定端口上為SMTP連接檢查數(shù)據(jù)流。如果對于一個給定的端口，沒有啟用fixupprotocolsmtp命令，那么將會暴露潛在的郵件服務器漏洞。例9．7顯示了用標準和非標準的端口，配置與刪除郵件防衛(wèi)功能特性。使用沒有任何參數(shù)的clearfixupprotocolsmtp命令，將使PIX防火墻清除以前所有的fixupprotocolsmtp命令指定，并將端口25設置回缺省的情況。9．3．2DNS防衛(wèi)

DNS防衛(wèi)可以辨別一個向外的DNS查詢請求，只允許一個DNS響應返回請求者。在第一臺服務器響應慢的情況下，主機可能會查詢好幾臺服務器，來獲得DNS解析響應；但是，只有對特定問題的第一個應答才被允許通過PIX防火墻返回。來自其他服務器的所有額外的應答都將被丟棄。在客戶端發(fā)出一個DNS請求之后，一個動態(tài)的管道將允許UDP數(shù)據(jù)包從DNS服務器返回。缺省的UDP定時器在兩分鐘之后將超時。因為DNS經(jīng)常受到攻擊，所以讓管道保持開放兩分鐘，將會產(chǎn)生一種不必要的風險。DNS防衛(wèi)功能是被缺省啟用的，而且我們不可以配置或禁止它。DNS防衛(wèi)執(zhí)行下列操作：·一旦收到DNS響應，就自動拆除PIX防火墻上的UDP管道。它不等待缺省的UDP定時器來關(guān)閉會話?！し乐筓DP會話劫持攻擊和拒絕服務(DoS)攻擊。圖9—7顯示了在DNS查詢過程中，PIX所涉及的操作。9．3．3碎片攻擊防衛(wèi)使用sysoptsecurityfragguard命令，來啟用碎片防衛(wèi)(FragGuard)特性。這個特性除了對RFC1858推薦的針對許多IP碎片類型的攻擊(比如，淚滴(teradrop)、land等)進行安全檢查外，還強制對IP數(shù)據(jù)包進行兩項附加的安全檢查。第一項安全檢查要求每個非初始的IP碎片與一個已經(jīng)看到的、有效的、初始IP碎片相關(guān)。在PIx防火墻OS版本5．1中，不要求一個初始的碎片。這是因為碎片可能是無序到達的。對于第二項安全檢查，IP碎片的速率被限制成每秒最多可以有100個IP碎片數(shù)據(jù)包到達一臺內(nèi)部主機。這意味著，PIX防火墻每秒可以處理1200個數(shù)據(jù)包碎片。碎片防衛(wèi)特性運行在PIX防火墻的所有接口上，而且不可以根據(jù)接口有選擇性地啟用或禁止它。碎片攻擊防衛(wèi)和虛擬重組在版本5．1中，下列虛擬重組特性是新增的：·PIX防火墻OS版本5-1增強了IP碎片保護功能，并執(zhí)行對所有ICMP錯誤消息的完全重組，以及被路由通過PIX防火墻的剩余IP碎片的虛擬重組。以前對碎片防衛(wèi)有一個限制，即初始碎片必須第一個到達，現(xiàn)在這個限制被取消了?！ぴ黾恿艘粭l新的淚滴(teradrop)系統(tǒng)日志消息，來通知任何碎片重疊和小碎片偏移異常情況?！ぴ谶@個發(fā)布版本中，增加了系統(tǒng)日志消息％PIX-2-106020：DenyIPteardropfragment(size=num，offset=num)fromIP_addrtoIP_addr，用來記錄teardrop攻擊。當PIX防火墻丟棄一個具有淚滴(teardorp)標記的IP數(shù)據(jù)包(即具有小的偏移或碎片重疊)時，就會出現(xiàn)這條消息。我們應該將這種事件看作一種惡意的嘗試，它試圖繞過PIX防火墻或Cisco安全入侵檢測系統(tǒng)?！け环侄纬?2個部分以上的IP數(shù)據(jù)包不可以通過PIX防火墻。要想組成一個16KB的數(shù)據(jù)凈載，最多需要12個1500字節(jié)大小的碎片。對于令牌環(huán)網(wǎng)絡，16384字節(jié)是最大的IPMT[J(最大傳輸單元)。

PIX防火墻使用sysoptsecurityfragguard命令，來執(zhí)行由access-listpermit或access-listdeny命令確定的安全策略，允許或拒絕數(shù)據(jù)包通過PIX防火墻。缺省情況下，sysoptsecurityfragguard命令是被關(guān)閉的。sysoptsecurityfragguard命令的語法如下所示：Sysoptsecurityfragguardnosysoptsecurityfragguard

這條命令沒有參數(shù)。警告：使用sysoptsecurityfragguard命令會打破正常的IP分段規(guī)則。但是，如果不使用這條命令，就有可能把PIx防火墻保護的主機暴露給IP碎片攻擊。cisco建議，在網(wǎng)絡上盡可能地不要允許數(shù)據(jù)包碎片。技巧：如果PIX防火墻被用作路由器之間．FDDI數(shù)據(jù)包的一條隧道，碎片防衛(wèi)特性就應該被禁止。技巧：因為許多Linux和UNIx系統(tǒng)按照相反的順序發(fā)送IP碎片，所以在啟用sysoptsecurityfragguard命令的情況下，被分段的Linux數(shù)據(jù)包將不能通過PIx防火墻。通過首先發(fā)送最后的碎片，Linux/UNIx主機可以知道數(shù)據(jù)凈載的最終偏移，并可以預先分配接口緩沖區(qū)。9．3．4AAA風暴攻擊防衛(wèi)雖然在PIX上用AAA識別、授權(quán)并監(jiān)視我們的用戶，可以幫助減少因?qū)π畔①Y源的非授權(quán)訪問所帶來的問題，但是它也向黑客提供了一個進行攻擊的機會。如果必須認證所有的連接，有人偽造了大量的認證請求，以至于PIX的AAA資源被耗盡，那么將發(fā)生什么呢?PIX防火墻將拒絕繼續(xù)提供服務!如果用戶認證(uauth)子系統(tǒng)用完了資源，“floodguard”命令允許我們可以自動回收PIX防火墻資源。如果一條向內(nèi)的或向外的用戶認證連接正在受到攻擊，或者被過度使用，那么PIX防火墻將主動地收回TCP用戶資源。當資源被耗盡時，PIX防火墻會顯示消息，指明它已經(jīng)沒有資源或沒有TCP用戶了。如果PIX防火墻用戶認證子系統(tǒng)被耗盡，那么將按照下列順序的緊急程度，收回處于不同狀態(tài)的TCP用戶資源：1．等待(Timewait)。

2．結(jié)束等待(FinWait)。

3．未完成的(：Embryonic)。

4．空閑(Idle)。

floodguard命令在缺省情況下被啟用。

floodguard命令的語法如下所示：

floodguardenableldisable這里的enable選項用于啟用AAA風暴防衛(wèi)功能，disable選項則禁止AAA風暴防衛(wèi)功能。9.3.5SYN風暴攻擊防衛(wèi)

SYN風暴防衛(wèi)，也被稱為“TCP風暴"或“半開連接”攻擊，是針對IP服務器的常見DoS攻擊。SYN風暴的攻擊方式如下：

1．攻擊者偽造一個或多個不存在的源IP地址，將大量假裝來自被假冒主機的SYN數(shù)據(jù)包發(fā)往攻擊目標。

2．向一臺主機發(fā)送SYN數(shù)據(jù)包，這是TCP類型連接的三步握手過程中的第一步；因此，目標主機像預期的那樣，用指定到被假冒主機的SYN-ACK數(shù)據(jù)包進行響應。

3．因為這些SYN-ACK數(shù)據(jù)包被發(fā)送到根本不存在的主機，所以目標主機等待的相應ACK數(shù)據(jù)包將永遠不會出現(xiàn)。這樣就會讓目標主機的端口緩沖區(qū)中充滿未完成的或半開放的連接，從而使緩沖區(qū)被占滿，并停止響應合法的請求。圖9—8顯示了這種類型的攻擊。為了保護內(nèi)部主機，使它們免受DoS攻擊，可以使用static命令對允許到服務器的未完成連接的數(shù)量進行限制。使用em-limit參數(shù)，可以限制未完成或半開放連接的數(shù)量，將數(shù)量限制到我們想要保護的服務器可以處理的水平，從而使服務器不會受到DoS的攻擊。在PIX防火墻OS版本5．2中，向SYN風暴防衛(wèi)功能增加了TCP攔截特性。TCP攔截特性改善了PIx防火墻對未完成連接的響應