9

I am performing a quick audit of services listening on external interfaces on a Ubuntu 14.04 machine, and tmux is binding TCP *:50994 and *:59147 as reported by netstat -l.

I can connect to this port from another computer on the network (barring any firewall settings), but I can't find any documentation about why it's binding an external port. What is the purpose of this and is there a way to stop it?

Magneon
  • 193
  • 5
  • Does wireshark tell you anything about traffic going over those ports? – Parthian Shot Mar 08 '16 at 18:54
  • I shared this question on the tmux IRC channel and they are asking for you to post your tmux.conf – Aaron Mar 08 '16 at 19:06
  • Where is your netstat output? `tmux` only uses UNIX sockets... – ThiefMaster Mar 08 '16 at 20:00
  • There is no tmux.conf passed in. Running `tmux show -g` outputs [this](http://pastebin.com/gmL2RBEU). It looks like byobu changed the status bar. – Magneon Mar 08 '16 at 21:58
  • `netstat -l` shows only: "unix 2 [ ACC ] STREAM LISTENING 23223 3682/tmux /tmp/tmux-1000/default" `sudo lsof | grep 'tmux' | grep 'LISTEN'` shows tmux 3682 user_name 12u IPv4 23074 0t0 TCP *:60047 (LISTEN) tmux 3682 user_name 13u IPv4 23077 0t0 UDP *:40754 tmux 3682 user_name 14u IPv4 23078 0t0 TCP *:56417 (LISTEN) – Magneon Mar 08 '16 at 22:01
  • 3
    Can't reproduce at all, and I can't remotely think of a way an inet socket would show up in lsof but not netstat. Tried with byobu too. Also looked through tmux source and there doesn't seem to be any function that includes usage of TCP. You might want to check your tmux install source.. ? – Fira Mar 09 '16 at 08:22
  • 1
    Looking at the output of `netstat -l` how are you sure that it is tmux, as the output of that command doesn't even shown the associated process name. You need the `-p` switch for that. – Fred Thomsen Mar 10 '16 at 14:28
  • Notice that the port numbers are different in the output in your comment than in the question. So it looks like it's binding random ephemeral ports. – Barmar Mar 15 '16 at 18:03
  • Don't you have some chroot / lxc containers installed, so the process id would match tmux on the host but would be actually a different process in the container ? – Baptiste Mille-Mathias Aug 21 '16 at 08:57
  • It needn't be tmux, it could well be something tmux links against. I seem to recall that many moons ago, some nss ldap module ended up with i.e. bash listening. (Although - this may have been udp). If you really wanted to get to the bottm, run tmux through gdb, break on listen (or socket, or somesuch), and look at the call-stack to see where it happens. – Kjetil Joergensen Sep 29 '16 at 18:15

2 Answers2

1

It is tmux and it is a Unix socket. Tmux apparently uses server sockets to allow for independent tmux servers to be run. man tmux

Run tmux with no flags

tmux

$ ss -l |grep tmux
u_str  LISTEN     0      128    /tmp/tmux-1000/default 62749                 * 0

Then run tmux with -S /tmp/tmux.sock and see that the change in the socket path.

$ ss -l |grep tmux
u_str  LISTEN     0      128    /tmp/tmux.sock 62765                 * 0

Note, It is not TCP. This can be seen from using the flags -t (tcp) and -l (listening) 

$ ss -tl
(returns no lines but the headers)
Tim
  • 443
  • 2
  • 10
1

are you using tcsh? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204429 has a similar-ish problem where starting tmux on tcsh results in dns queries.

andrew perry
  • 106
  • 3