Red Hat Enterprise Linux Manual

Daftar Isi ☛

(Sebelumnya) 6 : 2.7. Virtual Private Netwo ...

7 : Power Management Guide (Berikutnya)

Security Guide

Chapter 3. Encryption

3.1. Data at Rest

3.1.1. Full Disk Encryption
3.1.2. File Based Encryption

3.2. Data in Motion

3.2.1. Virtual Private Networks
3.2.2. Secure Shell
3.2.3. OpenSSL Intel AES-NI Engine
3.2.4. LUKS Disk Encryption
3.2.5. Using GNU Privacy Guard (GnuPG)

There are two main types of data that must be protected: data at rest and data in motion. These different types of data are protected in similar ways using similar technology but the implementations can be completely different. No single protective implementation can prevent all possible methods of compromise as the same information may be at rest and in motion at different points in time.

3.1. Data at Rest

Data at rest is data that is stored on a hard drive, tape, CD, DVD, disk, or other media. This information's biggest threat comes from being physically stolen. Laptops in airports, CDs going through the mail, and backup tapes that get left in the wrong places are all examples of events where data can be compromised through theft. If the data was encrypted on the media then you wouldn't have to worry as much about the data being compromised.

3.1.1. Full Disk Encryption

Full disk or partition encryption is one of the best ways of protecting your data. Not only is each file protected but also the temporary storage that may contain parts of these files is also protected. Full disk encryption will protect all of your files so you don't have to worry about selecting what you want to protect and possibly missing a file.

Red Hat Enterprise Linux 6 natively supports LUKS Encryption. LUKS will bulk encrypt your hard drive partitions so that while your computer is off your data is protected. This will also protect your computer from attackers attempting to use single-user-mode to login to your computer or otherwise gain access.

Full disk encryption solutions like LUKS only protect the data when your computer is off. Once the computer is on and LUKS has decrypted the disk, the files on that disk are available to anyone who would normally have access to them. To protect your files when the computer is on, use full disk encryption in combination with another solution such as file based encryption. Also remember to lock your computer whenever you are away from it. A passphrase protected screen saver set to activate after a few minutes of inactivity is a good way to keep intruders out. For more information on LUKS, refer to Section 3.2.4, "LUKS Disk Encryption".

3.1.2. File Based Encryption

GnuPG (GPG) is an open source version of PGP that allows you to sign and/or encrypt a file or an email message. This is useful to maintain integrity of the message or file and also protects the confidentiality of the information contained within the file or email. In the case of email, GPG provides dual protection. Not only can it provide Data at Rest protection but also Data In Motion protection once the message has been sent across the network.

File based encryption is intended to protect a file after it has left your computer, such as when you send a CD through the mail. Some file based encryption solutions will leave remnants of the encrypted files that an attacker who has physical access to your computer can recover under some circumstances. To protect the contents of those files from attackers who may have access to your computer, use file based encryption combined with another solution such as full disk encryption.

3.2. Data in Motion

Data in motion is data that is being transmitted over a network. The biggest threats to data in motion are interception and alteration. Your username and password should never be transmitted over a network without protection as it could be intercepted and used by someone else to impersonate you or gain access to sensitive information. Other private information such as bank account information should also be protected when transmitted across a network. If the network session was encrypted then you would not have to worry as much about the data being compromised while it is being transmitted.

Data in motion is particularly vulnerable to attackers because the attacker does not have to be near the computer in which the data is being stored rather they only have to be somewhere along the path. Encryption tunnels can protect data along the path of communications.

3.2.1. Virtual Private Networks

Virtual Private Networks (VPN) provide encrypted tunnels between computers or networks of computers across all ports. With a VPN in place, all network traffic from the client is forwarded to the server through the encrypted tunnel. This means that the client is logically on the same network as the server it is connected to via the VPN. VPNs are very common and are simple to use and setup.

3.2.2. Secure Shell

Secure Shell (SSH) is a powerful network protocol used to communicate with another system over a secure channel. The transmissions over SSH are encrypted and protected from interception. Cryptographic log-on can also be utilized to provide a better authentication method over traditional usernames and passwords.

SSH is very easy to activate. By simply starting the sshd service, the system will begin to accept connections and will allow access to the system when a correct username and password is provided during the connection process. The standard TCP port for the SSH service is 22, however this can be changed by modifying the configuration file /etc/ssh/sshd_config and restarting the service. This file also contains other configuration options for SSH.

Secure Shell (SSH) also provides encrypted tunnels between computers but only using a single port. Port forwarding can be done over an SSH tunnel and traffic will be encrypted as it passes over that tunnel but using port forwarding is not as fluid as a VPN.

3.2.2.1. SSH Cryptographic Login

SSH supports the use of cryptographic keys to login to a computer. This is much more secure than using a password and if setup properly could be considered multifactor authentication.

