防火墻的工作原理是怎樣的
防火墻借由監(jiān)測所有的封包并找出不符規(guī)則的內(nèi)容，可以防范電腦蠕蟲或是木馬程序的快速蔓延。這篇文章主要介紹了防火墻的工作原理概述,需要的朋友可以參考下
具體介紹
防火墻就是一種過濾塞(目前你這么理解不算錯)，你可以讓你喜歡的東西通過這個塞子，別的玩意都統(tǒng)統(tǒng)過濾掉。在網(wǎng)絡的世界里，要由防火墻過濾的就是承載通信數(shù)據(jù)的通信包。
天下的防火墻至少都會說兩個詞：Yes或者No。直接說就是接受或者拒絕。最簡單的防火墻是以太網(wǎng)橋。但幾乎沒有人會認為這種原始防火墻能管多大用。大多數(shù)防火墻采用的技術和標準可謂五花八門。這些防火墻的形式多種多樣：
有的取代系統(tǒng)上已經(jīng)裝備的TCP/IP協(xié)議棧;有的在已有的協(xié)議棧上建立自己的軟件模塊;有的干脆就是獨立的一套操作系統(tǒng);還有一些應用型的防火墻只對特定類型的網(wǎng)絡連接提供保護(比如SMTP或者HTTP協(xié)議等);還有一些基于硬件的防火墻產(chǎn)品其實應該歸入安全路由器一類。
以上的產(chǎn)品都可以叫做防火墻，因為他們的工作方式都是一樣的：分析出入防火墻的數(shù)據(jù)包，決定放行還是把他們?nèi)拥揭贿叀?/p>
所有的防火墻都具有IP地址過濾功能。這項任務要檢查IP包頭，根據(jù)其IP源地址和目標地址作出放行/丟棄決定?？纯聪旅孢@張圖，兩個網(wǎng)段之間隔了一個防火墻，防火墻的一端有臺UNIX計算機，另一邊的網(wǎng)段則擺了臺PC客戶機。
當PC客戶機向UNIX計算機發(fā)起telnet請求時，PC的telnet客戶程序就產(chǎn)生一個TCP包并把它傳給本地的協(xié)議棧準備發(fā)送。接下來，協(xié)議棧將這個TCP包“塞”到一個IP包里，然后通過PC機的TCP/IP棧所定義的路徑將它發(fā)送給UNIX計算機。在這個例子里，這個IP包必須經(jīng)過橫在PC和UNIX計算機中的防火墻才能到達UNIX計算機。
現(xiàn)在我們“命令”(用專業(yè)術語來說就是配制)防火墻把所有發(fā)給UNIX計算機的數(shù)據(jù)包都給拒了，完成這項工作以后，“心腸”比較好的防火墻還會通知客戶程序一聲呢!既然發(fā)向目標的IP數(shù)據(jù)沒法轉發(fā)，那么只有和UNIX計算機同在一個網(wǎng)段的用戶才能訪問UNIX計算機了。
還有一種情況，你可以命令防火墻專給那臺可憐的PC機找茬，別人的數(shù)據(jù)包都讓過就它不行。這正是防火墻最基本的功能：根據(jù)IP地址做轉發(fā)判斷。但要上了大場面這種小伎倆就玩不轉了，由于黑客們可以采用IP地址欺騙技術，偽裝成合法地址的計算機就可以穿越信任這個地址的防火墻了。不過根據(jù)地址的轉發(fā)決策機制還是最基本和必需的。另外要注意的一點是，不要用DNS主機名建立過濾表，對DNS的偽造比IP地址欺騙要容易多了。
服務器TCP/UDP 端口過濾
僅僅依靠地址進行數(shù)據(jù)過濾在實際運用中是不可行的，還有個原因就是目標主機上往往運行著多種通信服務，比方說，我們不想讓用戶采用 telnet 的方式連到系統(tǒng)，但這絕不等于我們非得同時禁止他們使用SMTP/POP郵件服務器吧?所以說，在地址之外我們還要對服務器的TCP/ UDP端口進行過濾。
比如，默認的telnet服務連接端口號是23。假如我們不許PC客戶機建立對UNIX計算機(在這時我們當它是服務器)的telnet連接，那么我們只需命令防火墻檢查發(fā)送目標是UNIX服務器的數(shù)據(jù)包，把其中具有23目標端口號的包過濾就行了。這樣，我們把IP地址和目標服務器TCP/UDP端口結合起來不就可以作為過濾標準來實現(xiàn)相當可靠的防火墻了嗎?不，沒這么簡單。
客戶機也有TCP/UDP端口
TCP/IP是一種端對端協(xié)議，每個網(wǎng)絡節(jié)點都具有唯一的地址。網(wǎng)絡節(jié)點的應用層也是這樣，處于應用層的每個應用程序和服務都具有自己的對應“地址”，也就是端口號。地址和端口都具備了才能建立客戶機和服務器的各種應用之間的有效通信聯(lián)系。比如，telnet服務器在端口23偵聽入站連接。同時telnet客戶機也有一個端口號，否則客戶機的IP棧怎么知道某個數(shù)據(jù)包是屬于哪個應用程序的呢?
由于歷史的原因，幾乎所有的TCP/IP客戶程序都使用大于1023的隨機分配端口號。只有UNIX計算機上的root用戶才可以訪問1024以下的端口，而這些端口還保留為服務器上的服務所用。所以，除非我們讓所有具有大于1023端口號的數(shù)據(jù)包進入網(wǎng)絡，否則各種網(wǎng)絡連接都沒法正常工作。
這對防火墻而言可就麻煩了，如果阻塞入站的全部端口，那么所有的客戶機都沒法使用網(wǎng)絡資源。因為服務器發(fā)出響應外部連接請求的入站(就是進入防火墻的意思)數(shù)據(jù)包都沒法經(jīng)過防火墻的入站過濾。反過來，打開所有高于1023的端口就可行了嗎?也不盡然。由于很多服務使用的端口都大于1023，比如X client、基于RPC的NFS服務以及為數(shù)眾多的非UNIX IP產(chǎn)品等(NetWare/IP)就是這樣的。那么讓達到1023端口標準的數(shù)據(jù)包都進入網(wǎng)絡的話網(wǎng)絡還能說是安全的嗎?連這些客戶程序都不敢說自己是足夠安全的。
雙向過濾
OK，咱們換個思路。我們給防火墻這樣下命令：已知服務的數(shù)據(jù)包可以進來，其他的全部擋在防火墻之外。比如，如果你知道用戶要訪問Web服務器，那就只讓具有源端口號80的數(shù)據(jù)包進入網(wǎng)絡：
不過新問題又出現(xiàn)了。首先，你怎么知道你要訪問的服務器具有哪些正在運行的端口號呢? 象HTTP這樣的服務器本來就是可以任意配置的，所采用的端口也可以隨意配置。如果你這樣設置防火墻，你就沒法訪問哪些沒采用標準端口號的的網(wǎng)絡站點了!反過來，你也沒法保證進入網(wǎng)絡的數(shù)據(jù)包中具有端口號80的就一定來自Web服務器。有些黑客就是利用這一點制作自己的入侵工具，并讓其運行在本機的80端口!
檢查ACK位
源地址我們不相信，源端口也信不得了，這個不得不與黑客共舞的瘋狂世界上還有什么值得我們信任呢?還好，事情還沒到走投無路的地步。對策還是有的，不過這個辦法只能用于TCP協(xié)議。
TCP是一種可靠的通信協(xié)議，“可靠”這個詞意味著協(xié)議具有包括糾錯機制在內(nèi)的一些特殊性質。為了實現(xiàn)其可靠性，每個TCP連接都要先經(jīng)過一個“握手”過程來交換連接參數(shù)。還有，每個發(fā)送出去的包在后續(xù)的其他包被發(fā)送出去之前必須獲得一個確認響應。但并不是對每個TCP包都非要采用專門的ACK包來響應，實際上僅僅在TCP包頭上設置一個專門的位就可以完成這個功能了。所以，只要產(chǎn)生了響應包就要設置ACK位。連接會話的第一個包不用于確認，所以它就沒有設置ACK位，后續(xù)會話交換的TCP包就要設置ACK位了。
舉個例子，PC向遠端的Web服務器發(fā)起一個連接，它生成一個沒有設置ACK位的連接請求包。當服務器響應該請求時，服務器就發(fā)回一個設置了ACK位的數(shù)據(jù)包，同時在包里標記從客戶機所收到的字節(jié)數(shù)。然后客戶機就用自己的響應包再響應該數(shù)據(jù)包，這個數(shù)據(jù)包也設置了ACK位并標記了從服務器收到的字節(jié)數(shù)。通過監(jiān)視ACK位，我們就可以將進入網(wǎng)絡的數(shù)據(jù)限制在響應包的范圍之內(nèi)。于是，遠程系統(tǒng)根本無法發(fā)起TCP連接但卻能響應收到的數(shù)據(jù)包了。
這套機制還不能算是無懈可擊，簡單地舉個例子，假設我們有臺內(nèi)部Web服務器，那么端口80就不得不被打開以便外部請求可以進入網(wǎng)絡。還有，對UDP包而言就沒法監(jiān)視ACK位了，因為UDP包壓根就沒有ACK位。還有一些TCP應用程序，比如FTP，連接就必須由這些服務器程序自己發(fā)起。
FTP帶來的困難
一般的Internet服務對所有的通信都只使用一對端口號，F(xiàn)TP程序在連接期間則使用兩對端口號。第一對端口號用于FTP的“命令通道”提供登錄和執(zhí)行命令的通信鏈路，而另一對端口號則用于FTP的“數(shù)據(jù)通道”提供客戶機和服務器之間的文件傳送。
在通常的FTP會話過程中，客戶機首先向服務器的端口21(命令通道)發(fā)送一個TCP連接請求，然后執(zhí)行LOGIN、DIR等各種命令。一旦用戶請求服務器發(fā)送數(shù)據(jù)，F(xiàn)TP服務器就用其20端口 (數(shù)據(jù)通道)向客戶的數(shù)據(jù)端口發(fā)起連接。問題來了，如果服務器向客戶機發(fā)起傳送數(shù)據(jù)的連接，那么它就會發(fā)送沒有設置ACK位的數(shù)據(jù)包，防火墻則按照剛才的規(guī)則拒絕該數(shù)據(jù)包同時也就意味著數(shù)據(jù)傳送沒戲了。通常只有高級的、也就是夠聰明的防火墻才能看出客戶機剛才告訴服務器的端口，然后才許可對該端口的入站連接。
UDP端口過濾
好了，現(xiàn)在我們回過頭來看看怎么解決UDP問題。剛才說了，UDP包沒有ACK位所以不能進行ACK位過濾。UDP 是發(fā)出去不管的“不可靠”通信，這種類型的服務通常用于廣播、路由、多媒體等廣播形式的通信任務。NFS、DNS、WINS、NetBIOS-over-TCP/IP和 NetWare/IP都使用UDP。
看來最簡單的可行辦法就是不允許建立入站UDP連接。防火墻設置為只許轉發(fā)來自內(nèi)部接口的UDP包，來自外部接口的UDP包則不轉發(fā)?，F(xiàn)在的問題是，比方說，DNS名稱解析請求就使用UDP，如果你提供DNS服務，至少得允許一些內(nèi)部請求穿越防火墻。還有IRC這樣的客戶程序也使用UDP，如果要讓你的用戶使用它，就同樣要讓他們的UDP包進入網(wǎng)絡。我們能做的就是對那些從本地到可信任站點之間的連接進行限制。但是，什么叫可信任!如果黑客采取地址欺騙的方法不又回到老路上去了嗎?
有些新型路由器可以通過“記憶”出站UDP包來解決這個問題：如果入站UDP包匹配最近出站UDP包的目標地址和端口號就讓它進來。如果在內(nèi)存中找不到匹配的UDP包就只好拒絕它了!但是，我們?nèi)绾未_信產(chǎn)生數(shù)據(jù)包的外部主機就是內(nèi)部客戶機希望通信的服務器呢?如果黑客詐稱DNS服務器的地址，那么他在理論上當然可以從附著DNS的UDP端口發(fā)起攻擊。只要你允許DNS查詢和反饋包進入網(wǎng)絡這個問題就必然存在。辦法是采用代理服務器。
所謂代理服務器，顧名思義就是代表你的網(wǎng)絡和外界打交道的服務器。代理服務器不允許存在任何網(wǎng)絡內(nèi)外的直接連接。它本身就提供公共和專用的DNS、郵件服務器等多種功能。代理服務器重寫數(shù)據(jù)包而不是簡單地將其轉發(fā)了事。給人的感覺就是網(wǎng)絡內(nèi)部的主機都站在了網(wǎng)絡的邊緣，但實際上他們都躲在代理的后面，露面的不過是代理這個假面具。
補充閱讀：防火墻主要使用技巧
一、所有的防火墻文件規(guī)則必須更改。
盡管這種方法聽起來很容易，但是由于防火墻沒有內(nèi)置的變動管理流程，因此文件更改對于許多企業(yè)來說都不是最佳的實踐方法。如果防火墻管理員因為突發(fā)情況或者一些其他形式的業(yè)務中斷做出更改，那么他撞到槍口上的可能性就會比較大。但是如果這種更改抵消了之前的協(xié)議更改，會導致宕機嗎?這是一個相當高發(fā)的狀況。
防火墻管理產(chǎn)品的中央控制臺能全面可視所有的防火墻規(guī)則基礎，因此團隊的所有成員都必須達成共識，觀察誰進行了何種更改。這樣就能及時發(fā)現(xiàn)并修理故障，讓整個協(xié)議管理更加簡單和高效。
二、以最小的權限安裝所有的訪問規(guī)則。
另一個常見的安全問題是權限過度的規(guī)則設置。防火墻規(guī)則是由三個域構成的：即源(IP地址)，目的地(網(wǎng)絡/子網(wǎng)絡)和服務(應用軟件或者其他目的地)。為了確保每個用戶都有足夠的端口來訪問他們所需的系統(tǒng)，常用方法是在一個或者更多域內(nèi)指定打來那個的目標對象。當你出于業(yè)務持續(xù)性的需要允許大范圍的IP地址來訪問大型企業(yè)的網(wǎng)絡，這些規(guī)則就會變得權限過度釋放，因此就會增加不安全因素。服務域的規(guī)則是開放65535個TCP端口的ANY。防火墻管理員真的就意味著為黑客開放了65535個攻擊矢量?
三、根據(jù)法規(guī)協(xié)議和更改需求來校驗每項防火墻的更改。
在防火墻操作中，日常工作都是以尋找問題，修正問題和安裝新系統(tǒng)為中心的。在安裝最新防火墻規(guī)則來解決問題，應用新產(chǎn)品和業(yè)務部門的過程中，我們經(jīng)常會遺忘防火墻也是企業(yè)安全協(xié)議的物理執(zhí)行者。每項規(guī)則都應該重新審核來確保它能符合安全協(xié)議和任何法規(guī)協(xié)議的內(nèi)容和精神，而不僅是一篇法律條文。
四、當服務過期后從防火墻規(guī)則中刪除無用的規(guī)則。
規(guī)則膨脹是防火墻經(jīng)常會出現(xiàn)的安全問題，因為多數(shù)運作團隊都沒有刪除規(guī)則的流程。業(yè)務部門擅長讓你知道他們了解這些新規(guī)則，卻從來不會讓防火墻團隊知道他們不再使用某些服務了。了解退役的服務器和網(wǎng)絡以及應用軟件更新周期對于達成規(guī)則共識是個好的開始。運行無用規(guī)則的報表是另外一步。黑客喜歡從來不刪除規(guī)則的防火墻團隊。
防火墻的工作原理是怎樣的相關文章：