您好,登錄后才能下訂單哦!
本篇文章為大家展示了pfSense book配置防火墻的規則是什么,內容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
在防火墻>規則策略下配置防火墻規則時,有許多選項可用于控制流量的匹配和控制方式。 本節列出了大部分選項,因為pfsense book是以pfsense2.31來進行示例的,與現在pfsense2.41可能有些許不同。
該選項指定規則是否通過、阻止或拒絕流量。
通過: 符合此規則的數據包將被允許通過防火墻。 如果為規則啟用了狀態跟蹤,則會創建一個允許相關返回流量回傳的狀態表條目。
阻止: 符合此規則的數據包將被丟棄。
拒絕: 匹配這個規則的數據包將被丟棄,對于支持的協議,一條消息將被發送回始發者,表明連接被拒絕。
要禁用規則而不將其從規則列表中刪除,請選中此框。 它仍將顯示在防火墻規則頁面中,但該規則將顯示為灰色以提示其禁用狀態。
“接口”下拉菜單指定接收由此規則控制的流量的接口。 請記住,在接口和組選項卡規則中,流量僅在啟動流量的接口上被過濾。 從局域網發起的流量指向Internet或防火墻上的任何其他接口由LAN規則集過濾。
提示規則應用于IPv4,IPv6或同時應用IPv4 + IPv6流量。 這些規則將只匹配正確協議的數據包并采取動作。 可以使用包含這兩種IP地址的別名,并且該規則將僅匹配來自正確協議的地址。
規則將匹配的協議。 這些選項大部分都是不言自明的。 TCP / UDP將同時匹配TCP和UDP流量。 指定ICMP將顯示一個額外的下拉框來選擇ICMP類型。 其他幾個常見的協議也是可用的。
注意
這個字段默認為新的規則的TCP,因為它是一個通用的默認值,它將顯示該協議的預期字段。 要使規則適用于任何協議,請將此字段更改為any。 創建新規則最常見的錯誤之一是意外創建TCP規則,然后無法傳遞其他非TCP流量,如ping,DNS等。
選擇ICMP作為協議時,該下拉列表包含所有可能的ICMP類型。 通過ICMP時,最好的做法是只在可行的時候通過所需的類型。 最常見的用例是只傳遞一種回應請求,允許ICMP ping通。
提示
從歷史上看,ICMP的聲譽很差,但通常是有益的。 在允許ICMP時,允許任何ICMP類型通常是可以接受的。
該字段指定將匹配此規則的源IP地址,子網或別名。
源地址的下拉框允許幾種不同的預定義類型的源地址:
Any: 匹配任何地址。
單個主機或別名:匹配一個IP地址或別名。 當它處于活動狀態時,可以在“源地址”字段中鍵入一個別名。
網絡:使用IP地址和子網掩碼來匹配一個地址范圍。
PPPoE客戶端: 如果啟用了PPPoE服務器,則匹配來自PPPoE服務器的客戶端地址范圍的流量。
L2TP客戶端: 如果啟用了L2TP服務器,則將匹配來自L2TP服務器的客戶端地址范圍流量。
接口網絡:防火墻上的每個接口都有此列表中的條目。 這種源類型準確指定了該接口的子網,包括與定義的接口子網不同的任何IP別名VIP子網。
接口地址:防火墻上的每個接口都有此列表中的條目。這些源類型指定在該接口上配置的IP地址。
警告
源網絡或目的網絡的WAN Net選項僅表示WAN接口的子網。 這并不意味著“互聯網”或任何遠程主機。
對于匹配TCP和或UDP的規則,也可以通過點擊 顯示高級設置指定源端口。 源端口隱藏在“顯示高級”按鈕后面,因為通常源端口必須保持設置為任意端口,因為TCP和UDP連接源于臨時端口范圍內的隨機端口(在1024到65535之間,所使用的確切范圍取決于連接的操作系統和操作系統版本)。 源端口幾乎不會與目標端口相同,也不應該像這樣配置,除非正在使用的應用程序已知使用這種非典型行為。 將源端口定義為從1024到65535的范圍也是安全的。
選擇反轉匹配將取消匹配,以便除源值之外的所有通信都將觸發規則。
該字段指定將匹配此規則的目標IP地址,子網或別名。
對于指定TCP和或UDP的規則,此處還指定了目標端口,端口范圍或別名。 與源不同,在許多情況下配置目的端口是必需的,因為它比使用任何端口更安全,并且通常基于協議預先知道目的端口。 下拉列表中提供了許多常用端口值,或者選擇(其他)手動輸入值或使用端口別名。
提示
要指定連續范圍的端口,請在“從”部分輸入較低的端口,在“到”部分輸入較高的端口值。
此框決定是否將符合此規則的數據包記錄到防火墻日志中。
在這里輸入描述以供參考。 這是可選的,不影響規則的功能。 最好的做法是輸入描述規則目的的文字。 最大長度是52個字符。
頁面的這一部分已經隱藏了不太可能被需要或者具有對新用戶混淆的功能的選項。 單擊顯示高級選項。 如果頁面的這一部分中的選項已經設置,則將來在加載規則時會出現。
pf和pfSense更獨特的功能之一就是能夠通過對連接的操作系統進行過濾。 對于TCP規則,pf啟用被動操作系統指紋(“p0f”),允許規則根據啟動TCP連接的操作系統進行匹配。 pf的pf功能通過將啟動TCP連接的TCP SYN數據包的特征與指紋文件進行比較來確定正在使用的操作系統。 請注意,可以將操作系統的指紋更改為另一個操作系統,尤其是對于開放源代碼操作系統,如BSD和Linux。 這并不容易,但是如果一個網絡包含技術熟練的用戶,并且具有對系統的管理員或根級訪問權限,那么這是可能的。
區分服務代碼點是應用程序在數據包內部指示如何在路徑沿著路徑轉發時更喜歡路由器來處理其流量的一種方式。這最常見的用途是服務質量或流量×××的目的。冗長的名稱通常縮寫為Diffserv Code Point或簡寫為DSCP,有時也稱為TOS字段。
生成數據包的程序或設備(例如Asterisk通過它的tos_sip和tos_audioconfiguration參數)將設置數據包中的DSCP字段,然后由防火墻和其他臨時路由器來匹配,排隊或作用于數據包。
要在防火墻中匹配這些參數,請使用與始發設備設置的值匹配的“區分服務代碼點”下拉條目。有很多選項,每個都有特定的通行類型的特殊含義。請查閱相關設備的文檔以獲取有關信息。
DSCP的缺點是它假定路由器支持或在現場采取行動,這可能是也可能不是。不同的路由器可能會以無意或不匹配的方式處理相同的DSCP值。更糟糕的是,有些路由器在轉發數據包時會完全清除數據包中的DSCP字段。此外,pf匹配流量的方式,必須在創建狀態的連接的第一個數據包上設置DSCP值,因為每個數據包在創建狀態后都不會被單獨檢查。
注意
該選項只讀取和匹配DSCP值。 它不會在數據包中設置值。
選中此框將允許具有定義的IP選項的數據包通過。 默認情況下,pf會阻止所有設置了IP選項的數據包,以阻止操作系統指紋等。 選中此框可傳遞包含IP選項的IGMP或其他多播通信。
防火墻在默認情況下將應答關鍵字添加到WAN類型接口上的規則,以確保進入WAN的流量也將通過同一個WAN離開。 在某些情況下,這種行為是不受歡迎的,例如某些流量通過WAN接口上的單獨防火墻/路由器進行路由時。 在這些情況下,請選中此選項以僅對符合此規則的流量禁用應答,而不是全局禁用應答。
Tag和Tagged字段與浮動規則一起使用非常有用,因此防火墻可以在進入接口時使用特定字符串標記數據包,然后使用浮動規則在匹配的數據包上執行不同的操作。
此選項限制此規則允許的最大連接數(總數)。 如果更多連接符合連接限制時的此規則,則此規則將在規則執行中跳過。 如果以后的規則匹配,則流量將應用該規則的操作,否則將觸發默認的拒絕規則。 一旦該規則允許的連接數量下降到低于此連接限制,流量可以再次匹配此規則。
此選項指定可為此規則同時連接多少個源IP地址。 每個源IP地址允許不限數量的連接,但允許的不同源IP地址的總數限制為該值。
要根據每個主機的連接限制訪問,請使用此設置。 該值可以將規則限制為每個源主機的特定連接數(例如10),而不是特定的全局連接總數。 該選項控制每個主機匹配規則的完全建立的(完成的握手)連接的數量。 此選項僅適用于TCP連接。
此設置與上述建立的計數類似,但僅檢查狀態條目,而不是跟蹤是否成功建立連接。
這種速率限制方法有助于確保較高的TCP連接速率不會使服務器或防火墻上的狀態表過載。 例如,可以限制傳入郵件服務器的連接,減少垃圾郵件過載的負擔。 它也可以用于出站流量規則來設置限制,防止任何單個機器加載防火墻上的狀態表或進行太多快速連接,這是病毒常見的行為。 可以為該規則配置連接數量和該時間段的秒數。 在給定的時間范圍內超過指定連接數的任何IP地址將被防火墻阻止一個小時。 此選項僅適用于TCP連接。
使用此字段,可以定義匹配此規則的流量的狀態超時,覆蓋默認狀態超時。 當連接閑置了這段時間時,任何不活動的連接都將被關閉。 默認狀態超時取決于正在使用的防火墻優化算法。
注意
此選項僅控制入站方向的流量,所以它本身并不是很有用。 匹配連接的出站流量仍將具有默認狀態超時。 要正確使用此設置,需要在具有類似狀態超時設置的流量占用的出站路徑中使用匹配的浮動規則。
默認情況下,TCP的新傳遞規則只檢查要設置的TCP SYN標識,不包括可能的SYN和ACK集合。 為了解決更復雜的情況,例如解決非對稱路由或其他非傳統的流量組合,請使用這組控件來更改標識與防火墻規則匹配的方式。
第一行控制哪些標識必須設置為匹配規則。 第二行定義將在數據包上查詢的標識列表以查找匹配。
最常用的標志的含義是:
SYN: | 同步序列號。 指示新的連接嘗試。 |
---|---|
ACK: | 指示數據的確認。 這些是應答,讓發件人知道數據收到OK。 |
FIN: | 表示發件人沒有更多的數據,關閉連接。 |
RST: | 連接重置。 這個標志響應在沒有監聽守護進程的端口上打開一個連接的請求時被設置。 也可以通過防火墻軟件來設置,以避免不良連接。 |
PSH: | 指示應通過將數據傳遞給應用程序來推送或刷新數據,包括數據包中的數據。 |
URG: | 表示緊急字段是重要的,并且該數據包應該在不緊急的數據之前被發送。 |
要允許設置了任何標志的TCP,請選中任何標志。
在pfSense中有三種狀態跟蹤選項,可以按規則指定:
Keep: | 選擇后,防火墻將創建并維護允許通信的狀態表條目。 這是默認的,在大多數情況下是最好的選擇。 |
---|---|
Sloppy State: | 這是使用一種不太嚴格的手段來保持狀態,用于非對稱路由的場景。 當防火墻只能看到連接的一半流量時,缺省狀態保持的有效性檢查將失敗,流量將被阻止。 防止某些類型***的pf機制在審查不嚴格的狀態時不起作用。 |
Synproxy: | 此選項會導致pfSense代理傳入的TCP連接。 TCP連接以三次握手開始。 TCP連接的第一個數據包是來自源的SYN,它從目的地引發SYN ACK響應,然后從源返回ACK以完成握手。正常情況下,防火墻后面的主機會自行處理,但是synproxy狀態會讓防火墻完成這個握手。這有助于防止一種類型的拒絕服務***,SYN泛濫。這通常僅用于WAN接口上的規則。目前這種***類型最好是在目標操作系統級別進行處理,因為每個現代操作系統都包含獨立處理這種***的能力。由于防火墻無法知道后端主機支持哪些TCP擴展,因此在使用synproxy狀態時,它將宣告不支持TCP擴展。這意味著使用synproxy狀態創建的連接不會使用窗口縮放,SACK,也不會使用大多數情況下會導致性能顯著下降的時間戳。將TCP端口打開到不能很好地處理網絡濫用的主機時非常有用,其中最重要的性能不是問題。 |
None: | 這個選項不會保持這個規則的狀態。 這只是在一些高度專業化的高級場景下才需要的,本書沒有涉及這些內容,因為它們非常罕見。 注意 在這里設置“None”只影響入站方向的流量,所以它本身并不是很有用,因為在出站方向上仍然會創建一個狀態。 它必須與出站方向上的浮動規則配對,該規則也具有相同的選項。 |
選中此框可防止此規則通過XMLRPC同步到其他高可用性集群成員。 這包含在高可用性中。 這不會阻止輔助節點上的規則被主節點覆蓋。
802.1p(也稱為IEEE P802.1p或優先級代碼點)是一種匹配和標記具有特定服務質量優先級的數據包的方法。 與DSCP不同,802.1p在第2層使用VLAN運行。 但是,與DSCP一樣,上游路由器也必須支持802.1p才能有用。
本節有兩個選項。 第一個將匹配一個802.1p字段,以便防火墻可以對其執行操作。 第二個將通過這個防火墻將一個802.1p標簽注入到一個數據包中。 某些ISP可能需要在某些地區(如法國)設置802.1p標記,以正確處理隔離VLAN上的語音/視頻/數據,以確保質量。
802.1p有8個優先級,每個在GUI中都有一個雙字母代碼。 從最低優先到最高順序是:
BK: | Background |
---|---|
BE: | Best Effort |
EE: | Excellent Effort |
CA: | Critical Applications |
VI: | Video |
VO: | Voice |
IC: | Internetwork Control |
NC: | Network Control |
此選項配置一個時間表,指定規則生效的日期和時間。 選擇“None”意味著規則將始終啟用。
此選項將配置網關或網關組以供符合此規則的流量使用, 這包括在策略路由中。
這些選擇列表定義了限制器對進入該接口(In)的流量應用帶寬限制并離開該接口(Out)。
這些選項定義將哪個ALTQ流量×××器隊列應用于進入和退出此接口的流量。
浮動規則是一種特殊類型的高級規則,可以執行復雜的操作,這些操作在接口或組選項卡上都不可行。 浮動規則可以在入站,出站或兩個方向上的多個接口上運行。 入站和出站過濾的使用使設計規則更加復雜,并容易出現用戶錯誤,但是在特定的應用程序中它們是可取的。
大多數防火墻配置永遠不會有浮動規則,或者只有流量×××器才具有浮動規則。
浮動規則比其他規則更強大,但也更混亂,更容易做出可能有短暫的或中斷連接的意外后果。
浮動規則,入方向,應用于多個廣域網,不會得到應答,因為他們也會在各個接口上添加規則,所以同樣的問題存在接口組這里:流量將始終與默認網關退出WAN ,而不是從輸入的WAN中正確地返回。
鑒于許多用戶對浮動規則相對陌生,在維護防火墻時,他們可能不認為需要查看規則。因此,他們可能會更難以管理,因為它可能不是在一個明顯的地方尋找規則。
根據入站和出站方向考慮數據包的來源和目的地時要小心。例如,WAN上出站方向的規則將具有防火墻的本地源(NAT之后)和遠程目標。
浮動規則最常見的用途是ALTQ流量×××。浮動選項卡規則是唯一可以匹配和排隊流量而不顯式傳遞流量的規則類型。
另一種使用浮動規則的方法是控制從防火墻本身流出的流量。浮動規則可以防止防火墻到達特定的IP地址,端口等。
其他常見用途是確保沒有流量可以從其他路徑退出到安全網絡,而不管其他接口上存在什么規則。通過阻止除了經批準的位置以外的所有安全網絡向外的安全網絡,通過一些其他不希望的路徑意外地允許通信的可能性減小。同樣,它們可以用來防止專用網絡的流量離開WAN接口,以防止×××流量泄漏。
正如前面在接口規則中提到的,它們還可以有效地為非對稱路由制定狀態超時,標記或匹配操作“no state” 規則和 “sloppy state” 規則。
在入站方向上,浮動規則基本上與接口或組規則相同,只不過它們首先被處理。 然而,在出站方向,事情會變得更加混亂。
防火墻規則是在NAT規則之后進行處理的,因此,如果在該接口上的出站NAT處于活動狀態,則WAN上出站方向的規則永遠不會匹配本地/專用IP地址源。 到達規則時,數據包的源地址現在是WAN接口的IP地址。 在大多數情況下,這可以通過使用匹配選項來標記局域網上的數據包,然后在防火墻出口處匹配該標記。
浮動規則在接口組規則和接口規則之前進行處理,因此也必須予以考慮。
匹配動作對于浮動規則是獨一無二的。 具有匹配動作的規則不會傳遞或阻止數據包,而只是為了將流量分配給隊列或限制器進行流量×××。 匹配規則在啟用快速的情況下無效。
快速控制當規則匹配時規則處理是否停止。 快速行為將自動添加到所有接口選項卡規則中,但在浮動規則上是可選的。 如果沒有快速檢查,則只有在沒有其他規則匹配流量的情況下,規則才會生效。 它把“第一場比賽勝利”的行為逆轉為“最后一場勝利”。
使用這種機制,可以制定一個默認的排序行為,只有在沒有其他規則匹配的情況下才能生效,類似于廣域網上的默認阻止規則。
在大多數情況下,我們建議有快速選擇。 有一些特定的情況下離開快速取消選中是必要的,但他們是少之又少。 對于大多數情況下,他們沒有快速選擇的唯一規則是匹配規則流量×××規則。
浮動規則的接口選擇與普通接口規則不同:它是一個多選框,因此可以選擇一個,多個或所有可能的接口。 按住Ctrl的同時單擊接口以逐個選擇它們,或者使用其他組合的單擊/拖動或按住Shift鍵單擊以選擇多個接口。
浮動規則不僅限于入口方向,如接口規則。 他們也可以通過在這里選擇,或在兩個方向選擇任何方向的行動出站方向。 方向也是可用的。
出方向對于過濾來自防火墻本身的流量,用于匹配嘗試退出接口的其他不合需要的流量,或者用于完全配置“sloppy state”規則,“no state”規則或者備用狀態超時是有用的。
使用“Tag 和 Tagged”字段,可以使用接口選項卡規則標記連接,然后在浮動規則的出站方向上進行匹配。 這是對來自特定內部主機的WAN出站通信采取行動的有效方法,否則,由于NAT屏蔽了源地址,因此無法進行匹配。 它也可以被類似地用于應用在到達防火墻的專門標記的流量上的×××出站。
例如,在LAN規則中,使用Tag字段中的短字符串來標記來自10.3.0.56源的數據包。 然后在浮動規則上,快速出站到廣域網上,使用Tagged為相同的字符串來處理由LAN規則匹配的流量。
部署額外的公共IP地址的方法取決于如何委派地址,分配的大小以及特定網絡環境的目標。 例如,要通過NAT使用其他公有IP地址,防火墻將需要虛擬IP地址。
直接為主機分配公共IP地址有兩種選擇:路由公共IP子網和橋接。
額外的公有IP地址可以通過直接在使用它們的系統上分配或使用NAT來使用。 可用的選項取決于ISP如何分配地址。
使用附加靜態公共IP地址的方法因分配類型而異。 這里描述了每種常見的情況。
對于WAN上的單個公共IP子網,其中一個公共IP地址將位于上游路由器上,通常屬于ISP,另一個IP地址將作為pfSense上的WAN IP地址。 其余的IP地址可以用于NAT,橋接或兩者的組合。
要在NAT中使用地址,請添加代理ARP,IP別名或CARP類型虛擬IP地址。
要將公共IP地址直接分配給防火墻后面的主機,必須將這些主機的專用接口橋接到WAN。 與橋接一起使用時,直接分配了公網IP地址的主機必須使用與防火墻廣域網(即上游ISP路由器)相同的默認網關。 如果具有公有IP地址的主機需要發起到防火墻其它接口后面的主機的連接,則會產生困難,因為ISP網關不會將內部子網的通信路由回防火墻。
下圖顯示了使用多個公用IP地址并結合使用NAT和橋接的示例。
一些ISP將分配一個小的IP子網作為“WAN端”分配,有時稱為傳輸或互連網絡,并將更大的“內部”子網路由到防火墻。通常這是在WAN側的一個/ 30和在防火墻內的一個/ 29或更大的子網。服務提供商路由器被分配/ 30的一端,通常是最低的IP地址,防火墻被分配較高的IP地址。然后提供程序將第二個子網路由到防火墻的WAN IP地址。額外的IP子網可以被路由的LAN或OPT接口上的防火墻使用,公網IP地址直接分配給主機,NAT使用其他類型的VIP,或者兩者的組合。由于IP地址被路由到防火墻,因此不需要ARP,因此VIP條目不需要用于NAT。
由于pfSense是本地網段上的網關,從公共本地子網主機到局域網的路由比使用單個公有IP子網時所需的橋接場景要容易得多。下圖使用兩個IP子網的多個公用IP地址顯示了一個將路由的IP子網和NAT組合在一起的示例。路由公共IP地址在路由公共IP地址和網絡地址轉換中包含NAT。
如果防火墻是使用CARP的高可用性群集的一部分,則WAN側子網將需要為/ 29,因此每個防火墻都有自己的WAN IP地址和CARP VIP。 提供商將在這種類型的配置中將較大的內部子網路由到WAN CARP VIP。 內部IP子網必須路由到一個始終可用的IP地址,而不管哪個防火墻已經啟動,并且可用于CARP的最小子網是/ 29。 CARP的這種設置與上述相同,OPT1網關是CARP VIP,而提供商路由到CARP VIP,而不是WAN IP地址。 CARP涵蓋了高可用性。
在其他情況下,一個站點可能被分配來自ISP的多個IP子網。通常當發生這種情況時,站點以前面描述的兩種安排之一開始,隨后在請求額外的IP地址時,該站點被提供了額外的IP子網。理想情況下,這個額外的子網將被ISP路由到防火墻,或者在單個防火墻的情況下被路由到WAN IP地址,或者在使用HA的時候被路由到CARP VIP。如果提供商拒絕將IP子網路由到防火墻,而是將其路由到其路由器,并使用子網中的一個IP地址作為網關IP地址,則防火墻將需要使用代理ARP VIP,IP別名VIP,或IP別名和CARP VIP的組合用于其他子網。如果可能的話,提供者應該將IP子網路由到防火墻,因為無論防火墻是否被使用,它都可以更容易地工作。它還消除了在附加子網中增加3個IP地址的需要,一個用于網絡和廣播地址,一個用于網關IP地址。通過路由子網,整個子網可與NAT組合使用。
在將IP子網路由到防火墻的情況下,具有較大LAN IP子網的小型廣域網IP子網中描述的場景適用于額外的內部子網。子網可以分配給一個新的OPT接口,與NAT一起使用,或者兩者結合使用。
一些ISP需要通過DHCP獲得額外的IP地址。 這不是獲取多個公網IP地址的好方法,必須避免在任何嚴重的網絡中使用。 業務級連接不應該要求這樣做。 pfSense是少數可以在任何容量下使用DHCP的附加IP地址的防火墻之一。 這提供了有限的靈活性
如果來自DHCP的附加IP地址必須直接分配給將要使用它們的系統,橋接是唯一的選擇。 這些系統使用與WAN橋接的OPT接口,并且系統必須配置為使用DHCP獲取其地址。
讓防火墻將這些DHCP地址作為租約提取的唯一選擇是偽多WAN部署。 每個公共IP地址安裝一個網絡接口,并為每個DHCP配置一個。 將所有接口插入防火墻與調制解調器或路由器之間的交換機。 由于防火墻將有多個接口共享同一個廣播域,因此在系統>高級設置,網絡設置頁面選擇“抑制ARP報文”,可以消除系統日志中的ARP告警,這種配置方式是正常的。
以這種方式分配的多個公有IP地址的唯一用途是用于端口轉發。 端口轉發可以在每個WAN接口上使用,由ISP DHCP服務器使用分配給該接口的IP地址。 出站NAT到OPT WAN將不起作用,因為每個WAN必須具有唯一的網關IP地址才能將流量正確地引導出該WAN。 這將在多個WAN連接中進一步討論。
pfSense允許通過虛擬IP(VIP)將多個IP地址與NAT或本地服務結合使用。
在pfSense中有四種類型的虛擬IP地址:IP別名,CARP,代理ARP和其他。 每個在不同的情況下都很有用。 在大多數情況下,pfSense將需要回答對VIP的ARP請求,這意味著必須使用IP別名,代理ARP或CARP。 在不需要ARP的情況下,例如當服務提供商將其他公共IP地址路由到防火墻上的WAN IP地址時,請使用其他類型的VIP。
無論防火墻規則配置如何,pfSense都不會響應代理ARP和其他類型VIP的ping。 使用代理ARP和其他VIP,NAT必須存在于防火墻上,將流量轉發到內部主機才能運行。
IP別名與接口上的任何其他IP地址一樣工作,例如實際的接口IP地址。他們將響應第2層(ARP),并可以用作防火墻上服務的綁定地址。它們也可以用來處理同一接口上的多個子網。 pfSense將響應IP別名上的ping,防火墻上綁定到所有接口的服務也將響應IP別名VIP,除非使用VIP將這些端口轉發到其他設備(例如1:1 NAT)。
IP別名VIP可以使用本地主機作為其接口,使用路由地址塊中的IP地址綁定服務,而無需專門將IP地址分配給接口。這對HA和CARP場景是非常有用的,這樣當子網只存在于防火墻內時(例如NAT或防火墻),IP地址不需要由CARP設置消耗(每個節點一個IP,其余則為CARP VIP)諸如×××之類的服務)。
IP別名本身不會同步到XMLRPC配置同步對等體,因為這會導致IP地址沖突。 IP 別名 VIP使用CARP VIP“接口”作為例外。那些不會導致沖突,所以他們會同步。另一個例外是綁定到本地主機的IP別名VIP作為其接口。因為這些在防火墻本身以外是不活躍的,所以不會有沖突的機會,所以它們也會同步。
代理ARP VIP功能嚴格在第2層,為指定的IP地址或IP地址的CIDR范圍提供ARP應答。 這允許pfSense接受針對共享子網內這些地址的流量。 例如,pfSense可以根據其NAT配置將流量發送到WAN子網內的其他地址。 地址或地址范圍未分配給pfSense上的任何接口,因為它們不需要。 這意味著pfSense本身沒有任何服務可以響應這些IP地址。
代理ARP VIP不會同步到XML-RPC配置同步對等點,因為這樣做會導致IP地址沖突。
CARP VIP主要用于利用CARP的高可用性冗余部署。 每個CARP VIP都有自己獨特的MAC地址,這些MAC地址來源于他們的VHID,即使在高可用性部署之外,這也是有用的。
參考
CARP VIP也可以用于單個防火墻。 這通常是在pfSense部署最終轉換為HA群集節點或具有唯一MAC地址的情況下完成的。 在極少數情況下,供應商要求廣域網段上的每個唯一IP地址具有不同的MAC地址,而CARP VIP則提供這些地址。
其他
其他類型的VIP定義了額外的IP地址,以便在ARP請求IP地址不需要時使用。 添加其他類型VIP的唯一功能是使該地址在NAT配置下拉選擇器中可用。 當防火墻具有路由到其WAN IP地址,IP別名或CARP VIP的公共IP模塊時,這很方便。
基于時間的規則允許防火墻規則在指定的日期和/或時間范圍內激活。 基于時間的規則與任何其他規則的功能相同,除非它們在計劃時間以外的規則集中不存在。
在處理基于時間的規則時,計劃會確定何時應用防火墻規則中指定的操作。 如果當前時間或日期未被計劃覆蓋,則防火墻的行為就好像規則不存在一樣。 例如,如果在其下面存在單獨的阻止規則,則在星期六通過流量的規則將僅在其他日期阻止。 規則從上到下進行處理,與其他防火墻規則相同。 使用第一個匹配項,一旦找到匹配項,如果規則在計劃中,則執行該操作,并且不執行其他規則。
提示
請記住,在使用時間表時,規則在預定時間以外無效。 由于當前時間不在預定時間內,因此規則將不會顛倒過來。 此行為可能會導致客戶在計劃中超出定義的時間范圍之外的意外訪問。
時間表必須先定義,然后才能用于防火墻規則。 時間表在防火墻>時間表下定義,每個時間表可以包含多個時間范圍。 在下面的例子中,一個公司想要在工作時間拒絕對HTTP的訪問,其他時間則可以正常訪問網絡。
添加時間表:
導航到防火墻 >時間計劃
單擊 調出時間表編輯頁面,如下圖添加時間范圍。
輸入一個時間表名稱。 這是出現在選擇列表中用于防火墻規則的名稱。 就像別名一樣,這個名字只能包含字母和數字,不能包含空格。 例如:BusinessHours
輸入此時間表的說明,例如 Normal Business Hours
定義一個或多個時間范圍:
通過選擇特定月份和日期來設置月份,或者通過單擊每周重復計劃的星期幾標題來設置月份。
選擇一個開始時間和停止時間,控制在選定日期內該規則處于活動狀態。 時間不能在任何一天過午夜。 一整天是0點到23點59分。
為此特定范圍輸入可選的時間范圍說明,例如 Work Week
單擊 添加時間以將選項添加為范圍
重復月份,時間, 添加另外的時間范圍
單擊保存
時間安排可以適用于特定日期,例如2016年9月2日,或周一至周三的某幾天。 要選擇下一年的任何一天,請從下拉列表中選擇月份,然后點擊日歷上的特定日期或日期編號。 要選擇星期幾,請在列標題中單擊其名稱。
對于這個例子,點擊星期一,星期二,星期三,星期四和星期五。 這將使計劃在任何周一到周五都有效,無論月份如何。 現在選擇時間表為24小時制。 這個例子的業務時間是9點到17點(下午5點)。 所有時間都以當地時區為準。
一旦定義了時間范圍,它將出現在時間表編輯頁面底部的列表中,如下圖所示。
為了擴大這個設置,星期六可能會有半天的時間來定義,或者商店周一晚些時候開放。 在這種情況下,請為相同的天數定義一個時間范圍,然后為每天的另一個范圍定義不同的時間范圍。 這個時間范圍的集合將是完整的時間表。
一旦時間表條目被保存,瀏覽器將返回到時間計劃列表,如下圖所示。 此時間表現在可用于防火墻規則。
要使用此時間表創建防火墻規則,請在所需的接口上創建新規則。對于此示例,添加一個規則,以拒絕局域網接口上的TCP通信從LAN子網到HTTP端口上的任何目標。 在規則的高級選項中,找到“時間計劃”設置,然后選擇“BusinessHours”計劃,如圖選擇防火墻規則的計劃。
保存規則后,日程安排將顯示在防火墻規則列表中,同時顯示日程安排的活動狀態。 如下圖所示,這是一個拒絕規則,調度列指示規則當前處于活動阻止狀態,因為它在排定范圍內的某個時間正在被查看。 如果鼠標光標懸停在日程安排狀態指示器上,則防火墻會顯示一個工具提示,顯示當前規則將如何運行。 由于這是在BusinessHours時間表中定義的時間內查看的,因此將會顯示“匹配此規則的流量正在被拒絕”。 如果在這個規則之后有一個通行規則將匹配從LAN網絡的端口80上的通信量,那么它將被允許在規定的時間之外。
現在規則已經定義,在計劃時間的內部和外部進行測試,以確保所需的管理行為已經生效。
提示
默認情況下,當時間表到期時,狀態將被清除,以進行預定規則允許的活動連接。 這將關閉規則允許的任何人在活動時的訪問權限。 要使這些連接保持打開狀態,請選中“系統”>“高級設置”>"附帶組件"下的“當時間計劃表到期時不要終止連接”。
防火墻為配置為記錄的每個規則以及默認拒絕規則創建日志條目。 有幾種方法可以查看這些日志條目,每個日志條目具有不同級別的細節。 沒有“最佳”方法,因為它取決于防火墻管理員的偏好和技能水平,盡管使用GUI是最簡單的方法。
提示
默認拒絕規則和其他內部規則的記錄行為可以使用系統狀態>系統日志下的設置標簽進行控制。
像pfSense中的其他日志一樣,防火墻日志只使用二進制循環日志格式clog保留一定數量的記錄。 如果組織的需求需要長時間記錄防火墻日志,請參閱系統日志章節以獲取有關將這些日志條目復制到系統日志服務器的信息。
防火墻日志在WebGUI的“系統狀態”>“系統日志”“防火墻”選項卡上顯示。日志可以被看作是一個解析日志,這更容易閱讀,或作為一個原始日志,其中包含更多的細節。 還有一個設置可以正向或反向顯示這些條目。 如果顯示的日志條目的順序未知,請檢查第一行和最后一行的時間戳,或者檢查更改日志設置以獲取有關如何查看和更改這些設置的信息。
解析后的WebGUI日志分為6個列:Action,Time,Interface,Source,Destination和Protocol。
Action: | 顯示產生日志條目的數據包(例如pass或block) |
---|---|
Time: | 數據包到達的時間。 |
Interface: | 數據包進入防火墻的地方。 |
Source: | 源IP地址和端口。 |
Destination: | 目標IP地址和端口。 |
Protocol: | 分組的協議,例如 ICMP,TCP,UDP等 |
Action圖標是一個鏈接,它將查找并顯示導致日志條目的規則。 通常情況下,這是“默認拒絕規則”,但是在排除規則問題時,可以幫助縮小嫌疑人的范圍。
提示
在“系統狀態”>“系統日志”下的“設置”選項卡上,可以將此規則說明配置為直接顯示在日志條目中。 防火墻可以在單獨的列或單獨的行中顯示說明。
源和目標IP地址旁邊是。 點擊此圖標后,防火墻將對IP地址執行DNS查找。 如果地址有一個有效的主機名,它將顯示在頁面上該地址的所有實例的IP地址下。
TCP數據包的日志條目將附加信息附加到顯示數據包中存在TCP標志的協議字段。 這些標志表示各種連接狀態或數據包屬性。 常見的標志包括:
S – SYN: | 同步序列號。 提示僅設置SYN時的新連接嘗試。 |
---|---|
A – ACK: | 提示數據的確認。 這些是答復,讓發件人知道數據收到OK。 |
F – FIN: | 表示發件人沒有更多的數據,關閉連接。 |
R – RST: | 連接重置。 這個標志在響應沒有監聽守護進程的端口上打開一個連接的請求時被設置。 也可以通過防火墻軟件來設置,以避免不良連接 |
從日志視圖添加防火墻規則(簡單規則)
簡單規則使得從防火墻日志視圖快速添加防火墻規則變得簡單。
源IP地址旁邊的圖標會在該接口上添加該IP地址的阻止規則。 更確切地說,它會創建或添加一個包含從Easy Rule添加的IP地址的別名,并在選定的接口上阻止它們。
目標IP地址旁邊的圖標與阻止操作類似,但會添加更精確的傳遞規則。 此通過規則允許接口上的流量,但它必須匹配相同的協議,源IP地址,目標IP地址和目標端口。
easyrule可用于從shell提示符添加防火墻規則。 當easyrule命令不帶參數運行時,會打印一條用法消息來解釋其語法。
它使用別名或指定協議,源和目標的精確傳遞規則添加阻止規則的方式與GUI版本類似。 例如,要添加阻止規則,請運行:
# easyrule block wan 1.2.3.4
通過規則必須更加精確:
# easyrule pass wan tcp 1.2.3.4 192.168.0.4 80
可以使用控制臺菜單中的選項10從filter.log文件實時查看和跟蹤原始日志。 一個簡單的例子就是如上圖所示的日志條目:從WebGUI中查看的示例日志條目:
Aug 3 08:59:02 master filterlog: 5,16777216,,1000000103,igb1,match,block,in,4,0x10,,128,0,0,none,17,udp,328,198.51.100.1,198.51.100.2,67,68,308
這顯示規則ID 1000000103被匹配,導致對igb1接口的阻止動作。 源和目標IP地址顯示在日志條目末尾附近,其后是源和目標端口。 來自其他協議的數據包可能會顯示更多的數據。
從SSH或從控制臺使用shell時,有許多選項可用于查看過濾器日志。
直接查看clog文件的內容時,日志條目可能相當復雜且冗長。
過濾日志包含在二進制循環日志中,因此傳統工具(如cat,grep等)不能直接在文件上使用。 日志必須與阻止程序一起讀回,然后可以通過另一個程序傳送。
要查看日志文件的全部內容,請運行以下命令:
# clog /var/log/filter.log
要限制日志輸出到最后幾行,通過尾部管道:
# clog /var/log/filter.log | tail
要“跟隨”日志文件的輸出,使用-f參數來阻止。 對于在UNIX系統上用于正常日志文件的用戶,這相當于tail -f:
# clog -f /var/log/filter.log
這將輸出日志文件的全部內容,但不會在之后退出。 它將等待更多的條目,并在發生時進行打印。 這個輸出也可以根據需要傳送給其他命令。
有一個用PHP編寫的簡單日志解析器,可以從shell中使用它來生成減少的輸出,而不是完整的原始日志。 要查看當前日志的解析內容,請運行:
# clog /var/log/filter.log | filterparser.php
日志條目每行輸出一個:
Aug 3 08:59:02 block igb1 UDP 198.51.100.1:67 198.51.100.2:68
查看其中一種原始日志格式時,顯示條目的ID號碼。 這個規則號可以用來找到引起匹配的規則。 在以下示例中,標識為1000000103的規則是:
# pfctl -vvsr | grep 1000000103 @5(1000000103) block drop in log inet all label "Default deny rule IPv4"
如上面的輸出所示,這是IPv4的默認拒絕規則。
有時日志條目存在,雖然標有“默認拒絕”規則,但看起來好像它們屬于合法連接。最常見的例子是看到一個涉及Web服務器的連接被阻止。
當連接的狀態被移除或者在可接受的窗口時間之外收到ACK時,通常關閉連接的TCP FIN數據包到達時,可能會發生這種情況。發生這種情況的原因是,有時數據包將丟失或延遲,因為防火墻已關閉連接,所以重新傳輸將被阻止。
這些日志條目是無害的,并不表示實際阻止的連接。所有有狀態的防火墻都這樣做,盡管有些日志消息不會為被阻止的流量生成日志消息,即使所有被阻止的流量都被記錄了。
即使所有防火墻接口上都存在“全部允許”樣式規則,此行為也會出現,因為TCP連接的規則設置為“全部允許”僅允許TCP SYN數據包創建狀態。所有其他的TCP流量將是狀態表中現有狀態的一部分,或者是具有欺騙性或其他無效的TCP標志的數據包。
當網絡上存在非對稱路由時,可以指出問題的一個特殊變化。在這些情況下,日志條目將顯示TCP:SA(SYN + ACK)數據包被阻止,而不是FIN或RST。
我們經常被問到的問題是“如何阻止對網站的訪問?”,或者更準確地說:“如何阻止訪問Facebook?”并不總是一個容易回答的問題。 有幾種可能的策略來完成這個目標,有些在本書的其他地方討論過。
如果內置的DNS解析器或轉發器處于活動狀態,則可以在該處輸入覆蓋,以將不需要的網站解析為無效的IP地址,如127.0.0.1。
如果網站很少更改IP地址,則可以使用包含其IP地址的別名來阻止訪問,然后在防火墻規則中使用此別名。對于返回低TTL的站點,這不是一個可行的解決方案,并且將負載分散到許多服務器或數據中心,例如Google和類似的非常大的站點。大多數中小型網站可以使用這種方法有效阻止,因為它們很少更改IP地址。
主機名也可以在網絡別名內。主機名將被定期解析并根據需要進行更新。這比手動查找IP地址更有效,但如果站點以快速變化的方式返回DNS記錄,或者在每個查詢的服務器池中出現隨機化結果(這對于大型站點來說都是常見的),那么這種方法仍然不足。
另一個選擇是找到所有網站的IP子網分配,為這些網絡創建一個別名,并阻止到這些目的地的流量。這對傳播大量IP空間的Facebook等網站特別有用,但被限制在幾個網絡塊中。使用ARIN等區域注冊網站可以幫助追蹤這些網絡。例如,在ARIN所覆蓋的地區,Facebook所使用的所有網絡都可以在http://whois.arin.net/rest/org/THEFA-3.html的“相關網絡”下找到。公司可能在不同地區有其他地址,所以請檢查其他地區網站,如RIPE,APNIC等。
作為手動查找IP塊的替代方法,通過在其中一個IP地址上執行whois查找來找到目標公司的BGP自治系統(AS)編號,然后使用它查找所有的分配。例如,Facebook的AS號碼是AS32934:
# whois -h whois.radb.net -- '-i origin AS32934' | awk '/^route:/ {print $2;}' | sort | uniq
將該命令的結果復制到一個新的別名中,它將覆蓋當前分配的所有網絡。 定期檢查結果是否有更新。
pfBlocker軟件包提供了在這方面很有用的機制,如DNSBL,地理IP地址阻止以及AS查找過程的自動化。
如果網絡流量通過代理服務器流動,那么該代理服務器很可能被用來阻止訪問這些網站。 例如,Squid有一個名為SquidGuard的插件,允許通過URL或其他類似的標準阻止網站。
使用上述任何一種方法,都有很多方法來解決定義的塊。 最容易和最普遍的是使用任何數量的代理網站。 查找和阻止所有這些單獨和保持最新的名單是不可能的。 確保這些網站無法訪問的最佳方法是使用能夠按類別阻止的外部代理或內容過濾。
為了進一步保持控制,請使用限制性出口規則集,并僅允許將流量發送到特定的服務或主機。 例如,只允許DNS訪問防火墻或專門用于LAN客戶端的DNS服務器。 此外,如果網絡上正在使用代理,請確保不允許通過防火墻直接訪問HTTP和HTTPS,并且只允許代理服務器或來自代理服務器的通信。
本節提供了有關解決防火墻規則問題的指導。
排除可疑阻止通信的第一步是檢查防火墻日志(系統狀態>系統日志“防火墻”選項卡)。
默認情況下,pfSense將記錄所有丟棄的流量,并不會記錄任何通過的流量。 除非不使用日志記錄的規則集中存在阻止或拒絕規則,否則所有阻止的流量都將被記錄。 如果防火墻日志中沒有與所討論的流量匹配的日志條目為紅色,則pfSense不太可能丟失流量。
嘗試連接并立即在系統診斷>狀態中檢查狀態表,并在源或目標上過濾以查看是否存在狀態。 如果存在狀態表項,則防火墻已通過流量。
如果所討論的規則是通過規則,則狀態表條目表示防火墻已經通過了通信,問題可能在其他地方,而不在防火墻上。
如果該規則是阻止規則并且存在狀態表項,則打開的連接將不會被切斷。 要從新的阻止規則中看到即時的效果,必須重置狀態。
編輯有問題的規則并查看每個字段的參數。 對于TCP和UDP通信,請記住源端口幾乎不會與目標端口相同,通常應該設置為any。
如果默認的拒絕規則是阻止,制定一個新的通行證規則,將匹配允許的流量。 如果流量仍然被阻止,則在規則配置中可能還有一些需要額外處理的特殊方面的數據包。 例如,某些多點傳送流量可能需要啟用“允許IP選項”,或者日志條目可能是由于非對稱路由導致的,或者數據包可能具有無效的參數組合,例如內部設置了“Do not Fragment”的分段數據包。
請記住,對于接口選項卡規則,第一個匹配的規則會勝出 - 不會對更多規則進行評估。
確保規則在正確的接口上按預期運行。 流量只能通過在啟動流量的接口上配置的規則集進行過濾。 從局域網上的系統發往任何其他接口上的系統的流量僅通過LAN規則進行過濾。 所有其他接口也是如此。
確定哪個規則與所討論的流量相匹配。 規則列表中的命中計數器可以在一定程度上幫助解決這個問題。 通過啟用通過規則登錄,防火墻日志將顯示一個單獨的條目,以確定哪個規則通過連接。
數據包捕獲對于故障排除和調試流量問題是非常寶貴的。 通過數據包捕獲,很容易判斷流量是否到達外部接口或離開內部接口以及許多其他用途。
如果新的規則似乎不適用,有幾個可能的解釋。
首先,如果規則是阻止規則,并且有一個狀態表項,打開的連接將不會被切斷。
其次,規則集可能無法正確重新加載。 檢查系統狀態>過濾器重新加載以查看是否顯示錯誤。 點擊頁面上的重置過濾按鈕來強制重新加載一個新的過濾器。 如果顯示錯誤,請根據需要解決問題。
如果上述原因都不能解決問題,則可能是規則不匹配,所以請重新檢查流量和規則。
防火墻規則,NAT,路由和網絡設計中還有其他一些缺陷可能會干擾連接。
上述內容就是pfSense book配置防火墻的規則是什么,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。