Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Security and Hardening Guide › Network security › Enabling compliance with FIPS 140-2
ContentsContents
Security and Hardening Guide
  1. Preface
  2. 1 Security and confidentiality
  3. 2 Common Criteria
  4. I Authentication
    1. 3 Authentication with PAM
    2. 4 Using NIS
    3. 5 Setting up authentication clients using YaST
    4. 6 LDAP with 389 Directory Server
    5. 7 Network authentication with Kerberos
    6. 8 Active Directory support
    7. 9 Setting up a freeRADIUS server
  5. II Local security
    1. 10 Physical security
    2. 11 Software management
    3. 12 File management
    4. 13 Encrypting partitions and files
    5. 14 Storage encryption for hosted applications with cryptctl
    6. 15 User management
    7. 16 Restricting cron and at
    8. 17 Spectre/Meltdown checker
    9. 18 Configuring security settings with YaST
    10. 19 Authorization with PolKit
    11. 20 Access control lists in Linux
    12. 21 Intrusion detection with AIDE
  6. III Network security
    1. 22 X Window System and X authentication
    2. 23 Securing network operations with OpenSSH
    3. 24 Masquerading and firewalls
    4. 25 Configuring a VPN server
    5. 26 Managing a PKI with XCA, X certificate and key manager
    6. 27 Improving network security with sysctl variables
    7. 28 Enabling compliance with FIPS 140-2
  7. IV Confining privileges with AppArmor
    1. 29 Introducing AppArmor
    2. 30 Getting started
    3. 31 Immunizing programs
    4. 32 Profile components and syntax
    5. 33 AppArmor profile repositories
    6. 34 Building and managing profiles with YaST
    7. 35 Building profiles from the command line
    8. 36 Profiling your Web applications using ChangeHat
    9. 37 Confining users with pam_apparmor
    10. 38 Managing profiled applications
    11. 39 Support
    12. 40 AppArmor glossary
  8. V SELinux
    1. 41 Configuring SELinux
  9. VI The Linux Audit Framework
    1. 42 Understanding Linux audit
    2. 43 Setting up the Linux audit framework
    3. 44 Introducing an audit rule set
    4. 45 Useful resources
  10. A GNU licenses
Navigation←→
Security and Hardening Guide › Network security › Enabling compliance with FIPS 140-2
Top
←→
Applies to openSUSE Leap 15.3

28 Enabling compliance with FIPS 140-2 Edit source

Abstract

If your organization does any work for the United States federal government, it is likely that your cryptography applications (such as openSSL, GnuTLS, and OpenJDK) will be required to be in compliance with Federal Information Processing Standards (FIPS) 140-2. FIPS 140-2 is a security accreditation program for validating cryptographic modules produced by private companies. If your organization is not required by compliance rules to run SUSE Linux Enterprise in FIPS mode, it is most likely best to not do it. This chapter provides guidance on enabling FIPS mode, and links to resources with detailed information.

28.1 FIPS 140-2 overview
28.2 When to enable FIPS mode
28.3 Installing FIPS
28.4 Enabling FIPS mode
28.5 MD5 not supported in Samba/CIFS

28.1 FIPS 140-2 overview Edit source

Warning
Warning: FIPS requires expertise

Administering FIPS is complex and requires significant expertise. Implementing it correctly, testing, and troubleshooting all require a high degree of knowledge.

Every vendor that develops and maintains cryptographic applications, and wants them to be tested for FIPS compliance, must submit them to the Cryptographic Module Validation Program (CMVP) (see https://csrc.nist.gov/projects/cryptographic-module-validation-program).

There are currently two FIPS cryptographic standards, FIPS 140-2 and FIPS 140-3. The FIPS 140-2 standard was finalized in 2002, and is valid until September 22, 2026. The FIPS 140-3 standard was approved in March 2019, and is replacing 140-2. CMVP is no longer accepting modules for FIPS 140-2 testing, but only FIPS 140-3.

SUSE maintains a list of certified modules at https://www.suse.com/support/security/certifications/, along with a lot of other useful information.

28.2 When to enable FIPS mode Edit source

The use case for enabling FIPS mode on SUSE Linux Enterprise is simple: run your server in FIPS mode it when it is required to meet compliance rules.

When you are not required to meet compliance rules, running your systems in FIPS mode is most likely not a good idea. These are some of the reasons to not use FIPS mode:

  • FIPS is restrictive. It enforces the use of specific validated cryptographic algorithms, and specific certified binaries that implement these validated algorithms. You must use only the certified binaries.

  • Upgrades may break functionality.

  • The approval process is very long, so certified binaries are always several releases behind the newest release.

  • Certified binaries, such as ssh, sshd, and sftp-server, run their own self-checks at startup, and run only when these checks succeed. This creates some small performance degradation.

  • Administering FIPS is complex and requires significant expertise.

28.3 Installing FIPS Edit source

It is best to install the patterns-server-enterprise-fips pattern on a new installation. Then, after the installation is complete, enable FIPS mode by running the steps in Section 28.4, “Enabling FIPS mode”.

You may install patterns-server-enterprise-fips and enable FIPS mode on a running system, but then it is likely you will have to make adjustments, such as regenerating keys, and auditing your setup to ensure it is set up correctly.

28.4 Enabling FIPS mode Edit source

Enabling FIPS takes a few steps. First, read the /usr/share/doc/packages/openssh-common/README.FIPS and /usr/share/doc/packages/openssh-common/README.SUSE files, from the openssh-common package. These contain important information about FIPS on SUSE Linux Enterprise.

Check if FIPS is already enabled: 

> sudo sysctl -a | grep fips
crypto.fips_enabled = 0

crypto.fips_enabled = 0 indicates that it is not enabled. A return value of 1 means that it is enabled.

Then edit /etc/default/grub. If /boot is not on a separate partition, add fips=1 to GRUB_CMDLINE_LINUX_DEFAULT, like the following example: 

GRUB_CMDLINE_LINUX_DEFAULT="splash=silent mitigations=auto quiet fips=1"

If /boot is on a separate partition, specify which partition, like the following example, substituting the name of your boot partition: 

GRUB_CMDLINE_LINUX_DEFAULT="splash=silent mitigations=auto quiet fips=1 boot=/dev/sda1"

Save your changes, and rebuild your GRUB configuration and initramfs image (replace NAME with the name of the current initrd and KERNELVERSION with the currently running kernel): 

> sudo grub2-mkconfig -o /boot/grub2/grub.cfg
> sudo mkinitrd

Reboot, then verify your changes. The following example shows that FIPS is enabled: 

> sudo sysctl -a | grep fips
crypto.fips_enabled = 1

After enabling FIPS it is possible that your system will not boot. If this happens, reboot to bring up the GRUB menu. Press E to edit your boot entry, and delete the fips entry from the linux line. Press the F10 key to boot. This is a temporary change, and most likely the problem is an error in /etc/default/grub. Correct it, rebuild GRUB and initramfs, then reboot.

28.5 MD5 not supported in Samba/CIFS Edit source

According to the FIPS standards, MD5 is not a secure hashing algorithm, and it must not be used for authentication. If you run a FIPS-compliant network environment, and you have clients or servers that run in FIPS-compliant mode, you must use a Kerberos service for authenticating Samba/CIFS users. This is necessary as all other Samba authentication modes include MD5.

See the Samba section of the Storage Administration Guide for more information on running a Samba server.

→Part IV Confining privileges with AppArmor←Chapter 27 Improving network security with sysctl variables
Print this page

© 2022 SUSE