Securing a Default Linux Distro Installation


With the increasing popularity and reliance upon the World Wide Web, e-commerce, and computing in general by individuals, corporations, and governments information technology has become a huge target for amoral teenagers, hacker-activists, and out-right criminals. In the arms race to secure systems against attack and cracker's development of new tools to exploit weaknesses in those defenses there seems to be no end in sight. Some examples of this growing sophistication are the March 14, 2001 notice from The National Infrastructure Portection Center (NIPC), Intrusion Detection Systems (IDS) Exploit. This assessment details a manner in which a "denial of service" attack is directed at an IDS system. The attack "floods" the IDS with false positives in order to crash it. Once crashed the attacker can then look unrelated vulnerabilities in the target system.

While Nmap is a very useful tool for troubleshooting one's own system it is also a favored tool of crackers to "case" potential victims. Nmap incorporates numerous steath-mode port-probing techniques, remote operating system detection via TCP/IP stack fingerprinting, uptime scanning, TCP timestamp, IP ID sequence predictability reporting and much more. Once a system has been breached there are many tools that might be used. Various "root kits", trojan programs, clean up tools to hide the penetration, tools to subvert IDS systems (such as Tripwire), network sniffers, and more.

As the popularity of Linux grows more and more malicious attacks are being directed at systems running operating system built around the Linux kernel. This past January the Ramen worm attacked Red Hat 6.2 and 7.0 systems. Using commonly available tools and exploiting known bugs in the default installation of these versions of the Red Hat distribution the worm had a fairly high body count. The patches for the security holes targeted were available before the worm was released into the wild. (An in-depth dissection of the worm by Daniel Martin can be found here.) Its success was due in part to a lack of understanding on the part of many coomputer system administrators. A fair amount of blame can also be laid at the doorstep of proprietary operating system vendors who have misled users into believing that no maintenance is needed but to buy the upgrade every eighteen months. (The advanced user path is a Service Pack at six months, followed by a second Service Pack at twelve months, then buy an upgrade at eighteen months.)

A question often asked is "Which distro is more secure?" This is a somewhat misleading and begs the question "what is secure?". Security is coming to be seen as a process rather then a "set and forget" one-shot exercise. Which leads to how to strike a balance between security and usability. Particularily for someone who is not interested in the internals of the operating system but views it merely as a tool for doing other tasks.

The first step in setting up a computer is to decide the nature of its use. Is it to be a file-server, a thin-client, a stand-alone workstation, or a web-server to name just a few possiblities? The most common case for users new to computers and/or Linux is the stand-alone workstation. This is the configuration I am going to focus on here for two reasons. First, it is the simplist case. Second, anyone setting up one of the other configurations really needs to do their homework so that they know what is involved and what precautions must be taken. It is precisely those who don't do the legwork that cry the loudest when they end up with a disk full of ramen noodles.

Physical Security
It is recommended that you set a Boot password to disallow booting from floppy drives and set passwords on BIOS features. You can check your BIOS manual or look it over thoroughly the next time you boot up your system to know how to do this. Disallowing the possibility to boot from floppy drives and being able to set a password to access the BIOS features will improve the security of your system. This will block undesired people from trying to boot your Linux system with a special boot disk and will protect you from people trying to change BIOS feature like allowing boot from floppy drive or booting the server without prompt password.

With new systems it should be mentioned that a BIOS change to prevent booting from any removable media ought to be implemented. This would include CD-ROM and Zip drives to name two.

Some feedback from the meeting when this paper was presented suggested that the box be secured in a locked closet, security cabinet, or server room where ever possible. One problem of unauthorized access mentioned was cleaning staff and/or their children playing games on the machines at night. While setting the BIOS password is a good idea there are programs to get the BIOS password from a machine that may be used by a determined attacker.

After the box has been locked down so that it will only boot from the hard drive there are some settings that can be made in most bootloaders to tighten things up there. Using LILO on a single boot system the "delay" setting should be set to 0. Obviously this does not work for a dual boot system. additional LILO settings Additional the immutable flag should be set on the lilo.conf file to prevent any changes.

