A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

Part VI: Appendixes

C. Security Including GPG

In This Appendix


File Security

Email Security

Network Security

Host Security

Login Security

Remote Access Security

Viruses and Worms

Physical Security

Tutorial: Using GPG to Secure a File

Security Resources

Security is a major part of the foundation of any system that is not totally cut off from other machines and users. Some aspects of security have a place even on isolated machines. Examples of these measures include periodic system backups, BIOS or power-on passwords, and self-locking screensavers.

A system that is connected to the outside world requires other mechanisms to secure it: tools to check files (tripwire), audit tools (tiger/cops), secure access methods (kerberos/ssh), services that monitor logs and machine states (swatch/watcher), packet-filtering and routing tools (ipfwadm/iptables), and more.

System security has many dimensions. The security of a system as a whole depends on the security of individual components, such as email, files, network, login, and remote access policies, as well as the physical security of the host itself. These dimensions frequently overlap, and their borders are not always static or clear. For instance, email security is affected by the security of both files and the network. If the medium (the network) over which you send and receive your email is not secure, then you must take extra steps to ensure the security of your messages. If you save your secure email in a file on the local system, then you rely on the filesystem and host access policies for file security. A failure in any one of these areas can start a domino effect, diminishing reliability and integrity in other areas and potentially compromising system security as a whole.

This short appendix cannot cover all facets of system security in depth, but it does provide an overview of the complexity of setting up and maintaining a secure system. This appendix offers some specifics, concepts, guidelines to consider, and many pointers to security resources (Table C-1on page 1180).

Security: Other sources of system security information

Depending on how important system security is to you, you might want to purchase one or more books dedicated to system security, visit some of the Internet sites that are dedicated to security, or hire someone who is an expert in the field.

Do not rely on this appendix as your sole source of information on system security.


One of the building blocks of security is encryption, which provides a means of scrambling data for secure transmission to other parties. In cryptographic terms, the data or message to be encrypted is referred to as plaintext, and the resulting encrypted block of text as ciphertext. Processes exist for converting plaintext into ciphertext through the use of keys, which are essentially random numbers of a specified length used to lock and unlock data. This conversion is achieved by applying the keys to the plaintext according to a set of mathematical instructions, referred to as theencryption algorithm.

Developing and analyzing strong encryption software is extremely difficult. Many nuances exist, many standards govern encryption algorithms, and a background in mathematics is requisite. Also, unless an algorithm has undergone public scrutiny for a significant period of time, it is generally not considered secure; it is often impossible to know an algorithm is completely secure but possible to know that it is not secure. Ultimately time is the best test of any algorithm. Also, a solid algorithm does not guarantee an effective encryption mechanism because the fallibility of an encryption scheme frequently arises from problems with its implementation and distribution.

An encryption algorithm uses a key that is a certain number of bits long. Each bit added to the length of a key effectively doubles the key space (the number of combinations allowed by the number of bits in the key—2 to the power of the length of the key in bits1) and means it will take twice as long for an attacker to decrypt a message (assuming the scheme lacks any inherent weaknesses or vulnerabilities to exploit). However, it is a mistake to compare algorithms based only on the number of bits used. In some cases an algorithm that uses a 64-bit key can be more secure than an algorithm that uses a 128-bit key.

1. A 2-bit key would have a key space of 4 (22), a 3-bit key would have a key space of 8 (23), and so on.

The two primary classifications of encryption schemes are public key encryption and symmetric key encryption. Public key encryption, also called asymmetric encryption, uses two keys: a public key and a private key. These keys are uniquely associated with a specific user. Public key encryption schemes are used mostly to exchange keys and signatures. Symmetric key encryption, also called symmetric encryption or secret key encryption, uses one key that you and the person you are communicating with (hereafter referred to as your friend) share as a secret. Symmetric key encryption is typically used to encrypt large amounts of data because it is fast. Public key algorithm keys typically have a length of 512 bits to 2,048 bits, whereas symmetric key algorithms use keys in the range of 64 bits to 512 bits.

Asymmetric and symmetric algorithms complement each other. Asymmetric algorithms are good at providing digital signatures and authentication, but are slower. Symmetric algorithms are good at encrypting large blocks of data using a shared key and are faster. The algorithms are often combined to provide the best of both worlds: Text can first be processed using symmetric encryption and a random key. Then the random key can be encrypted using your friend’s public key (so your friend can read it) and signed with your private key (to prove it came from you). The next sections cover these concepts in detail.

When you are choosing an encryption scheme, realize that security comes at a price. There is usually a tradeoff between resilience of the cryptosystem and ease of administration.

The practicality of a security solution is a far greater factor in encryption, and in security in general, than most people realize. With enough time and effort, nearly every algorithm can be broken. In fact, you can often unearth the mathematical instructions for a widely used algorithm by flipping through a cryptography book, reviewing a vendor’s product specifications, or performing a quick search on the Internet. The challenge is to ensure the effort required to follow the twists and turns taken by an encryption algorithm and its resulting encryption solution outweighs the worth of the information it is protecting.

Tip: How much time and money should you spend on encryption?

When the cost of obtaining the information exceeds the value realized by its possession, the solution is an effective one.

Public Key (Asymmetric) Encryption

To use public key encryption, you must generate two keys: a public key and a private key. You keep the private key for yourself and give the public key to the world. In a similar manner, each of your friends will generate a pair of keys and give you their public keys. Public key encryption is marked by two distinct features:

1. When you encrypt data with someone’s public key, only that person’s private key can decrypt it.

2. When you encrypt data with your private key, anyone can decrypt it with your public key.

You might wonder why the second point is useful: Why would you want everyone else to be able to decrypt something you just encrypted? The answer lies in the purpose of the encryption. Although encryption changes the original message into unreadable ciphertext, its purpose is to provide a digital signature. If the message can be properly decrypted with your public key, only you could have encrypted it with your private key, proving the message is authentic. Combining these two modes of operation yields privacy and authenticity. You can sign a message with your private key so it can be verified as authentic, and then you can encrypt it with your friend’s public key so that only your friend can decrypt it.

Public key encryption has three major shortcomings:

1. Public key encryption algorithms are generally much slower than symmetric key algorithms and usually require a much larger key size and a way to generate large prime numbers2 to use as components of the key, making them more resource intensive.

2. In particular, RSA public key encryption is based on the property that if you take two large prime numbers and multiply them together you get a much larger number. Identifying the factors of this number is a very difficult computational problem. When you keep one prime number and give away the other, the numbers act like a private key and public key.

