Close Some Network Security Holes
As shipped, the SGI is fairly permissive in its networking. Their
philosophy appears to be that novices should be able to use their
systems and networks immediately, and if you're smart enough to be
concerned with network security, you're smart enough to close the
holes in the network. I don't necessarily agree with this approach,
but I'm sure it cuts down on the number of novice helpdesk calls they
XDM is the X Window System Display Manager. It presents a login window
(with user-icons, in the SGI case), accepts username and password, and
starts the session. It is configurable via files specifying resources,
other configuration files, and scripts. As shipped, it has a number of
SGI ships with XDM allowing all hosts access to your X server because
it runs xhost + in the XDM session files. This means that
anyone on the net can attach to your server and display on, take over,
or -- more importantly -- monitor your session (eg: login keystrokes).
You should negate this with xhost -.
Edit your system's xdm startup files to comment out the
xhost + stuff. Here are the files from Irix 5.3:
cshenton@wirehead> cd /usr/lib/X11/xdm/
cshenton@wirehead> grep -n xhost *
I change these to say:
It would be smart to then verify this. Log out of the console to
restart xdm, then log in again. Telnet to some host for which
you have not authorized X11 access to your console. Then launch an
xclock or something back to the SGI and make sure that the connection
gets rejected. Example, after logging into the console for host `apollo':
cshenton@apollo% telnet notmyfriend.hq.nasa.gov
chris@notmyfriend% xclock -display apollo.hq.nasa.gov:0
Error: Can't open display: apollo.hq.nasa.gov:0
Warning: don't do the following!
I found, to my cost, that something in the following X11-oriented
recommendations hoses the X server badly: you can't log in -- the X
server just restarts. Unfortunately, I haven't had time to determine
which one yet. If you do, please send me mail. Sorry...
Do continue with tightening the security by installing
tcp_wrappers and a modern version of sendmail,
at the end of this document.
According to the relevant section of the xdm man page, the authorize
resource should be on to enforce access authorization to the
server. Although this is said to be the default, this is set to
off in the /usr/lib/X11/xdm/xdm-config file. You should
change this, like:
Although not really a security hole, you might as well fix this while
you're in the xdm-config file. According to the appripriate
part of the xdm man page, this
defaults to false. But the server tends to grow without bounds,
consuming system memory resources. You should set it to true so
that the server restarts, rather than resets, upon logout:
X server shm bug
As mentioned above in the xdm manpage,
authorization can be bypassed because of a bug. Workaround it by the
following fix to /usr/lib/X11/xdm/Xservers; add the option
-shmnumclients 0 to the invocation of the X server:
:0 secure /usr/bin/X11/X -bs -nobitscale -c -pseudomap 4sight \
-solidroot sgilightblue -cursorFG red -cursorBG white \
(Note: the line above has be split with backslashes for readability).
Deny root login from the network
Most systems these days deny logins by root if they're coming
from the network. The idea is that if you want to log in as root, you
should do it from the console. Otherwise, you can login over the net
as yourself, then use su to become root.
SGI, by default, allows root logins from the net; here's how to
fix that. The file /etc/default/login defines lots of login
parameters. Here's the relevant part you want to use:
# If defined, only allows root logins on the device specified.
# MUST NOT be defined as either "/dev/syscon" or "/dev/systty"!
Originally, that CONSOLE variable was commented out. You
might also want to change the following variable which is defaulted to
NO for some strange reason:
# Like PASSREQ, but locks out user if they have no password.
There are other interesting variables there which you may want to play
with including ones to log failures, lockout accounts after a certain
number of failures, etc.
I like to replace my vendors' sendmail with the
UCB Sendmail. It's code has
been scrutinized and fixes are made quickly.
I install tcp_wrappers
on my systems to restrict Internet access to my machines' network
services. It's fairly easy to install and I think it stops most of the
bad guys at the front door.
$Id: close-security-holes.html,v 1.7 1996/06/11 15:28:58 cshenton Exp $