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() 함수라고 말하지만 엄청난 혼란을 일으키지 않고는 해당 함수를 변경할 수 있는 방법이 없습니다. 세 가지 다른 솔루션이 있습니다.

• RHEL은 rpcbind가 시작되기 전에 이러한 포트를 사전 할당하는 portreserve라는 데몬을 제공합니다. 이는 보안상의 이유로 원하지 않는 포트가 열려 있음을 보장하므로 도움이 되지 않습니다.
• 데비안과 그 후손은 /etc/bindresvport.blacklist에 구성 파일을 구현합니다. 이는 문서화되지 않은 것처럼 보이고 배포판에 의해 밟히기 쉽다는 점을 제외하면 우리의 목적에 이상적입니다.
• 배포판의 nfs-utils 패키지 업스트림은 /etc/services를 따르며 등록된 포트에 바인딩되지 않습니다.

하지만 내가 확인하고 싶은 것은 rpcbind가 처음에 추가 포트를 여는 이유는 무엇이며, 이러한 일이 발생하지 않도록 하려면 어떻게 해야 합니까? 지금까지 확인한 모든 내용에 따르면 포트가 시작 시 무작위로 할당되고 서버를 다시 시작하면 다른 포트로 푸시되는 것으로 표시되지만 그렇게 하는 방법은 아닙니다.