Section 2.7 Dangers and Countermeasures During Initial System Setup

   


2.7 Dangers and Countermeasures During Initial System Setup

graphics/onedangerlevel.gif

Many Linux distributions have temporary security holes. Additionally, after completing the distribution's installation and initial configuration you will want to do some additional "hardening" of the system. To protect against getting broken into during initial configuration, you should not connect to an unprotected network until configuration of the system is complete. This means that before even initially turning the system on, you should not have installed its Ethernet cable, modem cable, ISDN connection, DSL, or cable TV modem. This is absolutely imperative for DSL and cable modems because your box might appear networked with 100 of your neighbors. If any of them are crackers (or compromised systems), they could be listening for network packets from your new box to trigger automatic intrusion software.

By not initially being on untrusted networks, you then are able to "harden" your system against intrusion with the usual checks that all accounts have hard-to-guess passwords, no accounts are lacking passwords, files have the correct permissions, all security patches have been installed, no unnecessary services are enabled, etc.

At this point, some SysAdmins will want to run the Bastille Linux hardening script, presently supporting Red Hat and Mandrake. It no longer requires a freshly installed system. It may be downloaded from:

http://www.bastille-linux.org/

Some SuSE SysAdmins will want to run a hardening script for SuSE (6.1 and later), available on the CD-ROM and from:

www.suse.de/~marc/harden_suse-3.5.tar.gz


Then you can set up your "Rings of Security" with firewall rules, adaptive firewalls, TCP Wrappers, samhain or Tripwire, log file scanners, etc. See "Firewalls with IP Tables and DMZ" on page 446 or "Firewalls with IP Chains and DMZ" on page 514, "Adaptive Firewalls: Raising the Drawbridge with the Cracker Trap" on page 559, "TCP Wrappers" on page 555, "Tripwire" on page 649, and "Using Logcheck to Check Log Files You Never Check" on page 608. Only then would you turn on services that you needed and understood.

This would be a good point at which to test the configuration, preferably on a private trusted network, both for correctly providing services, and for repelling improper advances. Then it would be a good idea to make several full backups and send one to secure off-site storage. A backup using GNU tar or equivalent is recommended in addition to any other backup scheme you might prefer for reasons that will be explained.

These backups would not only be to allow you to start from scratch after an intrusion or disk failure, but also would allow future byte-by-byte comparison between the current disk contents and a trusted backup tape. This allows automatic detection of differences that might be the result of tampering by crackers. GNU tar's --compare feature (also known as --diff or -d) is useful here. Its use, as well as other techniques for finding alterations, are discussed in "Finding Cracker-Altered Files" on page 697. After following all these steps, it would then be safe to connect the new system to the network.

Keep in mind that some versions of some distributions actually enabled networking services before putting a password on root. I believe that an older version of Slackware, in particular, was guilty of this. Mike Warfield wrote a widely circulated security advisory on this.

To summarize, do not even connect your system to any networks, including any type of modem, until you have completed all installation, configuration, hardening procedures, and backed up the system.

A cracker could take over one of these systems before the SysAdmin had a chance to properly configure the system to be secure. Even though there might be a window of only a few minutes or even only a few seconds, all a cracker needs to do is leave an automatic sniffer on the network to recognize packets from any never-before-seen MAC address, also known as an Ethernet address (yours). This automatic tool would then start trying exploits.

It might take less than a second to take over your system. Because this would have been before you set up Tripwire you would not even have either a Tripwire baseline to compare against or an uncompromised backup tape to restore from. If the cracker is stealthy, he could be in for months.


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.


   
Top


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net