FreeBSD IPFILTER (IPF) 針對FTP的active mode及passive mode的設定方式

最近在開IPF讓ftp通過時，在passive mode 時吃了點虧，因此作個筆記記錄一下：

Active mode：

圖片的來源是：http://henrydu.com/blog/how-to/ftp-active-mode-vs-passive-mode-106.html

重點是在通訊過程中會使用到port這個指令，這個指令是由client往server發送的，它的目地是請server指派之後要用哪個port來傳資料。

Client 向 Server要求要使用 port：202*256+253 = 51965 port來傳資料

 

接著Server會用port 20往client 51965 port做3 way handshake

之後就開始傳資料 (server發起三向交握)

所以第一個session是client發起的，但第二個session是server發起的。

IPF的設定方式：

pass in log quick proto tcp from 126.1.65.11 to 126.1.60.91 port = 21 flags S keep state

pass in log quick proto tcp from 126.1.60.91 port = 20 to 126.1.65.11 flags S keep state

傳完之後再透過主通道看有沒有其它事要做，若還有其它檔要傳，會再起一個新的session，同樣由ftp server的tcp port 20發起。

實驗筆記：

1、 Windows 的 cmd的ftp只能用active mode來傳，就算你有下quote pasv或quote epsv也一樣。

2、有port指令的才是active mode

再來是passie mode:

圖片的來源是：http://henrydu.com/blog/how-to/ftp-active-mode-vs-passive-mode-106.html

client通知要用pasv mode之後， (之後FTP client用以傳輸的預設Port是原始port再加1)。接著server會回應他的port是：256*219+115=59179

接著做三向交握 (由client發起)

所以兩個session都是由client發起的，而且source 及destination port不同

第一個是any to 21，第二個是 > 1023 to > 1023

確認後就可以用這個通道傳資料，傳完後關閉，若要傳其它檔案再用主通道來溝通。

IPF的設定方式：

pass in log quick proto tcp from 126.1.65.11 to 126.1.60.91 port = 21 flags S keep state

pass in log quick proto tcp from 126.1.65.11 port >1023 to 126.1.60.91 port > 1023flags S keep state

( or pass in log quick proto tcp from 126.1.65.11 to 126.1.60.91 flags S keep state)

MPLS VPN (MP-BGP)客戶收到routing時的優先順序

 BPG選路徑有它的演算法，https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
或者參考這一篇：
https://supportforums.cisco.com/t5/network-infrastructure-documents/understanding-bgp-best-path-selection-manipulation/ta-p/3150576

我們遇到有趣的問題，就是如果一個客戶在IMPORT不同的route target時，都有一樣的網段，那要怎麼選？試了一下，是第10個規則，routing age。

When both paths are external, prefer the path that was received first (the oldest one).
但是這邊寫說是選最舊的 (因為它最穩定)，但實做起來確實是選擇最新的，也許IOS版本也有差異吧。

簡單驗證一下，在clear ip route vrf F9412016 * 之前，best path是 從F9999999 import進來的。
 

接著clear ip route vrf F9412016 *，之後best path就變成了往F9412016送。

測出來的結果竟然與思科官網相反...是最新的才是best。
我不能接受，所以又做了下面這個lab (本來的架構沒有辦法調整route age)
R1跟R2建mpbpg，然後r2與r3,r2與r5，r2與r4都跑rip。然後r2有三個vrf，收到三筆default route。

結果測試的結果還是一樣。只要我清哪一個vrf的routing，等他收斂之後，R1就會把它視為best path。

無解，先做個記錄也許過幾年再看看吧。

FreeBSD IPF 針對Remote shell (RSH) 的規則設定

這個問題研究了兩天，稍微有點心得。記錄一下。

Remote shell是很有趣的協定，在IPF的開法跟一般的協定不同。
Remote shell會有兩個流程。第一段是三向交握的階段 ，第二段才是正確的身份驗證和下達指令的部份。

 在我測試的架構中，10.100.33.15是rsh的client，而10.100.33.16是rsh的server。

其實ipf這樣開就好了：
pass in quick proto tcp from 10.100.33.15 to 10.100.33.16 port = 514 flags S keep state
pass in log quick proto tcp from 10.100.33.15 port 511 >< 1024 to 10.100.33.16 port 511 >< 1024 flags AS keep state