2. The private key must be stored securely and its integrity safeguarded. If a person’s private key is obtained by another party, that party can encrypt, decrypt, and sign messages while impersonating the original owner of the key. If the private key is lost or becomes corrupted, any messages previously encrypted with it are also lost, and a new key pair must be generated.

3. It is difficult to authenticate the origin of a key—that is, to prove whom it originally came from. This so-called key-distribution problem is the raison d’être for such companies as VeriSign (www.verisign.com).

Algorithms such as RSA, Diffie-Hellman, and ElGamal implement public key encryption methodology. Today a 512-bit key is considered barely adequate for RSA encryption and offers marginal protection; 1,024-bit keys are expected to hold off determined attackers for several more years. Keys that are 2,048 bits long are now becoming commonplace and are rated as espionage strength. A mathematical paper published in late 2001 and reexamined in spring 2002 describes how a machine can be built—for a very large sum of money—that could break 1,024-bit RSA encryption in seconds to minutes (this point is debated in an article at www.schneier.com/crypto-gram-0203.html#6). Although the cost of such a machine exceeds the resources available to most individuals and smaller corporations, it is well within the reach of large corporations and governments. Since the publication of that paper, subsequent algorithmic and hardware improvements have led to designs of machines that can be built for around $10,000.

Symmetric Key Encryption

Symmetric key encryption is generally fast and simple to deploy. First you and your friend agree on which algorithm to use and a key you will share. Then either of you can decrypt or encrypt a file with the chosen key. Behind the scenes, symmetric key encryption algorithms are most often implemented as a network of black boxes, which can involve hardware components, software, or a combination of the two. Each box imposes a reversible transformation on the plaintext and passes it to the next box, where another reversible transformation further alters the data. The security of a symmetric key algorithm relies on the difficulty of determining which boxes were used and the number of times the data was fed through the set of boxes. A good algorithm will cycle the plaintext through a given set of boxes many times before yielding the result, and there will be no obvious mapping from plaintext to ciphertext.

The disadvantage of symmetric key encryption is that it depends heavily on the availability of a secure channel through which to send the key to your friend. For example, you would not use email to send your key; if your email is intercepted, a third party is in possession of your secret key, and your encryption is useless. You could relay the key over the phone, but your call could be intercepted if your phone were tapped or someone overheard your conversation.

Common implementations of symmetric key algorithms include DES (Data Encryption Standard), 3-DES (triple DES), IDEA, RC5, Blowfish, and AES (Advanced Encryption Standard). AES is the new (FIPS-197) Federal Information Processing Standard algorithm endorsed for governmental use and has been selected to replace DES as the de facto encryption algorithm. AES uses the Rijndael algorithm, chosen after a thorough evaluation of 15 candidate algorithms by the cryptographic research community.

None of the aforementioned algorithms has undergone more scrutiny than DES, which has been in use since the late 1970s. However, the use of DES has drawbacks and is no longer considered secure because the weakness of its 56-bit key makes it unreasonably easy to break. Given the advances in computing power and speed since DES was developed, the small size of this algorithm’s key renders it inadequate for operations requiring more than basic security for a relatively short period of time. For a few thousand dollars, you can link off-the-shelf computer systems so they can crack DES keys in a few hours.

The 3-DES application of DES is intended to combat its degenerating resilience by running the encryption three times; it is projected to be secure for years to come. DES is probably sufficient for such tasks as sending email to a friend when you need it to be confidential or secure for only a few days (e.g., to send a notice of a meeting that will take place in a few hours). It is unlikely anyone is sufficiently interested in your email to invest the time and money to decrypt it. Because of 3-DES’s wide availability and ease of use, it is advisable to use it instead of DES.

Encryption Implementation

Most of today’s commercial software packages use both public and symmetric key encryption algorithms, taking advantage of the strengths of each and avoiding their weaknesses. The public key algorithm is used first, as a means of negotiating a randomly generated secret key and providing for message authenticity. Then a secret key algorithm, such as 3-DES, IDEA, AES, or Blowfish, encrypts and decrypts the data on both ends for speed. Finally a hash algorithm, such as DSA (Digital Signature Algorithm), generates a message digest that provides a signature that can alert you to tampering. The digest is digitally signed with the sender’s private key.


The most popular personal encryption packages available today are GPG (GNU Privacy Guard, also called GnuPG; www.gnupg.org) and PGP (Pretty Good Privacy; www.symantec.com/business/theme.jsp?themeid=pgp). GPG was designed as a free replacement for PGP, a security tool that made its debut during the early 1990s. Phil Zimmerman developed PGP as a PKI (Public Key Infrastructure), featuring a convenient interface, ease of use and management, and the security of digital certificates. One critical characteristic set PGP apart from the majority of cryptosystems then available: PGP functions entirely without CAs (certification authorities). Until the introduction of PGP, PKI implementations were built around the concept of CAs and centralized key management controls. See page 1169 for a tutorial on using PGP.

Both PGP and GPG rely on the notion of a web of trust:3 If you trust someone and that person trusts someone else, the person you trust can provide an introduction to the third party. When you trust someone, you perform an operation called key signing. By signing someone else’s key, you verify that the person’s public key is authentic and safe for you to use to send email. When you sign a key, you are asked whether you trust this person to introduce other keys to you. It is common practice to assign this trust based on several criteria, including your knowledge of a person’s character or a lasting professional relationship with the person. The best practice is to sign someone’s key only after you have met face to face to avert any chance of a man-in-the-middle scenario (see the adjacent tip). The disadvantage of this scheme is the lack of a central registry for associating with people you do not already know.

3. For more information see www.gnupg.org/gph/en/manual/x334.html.

Security: MTM (man-in-the-middle) attack

If Max and Zach try to carry on a secure email exchange over a network, Max first sends Zach his public key. However, suppose Mr. X sits between Max and Zach on the network and intercepts Max’s public key. Mr. X then sends his public key to Zach. Zach then sends his public key to Max, but once again Mr. X intercepts it and substitutes his public key and sends that to Max. Without some kind of active protection (a piece of shared information), Mr. X, the man in the middle, can decrypt all traffic between Max and Zach, reencrypt it, and send it on to the other party. This type of deception is called a MTM attack.

Symantec owns PGP. Although it is available without cost for personal use, its deployment in a commercial environment requires the purchase of a license. GnuPG is a free and compatible implementation of PGP.

GnuPG supports most features and implementations made available by PGP and complies with the OpenPGP Message Format standard. Because GnuPG does not use the patented IDEA algorithm but rather relies on BUGS (Big and Useful Great Security; www.gnu.org/directory/bugs.html), you can use it almost without restriction: It is released under the GNU GPL (refer to “The Code Is Free” on page 5). PGP and GnuPG are considered to be interchangeable and interoperable. The command sequences for and internal workings of these two tools are very similar.

Tip: The GnuPG system includes the gpg program

GnuPG is frequently referred to as gpg, but gpg is the name of the main program for the GnuPG system.

File Security

From an end user’s perspective, file security is one of the most critical areas of security. Some file security is built into Linux: chmod (page 193) gives you basic security control. ACLs (Access Control Lists) allow more fine-grained control of file access permissions. ACLs are part of Solaris, Windows NT/2000/XP, VAX/VMS, and mainframe operating systems. Fedora/RHEL supports ACLs (page 198). Even these tools are insufficient, however, when your account is compromised (e.g., by someone watching your fingers on the keyboard as you type your password). To provide maximum file security, you must encrypt your files. Then even someone who knows your login password cannot read your files. Of course, if someone knows your key, that person can decrypt your files if she can get to them.

Email Security

Email security overlaps file security and, as discussed later, network security. GnuPG is the tool most frequently used for email security, although you can also use PGP.

MTAs (Mail Transfer Agents)

An increasingly common protocol option is STARTTLS (Start Transport Layer Security; www.sendmail.org/~ca/email/starttls.html). TLS itself usually refers to SSL (Secure Sockets Layer) and has become the de facto method for encrypting TCP/IP traffic on the Internet. The sendmail(Chapter 20) and exim4 daemons fully support STARTTLS, and much documentation exists on how to configure them. STARTTLS enhancements are also available for Qmail (page 742) and Postfix (page 742) and other popular MTAs (mail transfer agents). This capability provides encryption between two mail servers but not necessarily between the local system and the mail server. Also, the advantages of using TLS are negated if the email must pass through a relay that does not support TLS.

MUAs (Mail User Agents)

Many popular mail user agents, such as mutt, elm, Thunderbird, and emacs, include the ability to use PGP or GnuPG for encryption. Evolution, the default Fedora/RHEL MUA (mail user agent), has built-in GnuPG support. This approach has become the default way to exchange email securely.

Network Security

Network security is a vital component for ensuring the security of a computing site. However, without the right infrastructure, providing network security is difficult, if not impossible. For example, if you run a shared network topology,4 such as wireless, without the latest security implementation to prevent snooping, how can you prevent someone from plugging in a machine and capturing all the packets (page 1265) that traverse the network?5 You cannot—so you have a potential security hole. Another common security hole relates to the use of telnet for logins. Because telnet sends and receives cleartext, anyone “listening in” on the line can easily capture usernames and passwords, compromising security. Fortunately, this problem is serious only for legacy devices that support only telnet.

4. Shared network topology: A network in which each packet might be seen by machines other than its destination. “Shared” means that the network bandwidth is shared by all users.

5. Do not make the mistake of assuming the local network is secure just because you have a switch. Switches are designed to allocate bandwidth, not to guarantee security.

Do not allow any unauthenticated PC (any PC that does not require users to supply a local name and password) on a network. On UNIX/Linux, only a user working with root privileges can put the network interface in promiscuous mode and collect packets. On UNIX/Linux, ports numbered less than 1,0246 are privileged—that is, normal user protocols cannot bind to these ports. This is an important but regrettable means of security for some protocols, such as NIS, NFS, RSH, and LPD. Normally a data switch on a LAN automatically protects machines from people snooping on the network for data. In high-load situations, switches have been known to behave unpredictably, directing packets to the wrong ports. Certain programs can overload the switch tables that hold information about which machine is on which port. When these tables are overloaded, the switch becomes a repeater and broadcasts all packets to all ports. An attacker on the same switch as you can potentially see the traffic the local system sends and receives.

6. The term port has many meanings; here it is a number assigned to a program. This number links incoming data with a specific service. For example, port 21 is used by FTP traffic, and port 23 is used by TELNET.

Network Security Solutions

One solution to shared-network problems is to encrypt messages that travel between machines. IPSec (Internet Protocol Security) provides an appropriate technology. IPSec is commonly used to establish a secure point-to-point virtual network (VPN, page 1280) that allows two hosts to communicate securely over an unsecure channel, such as the Internet. This protocol provides integrity, confidentiality, authenticity, and flexibility of implementation that supports multiple vendors.

IPSec is an amalgamation of protocols (IPSec = AH + ESP + IPComp + IKE):

• AH (Authentication Header)—A cryptographically secure, irreversible checksum (page 1242) for an entire packet. AH guarantees that the packet is authentic.

• ESP (Encapsulating Security Payload)—Encrypts a packet to make the data unreadable.

• IPComp (IP Payload Compression)—Compresses a packet. Encryption can increase the size of a packet, and IPComp counteracts this increase in size.

• IKE (Internet Key Exchange)—Provides a way for the endpoints to negotiate a common key securely. For AH to work, both ends of the exchange must use the same key to prevent a “man in the middle” (see the tip on page 1160) from spoofing the connection.

While IPSec is an optional part of IPv4, IPv6 (page 293) mandates its use.

Network Security Guidelines

The following list of general guidelines for establishing and maintaining a secure system is not a complete list, but rather is meant as a guide.

• Fiberoptic cable is more secure than copper cable. Copper is subject to both active and passive eavesdropping. With access to copper cable, all a data thief needs to monitor your network traffic is a passive device for measuring magnetic fields. In contrast, it is much more difficult to tap a fiberoptic cable without interrupting the signal. Sites requiring top security keep fiberoptic cable in pressurized conduits, where a change in pressure signals that the physical security of the cable has been breached.

• Avoid leaving unused ports available in public areas. If a malicious user can plug a laptop into the network without being detected, you are at risk of a serious security problem. Network drops that will remain unused for extended periods should be disabled at the switch, preventing them from accepting or passing network traffic.

• Use the latest in wireless encryption. At the time of this writing, WEP is totally broken and WPA with TKIP is seriously flawed. WPA2 with AES is generally believed to be relatively secure.

• Many network switches have provisions for binding a hardware address to a port for enhanced security. If someone unplugs one machine and plugs in another machine to capture traffic, chances are that the second machine will have a different hardware address. When it detects a device with a different hardware address, the switch can disable the port. Even this solution is no guarantee, however, as some programs enable you to change or mask the hardware address of a network interface. This setup can be inconvenient when you need to swap out a machine for repair.

Security: Install a small kernel and run only the programs you need

Linux systems contain a huge number of programs that, although useful, significantly reduce the security of the host. Install the smallest operating system kernel that meets your needs. For servers, install only the needed components and do not install a graphical interface. Fewer packages mean fewer urgent security patches. Users might require additional packages.

• Do not allow NFSv3 or NIS access outside the local network. Otherwise, it is a simple matter for a malicious user to steal the password map. Default NFSv3 security is marginal to nonexistent (a common joke is that NFS stands for No File Security or Nightmare File System) so such access should not be allowed outside your network to machines you do not trust. Versions of NFS for Linux that support much better authentication algorithms are available. Use IPSec, NFSv4 (which includes improved authentication), or firewalls to provide access outside of the local domain. Kerberos, when combined with NFSv4 or NFSv3 provides very good security, but configuring Kerberos requires a book unto itself.

• Support for VPN configuration is often built into new firewalls or provided as a separate product, enabling your system to join securely with the systems of your customers or partners. If you must allow business partners, contractors, or other outside parties to access local files, consider using a secure filesystem, such as NFS with Kerberos (page 1257), secure NFS (encrypts authentication, not traffic), NFS over a VPN such as IPSec, or cfs (cryptographic filesystem).

• Specify /usr as readonly (ro) in /etc/fstab. Following is an example of such a configuration:

/dev/sda6      /usr      ext2     ro    0   0

This approach is not suitable for all operating systems, or even all Linux distributions. Some applications put changeable files in /usr. Also, this setup entrenches security flaws and makes the system difficult to update.

• Mount filesystems other than / and /usr nosuid to prevent setuid programs from executing on this filesystem. For example:

/dev/sda4      /var        ext4    nosuid   0   0
/dev/sda5      /usr/local  ext4    nosuid   0   0

• Use a barrier or firewall product between the local network and the Internet. Several valuable mailing lists cover firewalls, including the free firewalls Web site (www.freefire.org). Fedora/RHEL includes firewall-config (page 900) and iptables (page 908), which allow you to set up a firewall.

• Use a program that checks file integrity. Some examples are tripwire, samhain, and AIDE. These tools include a database of checksums of files you want to monitor and alert you when any of the monitored files change.

Host Security

Your host must be secure. Simple security steps include preventing remote logins and leaving the /etc/hosts.equiv and individual users’ ~/.rhosts files empty (or not having them at all). Complex security steps include installing IPSec for VPNs between hosts. Many other security measures, some of which are discussed in this section, fall somewhere between these extremes. See Table C-1 on page 1180 for relevant URLs.

• Although potentially tricky to implement and manage, IDSs (intrusion detection systems) are an excellent way to keep an eye on the integrity of a device. An IDS can warn of possible attempts to subvert security on the host on which it runs. The great-granddaddy of intrusion detection systems is tripwire. This host-based system checks modification times and integrity of files by using strong algorithms (cryptographic checksums or signatures) that can detect even the most minor modifications. A commercial version of tripwire is also available. Another commercial IDS is DragonSquire. Other free, popular, and flexible IDSs include samhain and AIDE. The last two IDSs offer even more features and means of remaining invisible to users than tripwire does. Commercial IDSs that are popular in enterprise environments include Cisco Secure IDS (formerly NetRanger), Enterasys Dragon, and ISS RealSecure.

• Keep Fedora systems up-to-date by downloading and installing the latest updates. Use yum to update the system regularly (page 534) or allow the system to update itself every night automatically.

• Complementing host-based IDSs are network-based IDSs. The latter programs monitor the network and nodes on the network and report suspicious occurrences (attack signatures) via user-defined alerts. These signatures can be matched based on known worms, overflow attacks against programs, or unauthorized scans of network ports. Such programs as snort, klaxon, and NFR are used in this capacity. Commercial programs, such as DragonSentry, also fill this role.

• Provided with Fedora/RHEL is PAM, which allows you to set up different methods and levels of authentication in many ways (page 476).

• Process accounting—a good supplement to system security—can provide a continuous record of user actions on your system. See the accton man page (part of the acct package) for more information.

• Emerging standards for things such as RBAC (Role-Based Access Control) allow tighter delegation of privileges along defined organizational boundaries. You can delegate roles to each user as appropriate to the access required.

• General mailing lists and archives are useful repositories of security information, statistics, and papers. The most useful are the BugTraq mailing list and CERT.7 The BugTraq site and email service offer immediate notifications about specific vulnerabilities, whereas CERT provides notice of widespread vulnerabilities and useful techniques to fix them, plus links to vendor patches.

7. CERT is slow but useful as a medium for coordination between sites. It acts as a tracking agency to document the spread of security problems.

• The syslog facility can direct messages from system daemons to specific files such as those in /var/log. On larger groups of systems, you can send all important syslog information to a secure host, where that host’s only function is to store syslog data so it cannot be tampered with. See page 316 and the syslogd man page for more information.

Login Security

Without a secure host, good login security cannot add much protection. Table C-1 on page 1180 lists some of the best login security tools, including replacement daemons for telnetdrlogind, and rshd. Many sites use ssh, which comes as both freeware and a commercially supported package that works on UNIX/Linux, Windows, and Macintosh platforms.

The PAM facility (page 476) allows you to set up multiple authentication methods for users in series or in parallel. In-series PAM requires multiple methods of authentication for a user. In-parallel PAM uses any one of a number of methods for authentication.

Although not the most popular choice, you can configure a system to take advantage of one-time passwords. S/Key is the original implementation of one-time passwords by Bellcore. OPIE (one-time passwords in everything), which was developed by the U.S. Naval Research Labs, is an improvement over the original Bellcore system. In one permutation of one-time passwords, the user gets a piece of paper listing a set of one-time passwords. Each time a user logs in, she enters a password from the piece of paper. Once used, a password becomes obsolete, and the next password in the list is the only one that will work. Even if a malicious user compromises the network and sees your password, this information will be of no use because the password can be used only once. This setup makes it very difficult for someone to log in as you but does nothing to protect the data you type at the keyboard. One-time passwords is a good solution if you are at a site where no encrypted login is available. A truly secure (or paranoid) site will combine one-time passwords and encrypted logins.

Another type of secure login that is becoming more common is facilitated by a token or a smartcard. Smartcards are credit-card-like devices that use a challenge–response method of authentication. Smartcard and token authentication rely on something you have (the card) and something you know (a passphrase, user ID, or PIN). For example, you might enter your username in response to the login prompt and get a password prompt. You would then enter your PIN and the number displayed on the access token. The token has a unique serial number that is stored in a database on the authentication server. The token and the authentication server use this serial number as a means of computing a challenge every 30 to 60 seconds. If the PIN and token number you enter match what they should be as computed by the access server, you are granted access to the system.

Remote Access Security

Issues and solutions surrounding remote access security overlap with those pertaining to login and host security. Local logins might be secure with simply a username and password, whereas remote logins (and all remote access) should be made more secure. Many break-ins can be traced back to reusable passwords. It is a good idea to use an encrypted authentication client, such as ssh or kerberos. You can also use smartcards for remote access authentication.

Modem pools can also be an entry point into a system. Most people are aware of how easy it is to monitor a network line, but they might take for granted the security of the PSTN (public switched telephone network, also known as POTS—plain old telephone service). You might want to set up an encrypted channel after dialing in to a modem pool. One way to do so is by running ssh over PPP (page 292).

There are ways to implement stringent modem authentication policies so unauthorized users cannot use local modems. The most common techniques are PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), and Radius. PAP and CHAP are relatively weak compared to Radius, so the latter has rapidly gained in popularity. Cisco also provides a method of authentication called TACACS/TACACS+ (Terminal Access Controller Access Control System).

One or more of these authentication techniques are available in a RAS (remote access server—in a network, a computer that provides network access to remote users via modem).

Two other techniques for remote access security can be built into a modem (or RAS if it has integrated modems). One is callback: After you dial in, you get a password prompt. Once you type your password, the modem hangs up and calls you back at a phone number it has stored internally. Unfortunately this technique is not foolproof. Some modems have a built-in callback table that holds about ten entries, so this strategy works for small sites with only a few modems. If you use more modems, the RAS software must provide the callback.

The second technique is to use CLID (caller line ID) or ANI (automatic number identification) to decide whether to answer the call. Depending on your wiring and the local phone company, you might not be able to use ANI. ANI information is provided before the call, whereas CLID information is provided in tandem with the call.

Viruses and Worms

Viruses spread through systems by infecting executable files. Examples of UNIX/Linux viruses include the Bliss virus/worm released in 1997 and the RST.b virus discovered in December 2001. Both are discussed in detail in articles on the Web. In the cases of Bliss and RST.b, the Linux native executable format, ELF, was used as a propagation vector.

Just after 5 PM on November 2, 1988, Robert T. Morris, Jr., a graduate student at Cornell University, released the first big virus onto the Internet. Called an Internet worm, this virus was designed to propagate copies of itself over many machines on the Internet. The worm was a piece of code that exploited four vulnerabilities, including one in finger, to force a buffer to overflow on a system. Once the buffer overflowed, the code was able to get a shell and then recompile itself on the remote machine. The worm spread around the Internet very quickly and was not disabled, despite many people’s efforts, for 36 hours.

