規則
新增規則
對於每個規則來說,我們需要在網路封包上執行相關“動作”。通常,那些“動作”是指:接受(ACCEPT),阻止(DROP),拒絕(REJECT),轉發(DNAT),改道 (REDIRECT)。除這些動作之外,如來源(Source)、目的地(Destination)、協定(Protocol)、目的埠(Destination Port)、來源埠(Source Port),和初始目的地(Original Destination)。這些屬性,是用來鑒別IP標頭中網路封包的類型,及我們要執行的相關動作。來源(source),表示封包的IP標頭中的“來源IP位址”,或是產生網路封包的區域(net,loc,fw,dmz)。
協定有兩種:UDP和TCP。來源埠 (Source port) 和目的埠 (Destination port),表示它們在IP標頭中的相應區域。初始目的地(Original Destination) 表示在邊界控制路由動作運作於封包前的、位於IP標頭的目的IP位址。您也可在初始目的地 (Original Destination) 中置入IP別名 的IP位址。
就目的地 (Destination) 此屬性來說,它的用法有很多。在接受 (ACCEPT)、阻止 (DROP) 和拒絕 (REJECT) 的動作中,目的地 (Destination)表示網路傳輸將要到達的區域(net,fw,loc,dmz)在此狀況下,,您可以指定規則如,“接受 (ACCEPT) ”從“net”到“fw”與TCP埠23相關聯的傳輸。
設定項目 |
可填入的值(範例或說明) |
指令 (Action) |
ACCEPT, DROP, REJECT, DNAT, REDIRECT |
來源 (Source) |
net, fw, loc, dmz |
目的地 (Destination) |
net, fw, loc, loc:192.168.1.22:80 , loc:192.168.1.2 , 3128 (埠號) |
目的傳輸埠 (Destination Port) |
80, 1024: 等等 … |
來源傳輸埠 (Source Port): |
- |
初始目的IP (Original Destination IP) |
到達eth0的原始目地 IP,例: 1.2.3.4 |
協定 (Protocol) |
UDP, TCP |
速控(Rate Limit)是提供給網路管理者去針對所屬區段的子網路制定完善的安全策略和網路流量管控的一個工具。通過它,可以對網路的總流量做一個管理的機制,讓管理者可以有效地分配頻寬,避免發生濫用者佔用過多頻寬;也可以限制異常流量,緩衝黑客攻擊的衝擊;但在其能對應用流量作出有效的控管之前,要如何針對其現有網路使用狀況,擬定適切的流量管理策略,是在實施控制前不可或缺的。
邊界控制路由上設置極限速率控制的本身的價值是什麼呢?答案取決於伺服器的表現。當短時間內突然遭遇巨量的工作請求,您試圖去保護郵件伺服器或http伺服器時,這顯得尤為重要。
有很多數學模型去預言這種行為。在這裏我們僅以較耳熟能詳的排隊理論模型來解釋它。請求抵達某系統是一種速率為的卜氏過程(Poisson Process);處理那些請求所用的時間是具有指數分佈功能的i.i.d.(獨立同分佈),這也可以被闡述為處理速率是的卜氏過程。在隨機處理理論中,它呈現為一個產生和死亡問題。
在定態中,預計的佇列長度
, 在這裡的 >
在郵件伺服器防禦的情形下,如郵件伺服器的處理速率是每分鐘封郵件,則佇列長度設定為N,以此來保護伺服器。所以,通過上面的公式,我們可以知曉如何在邊界控制路由上設置極限速率。
為詳細說明,我們假設A郵件伺服器之郵件的處理速率:12封/分鐘,預計的平均佇列長度:20
這樣可得 20= /(12 -) ,所以 = 11.43 (emails/min )
因此,在邊界控制路由上,我們應將SMTP連接的極限速率設置為每分鐘11次,以此來保護郵件伺服器免遭垃圾郵件的轟炸攻擊。
為什麼要在這裏提出這個話題呢?這與郵件伺服器的效能有關。假設在掃描了150000個病毒信號及進行內容分析後,伺服器需要花平均5秒鐘的時間去辨別某封郵件是否是垃圾郵件。但很不幸,無數垃圾郵件突然以遠大於前面提及的處理速率的速度抵達伺服器,並且它們不分晝夜持續很長時間地攻擊,這會導致什麼結果呢?
最直覺的反應就是,大家都知道這會致使一大堆郵件在排隊等候處理,郵件伺服器會因此變得行動遲緩。
回顧我們剛才提到的模式,
它意味著當處理速率與抵達速率幾乎一致的時候,佇列長度趨於無限值。所以,當有人向您聲稱某郵件伺服器每天可以處理多達100萬封郵件時,您應問問看那是在什麼測試環境下得出的資料。如果該環境未將資料抵達的速率考慮在內,則您不能寄望該郵件伺服器真的能在一天內處理100萬封郵件。
如果有大量的垃圾郵件在排隊等候以至於系統無法處理時,我們可以做什麼呢?若病毒掃描和內容分析佔用了太多處理時間,那最好的方式是:尋求其他的方法去儘快消除這些垃圾郵件。在這“合適的”方法完工之前,我們可以使用邊界控制路由中的速率控制去調整進入郵件伺服器的通信量。
但正如您可以預知的那樣,針對垃圾郵件去調整最高的抵達速率同樣也會擾亂“正常的”郵件的抵達。它僅能將伺服器維持在活動狀態,而其他實體卻可能因此要努力很長的時間,才能使它們的郵件運送您的郵件伺服器。所以,我們還是必須要能靈活運用相關的功能,去結合其他可使用的方法來解決這個問題。
範例四:打開邊界控制路由上的SMTP埠
接收電子郵件通常是在TCP埠25使用SMTP。因而,我們在邊界控制路由中做以下設定:
指令 (Action): ACCEPT
來源 (Source): net
目的地 (Destination): fw
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 25
範例五:欲使用FTP前必先在邊界控制路由開啟的FTP埠
想要在不同機器之間作檔案的傳輸,在TCP埠20, 21使用FTP的協定是最佳的選擇,因此您需要在邊界控制路由做如下的設定:
指令 (Action): ACCEPT
來源 (Source): net
目的地 (Destination): fw
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 20
指令 (Action): ACCEPT
來源 (Source): net
目的地 (Destination): fw
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 21
範例六:打開邊界控制路由上的DNS通道
當外部網路無法查詢到正確的主機位置時,記得打開UDP埠53,才能讓DNS正常的運作,在邊界控制路由需要做的設定是:
指令 (Action): ACCEPT
來源 (Source): net
目的地 (Destination): fw
協定 (Protocol): UDP
目的傳輸埠 (Destination Port): 53
範例七:封鎖 (DROP) 本地用戶瀏覽網際網路(http 傳輸)
請注意邊界控制路由不單是具備封鎖外部傳輸進入邊界控制路由的能力,也具備封鎖源於邊界控制路由內部傳輸的能力。例如,如您想要禁止內部用戶使用Web瀏覽器去檢視邊界控制路由外的網頁,您只要如此做:
指令 (Action): DROP
來源 (Source): loc
目的地 (Destination): net
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
在此狀況下,所有目的地為TCP埠80的外發傳輸(普通http傳輸)都會被封鎖。如您只是想要封鎖某台特定的電腦去存取外部網頁,您可以在來源中指定IP位址。例如:
指令 (Action): DROP
來源 (Source): loc:192.168.2.21
目的地 (Destination): net
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
這意味著:這台IP位址為192.168.2.21的主機將不能瀏覽網際網路。
封包在經過邊界控制路由時,REJECT 會傳送一個ICMP錯誤封包通知至傳送端,告知封包無法到達目地的原因,大多用於對內部網路主機的回應;而 DROP 則會直接丟棄封包,傳送端並不會收到任何封包無法傳達的通知,這通常會用於對外部網路的回應。之所以要使用DROP的原因不外乎:退回封包通知會增加網路傳輸的負擔、回應封包可能會成為DOS攻擊的媒介、回應的訊息可能有包含入侵者所需要的訊息等。
範例八:邊界控制路由上eth0有多個IP位址—綜合運用傳輸埠轉送和目的網路位址轉換 (DNAT) 與IP別名及目的地屬性格式
應用前面介紹過的IP別名,我們可以在eth0上擁有若干IP位址。現在,我們將此特性與邊界控制路由結合。現在我們嘗試做的是將不同目的IP位址的傳輸轉送給不同的內部伺服器(儘管它們擁有相同的目的埠)。
DNAT是目的網路位址轉換 (Destination Network Address Translation) 的縮寫。它用來改變封包IP標頭中與目的埠和目的IP位址相關的紀錄。應用DNAT時,目的地屬性是如此的格式:
封包區域:IP_位址 (zone:IP_ADDRESS) 或
封包區域:IP_位址:埠號 (zone:IP_ADDRESS:port_number )
例如,loc:192.168.1.21則表示封包會在不改變目的埠的情況下,被轉送到LAN中的192.168.1.21。另一個例子是loc:192.168.1.22:8080表示傳輸將會被轉送到位於LAN區域中的主機,其IP位址為192.168.1.22 的埠8080上;再以上例來做延伸,倘若它是位於邊界控制路由內的一台www伺服器,既已使用埠8080來作為它的傳輸端口,但是對外又想讓人可以從埠80 (http) 就找得到它,該如何做設定呢?
指令 (Action): DNAT
來源 (Source): net
目的地 (Destination): loc:192.168.1.22:8080
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
DNAT是針對 傳輸埠轉送 的基本操作。如果您要在傳輸埠轉送的設定功能表中增加伺服器,您會看到相應的規則會顯示在規則列表的設定頁面。下面的網路圖表可以如此執行:依據初始目的IP位址,用DNAT和IP別名將傳輸轉送給不同的伺服器。
我們用下圖來演示如何使用DNAT。 假設eth0介面擁有3個IP位址:1.2.3.4,1.2.3.5,和1.2.3.6 (額外加入多個公用IP位址可以使用System >> 網路 >> 網際網路 中之IP別名新增的方式)。
另有3個內部伺服器A、B和C,其IP位址分別為192.168.1.2,192.168.1.3和192.168.1.4。
我們要使目的地為1.2.3.4 TCP埠80的封包轉送給主機A,目的地為1.2.3.5 TCP埠8080的封包轉送給主機B,目的地為1.2.3.6 TCP埠8081的封包轉送給主機C。
可以如下設定:
指令 (Action): DNAT
來源 (Source): net
目的地 (Destination): loc:192.168.1.2
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
來源傳輸埠 (Source Port): - (記得需填入 ‘-‘ )
初始目的IP (Original Destination IP): 1.2.3.4
(資料將轉送到主機A)
指令 (Action): DNAT
來源 (Source): net
目的地 (Destination): loc:192.168.1.3
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 8080
來源傳輸埠 (Source Port): -
初始目的IP (Original Destination IP): 1.2.3.5
(資料將轉送到主機B)
指令 (Action): DNAT
來源 (Source): net
目的地 (Destination): loc:192.168.1.4
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 8081
來源傳輸埠 (Source Port): -
初始目的IP (Original Destination IP): 1.2.3.6
(資料將轉送到主機C)
範例九:將傳輸從一個埠改道 (REDIRECT) 至另一個埠
REDIRECT 是指使某個特定類型的傳輸改變方向,而送至邊界控制路由的本地埠。這種情況下,目的地僅僅就是埠資料了。
例如,下面的例子是讓從loc而來、初始目的埠80的傳輸改道至埠3128:
指令 (Action): REDIRECT
來源 (Source): loc
目的地 (Destination): 3128
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
請留意,不要任意將網路資訊流做無意義的轉送。資訊流被轉送後,必須要有一個程式來監聽,若無任何程式在監聽,則該資訊流會被丟棄。 以下是一個有用的例子,它將 “ 目的埠80的TCP資訊流導向埠 443” 使得 “http” 資訊流變為 “https” 資訊流。 ( TCP 埠 443 常設為“https” 埠 )
指令 (Action): REDIRECT
來源 (Source): loc
目的地 (Destination): 443
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
當您向邊界控制路由增加某條規則時,請注意以下細節。例如,在處理邊界控制路由內的網路封包時,部分不用注意的屬性,可空著不填。但有時您會發現因為這些“空白欄位”的關係,會導致您曾輸入的某些的欄位資訊,不會顯示在相應位置。這歸因於分解字串時,那些設定參數的內部處理邏輯。這種情況下,您可以只用“-”來表示“空白”,從而來避免混淆並使規則列表功能表上的規則能正常顯示。
請注意 傳輸埠轉送 和 LAN-NET路由迴路 會顯示在規則列表功能表中的一些規則。但這不意味著所有與 傳輸埠轉送 和 LAN-NET路由迴路 相關的規則都會顯示出來。有些規則無法在此格式中展現,它們涉及到一些追蹤網路封包的關係創建方面的細節。這部分已經超出本書的範圍了,不在這裡介紹。
範例十:運用速控以避免因流量過大造成的網站崩潰
太過熱門的網站或是遭受惡意攻擊的網站通常都會有流量過大的問題,瞬間流量過大會使主機忙碌不堪,而若持續流量過大則可能導致網站癱瘓,可用流量控制來避免此類情形發生。
指令 (Action): ACCEPT
來源 (Source): net
目的地 (Destination): fw
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 80
速控 (Rate Limit): 平均 60
極速 60
單位 min
在“速控”的部分,“平均”意味著系統會將當前傳輸速率與機器前一次重新啟動之後的平均值做比較;如果該平均值超過了限定,系統會關閉連接。“極速”是指在任一時間間隔單位,都不應該超出限定。
上列的規則所表達的意思是:在開機後,伺服器平均每分鐘所能允許的流量為60次的存取;而在平均的設定項目次數是可累計的,也就是主機開機時間越久,所能允許的連線次數便可累積越多,除非主機有重新開機,否則便會持續累計;如果您擔心主機太久沒有重新啟動而使累積次數過大的話,極速便是讓您在設定每分鐘的單位裡所能允許的存取極限次數;以上的範例只是提供您做參考,主機效能的影響因素有很多,您必須依您就有的現況,因地因時來做最有效的安排。
移除規則
您可為處理網路封包而向邊界控制路由新增規則,也可移除邊界控制路由中現存的規則。移除邊界控制路由中的規則會引起一系列的影響。按下與該規則相關的 移除 按鈕,對跳出的詢問對話框做出確認動作,就可以完成移除的動作。
請注意在邊界控制路由設定改變之後,系統須重新啟動。
即時通 (Instant Messenger) 管理規則
封鎖如MSN Messenger、Yahoo Messenger、AIM、ICQ、QQ或Skype等其他即時通訊工具的傳輸,在某些地方或場合看起來是一個很嚴重的問題。這裏,我們不去爭論這一類的傳輸是否應該封鎖:有些人可能爭辯說這類工具促進了人們彼此的交流;有些人則辯說這類應用會消耗系統資源(網路頻寬,工作專心與否,等等),或者說在發展中國家頻寬是非常昂貴且被壟斷的。是否應該封鎖此類應用,眾說紛云,沒有定見。我們僅簡單地描述此類即時通訊工具的傳輸方式,而將剩下的工作 --- 即如何使用手邊的工具去建構自己的網路,則交由您自己去處理。
在以前NAT還不流行時,某些及時通訊工具僅僅是讓兩個終端用戶,在郵件伺服器上進行登錄後直接交流。隨著NAT結合邊界控制路由的設定,使用的普及,那些即時通訊訊息被加上更多且複雜的設定,以探測網路佈局或方法。舉例來說,電腦都具有“直接的NAT”或使用結合UDP或TCP封包來發出初始的外送訊息,或者透過一些自動調整架構而建立出眾多的超級節點,如此其下的眾多用戶端,就能基於這些初始節點,來開始從事訊息傳遞了。
封鎖這些即時訊息並不能僅僅靠“簡單的”設定來完成,如關閉4或5個埠,或者將一些IP位址放入“黑名單”來封鎖。這些簡單設定,有一些在初始的時候可能有用,但卻非“一勞永逸”的解決方法。那些即時通訊工具也在不斷發展中,如今,某些即時聊天工具會掃描所有可用的埠(它們甚至可用TCP埠80或433-這些當初是僅供http或https使用的埠),並用私有的協定將封包加密。此外,初始的外發連接封包所用的目的IP位址,甚至都會改變了-它是個活動的目標。某些人可能會想利用透過傳輸分析,來抓取某特定即時訊息工具的一些信號,並試圖以這在搜集到的即時傳輸訊息的基礎上去封鎖它們,但這也不是一個“一勞永逸”的解決方法。
所以,怎麼去封鎖此類的傳輸呢? 我們可以按以下的方式思考:所有在1024以下埠的資料都是供IANA(網際網路指派資料管理Internet Assigned Numbers Authority-網際網路上一個“資料指派”的組織)專用的。所以,當某個即時訊息工具在做埠掃描時,它會首先掃描1024以上的埠,如1025至65535。
所以,可以封鎖目的埠在1024以上的、從loc至net的外發的傳輸。(您可以填入“1024:”到在目的埠的欄位中)但如果那些即時通訊工具,使用目的埠80或者433的情形又當如何呢?封鎖所有目的埠80或433從loc至net的外發傳輸嗎?您可能不能接受這個方法,因為您還要使用“http”;您不想因為那些即時通訊工具而去封鎖http的傳輸。然而我們的答案是:一旦您封鎖了那些外發的傳輸,您可以用 代理伺服器,並須在邊界控制路由上設定 http的代理伺服器。並且您須要強制所有邊界控制路由內的人,都使用代理伺服器。換句話說,從loc至net的傳輸都是被禁止的--只有某些從loc至fw的埠才被允許,然後從fw至net,則使用代理伺服器。
那如果未來有些即時通訊工具,使用了TCP埠25(email所用的)呢?如果您確實是要用類似剛才那樣的方式來封鎖,那除了將電子郵件伺服器放在邊界控制路由上外別無選擇。您想那樣做嗎? 那是網路規劃的問題了;您不得不做些抉擇,並在同一時間去考慮其他的方法。
一旦您明白了上面提及的基本原理,另外還有其他一些複雜的設定可以用。例如,若您只允許郵件伺服器和http代理伺服器的機器可以擁有外發封包,卻仍然將“http代理伺服器”或者“郵件伺服器”置於邊界控制路由內部的機器上,而不是邊界控制路由上。 在執行這些計畫和設定時,您必需從網路的彈性或擴充性上考慮及是否容易做日常的運行及維護。
範例十一:封鎖所有目的TCP埠在1024以上的外發傳輸
指令 (Action): DROP
來源 (Source): loc
目的地 (Destination): net
協定 (Protocol): TCP
目的傳輸埠 (Destination Port): 1024: (請注意末尾的 : 符號)
在本書的末尾處,我們會告訴您如何做辦公室的網路規劃。
IP置換
IP置換是用於設定於置換通往外部網路封包中的來源IP地址。
由於此邊界控制路由帶有NAT的功能,所以,所有的傳輸都會經由網路位址轉換後才能被送出。也就是說當在邊界控制路由裡面的使用者,在送出要求要連到一個位於邊界控制路由外的網站或是資源的時候,那麼NAT就會發揮它的功用,把邊界控制路由內部的私有IP位址送出的封包檔頭裡面來源端的位址,改成主機共用一個公共IP位址,再做送出封包的動作。但若只有一台邊界控制路由,對外傳輸也就只有使用一個公共IP位址,在某些情況下,我們希望能讓單一主機的對外傳輸能有多個公共IP在變換,類似就像有很多不同的主機在運作一樣,這與效能無關,目的主要是偽裝。
一般情況下並不用在此處做任何設定。這牽涉到比較特殊的網路需求,只有在有特殊網路規劃的需求下,才要做此類的設定。
|