Rpcbind Listening on a Non-Standard Port

Hello,

I was trying to find information about below rpcbind issue and how can I fix it so that, it wont happen again.

Below is the one of the vulnerability from my security team,

RPC
service name: portmapper
service protocal: udp
Portmapper found at: 327xx
service port: 327xx

Vulnerability ID: rpc-portmapper-0001
vulnerability title: Rpcbind Listening on a Non-Standard Port


 Vulnerability Description: 

 The rpcbind program converts RPC program numbers into universal addresses.
 When a client makes an RPC call to a given program number, it first connects to rpcbind on the target system to determine the address where the RPC request should be sent. Rpcbind has been detected listening on a non-standard port (above 32770) instead of the standard TCP / UDP port 111. 

 This configuration flaw has been confirmed on some operating systems such as Solaris 2.x. The exact high port number rpcbind listens on is dependent on the OS release and architecture. Thus, packet filtering devices that are configured to block access to rpcbind / portmapper, may be subverted by sending UDP requests to rpcbind listening above port 32770. This vulnerability may allow an unauthorized user to obtain remote RPC information from a remote system even if port 111 is being blocked.
 
 
 
Solution:
========
 
Fix Solaris rpcbind filter evasion
Download and apply the patch from:  http://ftp.porcupine.org/pub/security/ 


 For Solaris, the newest version of Weitse Venema's Rpcbind replacement can be found at  Wietse Venema's web site (http://ftp.porcupine.org/pub/security/) 
 ( http://ftp.porcupine.org/pub/security/ ) . 
 Patches are available to all Sun customers at the  SunSolve web site (http://sunsolve.sun.com)  ( http://sunsolve.sun.com ) . 
 Other than these patches, firewall best practices and "default deny" rules can help protect against attacks targeting rpcbind.

This is what I can see from lpar

[root@testlpar]/tmp>lsof -i :111 | grep LISTEN
portmap 7995500 root    3u  IPv6 0xf1000e0000045455b      0t0  TCP *:sunrpc (LISTEN)

 
[root@testlpar]/tmp>lsof -i :327xx | grep LISTEN


user1@testlpar]/home/user1>rpcinfo  -p
   program vers proto   port  service
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper

From above information,we can see that portmapper is listening on port "111" not non-standard port "327xx".

oslevel is "7100-03-01-1341"

I'm not sure how did they found the above vulnerability in scanning. Can you please help me understand the cause of the issue and how can we avoid this in future.

Thanks for your time.

OK.

Gladly so: fire your security team for proven incompetence.

First: there is a - very small, but subtle - difference between IPv6 and IPv4. It might be hard to grasp for a security person, but let me assure you: there is.

Second: there is a similar subtle and small difference between SunOS and AIX.

Third: this "filter evasion" is horse manure. A firewall worth its name will look at any ports, not just specific ones, anyway. The difference between ""well-known services" (ports below 1024) and other ports is that you have to be root to open a WKS port. There is nothing specifically problematic by using other ports at all. So, even if assuming their observation would have been correct - which it wasn't, see below - there would be no "security problem" per se, at best the problem of a bad (or badly configured) firewall. Inside a non-firewalled network it is completely bogus.

Fourth: your rpcbind process listens on exactly the right port: 111, as you have shown beyond doubt.

Fifth: you might have a real problem, which is less security-related then robustness-related. You (seem to) use UDP, which lacks - contrary to TCP - flow control. In the back the upside of this (slightly more throughput) was very significant because networks had limited bandwidth (i talk about classic 10Mbit ethernet here) but since bandwidth is almost as high as you want it to be the downside - missing flow control - in recent years outweighs this by far, which is why the most common reason to use remote procedure calls at all - NFS - turned to use TCP by default (UDP optional) in NFSv3 and TCP-only (NFSv4).

If you do not use NFS (or r-commands, but then you'd have bigger problems than strange port numbers) you might probably as well disable rpcbind altogether because the system might not use it anyways. (This you will have to check with your real system, it is just conjecture.)

I hope this helps.

bakunin

PS: you might update to the latest TL (6) from your TL-1-system, which would do a lot to enhance some problematic parts. It would do more for your security than tampering with rpcbind

there is at least one well known in enterprise world software, which has afair its own RPC implementation. and agents of this s.....oftware on AIX like using ports like 32xxx for RPC server. but it seems, that you don't have it.

that's why: