NFS: Static Port for rpc.mountd

[Enno Baars]

Hello!

Is there a way to make the rpc.mountd bind to a predefined port under HP-UX 10.20?

I know, the philosophy of RPC is the opposite, using the portmapper for port inquiries.
But filtering NFS on a firewall is virtually impossible without a predefined port for mountd.
I know other OS can do this - usually the option is "-P ". Is something like this possible with HP-UX 10.20?
Any information is appreciated!

Cheers,
Enno

[Sridhar Bhaskarla]

Enno,

It is possible. Edit /etc/rc.config.d/nfsconf
and change the MOUNTD_OPTIONS to look like

MOUNT_OPTIONS="-p port#"

Restart nfs.server from /sbin/init.d

-Sri

[Enno Baars]

Hello Sridhar!

Thanx for the information, but...
Are you sure this works on 10.20?

Even though specifying this option gives no error when starting nfs.server, the port for mountd is still some random number (as advertised by portmapper).
With each restart the portnumber changes, but it's not what I specified. :-(

ps shows that the process rpc.mountd is runnig with the option though.

Am I missing something?

Confused,
Enno

[A. Clay Stephenson]

Hi,

The -p option takes no arguments; it simply allows mountd to use unreserved ports.

[Anthony deRito]

There are many know exploits against a large list of services that the portmapper provides access to. All RPC services register themselves at port 111 (the "portmapper" or rpcbind for the Solaris guys). The calling client will have to access port 111 to query and identify ports where the needed service is running and ultimately connect to the service. This can be done with both TCP and UDP.

So the point is that port 111 is a place to find out where services are running. Many vulnerabilities exist with this port. For example, NFS has a known rpc-update exploit. Also, the NIS update daemon, rpc.ypupdated, contains vulnerabilities in how it passes commands to certain function calls.

Filter TCP port 111, UDP port 111 (portmapper), TCP port 2049, and UDP port 2049 (nfsd). If you run NFS on a port other than 2049, determine which port is running NFS by entering the following command on the machine in question: rpcinfo ?p

Hope this helps.

Tony

[Anthony deRito]

Your question may be a result of CERT CA-1994-02 advisory warning but in case you did not see it here is the URL:

http://www.cert.org/advisories/CA-1994-02.html

Tony

[Enno Baars]

Hi Tony!

Thanx for the information!

I'm well aware of the dangers connected to RPC services - that's one of the reasons why I installed the firewall in the first place... :-)

Now what I'm trying to do is quite the opposite:
My firewall has the default policy of blocking everyting. I just allow certain services from/to certain hosts.
One of those services is an NFS connection from an outside NFS client (which I trust, of course) to my NFS server. So I need to allow connections from that specific client to three ports on my server:

portmapper - Port 111
nfsd - Port 2049
mountd - Port ???? (not static, changes at every nfs.server restart)
Without a static Port for mountd I would have to allow connections to any port on my server as mountd might be listening on any one of them - inacceptable!

Hence the question: How can I tell mountd to bind to the same predefined port every time it starts?

Cheers,
Enno

[Anthony deRito]

Enno,

My intent was to provide as much information to anyone who is following this thread? did not mean to under-estimate your level of knowledge in these issues. I think with security, we all have a lot to learn so I try to provide as much information as possible.

Speaking of learning, I learned today that certain operating systems, including HP-UX, make rpc information available at other undocumented ports. I?ve learned that there is use of an undocumented port for rpcbind under Solaris 2.X operating systems. It seems as though on Solaris 2.x, rpcbind listens not only on TCP port 111, and UDP port 111, but also on a port a port greater that 32770!! Instead of sending requests to TCP or UDP port 111, the attacker simply sends them to a UDP port greater than 32770 on which rpcbind is listening and presto? they?re in. This would lead to a huge number of packet filters which would intend to block access to rpcbind/portmapper in order to be effective. Sun has a patch to address this issue. Maybe HP also has addressed this issue... it would be worth looking into. I am not able to provide you with information on forcing RPC to use specific ports consistently.

Good luck ?

Tony

[Kevin Sorohan]

Enno

did you ever fidn a way to do this?

I too would like to assign a static port to nfs rpc services so i can use a firewall between the my nfs servers network and my nfs clients network.

If you founmd a way to do this could you let me know?

Thanks

Kevin

[Dave Olker]

Hello Enno,

No, there is no way to get rpc.mountd to start on the same port every time it comes up. On HP-UX 10.20, the daemon is coded to select an available port in the reserved range (1-1024) by default.

Also, the -p option is incorrectly documented in the man page for mountd on 10.20. The -p option does not allow rpc.mountd to register on ports in the non-reserved range. What -p does is it allows rpc.mountd to *accept requests* that arrive on non-reserved ports. In other words, without the -p option, mountd will only listen to MOUNT/UNMOUNT etc. requests that arrive on ports in the range 1-1024. The thinking is that you must be a root user to use a port in this range, so mountd is using the port range as a type of security check. Launching rpc.mountd with the -p option tells mountd to disable this check and accept requests regardless of which port number they arrive on.

On newer releases of HP-UX (i.e. 11.0 and newer), the rpc.mountd daemon obtains an available port in the non-reserved range (48K-64K).

Even on the latest HP-UX releases, there is no way to "fix" rpc.mountd (or rpc.lockd, rpc.statd) to a specific port number. These daemons always ask for an available port number in the anonymous range.

This is one of the improvments NFS V4 will offer, where all requests - NFS, MOUNT, LOCK, etc. - will be sent to the nfsd port 2049, so configuring V4 for firewall access will be simple compared to today's implementation.

Regards,

Dave