Password Selection

What many security experts consider to be the number one security exploit is weak passwords. Some suggestions for password selection include a mnemonic sentence where the first letter of each word is used. Mix lower and upper case letters with numbers and special characters.

For some additional considerations for increasing password security see

Installation and Configuration

Since we are describing the securing of a stand-alone workstation there is no need to install the Apache web server, the MySQL database management application, an FTP server, or other server or remote access software. If the software is not installed cracker's can not leverage exploits in that package and the owner of the system does not have to expend time and energy maintaining it.

Configure the hosts deny and hosts allow files.

  Access control
  One area often overlooked in security is the use of access control files. Two main files, 
/etc/hosts.deny and /etc/hosts.allow control who can access a given system, how they can 
access it, and from where they can access it. These two files are set up as an access pair 
with hosts.deny being read and used first and then hosts.allow. Simply put, /etc/hosts.deny 
should be set up to deny everyone from accessing your computer. Then, add the specific hosts 
that can access your system to hosts.allow. Generally, you only want your internal network 
to be able to access your system and nothing else.
  Here is a typical hosts.deny file:
  # hosts.deny	This file describes the names 
  #       of the hosts which are *not* allowed to 
  #       use the local INET services, as decided
  #		by the '/usr/sbin/tcpd' server.
  # The portmap line is redundant, but it is left to 
  # remind you that the new secure portmap uses hosts.deny 
  # and hosts.allow.  In particular you should know that 
  # NFS uses portmap!
  The line ALL:ALL means that all services from all hosts are denied access. Now, look at 
  # hosts.allow	This file describes the names 
  # of the hosts which are allowed to use the 
  # local INET services, as decided
  # by the '/usr/sbin/tcpd' server.
  The use of LOCAL refers to the loopback interface and to unqualified hostnames; hosts without 
a dot in their name or hostnames without a domain name. For better security however, it's best 
to address your internal network specifically like this:
  # hosts.allow	This file describes the names 
  # of the hosts which are allowed to use the 
  # local INET services, as decided
  # by the '/usr/sbin/tcpd' server.
  Once again, if this is a server machine, you might want to allow access to specific services 
such as SSH or POP3 from specific machines on your network, like this:
  # hosts.allow	This file describes the names 
  # of the hosts which are allowed to use the 
  # local INET services, as decided
  # by the '/usr/sbin/tcpd' server.
  You can set up rules that are considerably more complicated and restricted, but the above 
examples should give you a general idea. Take a look at host_access(5) for more details as well 
as a good book on system security.

Apply Patches

Visit your distribution vendor's website and download/install all applicable security patches. For example Red Hat 7.1 Errata

Feedback from the meeting offered quite a few options in this area.

[fix me]

Turning Off Services

Killing Daemons!

[fix me]

Monitor Alert Resources

I find BugTraq to be the most informed and timely mailing list. Knowing what software I have installed on my various systems I am able to peruse the subject lines of posts to this list and be tipped off to problems often days or weeks before they appear in other channels. Thus, greatly reducing the "window of vulnerablity" of my systems.

See BozemanLUG Security Links

[fix me]

Install Security Software

Red Hat 7.1 comes with a pre-configured firewall option. I have not had a chance to explore the nature of this set-up and therefore can not really report upon it. It does use the 2.4.x kernel which allows the use of iptables.

Netfilter is the new firewall infrastructure built into the 2.4.x series of kernels. It is configured with the iptables tool. Netfilter is a stateful packet filtering implementation. It includes such features as connection tracking and a new implementation of network address translation (NAT).

Tripwire is a tool that creates a checksum hash of files. This hash can then be compared with the file to see if it has been modified.

From here the meeting progressed into a lively discussion of various security measures and techniques.

[fix me]

Related Links
Intrusion Detection Systems (IDS) Exploit
Ramen Worm
Securing and Optimizing Linux
Linux Administrator's Security Guide
Beyond Firewalls
Red Hat 7.1 Errata
Killing Daemons!


Last updated on April 27, 2001