防火墻的工作原理
加入技術(shù)交流群
雙向過(guò)濾
OK，咱們換個(gè)思路。我們給防火墻這樣下命令：已知服務(wù)的數據包可以進(jìn)來(lái)，其他的全部擋在防火墻之外。比如，如果你知道用戶(hù)要訪(fǎng)問(wèn)Web服務(wù)器，那就只讓具有源端口號80的數據包進(jìn)入網(wǎng)絡(luò )：
不過(guò)新問(wèn)題又出現了。首先，你怎么知道你要訪(fǎng)問(wèn)的服務(wù)器具有哪些正在運行的端口號呢？ 象HTTP這樣的服務(wù)器本來(lái)就是可以任意配置的，所采用的端口也可以隨意配置。如果你這樣設置防火墻，你就沒(méi)法訪(fǎng)問(wèn)哪些沒(méi)采用標準端口號的的網(wǎng)絡(luò )站點(diǎn)了！反過(guò)來(lái)，你也沒(méi)法保證進(jìn)入網(wǎng)絡(luò )的數據包中具有端口號80的就一定來(lái)自Web服務(wù)器。有些黑客就是利用這一點(diǎn)制作自己的入侵工具，并讓其運行在本機的80端口！
檢查ACK位
源地址我們不相信，源端口也信不得了，這個(gè)不得不與黑客共舞的瘋狂世界上還有什么值得我們信任呢？還好，事情還沒(méi)到走投無(wú)路的地步。對策還是有的，不過(guò)這個(gè)辦法只能用于TCP協(xié)議?！?br />
TCP是一種可靠的通信協(xié)議，“可靠”這個(gè)詞意味著(zhù)協(xié)議具有包括糾錯機制在內的一些特殊性質(zhì)。為了實(shí)現其可靠性，每個(gè)TCP連接都要先經(jīng)過(guò)一個(gè)“握手”過(guò)程來(lái)交換連接參數。還有，每個(gè)發(fā)送出去的包在后續的其他包被發(fā)送出去之前必須獲得一個(gè)確認響應。但并不是對每個(gè)TCP包都非要采用專(zhuān)門(mén)的ACK包來(lái)響應，實(shí)際上僅僅在TCP包頭上設置一個(gè)專(zhuān)門(mén)的位就可以完成這個(gè)功能了。所以，只要產(chǎn)生了響應包就要設置ACK位。連接會(huì )話(huà)的第一個(gè)包不用于確認，所以它就沒(méi)有設置ACK位，后續會(huì )話(huà)交換的TCP包就要設置ACK位了?！?br />
舉個(gè)例子，PC向遠端的Web服務(wù)器發(fā)起一個(gè)連接，它生成一個(gè)沒(méi)有設置ACK位的連接請求包。當服務(wù)器響應該請求時(shí)，服務(wù)器就發(fā)回一個(gè)設置了ACK位的數據包，同時(shí)在包里標記從客戶(hù)機所收到的字節數。然后客戶(hù)機就用自己的響應包再響應該數據包，這個(gè)數據包也設置了ACK位并標記了從服務(wù)器收到的字節數。通過(guò)監視ACK位，我們就可以將進(jìn)入網(wǎng)絡(luò )的數據限制在響應包的范圍之內。于是，遠程系統根本無(wú)法發(fā)起TCP連接但卻能響應收到的數據包了?！?br />
這套機制還不能算是無(wú)懈可擊，簡(jiǎn)單地舉個(gè)例子，假設我們有臺內部Web服務(wù)器，那么端口80就不得不被打開(kāi)以便外部請求可以進(jìn)入網(wǎng)絡(luò )。還有，對UDP包而言就沒(méi)法監視ACK位了，因為UDP包壓根就沒(méi)有ACK位。還有一些TCP應用程序，比如FTP，連接就必須由這些服務(wù)器程序自己發(fā)起?！?br />
FTP帶來(lái)的困難
一般的Internet服務(wù)對所有的通信都只使用一對端口號，FTP程序在連接期間則使用兩對端口號。第一對端口號用于FTP的“命令通道”提供登錄和執行命令的通信鏈路，而另一對端口號則用于FTP的“數據通道”提供客戶(hù)機和服務(wù)器之間的文件傳送?！?br />
在通常的FTP會(huì )話(huà)過(guò)程中，客戶(hù)機首先向服務(wù)器的端口21（命令通道）發(fā)送一個(gè)TCP連接請求，然后執行LOGIN、DIR等各種命令。一旦用戶(hù)請求服務(wù)器發(fā)送數據，FTP服務(wù)器就用其20端口 (數據通道)向客戶(hù)的數據端口發(fā)起連接。問(wèn)題來(lái)了，如果服務(wù)器向客戶(hù)機發(fā)起傳送數據的連接，那么它就會(huì )發(fā)送沒(méi)有設置ACK位的數據包，防火墻則按照剛才的規則拒絕該數據包同時(shí)也就意味著(zhù)數據傳送沒(méi)戲了。通常只有高級的、也就是夠聰明的防火墻才能看出客戶(hù)機剛才告訴服務(wù)器的端口，然后才許可對該端口的入站連接?！?br />
UDP端口過(guò)濾
好了，現在我們回過(guò)頭來(lái)看看怎么解決UDP問(wèn)題。剛才說(shuō)了，UDP包沒(méi)有ACK位所以不能進(jìn)行ACK位過(guò)濾。UDP 是發(fā)出去不管的“不可靠”通信，這種類(lèi)型的服務(wù)通常用于廣播、路由、多媒體等廣播形式的通信任務(wù)。NFS、DNS、WINS、NetBIOS-over-TCP/IP和 NetWare/IP都使用UDP?！?br />
看來(lái)最簡(jiǎn)單的可行辦法就是不允許建立入站UDP連接。防火墻設置為只許轉發(fā)來(lái)自?xún)炔拷涌诘腢DP包，來(lái)自外部接口的UDP包則不轉發(fā)?，F在的問(wèn)題是，比方說(shuō)，DNS名稱(chēng)解析請求就使用UDP，如果你提供DNS服務(wù)，至少得允許一些內部請求穿越防火墻。還有IRC這樣的客戶(hù)程序也使用UDP，如果要讓你的用戶(hù)使用它，就同樣要讓他們的UDP包進(jìn)入網(wǎng)絡(luò )。我們能做的就是對那些從本地到可信任站點(diǎn)之間的連接進(jìn)行限制。但是，什么叫可信任！如果黑客采取地址欺騙的方法不又回到老路上去了嗎？
有些新型路由器可以通過(guò)“記憶”出站UDP包來(lái)解決這個(gè)問(wèn)題：如果入站UDP包匹配最近出站UDP包的目標地址和端口號就讓它進(jìn)來(lái)。如果在內存中找不到匹配的UDP包就只好拒絕它了！但是，我們如何確信產(chǎn)生數據包的外部主機就是內部客戶(hù)機希望通信的服務(wù)器呢？如果黑客詐稱(chēng)DNS服務(wù)器的地址，那么他在理論上當然可以從附著(zhù)DNS的UDP端口發(fā)起攻擊。只要你允許DNS查詢(xún)和反饋包進(jìn)入網(wǎng)絡(luò )這個(gè)問(wèn)題就必然存在。辦法是采用代理服務(wù)器?！?br />
所謂代理服務(wù)器，顧名思義就是代表你的網(wǎng)絡(luò )和外界打交道的服務(wù)器。代理服務(wù)器不允許存在任何網(wǎng)絡(luò )內外的直接連接。它本身就提供公共和專(zhuān)用的DNS、郵件服務(wù)器等多種功能。代理服務(wù)器重寫(xiě)數據包而不是簡(jiǎn)單地將其轉發(fā)了事。給人的感覺(jué)就是網(wǎng)絡(luò )內部的主機都站在了網(wǎng)絡(luò )的邊緣，但實(shí)際上他們都躲在代理的后面，露面的不過(guò)是代理這個(gè)假面具?！?br />
小結
IP地址可能是假的，這是由于IP協(xié)議的源路有機制所帶來(lái)的，這種機制告訴路由器不要為數據包采用正常的路徑，而是按照包頭內的路徑傳送數據包。于是黑客就可以使用系統的IP地址獲得返回的數據包。有些高級防火墻可以讓用戶(hù)禁止源路由。通常我們的網(wǎng)絡(luò )都通過(guò)一條路徑連接ISP，然后再進(jìn)入Internet。這時(shí)禁用源路由就會(huì )迫使數據包必須沿著(zhù)正常的路徑返回?！?br />
還有，我們需要了解防火墻在拒絕數據包的時(shí)候還做了哪些其他工作。比如，防火墻是否向連接發(fā)起系統發(fā)回了“主機不可到達”的ICMP消息？或者防火墻真沒(méi)再做其他事？這些問(wèn)題都可能存在安全隱患。ICMP“主機不可達”消息會(huì )告訴黑客“防火墻專(zhuān)門(mén)阻塞了某些端口”，黑客立即就可以從這個(gè)消息中聞到一點(diǎn)什么氣味。如果ICMP“主機不可達”是通信中發(fā)生的錯誤，那么老實(shí)的系統可能就真的什么也不發(fā)送了。反過(guò)來(lái)，什么響應都沒(méi)有卻會(huì )使發(fā)起通信的系統不斷地嘗試建立連接直到應用程序或者協(xié)議棧超時(shí)，結果最終用戶(hù)只能得到一個(gè)錯誤信息。當然這種方式會(huì )讓黑客無(wú)法判斷某端口到底是關(guān)閉了還是沒(méi)有使用。本文引用地址：http://dyxdggzs.com/article/155626.htm
tcp/ip相關(guān)文章:tcp/ip是什么
評論