Linux Security HOWTO

Kevin Fenzi

Tummy.com, LTD

kevin-securityhowto@tummy.com

Dave Wreski

linuxsecurity.com

dave@linuxsecurity.com

v2.0, 11 June 2002


Table of Contents
1. Introduction
1.1. New Versions of this Document
1.2. Feedback
1.3. Disclaimer
1.4. Copyright Information
2. Overview
2.1. Why Do We Need Security?
2.2. How Secure Is Secure?
2.3. What Are You Trying to Protect?
2.4. Developing A Security Policy
2.5. Means of Securing Your Site
2.6. Organization of This Document
3. Physical Security
3.1. Computer locks
3.2. BIOS Security
3.3. Boot Loader Security
3.4. xlock and vlock
3.5. Security of local devices
3.6. Detecting Physical Security Compromises
4. Local Security
4.1. Creating New Accounts
4.2. Root Security
5. Files and File system Security
5.1. Umask Settings
5.2. File Permissions
5.3. Integrity Checking
5.4. Trojan Horses
6. Password Security and Encryption
6.1. PGP and Public-Key Cryptography
6.2. SSL, S-HTTP and S/MIME
6.3. Linux IPSEC Implementations
6.4. ssh (Secure Shell) and stelnet
6.5. PAM - Pluggable Authentication Modules
6.6. Cryptographic IP Encapsulation (CIPE)
6.7. Kerberos
6.8. Shadow Passwords.
6.9. "Crack" and "John the Ripper"
6.10. CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System
6.11. X11, SVGA and display security
7. Kernel Security
7.1. 2.0 Kernel Compile Options
7.2. 2.2 Kernel Compile Options
7.3. Kernel Devices
8. Network Security
8.1. Packet Sniffers
8.2. System services and tcp_wrappers
8.3. Verify Your DNS Information
8.4. identd
8.5. Configuring and Securing the Postfix MTA
8.6. SATAN, ISS, and Other Network Scanners
8.7. sendmail, qmail and MTA's
8.8. Denial of Service Attacks
8.9. NFS (Network File System) Security.
8.10. NIS (Network Information Service) (formerly YP).
8.11. Firewalls
8.12. IP Chains - Linux Kernel 2.2.x Firewalling
8.13. Netfilter - Linux Kernel 2.4.x Firewalling
8.14. VPNs - Virtual Private Networks
9. Security Preparation (before you go on-line)
9.1. Make a Full Backup of Your Machine
9.2. Choosing a Good Backup Schedule
9.3. Testing your backups
9.4. Backup Your RPM or Debian File Database
9.5. Keep Track of Your System Accounting Data
9.6. Apply All New System Updates.
10. What To Do During and After a Breakin
10.1. Security Compromise Underway.
10.2. Security Compromise has already happened
11. Security Sources
11.1. LinuxSecurity.com References
11.2. FTP Sites
11.3. Web Sites
11.4. Mailing Lists
11.5. Books - Printed Reading Material
12. Glossary
13. Frequently Asked Questions
14. Conclusion
15. Acknowledgments

1. Introduction

This document covers some of the main issues that affect Linux security. General philosophy and net-born resources are discussed.

A number of other HOWTO documents overlap with security issues, and those documents have been pointed to wherever appropriate.

This document is not meant to be a up-to-date exploits document. Large numbers of new exploits happen all the time. This document will tell you where to look for such up-to-date information, and will give some general methods to prevent such exploits from taking place.


1.2. Feedback

All comments, error reports, additional information and criticism of all sorts should be directed to:

kevin-securityhowto@tummy.com

and

dave@linuxsecurity.com

Note: Please send your feedback to both authors. Also, be sure and include "Linux" "security", or "HOWTO" in your subject to avoid Kevin's spam filter.


2. Overview

This document will attempt to explain some procedures and commonly-used software to help your Linux system be more secure. It is important to discuss some of the basic concepts first, and create a security foundation, before we get started.


2.3. What Are You Trying to Protect?

Before you attempt to secure your system, you should determine what level of threat you have to protect against, what risks you should or should not take, and how vulnerable your system is as a result. You should analyze your system to know what you're protecting, why you're protecting it, what value it has, and who has responsibility for your data and other assets.


2.5. Means of Securing Your Site

This document will discuss various means with which you can secure the assets you have worked hard for: your local machine, your data, your users, your network, even your reputation. What would happen to your reputation if an intruder deleted some of your users' data? Or defaced your web site? Or published your company's corporate project plan for next quarter? If you are planning a network installation, there are many factors you must take into account before adding a single machine to your network.

Even if you have a single dial up PPP account, or just a small site, this does not mean intruders won't be interested in your systems. Large, high-profile sites are not the only targets -- many intruders simply want to exploit as many sites as possible, regardless of their size. Additionally, they may use a security hole in your site to gain access to other sites you're connected to.

Intruders have a lot of time on their hands, and can avoid guessing how you've obscured your system just by trying all the possibilities. There are also a number of reasons an intruder may be interested in your systems, which we will discuss later.


2.6. Organization of This Document

This document has been divided into a number of sections. They cover several broad security issues. The first, Section 3, covers how you need to protect your physical machine from tampering. The second, Section 4, describes how to protect your system from tampering by local users. The third, Section 5, shows you how to setup your file systems and permissions on your files. The next, Section 6, discusses how to use encryption to better secure your machine and network. Section 7 discusses what kernel options you should set or be aware of for a more secure system. Section 8, describes how to better secure your Linux system from network attacks. Section 9, discusses how to prepare your machine(s) before bringing them on-line. Next, Section 10, discusses what to do when you detect a system compromise in progress or detect one that has recently happened. In Section 11, some primary security resources are enumerated. The Q and A section Section 13, answers some frequently-asked questions, and finally a conclusion in Section 14

The two main points to realize when reading this document are:

  • Be aware of your system. Check system logs such as /var/log/messages and keep an eye on your system, and

  • Keep your system up-to-date by making sure you have installed the current versions of software and have upgraded per security alerts. Just doing this will help make your system markedly more secure.


3. Physical Security

The first layer of security you need to take into account is the physical security of your computer systems. Who has direct physical access to your machine? Should they? Can you protect your machine from their tampering? Should you?

How much physical security you need on your system is very dependent on your situation, and/or budget.

If you are a home user, you probably don't need a lot (although you might need to protect your machine from tampering by children or annoying relatives). If you are in a lab, you need considerably more, but users will still need to be able to get work done on the machines. Many of the following sections will help out. If you are in an office, you may or may not need to secure your machine off-hours or while you are away. At some companies, leaving your console unsecured is a termination offense.

Obvious physical security methods such as locks on doors, cables, locked cabinets, and video surveillance are all good ideas, but beyond the scope of this document. :)


3.2. BIOS Security