下面是驗證的結果：你可以看到10.100.33.15會使用512至1023的port去跟server發起連線 (目的port似乎也是512~1023 port)。但這個session並不包含在一開始發起rsh的session中，因此要另起規則放行。(視為不同的session來處理)
27/09/2017 22:02:37.002734 fxp0 @0:4 p 10.100.33.15,772 -> 10.100.33.16,997 PR tcp len 20 64 -AS K-S IN
27/09/2017 22:02:37.002756 fxp0 @0:4 p 10.100.33.16,997 -> 10.100.33.15,772 PR tcp len 20 52 -A K-S OUT
27/09/2017 22:02:37.116048 fxp0 @0:4 p 10.100.33.15,772 -> 10.100.33.16,997 PR tcp len 20 52 -A K-S IN
27/09/2017 22:02:37.116529 fxp0 @0:4 p 10.100.33.15,772 -> 10.100.33.16,997 PR tcp len 20 52 -AF K-S IN
27/09/2017 22:02:37.116538 fxp0 @0:4 p 10.100.33.16,997 -> 10.100.33.15,772 PR tcp len 20 52 -A K-S OUT

但Remote shell很有趣，因為第二個階段用的TCP flag並不是S，所以ipf如果要放行的時候，用預設的S是不會通的。要用的是AS (我用紅包強調)。或者你也可以不做TCP flag的檢查，只保留keep state就好了。

至於為何客戶的規則只開flags S還能通呢，因為他們最後有補一個flags A/A的規則
pass in quick proto tcp from 10.100.33.15 to 10.100.33.16 port = 514 flags S keep state
pass in log quick proto tcp from 10.100.33.15 port 511 >< 1024 to 10.100.33.16 port 511 >< 1024 flags S keep state
pass in log quick proto tcp from any to any flags A/A

至於其它沒有設定 pass in log quick proto tcp from any to any flags A/A
的設備是怎麼通過的呢？

原因是他們有設定另一條policy：
pass out quick proto tcp from 10.100.33.16 to any flags S keep state
這個作法就是把10.100.33.16發起的session視為獨立的另一條session
所以你去錄封包，會看到它長這樣：
29/09/2017 18:27:33.369510 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 64 -S K-S OUT
29/09/2017 18:27:33.369676 fxp0 @0:1 p 10.100.33.15,721 -> 10.100.33.16,967 PR tcp len 20 64 -AS K-S IN
29/09/2017 18:27:33.369695 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 52 -A K-S OUT
29/09/2017 18:27:33.482540 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 52 -AF K-S OUT
29/09/2017 18:27:33.482817 fxp0 @0:1 p 10.100.33.15,721 -> 10.100.33.16,967 PR tcp len 20 52 -A K-S IN
29/09/2017 18:27:33.483126 fxp0 @0:1 p 10.100.33.15,721 -> 10.100.33.16,967 PR tcp len 20 52 -AF K-S IN
29/09/2017 18:27:33.483133 fxp0 @0:1 p 10.100.33.16,967 -> 10.100.33.15,721 PR tcp len 20 52 -A K-S OUT

第一條符合TCP-SYN，所以後面就都過了。

這兩者好像有點衝突對吧？究竟第二條session中，是client先發起還是server先發起？為何兩種開法都會通？

我們再回頭看一下完整的封包：

第八條是client發起的A，就是一開始講的any to any flags A/A，所以它會通 (並不是一開始的那一條any to 514喔，那一條是S)

第九條是server發起的S，就是剛剛講的的10.100.33.16 to any flags S keep state，所以它也會通。

至於為何同一客戶的兩台機器有不同的開法，推想是兩台設備是不同時期或不同人維護的，所以解決問題的辦法有所不同。

xargs的取代字串功能

最近發現xargs有一個很好用的取代功能。

ls | grep firewall.backup | tail -1 | xargs -iz scp z root@firewallbk:./firewall/

這是一個簡單的程式，取出最新的檔案，然後把它用scp複製到遠端。
重點是xargs：-i指的是replace後面的字串，z是指取代後的名稱。

簡單來說，就是把前面ls取出的檔名取代為z (算是一個代號吧)，後面的scp z做的其實是
scp 該檔名

VTUR Zyxel P874 從遠端無法PING到的解決方法

針對VTUR Zyxel P874 從遠端無法PING到的問題，剛好又遇到同事報修就順便再整個把流程跑一次：

1、由於P874還是有版本的差異，因此這個說明是針對20140730版的。

2、如何RESET機器：之前的機器印象中都是壓住reset 5至10秒，等power燈閃爍就可以reset，但我遇到的這一台竟然是要壓住reset再送電...不曉得是個案還是版本差異還是我記錯。

