Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185683 > unrolled thread

NFS creates hidden port

Back to article view | Back to linux.debian.user

Contents

  NFS creates hidden port Rob van der Putten <rob@sput.nl> - 2017-08-22 10:40 +0200
    Re: NFS creates hidden port tomas@tuxteam.de - 2017-08-22 11:00 +0200
    Re: NFS creates hidden port <tomas@tuxteam.de> - 2017-08-22 11:00 +0200
      Re: NFS creates hidden port "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-22 11:20 +0200
        Re: NFS creates hidden port <tomas@tuxteam.de> - 2017-08-22 11:50 +0200
          Re: NFS creates hidden port Rob van der Putten <rob@sput.nl> - 2017-08-22 12:10 +0200
            Re: NFS creates hidden port <tomas@tuxteam.de> - 2017-08-22 12:30 +0200
            Re: NFS creates hidden port "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-22 12:40 +0200
              Re: NFS creates hidden port Rob van der Putten <rob@sput.nl> - 2017-08-22 13:50 +0200
                Re: NFS creates hidden port "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-22 15:30 +0200
                  Re: NFS creates hidden port Rob van der Putten <rob@sput.nl> - 2017-08-22 17:20 +0200
                    Re: NFS creates hidden port "Thomas Schmitt" <scdbackup@gmx.net> - 2017-08-22 18:10 +0200
                      Re: NFS creates hidden port Rob van der Putten <rob@sput.nl> - 2017-08-23 13:50 +0200

#185683 — NFS creates hidden port

Hi there


More stretch weirdness:
Rkhunter alerts me to a hidden port. Restarting NFS changes the port 
number. Today I did a netstat after restarting NFS and then run 
unhide-tcp a few times: It's the client side of RPC NFS callback.
What can I do about this?


Regards,
Rob

[toc] | [next] | [standalone]

#185684

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 22, 2017 at 10:55:09AM +0200, tomas@tuxteam.de wrote:
> On Tue, Aug 22, 2017 at 10:31:03AM +0200, Rob van der Putten wrote:
> > Hi there
> > 
> > 
> > More stretch weirdness:
> > Rkhunter alerts me to a hidden port. Restarting NFS changes the port
> > number. Today I did a netstat after restarting NFS and then run
> > unhide-tcp a few times: It's the client side of RPC NFS callback.
> > What can I do about this?
> 
> This is a bit thin on details, so just guessing from my side. RPC
> traditionally uses a moving port, assigned by the port mapper.

Duh. Forgot to provide a link, sorry. Here it is:

  https://en.wikipedia.org/wiki/Portmap

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmb8doACgkQBcgs9XrR2kYjswCePDE5cBtgCBqNOanmlyZgzMFz
GcYAn0jf2rOw+7noZQUn/4sh06J5ObnK
=GYAL
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185685

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 22, 2017 at 10:31:03AM +0200, Rob van der Putten wrote:
> Hi there
> 
> 
> More stretch weirdness:
> Rkhunter alerts me to a hidden port. Restarting NFS changes the port
> number. Today I did a netstat after restarting NFS and then run
> unhide-tcp a few times: It's the client side of RPC NFS callback.
> What can I do about this?

This is a bit thin on details, so just guessing from my side. RPC
traditionally uses a moving port, assigned by the port mapper.

You can configure it to behave as you want it to (RPC and naive,
port based firewall rules have always been a bit at odds with each
other.).

Perhaps you are seeing that? 

What on earth is "unhide-tcp"?

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmb8W0ACgkQBcgs9XrR2kbIvwCeKtPVD17ocTpy7y2aMhWUUsyR
knsAnjZyHlCYPg3IjbM4FuB/ToSxEQ3h
=p6Xi
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185687

Hi,

tomas@tuxteam.de wrote:
> What on earth is "unhide-tcp"?

A very heuristic thing, as it seems:

  https://linux.die.net/man/8/unhide-tcp
  "unhide-tcp is a forensic tool that identifies TCP/UDP ports that
   are listening but are not listed in /bin/netstat through brute
   forcing of all TCP/UDP ports available."

This raises the question why netstat does not show Rob's NFS ports.
Does NFS change the port fast enough so that netstat and port scan differ ?


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185689

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 22, 2017 at 11:14:51AM +0200, Thomas Schmitt wrote:
> Hi,
> 
> tomas@tuxteam.de wrote:
> > What on earth is "unhide-tcp"?
> 
> A very heuristic thing, as it seems:

Hm. Thanks.

> This raises the question why netstat does not show Rob's NFS ports.
> Does NFS change the port fast enough so that netstat and port scan differ ?

A good question. I guess we need more details from the OP.

> Have a nice day :)

Thanks, likewise :)
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmb/PsACgkQBcgs9XrR2kZviQCdHHsREqjhroUScdHyiG3GoFZ2
/swAn1FbgHaYNZpNFFVfHjxt0MuaXmkG
=DHpP
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185692

Hi there


On 22/08/17 11:44, tomas@tuxteam.de wrote:

<Cut>

>> This raises the question why netstat does not show Rob's NFS ports.
>> Does NFS change the port fast enough so that netstat and port scan differ ?
> 
> A good question. I guess we need more details from the OP.

The hidden port lingers on for days. Until one restarts NFS. NFS then 
uses an other port which clearly shows in netstat, until it becomes 
hidden again. And the daily rkhunter [1] starts complaining about it.

[1] https://en.wikipedia.org/wiki/Rkhunter

I think this may be a kernel bug.


Regards,
Rob