A configuration change must occur before cryptographic logon can occur. In the file /etc/ssh/sshd_config uncomment and modify the following lines so that appear as such:

PubkeyAuthentication yesAuthorizedKeysFile.ssh/authorized_keys

The first line tells the SSH program to allow public key authentication. The second line points to a file in the home directory where the public key of authorized key pairs exists on the system.

The next thing to do is to generate the SSH key pairs on the client you will use to connect to the system. The command ssh-keygen will generate an RSA 2048-bit key set for logging into the system. The keys are stored, by default, in the ~/.ssh directory. You can utilize the switch -b to modify the bit-strength of the key. Using 2048-bit is normally sufficient.

In your ~/.ssh directory you should see the two keys you just created. If you accepted the defaults when running the ssh-keygen then your keys are named id_rsa and id_rsa.pub, the private and public keys. You should always protect the private key from exposure. The public key, however, needs to be transferred over to the system you are going to login to. Once you have it on your system the easiest way to add the key to the approved list is by:

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

This will append the public key to the authorized_key file. The SSH application will check this file when you attempt to login to the computer.

Similarly to passwords and any other authentication mechanism, you should change your SSH keys regularly. When you do, make sure you clean out any unused keys from the authorized_key file.

3.2.3. OpenSSL Intel AES-NI Engine

The Intel Advanced Encryption Standard (AES) New Instructions (AES-NI) engine is available for certain Intel processors, and allows for extremely fast hardware encryption and decryption.

Note

For a list of Intel processors that support the AES-NI engine, refer to: Intel's ARK.

The AES-NI engine is automatically enabled if the detected processor is among the supported ones.

To check if the engine is enabled, run the following command as the root user:

openssl engine -c -tt

To test its speed, run the following command as root:

openssl speed aes-128-cbc

To test the speed of OpenSSH you can run a command like the following:

~]# dd if=/dev/zero count=100 bs=1M | ssh -c aes128-cbc localhost "cat >/dev/null"root@localhost's password: 100+0 records in100+0 records out104857600 bytes (105 MB) copied, 4.81868 s, 21.8 MB/s

You can find out more about the AES-NI engine at the following URL: http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/.

3.2.4. LUKS Disk Encryption

Linux Unified Key Setup-on-disk-format (or LUKS) allows you to encrypt partitions on your Linux computer. This is particularly important when it comes to mobile computers and removable media. LUKS allows multiple user keys to decrypt a master key which is used for the bulk encryption of the partition.

Overview of LUKS

What LUKS does

LUKS encrypts entire block devices and is therefore well-suited for protecting the contents of mobile devices such as removable storage media or laptop disk drives.
The underlying contents of the encrypted block device are arbitrary. This makes it useful for encrypting swap devices. This can also be useful with certain databases that use specially formatted block devices for data storage.
LUKS uses the existing device mapper kernel subsystem.
LUKS provides passphrase strengthening which protects against dictionary attacks.
LUKS devices contain multiple key slots, allowing users to add backup keys/passphrases.

What LUKS does not do:

LUKS is not well-suited for applications requiring many (more than eight) users to have distinct access keys to the same device.
LUKS is not well-suited for applications requiring file-level encryption.

3.2.4.1. LUKS Implementation in Red Hat Enterprise Linux

Red Hat Enterprise Linux 6 utilizes LUKS to perform file system encryption. By default, the option to encrypt the file system is unchecked during the installation. If you select the option to encrypt your hard drive, you will be prompted for a passphrase that will be asked every time you boot the computer. This passphrase "unlocks" the bulk encryption key that is used to decrypt your partition. If you choose to modify the default partition table you can choose which partitions you want to encrypt. This is set in the partition table settings.

The default cipher used for LUKS (refer to cryptsetup --help) is aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector). Note that the installation program, Anaconda, uses by default XTS mode (aes-xts-plain64). The default key size for LUKS is 256 bits. The default key size for LUKS with Anaconda (XTS mode) is 512 bits. Ciphers that are available are:

AES - Advanced Encryption Standard - FIPS PUB 197
Twofish (A 128-bit Block Cipher)
Serpent
cast5 - RFC 2144
cast6 - RFC 2612

3.2.4.2. Manually Encrypting Directories

Warning

Following this procedure will remove all data on the partition that you are encrypting. You WILL lose all your information! Make sure you backup your data to an external source before beginning this procedure!

Enter runlevel 1 by typing the following at a shell prompt as root:
```
telinit 1
```
Unmount your existing /home:
```
umount /home
```
If the command in the previous step fails, use fuser to find processes hogging /home and kill them:
```
fuser -mvk /home
```
Verify /home is no longer mounted:
```
grep home /proc/mounts
```
Fill your partition with random data:
```
shred -v --iterations=1 /dev/VG00/LV_home
```
This command proceeds at the sequential write speed of your device and may take some time to complete. It is an important step to ensure no unencrypted data is left on a used device, and to obfuscate the parts of the device that contain encrypted data as opposed to just random data.

Initialize your partition:

cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home

Open the newly encrypted device:

cryptsetup luksOpen /dev/VG00/LV_home home

Make sure the device is present:
```
ls -l /dev/mapper | grep home
```
Create a file system:
```
mkfs.ext3 /dev/mapper/home
```
Mount the file system:
```
mount /dev/mapper/home /home
```
Make sure the file system is visible:
```
df -h | grep home
```
Add the following to the /etc/crypttab file:
```
home /dev/VG00/LV_home none
```
Edit the /etc/fstab file, removing the old entry for /home and adding the following line:
```
/dev/mapper/home /home ext3 defaults 1 2
```
Restore default SELinux security contexts:
```
/sbin/restorecon -v -R /home
```
Reboot the machine:
```
shutdown -r now
```
The entry in the /etc/crypttab makes your computer ask your luks passphrase on boot.
Log in as root and restore your backup.

You now have an encrypted partition for all of your data to safely rest while the computer is off.

3.2.4.3. Add a new passphrase to an existing device

Use the following command to add a new passphrase to an existing device:

cryptsetup luksAddKey <device>

After being prompted for any one of the existing passprases for authentication, you will be prompted to enter the new passphrase.

3.2.4.4. Remove a passphrase from an existing device

Use the following command to remove a passphrase from an existing device:

cryptsetup luksRemoveKey <device>

You will be prompted for the passphrase you wish to remove and then for any one of the remaining passphrases for authentication.

3.2.4.5. Creating Encrypted Block Devices in Anaconda

You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions.

To enable block device encryption, check the Encrypt System checkbox when selecting automatic partitioning or the Encrypt checkbox when creating an individual partition, software RAID array, or logical volume. After you finish partitioning, you will be prompted for an encryption passphrase. This passphrase will be required to access the encrypted devices. If you have pre-existing LUKS devices and provided correct passphrases for them earlier in the install process the passphrase entry dialog will also contain a checkbox. Checking this checkbox indicates that you would like the new passphrase to be added to an available slot in each of the pre-existing encrypted block devices.

Note

Checking the Encrypt System checkbox on the Automatic Partitioning screen and then choosing Create custom layout does not cause any block devices to be encrypted automatically.

Note

You can use kickstart to set a separate passphrase for each new encrypted block device.

3.2.4.6. Links of Interest

For additional information on LUKS or encrypting hard drives under Red Hat Enterprise Linux please visit one of the following links:

3.2.5. Using GNU Privacy Guard (GnuPG)

GPG is used to identify yourself and authenticate your communications, including those with people you do not know. GPG allows anyone reading a GPG-signed email to verify its authenticity. In other words, GPG allows someone to be reasonably certain that communications signed by you actually are from you. GPG is useful because it helps prevent third parties from altering code or intercepting conversations and altering the message.

3.2.5.1. Creating GPG Keys in GNOME

Install the Seahorse utility, which makes GPG key management easier:

~]# yum install seahorse

To create a key, from the Applications ⤍ Accessories menu select Passwords and Encryption Keys, which starts the application Seahorse. From the File menu select New and then PGP Key. Then click Continue. Type your full name, email address, and an optional comment describing who are you (for example: John C. Smith, [email protected], Software Engineer). Click Create. A dialog is displayed asking for a passphrase for the key. Choose a strong passphrase but also easy to remember. Click OK and the key is created.

Warning

If you forget your passphrase, the key cannot be used and any data encrypted using that key will be lost.

To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if you are asked for the key ID, you should prepend 0x to the key ID, as in 0x6789ABCD. You should make a backup of your private key and store it somewhere secure.

3.2.5.2. Creating GPG Keys in KDE

Start the KGpg program from the main menu by selecting Applications ⤍ Utilities ⤍ Encryption Tool. If you have never used KGpg before, the program walks you through the process of creating your own GPG keypair. A dialog box appears prompting you to create a new key pair. Enter your name, email address, and an optional comment. You can also choose an expiration time for your key, as well as the key strength (number of bits) and algorithms. The next dialog box prompts you for your passphrase. At this point, your key appears in the main KGpg window.

Warning

If you forget your passphrase, the key cannot be used and any data encrypted using that key will be lost.

3.2.5.3. Creating GPG Keys Using the Command Line

Use the following shell command: gpg2 --gen-key

This command generates a key pair that consists of a public and a private key. Other people use your public key to authenticate and/or decrypt your communications. Distribute your public key as widely as possible, especially to people who you know will want to receive authentic communications from you, such as a mailing list.

A series of prompts directs you through the process. Press the Enter key to assign a default value if desired. The first prompt asks you to select what kind of key you prefer:

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?

In almost all cases, the default is the correct choice. A RSA/RSA key allows you not only to sign communications, but also to encrypt files.

Next, choose the key size:

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

Again, the default, 2048, is sufficient for almost all users, and represents an extremely strong level of security.

Next, choose when the key will expire. It is a good idea to choose an expiration date instead of using the default, which is none. If, for example, the email address on the key becomes invalid, an expiration date will remind others to stop using that public key.

Please specify how long the key should be valid. 0 = key does not expire d = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0)

Entering a value of 1y, for example, makes the key valid for one year. (You may change this expiration date after the key is generated, if you change your mind.)

Before the gpg2 application asks for signature information, the following prompt appears:

Is this correct (y/n)?

Enter y to finish the process.

Next, enter your name and email address. Remember this process is about authenticating you as a real individual. For this reason, include your real name. Do not use aliases or handles, since these disguise or obfuscate your identity.

Enter your real email address for your GPG key. If you choose a bogus email address, it will be more difficult for others to find your public key. This makes authenticating your communications difficult. If you are using this GPG key for self-introduction on a mailing list, for example, enter the email address you use on that list.

Use the comment field to include aliases or other information. (Some people use different keys for different purposes and identify each key with a comment, such as "Office" or "Open Source Projects.")

At the confirmation prompt, enter the letter O to continue if all entries are correct, or use the other options to fix any problems. Finally, enter a passphrase for your secret key. The gpg2 program asks you to enter your passphrase twice to ensure you made no typing errors.

Finally, gpg2 generates random data to make your key as unique as possible. Move your mouse, type random keys, or perform other tasks on the system during this step to speed up the process. Once this step is finished, your keys are complete and ready to use:

pub  1024D/1B2AFA1C 2005-03-31 John Q. Doe <[email protected]>Key fingerprint = 117C FE83 22EA B843 3E86  6486 4320 545E 1B2A FA1Csub  1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]

The key fingerprint is a shorthand "signature" for your key. It allows you to confirm to others that they have received your actual public key without any tampering. You do not need to write this fingerprint down. To display the fingerprint at any time, use this command, substituting your email address:

~]$ gpg2 --fingerprint [email protected]

Your "GPG key ID" consists of 8 hex digits identifying the public key. In the example above, the GPG key ID is 1B2AFA1C. In most cases, if you are asked for the key ID, you should prepend 0x to the key ID, as in 0x6789ABCD.

Warning

If you forget your passphrase, the key cannot be used and any data encrypted using that key will be lost.

3.2.5.4. About Public Key Encryption

Chapter 4. General Principles of Information Security

4.1. Tips, Guides, and Tools

The following general principals provide an overview of good security practices:

Encrypt all data transmitted over networks to help prevent man-in-the-middle attacks and eavesdropping. It is important to encrypt authentication information, such as passwords.
Minimize the amount of software installed and running services.
Use security-enhancing software and tools, for example, Security-Enhanced Linux (SELinux) for Mandatory Access Control (MAC), Netfilter iptables for packet filtering (firewall), and the GNU Privacy Guard (GnuPG) for encrypting files.
If possible, run each network service on a separate system to minimize the risk of one compromised service being used to compromise other services.
Maintain user accounts: create and enforce a strong password policy; delete unused user accounts.
Routinely review system and application logs. By default, security-relevant system logs are written to /var/log/secure and /var/log/audit/audit.log. Note: sending logs to a dedicated log server helps prevent attackers from easily modifying local logs to avoid detection.
Never log in as the root user unless absolutely necessary. It is recommended that administrators use sudo to execute commands as root when required. Users capable of running sudo are specified in /etc/sudoers. Use the visudo utility to edit /etc/sudoers.

4.1. Tips, Guides, and Tools

The United States' National Security Agency (NSA) provides hardening guides and tips for many different operating systems, to help government agencies, businesses, and individuals secure their systems against attack. The following guides (in PDF format) provide guidance for Red Hat Enterprise Linux 6:

Note

References to Red Hat Enterprise Linux 5 hardening guides are provided in this document until hardening guides for Red Hat Enterprise Linux 6 can be made available. In the meantime, please note that the hardening guides for Red Hat Enterprise Linux 5 may not apply completely to Red Hat Enterprise Linux 6.

The Defense Information Systems Agency (DISA) provides documentation, checklists, and tests to help secure your system (Information Assurance Support Environment).

Chapter 5. Secure Installation

5.1. Disk Partitions
5.2. Utilize LUKS Partition Encryption

Security begins with the first time you put that CD or DVD into your disk drive to install Red Hat Enterprise Linux. Configuring your system securely from the beginning makes it easier to implement additional security settings later.

5.1. Disk Partitions

The NSA recommends creating separate partitions for /boot, /, /home, /tmp, and /var/tmp. The reasons for each are different and we will address each partition.

/boot - This partition is the first partition that is read by the system during boot up. The boot loader and kernel images that are used to boot your system into Red Hat Enterprise Linux are stored in this partition. This partition should not be encrypted. If this partition is included in / and that partition is encrypted or otherwise becomes unavailable then your system will not be able to boot.

/home - When user data (/home) is stored in / instead of in a separate partition, the partition can fill up causing the operating system to become unstable. Also, when upgrading your system to the next version of Red Hat Enterprise Linux it is a lot easier when you can keep your data in the /home partition as it will not be overwritten during installation. If the root partition (/) becomes corrupt your data could be lost forever. By using a separate partition there is slightly more protection against data loss. You can also target this partition for frequent backups.

/tmp and /var/tmp - Both the /tmp and the /var/tmp directories are used to store data that doesn't need to be stored for a long period of time. However if a lot of data floods one of these directories it can consume all of your storage space. If this happens and these directories are stored within / then your system could become unstable and crash. For this reason, moving these directories into their own partitions is a good idea.

5.2. Utilize LUKS Partition Encryption

During the installation process an option to encrypt your partitions will be presented to the user. The user must supply a passphrase that will be the key to unlock the bulk encryption key that will be used to secure the partition's data.

Chapter 6. Software Maintenance

6.1. Install Minimal Software
6.2. Plan and Configure Security Updates
6.3. Adjusting Automatic Updates
6.4. Install Signed Packages from Well Known Repositories

Software maintenance is extremely important to maintaining a secure system. It is vital to patch software as soon as it becomes available in order to prevent attackers from using known holes to infiltrate your system.

6.1. Install Minimal Software

It is best practice to install only the packages you will use because each piece of software on your computer could possibly contain a vulnerability. If you are installing from the DVD media take the opportunity to select exactly what packages you want to install during the installation. When you find you need another package, you can always add it to the system later.

For more information on minimal installation, refer to Section 9.17., "Package Group Selection" of the Red Hat Enterprise Linux 6 Installation Guide. A minimal installation can also be performed via a kickstart file using the --nobase option. For more information, refer to Section 32.5., "Package Selection" of the Red Hat Enterprise Linux 6 Installation Guide.

6.2. Plan and Configure Security Updates

All software contains bugs. Often, these bugs can result in a vulnerability that can expose your system to malicious users. Unpatched systems are a common cause of computer intrusions. You should have a plan to install security patches in a timely manner to close those vulnerabilities so they can not be exploited.

For home users, security updates should be installed as soon as possible. Configuring automatic installation of security updates is one way to avoid having to remember, but does carry a slight risk that something can cause a conflict with your configuration or with other software on the system.

For business or advanced home users, security updates should be tested and scheduled for installation. Additional controls will need to be used to protect the system during the time between the patch release and its installation on the system. These controls would depend on the exact vulnerability, but could include additional firewall rules, the use of external firewalls, or changes in software settings.

6.3. Adjusting Automatic Updates

Red Hat Enterprise Linux is configured to apply all updates on a daily schedule. If you want to change how your system installs updates, you must do so via Software Update Preferences. You can change the schedule, the type of updates to apply, or to notify you of available updates.

In GNOME, you can find controls for your updates at: System ⤍ Preferences ⤍ Software Updates. In KDE, it is located at: Applications ⤍ Settings ⤍ Software Updates.

6.4. Install Signed Packages from Well Known Repositories

Software packages are published through repositories. All well known repositories support package signing. Package signing uses public key technology to prove that the package that was published by the repository has not been changed since the signature was applied. This provides some protection against installing software that may have been maliciously altered after the package was created but before you downloaded it.

Using too many repositories, untrustworthy repositories, or repositories with unsigned packages has a higher risk of introducing malicious or vulnerable code into your system. Use caution when adding repositories to yum/software update.

Chapter 7. Federal Standards and Regulations

7.1. Introduction

7.2. Federal Information Processing Standard (FIPS)

7.2.1. Enabling FIPS Mode

7.3. National Industrial Security Program Operating Manual (NISPOM)

7.4. Payment Card Industry Data Security Standard (PCI DSS)

7.5. Security Technical Implementation Guide

7.1. Introduction

In order to maintain security levels, it is possible for your organization to make efforts to comply with federal and industry security specifications, standards and regulations. This chapter describes some of these standards and regulations.

7.2. Federal Information Processing Standard (FIPS)

The Federal Information Processing Standard (FIPS) Publicaton 140-2, is a computer security standard, developed by a U.S. Government and industry working group to validate the quality of cryptographic modules. FIPS publications (including 140-2) can be found at the following URL: http://csrc.nist.gov/publications/PubsFIPS.html. Note that at the time of writing, Publication 140-3 is at Draft status, and may not represent the completed standard. The FIPS standard provides four (4) security levels, to ensure adequate coverage of different industries, implementations of cryptographic modules and organizational sizes and requirements. These levels are described below:

Level 1 - Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one Approved algorithm or Approved security function shall be used). No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. An example of a Security Level 1 cryptographic module is a personal computer (PC) encryption board.
Level 2 - Security Level 2 enhances the physical security mechanisms of a Security Level 1 cryptographic module by adding the requirement for tamper-evidence, which includes the use of tamper-evident coatings or seals or for pick-resistant locks on removable covers or doors of the module. Tamper-evident coatings or seals are placed on a cryptographic module so that the coating or seal must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module. Tamper-evident seals or pick-resistant locks are placed on covers or doors to protect against unauthorized physical access.
Level 3 - In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.
Level 4 - Security Level 4 provides the highest level of security defined in this standard. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of all plaintext CSPs. Security Level 4 cryptographic modules are useful for operation in physically unprotected environments.

Refer to the full FIPS 140-2 standard at http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf for further details on these levels and the other specifications of the FIPS standard.

7.2.1. Enabling FIPS Mode

To make Red Hat Enterprise Linux 6 compliant with the Federal Information Processing Standard (FIPS) Publication 140-2 you need to make several changes to ensure that accredited cryptographic modules are used. To turn your system (kernel and user space) into FIPS mode, follow these steps:

For proper operation of the in-module integrity verification, the prelink has to be disabled. This can be done by setting configuring PRELINKING=no in the /etc/sysconfig/prelink configuration file. Existing prelinking, if any, should be undone on all system files using the prelink -u -a command.
Next, install the dracut-fips package:
```
~]# yum install dracut-fips
```
Recreate the initramfs file:
```
~]# dracut -f
```
Warning
This operation will overwrite the existing initramfs file.
Modify the kernel command line of the current kernel in the /boot/grub/grub.conf file by adding the following option:
```
fips=1
```
Note
If /boot or /boot/efi reside on separate partitions, the kernel parameter boot=<partition of /boot or /boot/efi> must be added to the kernel command line. Partitions can be identified with the df /boot or df /boot/efi command respectively. For example:
```
~]$ df /bootFilesystem   1K-blocks  Used Available Use% Mounted on/dev/sda1   495844 53780 416464  12% /boot
```
In the example above, the /boot partition is located on /dev/sda1. Therefore, the following string needs to be appended to the kernel command line:
```
boot=/dev/sda1
```
Reboot your system.

Should you require strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel command line during system installation so that key generation is done with FIPS approved algorithms and continuous monitoring tests in place. Users should also ensure that the system has plenty of entropy during the installation process by moving the mouse around, or if no mouse is available, ensuring that many keystrokes are typed. The recommended amount of keystrokes is 256 and more. Less than 256 keystrokes may generate a non-unique key.

7.3. National Industrial Security Program Operating Manual (NISPOM)

The NISPOM (also called DoD 5220.22-M), as a component of the National Industrial Security Program (NISP), establishes a series of procedures and requirements for all government contractors with regard to classified information. The current NISPOM is dated February 28, 2006. The NISPOM document can be downloaded from the following URL: https://www.dss.mil/GW/ShowBinary/DSS/isp/fac_clear/download_nispom.html.

7.4. Payment Card Industry Data Security Standard (PCI DSS)

From https://www.pcisecuritystandards.org/about/index.shtml: The PCI Security Standards Council is an open global forum, launched in 2006, that is responsible for the development, management, education, and awareness of the PCI Security Standards, including the Data Security Standard (DSS).

You can download the PCI DSS standard from https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml.

7.5. Security Technical Implementation Guide

A Security Technical Implementation Guide or STIG is a methodology for standardized secure installation and maintenance of computer software and hardware.

Refer to the following URL for more information on STIG: http://iase.disa.mil/stigs/index.html .

Chapter 8. References

The following references are pointers to additional information that is relevant to SELinux and Red Hat Enterprise Linux but beyond the scope of this guide. Note that due to the rapid development of SELinux, some of this material may only apply to specific releases of Red Hat Enterprise Linux.

Books

SELinux by Example: Mayer, MacMillan, and Caplan
Prentice Hall, 2007

Tutorials and Help

Understanding and Customizing the Apache HTTP SELinux Policy: http://docs.fedoraproject.org/selinux-apache-fc3/
Tutorials and talks from Russell Coker: http://www.coker.com.au/selinux/talks/ibmtu-2004/
Generic Writing SELinux policy HOWTO: http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html
Red Hat Knowledgebase: http://kbase.redhat.com/

General Information

NSA SELinux main website: http://www.nsa.gov/selinux/
NSA SELinux FAQ: http://www.nsa.gov/selinux/info/faq.cfm
Fedora SELinux FAQ: http://docs.fedoraproject.org/selinux-faq/
SELinux NSA's Open Source Security Enhanced Linux: http://www.oreilly.com/catalog/selinux/

Technology

An Overview of Object Classes and Permissions: http://www.tresys.com/selinux/obj_perms_help.html
Integrating Flexible Support for Security Policies into the Linux Operating System (a history of Flask implementation in Linux): http://www.nsa.gov/research/_files/selinux/papers/selsymp2005.pdf
Implementing SELinux as a Linux Security Module: http://www.nsa.gov/research/_files/publications/implementing_selinux.pdf
A Security Policy Configuration for the Security-Enhanced Linux: http://www.nsa.gov/research/_files/selinux/papers/policy/policy.shtml