The chief characteristic of any worm is propagation over a public network, such as the Internet. A virus propagates by infecting executables on the machine, whereas a worm tends to prefer exploiting known security holes in network servers to gain root access and then tries to infect other machines in the same way.

UNIX/Linux file permissions help to inoculate systems against many viruses. Windows NT is resistant for similar reasons. You can easily protect the local system against many viruses and worms by keeping its system patches up-to-date, not executing untrusted binaries from the Internet, limiting PATH (page 359) to include only necessary system directories, and doing as little as possible while working with root privileges. You can prevent a disaster in case a virus strikes by frequently backing up the local system.

Physical Security

Often overlooked as a defense against intrusion, physical security covers access to the computer itself and to the console or terminal attached to the machine. If the machine is unprotected in an unlocked room, there is very little hope for physical security. (A simple example of physical vulnerability is someone walking into the room where the computer is, removing the hard drive from the computer, taking it home, and analyzing it.) You can take certain steps to improve the physical security of a computer.

• Keep servers in a locked room with limited access. A key, a combination, or a swipe card should be required to gain access. Protect windows as well as doors. Maintain a single point of entry. (Safety codes might require multiple exits, but only one must be an entry.)

• For public machines, use a security system, such as a fiberoptic security system, that can secure a lab full of machines. With such a system, you run a fiberoptic cable through each machine such that the machine cannot be removed (or opened) without cutting the cable. When the cable is cut, an alarm goes off. Some machines—for example, PCs with plastic cases—are much more difficult to secure than others. Although it is not a perfect solution, a fiberoptic security system might improve local security enough to persuade a would-be thief to go somewhere else.

• Most modern PCs have a BIOS password. You can set the order in which a PC searches for a boot device, preventing the PC from being booted from a CD/DVD or USB flash drive. Some BIOSs can prevent the machine from booting altogether without a proper password. The password protects the BIOS from unauthorized modification. Beware, however: Many BIOSs have well-known back doors (page 1238). In addition, you can blank the BIOS password by setting the clear-CMOS jumper on a PC motherboard; if you are relying on a BIOS password, lock the case.

• Run only fiberoptic cable between buildings. This strategy is not only more secure but also safer in the event of lightning strikes and is required by many commercial building codes.

• Maintain logs of who goes in and out of secure areas. Sign-in/out sheets are useful only if everyone uses them. Sometimes a guard is warranted. Often a simple proximity badge or smartcard can tell when anyone has entered or left an area and keep logs of these events.

• Anyone who has access to the physical hardware has the keys to the palace. Someone with direct access to a computer system can do such things as swap components and insert an installation medium, all of which are security threats.

• Avoid having activated, unused network jacks in public places. Such jacks provide unnecessary risk.

• Many modern switches can lock a particular switch port so it accepts only traffic from an NIC (network interface card) with a particular hardware address and shuts down the port if another address is seen. However, commonly available programs can enable someone to reset this address.

• Make periodic security sweeps. Check doors for proper locking. If you must have windows, make sure they are locked or are permanently sealed.

• Waste receptacles are often a source of information for intruders. Have policies for containment and disposal of sensitive documents.

• Use a UPS (uninterruptable power supply). Without a clean source of power, your system is vulnerable to corruption.

Image Tutorial: Using GPG to Secure a File

GPG (GNU Privacy Guard, also GnuPG; www.gnupg.org) enables you to encrypt a document so that only the person you specify when you encrypt the document can decrypt and read it. It also enables you to sign a document digitally so anyone can be sure it came from you and was not altered. See page 1160 for a discussion of how GPG works.

GPG uses public key encryption (page 1157) wherein you create a key pair: one private or secret key you keep to yourself and one public key you share with your correspondents or the world. The important part of this two-key system is that neither key can be calculated by having the other. They are each an independent and necessary part of the system and are based upon solid mathematical foundations. This setup allows you to

• Use your private key to sign a document to provide identification and message integrity to a recipient who has your public key.

Image Identification means the recipient can be certain the document came from you.

Image Message integrity means the recipient knows the message has not been altered.

You can provide these features because only you have your private key.

• Use the recipient's public key to encrypt a document and provide secrecy.

Image Secrecy means that only the recipient (who has the corresponding private key) can decrypt the document.

• Combine these steps to provide identification, message integrity, and secrecy (i.e., only the recipient can decrypt the document, the recipient knows the document came from you, and the recipient knows the document was not altered).

