6. Password Security and
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
You can go to https://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: https://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
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
See the GNU Privacy Guard web page for more information: https://www.gnupg.org/.
More information on cryptography can be found in the RSA cryptography FAQ,
available at https://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.
SSL: - SSL, or Secure Sockets Layer, is an encryption method
developed by Netscape to provide security over the Internet. It supports
several different encryption protocols, and provides client and server
authentication. SSL operates at the transport layer, creates a secure
encrypted channel of data, and thus can seamlessly encrypt data of many types.
This is most commonly seen when going to a secure site to view a secure online
document with Communicator, and serves as the basis for secure communications
with Communicator, as well as many other Netscape Communications data
encryption. More information can be found at https://www.consensus.com/security/ssl-talk-faq.html.
Information on Netscape's other security implementations, and a good starting
point for these protocols is available at https://home.netscape.com/info/security-doc.html. It's also
worth noting that the SSL protocol can be used to pass many other common
protocols, "wrapping" them for security. See https://www.quiltaholic.com/rickk/sslwrap/
S-HTTP: - S-HTTP is another protocol that provides security
services across the Internet. It was designed to provide confidentiality,
authentication, integrity, and non-repudiability [cannot be mistaken for
someone else] while supporting multiple key-management mechanisms and
cryptographic algorithms via option negotiation between the parties involved
in each transaction. S-HTTP is limited to the specific software that is
implementing it, and encrypts each message individually. [ From RSA
Cryptography FAQ, page 138]
S/MIME: - S/MIME, or Secure Multipurpose Internet Mail Extension,
is an encryption standard used to encrypt electronic mail and other types of
messages on the Internet. It is an open standard developed by RSA, so it is
likely we will see it on Linux one day soon. More information on S/MIME can be
found at https://home.netscape.com/assist/security/smime/overview.html.
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 https://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 https://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 https://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)
ssh and stelnet are suites of
programs that allow you to login to remote systems and have a encrypted
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
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 https://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: https://www.openssh.com/.
There is also a open source project to re-implement ssh from the ground up
called "psst...". For more information see: https://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 https://guardian.htu.tuwien.ac.at/therapy/ssh/ as well as a
commercial implementation from DataFellows, at https://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 https://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 https://www-cs-students.stanford.edu/~tjw/srp/
6.5. PAM - Pluggable Authentication
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. https://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
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
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
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
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
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...)
Further information can be found at https://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 https://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.]
Kerberos should not be your first step in improving security of your host. It
is quite involved, and not as widely used as, say, SSH.
6.8. Shadow Passwords.
Shadow passwords are a means of keeping your encrypted password information
secret from normal users. Recent versions of both Red Hat and Debian Linux use
shadow passwords by default, but on other systems, 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 https://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html It
is rather dated now, and will not be required for distributions supporting PAM.
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
There are a number of programs out there...the two most notable of which are
"Crack" and "John the Ripper" (https://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
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 https://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 https://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: https://www.tcfs.it/.
It also need not be used on entire file systems. It works on directory trees
6.11. X11, SVGA and display security
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 https://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.
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.
6.11.3. GGI (Generic Graphics Interface
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. https://synergy.caltech.edu/~ggi/