rpcbind 正在打開埠 873 UDP 但 rpcinfo -p 顯示沒有程序綁定到該埠
我正在查看我們環境中幾台 Linux 伺服器上的 lsof -i 輸出，發現 rpcbind 在 TCP 和 UDP 協議中打開了常用的埠 111，但也無緣無故地打開了埠 873 UDP。這引發了安全標誌，因為埠 873 已分配給 rsyncd，並且我們的策略要求 rsync 使用 ssh 傳輸（rsyncd 不執行加密，並且僅通過信任關係進行身份驗證）。
通常當我懷疑某個 RPC 程序時，我會在 rpcinfo -p 中查找它以查看實際上是哪個服務打開了埠。但是，在這些伺服器上，我只看到埠映射器的埠 111 和狀態和 nlockmgr 的高編號埠，埠 873 無處可見。
我已經看到了很多錯誤報告（包括 RHEL：https ://bugzilla.redhat.com/show_bug.cgi?id=103401和核心：https ://patchwork.kernel.org/patch/10153769/ ）說罪魁禍首是glibc中的bindresvport（）函式，但是如果沒有大量損壞，就無法在那裡更改該函式。我已經看到了三種不同的解決方案：
- RHEL 提供了一個名為 portreserve 的守護程序，用於在 rpcbind 啟動之前預先分配這些埠。這對我沒有幫助，因為它保證這些埠是開放的，出於安全原因，我們不希望這樣做。
- Debian 及其後代在 /etc/bindresvport.blacklist 中實現了一個配置文件，這對於我們的目的來說是理想的，除了它似乎沒有記錄並且容易被發行版踩到。
- 發行版上游的 nfs-utils 包支持 /etc/services 並且不綁定到註冊埠。
不過，我試圖確定的是，為什麼 rpcbind 首先要打開額外的埠，以及如何防止它？到目前為止，我檢查的所有似乎都表明該埠是在引導時隨機分配的，並且重新啟動伺服器已顯示將其推送到不同的埠，但這是無法操作的。
實際上，只有 Debian 9 或 RHEL 7 之前的版本存在此問題，而不是 Debian 10 或 RHEL 8。導致隨機特權 UDP 埠綁定的功能已在 rpcbind 1.2.5 中被禁用，該版本在 0.2.3 和 0.2 之後發布。 4.
從 Debian 10.1+ 開始
/usr/share/doc/rpcbind/README.Debian：從 1.2.5 版開始，出於安全考慮，上游預設關閉了遠端呼叫功能，並在建構時添加了一個配置標誌來啟用它。
此功能導致 rpcbind 打開隨機偵聽埠。關閉遠端呼叫後，rpcbind 停止接收任何廣播查詢，這會導致系統損壞，具體取決於此功能，例如 NIS 系統。
在 Debian 系統上，遠端呼叫可以在執行時使用命令行參數 ‘r’ 打開。有關詳細資訊，請參閱 rpcbind(8)。
我可以在 Debian 9 上驗證（強制）升級
rpcbind到 Debian 10 的版本足以失去額外的特權綁定埠。使用Debian 更新檔提供的新的 Debian 特定-r選項（主要是重新編譯並添加執行時選項）“恢復”該功能，但綁定的 UDP 埠似乎不再具有特權。--enable-rmtcalls此遠端呼叫功能的使用是與
rpcinfo -b（或Kodi）一起向所有 LAN 的埠映射器發送廣播查詢。例如發現RPC prognum 100005 版本 3（對於 NFSv3 的mountd）：rpcinfo -b 100005 3這將向埠 111/UDP 發送廣播，並且回复埠映射器將使用額外綁定的 UDP 埠作為源（在類似於TFTP的典型防火牆不友好方法中）。沒有這個埠，他們不會回答，但仍然可以像往常一樣直接從埠 111/UDP 回答直接單播查詢。