Community

Fedora SELinux User Guide: http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/
Fedora SELinux Managing Confined Services Guide: http://docs.fedoraproject.org/en-US/Fedora/13/html/Managing_Confined_Services/
SELinux community page: http://selinuxproject.org/
IRC: irc.freenode.net, #selinux, #fedora-selinux, #security

History

Quick history of Flask: http://www.cs.utah.edu/flux/fluke/html/flask.html
Full background on Fluke: http://www.cs.utah.edu/flux/fluke/html/index.html

Encryption Standards

A.1. Synchronous Encryption

A.1.1. Advanced Encryption Standard - AES

In cryptography, the Advanced Encryption Standard (AES) is an encryption standard adopted by the U.S. government. The standard comprises three block ciphers, AES-128, AES-192 and AES-256, adopted from a larger collection originally published as Rijndael. Each AES cipher has a 128-bit block size, with key sizes of 128, 192 and 256 bits, respectively. The AES ciphers have been analyzed extensively and are now used worldwide, as was the case with its predecessor, the Data Encryption Standard (DES).^[13]

A.1.1.1. AES History

AES was announced by National Institute of Standards and Technology (NIST) as U.S. FIPS PUB 197 (FIPS 197) on November 26, 2001 after a 5-year standardization process in which fifteen competing designs were presented and evaluated before Rijndael was selected as the most suitable (see Advanced Encryption Standard process for more details). It became effective as a standard May 26, 2002. It is available in many different encryption packages. AES is the first publicly accessible and open cipher approved by the NSA for top secret information (see Security of AES, below).^[14]

The Rijndael cipher was developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, and submitted by them to the AES selection process. Rijndael (pronounced [rɛindaːl]) is a portmanteau of the names of the two inventors.^[15]

A.1.2. Data Encryption Standard - DES

The Data Encryption Standard (DES) is a block cipher (a form of shared secret encryption) that was selected by the National Bureau of Standards as an official Federal Information Processing Standard (FIPS) for the United States in 1976 and which has subsequently enjoyed widespread use internationally. It is based on a symmetric-key algorithm that uses a 56-bit key. The algorithm was initially controversial with classified design elements, a relatively short key length, and suspicions about a National Security Agency (NSA) backdoor. DES consequently came under intense academic scrutiny which motivated the modern understanding of block ciphers and their cryptanalysis.^[16]

A.1.2.1. DES History

DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key size being too small; in January, 1999, distributed.net and the Electronic Frontier Foundation collaborated to publicly break a DES key in 22 hours and 15 minutes (see chronology). There are also some analytical results which demonstrate theoretical weaknesses in the cipher, although they are unfeasible to mount in practice. The algorithm is believed to be practically secure in the form of Triple DES, although there are theoretical attacks. In recent years, the cipher has been superseded by the Advanced Encryption Standard (AES).^[17]

In some documentation, a distinction is made between DES as a standard and DES the algorithm which is referred to as the DEA (the Data Encryption Algorithm). When spoken, "DES" is either spelled out as an abbreviation (/ˌdiːˌiːˈɛs/), or pronounced as a one-syllable acronym (/ˈdɛz/).^[18]

A.2. Public-key Encryption

Public-key cryptography is a cryptographic approach, employed by many cryptographic algorithms and cryptosystems, whose distinguishing characteristic is the use of asymmetric key algorithms instead of or in addition to symmetric key algorithms. Using the techniques of public key-private key cryptography, many methods of protecting communications or authenticating messages formerly unknown have become practical. They do not require a secure initial exchange of one or more secret keys as is required when using symmetric key algorithms. It can also be used to create digital signatures.^[19]

Public key cryptography is a fundamental and widely used technology around the world, and is the approach which underlies such Internet standards as Transport Layer Security (TLS) (successor to SSL), PGP and GPG.^[20]

The distinguishing technique used in public key cryptography is the use of asymmetric key algorithms, where the key used to encrypt a message is not the same as the key used to decrypt it. Each user has a pair of cryptographic keys - a public key and a private key. The private key is kept secret, whilst the public key may be widely distributed. Messages are encrypted with the recipient's public key and can only be decrypted with the corresponding private key. The keys are related mathematically, but the private key cannot be feasibly (ie, in actual or projected practice) derived from the public key. It was the discovery of such algorithms which revolutionized the practice of cryptography beginning in the middle 1970s.^[21]

In contrast, Symmetric-key algorithms, variations of which have been used for some thousands of years, use a single secret key shared by sender and receiver (which must also be kept private, thus accounting for the ambiguity of the common terminology) for both encryption and decryption. To use a symmetric encryption scheme, the sender and receiver must securely share a key in advance.^[22]