The BIOS is the lowest level of software that configures or manipulates your x86-based hardware. LILO and other Linux boot methods access the BIOS to determine how to boot up your Linux machine. Other hardware that Linux runs on has similar software (Open Firmware on Macs and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent attackers from rebooting your machine and manipulating your Linux system.

Many PC BIOSs let you set a boot password. This doesn't provide all that much security (the BIOS can be reset, or removed if someone can get into the case), but might be a good deterrent (i.e. it will take time and leave traces of tampering). Similarly, on S/Linux (Linux for SPARC(tm) processor machines), your EEPROM can be set to require a boot-up password. This might slow attackers down.

Another risk of trusting BIOS passwords to secure your system is the default password problem. Most BIOS makers don't expect people to open up their computer and disconnect batteries if they forget their password and have equipped their BIOSes with default passwords that work regardless of your chosen password. Some of the more common passwords include:

j262 AWARD_SW AWARD_PW lkwpeter Biostar AMI Award bios BIOS setup cmos AMI!SW1 AMI?SW1 password hewittrand shift + s y x z

I tested an Award BIOS and AWARD_PW worked. These passwords are quite easily available from manufacturers' websites and http://astalavista.box.sk and as such a BIOS password cannot be considered adequate protection from a knowledgeable attacker.

Many x86 BIOSs also allow you to specify various other good security settings. Check your BIOS manual or look at it the next time you boot up. For example, some BIOSs disallow booting from floppy drives and some require passwords to access some BIOS features.

Note: If you have a server machine, and you set up a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the event of a power failure. ;(


3.3. Boot Loader Security

The various Linux boot loaders also can have a boot password set. LILO, for example, has password and restricted settings; password requires password at boot time, whereas restricted requires a boot-time password only if you specify options (such as single) at the LILO prompt.

>From the lilo.conf man page:

password=password
              The per-image option `password=...' (see below) applies to all images.

restricted
              The per-image option `restricted' (see below) applies to all images.

       password=password
              Protect the image by a password.

       restricted
              A password is only required to boot the image if
              parameters are specified  on  the  command  line 
              (e.g. single).

Keep in mind when setting all these passwords that you need to remember them. :) Also remember that these passwords will merely slow the determined attacker. They won't prevent someone from booting from a floppy, and mounting your root partition. If you are using security in conjunction with a boot loader, you might as well disable booting from a floppy in your computer's BIOS, and password-protect the BIOS.

Also keep in mind that the /etc/lilo.conf will need to be mode "600" (readable and writing for root only), or others will be able to read your passwords!

If anyone has security-related information from a different boot loader, we would love to hear it. (grub, silo, milo, linload, etc).

Note: If you have a server machine, and you set up a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the event of a power failure. ;(


3.6. Detecting Physical Security Compromises

The first thing to always note is when your machine was rebooted. Since Linux is a robust and stable OS, the only times your machine should reboot is when you take it down for OS upgrades, hardware swapping, or the like. If your machine has rebooted without you doing it, that may be a sign that an intruder has compromised it. Many of the ways that your machine can be compromised require the intruder to reboot or power off your machine.

Check for signs of tampering on the case and computer area. Although many intruders clean traces of their presence out of logs, it's a good idea to check through them all and note any discrepancy.

It is also a good idea to store log data at a secure location, such as a dedicated log server within your well-protected network. Once a machine has been compromised, log data becomes of little use as it most likely has also been modified by the intruder.

The syslog daemon can be configured to automatically send log data to a central syslog server, but this is typically sent unencrypted, allowing an intruder to view data as it is being transferred. This may reveal information about your network that is not intended to be public. There are syslog daemons available that encrypt the data as it is being sent.

Also be aware that faking syslog messages is easy -- with an exploit program having been published. Syslog even accepts net log entries claiming to come from the local host without indicating their true origin.

Some things to check for in your logs:

We will discuss system log data Section 9.5 in the HOWTO.


4. Local Security

The next thing to take a look at is the security in your system against attacks from local users. Did we just say local users? Yes!

Getting access to a local user account is one of the first things that system intruders attempt while on their way to exploiting the root account. With lax local security, they can then "upgrade" their normal user access to root access using a variety of bugs and poorly setup local services. If you make sure your local security is tight, then the intruder will have another hurdle to jump.

Local users can also cause a lot of havoc with your system even (especially) if they really are who they say they are. Providing accounts to people you don't know or for whom you have no contact information is a very bad idea.


4.2. Root Security

The most sought-after account on your machine is the root (superuser) account. This account has authority over the entire machine, which may also include authority over other machines on the network. Remember that you should only use the root account for very short, specific tasks, and should mostly run as a normal user. Even small mistakes made while logged in as the root user can cause problems. The less time you are on with root privileges, the safer you will be.

Several tricks to avoid messing up your own box as root:

If you absolutely positively need to allow someone (hopefully very trusted) to have root access to your machine, there are a few tools that can help. sudo allows users to use their password to access a limited set of commands as root. This would allow you to, for instance, let a user be able to eject and mount removable media on your Linux box, but have no other root privileges. sudo also keeps a log of all successful and unsuccessful sudo attempts, allowing you to track down who used what command to do what. For this reason sudo works well even in places where a number of people have root access, because it helps you keep track of changes made.

Although sudo can be used to give specific users specific privileges for specific tasks, it does have several shortcomings. It should be used only for a limited set of tasks, like restarting a server, or adding new users. Any program that offers a shell escape will give root access to a user invoking it via sudo. This includes most editors, for example. Also, a program as innocuous as /bin/cat can be used to overwrite files, which could allow root to be exploited. Consider sudo as a means for accountability, and don't expect it to replace the root user and still be secure.


5. Files and File system Security

A few minutes of preparation and planning ahead before putting your systems on-line can help to protect them and the data stored on them.


5.2. File Permissions

It's important to ensure that your system files are not open for casual editing by users and groups who shouldn't be doing such system maintenance.

Unix separates access control on files and directories according to three characteristics: owner, group, and other. There is always exactly one owner, any number of members of the group, and everyone else.

A quick explanation of Unix permissions:

Ownership - Which user(s) and group(s) retain(s) control of the permission settings of the node and parent of the node

Permissions - Bits capable of being set or reset to allow certain types of access to it. Permissions for directories may have a different meaning than the same set of permissions on files.

Read:

Write:

  • To be able to add to or change a file

  • To be able to delete or move files in a directory

Execute:

  • To be able to run a binary program or shell script

  • To be able to search in a directory, combined with read permission

Save Text Attribute: (For directories)

The "sticky bit" also has a different meaning when applied to directories than when applied to files. If the sticky bit is set on a directory, then a user may only delete files that the he owns or for which he has explicit write permission granted, even when he has write access to the directory. This is designed for directories like /tmp, which are world-writable, but where it may not be desirable to allow any user to delete files at will. The sticky bit is seen as a t in a long directory listing.

SUID Attribute: (For Files)

This describes set-user-id permissions on the file. When the set user ID access mode is set in the owner permissions, and the file is executable, processes which run it are granted access to system resources based on user who owns the file, as opposed to the user who created the process. This is the cause of many "buffer overflow" exploits.

SGID Attribute: (For Files)

If set in the group permissions, this bit controls the "set group id" status of a file. This behaves the same way as SUID, except the group is affected instead. The file must be executable for this to have any effect.

SGID Attribute: (For directories)

If you set the SGID bit on a directory (with chmod g+s directory), files created in that directory will have their group set to the directory's group.

You - The owner of the file

Group - The group you belong to

Everyone - Anyone on the system that is not the owner or a member of the group

File Example:


        -rw-r--r--  1 kevin  users         114 Aug 28  1997 .zlogin
        1st bit - directory?             (no)
         2nd bit - read by owner?         (yes, by kevin)
          3rd bit - write by owner?        (yes, by kevin)
           4th bit - execute by owner?      (no)
            5th bit - read by group?         (yes, by users)
             6th bit - write by group?        (no)
              7th bit - execute by group?      (no)
               8th bit - read by everyone?      (yes, by everyone)
                9th bit - write by everyone?     (no)
                 10th bit - execute by everyone?  (no)

The following lines are examples of the minimum sets of permissions that are required to perform the access described. You may want to give more permission than what's listed here, but this should describe what these minimum permissions on files do:


-r--------  Allow read access to the file by owner
--w-------  Allows the owner to modify or delete the file
            (Note that anyone with write permission to the directory
             the file is in can overwrite it and thus delete it)
---x------  The owner can execute this program, but not shell scripts, 
	     which still need read permission
---s------  Will execute with effective User ID = to owner
--------s-  Will execute with effective Group ID = to group
-rw------T  No update of "last modified time".  Usually used for swap
	     files
---t------  No effect.  (formerly sticky bit)

Directory Example:

        drwxr-xr-x  3 kevin  users         512 Sep 19 13:47 .public_html/
        1st bit - directory?             (yes, it contains many files)
         2nd bit - read by owner?         (yes, by kevin)
          3rd bit - write by owner?        (yes, by kevin)
           4th bit - execute by owner?      (yes, by kevin)
            5th bit - read by group?         (yes, by users
             6th bit - write by group?        (no)
              7th bit - execute by group?      (yes, by users)
               8th bit - read by everyone?      (yes, by everyone)
                9th bit - write by everyone?     (no)
                 10th bit - execute by everyone?  (yes, by everyone)

The following lines are examples of the minimum sets of permissions that are required to perform the access described. You may want to give more permission than what's listed, but this should describe what these minimum permissions on directories do:


dr--------  The contents can be listed, but file attributes can't be read
d--x------  The directory can be entered, and used in full execution paths
dr-x------  File attributes can be read by owner
d-wx------  Files can be created/deleted, even if the directory
	     isn't the current one
d------x-t  Prevents files from deletion by others with write
	     access. Used on /tmp
d---s--s--  No effect

System configuration files (usually in /etc) are usually mode 640 (-rw-r-----), and owned by root. Depending on your site's security requirements, you might adjust this. Never leave any system files writable by a group or everyone. Some configuration files, including /etc/shadow, should only be readable by root, and directories in /etc should at least not be accessible by others.

SUID Shell Scripts

SUID shell scripts are a serious security risk, and for this reason the kernel will not honor them. Regardless of how secure you think the shell script is, it can be exploited to give the cracker a root shell.


5.3. Integrity Checking

Another very good way to detect local (and also network) attacks on your system is to run an integrity checker like Tripwire, Aide or Osiris. These integrety checkers run a number of checksums on all your important binaries and config files and compares them against a database of former, known-good values as a reference. Thus, any changes in the files will be flagged.

It's a good idea to install these sorts of programs onto a floppy, and then physically set the write protect on the floppy. This way intruders can't tamper with the integrety checker itself or change the database. Once you have something like this setup, it's a good idea to run it as part of your normal security administration duties to see if anything has changed.

You can even add a crontab entry to run the checker from your floppy every night and mail you the results in the morning. Something like:

		# set mailto
		MAILTO=kevin
		# run Tripwire
		15 05 * * * root /usr/local/adm/tcheck/tripwire 
will mail you a report each morning at 5:15am.

Integrity checkers can be a godsend to detecting intruders before you would otherwise notice them. Since a lot of files change on the average system, you have to be careful what is cracker activity and what is your own doing.

You can find the freely available unsusported version of Tripwire at http://www.tripwire.org, free of charge. Manuals and support can be purchased.

Aide can be found at http://www.cs.tut.fi/~rammer/aide.html.

Osiris can be found at http://www.shmoo.com/osiris/.


6. Password Security and Encryption

One of the most important security features used today are passwords. It is important for both you and all your users to have secure, unguessable passwords. Most of the more recent Linux distributions include passwd programs that do not allow you to set a easily guessable password. Make sure your passwd program is up to date and has these features.

In-depth discussion of encryption is beyond the scope of this document, but an introduction is in order. Encryption is very useful, possibly even necessary in this day and age. There are all sorts of methods of encrypting data, each with its own set of characteristics.

Most Unicies (and Linux is no exception) primarily use a one-way encryption algorithm, called DES (Data Encryption Standard) to encrypt your passwords. This encrypted password is then stored in (typically) /etc/passwd (or less commonly) /etc/shadow. When you attempt to login, the password you type in is encrypted again and compared with the entry in the file that stores your passwords. If they match, it must be the same password, and you are allowed access. Although DES is a two-way encryption algorithm (you can code and then decode a message, given the right keys), the variant that most Unixes use is one-way. This means that it should not be possible to reverse the encryption to get the password from the contents of /etc/passwd (or /etc/shadow).

Brute force attacks, such as "Crack" or "John the Ripper" (see section Section 6.9) can often guess passwords unless your password is sufficiently random. PAM modules (see below) allow you to use a different encryption routine with your passwords (MD5 or the like). You can use Crack to your advantage, as well. Consider periodically running Crack against your own password database, to find insecure passwords. Then contact the offending user, and instruct him to change his password.

You can go to http://consult.cern.ch/writeup/security/security_3.html for information on how to choose a good password.


6.1. PGP and Public-Key Cryptography

Public-key cryptography, such as that used for PGP, uses one key for encryption, and one key for decryption. Traditional cryptography, however, uses the same key for encryption and decryption; this key must be known to both parties, and thus somehow transferred from one to the other securely.

To alleviate the need to securely transmit the encryption key, public-key encryption uses two separate keys: a public key and a private key. Each person's public key is available by anyone to do the encryption, while at the same time each person keeps his or her private key to decrypt messages encrypted with the correct public key.

There are advantages to both public key and private key cryptography, and you can read about those differences in the RSA Cryptography FAQ, listed at the end of this section.

PGP (Pretty Good Privacy) is well-supported on Linux. Versions 2.6.2 and 5.0 are known to work well. For a good primer on PGP and how to use it, take a look at the PGP FAQ: http://www.pgp.com/service/export/faq/55faq.cgi

Be sure to use the version that is applicable to your country. Due to export restrictions by the US Government, strong-encryption is prohibited from being transferred in electronic form outside the country.

US export controls are now managed by EAR (Export Administration Regulations). They are no longer governed by ITAR.

There is also a step-by-step guide for configuring PGP on Linux available at http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html. It was written for the international version of PGP, but is easily adaptable to the United States version. You may also need a patch for some of the latest versions of Linux; the patch is available at ftp://metalab.unc.edu/pub/Linux/apps/crypto.

There is a project maintaining a free re-implementation of pgp with open source. GnuPG is a complete and free replacement for PGP. Because it does not use IDEA or RSA it can be used without any restrictions. GnuPG is in compliance with OpenPGP. See the GNU Privacy Guard web page for more information: http://www.gnupg.org/.

More information on cryptography can be found in the RSA cryptography FAQ, available at http://www.rsa.com/rsalabs/newfaq/. Here you will find information on such terms as "Diffie-Hellman", "public-key cryptography", "digital certificates", etc.


6.2. SSL, S-HTTP and S/MIME

Often users ask about the differences between the various security and encryption protocols, and how to use them. While this isn't an encryption document, it is a good idea to explain briefly what each protocol is, and where to find more information.


6.3. Linux IPSEC Implementations

Along with CIPE, and other forms of data encryption, there are also several other implementations of IPSEC for Linux. IPSEC is an effort by the IETF to create cryptographically-secure communications at the IP network level, and to provide authentication, integrity, access control, and confidentiality. Information on IPSEC and Internet draft can be found at http://www.ietf.org/html.charters/ipsec-charter.html. You can also find links to other protocols involving key management, and an IPSEC mailing list and archives.

The x-kernel Linux implementation, which is being developed at the University of Arizona, uses an object-based framework for implementing network protocols called x-kernel, and can be found at http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html. Most simply, the x-kernel is a method of passing messages at the kernel level, which makes for an easier implementation.

Another freely-available IPSEC implementation is the Linux FreeS/WAN IPSEC. Their web page states, ""These services allow you to build secure tunnels through untrusted networks. Everything passing through the untrusted net is encrypted by the IPSEC gateway machine and decrypted by the gateway at the other end. The result is Virtual Private Network or VPN. This is a network which is effectively private even though it includes machines at several different sites connected by the insecure Internet.""

It's available for download from http://www.xs4all.nl/~freeswan/, and has just reached 1.0 at the time of this writing.

As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.


6.4. ssh (Secure Shell) and stelnet

ssh and stelnet are suites of programs that allow you to login to remote systems and have a encrypted connection.

openssh is a suite of programs used as a secure replacement for rlogin, rsh and rcp. It uses public-key cryptography to encrypt communications between two hosts, as well as to authenticate users. It can be used to securely login to a remote host or copy data between hosts, while preventing man-in-the-middle attacks (session hijacking) and DNS spoofing. It will perform data compression on your connections, and secure X11 communications between hosts.

There are several ssh implementiations now. The original commercial implementation by Data Fellows can be found at The ssh home page can be found at http://www.datafellows.com.

The excellent Openssh implementation is based on a early version of the datafellows ssh and has been totally reworked to not include any patented or proprietary pieces. It is free and under a BSD license. It can be found at: http://www.openssh.com.

There is also a open source project to re-implement ssh from the ground up called "psst...". For more information see: http://www.net.lut.ac.uk/psst/

You can also use ssh from your Windows workstation to your Linux ssh server. There are several freely available Windows client implementations, including the one at http://guardian.htu.tuwien.ac.at/therapy/ssh/ as well as a commercial implementation from DataFellows, at http://www.datafellows.com.

SSLeay is a free implementation of Netscape's Secure Sockets Layer protocol, developed by Eric Young. It includes several applications, such as Secure telnet, a module for Apache, several databases, as well as several algorithms including DES, IDEA and Blowfish.

Using this library, a secure telnet replacement has been created that does encryption over a telnet connection. Unlike SSH, stelnet uses SSL, the Secure Sockets Layer protocol developed by Netscape. You can find Secure telnet and Secure FTP by starting with the SSLeay FAQ, available at http://www.psy.uq.oz.au/~ftp/Crypto/.

SRP is another secure telnet/ftp implementation. From their web page:

""The SRP project is developing secure Internet software for free worldwide use. Starting with a fully-secure Telnet and FTP distribution, we hope to supplant weak networked authentication systems with strong replacements that do not sacrifice user-friendliness for security. Security should be the default, not an option!" "

For more information, go to http://www-cs-students.stanford.edu/~tjw/srp/


6.5. PAM - Pluggable Authentication Modules

Newer versions of the Red Hat Linux and Debian Linux distributions ship with a unified authentication scheme called "PAM". PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries. Configuration of PAM is beyond the scope of this document, but be sure to take a look at the PAM web site for more information. http://www.kernel.org/pub/linux/libs/pam/index.html.

Just a few of the things you can do with PAM:

  • Use encryption other than DES for your passwords. (Making them harder to brute-force decode)

  • Set resource limits on all your users so they can't perform denial-of-service attacks (number of processes, amount of memory, etc)

  • Enable shadow passwords (see below) on the fly

  • allow specific users to login only at specific times from specific places

Within a few hours of installing and configuring your system, you can prevent many attacks before they even occur. For example, use PAM to disable the system-wide usage of .rhosts files in user's home directories by adding these lines to /etc/pam.d/rlogin:

		#
		# Disable rsh/rlogin/rexec for users
		#
		login auth required pam_rhosts_auth.so no_rhosts


6.6. Cryptographic IP Encapsulation (CIPE)

The primary goal of this software is to provide a facility for secure (against eavesdropping, including traffic analysis, and faked message injection) subnetwork interconnection across an insecure packet network such as the Internet.

CIPE encrypts the data at the network level. Packets traveling between hosts on the network are encrypted. The encryption engine is placed near the driver which sends and receives packets.

This is unlike SSH, which encrypts the data by connection, at the socket level. A logical connection between programs running on different hosts is encrypted.

CIPE can be used in tunnelling, in order to create a Virtual Private Network. Low-level encryption has the advantage that it can be made to work transparently between the two networks connected in the VPN, without any change to application software.

Summarized from the CIPE documentation:

"The IPSEC standards define a set of protocols which can be used (among other things) to build encrypted VPNs. However, IPSEC is a rather heavyweight and complicated protocol set with a lot of options, implementations of the full protocol set are still rarely used and some issues (such as key management) are still not fully resolved. CIPE uses a simpler approach, in which many things which can be parameterized (such as the choice of the actual encryption algorithm used) are an install-time fixed choice. This limits flexibility, but allows for a simple (and therefore efficient, easy to debug...) implementation."

Further information can be found at http://www.inka.de/~bigred/devel/cipe.html

As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.


6.9. "Crack" and "John the Ripper"

If for some reason your passwd program is not enforcing hard-to-guess passwords, you might want to run a password-cracking program and make sure your users' passwords are secure.

Password cracking programs work on a simple idea: they try every word in the dictionary, and then variations on those words, encrypting each one and checking it against your encrypted password. If they get a match they know what your password is.

There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" (http://www.openwall.com/john/) . They will take up a lot of your CPU time, but you should be able to tell if an attacker could get in using them by running them first yourself and notifying users with weak passwords. Note that an attacker would have to use some other hole first in order to read your /etc/passwd file, but such holes are more common than you might think.

Because security is only as strong as the most insecure host, it is worth mentioning that if you have any Windows machines on your network, you should check out L0phtCrack, a Crack implementation for Windows. It's available from http://www.l0pht.com


6.10. CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System

CFS is a way of encrypting entire directory trees and allowing users to store encrypted files on them. It uses an NFS server running on the local machine. RPMS are available at http://www.zedz.net/redhat/, and more information on how it all works is at ftp://ftp.research.att.com/dist/mab/.

TCFS improves on CFS by adding more integration with the file system, so that it's transparent to users that the file system that is encrypted. More information at: http://www.tcfs.it/.

It also need not be used on entire file systems. It works on directory trees as well.


6.11. X11, SVGA and display security

6.11.1. X11

It's important for you to secure your graphical display to prevent attackers from grabbing your passwords as you type them, reading documents or information you are reading on your screen, or even using a hole to gain root access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system.

X has a number of access-control mechanisms. The simplest of them is host-based: you use xhost to specify the hosts that are allowed access to your display. This is not very secure at all, because if someone has access to your machine, they can xhost + their machine and get in easily. Also, if you have to allow access from an untrusted machine, anyone there can compromise your display.

When using xdm (X Display Manager) to log in, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128-bit "cookie" is generated and stored in your .Xauthority file. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide access to only that connection. See the Remote-X-Apps mini-howto, available at http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.

You can also use ssh (see Section 6.4, above) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no unencrypted data flows across the network.

You can also disable any remote connections to your X server by using the '-nolisten tcp' options to your X server. This will prevent any network connections to your server over tcp sockets.

Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites on which you wish to run X programs.


7. Kernel Security

This is a description of the kernel configuration options that relate to security, and an explanation of what they do, and how to use them.

As the kernel controls your computer's networking, it is important that it be very secure, and not be compromised. To prevent some of the latest networking attacks, you should try to keep your kernel version current. You can find new kernels at or from your distribution vendor.

There is also a international group providing a single unified crypto patch to the mainstream Linux kernel. This patch provides support for a number of cryptographic subsystems and things that cannot be included in the mainstream kernel due to export restrictions. For more information, visit their web page at: http://www.kerneli.org


7.1. 2.0 Kernel Compile Options

For 2.0.x kernels, the following options apply. You should see these options during the kernel configuration process. Many of the comments here are from ./linux/Documentation/Configure.help, which is the same document that is referenced while using the Help facility during the make config stage of compiling the kernel.


7.2. 2.2 Kernel Compile Options

For 2.2.x kernels, many of the options are the same, but a few new ones have been developed. Many of the comments here are from ./linux/Documentation/Configure.help, which is the same document that is referenced while using the Help facility during the make config stage of compiling the kernel. Only the newly- added options are listed below. Consult the 2.0 description for a list of other necessary options. The most significant change in the 2.2 kernel series is the IP firewalling code. The ipchains program is now used to install IP firewalling, instead of the ipfwadm program used in the 2.0 kernel.


7.3. Kernel Devices

There are a few block and character devices available on Linux that will also help you with security.

The two devices /dev/random and /dev/urandom are provided by the kernel to provide random data at any time.

Both /dev/random and /dev/urandom should be secure enough to use in generating PGP keys, ssh challenges, and other applications where secure random numbers are required. Attackers should be unable to predict the next number given any initial sequence of numbers from these sources. There has been a lot of effort put in to ensuring that the numbers you get from these sources are random in every sense of the word.

The only difference between the two devices, is that /dev/random runs out of random bytes and it makes you wait for more to be accumulated. Note that on some systems, it can block for a long time waiting for new user-generated entropy to be entered into the system. So you have to use care before using /dev/random. (Perhaps the best thing to do is to use it when you're generating sensitive keying information, and you tell the user to pound on the keyboard repeatedly until you print out "OK, enough".)

/dev/random is high quality entropy, generated from measuring the inter-interrupt times etc. It blocks until enough bits of random data are available.

/dev/urandom is similar, but when the store of entropy is running low, it'll return a cryptographically strong hash of what there is. This isn't as secure, but it's enough for most applications.

You might read from the devices using something like:


	root#  head -c 6 /dev/urandom | mimencode
This will print six random characters on the console, suitable for password generation. You can find mimencode in the metamail package.

See /usr/src/linux/drivers/char/random.c for a description of the algorithm.

Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for helping me (Dave) with this.


8. Network Security

Network security is becoming more and more important as people spend more and more time connected. Compromising network security is often much easier than compromising physical or local security, and is much more common.

There are a number of good tools to assist with network security, and more and more of them are shipping with Linux distributions.


8.2. System services and tcp_wrappers

Before you put your Linux system on ANY network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole.

There are a number of ways to disable services under Linux. You can look at your /etc/inetd.conf file and see what services are being offered by your inetd. Disable any that you do not need by commenting them out (# at the beginning of the line), and then sending your inetd process a SIGHUP.

You can also remove (or comment out) services in your /etc/services file. This will mean that local clients will also be unable to find the service (i.e., if you remove ftp, and try and ftp to a remote site from that machine it will fail with an "unknown service" message). It's usually not worth the trouble to remove services from /etc/services, since it provides no additional security. If a local person wanted to use ftp even though you had commented it out, they would make their own client that used the common FTP port and would still work fine.

Some of the services you might want to leave enabled are:

If you know you are not going to use some particular package, you can also delete it entirely. rpm -e packagename under the Red Hat distribution will erase an entire package. Under Debian dpkg --remove does the same thing.

Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login (used by rlogin), shell (used by rcp), and exec (used by rsh) from being started in /etc/inetd.conf. These protocols are extremely insecure and have been the cause of exploits in the past.

You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-9].d on Debian), and see if any of the servers started in those directories are not needed. The files in those directories are actually symbolic links to files in the directory /etc/rc.d/init.d (on Red Hat; /etc/init.d on Debian). Renaming the files in the init.d directory disables all the symbolic links that point to that file. If you only wish to disable a service for a particular run level, rename the appropriate symbolic link by replacing the upper-case S with a lower-case s, like this:


       root#  cd /etc/rc6.d
       root#  mv S45dhcpd s45dhcpd

If you have BSD-style rc files, you will want to check /etc/rc* for programs you don't need.

Most Linux distributions ship with tcp_wrappers "wrapping" all your TCP services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real server. tcpd then checks the host that is requesting the service, and either executes the real server, or denies access from that host. tcpd allows you to restrict access to your TCP services. You should make a /etc/hosts.allow and add in only those hosts that need to have access to your machine's services.

If you are a home dial up user, we suggest you deny ALL. tcpd also logs failed attempts to access services, so this can alert you if you are under attack. If you add new services, you should be sure to configure them to use tcp_wrappers if they are TCP-based. For example, a normal dial-up user can prevent outsiders from connecting to his machine, yet still have the ability to retrieve mail, and make network connections to the Internet. To do this, you might add the following to your /etc/hosts.allow:

ALL: 127.

And of course /etc/hosts.deny would contain:

ALL: ALL

which will prevent external connections to your machine, yet still allow you from the inside to connect to servers on the Internet.

Keep in mind that tcp_wrappers only protects services executed from inetd, and a select few others. There very well may be other services running on your machine. You can use netstat -ta to find a list of all the services your machine is offering.


8.6. SATAN, ISS, and Other Network Scanners

There are a number of different software packages out there that do port and service-based scanning of machines or networks. SATAN, ISS, SAINT, and Nessus are some of the more well-known ones. This software connects to the target machine (or all the target machines on a network) on all the ports they can, and try to determine what service is running there. Based on this information, you can tell if the machine is vulnerable to a specific exploit on that server.

SATAN (Security Administrator's Tool for Analyzing Networks) is a port scanner with a web interface. It can be configured to do light, medium, or strong checks on a machine or a network of machines. It's a good idea to get SATAN and scan your machine or network, and fix the problems it finds. Make sure you get the copy of SATAN from metalab or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. http://www.trouble.org/~zen/satan/satan.html. Note that SATAN has not been updated in quite a while, and some of the other tools below might do a better job.

ISS (Internet Security Scanner) is another port-based scanner. It is faster than Satan, and thus might be better for large networks. However, SATAN tends to provide more information.

Abacus is a suite of tools to provide host-based security and intrusion detection. Look at it's home page on the web for more information. http://www.psionic.com/abacus/

SAINT is a updated version of SATAN. It is web-based and has many more up-to-date tests than SATAN. You can find out more about it at: http://www.wwdsi.com/~saint

Nessus is a free security scanner. It has a GTK graphical interface for ease of use. It is also designed with a very nice plug in setup for new port-scanning tests. For more information, take a look at: http://www.nessus.org


8.7. sendmail, qmail and MTA's

One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs.

If you are using sendmail it is very important to keep up on current versions. sendmail has a long long history of security exploits. Always make sure you are running the most recent version from http://www.sendmail.org.

Keep in mind that sendmail does not have to be running in order for you to send mail. If you are a home user, you can disable sendmail entirely, and simply use your mail client to send mail. You might also choose to remove the "-bd" flag from the sendmail startup file, thereby disabling incoming requests for mail. In other words, you can execute sendmail from your startup script using the following instead:

		# /usr/lib/sendmail -q15m
This will cause sendmail to flush the mail queue every fifteen minutes for any messages that could not be successfully delivered on the first attempt.

Many administrators choose not to use sendmail, and instead choose one of the other mail transport agents. You might consider switching over to qmail. qmail was designed with security in mind from the ground up. It's fast, stable, and secure. Qmail can be found at http://www.qmail.org

In direct competition to qmail is "postfix", written by Wietse Venema, the author of tcp_wrappers and other security tools. Formerly called vmailer, and sponsored by IBM, this is also a mail transport agent written from the ground up with security in mind. You can find more information about postfix at http://www.postfix.org


8.8. Denial of Service Attacks

A "Denial of Service" (DoS) attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to your machine.

Denial of service attacks have increased greatly in recent years. Some of the more popular and recent ones are listed below. Note that new ones show up all the time, so this is just a few examples. Read the Linux security lists and the bugtraq list and archives for more current information.

  • SYN Flooding - SYN flooding is a network denial of service attack. It takes advantage of a "loophole" in the way TCP connections are created. The newer Linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your machine or services. See Section 7 for proper kernel protection options.

  • Pentium "F00F" Bug - It was recently discovered that a series of assembly codes sent to a genuine Intel Pentium processor would reboot the machine. This affects every machine with a Pentium processor (not clones, not Pentium Pro or PII), no matter what operating system it's running. Linux kernels 2.0.32 and up contain a work around for this bug, preventing it from locking your machine. Kernel 2.0.33 has an improved version of the kernel fix, and is suggested over 2.0.32. If you are running on a Pentium, you should upgrade now!

  • Ping Flooding - Ping flooding is a simple brute-force denial of service attack. The attacker sends a "flood" of ICMP packets to your machine. If they are doing this from a host with better bandwidth than yours, your machine will be unable to send anything on the network. A variation on this attack, called "smurfing", sends ICMP packets to a host with your machine's return IP, allowing them to flood you less detectably. You can find more information about the "smurf" attack at http://www.quadrunner.com/~chuegen/smurf.txt

    If you are ever under a ping flood attack, use a tool like tcpdump to determine where the packets are coming from (or appear to be coming from), then contact your provider with this information. Ping floods can most easily be stopped at the router level or by using a firewall.

  • Ping o' Death - The Ping o' Death attack sends ICMP ECHO REQUEST packets that are too large to fit in the kernel data structures intended to store them. Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the "Ping o' Death." This one has long been fixed, and is no longer anything to worry about.

  • Teardrop / New Tear - One of the most recent exploits involves a bug present in the IP fragmentation code on Linux and Windows platforms. It is fixed in kernel version 2.0.33, and does not require selecting any kernel compile-time options to utilize the fix. Linux is apparently not vulnerable to the "newtear" exploit.

You can find code for most exploits, and a more in-depth description of how they work, at http://www.rootshell.com using their search engine.


8.11. Firewalls

Firewalls are a means of controlling what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local LAN, and the only access from your LAN to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your LAN.

There are a number of types of firewalls and methods of setting them up. Linux machines make pretty good firewalls. Firewall code can be built right into 2.0 and higher kernels. The user-space tools ipfwadm for 2.0 kernels and ipchains for 2.2 kernels, allows you to change, on the fly, the types of network traffic you allow. You can also log particular types of network traffic.

Firewalls are a very useful and important technique in securing your network. However, never think that because you have a firewall, you don't need to secure the machines behind it. This is a fatal mistake. Check out the very good Firewall-HOWTO at your latest metalab archive for more information on firewalls and Linux. http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html

More information can also be found in the IP-Masquerade mini-howto: http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html

More information on ipfwadm (the tool that lets you change settings on your firewall, can be found at it's home page: http://www.xos.nl/linux/ipfwadm/

If you have no experience with firewalls, and plan to set up one for more than just a simple security policy, the Firewalls book by O'Reilly and Associates or other online firewall document is mandatory reading. Check out http://www.ora.com for more information. The National Institute of Standards and Technology have put together an excellent document on firewalls. Although dated 1995, it is still quite good. You can find it at http://csrc.nist.gov/nistpubs/800-10/main.html. Also of interest:


8.13. Netfilter - Linux Kernel 2.4.x Firewalling

In yet another set of advancements to the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel.

The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks.


iptables
is the command-line interface used to manipulate the firewall tables within the kernel.

Netfilter provides a raw framework for manipulating packets as they traverse through various parts of the kernel. Part of this framework includes support for masquerading, standard packet filtering, and now more complete network address translation. It even includes improved support for load balancing requests for a particular service among a group of servers behind the firewall.

The stateful inspection features are especially powerful. Stateful inspection provides the ability to track and control the flow of communication passing through the filter. The ability to keep track of state and context information about a session makes rules simpler and tries to interpret higher-level protocols.

Additionally, small modules can be developed to perform additional specific functions, such as passing packets to programs in userspace for processing then reinjecting back into the normal packet flow. The ability to develop these programs in userspace reduces the level of complexity that was previously associated with having to make changes directly at the kernel level.

Other IP Tables references include:


9. Security Preparation (before you go on-line)

Ok, so you have checked over your system, and determined it's as secure as feasible, and you're ready to put it online. There are a few things you should now do in order to prepare for an intrusion, so you can quickly disable the intruder, and get back up and running.


9.5. Keep Track of Your System Accounting Data

It is very important that the information that comes from syslog not be compromised. Making the files in /var/log readable and writable by only a limited number of users is a good start.

Be sure to keep an eye on what gets written there, especially under the auth facility. Multiple login failures, for example, can indicate an attempted break-in.

Where to look for your log file will depend on your distribution. In a Linux system that conforms to the "Linux Filesystem Standard", such as Red Hat, you will want to look in /var/log and check messages, mail.log, and others.

You can find out where your distribution is logging to by looking at your /etc/syslog.conf file. This is the file that tells syslogd (the system logging daemon) where to log various messages.

You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the logrotate package on recent Red Hat distributions. Other distributions likely have a similar process.

If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things appeared to be tampered with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea.

Intruders typically modify log files in order to cover their tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them.

You should also be sure to separate the auth facility from other log data, including attempts to switch users using su, login attempts, and other user accounting information.

If possible, configure syslog to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login/su/ftp/etc attempts. See the syslog.conf man page, and refer to the @ option.

There are several more advanced syslogd programs out there. Take a look at http://www.core-sdi.com/ssyslog/ for Secure Syslog. Secure Syslog allows you to encrypt your syslog entries and make sure no one has tampered with them.

Another syslogd with more features is syslog-ng. It allows you a lot more flexibility in your logging and also can has your remote syslog streams to prevent tampering.

Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what they look like on a normal day. Knowing this can help make unusual things stand out.


10. What To Do During and After a Breakin

So you have followed some of the advice here (or elsewhere) and have detected a break-in? The first thing to do is to remain calm. Hasty actions can cause more harm than the attacker would have.


10.1. Security Compromise Underway.

Spotting a security compromise under way can be a tense undertaking. How you react can have large consequences.

If the compromise you are seeing is a physical one, odds are you have spotted someone who has broken into your home, office or lab. You should notify your local authorities. In a lab, you might have spotted someone trying to open a case or reboot a machine. Depending on your authority and procedures, you might ask them to stop, or contact your local security people.

If you have detected a local user trying to compromise your security, the first thing to do is confirm they are in fact who you think they are. Check the site they are logging in from. Is it the site they normally log in from? No? Then use a non-electronic means of getting in touch. For instance, call them on the phone or walk over to their office/house and talk to them. If they agree that they are on, you can ask them to explain what they were doing or tell them to cease doing it. If they are not on, and have no idea what you are talking about, odds are this incident requires further investigation. Look into such incidents , and have lots of information before making any accusations.

If you have detected a network compromise, the first thing to do (if you are able) is to disconnect your network. If they are connected via modem, unplug the modem cable; if they are connected via Ethernet, unplug the Ethernet cable. This will prevent them from doing any further damage, and they will probably see it as a network problem rather than detection.

If you are unable to disconnect the network (if you have a busy site, or you do not have physical control of your machines), the next best step is to use something like tcp_wrappers or ipfwadm to deny access from the intruder's site.

If you can't deny all people from the same site as the intruder, locking the user's account will have to do. Note that locking an account is not an easy thing. You have to keep in mind .rhosts files, FTP access, and a host of possible backdoors.

After you have done one of the above (disconnected the network, denied access from their site, and/or disabled their account), you need to kill all their user processes and log them off.

You should monitor your site well for the next few minutes, as the attacker will try to get back in. Perhaps using a different account, and/or from a different network address.


10.2. Security Compromise has already happened

So you have either detected a compromise that has already happened or you have detected it and locked (hopefully) the offending attacker out of your system. Now what?


10.2.1. Closing the Hole

If you are able to determine what means the attacker used to get into your system, you should try to close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check and see if there is an updated version, or if any of the lists know of a fix.

Check all your log files, and make a visit to your security lists and pages and see if there are any new common exploits you can fix. You can find Caldera security fixes at http://www.caldera.com/tech-ref/security/. Red Hat has not yet separated their security fixes from bug fixes, but their distribution errata is available at http://www.redhat.com/errata

Debian now has a security mailing list and web page. See: http://www.debian.org/security/ for more information.

It is very likely that if one vendor has released a security update, that most other Linux vendors will as well.

There is now a Linux security auditing project. They are methodically going through all the user-space utilities and looking for possible security exploits and overflows. From their announcement:

""We are attempting a systematic audit of Linux sources with a view to being as secure as OpenBSD. We have already uncovered (and fixed) some problems, but more help is welcome. The list is unmoderated and also a useful resource for general security discussions. The list address is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to: security-audit-subscribe@ferret.lmh.ox.ac.uk""

If you don't lock the attacker out, they will likely be back. Not just back on your machine, but back somewhere on your network. If they were running a packet sniffer, odds are good they have access to other local machines.


11. Security Sources

There are a LOT of good sites out there for Unix security in general and Linux security specifically. It's very important to subscribe to one (or more) of the security mailing lists and keep current on security fixes. Most of these lists are very low volume, and very informative.


11.1. LinuxSecurity.com References

The LinuxSecurity.com web site has numerous Linux and open source security references written by the LinuxSecurity staff and people collectively around the world.

  • Linux Advisory Watch -- A comprehensive newsletter that outlines the security vulnerabilities that have been announced throughout the week. It includes pointers to updated packages and descriptions of each vulnerability.

  • Linux Security Week -- The purpose of this document is to provide our readers with a quick summary of each week's most relevant Linux security headlines.

  • Linux Security Discussion List -- This mailing list is for general security-related questions and comments.

  • Linux Security Newsletters -- Subscription information for all newsletters.

  • comp.os.linux.security FAQ -- Frequently Asked Questions with answers for the comp.os.linux.security newsgroup.

  • Linux Security Documentation -- A great starting point for information pertaining to Linux and Open Source security.


11.2. FTP Sites

CERT is the Computer Emergency Response Team. They often send out alerts of current attacks and fixes. See ftp://ftp.cert.org for more information.

ZEDZ (formerly Replay) (http://www.zedz.net) has archives of many security programs. Since they are outside the US, they don't need to obey US crypto restrictions.

Matt Blaze is the author of CFS and a great security advocate. Matt's archive is available at ftp://ftp.research.att.com/pub/mab

tue.nl is a great security FTP site in the Netherlands. ftp.win.tue.nl


11.3. Web Sites


12. Glossary

Included below are several of the most frequently used terms in computer security. A comprehensive dictionary of computer security terms is available in the LinuxSecurity.com Dictionary


13. Frequently Asked Questions

  1. Is it more secure to compile driver support directly into the kernel, instead of making it a module?

    Answer: Some people think it is better to disable the ability to load device drivers using modules, because an intruder could load a Trojan module or a module that could affect system security.

    However, in order to load modules, you must be root. The module object files are also only writable by root. This means the intruder would need root access to insert a module. If the intruder gains root access, there are more serious things to worry about than whether he will load a module.

    Modules are for dynamically loading support for a particular device that may be infrequently used. On server machines, or firewalls for instance, this is very unlikely to happen. For this reason, it would make more sense to compile support directly into the kernel for machines acting as a server. Modules are also slower than support compiled directly in the kernel.

  2. Why does logging in as root from a remote machine always fail?

    Answer: See Section 4.2. This is done intentionally to prevent remote users from attempting to connect via telnet to your machine as root, which is a serious security vulnerability, because then the root password would be transmitted, in clear text, across the network. Don't forget: potential intruders have time on their side, and can run automated programs to find your password. Additionally, this is done to keep a clear record of who logged in, not just root.

  3. How do I enable shadow passwords on my Linux box?

    Answer:

    To enable shadow passwords, run pwconv as root, and /etc/shadow should now exist, and be used by applications. If you are using RH 4.2 or above, the PAM modules will automatically adapt to the change from using normal /etc/passwd to shadow passwords without any other change.

    Some background: shadow passwords is a mechanism for storing your password in a file other than the normal /etc/passwd file. This has several advantages. The first one is that the shadow file, /etc/shadow, is only readable by root, unlike /etc/passwd, which must remain readable by everyone. The other advantage is that as the administrator, you can enable or disable accounts without everyone knowing the status of other users' accounts.

    The /etc/passwd file is then used to store user and group names, used by programs like /bin/ls to map the user ID to the proper user name in a directory listing.

    The /etc/shadow file then only contains the user name and his/her password, and perhaps accounting information, like when the account expires, etc.

    To enable shadow passwords, run pwconv as root, and /etc/shadow should now exist, and be used by applications. Since you are using RH 4.2 or above, the PAM modules will automatically adapt to the change from using normal /etc/passwd to shadow passwords without any other change.

    Since you're interested in securing your passwords, perhaps you would also be interested in generating good passwords to begin with. For this you can use the pam_cracklib module, which is part of PAM. It runs your password against the Crack libraries to help you decide if it is too-easily guessable by password-cracking programs.

  4. How can I enable the Apache SSL extensions?

    Answer:

    1. Get SSLeay 0.8.0 or later from

    2. Build and test and install it!

    3. Get Apache source

    4. Get Apache SSLeay extensions from here

    5. Unpack it in the apache source directory and patch Apache as per the README.

    6. Configure and build it.

    You might also try ZEDZ net which has many pre-built packages, and is located outside of the United States.

  5. How can I manipulate user accounts, and still retain security?

    Answer: most distributions contain a great number of tools to change the properties of user accounts.

    • The pwconv and unpwconv programs can be used to convert between shadow and non-shadowed passwords.

    • The pwck and grpck programs can be used to verify proper organization of the passwd and group files.

    • The useradd, usermod, and userdel programs can be used to add, delete and modify user accounts. The groupadd, groupmod, and groupdel programs will do the same for groups.

    • Group passwords can be created using gpasswd.

    All these programs are "shadow-aware" -- that is, if you enable shadow they will use /etc/shadow for password information, otherwise they won't.

    See the respective man pages for further information.

  6. How can I password-protect specific HTML documents using Apache?

    I bet you didn't know about http://www.apacheweek.org, did you?

    You can find information on user authentication at http://www.apacheweek.com/features/userauth as well as other web server security tips from http://www.apache.org/docs/misc/security_tips.html


14. Conclusion

By subscribing to the security alert mailing lists, and keeping current, you can do a lot towards securing your machine. If you pay attention to your log files and run something like tripwire regularly, you can do even more.

A reasonable level of computer security is not difficult to maintain on a home machine. More effort is required on business machines, but Linux can indeed be a secure platform. Due to the nature of Linux development, security fixes often come out much faster than they do on commercial operating systems, making Linux an ideal platform when security is a requirement.


15. Acknowledgments

Information here is collected from many sources. Thanks to the following who either indirectly or directly have contributed:


Rob Riggs
rob@DevilsThumb.com

S. Coffin scoffin@netcom.com

Viktor Przebinda viktor@CRYSTAL.MATH.ou.edu

Roelof Osinga roelof@eboa.com

Kyle Hasselbacher kyle@carefree.quux.soltc.net

David S. Jackson dsj@dsj.net

Todd G. Ruskell ruskell@boulder.nist.gov

Rogier Wolff R.E.Wolff@BitWizard.nl

Antonomasia ant@notatla.demon.co.uk

Nic Bellamy sky@wibble.net

Eric Hanchrow offby1@blarg.net

Robert J. Bergerrberger@ibd.com

Ulrich Alpers lurchi@cdrom.uni-stuttgart.de

David Noha dave@c-c-s.com

Pavel Epifanov. epv@ibm.net

Joe Germuska. joe@germuska.com

Franklin S. Werren fswerren@bagpipes.net

Paul Rusty Russell <Paul.Russell@rustcorp.com.au>

Christine Gaunt <cgaunt@umich.edu>

lin bhewitt@refmntutl01.afsc.noaa.gov

A. Steinmetz astmail@yahoo.com

Jun Morimoto morimoto@xantia.citroen.org

Xiaotian Sun sunx@newton.me.berkeley.edu

Eric Hanchrow offby1@blarg.net

Camille Begnis camille@mandrakesoft.com

Neil D neild@sympatico.ca

Michael Tandy Michael.Tandy@BTInternet.com

Tony Foiani tkil@scrye.com

Matt Johnston mattj@flashmail.com

Geoff Billin gbillin@turbonet.com

Hal Burgiss hburgiss@bellsouth.net

Ian Macdonald ian@linuxcare.com

M.Kiesel m.kiesel@iname.com

Mario Kratzer kratzer@mathematik.uni-marburg.de

Othmar Pasteka pasteka@kabsi.at

Robert M rom@romab.com

Cinnamon Lowe clowe@cinci.rr.com

Gunnar Ritter g-r@bigfoot.de

The following have translated this HOWTO into various other languages!

A special thank you to all of them for help spreading the Linux word...

Polish: Ziemek Borowski ziembor@FAQ-bot.ZiemBor.Waw.PL

Japanese: FUJIWARA Teruyoshi fjwr@mtj.biglobe.ne.jp

Indonesian: Tedi Heriyanto 22941219@students.ukdw.ac.id

Korean: Bume Chang Boxcar0001@aol.com

Spanish: Juan Carlos Fernandez piwiman@visionnetware.com

Dutch: "Nine Matthijssen" nine@matthijssen.nl

Norwegian: ketil@vestby.com ketil@vestby.com

Turkish: tufan karadere tufank@metu.edu.tr