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.

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.

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 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.

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 http://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 http://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
http://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 http://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 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.""

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.

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!" "

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:

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."

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

6.7. Kerberos

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.

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 http://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 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

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.

6.11.2. SVGA

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 project)

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/