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://www.linuxsecurity.com/content/view/117260/50/
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.
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.
More information on cryptography can be found in the RSA Cryptography FAQ.
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.
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 the SSL
Talk Mailing List FAQ. Information on Netscape's other
security implementations, and a good starting point for these
protocols is available at The SSL
Protocol. 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 the Mozilla
Open Source Crypto Libraries list.
IPsec is a suite of protocols designed to provide secure
communications over insecure networks. As defined by Wikipedia:
IPsec (IP security) is a standard for securing Internet
Protocol (IP) communications by encrypting and/or authenticating all IP
packets. IPsec provides security at the network layer. IPsec is a set of
cryptographic protocols for (1) securing packet flows and (2) key
exchange. Of the former, there are two: Encapsulating Security Payload
(ESP) provides authentication, data confidentiality and message
integrity; Authentication Header (AH) provides authentication and
message integrity, but does not offer confidentiality. Originally AH was
only used for integrity and ESP was used only for encryption;
authentication functionality was added subsequently to ESP. Currently
only one key exchange protocol is defined, the IKE (Internet Key
Exchange) protocol.
Probably the most common IPsec implementation for Linux is FreeS/WAN
although it has recently been replaced with OpenS/WAN. Installing an IPsec
implementation on Linux is easier than it used to be, but configuring it
still requires a pretty thorough understanding of the technology and is
beyond the scope of this HOWTO. Most applications calling for some sort
of encrypted tunnel can usually implement OpenSSH instead, as it's much
easier to configure, and recent versions include real tunneling where
previously only port forwarding was possible.
OpenSSH, the most common and most developed implementation of the
Secure Shell (ssh) protocol for Linux, is a suite of programs that allow
you to login over unsecured links (like the Internet) to remote systems
using an encrypted connection. Most Linux users now know that using
telnet is simply unacceptible, but ensuring ssh is configured properly
is also equally important. The EnGarde Secure Linux platform
doesn't even include a telnet daemon, and includes an easy way to
configure properly an ssh daemon.
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.
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 the OpenSSH Home
Page. Read a near-complete list of features on the OpenSSH Features List
page.
You can also use ssh from your
Windows workstation to your Linux ssh
server. There are several freely available Windows client
implementations, including PuTTY,
probably the most common one.
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
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.
Cryptographic IP
Encapsulation 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."
CIPE is no longer actively developed and alternatives should first
be considered before implementing.
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/.
It is important that you have an understanding of what Kerberos
actually is, but in order to implement it requires that the particular
application be compiled against the necessary Kerberos libraries.
Applications and protocols including OpenSSH, PAM, X11, NIS and others
that require advanced authentication typically already have Kerberos
support available.
Kerberos should not be your first step in improving security of
your host. It is quite involved, and not as widely used as, say,
standard password authentication methods available in SSH.
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 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.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.
Creating an encrypted container to store critcally important files
on your Linux machine is quite compelling. Generally this is done in the
form of a file that is mounted as a filesystem, only after having been
provided a password to decrypt its contents. When unmounted, the
filesystem is automatically encrypted again.
In the past, this was done using CFS or TCFS although they have
not been maintained in quite some time. The EncFS project is keeping
encrypted filesystems alive in Linux, and describes itself as:
EncFS provides an encrypted filesystem in user-space. It
runs without any special permissions and uses the FUSE library and Linux
kernel module to provide the filesystem interface. You can find links to
source and binary releases below. EncFS is open source software,
licensed under the GPL.
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.
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.
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/