Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This question is similar to Network port open, but no process attached?

I've tried everything from there, reviewed the logs, etc... and can't find anything.

My netstat shows a TCP listening port and a UDP port without a pid. When I search lsof for those ports nothing comes up.

netstat -lntup
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:44231           0.0.0.0:*               LISTEN      -               
udp        0      0 0.0.0.0:55234           0.0.0.0:*                           - 

The following commands display nothing:

lsof | grep 44231
lsof | greo 55234
fuser -n tcp 44231
fuser -n udp 55234

After rebooting, those "same" two connections are there except with new port numbers:

netstat -lntup
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:45082           0.0.0.0:*               LISTEN      -               
udp        0      0 0.0.0.0:37398           0.0.0.0:*                           - 

And once again, the lsof and fuser commands show nothing.

Any ideas what they are? Should I be concerned about them?

share|improve this question
add comment

6 Answers

up vote 3 down vote accepted

From data you provided I'd say it's related to some NFS mounts or something using RPC.

you can check with rpcinfo -p for ports that might be used by some of RPC related services.

Here is how it looks on my system

# netstat -nlp | awk '{if ($NF == "-")print $0}'
tcp        0      0 0.0.0.0:55349           0.0.0.0:*               LISTEN      -               
udp        0      0 0.0.0.0:18049           0.0.0.0:*                           - 

# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  10249  status
    100024    1   tcp  10249  status
    100021    1   udp  18049  nlockmgr
    100021    3   udp  18049  nlockmgr
    100021    4   udp  18049  nlockmgr
    100021    1   tcp  55349  nlockmgr
    100021    3   tcp  55349  nlockmgr
    100021    4   tcp  55349  nlockmgr
share|improve this answer
    
Thanks. That was it. They were both nlockmgr –  mhost Sep 14 '11 at 16:17
add comment

Some processes/pids are only available to root. Try

sudo netstat -antlp

it should return the pid of every open port that's not in a TIME_WAIT state

share|improve this answer
    
every open TCP ports only with this command. UDP ports will not be shown. –  petrus Mar 31 '13 at 21:51
add comment

Is there any traffic coming or going from this port, check that with tcpdump -vv -x s 1500 port 37398 -w trace.out Saves your capture in the file trace.out you can then open it with wireshark, or tcpdump -vv port 37398 and see whats going on directly.

Try to telnet to that port use netcat for the udp socket maybe you get some kind of banner that helps.

Get rkhunter and check your system for a backdoor.

Compare the md5 hash of lsof/netstat with the one from your install media, assuming the files where not updatet.

share|improve this answer
    
I did try to locally netcat to both ports and it displays nothing. For the tcp port, it closes if I type anything and then enter. The UDP one only closes if I press Ctrl+C. I have iptables in place, and it does not allow connections to those ports, so unless they are bypassing iptables, I can't imagine something is connecting to them. –  mhost Sep 13 '11 at 19:08
    
what kind of server is it DB,APP.. which software are you using ? –  Izac Sep 13 '11 at 19:22
    
It is a web server running apache and pretty much nothing else other than things like cron and syslog. –  mhost Sep 13 '11 at 22:28
add comment

I don't know what these are specifically, but kernel modules (NFS for example) do not have a PID to associate with these sockets. Look for something suspect in lsmod.

share|improve this answer
    
lsmod returns nothing. This server is an NFS client. That is currently my #1 suspect. –  mhost Sep 13 '11 at 19:13
    
That would explain why the client ports have changed after a new instance of the kernel. –  andyortlieb Sep 13 '11 at 19:30
add comment

I have same problem that listening socket with no program. fuser shows nothing. And system is SuSE10 with 2.6.16 kernel.

On my box, rpc is stopped, but nfs is started.

share|improve this answer
add comment

I dont know if this can be useful. I had the same problem and what I did is the following: First, I called netstat with options -a(all) and -e(extended). With the latter option I can see the Inode associated to the used port. Then, I called lsof |grep with the inode number obtained and I got the PID of process associated to that inode. That worked in my case.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.