An open X server is one which accepts X client connections without restriction or authentication of the client. Internet attackers are scanning networks for open X servers. In particular, scanning is done from a compromised system inside a site's perimeter, so blocking the X server ports at the boundary is only a small help in preventing attacks on X.
An X client can obtain an image of any open windows or the entire display, copies of all keypress and/or mouse events sent to any windows, and can send synthetic events to windows. If an intruder has this access, he essentially can control all applications and sessions you have running. That leads to compromises of at least your account, and sometimes the entire system, on every machine you are logged into.
You improve your security quite a bit by only allowing client connections from the systems you need to use at any given moment. You can give your X server process a list of hosts from which client connenctions should be permitted. This is the next level of security above "none" and is barely acceptable. In this mode, your server is open to any user on any of the machines you have enabled.
Better security involves use of an authorization key, which is a
string of bytes generated by the X server and stored in a private file
on each machine where you want to run X clients. In the Unix world, a
command-line program xauth manages this byte string. The
string is sometimes referred to as a "magic cookie" or an "xauth key"
X client programs obtain the string from the file when they open a
connection to the X server. Because of the file protections, the key
is only available to processes running under your account (or as
root). This reduces the risk exposure for your display.
Even use of xauth keys leaves you vulnerable to sniffers on the
network, because the X protocol transfers the authorization key in the
clear. The final increment of security comes from combining use of the
authorization key with an encrypted network connection.
The ssh program can create a side channel to carry your
X connection from a remote client when you use ssh to log
into that remote system. (Ssh creates the appearance of a separate X
display on the remote system itself, with a separate authorization
key, and presents itself to the real X server as a local client.)
Type Under the Settings menu,
select Security. The Security
mode MUST NOT be set to "Unrestricted
access". "User-based access" is preferred. Then you must ensure
that your remote-session-starting commands either send your
cookie (authorization key) to the remote host, or use ssh to
forward the X traffic over an encrypted tunnel. The middle
choice, "Host-based access," allows all users on any of your
designated hosts to access your X display.
When you choose user-based access, you have to send the
authorization key to the remote system when you start a remote
client. Including the following command in a session-startup dialog
will do that:
xhost - to restrict access to certain client
hosts. When the list of allowed clients is empty, access is then
based on xauth keys. See the documentation for
the xauth command for more information.
WRQ Reflection
With the semicolon in place as shown, you can simply put this
before the /usr/bin/X11/xauth add %IP#% %C%;
xterm or whatever other command starts your
remote X client.
There's also a sample session definition
file you can edit and save. (Be sure to
change some-host and yourname to fit the
remote host's name and your login name. (You may also have to
change the paths to the xauth and xterm programs on the remote system.)
There's a futher choice of what to do when clients not covered
by the host- or user-based access control request a connection. If
you set this to "prompt" you will get a dialog box every time the
scanner checks your system. If you choose "prompt" you must deny the
request to connect from the scanner when the dialog box appears or
you will be found vulnerable and blocked again. You can only allow
connections from nodes you recognize and trust. A setting of "refuse"
is recommended.
For Exceed V8, you may want to bring it up to Version 8.0.0.7 or
later, for reasons
described on Hummingbird's support pages.
(Thanks to Jim Smedinghoff for contributing the above.)
Hummingbird Exceed
[Exceed]
AskUserToAddHost=0
nightwatch@fnal.gov