Creating a Key Pair

Image ~/.gnupg

To start working with GPG you need to create a key pair for yourself. Use gpg with the ––gen-key option to create a key pair. With this option, gpg creates and populates the ~/.gnupg directory if it does not exist. The secring.gpg file is the keyring that holds your secret keys; thepubring.gpg file is the keyring that holds your holds public keys. The following steps show Sam creating a key pair for himself.

gpg --gen-key
gpg (GnuPG) 1.4.14; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory '/home/sam/.gnupg' created
gpg: new configuration file '/home/sam/.gnupg/gpg.conf' created
gpg: WARNING: options in '/home/sam/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring '/home/sam/.gnupg/secring.gpg' created
gpg: keyring '/home/sam/.gnupg/pubring.gpg' created

The first question is about which kind of encryption (“what kind of key”) you want to use. The default, RSA and RSA, is a good choice.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1

The next question concerns the size of the key. Larger keys are more secure but take longer to process. A key that is 2,048 bits long is a good compromise.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 2048
Requested keysize is 2048 bits

Your answer to the next question determines when or if the key will expire. For most uses, a key that does not expire is a good choice. You must confirm this choice by typing y.

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

Next you specify your real name (you can specify a nickname or handle in the comment section), your email address (the one most people associate with you), and an optional comment. After you specify these traits, a prompt allows you to edit them, quit, or continue (Okay).

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Sam Smith
Email address: sam@example.com
Comment: Sam the Great
You selected this USER-ID:
    "Sam Smith (Sam the Great) <sam@example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

The last step in generating a key pair is specifying a passphrase that will keep your secret key secure. The passphrase should have the same characteristics as a password except it should be longer. Protect the passphrase as you would a password. For more information refer to “Password Security” on page 136.

You need a Passphrase to protect your secret key.

Enter passphrase:
Repeat passphrase:

After you enter a passphrase, gpg generates your keys. Generating truly random keys requires many random bytes, and generating random bytes requires entropy. As the instructions suggest, type on the keyboard, move the mouse, and use the disk (e.g., copy several large files) to gain entropy.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 284 more bytes)
gpg: /home/sam/.gnupg/trustdb.gpg: trustdb created
gpg: key D26C84B3 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 2048R/D26C84B3 2013-10-03
      Key fingerprint = 036A DE6E D653 3769 B243  A9EE 286A C3E0 D26C 84B3
uid                  Sam Smith (Sam the Great) <sam@example.com>
sub 2048R/569BA710 2013-10-03

When gpg finishes, you have generated your key pair. The gpg utility stores all information in the ~/.gpg directory. Your keys, and public keys you import using gpg, are stored on your keyring. The output shows two items you will use while working with gpg: the key ID (569BA710 in the example) and the key fingerprint.


After you have generated your key pair, you can display information about the pair using the gpg ––list-keys and ––fingerprint options. A fingerprint is a shorthand for the public portion of a key; you can use it for manual identification of the key.

gpg --list-keys
pub   2048R/D26C84B3 2013-10-03
uid                  Sam Smith (Sam the Great) <sam@example.com>
sub   2048R/569BA710 2013-10-03

gpg --fingerprint
pub   2048R/D26C84B3 2013-10-03
      Key fingerprint = 036A DE6E D653 3769 B243  A9EE 286A C3E0 D26C 84B3
uid                  Sam Smith (Sam the Great) <sam@example.com>
sub   2048R/569BA710 2013-10-03

Exporting and Importing Public Keys

You need to give your public key to people you want to share information with securely. The best way to share public keys is on a public keyserver (e.g., pgp.mit.edu). Public keyservers propagate keys to other keyservers so over time your keys will appear in many places. In addition, you can put your public key fingerprint on your business card. The more places your public key appears, the better. For more information refer to “Using a Keyserver” on page 1178.

Alternately, you can manually exchange public keys. It is poor practice to use email to give someone your public key because such an exchange can give rise to a man-in-the-middle attack (see the tip on page 1160). A better practice is to use a removable medium (e.g., a USB flash drive) to exchange keys. The following paragraphs explain how to manually exchange keys.

The following command exports public keys (––export) in ASCII format (––armor; or –a) to a file named sam_pgp.asc (––output; or –o followed by the name of the file you want to write to). If you specify a user, the command exports the public key for that user, otherwise it exports the public keys for all users on the public keyring. Following, Sam writes his public key to sam_pgp.asc and then displays that file. Then he saves it on a USB flash drive and gives the drive to Max.

gpg --export --armor --output sam_pgp.asc sam@example.com

cat sam_pgp.asc
Version: GnuPG v1.4.14 (GNU/Linux)



Without the ––armor or –a option gpg writes a binary file.

After Max copies Sam’s public key from the flash drive, he adds it to his keyring using the following command

[max@guava ~]$ gpg --import sam_pgp.asc
gpg: key D26C84B3: public key "Sam Smith (Sam the Great) <sam@example.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Next, Sam follows the same procedure to add Max’s public key to his keyring. The following examples assume Sam and Max have each other’s public keys on their keyrings.

Signing and Verifying a File

Next, Sam wants to send Max a text file named memoA.

cat memoA
This is memoA.
This is memoA.
This is memoA.
This is memoA.

Sam wants to make sure Max knows the messages is from him and that it has not been tampered with but does not care if anyone else can read it; he signs the file but does not encrypt it.

You can use one of two options to sign a file: ––clearsign or ––detach-sign (–b). The ––clearsign option creates a clear-text signature that gpg appends to the file. This option is good for text files but does not work with binary files. The ––detach-sign (–b) option creates a separate file that holds the signature and works with binary files. This section discusses both options.

Signing a file with either of these options does two things. It provides a digital signature that can prove who signed the file. It also generates a hash of the original file. When the recipient verifies the file, gpg confirms who signed the file and confirms that the file has not been tampered with.

Using the ––clearsign Option

Sam signs the file using the ––clearsign option, which generates a single, readable text file. The gpg utility requires Sam to enter his passphrase to unlock his secret key that gpg uses to sign the file.

gpg --clearsign memoA

You need a passphrase to unlock the secret key for
user: "Sam Smith (Sam the Great) <sam@example.com>"
2048-bit RSA key, ID D26C84B3, created 2013-10-03

Enter passphrase:

The preceding command generates the following file:

cat memoA.asc
Hash: SHA1

This is memoA.
This is memoA.
This is memoA.
This is memoA.
Version: GnuPG v1.4.14 (GNU/Linux)



Sam can verify the identity of the file (it was properly signed by himself) and message integrity (it was not tampered with) using the gpg ––verify option. However, the message is not secret.

