2.7 Dangers and Countermeasures During Initial System Setup
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
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.
Then you can set up your "Rings of Security" with firewall rules, adaptive firewalls, TCP Wrappers, samhain or Tripwire, log file
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
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
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
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
First, the client is
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
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
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/
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
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
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
X -nolisten tcp :0
Shut down and restart X and invoke
again to verify that TCP port 6000 no longer is
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
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
By default, RH7.3 starts IP Chains rather than IP Tables. There is a bug in the IP Chains
script. This bug causes the system to
argument while networking is enabled. Fortunately, when this is done during system
This script processes rules from the configuration file
The format of this file is the same as a shell script containing the
commands, except that the command
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
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,
################## LogWatch 2.6 Begin ##################### --------------------- SSHD Begin ------------------------ Failed logins from these: root/none from 184.108.40.206: 1 time(s) Users logging in through sshd: root logged in from f18 (220.127.116.11) 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