why does nfsv4 client open an extra port ? how to close it if it is actually useless ?

why does nfsv4 client open an extra port ? how to close it if it is actually useless ?

hello, all

i'm working with an ubuntu ( xenial ) bunch of servers and need to understand why mounting an nfs v4 share opens a random port on the client side. the port has no associated process and seems to be directly open by the nfs kernel module. the port is closed if i unmount and a different one is opened if i remount the share. no traffic ever hits that port neither when mounting nor afterwards ( possibly because the share is read-only ).

nmap reports the port ( the number ????? changes from time to time using an apparently random high range port ) as :

PORT      STATE SERVICE   VERSION
?????/tcp open  fmproduct 1-4 (RPC #1073741824)

as far as i remember, nfsv4 does not need a port mapper to work so i don't really get the point of whatever RPC service is open on the client side. is that correct ?

if the above is correct, anybody knows how to instruct ubuntu not to open that port ?
( please don't tell me to use the firewall or hosts.deny : i do not want the port to be open in the first place )

thanks all
LVL 28
skullnobrainsAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

skullnobrainsAuthor Commented:
closing the port with the firewall ( for the sake of testing ) apparently does not prevent the mount from occurring.
tcpdump shows no connection attempt ( sniffing the traffic originating from the server on the client )

this is a recap of sniffed packets while performing unmount + mount + list directory operations

      3 IP depl101.lab.hbs.lan.58669 > nas-dist.depl.pra.hbs.lan..nfs: Flags [.],
      1 IP depl101.lab.hbs.lan.58669 > nas-dist.depl.pra.hbs.lan..nfs: Flags [F.],
      1 IP depl101.lab.hbs.lan.58669 > nas-dist.depl.pra.hbs.lan..nfs: Flags [P.],
      1 IP depl101.lab.hbs.lan.58669 > nas-dist.depl.pra.hbs.lan..nfs: Flags [S],
     42 IP depl101.lab.hbs.lan.686 > nas-dist.depl.pra.hbs.lan..nfs: Flags [.],
      1 IP depl101.lab.hbs.lan.686 > nas-dist.depl.pra.hbs.lan..nfs: Flags [F.],
   1133 IP depl101.lab.hbs.lan.686 > nas-dist.depl.pra.hbs.lan..nfs: Flags [P.],
     12 IP depl101.lab.hbs.lan.689 > nas-dist.depl.pra.hbs.lan..nfs: Flags [.],
    170 IP depl101.lab.hbs.lan.689 > nas-dist.depl.pra.hbs.lan..nfs: Flags [P.],
      1 IP depl101.lab.hbs.lan.689 > nas-dist.depl.pra.hbs.lan..nfs: Flags [S],
      1 IP nas-
      1 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.58669: Flags [.],
      1 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.58669: Flags [F.],
      1 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.58669: Flags [P.],
      1 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.58669: Flags [S.],
     10 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.686: Flags [.],
      1 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.686: Flags [F.],
   1133 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.686: Flags [P.],
     11 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.689: Flags [.],
    169 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.689: Flags [P.],
      1 IP nas-dist.depl.pra.hbs.lan..nfs > depl101.lab.hbs.lan.689: Flags [S.],

Open in new window


notice that every SYN packet is sent by depl101 ( nfs client ) to nas-dist (server ) on the NFS port

the extra opened port ( actually ports since it changes when unmounting + remounting ) do not even appear in the sniffed traffic
0
robocatCommented:
This could possibly be the nfs callback port.  This is only called to recall a delegation on a file, so you're unlikely so see traffic on this port very often.

Some distributions allow to set a fixed port for this, check your documentation. But nfsv4 will still function if this port is blocked by a firewall and not use delegations.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
skullnobrainsAuthor Commented:
confirmed, thanks : changing sysctl fs.nfs.nfs_callback_tcpport changes the port

i clearly do not want the corresponding behavior in this context

would you happen to know how to disable the feature altogether client-side ?
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

robocatCommented:
I’m not sure if you can disable this, but I don’t see the need. If the firewall blocks the callback port, nfs will detect this and automatically disable delegations.
0
skullnobrainsAuthor Commented:
my goal is to prevent programs from opening sockets and run as privileged users unless there is an actual need. i have no time to fully audit but am reluctant to trust the delegation mechanism to be even mildly difficult to exploit somehow and do not want to rely on the firewall to block loopback connections.

thanks for your help so far. i'll close this thread once i'll have time to find a decent/dumb way to achieve my secondary goal. and obviously accept your answer. thanks.
0
skullnobrainsAuthor Commented:
this is my closing comment

thanks @robocat.
this probably should have been obvious but you saved me some precious time and some hair. thanks again

i failed to find a way to disable the feature entirely.
additionally mount will fail if the callback port is fixed to an already used port.

i'll have to look into hosts.allow once/if i figure out the name of the "daemon" and if the callback port does not bypass the corresponding wrappers... or wait for the next kernel version that does have the feature
0
skullnobrainsAuthor Commented:
i REALLY thought i had closed this question weeks ago.

i guess the sliding semi-transparent ad-like windows10-UI-like confirmation not-a-window was too weird for me to figure out i was supposed to click "next" ... which i was reluctant to do, since next involves a series of different clicks and questions.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.