Solved Listening port :600/tcp6 cannot be mapped to process. Am I hacked?

bigbrother

New Member


Messages: 9

Dear,

I have a strange problem. I have located on my Freebsd machine a listening port 600/tcp6 which cannot be traced back to a process.
I have tried, to locate the process that has opened this port, but as you see in the attached code, nothing happened. I believe that this port has been opened by a kernel module. I also attach the kldstat. Is this port opened by a legit kernel module (and if yes, which?). Otherwise is it a rootkit and my machine has been somehow hacked (it is used for nginx and rtorrent and it is located on a fast line). How can I trace the offending program that listens on this port?

I haven't reboot the system, because I would like to investigate it further. If no suggestions are posted for 1 week, I will reboot and see if this port is opened again.

Code:
[root@xxx ~]# netstat -an |grep 600
tcp6       0      0 *.600                  *.*                    LISTEN

[root@xxx ~]# sockstat |grep :600
?        ?          ?     ?  tcp6   *:600                 *:*

[root@xxx ~]# lsof -n -s -P    | grep ':600 '
lsof: WARNING: compiled for FreeBSD release 11.2-RELEASE-p7; this is 11.2-RELEASE-p8.

[root@xxx ~]# uname -a
FreeBSD xxxxx 11.2-RELEASE-p8 FreeBSD 11.2-RELEASE-p8 #0: Tue Jan  8 21:35:12 UTC 2019     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

[root@xxx ~]# kldstat
Id Refs Address            Size     Name
 1   37 0xffffffff80200000 20647c8  kernel
 2    1 0xffffffff82266000 2d40     coretemp.ko
 3    1 0xffffffff82421000 6fc4     tmpfs.ko
 4    1 0xffffffff82428000 41f0     linprocfs.ko
 5    2 0xffffffff8242d000 2d28     linux_common.ko
 6    1 0xffffffff82430000 195c     linsysfs.ko
 7    4 0xffffffff82432000 20198    ipfw.ko
 8    1 0xffffffff82453000 24a0     if_tap.ko
 9    1 0xffffffff82456000 107a0    dummynet.ko
10    1 0xffffffff82467000 13f0     ipdivert.ko
11    1 0xffffffff82469000 21b0     ipfw_nat.ko
12    1 0xffffffff8246c000 a4f2     libalias.ko

#connecting to the port produces no input...

[root@xxx ~]# telnet -6  ::1 600
Trying ::1...
Connected to localhost.
Escape character is '^]'.
help
?
test
...
 
Last edited by a moderator:

roccobaroccoSC

Well-Known Member

Reaction score: 95
Messages: 425

You could make the firewall log activity on that port.
Also, you can use tcpdump to analyze the content of the datagrams.
If I recall correctly, nmap has a service discovery mode and it can try to detect what exactly is listening on the port.
 
OP
OP
B

bigbrother

New Member


Messages: 9

I have executed tcpdump for 24 hours but I couln't receive/send any packet destined for that port. This is a passive way of detecting what is happening, and involves reverse engineering, because the datagram may be encrypted.

It is difficult to wait for a packet to arrive or depart on port 600 (maybe it is trojan waiting to be activated?).

I find it strange that FreeBSD does not have a tool to detect kernel listening sockets and the only way to detect what is happening it just by sniffing and trying to figure out the datagrams.
 

roccobaroccoSC

Well-Known Member

Reaction score: 95
Messages: 425

I don't know if this is the only way, because I don't know all the ways.
If you're just annoyed by it, simply block it in the firewall. It'll never receive or send any packets, so it'll never communicate to anything ever.

If you want to analyze - juse tools like nmap. They will try to communicate with the port and identify the software behind it.
There is also a hacker toolkit called "metasploit", which is a kind of database of all publicly known vulnerabilities and can scan a host for them. So you could let it loose on your box and see what it can detect.

I personally try not to use such tools though, because I don't completely trust them, they might just as well infect my host, or upload its vulnerabilities somewhere. But I am quite paranoid as admin.

P.S. If you decide to use metasploit, install it on some other machine you are prepared to "sacrifice" and then scan your main system. After finishing the job, you could just format the sacrificial machine and then you're clean again... unless your main host is indeed infected.
 

roccobaroccoSC

Well-Known Member

Reaction score: 95
Messages: 425

Some other ideas:

In sysctl.conf I see the following comment (maybe check if you enabled that):
# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0

Use commands like this:
who
htop
iftop
lsof -i :600
fstat | grep ':600'

netstat -Aan | grep "LISTEN"
fstat | grep fffff8033f99e000 # the last thing is the number falling out of "netstat -Aan" for your process

If that does not help, I woud think you need to either get a fresh binary kernel, or make sure you compile your kernel without any modifications in the source tree. Just pull the latest svn, make sure nothing is modified and compile GENERIC.

Use the command "freebsd-update IDS" to see which files on your system are different from the officially released ones.
 
OP
OP
B

bigbrother

New Member


Messages: 9

I have raised this in freebsd-questions and freebsd-hackers list http://freebsd.1045724.x6.nabble.com/Cannot-identify-process-of-listening-port-600-tcp6-td6314916.html#none http://freebsd.1045724.x6.nabble.com/userland-process-rpc-lockd-opens-untraceable-ports-is-something-wrong-here-td6315572.html . This behaviour is known to the freebsd hackers and is due to rpc.lockd to open a port and pass that reference to the kernel and closes it. Thus, the userland tools like sockstat and lsof cannot identify the process because it is the kernel itself.

I believe sockstat or lsof should print the kernel as the owner of that port and not just questionmark ?

Also, rpcinfo does not seem to print IPv6 port bindings (for my case, probably for others?).

I always do a binary update and keep track of GENERIC.
For security in every server I do enable: security.bsd.see_other_uids=0

I know metasploit but it has a rough learning curve and thus I have never used it more than some minutes.

I considered this solved, because I have identified the culprit.

Thanks.
 
Top