GDM also supports the X Display Manager Protocol (XDMCP) for managing
remote displays.
GDM listens to UDP port 177 and will respond to QUERY and
BROADCAST_QUERY requests by sending a WILLING packet to the originator.
GDM can also be configured to honor INDIRECT queries and present a
host chooser to the remote display. GDM will remember the user's
choice and forward subsequent requests to the chosen manager.  GDM
also supports an extension to the protocol which will make it forget
the redirection once the user's connection succeeds.  This extension
is only supported if both daemons are GDM.  It is transparent and
will be ignored by XDM or other daemons that implement XDMCP.
GDM only supports the MIT-MAGIC-COOKIE-1 authentication system.
Normally little is gained from the other schemes, and no effort has
been made to implement them so far.  Because of this the cookies go
over the wire as clear text, and thus you should be careful about what
network you use this on.  That is, you should be careful about through
where your XDMCP connection is going.  Note that obviously if snooping
is possible, then the attacker could just snoop your password as you
log in, so a better XDMCP authentication wouldn't help you much anyway.
If snooping is possible and undesirable, then you had better use ssh
for tunneling an X connection anyway rather then using GDM's XDMCP.
You could think of XDMCP as a sort of graphical telnet, having the
same security issues.
On the upside, GDM's random number generation is very anal and GDM
goes to extraordinary measures to truly get a 128 bit random number,
using hardware random number generators if available, plus the current
time (in microsecond precision), a 20 byte array of pseudorandom
numbers, process pid's, plus other random information (possibly using
/dev/audio or /dev/mem if
hardware random generators are not available) to create a large buffer
and then run MD5 digest on this.  Obviously, all this work is wasted if
you send this cookie over an open network or store it on an NFS
directory (see UserAuthDir configuration key).  So
be careful about where you use remote X display.
Since it is fairly easy to do denial of service attacks on the XDMCP
service, GDM incorporates a few features to guard against attacks.
Please read the XDMCP reference section below for more information.
Even though GDM tries to outsmart potential attackers, it is still
advised that you block UDP port 177 on your firewall unless you really
need it. GDM guards against DoS attacks, but the X protocol is still
inherently insecure and should only be used in controlled environments.
Also each remote connection takes up lots of resources, so it is much
easier to to DoS an XDMCP server then say a webserver.
In addition to UDP port 177, you should also block all the X server
ports (TCP ports 6000 + display number) on the firewall as well.  Do
note that various places in GDM will use display numbers 20 and higher
(for example the on demand server stuff).  X is not a very safe
protocol for leaving on the net, and XDMCP is even less safe.
Even though your display is protected by cookies the XEvents and thus
the keystrokes typed when entering passwords will still go over the
wire in clear text. It is trivial to capture these.  You should also be
aware that cookies, if placed on an NFS mounted directory, are prone to
eavesdropping too.  In case of NFS home directories you should really
use the UserAuthDir and set it to some local
temporary directory.
XDMCP is primarily useful for running thin clients such as in terminal
labs.  Those thin clients will only ever need the network to access
the server, and so it seems like the best policy securitywise to have
those thin clients on a separate network that cannot be accessed by
the outside world, and can only connect to the server.  The only point
from which you need to access outside is the server.
