By Kurt Seifried, [email protected]
The X Window System provides a network-transparent method for sharing graphical data, or more specifically for exporting the display of a program to a remote (or the local) host. Using it you can run a powerful 3d rendering package on your SGI origin 2000 and display it on a 486. Essentially it's the granddaddy to all this 'thin client' hype that is becoming very popular nowadays. It was created by MIT, at a time when security was not much of a concern. This, of course, has led to more then a few nasty bugs being found. Worse, the level of control X is given (it handles keystrokes, mouse movements, draws the screen, etc.) means if it is compromised, very bad things will happen. This data, if sent over the network (i.e., the X program being run is displaying on a remote host) can easily be logged, so sensitive information (like an xterm being used to login to another remote system) is vulnerable. In addition to these problems the authentication protocol that X uses is relatively weak (although it has been improved). Running a graphical xemacs session on a server 3 timezones away however can be a very handy thing.
X is very predictable in port usage, almost all implementations and installations of X use port 6000 for the first session and increment by one for other sessions, thus making it quite easy to scan for. If you are not going to be using X to display program running on remote systems I suggest strongly that you firewall port 6000.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 6000:6100 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 6000:6100 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 6000:6100
or
ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 6000:6100 ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 6000:6100 ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 6000:6100
There are a number of methods to secure access to your X server. --no-listen-tcp
xhost simply allows you to specify which machines are, or aren't allowed to connect to the X server, this is a very simplistic security mechanism and is not really suitable in any modern environment, however used in conjunction with other mechanisms it can help. The command is quite simple: 'xhost +example.org' adds example.org, 'xhost -example.org' removes example.org from the list, you must also specify 'xhost -' to turn on the access control list, or else everyone is let in by default.
mkxauth is definitely a step up from xhost. mkxauth helps create ~/.Xauthority files, and merge them, which are used to specify hostnames and the related magic cookies (basically a token used to gain access). These cookies can then be used to gain access to a remote X host (you essentially have a copy of the cookie on each end) and are transferred either plain text (insecure) or DES encrypted (quite secure). Using this method you can be relatively safe and secure. Xauthority files can also be used in conjunction with Kerberos, removing the necessity to copy Xauthority files around and keep them in synchronization. Hosts authenticate to each other through a central Kerberos key server(s) in an encrypted fashion, this method is most appropriate for large installations/etc. mkxauth has an excellent man page 'man mkxauth' and more generalized details are available in the Xsecurity man page (not sure how common this name page is) 'man Xsecurity'.
SSH or OpenSSH can be used to create a tunnel between hosts (or more specifically between two X servers), thus encrypting the channel, providing authentication, and generally making things safer. The following web page explains it http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/.
Last updated on 2/9/2001
Copyright Kurt Seifried 2001 [email protected]