# 6000/tcp open X11 - What is this for?

## njcwotx

I use nmap externally from my gentoo box and saw that port 6000/tcp was open for X11.

I know that I can disable this and will probably do so, but this is not the question.  I want to know what it is used for.

What would connect to the X11 service externally?   Why would it be a default? I see its fairly vulnerable in research.

----------

## malern

The ability to be used over a network is one of the major features of X11. Basically it lets you run programs on other computers that connect to your X11 server to display themselves. It normally requires some sort of authentication, so vulnerabilities are limited. If you don't need it, I think you can disable the TCP socket with the "-nolisten tcp" option, local programs should still work because they connect via unix domain sockets instead.

----------

## phoenixp

 *njcwotx wrote:*   

> I use nmap externally from my gentoo box and saw that port 6000/tcp was open for X11.
> 
> 

 

For future reference you can get this info much faster with:

```
netstat -latn
```

nmap is awesome and useful for machines you don't have access to/don't trust (think rootkits hiding ports), but it's overkill in this situation. Just saying  :Wink: 

 *Quote:*   

> 
> 
> What would connect to the X11 service externally?
> 
> 

 

X11, obviously  :Wink:  It's quite cool actually. You can run your gui programs on one X server from another. 

 *Quote:*   

> Why would it be a default?
> 
> 

 

It's not in most distros (anymore), but Gentoo's all about choice, right? So, yeah, choose to check for things like this.

 *Quote:*   

> I see its fairly vulnerable in research.
> 
> 

 

Is it a clear text protocol? Yes.

Solution: X11 port forwarding through ssh for untrusted networks.

Does X run as root and have a history of buffer overflows? Yes.

Solution: As above and limit it's use to users you trust and who need to run gui apps over the network (Universities sometimes do this with a thin client infrastructure)

You can probably just disable it though if you can't see a use for it. It's probably a good idea for this to become the default. People who need it know how to enable it.

----------

## njcwotx

I had already gathered it was for porting X over network, but how would I go about connecting to it and running an app or remotely logging in.  Im more curious as to the how one goes about doing it.

I know I can tunnel through ssh with X forwarding, is this a similar process.  Some years back I saw someone using some low level system as terminals for X, is there a doc that shows the basics of how to do this?

----------

## Hu

Set the $DISPLAY variable, or pass -display if the application supports it.  If no hostname is specified, the connection is made locally.

X forwarding is based on having the sshd on the server open a socket on the server, which accepts your X traffic, performs some trickery with the authentication cookie, then forwards the traffic over the encrypted connection to the ssh on the client, which connects to your real X server.

----------

## eccerr0r

Also worth saying:

Most newer distributions have X authentication cookies working with ssh, etc.  This mechanism prevents random people from connecting to your display and wrecking havoc.  This is done with xauth and should be automatic when you ssh.  You can "xauth list" to get a list of cookies (md5 hashes) that can connect to your X server.  Both ends need to have the same MD5 'cookie' to connect with the normal authentication scheme.  Both ssh X forwarding and native tcp X connections use these cookies.

On systems that don't forward X authentication properly, a tool 'xhost' is available to allow machine level authentication, allowing whole computers to have access to your display.

Authentication is just that, authentication.  Does not do encryption.

Also the DISPLAY or -display switch should contain a string

hostname:displaynumber

where hostname is your computer's IPAddress or hostname (or localhost for loopback).  As said, if the hostname is omitted, it means the machine the software is running on via a socket, which is faster than going through the whole TCP/IP stack (and does not depend on listening to a port).  Displaynumber is usually '0' if you have only one display.  For bourne shells you could:

DISPLAY=mylocalmachine:0 xterm &

or for most other shells,

xterm -display mylocalmachine:0 &

to start an xterm through the network.  I find that X done this way on a low latency network (namely, a LAN) to be fairly quick and pleasant to use, but if latency is bad or network unreliable, VNC is a better protocol.

Personally if your app works fine with ssh X forwarding, that should be used (ssh will not forward everything correctly as far as I can tell, plus it's additional CPU load).  If not, try VNC.  Unless you're on your on private fast network, it's not worth it to use native X tcp connections.

----------

## njcwotx

I was not planning on using it full time, it was more of a gee-wiz I want to try it out and make it work before I kill it thing.  The idea being if I see someone else with an open port that ignores any suggestion to close the port, I can actually connect to their machine and show them how easy it can be done.  I find that proof is more valuable than talk  :Wink: 

----------

## eccerr0r

If their machine is set up properly, chances of you remotely connecting to a random person's open X port is slim due to the Xauth cookie - unless you manage to get it somehow.  This is not to say that it might be possible to find a bug in the listening thread to crash it and all of X along with it.  Or if that person is using host authentication instead of magic cookie... host authentication is a big hole.

----------

## cmp

I am also trying disable my listening on 6000

generaly I login to tty1 and then do a $ "startxfce4 -nolisten tcp"   which does not work. 

so I guess I have to implement the -nolisten into some other place can I get a hint?

Is it possible to run X as something else then root?

----------

## Hu

 *cmp wrote:*   

> generaly I login to tty1 and then do a $ "startxfce4 -nolisten tcp"   which does not work. 
> 
> so I guess I have to implement the -nolisten into some other place can I get a hint?
> 
> Is it possible to run X as something else then root?

 Using the basic startx script seems to pass -nolisten tcp for me.  Try that, and we can customize the resulting environment later.

The X server needs to manipulate the graphics card.  Historically, this required root privilege.  If you have a card and server that supports KMS, then X could be run as non-root.  I expect that the packager will handle switching X to non-root as soon as that is a supportable configuration.

----------

## cmp

Hey

startx -nolisten tcp 

works nicely for me so the question is how can I pass the argument in my standard settings.

----------

## depontius

 *cmp wrote:*   

> Hey
> 
> startx -nolisten tcp 
> 
> works nicely for me so the question is how can I pass the argument in my standard settings.

 

Last I knew, "-nolisten tcp" is the default for startx.  I suspect the problem was that it isn't the default for startxfce, and apparently startxfce can start X if it needs to.  You can just use startx, and put startxfce in your .xinitrc file.

I've had the problem the other way around.  At work I practically always export displays from other systems back to my desktop.  (poaching cycles on others' machines)  I was recently having some problems with xdm/gdm, and tried text mode login with startx.  Then I found that I couldn't export the display back because of the "-nolisten tcp", and port 6000 wasn't open.  I got xdm/gdm running again, faster than I had planned spending the time on it.

----------

## SamuliSuominen

This is a bug in x11-apps/xinit. The problem is missing file, and invalid patch hardcoding the -nolisten tcp to startx script instead.

There should be /etc/X11/xinit/xserverrc file with:

```
exec /usr/bin/X -nolisten tcp
```

Which both startxfce4 and startx could use. There's a open bug in Gentoo's bugzilla, please do search.

----------

## SamuliSuominen

```
http://bugs.gentoo.org/show_bug.cgi?id=193044
```

It's now fixed in X11 Overlay and will be in next xinit release in Portage. Thanks to the Xorg maintainers.   :Cool: 

----------

