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 Unixes (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 unices 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 below) 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 go to http://consult.cern.ch/writeup/security/security_3.html for information on how to choose a good password.
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: as 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 working on 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 nearly in compliance with RFC2440 (OpenPGP). See the GNU Privacy Guard web page for more information: http://www.gpg.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.
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.
Along with CIPE, and other forms of data encryption, there is also an implementation 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 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.
As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.
ssh (Secure Shell) and stelnet
ssh and stelnet are programs that allow you to login
to remote systems and have a encrypted connection.
ssh 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. The ssh
home page can be found at
http://www.cs.hut.fi/ssh/
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. There is also a open source
project to re-implement ssh called "psst...". For more information
see:
http://www.net.lut.ac.uk/psst/
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 SRP's home page.
Newer versions of the Red Hat Linux distribution 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:
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
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.
Kerberos is an authentication system developed by the Athena Project at MIT. When a user logs in, Kerberos authenticates that user (using a password), and provides the user with a way to prove her identity to other servers and hosts scattered around the network.
This authentication is then used by programs such as rlogin to allow
the user to login to other hosts without a password (in place of the
.rhosts file). This authentication method can also used by the mail
system in order to guarantee that mail is delivered to the correct
person, as well as to guarantee that the sender is who he claims to
be.
Kerberos and the other programs that come with it, prevent users from "spoofing" the system into believing they are someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification or replacement of numerous standard programs.
You can find more information about kerberos by looking at the kerberos FAQ, and the code can be found at http://nii.isi.edu/info/kerberos/.
[From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]
Shadow passwords are a means of keeping your encrypted password
information secret from normal users. Normally, this encrypted passwords
are stored in /etc/passwd file for all to read. Anyone can then run
password guesser programs on them and attempt to determine what they are.
Shadow passwords, by contrast, are saved in /etc/shadow, which
only privileged users can read. In order to use shadow passwords, you
need to make sure all your utilities that need access to password
information are recompiled to support them. PAM (above) also allows you
to just plug in a shadow module; it doesn't require re-compilation of
executables. You can refer to the Shadow-Password HOWTO for further
information if necessary. It is available at
http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html
It is rather dated now, and will not be required for distributions
supporting PAM.
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.false.com/security/john/index.html) . 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.
CFS is a way of encrypting an entire directory trees and allowing users to store encrypted files on them. It uses a NFS server running on the local machine. RPMS are available at http://www.replay.com/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://edu-gw.dia.unisa.it/tcfs/.
It also need not be used on entire filesystems. It works on directories trees as well.
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 what hosts 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
ssh
, 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.
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 with to run X programs.
SVGAlib programs are typically SUID-root in order to access all your Linux machine's video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all.
The Linux GGI project is trying to solve several of the problems with
video interfaces on Linux. GGI will move a small piece of the video
code into the Linux kernel, and then control access to the video
system. This means GGI will be able to restore your console at any
time to a known good state. They will also allow a secure attention
key, so you can be sure that there is no Trojan horse login program
running on your console.
http://synergy.caltech.edu/~ggi/