userland process rpc.lockd opens untraceable ports...is something wrong here?

[Freddie Cash]

On Tue, Feb 19, 2019 at 1:15 PM BBlister <bblister at gmail.com> wrote:

> During a security auditing on one FreeBSD 11.2 server I noticed that
> something was listening on a tcp4 and tcp6 port. This could not be traced
> back using lsof or sockstat. sockstat returned ? for the process name, and
> lsof did not list the port opened. The port was opened because i could
> telnet to it.
>
> I opened a thread at freebsd-questions (Cannot identify process of
> listening
> port 600/tcp6). You can find the archive of that thread here:
>
> http://freebsd.1045724.x6.nabble.com/Cannot-identify-process-of-listening-port-600-tcp6-td6314916.html
>
> After many trials, I found out that these ports were opened by rpc.locked.
> Killing that process removed the two listening ports. Restarting the
> process, opened two new random ports bellow 1024 that could not be traced
> back using all FreeBSD tools that I know to the userland process.
>
> And here is my question: How is this happening? What magic trick did
> rpc.lockd process utilizes and hides itself from security auditing tools
> like lsof or sockstat? Why rpc.lockd is the only process that hides itself
> from locating what ports it has opened? Is there any other tool except
> lsof/sockstat that can backtrace the  listening port to the process
> rpc.locked?
>
> but the most important question: Can this trickery being exploited by a
> malicious process and open listening ports without being traced using
> lsof/sockstat?
>

While it doesn't take you from a socket/port to a process, does procstat at
least show you the sockets that rpc.lockd has open?

Something like:  procstat -f <pid-of-rpc.lockd>

Although, one could probably run the following to get from the socket/port
number to the process:  procstat -f -a | grep 600

-- 
Freddie Cash
fjwcash at gmail.com