Improving systems security

World Oil, Oct, 2000 by Will Morse

Part 2-Computer security is a process of making many patches to many little holes: There is no single solution--it requires vigilance. A systems administrator gives advice to peers on practical solutions

Last month, Part 1 discussed a variety of risks, myths, misconceptions and some non-solutions. Part 2 is a list of practical solutions for reducing vulnerabilities of daemons, passwords and other common security weaknesses, without unduly hampering exploration applications. It is written for upstream-based IT professionals and developers of scripts and applications; the focus is on Unix-type systems, especially Solaris.

SECURITY POLICIES

Improving security is pointless if top management does not empower the security administrator to do his job and create/find security policies essential for success. If security management is just another difficult and obscure chore in a long list for an overworked systems administrator, it isn't going to be done.

If an exploration manager can go to the security administrator and demand something that compromises security--and get it--then there might as well not be a security administrator.

UNUSED SOFTWARE AND FUNCTIONS:

Many people think of security as a constraint, but modern operating systems come with lots of bundled software--much of which you may not even be aware of, let alone use. This software is a big risk because, since you don't use it, you are not familiar with its vulnerabilities and won't notice if it gets modified. Turning this software off by changing ownership, permissions and commenting lines in /etc/inetd.conf is a big win because it greatly reduces vulnerability with no pain to the users.

APPROPRIATE USE BANNERS

Appropriate use banners put up a message when you login (or better, before you login) that says something like: "For business use by authorized persons only." Talk to your legal department about exact wording. Some courts have found that if you don't say no, you can't sue or complain--or at least not as effectively. You also avoid giving potential intruders hints as to what operating system or version is in use.

For Solaris systems:

* The banner for login is in/etc/motd. Put the banner here.

* The banner for telnet is in /etc/default/telnetd. Use the BANNER= parameter.

* The banner for ftp is in /etc/ default/ftpd. There is also a BANNER= parameter, but it can only be one line.

* Display a banner during the dtlogin or xdm login by modifying the appropriate Xsession file to display an xmessage screen before the window manager starts. It is not necessary to have the window manager running to display an xmessage.

* The dtlogin or xdm login window should not say "Welcome." This title can be changed in /etc/dt/config/C/Xresources. Change Dtlogin*greeting.

For IRIX systems:

* The banner is in /etc/issue. This works for login, ftp and telnet. Also modify the line in /etc/inetd.conf for telnetd to put an "-h" at the end.

* Display a banner during the xdm login by changing /var/X11/xdm/Xsession to include an xmessage before the start of 4DWM.

* The xdm login window should not say "Welcome." It should not give a list of possible login names. The xdm title is defined in /var/X11/xdm/Xresources. Change Login*greeting.

* Turn off the visual login list using the chkcconfig command.

SECURITY PATCHES

Both Sun Microsystems and SGI make free security patches available on their websites. For Sun, the URL is:

http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

For SGI:

http://www.sgi.com/support/security

CDE has four major security vulnerabilities. These are documented in CERT Advisory CA-99-11 dated Sept 13, 1999.

* Tooltalk ttsession uses weak RPC authentication mechanism.

* CDE dtspcd relies on filesystem-based authentication.

* CDE dtaction can have a buffer overflow.

* CDE Tooltalk shared-library buffer overflows in ttsession.

Also, there are a series of programs in /usr/dt/bin--including dtappgather and printinfo--that are set-uid and have buffer-overflow vulnerabilities.

/ETC/INETD.CONF

The Unix "superdaemon" is inetd. It monitors messages for various programs and starts that program if needed. The list of ports and programs is in /etc/inetd.conf. If a program is commented out in /etc/inetd.conf, inetd won't start it.

There are programs listed in /etc/inetd.conf that are not likely to be used in petroleum-exploration systems. These include: rusersd, fingerd, sprayd, walld, tftpd and bootp.

Even if these programs are needed on some servers, they are probably not needed on all servers or desktops. It is likely that you use some ftp or telnet, but perhaps only on a limited set of systems. You can telnet or ftp out from a machine that cannot answer. The more things you restrict, the harder it is to break in.

/ETC/SYSTEM SETTINGS

A very large percentage of security problems come from stack overflows or buffer overflows. Many of these attacks can be stopped by putting the following two lines in your /etc/system file (for Solaris 2.6 and above):