rpcbindはポート873 UDPを開いたが、rpcinfo -pはそのポートにバインドされたプログラムを表示しません。

私たちの環境のいくつかのLinuxサーバーでlsof -i出力を見て、rpcbindはTCPプロトコルとUDPプロトコルで一般的に使用されているポート111を開きましたが、明らかな理由なくポート873 UDPも開いたことがわかりました。これは、ポート873がrsyncdに割り当てられており、ポリシーによってはrsyncがsshトランスポートを使用する必要があるため、セキュリティフラグが発生します（rsyncdは暗号化を実行せず、信頼関係を介してのみ認証します）。

通常、RPCプロセスが疑われる場合は、どのサービスが実際にポートを開いているかを確認するためにrpcinfo -pを見てください。ただし、これらのサーバーではportmapperのポート111のみが表示され、statusおよびnlockmgrの番号は高いポートのみが表示されますが、ポート873は表示されません。

私は多くのバグレポートを見ました（RHELを含む：https://bugzilla.redhat.com/show_bug.cgi?id=103401そしてカーネル：https://patchwork.kernel.org/patch/10153769/）犯人はglibcのfindresvport（）関数だと言いますが、途方もない混乱を引き起こさずにその関数を変更する方法はありません。 3つの異なる解決策があります。

• RHEL は、rpcbind が起動する前にこれらのポートを事前に割り当てる portreserve というデーモンを提供します。これにより、セキュリティ上の理由から不要なポートが開いていることが保証されるため、役に立ちません。
• Debian とその子孫は /etc/bindresvport.blacklist に設定ファイルを実装します。これは、文書化されていないように見え、ディストリビューションによって踏み込みやすいことを除いて、私たちの目的に最適です。
• ディストリビューションの nfs-utils パッケージのアップストリームは /etc/services に従い、登録済みポートにバインドされません。

しかし、私が確認したいのは、最初にrpcbindが追加のポートを開く理由です。これまでに確認した内容によれば、ポートが起動時にランダムに割り当てられ、サーバーを再起動すると他のポートにプッシュされるとマークされますが、それを行う方法ではありません。