Because symmetric key algorithms are nearly always much less computationally intensive, it is common to exchange a key using a key-exchange algorithm and transmit data using that key and a symmetric key algorithm. PGP, and the SSL/TLS family of schemes do this, for instance, and are called hybrid cryptosystems in consequence.^[23]

A.2.1. Diffie-Hellman

Diffie-Hellman key exchange (D-H) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.^[24]

A.2.1.1. Diffie-Hellman History

The scheme was first published by Whitfield Diffie and Martin Hellman in 1976, although it later emerged that it had been separately invented a few years earlier within GCHQ, the British signals intelligence agency, by Malcolm J. Williamson but was kept classified. In 2002, Hellman suggested the algorithm be called Diffie-Hellman-Merkle key exchange in recognition of Ralph Merkle's contribution to the invention of public-key cryptography (Hellman, 2002).^[25]

Although Diffie-Hellman key agreement itself is an anonymous (non-authenticated) key-agreement protocol, it provides the basis for a variety of authenticated protocols, and is used to provide perfect forward secrecy in Transport Layer Security's ephemeral modes (referred to as EDH or DHE depending on the cipher suite).^[26]

U.S. Patent 4,200,770, now expired, describes the algorithm and credits Hellman, Diffie, and Merkle as inventors.^[27]

A.2.2. RSA

In cryptography, RSA (which stands for Rivest, Shamir and Adleman who first publicly described it; see below) is an algorithm for public-key cryptography. It is the first algorithm known to be suitable for signing as well as encryption, and was one of the first great advances in public key cryptography. RSA is widely used in electronic commerce protocols, and is believed to be secure given sufficiently long keys and the use of up-to-date implementations.

A.2.3. DSA

DSA (Digital Signature Algorithm) is a standard for digital signatures, a United States federal government standard for digital signatures. DSA is for signatures only and is not an encryption algorithm. ^[28]

A.2.4. SSL/TLS

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end.

Several versions of the protocols are in widespread use in applications like web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).^[29]

A.2.5. Cramer-Shoup Cryptosystem

The Cramer-Shoup system is an asymmetric key encryption algorithm, and was the first efficient scheme proven to be secure against adaptive chosen ciphertext attack using standard cryptographic assumptions. Its security is based on the computational intractability (widely assumed, but not proved) of the decisional Diffie-Hellman assumption. Developed by Ronald Cramer and Victor Shoup in 1998, it is an extension of the Elgamal cryptosystem. In contrast to Elgamal, which is extremely malleable, Cramer-Shoup adds additional elements to ensure non-malleability even against a resourceful attacker. This non-malleability is achieved through the use of a collision-resistant hash function and additional computations, resulting in a ciphertext which is twice as large as in Elgamal.^[30]

A.2.6. ElGamal Encryption

In cryptography, the ElGamal encryption system is an asymmetric key encryption algorithm for public-key cryptography which is based on the Diffie-Hellman key agreement. It was described by Taher Elgamal in 1985. ElGamal encryption is used in the free GNU Privacy Guard software, recent versions of PGP, and other cryptosystems.^[31]

^[13]"Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

^[14]"Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

^[15]"Advanced Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

^[16]"Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard

^[17]"Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard

^[18]"Data Encryption Standard." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Data_Encryption_Standard

^[19]"Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography

^[20]"Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography

^[21]"Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography

^[22]"Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography

^[23]"Public-key Encryption." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Public-key_cryptography

^[24]"Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman

^[25]"Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman

^[26]"Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman

^[27]"Diffie-Hellman." Wikipedia. 14 November 2009 http://en.wikipedia.org/wiki/Diffie-Hellman

^[28]"DSA." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

^[29]"TLS/SSL." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/Transport_Layer_Security

^[30]"Cramer-Shoup cryptosystem." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/Cramer-Shoup_cryptosystem

^[31]"ElGamal encryption" Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/ElGamal_encryption

Revision History

Revision History

Revision 1-9

Feb 21 2013

Martin Prpič

Release of the Security Guide for Red Hat Enterprise Linux 6.4

Revision 1-8.25

Jun 20 2012

Martin Prpič

Release of the Security Guide for Red Hat Enterprise Linux 6.3

Revision 1-7

Dec 6 2011

Martin Prpič

Release of the Security Guide for Red Hat Enterprise Linux 6.2

Revision 1-6

Aug 05 2011

Paul Kennedy

Resolves BZ#702249, broken link.

Revision 1-5

Apr 19 2010

Scott Radvan

Minor fixes, final build for Beta

Revision 1-4

Mar 5 2010

Scott Radvan

QE Review and Updates

Revision 1-3

Feb 19 2010

Scott Radvan

Push to testing area ready for review.

Source : http://www.redhat.com

(Sebelumnya) 6 : 2.7. Virtual Private Netwo ...

7 : Power Management Guide (Berikutnya)