gpg --verify memoA.asc
gpg: Signature made Thu 03 Oct 2013 12:10:39 PM PDT using RSA key ID D26C84B3
gpg: Good signature from "Sam Smith (Sam the Great) <sam@example.com>"

If the file had been altered, gpg would display the following message:

gpg --verify memoA.asc
gpg: Signature made Thu 03 Oct 2013 12:10:39 PM PDT using RSA key ID D26C84B3
gpg: BAD signature from "Sam Smith (Sam the Great) <sam@example.com>"

When Sam sends the file to Max and Max verifies the file (using Sam’s public key, which is on his keyring) gpg displays the following message

[max@guava ~]$ gpg --verify memoA.asc
gpg: Signature made Thu 03 Oct 2013 12:10:39 PM PDT using RSA key ID D26C84B3
gpg: Good signature from "Sam Smith (Sam the Great) <sam@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 036A DE6E D653 3769 B243  A9EE 286A C3E0 D26C 84B3

This message says that the signature and file are good based on the copy of Sam’s public key on Max’s keyring, but that the signature cannot be trusted. Someone (a man in the middle; page 1160) could have generated a key pair with Sam’s name on it, sent the public key to Max, and signed the document using the bogus private key. To be trusted, a public key must be signed; see “Signing a Public Key” on page 1177.

Using the ––detach-sign Option

The ––clearsign option does not work with binary files: Appending an ASCII signature to a binary file would render the file useless. Instead, the ––detach-sign (–b) option creates a separate signature file that gpg can use to verify the source of the file and also verify that the file has not been tampered with.

Max wants to send Sam binfile. He wants to ensure that Sam knows the file is from him and that it has not been altered, but does not care if someone else can use the file. When Max uses the ––detach-sign option, gpg prompts Max to enter his passphrase and creates a binfile.sig file that holds the signature. Max must send both the binfile and binfile.sig files to Sam for Sam to verify the signature (and use the file).

[max@guava ~]$ gpg --detach-sign binfile

You need a passphrase to unlock the secret key for
user: "Max Wild <max@example.com>"
2048-bit RSA key, ID 643E62B8, created 2013-10-03

Enter passphrase:

[max@guava ~]$ ls -l binfile*
-rwxr-xr-x. 1 max pubs 982296 10-03 12:28 binfile
-rw-r--r--. 1 max pubs    287 10-03 12:30 binfile.sig

Assuming Max’s public key is on Sam’s keyring, when Sam specifies the name of the signature file as an argument to gpg, gpg verifies the file and signature.

gpg binfile.sig
gpg: Signature made Thu 03 Oct 2013 12:30:02 PM PDT using RSA key ID 643E62B8
gpg: Good signature from "Max Wild <max@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 92CB 83B7 8439 C740 8B80  6C75 72E3 1884 643E 62B8

Again, Max’s public key must be signed to be trusted.

Encrypting and Decrypting a File

When you encrypt a file using a public key, only the corresponding private key can decrypt the file. If you want to send a file to someone such that only that person can read (or run) that file, you can encrypt the file using the recipient’s public key. Then the recipient can decrypt the file using her private key; no one else can read the file.

Following, Max encrypts the memoB file using Sam’s public key, yielding an unreadable file named memoB.gpg.

[max@guava ~]$ gpg --recipient sam@example.com --encrypt memoB
[max@guava ~]$ ls -l memoB*
-rw-r--r--. 1 max pubs  60 10-03 12:45 memoB
-rw-r--r--. 1 max pubs 349 10-03 12:45 memoB.gpg

When Sam receives the file, he decrypts it using his secret key:

gpg --output memoB --decrypt memoB.gpg

You need a passphrase to unlock the secret key for
user: "Sam Smith (Sam the Great) <sam@example.com>"
2048-bit RSA key, ID 569BA710, created 2013-10-03 (main key ID D26C84B3)

gpg: encrypted with 2048-bit RSA key, ID 569BA710, created 2013-10-03
      "Sam Smith (Sam the Great) <sam@example.com>"

cat memoB
This is memoB.
This is memoB.
This is memoB.
This is memoB.

Signing and Encrypting a File

If you want to keep a file from prying eyes and ensure that it comes from the person it says it comes from and that it has not be altered, you can sign the file using your private key and encrypt it using the recipient’s public key. The recipient can then decrypt it using his public key and verify the signature using the sender’s public key.

In the next example, Max encrypts memoC using Sam’s public key and signs the file using his private key. The resulting file is named memoC.gpg. Because Max is using his private key, he must supply his passphrase.

gpg --recipient sam@example.com --encrypt --sign memoC

You need a passphrase to unlock the secret key for
user: "Max Wild <max@example.com>"
2048-bit RSA key, ID 643E62B8, created 2013-10-03

Enter passphrase:

When Sam gets the file he decrypts it, sending the output (the decrypted file) to memoC. Because the file was encrypted using Sam’s public key, Sam must provide his private key to decrypt it. At the bottom of the output, gpg confirms that Max’s signature is good.

gpg --output memoC memoC.gpg

You need a passphrase to unlock the secret key for
user: "Sam Smith (Sam the Great) <sam@example.com>"
2048-bit RSA key, ID 569BA710, created 2013-10-03 (main key ID D26C84B3)
Enter passphrase:

gpg: encrypted with 2048-bit RSA key, ID 569BA710, created 2013-10-03
      "Sam Smith (Sam the Great) <sam@example.com>"
gpg: Signature made Thu 03 Oct 2013 12:50:51 PM PDT using RSA key ID 643E62B8
gpg: Good signature from "Max Wild <max@example.com>"

Signing a Public Key

If you trust that a public key belongs to the person it says it belongs to, you can sign that key to make it more trustworthy. The more people who sign a key, the more trustworthy it becomes.

A key ID identifies a key. You can use the gpg ––list-key option to list the IDs of all the keys on your keyring. The following output shows that Sam’s key is 2,048 bits long, uses RSA encryption (R), and has a key ID of D26C84B3.

gpg --list-key
pub   2048R/D26C84B3 2013-10-03
uid                  Sam Smith (Sam the Great) <sam@example.com>
sub   2048R/569BA710 2013-10-03

Before you sign a key, make sure it belongs to the person it says it belongs to. Download the key from several sources (e.g., keyservers). Each key has a unique fingerprint that you can use to identify that key. Use the gpg ––fingerprint option followed by the key ID to display the fingerprint of a key and compare the fingerprints.

[max@guava ~]$ gpg --fingerprint D26C84B3
pub   2048R/D26C84B3 2013-10-03
      Key fingerprint = 036A DE6E D653 3769 B243  A9EE 286A C3E0 D26C 84B3
