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，所以它也會通。

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