3、在WAN介面設定固定IP (請參考小弟的其它介紹 http://tiserle.blogspot.tw/2017/08/vtur-zyxel-p874-wanip.html )，如果在DNS部份若不填入則會有以下的錯誤訊息：(我猜想是因為我之前都有輸入，所以其實一直都需要輸入，只是我沒有注意到)
這個問題真的很鳥，但遇到了就是要解決，請隨意填入IP即可 (建議還是依各大ISP來輸入，但記得兩組都要輸入，不能只輸入一組喔。

4、設定Security：設定完WAN IP之後，我是建議把security的level改為low，不管你點Security或點Security General Firewall都是連到一樣的地方。

5、在BRAS上測試能否PING到VTUR的WAN IP，理論上是不行的，因此要重開機讓設定生效。重開之後確認BRAS端可以PING到WAN IP就可以重新設定LAN IP。但重開之後某公司的網管還是PING不到這一款VTUR，因此我們要再回頭找ACL (access control limit)的相關設定：
在這個版本，他被移到了Access Control裡面的IP Address，不過預設就是Disable。

6、20200323補充說明，我補上Service的ACL設定供參考，這個圖是從P880抓下來的，理論上相差不多。設定時先點選Management，再點選Access Control或者點選Access Control裡面的Service，我們需要的是開放WAN ICMP，因此我們點選Enable，再點選Save/Apply.

7、新增靜態路由：真的沒有辦法，只好手動加入靜態路由試試。在靜態路由表中新增某公司的監控網段：

這個圖是後來抓的，但在測試時我只有選擇Interface並輸入172.32.96.33的對口IP，但我並沒有打勾User Gateway IP Address這個選項，但重開機後 (我設定完LAN IP後有重開)，竟然自己打勾了。不過一般來說就是要打勾的，我原先只是刻意作測試。之後遠端監控也就正常了，為了避免客戶斷太久，也不好意思再作其它的測試了

結語：老實說這台設備怪怪的，裡面的設定也一堆沒有清乾淨的。建議也可以用VTUR本身的功能將設定清除再來做其它的設定。

中華電信 VTUR Zyxel P874 WAN設定為固定IP設定方式

我們這一次要示範如何在Zyxel P874上面設定固定IP：

一、選擇Advanced Setup 再選擇 WAN，接著點選Add，新增一組設定。

二、接著要選擇Layer 2的模式，也沒有什麼可以選的，選擇Next前進下一步。

三、接著是關鍵，要選擇WAN的連線模式，請從預設的PPPoE，改為IPoE，接著點選Next。

四、接著就可以填入固定IP的相關設定了，基本上這些資訊ISP公司應該老早就提供給您了。設定完成後點選Next。

五、接著確認一下設定值，Enable NAT預設就有打勾，請維持。Firewall的部份就自行決定吧，預設是沒有打勾的。其餘就保持預設值即可，接著點選Next。

 六、最後要確定Default Gateway為何，由於我只有一個設定值，就維持即可。若有其它的設定 (例如 PPPoE)，請自行更正，其名稱應與第五步驟一致，在此例為ipoe_0_0_1_3。接著點選Next。

 七、最後會把所有設定值都列出來給你看，若確定都正常就可以點選儲存。

八、最後還是要重開一下VTUR，讓新的設定生效。我們點選Save/Reboot。

rrdtool fetch max 與 繪圖不符...

root@solaris:/var/www/OM/rrd# rrdtool fetch 139.175.240.142_port_ethernet_14_2.rrd MAX -r 86400 -s -18h -e -14h
                     traffic_in         traffic_out

1501718400: 2.0671411616e+07 8.4111154469e+07

算出來大概是642Mbps，但繪圖出來卻是550Mbps...

用fetch average來讀值再排序，最大的也還是8.4111154469e+07，

root@solaris:/var/www/OM/rrd# rrdtool fetch 139.175.240.142_port_ethernet_14_2.rrd AVERAGE  -r 300 -s -25h -e -13h | awk '{print $3}' | sort | tail -n 1

8.4111154469e+07

看來真的要好好study一下了。

接著我們再同意的時間取值，取出前一天20:00~23:59的值，
rrdtool fetch 139.175.240.142_port_ethernet_14_2.rrd AVERAGE  -r 300 -s $start =e $end  | awk '{print $3}' | sort | tail -n 3
6.8785461058e+07
9.9885483539e+06

確實最大值的確是550Mbps。

我們接著再畫一張全日的圖：

發現的確瞬間有爆表，所以我們回頭查RRD檔的上限值是多少

root@solaris:/var/www/OM/rrd# rrdtool dump 139.175.240.142_port_ethernet_14_2.rrd | grep max

                1.0000000000e+10

                1.0000000000e+10

看起來還沒有爆表...，從ifspeed來看的話，其速度為1000000000 (1.00e+9)

IF-MIB::ifSpeed.1 = Gauge32: 1000000000

但我也還不能確定原因，說不定是設備吐出來的值就有問題。

先把max改為1.00e+9試試吧。

作了很多測試，我只記錄最後找到的問題點。
一開始的設計，在update  rrd檔時，用的是程式開始時的timestamp，但其實BRAS有時回應時間會很長，假設多拖了30秒才回資料，但計算時是用300秒來算，因此其實資料量已經不是300秒的資料了。等於說用300秒來算330秒的資料，這樣當然是不準確。因此我最後改為N，用update rrd檔時的時間來做為計算的依據。目前看起來正常，再觀察幾天吧。