Section 2.7 Dangers and Countermeasures During Initial System Setup

2.7.1 Revving Up Red Hat 7.3

Red Hat's version 7.3 goes farther than previous versions in trying to reduce the "geek knowledge" required to get Linux running, as do some of the other major Linux players. I salute this effort as I assist my nontechnical friends in moving to Linux. However, a few things could use improvement. With any initial system installation and configuration, I recommend either disconnecting the system from all networks or ensuring that no intruder can get to it. If the system is behind a well-configured firewall where there are no systems vulnerable to viruses, this should be suitable.

First, the client is offered a choice of four installation types: workstation, server, laptop, or custom. For casual use when chained to a desk, the choice is between workstation and server installation. With a workstation installation, you get the X windowing system, but no SSH daemon. This prevents the almost universal practice of SSH'ing into one's workstation from home or the office or the other side of the world.

Ha! I'll just tell it that I want a server installation to get the SSH daemon and any other servers that I may want to "play" with, possibly for "collaboration." The excellent on-screen documentation told me that with that server installation, I will not get X. While I recommend not installing X on high-security servers (because it is buggy and runs set-UID), this lack of choice to have both the SSH daemon and X on a noncustom system was not well-thought-out by Red Hat. The installation process really should have asked me if I wanted X for a server installation and if I wanted the SSH daemon for workstation setup, in my opinion.

Ensure that all accounts have strong passwords if there is any chance of a path to the system from the Internet—and even if there is not such a path . To install the SSH daemon, sshd, on your workstation, insert the second installation CD-ROM and issue the following commands as root while muttering under your breath :

mount -r /dev/cdrom /mnt/cdrom rpm -vhU /mnt/cdrom/RedHat/RPMS/openssh-server-3.1p1-3.i386.rpm rpm -vhU /mnt/cdrom/RedHat/RPMS/openssh-askpass-3.1p1-3.i386.rpm umount /dev/

cdrom

chkconfig --level 234 sshd on chkconfig --add sshd service sshd start

Copy over your shell and editor configuration files and then get to work with initial hardening. This hardening is just to protect the system from network attacks. I am assuming that initially we can trust anyone with a user password to not be evil. Doing a man command on xinetd and xinetd.conf will give all of the details.

Red Hat has created the inetdconvert program to convert one's inetd.conf file to xinetd configuration files and released it under the GNU's Not UNIX (GNU) General Public License. It is on the companion CD-ROM. Invoking it with the -h flag will give a confusing usage message. To convert from an inetd.conf file in the current directory, the following will work:

mkdir foo inetdconvert -d foo --inetdfile inetd.conf --convertremaining more foo/* cp foo/* /etc/xinetd.d/. killall -1 xinetd

We now will use the techniques that will be discussed in "Turn Off Unneeded Services" on page 86. Invoke X (unless you will not ever be using X) with the command

startx

Issue the command

netstat -anptu  more

Alas, you will see that X is listening on TCP port 6000, ripe for the cracking. Since X runs as root, has a default authentication of questionable security, and has plenty of bugs , it should not be accessible from the network. As per "X Marks the Hole" on page 117, edit $HOME/.xserverrc . If it already has a line that begins with "X", remove it. Add the line

X -nolisten tcp :0

Shut down and restart X and invoke netstat again to verify that TCP port 6000 no longer is open . Edit .xserverrc for each account where someone might invoke X.

Sendmail is listening on port 25 of the loopback device at IP 127.0.0.1. It is not clear if this represents more than a small locally exploitable risk but there is no reason for Sendmail to be listening on any port unless the system will be a mail server. Edit the /etc/sysconfig/sendmail file and change the line

DAEMON=yes

to read

DAEMON=no

Then issue the command

service sendmail restart netstat -anptu  more

Observe that Sendmail no longer is listening on TCP port 25.

Check for security patches and install any that affect programs, libraries, or the kernel as discussed in "New Lamps for Old" on page 103. Red Hat's innovative up2date program that checks for new security patches and advises when they are available is a good solution for many people. For production systems, any new versions of software need to be tested , both to make sure that nothing went awry during installation and that the new programs did not cause a regression in security, such as alteration of permissions or access.

By default, RH7.3 starts IP Chains rather than IP Tables. There is a bug in the IP Chains startup script. This bug causes the system to briefly turn off all firewall rules if you issue the command

/etc/rc.d/init.d/ipchains

with a start , stop , or restart argument while networking is enabled. Fortunately, when this is done during system bootup or shutdown, networking is not enabled so there is not a window of vulnerability created.

This script processes rules from the configuration file

/etc/sysconfig/ipchains

The format of this file is the same as a shell script containing the ipchains commands, except that the command name ( ipchains ) is absent, and policies are specified with a " : " instead of " -P ".

If the /etc/rc.d/init.d/ipchains script is invoked with save , it will save the system's current rules in this configuration file. A better solution is to install my modified version of this script that simply will invoke /etc/rc.d/rc.fw , which should be a script you write from scratch based on "Firewalls with IP Chains and DMZ" on page 514.

Both IP Tables and IP Chains are implemented as kernel modules. If either is loaded, the other one cannot be loaded. Because there is both an S08ipchains and an S08iptables script in the /etc/rc.d/rc3.d directory, they are invoked in ASCII collating sequence, and because S08ipchains comes first, it wins. If you rename S08ipchains to s08ipchains and do

ipchains -X ipchains -F rmmod ipchains

or reboot the system, you then can use IP Tables. The ipchains -X and ipchains -F are because you cannot unload the module if there are user-chains or rules defined.

As with IP Chains, there is a window of vulnerability if you invoke Red Hat's IP Tables script when networking is enabled. There is an improved script on the CD-ROM. Instead of parsing /etc/sysconfig/ipchains , it will invoke /etc/rc.d/rc.fw . This should be a shell script you write based on "Firewalls with IP Tables and DMZ" on page 446.

Red Hat 7.3 runs LogWatch at 4 A.M. every night. This program's job is to scan the log files for abnormalities and send e-mail to root listing them. Once a day, especially at 4 A.M. , is not frequent enough to receive timely notification of an attack. Further, it does not give enough information to know more than something is happening with sftp . It does not give times of events, nor does it indicate what terminal a failed login occurred on. The following are the results of one 4 A.M. run.

################## LogWatch 2.6 Begin ##################### --------------------- SSHD Begin ------------------------ Failed logins from these: root/none from 12.129.72.144: 1 time(s) Users logging in through sshd: root logged in from f18 (12.129.72.144) using password: 1 times(s) **Unmatched Entries** subsystem request for sftp ---------------------- SSHD End ------------------------- ###################### LogWatch End #########################

Red Hat's choice of LogWatch may be to spare its customers from the time-consuming process of, say, checking Logcheck's detailed output every few hours. Unfortunately, it is ineffective . Logcheck does a much better job, is not a significant burden for small networks and individual systems, and is quite necessary for larger ones. I recommend that the daily LogWatch invocations be turned off (by removing /etc/cron.daily/00-logwatch ) and that Logcheck be installed and used, as discussed in "Using Logcheck to Check Log Files You Never Check" on page 608.