[toc] | [prev] | [next] | [standalone]

#185695

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 22, 2017 at 12:02:45PM +0200, Rob van der Putten wrote:
> Hi there
> 
> 
> On 22/08/17 11:44, tomas@tuxteam.de wrote:
> 
> <Cut>
> 
> >>This raises the question why netstat does not show Rob's NFS ports.
> >>Does NFS change the port fast enough so that netstat and port scan differ ?
> >
> >A good question. I guess we need more details from the OP.
> 
> The hidden port lingers on for days. Until one restarts NFS. NFS
> then uses an other port which clearly shows in netstat, until it
> becomes hidden again. And the daily rkhunter [1] starts complaining
> about it.

How do you call netstat?

cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmcBw0ACgkQBcgs9XrR2kavNQCcC20qO99YzqJaZT2lJruBe0O6
JsEAn00ua1A91Z+FUuRJXHy7JVlOPLg/
=mmo0
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185697

Hi,

Rob van der Putten wrote:
> I think this may be a kernel bug.

A valid theory for now. I googled on:
  https://askubuntu.com/questions/851986/rkhunter-reports-hidden-tcp-port-probably-nfs-server
brings me to
  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg910866.html
Some suspicious kernel commit ids are mentioned in
  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg911346.html
It looks like the original poster ended up speaking to himself. Insightful
but lonely.

One year late the problem appeared again
  https://patchwork.kernel.org/patch/9207481/


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185698

Hi there


On 22/08/17 12:38, Thomas Schmitt wrote:

> Rob van der Putten wrote:
>> I think this may be a kernel bug.
> 
> A valid theory for now. I googled on:
>    https://askubuntu.com/questions/851986/rkhunter-reports-hidden-tcp-port-probably-nfs-server
> brings me to
>    http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg910866.html
> Some suspicious kernel commit ids are mentioned in
>    http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg911346.html
> It looks like the original poster ended up speaking to himself. Insightful
> but lonely.
> 
> One year late the problem appeared again
>    https://patchwork.kernel.org/patch/9207481/

And this post is over a year old. One would expect this to be fixed by now.


Regards,
Rob

[toc] | [prev] | [next] | [standalone]

#185706

Hi,

Rob van der Putten wrote:
> And this post is over a year old.

It seems that it was fixed or suppressed intermediately.
The newer post says "It's back!".


> One would expect this to be fixed by now.

I already stated my enthusiasm on occasion of your post about DVD ejecting.
It is discouraging to get ignored after having invested substantial
effort in diagnosing or at least reliably reproducing a kernel problem.


Well, complaining is futile. Try to work around in user space.
E.g. try to patch unhide-tcp so that it reads the NFS port number from
a file which you create before the Rkhunter run.

You could let function checkoneport() return "ok" if "port" is the
registered NFS zombie. This would be done before the function runs
netstat by
   if (NULL != (fich_tmp=popen (command, "r")))
in
  https://sources.debian.net/src/unhide/20130526-1/unhide-tcp.c/#L190


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#185718

Hi there


On 22/08/17 15:23, Thomas Schmitt wrote:

> It seems that it was fixed or suppressed intermediately.
> The newer post says "It's back!".

> I already stated my enthusiasm on occasion of your post about DVD ejecting.
> It is discouraging to get ignored after having invested substantial
> effort in diagnosing or at least reliably reproducing a kernel problem.
> 
> 
> Well, complaining is futile. Try to work around in user space.
> E.g. try to patch unhide-tcp so that it reads the NFS port number from
> a file which you create before the Rkhunter run.
> 
> You could let function checkoneport() return "ok" if "port" is the
> registered NFS zombie. This would be done before the function runs
> netstat by
>     if (NULL != (fich_tmp=popen (command, "r")))
> in
>    https://sources.debian.net/src/unhide/20130526-1/unhide-tcp.c/#L190

I would have to find out when NFS does a callback an then dump the local 
port into a file.


Regards,
Rob

[toc] | [prev] | [next] | [standalone]

#185724

Hi,

i wrote:
> > E.g. try to patch unhide-tcp so that it reads the NFS port number from
> > a file which you create before the Rkhunter run.

Rob van der Putten wrote:
> I would have to find out when NFS does a callback an then dump the local
> port into a file.

Earlier:
> > > The hidden port lingers on for days. Until one restarts NFS.
> > > NFS then uses an other port which clearly shows in netstat,
> > > until it becomes hidden again.

One could make a script which determines and records the port number
as long as it is visible. When it vanishes from netstat, then one would
stay with the recorded number until the NFS port re-appears in netstat
again.


> It's the client side of RPC NFS callback. 

Question is whether it can be unambiguously recognized in netstat output
as long as it is visible.
Further: Is it always only one hidden port ?


Have a nice day 

Thomas

[toc] | [prev] | [next] | [standalone]

#185775

Hi there


On 22/08/17 18:01, Thomas Schmitt wrote:

<Cut>

> Question is whether it can be unambiguously recognized in netstat output
> as long as it is visible.
> Further: Is it always only one hidden port ?

It's always a callback from a Stretch NFS server to a Jessie NFS client. 
It occurs when the client mounts. The port moves from established, to 
wait to hidden.

When the Jessie box mounts a dir exported by Stretch, the Stetch box 
does a callback. When the Stretch box mounts a dir exported by the 
Jessie box, the Jessie box doesn't callback.

As a temporary fix a disabled the callback by mounting with NFS version 
three (vers=3) on the Jessie box.


Regards,
Rob

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web