uid                  Sam Smith (Sam the Great) <sam@example.com>
sub   2048R/569BA710 2013-10-03

Check that the fingerprint is correct by comparing it to one supplied by the person who owns it. Use a keyserver, the phone, or a printout, not email, to verify the fingerprint. Once you are sure you have a valid key you can sign it using the gpg ––sign-key option followed by the key ID you have just verified. Following, Max signs the copy of Sam’s public key that is on Max’s keyring.

[max@guava ~]$ gpg --sign-key D26C84B3

pub  2048R/D26C84B3  created: 2013-10-03  expires: never       usage: SC
                     trust: unknown       validity: unknown
sub  2048R/569BA710  created: 2013-10-03  expires: never       usage: E
[ unknown] (1). Sam Smith (Sam the Great) <sam@example.com>

pub  2048R/D26C84B3  created: 2013-10-03  expires: never       usage: SC
                     trust: unknown       validity: unknown
 Primary key fingerprint: 036A DE6E D653 3769 B243  A9EE 286A C3E0 D26C 84B3

     Sam Smith (Sam the Great) <sam@example.com>

Are you sure that you want to sign this key with your
key "Max Wild <max@example.com>" (643E62B8)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "Max Wild <max@example.com>"
2048-bit RSA key, ID 643E62B8, created 2013-10-03

Enter passphrase:

You use your secret key to sign a document, proving you signed the document. To gain access to your secret key, gpg requires you to enter your passphrase.

Now when Max verifies Sam’s document gpg checks the trust database, displays some information about Sam’s public key, and declares that Sam’s signature is good.

gpg --verify memoA.asc
gpg: Signature made Thu 03 Oct 2013 12:10:39 PM PDT using RSA key ID D26C84B3
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: Good signature from "Sam Smith (Sam the Great) <sam@example.com>"

Using a Keyserver

If you want to share your public key with the world, you can upload it to a keyserver. Having your key on a keyserver makes it easier for several people to sign it. It also makes it easier for people to find and use to encrypt documents they send to you. Once it is uploaded, it will be distributed to all keyservers; there is no need to upload it to more than one. The keys.gnupg.net URL uses a round-robin DNS that points to a different keyserver each time you reference it.

The following example sends the public key with the key ID 99ZZ99ZZ from the user’s keyring to the keyserver that keys.gnupg.net points to. The gpg utility uses keys.gnupg.net by default; you can specify a different keyserver by using the ––keyserver option. The argument following the––send-keys option specifies the key ID of the public key gpg is to send from the user’s keyring to the keyserver.

gpg  --send-keys 99ZZ99ZZ
gpg: sending key 99ZZ99ZZ to hkp server keys.gnupg.net

If you want to sign a key that is stored on a keyserver, first determine the key ID of the key (get it from your friend or look it up on a keyserver [e.g., pgp.mit.edu]). Then download the key. Again, gpg defaults to keys.gnupg.net. The ––recv-keys option specifies the key ID of the key you want to download. The gpg utility stores the key on your keyring.

gpg --recv-keys 99ZZ99ZZ
gpg: requesting key 99ZZ99ZZ from hkp server keys.gnupg.net
gpg: key 99ZZ99ZZ: public key "Zach Brill <zach@example.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

Next use the ––fingerprint option followed by the key ID of the key you just downloaded to display the fingerprint of the key.

gpg --fingerprint 99ZZ99ZZ
pub   1024D/99ZZ99ZZ 1998-10-23
      Key fingerprint = 5E1C 544D 83BF D3D0 6ED9  61EA C1B2 A984 68DB 67AE
uid                  Zach Brill <zach@example.com>
sub   2048g/C548F7C0 1998-10-23

Always make sure the key you are signing belongs to the person it says it belongs to and that that person is a real person. Obtain the fingerprint of the key from a source other than a keyserver and verify the fingerprint before signing a key. In the following example, the argument following the––sign-key option specifies the key ID of the key the user will sign on the keyserver. Because this command signs the key on the keyserver, there is no need to upload the key from your keyring.

gpg --keyserver keys.gnupg.net --sign-key 99ZZ99ZZ

pub  1024D/99ZZ99ZZ  created: 1998-10-23  expires: never       usage: SCA
                     trust: unknown       validity: unknown
sub  2048g/C548F7C0  created: 1998-10-23  expires: never       usage: E
[ unknown] (1). Zach Brill <zach@example.com>

pub  1024D/99ZZ99ZZ  created: 1998-10-23  expires: never       usage: SCA
                     trust: unknown       validity: unknown
 Primary key fingerprint: 9Z9Z 999Z 99ZZ 9Z9Z 999Z  9Z9Z 999Z 9Z9Z 999Z 99ZZ

     Zach Brill <zach@example.com>

Are you sure that you want to sign this key with your
key "Max Wild <max@example.com>" (643E62B8)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "Max Wild <max@example.com>"
2048-bit RSA key, ID 643E62B8, created 2013-10-03

Enter passphrase:

Security Resources

Many free and commercial programs can enhance system security. Some of these are listed in Table C-1. Many of these sites have links to other, interesting sites that are worth looking at.






Table C-1 Security resources

Appendix Summary

Security is inversely proportional to usability. There must be a balance between users’ requirements to get their work done and the amount of security that is implemented. It is often unnecessary to provide top security for a small business with only a few employees. By contrast, if you work for a government military contractor, you are bound to have extreme security constraints and an official audit policy to determine whether security policies are being implemented correctly.

Review your own security requirements periodically. Several of the tools mentioned in this appendix can help you monitor a system’s security measures. Tools such as nessus, samhain, and SAINT, for example, provide auditing mechanisms.

Some companies specialize in security and auditing. Hiring one of them to examine your site can be costly but might yield specific recommendations for areas you might have overlooked in your initial setup. When you hire someone to audit your security, recognize that you might be providing both physical and root access to local systems. Make sure the company that you hire has a good history, has been in business for several years, and has impeccable references. Check up on the company periodically: Things change over time. Avoid the temptation to hire former system crackers as consultants. Security consultants should have an irreproachable ethical background or you will always have doubts about their intentions.

Your total security package is based on your risk assessment of local vulnerabilities. Strengthen those areas that are most important for your business. For example, many sites rely on a firewall to protect them from the Internet, whereas internal hosts might receive little or no security attention. Crackers refer to this setup as “the crunchy outside surrounding the soft chewy middle.” Yet this setup is entirely sufficient to protect some sites. Perform your own risk assessment and address your needs accordingly. If need be, hire a full-time security administrator whose job it is to design and audit local security policies.