A clear definition of security in IT products is challenging. Security should be considered a process that never ends, not a static condition that can be met or not. A Common Criteria certificate (below EAL7) does not make a clear statement about the error-proneness of the system, but it adds an important value to the product that cannot be described with the presence of technology alone: That someone has independently inspected the design of the system in such way that it corresponds to the claims that are made, and that explicit care has been taken in producing and maintaining the product.

The certificate states a degree of maturity of both the product with its security functions and the processes of the company that has designed, built and engineered the product, and that will maintain the product across its lifecycle. As such, Common Criteria aims to be fairly holistic with its approach to take everything into account that is relevant for the security of an IT product.

The Evaluation Assurance Level denotes the degree of confidence that the product fulfills the described claims. The levels are from 1 through 7:

While EAL1 only provides basic assurance for products to meet security requirements, EAL2 to 4 are medium assurance levels. EAL5-EAL7 describe medium-to-high and high assurance. EAL4 is expected to be the highest level of assurance that a product can have if it has not been designed from the start to achieve a higher level of assurance.

Much of the advice in this guide is based on the following guidelines. Consider them when defining your own security processes or deciding about configurations that are not explicitly covered here.

The Common Criteria evaluations inspect a specific configuration of the product in an evaluated setup. How to install and configure the reference system that was used as baseline in the Common Criteria evaluation is documented in the “Administrator's Guide” part of the Common Criteria evaluation documentation.

However, it would be incorrect to understand the evaluated configuration as a hardened configuration. The removal of setuid bits and the prescription of administrative procedures after installation help to reach a specific configuration that is sane. But this is not sufficient for a hardening claim.

Physical security should be one of the utmost concerns. Linux production servers should be in locked data centers where only people have access that have passed security checks. Depending on the environment and circumstances, you can also consider boot loader passwords.

Additionally, consider questions like:

The amount of physical security needed on a particular system depends on the situation, and can also vary widely by available funds.

Tip: Secure Boot

This section describes only basic methods to secure the boot process. To find out more advanced UEFI and the secure boot feature, see Book “Administration Guide”, Chapter 12 “UEFI (Unified Extensible Firmware Interface)”, Section 12.1 “Secure Boot”.

The BIOS (Basic Input/Output System) or its successor UEFI (Unified Extensible Firmware Interface) is the lowest level of software/firmware that dictates system configuration and low-level hardware. When this document references the BIOS, it usually means BIOS and/or UEFI. GRUB 2 and other Linux boot loaders access the BIOS to determine how to boot the host. Other hardware types (IBM POWER/IBM Z) that run Linux also have low-level software/firmware. Typically the BIOS can be configured to help prevent attackers from being able to reboot the host and manipulate the system.

Most BIOS varieties allow the setting of a boot password. While this does not provide a high level of security (a BIOS can be reset, removed or modified – assuming case access), it can be another deterrent.

Many BIOS capabilities have other various security settings – checking with the system vendor, the system documentation or examine the BIOS during a system boot.

Important: Booting when a BIOS Password is Set

If a system host has been set up with a boot password, the host will not boot up unattended (for example a system reboot, power failure, etc.). This is a trade-off.

The Linux boot loader GRUB 2, which is used by default in SUSE Linux Enterprise Server, can have a boot passwords set. It also provides a password feature, so that only administrators can start the interactive operations (for example editing menu entries and entering the command line interface). If a password is specified, GRUB 2 will disallow any interactive control until you press the key C and E and enter a correct password.

You can refer to the GRUB 2 man page for examples.

It is very important to keep in mind that when setting these passwords they will need to be remembered! Also, enabling these passwords might merely slow an intrusion, not necessarily prevent it. Again, someone could boot from a removable device, and mount your root partition. If you are using BIOS-level security and a boot loader, it is a good practice to disable the ability to boot from removable devices in your computer's BIOS, and then also password-protecting the BIOS itself.

Also keep in mind that the boot loader configuration files will need to be protected by changing their mode to 600 (read/write for root only), or others will be able to read your passwords or hashes!

It is highly recommended to have scripts in place which can verify that security actions or procedures have been run. Even the best systems administrators can make errors or forget something. If you have a small or large Linux installation or environment, you should consider the use of the seccheck scripts.

seccheck is the SUSE Security Checker. It is a set of several shell scripts designed to check the local security of the system on a regular basis. There are three main scripts that are executed at different time intervals. They are security-daily, security-weekly and security-monthly. If seccheck is not installed on your system, install it with sudo zypper in seccheck. These scripts all have schedule entries that get placed in cron that determine when they run. Although cron scheduling is the default behavior, this can be controlled via configuration settings (see next section). The daily script runs at midnight, and if changes are detected since the last run (the night before), an e-mail noting the differences will be sent. The weekly script runs every Monday at 1:00 am, and only if changes to the last run (the week before) are found, a mail with the differences will be sent. The monthly script runs every on every 1st of the month and sends the full last daily and weekly report via e-mail.

SECCHK_USER="firewall" # exchange firewall is an admin user's account name

2.4.2 Automatic Logout #

  

The seccheck package provides an automatic logout feature. It is a script that runs every 10 minutes and checks both remote or local terminal sessions for inactivity, and terminates them if an idle time is exceeded.

You can configure the functionality in the /etc/security/autologout.conf file. Parameters include default idle and logout delay times, and the configuration for limiting maximum idle times specific to users, groups, TTY devices and SSH sessions. /etc/security/autologout.conf also includes several configuration examples.

Tip

The automatic logout feature is not enabled by default. To enable it, edit /etc/cron.d/autologout and uncomment the example cron line.

Security policies usually contain some procedures for the treatment of storage media that is going to be retired or disposed of. Disk and media wipe procedures are frequently prescribed as is complete destruction of the media. You can find several free tools on the Internet. A search of “dod disk wipe utility” will yield several variants. To retire servers with sensitive data, it is important to ensure that data cannot be recovered from the hard disks. To ensure that all traces of data are removed, a wipe utility—such as scrub—can be used. Many wipe utilities overwrite the data several times. This assures that even sophisticated methods are not able to retrieve any parts of the wiped data. Some tools can even be operated from a bootable removable device and remove data according to the U.S. Department of Defense (DoD) standards. Note that many government agencies specify their own standards for data security. Some standards are stronger than others, yet may require more time to implement.

Important: Wiping Wear Leveling Devices

Some devices, like SSDs, use wear leveling and do not necessarily write new data in the same physical locations. Such devices usually provide their own erasing functionality.

If your system is compromised, backups can be used to restore a prior system state. When bugs or accidents occur, backups can also be used to compare the current system against an older version. For production systems, it is very important to take some backups off-site for cases like disasters (for example off-site storage of tapes/recordable media, or off-site initiated).

For legal reasons, some firms and organizations must be careful about backing up too much information and holding it too long. If your environment has a policy regarding the destruction of old paper files, you might need to extend this policy to Linux backup tapes as well.

The rules about physical security of servers apply on backups as well.

Servers should have separate file systems for at least /, /boot, /usr, /var, /tmp, and /home. You do not want that for example logging and temporary space under /var and /tmp fill up the root partition. Third-party applications should be on separate file systems as well, for example under /opt.

You are advised to review Chapter 1, Common Criteria. It is important to understand the need to separate the partitions that could impact a running system (for example, log files filling up /var/log are a good reason to separate /var from the / partition). Another thing to keep in mind is that you will likely need to leverage LVM or another volume manager or at the very least the extended partition type to work around the limitations of primary partitions (4 partitions).

Another capability in SUSE Linux Enterprise Server is encrypting a partition or even a single directory or file as a container. Refer to Book “Security and Hardening Guide”, Chapter 12 “Encrypting Partitions and Files” for details.

iptables will not be covered in detail in this guide. Most companies use dedicated firewalls or appliances to protect their servers in a production network. This is strongly recommended for secure environments. SUSE Linux Enterprise Server also includes SuSEfirewall2 which is a wrapper for iptables and is enabled by default as a simple and layered protection.

If you are also interested in Linux stateful firewalls using iptables, there are many guides on the Internet. See the Appendix for resources. For lots of iptables tutorials and examples, see http://www.linuxguruz.com/iptables/.

The following list shows tunable kernel parameters you can use to secure your Linux server against attacks. Some are defaults already within the SLE distributions. To check the current status of any of these settings, you can query the kernel (/proc/sys/... contents). For example, the Source Routing setting is located in the /proc/sys/net/ipv4/conf/all/accept_source_route file. Simply display the contents of a file to see how the current running kernel is set up.

For each tunable kernel parameter shown, the change to the entry that needs to be affected can be modified or added to the /etc/sysctl.conf configuration file to make the change persistent after a reboots.

You can get a list of current kernel settings by using the command:

root # sysctl -a

It is even a very good idea to store the output of the kernel settings (for comparison or reference) by redirecting the output of the sysctl command to a file, for example

root # sysctl -A > /root/sysctl.settings.store

Because SUSE Linux Enterprise Server includes, by default, security-focused kernel tuning parameters, you will find the existing /etc/sysctl.conf file to be sparsely populated. You may choose to use the above mentioned “catalog” method of storing the complete gamut of kernel settings and then choose those parameters you want to be reset at reboot. You can place these in the /etc/sysctl.conf file where they will be picked up upon a reboot or they can be inserted immediately (into the running kernel) by running the command sysctl -p.

Many third-party applications like Oracle, SAP, DB2, Websphere, etc. recommend changing kernel parameters to ensure high performance for I/O or CPU processing. Having a full list of current settings can be helpful for reference.

2.9.1 Enable TCP SYN Cookie Protection (default in SUSE Linux Enterprise Server 12 SP5) #

  

A SYN attack is a denial-of-service attack that consumes all the resources on a machine. Any server that is connected to a network is potentially subject to this attack. To enable TCP SYN Cookie Protection, edit the /etc/sysctl.conf file and ensure the following line and value exists:

net.ipv4.tcp_syncookies = 1

Note

Despite the name of the configuration option, it applies to IP version 6 as well.

net.ipv4.conf.all.accept_source_route = 0

net.ipv6.conf.all.accept_source_route = 0

net.ipv4.conf.all.accept_redirects = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv4.conf.all.rp_filter = 1

net.ipv4.icmp_echo_ignore_all = 1

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.icmp_ignore_bogus_error_responses = 1

2.9.8 Enable Logging of Spoofed Packets, Source Routed Packets, Redirect Packets #

  

To turn on logging for Spoofed Packets, Source Routed Packets, and Redirect Packets, edit the /etc/sysctl.conf file and add the following line:

net.ipv4.conf.all.log_martians = 1

Note

Because of the way SUSE Linux Enterprise Server is set up (with rsyslog) for network event tracking, keep in mind that this can cause a large amount of messages to be logged.

tux > cat /proc/sys/kernel/randomize_va_space
2

tux > dmesg | grep '[NX|DX]*protection'
[    0.000000] NX (Execute Disable) protection: active

tux > cat /proc/sys/kernel/kptr_restrict
1

tux > cat /proc/sys/fs/protected_hardlinks
1

tux > cat /proc/sys/fs/protected_symlinks
1

Included with SUSE Linux Enterprise Server, AppArmor is an application security tool designed to provide an easy-to-use security framework for your applications. AppArmor proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing a specified behavior and preventing some unknown application flaws from being exploited. AppArmor security policies, called “profiles”, completely define which system resources and files can be accessed by each application. The profiles also define the access mode, for example read or write. Several default profiles are included with AppArmor, and using a combination of advanced static analysis and learning-based tools, AppArmor profiles for even very complex applications can be deployed successfully in a matter of hours.

AppArmor consists of:

It is best to reboot a system after completing installation, so that AppArmor can confine all system daemons.

For additional details and step-by-step instructions on the usage and configuration of AppArmor you can also refer to Book “Security and Hardening Guide”.

SELinux is an advanced technology for securing Linux systems. It is included with “basic enablement” in SUSE Linux Enterprise Server 12 SP5, and is included with some other distributions by default. Hardening Linux using SELinux technology, on its own, warrants its own security HOWTO and is out of scope for this guide. The book SELinux: NSA's Open Source Security Enhanced Linux contains a very good description of its setup and usage. As part of the “basic enablement”, SELinux will not be officially supported, but packages have now been added to SUSE Linux Enterprise Server 12 SP5 to enable its usage with minimal effort. While AppArmor is much easier to use and has a similar feature set, knowing both will most certainly be beneficial.

The programs/protocols of FTP, telnet, and rlogin (rsh) are vulnerable to eavesdropping, which is one of the main reasons secure alternatives such as ssh, scp or sftp should be used instead. It is highly recommended not to run these insecure services. Because of the high risk, this guide does not cover these services (other than vsftp). It would also be a good idea (and part of our guidance, see next section) not to have FTP and Telnet server RPMs installed on the system. Note that the EAL 4+ evaluation had vsftp installed. The “vs” stands for “very secure”, which is a differentiator here when compared to normal FTP.

A very important step in securing a Linux system is to determine the primary function(s) or role(s) of the Linux server. Otherwise, it can be difficult to understand what needs to be secured and securing these Linux systems can prove ineffective. Therefore, it is critical to look at the default list of software packages and remove any unnecessary packages or packages that do not comply with your defined security policies.

Generally, an RPM software package consists of the following:

Packages generally do not impose any security risk to the system unless they contain:

Assuming that neither of the three conditions above apply, a package is merely a collection of files. Neither installation nor deinstallation of such packages has influence on the security value of the system.

Nevertheless, it is useful to restrict the installed packages in your system to a minimum. Doing this will result in fewer packages that require updates and will simplify maintenance efforts when security alerts and patches are released. It is a best practice not to install, among others, development packages or desktop software packages (for example, an X Server) on production servers. If you do not need them, you should also not install, for example, the Apache Web server or Samba file sharing server.

Important: Requirements of Third-party Installers

Many third-party vendors like Oracle and IBM require a desktop environment and development libraries to run installers. To avoid this from having an impact on the security of their production servers, many organizations work around this by creating a silent installation (response file) in a development lab.

Also, other packages like FTP and Telnet daemons should not be installed as well unless there is a justified business reason for it (again, ssh, scp or sftp should be used as replacements).

One of the first action items should be to create a Linux image that only contains RPMs needed by the system and applications, and those needed for maintenance and troubleshooting purposes. A good approach is to start with a minimum list of RPMs and then add packages as needed. This process is time-consuming but usually worth the effort.

Tip: Just Enough Operating System (JeOS)

The SUSE Appliance Program includes a component called JeOS (Just Enough Operating System). JeOS has a very small footprint and can be customized to fit the specific needs of a system developer. Main uses of JeOS are for hardware/software appliance or virtual machine development. Key benefits of JeOS are efficiency, higher performance, increased security and simplified management.

If JeOS is not an option for you, a good choice is the minimal installation pattern.

To generate a list of all installed RPMs, use the following command:

root # rpm -qa

To retrieve details about a particular RPM (from the RPM itself), run:

root # rpm -qi PACKAGE_NAME

To check for and report potential conflicts and dependencies when deleting an RPM, run:

root # rpm -e --test PACKAGE_NAME

This can be very useful, as running the removal command without a test can often yield a mass of complaints and require manual recursive dependency hunting.

Building an infrastructure for patch management is another very important part of a proactive and secure production Linux environment.

It is recommended to have a written security policy and procedure to handle Linux security updates and issues. For example, a security policy should detail the time frame for assessment, testing, and roll out of patches. Network related security vulnerabilities should get the highest priority and should be addressed immediately within a short time frame. The assessment phase should occur within a testing lab, and initial roll out should occur on development systems first

A separate security log file should contain details on which Linux security announcements have been received, which patches have been researched and assessed, when patches have been applied, etc.

SUSE releases their patches in three categories, security, recommended and optional. There are a few options that can be used to keep systems patched, up to date and secure. Each system can register and then retrieve updates via the SUSE Update Web site using the included YaST tool—YaST Online Update. SUSE has also created the Subscription Management Tool (SMT), an efficient way to maintain a local repository of available/released patches/updates/fixes that systems can then pull from (reducing Internet traffic). SUSE also offers SUSE Manager for the maintenance, patching, reporting and centralized management of Linux systems, not only SUSE, but other distributions as well.

Securing a server requires that you know what it is serving; what services are running. Default server installations may have services running that aren't self apparent and open network ports that they are using. So, one of the most important tasks is to detect and close network ports that are not needed. To get a list of listening network ports (TCP and UDP sockets), you can use the netstat service run the following command:

root # netstat -tulp

Be aware that netstat output can be wider than a default terminal screen. If the screen is too narrow, the options described above will likely cause the output to wrap and be less legible.

Below is an example of output from the above command:

Proto Recv-Q Send-Q Local            Foreign         State   PID/Program
                    Address          Address                 name
tcp   0      0      *:auth           *.*             LISTEN  2328/xinetd
tcp   0      0      local[...].:smtp *.*             LISTEN  2360/sendmail:acce
tcp   0      0      *:ssh            *.*             LISTEN  2317/sshd

From the output above you can see that three TCP-based services are running and listening: xinetd, sendmail, and sshd. Sendmail should not be configured to listen for incoming network connections unless the server running it is a designated as a mail or relay server. Running a port scan from another server can confirm that, but make sure to obtain proper permissions to scan/probe a machine on a production network.

Important

Some organizations consider port scans without permission a security offense.

Using the Nmap tool, such a probe/scan can be run:

root # nmap -sTU REMOTE_HOST
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2004-12-10 22:51 CST
Interesting ports on venus (192.168.2.101):
(The 3131 ports scanned but not shown below are in state: closed)
PORT     STATE         SERVICE
22/tcp   open          ssh
113/tcp  open          auth

Nmap run completed -- 1 IP address (1 host up) scanned in 221.669 seconds

Note that running the nmap command can take quite a while (in this example almost 4 minutes) depending on the options used. If you remove the UDP port scan (leave out the -U option), then nmap will finish the port scan nearly immediately. The results of nmap can vary widely and might not show all listening network sockets depending on the status of the SuSEfirewall2 (or other) and if it has been set up to block any ports.

From the sample run above, you see that the xinetd daemon is listening on port auth (port 113) for IDENT (for more information on this service, see Section 2.16, “xinetd Services - Disabling”). You can also see that sendmail is not listening for remote incoming network connections.

Another method to list all of the TCP and UDP sockets to which programs are listening (on a host) is to use the lsof command – which lists open files:

root # lsof -i -n | egrep 'COMMAND|LISTEN|UDP'
COMMAND  PID   USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
sshd     2317  root   3u   IPv6    6579   0t0      TCP *:ssh (LISTEN)
xinetd   2328  root   5u   IPv4    6698   0t0      TCP *:auth (LISTEN)
sendmail 2360  root   3u   IPv4    6729   0t0      TCP 127.0.0.1:smtp (LISTEN)

The xinetd daemon is a replacement for inetd, the Internet services daemon. It monitors the ports for all network services configured in /etc/xinetd.d, and starts the services in response to incoming connections. To check if xinetd is enabled and running, execute:

root # systemctl status xinetd

To check the current status of the xinetd service, execute:

root # systemctl status xinetd

If xinetd is active, it is very important to see which services are active and being controlled by xinetd. The following command will list all services configured in /etc/xinetd.d and whether xinetd monitors the ports for these services:

root # chkconfig -list | awk '/xinetd based services/,/""/'
xinetd based services:

  chargen:     off
  chargen-udp: off
  cups-lpd:    off
  cvs:         off
  daytime:     off
  daytime-udp: off
  discard:     off
  discard-udp: off
  echo:        off
  echo-udp:    off
  netstat:     off
  rsync:       off
  sane-port:   off
  servers:     off
  services:    off
  svnserve:    off
  swat:        off
  systat:      off
  tftp:        on
  time:        off
  time-udp:    off
  vnc:         off

To get a list of only active services for which xinetd monitors the ports, you could run (where the -v option of grep does an inverse-match) :

root # chkconfig --list | awk '/xinetd based services/,/""/' | grep -v off
xinetd based services:

  tftp:        on

In the above example you can see that the telnet-server package is not installed on the system. If the Telnet Server package telnet-server would be installed, it would show up on the list whether it is active. Here is an example how to disable a service. Assuming the tftp service is active, run the following commands to disable it and to see how the telnet service entries are being updated:

tux > sudo systemctl status tftp
tftp.service - Tftp Server
Loaded: loaded (/usr/lib/systemd/system/tftp.service; static)
Active: active (running) since Fri 2014-09-05 07:56:23 CEST; 2h 1min ago

# sudo cat /etc/xinetd.d/tftp | grep disable
   disable = no

# sudo systemctl disable tftp

# systemctl status tftp
tftp.service - Tftp Server
Loaded: loaded (/usr/lib/systemd/system/tftp.service; static)
Active: inactive (dead)

# sudo cat /etc/xinetd.d/tftp | grep disable
      disable = yes

For the TFTP service it would be better to remove the package from the system since removal is always safer than disabling (when possible):

root # rpm -e tftp

root # grep " server" /etc/xinetd.d/tftp
  server = /usr/sbin/in.tftpd
  server_args = -s /tftpboot

root # man in.tftpd
TFTPD(8)               System Manager's Manual              TFTPD(8)



NAME
       tftpd - IPv4 Trivial File Transfer Protocol server

SYNOPSIS
       in.tftpd [options...]  directory...

DESCRIPTION
       tftpd  is  a  server  for the Trivial File Transfer Protocol.
       The TFTP protocol is extensively used to support remote boot-
       ing  of  diskless devices.  The server is normally started by
       inetd, but can also run stand-alone.
[...]

root # rpm -qf /usr/sbin/in.tftpd
tftp-0.48-101.16

root # rpm -qi tftp-0.48-101.16| awk '/Description/,/""/'
Description :
The Trivial File Transfer Protocol (TFTP) is normally used only for
booting diskless workstations and for getting or saving network
component configuration files.

root # rpm -ql tftp-0.48-101.16
/etc/xinetd.d/tftp
/usr/bin/tftp
/usr/sbin/in.tftpd
/usr/share/doc/packages/tftp
/usr/share/doc/packages/tftp/README
/usr/share/doc/packages/tftp/README.security
/usr/share/doc/packages/tftp/sample.rules
/usr/share/man/man1/tftp.1.gz
/usr/share/man/man8/in.tftpd.8.gz
/usr/share/man/man8/tftpd.8.gz

root # systemctl disable tftp

Postfix is a replacement for Sendmail and has several security advantages over Sendmail. Postfix is the default mail system in SUSE Linux Enterprise Server and consists of several small programs that each perform their own small task—most of these programs run in a chroot jail. This is one of the reasons Postfix is recommended over Sendmail.

Linux servers that are not dedicated mail or relay servers should not accept external e-mails. However, it is important for production servers to send local e-mails to a relay server—some security setups (for example the seccheck scripts) can be configured to send e-mails to someone other than root, even off the local system.

Verify the following parameters in /etc/postfix/main.cf are set to ensure that Postfix accepts only local e-mails for delivery (look toward the bottom of the file as the top portion is mostly commented-out example entries and explanations):

mydestination = $myhostname, localhost.$mydomain, localhost
inet_interfaces = localhost

The mydestination parameter lists all domains to receive e-mails for. The inet_interfaces parameter specifies the network to listen on. After reconfiguring Postfix, a restart of the mail system is necessary:

root # systemctl restart postfix

Verify that Postfix is not listening for network requests (incoming) by running one of these commands from another host:

nmap -sT -p 25 REMOTE_HOST
telnet <remote_host> 25

Note

Running these commands on the local host will provide inaccurate results because Postfix is supposed to accept connections from the local node. Use an external host for correct results.

NFS (Network File System) allows servers to share files over a network. But like all network services using NFS involves risks.

Here are some basic rules:

If you do not have shared directories to export, then ensure that the NFS service is not enabled nor running on the system:

Check the NFS service status:

root # systemctl status nfsserver

Check the current targets:

root # ls /etc/systemd/system/*.wants/nfsserver.service

root # systemctl enable nfs
systemctl start nfs

root # rpcinfo -p SERVERNAME
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100005    1   udp    623  mountd
    100005    1   tcp    626  mountd
    100005    2   udp    623  mountd
    100005    2   tcp    626  mountd
    100005    3   udp    623  mountd
    100005    3   tcp    626  mountd

root # rpcinfo -p SERVERNAME
No remote programs registered.

      /pub *.network.example.com(ro,sync)

/data/MYSQL sles-ha1.example.com(rw,sync) sles-ha2.example.com(rw,sync) sles-ha3.example.com(rw,sync)

root # exportfs -a

root # exportfs -ua

root # showmount -e localhost
Export list for localhost:

/pub *.network.example.com/data/MYSQL
sles-ha1.example.com,sles-ha2.example.com,sles-ha3.example.com

root # mount -o proto=tcp SERVERNAME:/pub /usr/local/pub

root # mount [...] SERVERNAME:/pub on
/usr/local/pub type nfs (rw,proto=tcp,addr=192.168.1.110)

SERVERNAME:/pub /usr/local/pub nfs rsize=8192,wsize=8192,timeo=14,intr,tcp 0 0

This example is needed in some cases to enable files to be copied over the network using SSH without providing an interactive login prompt. This allows trusted hosts to be set up—an example of federation.

SSH can allow a forced command using the “command” option. Using this option it is possible to disable scp (secure copy) and enforce every passed ssh command to be ignored. On the server side where you want to retrieve the file from, add the following entry to the beginning of the SSH key in the ~/.ssh/authorized_keys file (the ~ represents a particular users home directory – root's home directory is /root – other users typically reside in /home/USERNAME):

command="/bin/cat ~/<file_name>" ssh-rsa AAAAB3N...{etc}

To copy now the file from the remote server, run the following command:

ssh USER@SERVERNAME LOCAL_FILE

Since /bin/cat is run on the server side, its output needs to be redirected to the local file.

Another approach is to replace the /bin/cat (referenced above) with your own script that checks the passed SSH commands by reading the environment variable $SSH_ORIGINAL_COMMAND. For example:

#!/bin/ksh
 if [[ $SSH_ORIGINAL_COMMAND = "File1" ||
       $SSH_ORIGINAL_COMMAND = "File2" ]]
 then
     /bin/cat $SSH_ORIGINAL_COMMAND
 else
     echo "Invalid file name!"
     exit 1
 fi

So you replace the /bin/cat portion with the script name in ~/.ssh/authorized_keys, and run the following command to copy Foo1:

tux > ssh USER@SERVERNAME Foo1 > LOCAL_FILE

To copy Foo 2, run:

tux > ssh USER@SERVERNAME Foo2 > LOCAL_FILE

With the modifications above, every other variety of passed parameters will return errors.

The following sections deal with some ways the default permissions and file settings can be modified to enhance the security of a host. It is important to note that the use of the default SUSE Linux Enterprise Server utilities like seccheck - can be run to lock down and improve the general file security and user environment. However, it is beneficial to understand how to modify these things.

SUSE Linux Enterprise Server hosts include three default settings for file permissions: permissions.easy, permissions.secure, and permissions.paranoid, all located in the /etc directory. The purpose of these files is to define special permissions, such as world-writable directories or, for files, the setuser ID bit (programs with the setuser ID bit set do not run with the permissions of the user that has launched it, but with the permissions of the file owner, usually root).

Administrators can use the file /etc/permissions.local to add their own settings. The easiest way to implement one of the default permission rule-sets above is to use the Local Security module in YaST.

Each of the following topics will be modified by a selected rule-set, but the information is important to understand on its own.

The umask (user file-creation mode mask) command is a shell built-in command which determines the default file permissions for newly created files. This can be overwritten by system calls but many programs and utilities use umask. By default, SUSE sets umask to 022. You can modify this by changing the value in /etc/profile.

The id command will print out the current user identity information. Example from a non-root prompt:

tux > id
uid=1000(ne0) gid=100(users) groups=16(dialout),33(video),100(users)

And to determine the active umask, use the umask command:

tux > umask
0022

Now, for comparison's sake, the same commands from the root user:

root # id
uid=0(root) gid=0(root) groups=0(root)
root # umask
0022

When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that, for example, all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.

But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you should search the entire system for SUID/SGID executables and document it. For example, ensure that code developers do not set SUID/SGID bits on their programs if it is not an absolute requirement. Very often you can use workarounds like removing the executable bit for world/others. However, a better approach is to change the design of the software if possible.

To search the entire system for SUID or SGID files, you can run the following command:

root # find / -path /proc -prune -o -type f -perm '/6000' -ls

The -prune option in this example is used to skip the /proc file system.

World-writable files are a security risk since it allows anyone to modify them. Additionally, world-writable directories allow anyone to add or delete files. To locate world-writable files and directories, you can use the following command:

root # find / -path /proc -prune -o -perm -2 ! -type l -ls

The ! -type l parameter skips all symbolic links since symbolic links are always world-writable. However, this is not a problem as long as the target of the link is not world-writable, which is checked by the above find command.

World-writable directories with sticky bit—directory or file ownership where only the item's owner, the directory's owner, or root can rename or delete files—such as the /tmp directory do not allow anyone except the owner of a file to delete or modify it in this directory. The sticky bit makes files stick to the user who created it and it prevents other users from deleting and renaming the files. Therefore, depending on the purpose of the directory world-writable directories with sticky are usually not an issue. An example is the /tmp directory:

tux > ls -ld /tmp
drwxrwxrwt 18 root root 16384 Dec 23 22:20 /tmp

The t mode, which denotes the sticky bit, allows files to be deleted and renamed only if the user is the owner of this file or the owner of the directory.

SUSE Linux Enterprise Server supports file capabilities to allow more fine grained privileges to be given to programs rather than the full power of root:

root # getcap -v /usr/bin/ping
      /usr/bin/ping = cap_new_raw+eip

The previous command only grants the CAP_NET_RAW capability to whoever executes ping. In case of vulnerabilities inside ping, an attacker can gain at most this capability in contrast to full root when granting the ping binary SUID root rights. Whenever possible, file capabilities should be chosen in favor of the suid-to-root bit. But this only applies when the binary is suid to root, not to other users such as news, lp and alike.

Files not owned by any user or group might not necessarily be a security problem in itself. However, unowned files could pose a security problem in the future. For example, if a new user is created and the new users happens to get the same UID as the unowned files have, then this new user will automatically become the owner of these files.

To locate files not owned by any user or group, use the following command:

root # find / -path /proc -prune -o -nouser -o -nogroup

In some environments it is required to restrict access to removable media such as USB storage or optical devices. The tools coming with the udisks2 package help with such a configuration.

Password expiration is a general best practice—but might need to be excluded for some system and shared accounts (for example Oracle, etc.). Expiring password on those accounts could lead to system outages if the application account expires.

Typically a corporate policy should be developed that dictates rules/procedures regarding password changes for system and shared accounts. However, normal user account passwords should expire automatically. The following example shows how password expiration can be set up for individual user accounts.

The following files and parameters in the table can be used when a new account is created with the useradd command. Settings such as these are stored for each user account in the /etc/shadow file. If using the YaST tool (User and Group Management) to add users, the settings are available on a per-user basis. Here are the various settings—some of which can also be system-wide (for example modification of /etc/login.defs and /etc/default/useradd):

Note

Users created prior to these modifications will not be affected.

Ensure that the above parameters are changed in the /etc/login.defs and /etc/default/useradd files. Review of the /etc/shadow file will show how these settings get stored after adding a user.

To create a new user account, execute the following command:

root # useradd -c "TEST_USER" -g USERS TEST

The -g option specifies the primary group for this account:

root # id TEST
uid=509(test) gid=100(users) groups=100(users)

The settings in /etc/login.defs and /etc/default/useradd are recorded for the test user in the /etc/shadow file as follows:

root # grep TEST /etc/shadow
test:!!:12742:7:60:7:14::

Password aging can be modified at any time by use of the chage command. To disable password aging for system and shared accounts, you can run the following chage command:

root # chage -M -1 SYSTEM_ACCOUNT_NAME

To get password expiration information:

root # chage -l SYSTEM_ACCOUNT_NAME

For example:

root # chage -l TEST
Minimum: 7
Maximum: 60
Warning: 7
Inactive: 14
Last Change: Jan 11, 2015
Password Expires: Mar 12, 2015
Password Inactive: Mar 26, 2015
Account Expires: Never

On an audited system it is important to restrict people from using simple passwords that can be cracked too easily. Writing down complex passwords is all right as long as they are stored securely. Some will argue that strong passwords protect you against dictionary attacks and those type of attacks can be defeated by locking accounts after a few failed attempts. However, this is not always an option. If set up like this, locking system accounts could bring down your applications and systems which would be nothing short of a denial-of-service attack - another issue.

At any rate, it is important to practice effective password management safety. Most companies require that passwords have at the very least a number, one lowercase letter, and one uppercase letter. Policies vary, but maintaining a balance between password strength/complexity and management is sometimes difficult.

Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.

It is strongly recommended to familiarize oneself with the capabilities of PAM and how this architecture can be leveraged to provide the best authentication setup for an environment. This configuration can be done once – and implemented across all systems (a standard) or can be enhanced for individual hosts (enhanced security – by host / service / application). The key is to realize how flexible the architecture is.

To learn more about the PAM architecture, find PAM documentation in the /usr/share/doc/packages/pam directory (in a variety of formats).

The following discussions are examples of how to modify the default PAM stacks—specifically around password policies—for example password strength, password re-use and account locking. While these are only a few of the possibilities, they serve as a good start and demonstrate PAM's flexibility.

sudo pam-config -a --cracklib-minlen=8 --cracklib-retry=3 \
--cracklib-lcredit=-1 --cracklib-ucredit=-1 --cracklib-dcredit=-1 \
--cracklib-ocredit=-1 --cracklib

2.29.2 Restricting Use of Previous Passwords #

  

The pam_pwhistory module can be used to configure the number of previous passwords that cannot be reused. The following command implements password restrictions on a system so that a password cannot be reused for at least 6 months:

sudo pam-config -a --pwhistory --pwhistory-remember=26

Recall that in the section Section 2.27, “Enabling Password Aging” we set PASS_MIN_DAYS to 7, which specifies the minimum number of days allowed between password changes. Therefore, if pam_unix is configured to remember 26 passwords, then the previously used passwords cannot be reused for at least 6 months (26*7 days).

The PAM configuration (/etc/pam.d/common-auth) resulting from the pam-config command looks like the following:

auth      required   pam_env.so
auth      required   pam_unix.so     try_first_pass
account   required   pam_unix.so     try_first_pass
password  requisit   pam_cracklib.so
password  required   pam_pwhistory.so        remember=26
password  optional   pam_gnome_keyring.so    use_authtok
password  required   pam_unix.so     use_authtok nullok shadow try_first_pass
session   required   pam_limits.so
session   required   pam_unix.so     try_first_pass
session   optional   pam_umask.so

Tip

Editing the PAM configuration files directly is not recommended. Use the pam-config command as shown above to fine-tune PAM. For more information see man 8 pam-config.

2.29.3 Locking User Accounts After Too Many Login Failures #

  

It is not generally recommend that a host automatically locks system and shared accounts after too many failed login or su attempts. This could lead to outages if the application's account gets locked because of too many login failures like in this example for an Oracle shared account:

root # su oracle -c id
su: incorrect password

This could be an easy target for a denial-of-service attack. The following example shows how to lock only individual user accounts after too many failed su or login attempts. Add the following line to the service files (such as /etc/pam.d/su or /etc/pam.d/login) that you want to configure (but not to /etc/pam.d/common-auth!):

auth      required     pam_tally2.so deny=5 unlock_time=1200
[...]

The line counts failed login and failed su attempts for all user accounts except the root account. The accounts will be automatically unlocked after 1200 seconds. The default location for attempted accesses is recorded in /var/log/tallylog.

If the user is authenticated and the login process continues on call to pam_setcred(3) it resets the attempts counter to 0.

Note: SSH Lockout Configuration

SSH configuration requires an additional line in /etc/pam.d/sshd, so that the failed login counter will reset after a successful login. The line is account required pam_tally2.so, as shown in the following example:

#%PAM-1.0
auth        requisite   pam_nologin.so
auth        include     common-auth
auth        required    pam_tally2.so deny=5 unlock_time=1200
account     requisite   pam_nologin.so
account     include     common-account
account     required    pam_tally2.so
password    include     common-password
session     required    pam_loginuid.so
session     include     common-session
session     optional    pam_lastlog.so   silent noupdate showfailed

If this line is omitted, pam_tally2 keeps the previous failure count.

It is also possible to add the lock_time=N parameter, and then optionally the unlock_time=N parameter. For example, setting the lock_time=60 would deny access for 60 seconds after a failed attempt. The unlock_time=N option would then allow access after N seconds after an account has been locked. If this option is used the user will be locked out for the specified amount of time after he exceeded his maximum allowed attempts. Otherwise the account is locked until the lock is removed by a manual intervention of the system administrator. See the pam_tally2 man page for more information.

To exempt system and shared accounts from the deny=N parameter, the per_user parameter was added to the module. The per_user parameter instructs the module not to use the deny=N limit for accounts where the maximum number of login failures is set explicitly. For example:

root # pam_tally2 -u oracle
Login      Failures Latest failure                 From
oracle     0        Fri Dec 10 23:57:55 -0600 2005 on unknown

To instruct the module to activate the deny=N limit for this account again, run:

pam_tally2 -u oracle deny=n

By default, the maximum number of login failures for each account is set to zero (0) which instructs pam_tally2 to leverage the deny=N parameter. To see failed login attempts, run:

pam_tally2

Test these changes thoroughly on your system using ssh and su, and make sure the root id does not get locked! To lock or unlock accounts manually, run one of the following commands:

Locking

passwd -l USER
usermod -L USER

Unlocking

passwd -u USER
usermod -U USER

By default, the root user is assigned a password and can log in using various methods—for example, on a local terminal, in a graphical session, or remotely via SSH. These methods should be restricted as far as possible. Shared usage of the root account should be avoided. Instead, individual administrators should use tools such as su or sudo (for more information, type man 1 su or man 8 sudo) to obtain elevated privileges. This allows associating root logins with particular users. This also adds another layer of security; not only the root password, but both the root and the password of an an administrator's regular account would need to be compromised to gain full root access. This section explains how to limit direct root logins on the different levels of the system.

2.30.1 Restricting Local Text Console Logins #

  

TTY devices provide text-mode system access via the console. For desktop systems these are accessed via the local keyboard or—in case of server systems—via input devices connected to a KVM switch or a remote management card (ILO, DRAC, etc). By default, Linux offers 6 different consoles, that can be switched to via the key combinations Alt–F1 to Alt–F6, when running in text mode, or Ctrl–Alt–F1 to Ctrl–Alt–F6 when running in a graphical session. The associated terminal devices are named tty1 .. tty6 accordingly.

The following steps restrict root access to the first TTY. Even this access method is only meant for emergency access to the system and should never be used for everyday system administration tasks.

Note

The steps shown here are tailored towards PC architectures (x86 and AMD64/Intel 64). On architectures such as POWER, different terminal device names than tty1 may be used. Be careful not to lock yourself out completely by specifying wrong terminal device names. You can determine the device name of the terminal you are currently logged into by running the tty command. Be careful not to do this in a virtual terminal, such as via SSH or in a graphical session (device names /dev/pts/N), but only from an actual login terminal reachable via Alt–FN.

Procedure 2.1: Restricting root logins on local TTYs #

  

1. Ensure that the PAM stack configuration file /etc/pam.d/login contains the pam_securetty module in the auth block:

   auth     requisite      pam_nologin.so
    auth     [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so noconsole
    auth     include        common-auth

   This will include the pam_securetty module during the authentication process on local consoles, which restricts root to logging-in only on TTY devices that are listed in the file /etc/securetty.

2. Remove all entries from /etc/securetty except one. This limits the access to TTY devices for root.

   #
   # This file contains the device names of tty lines (one per line,
   # without leading /dev/) on which root is allowed to login.
   #
   tty1

3. Check whether logins to other terminals will be rejected for root. A login on tty2, for example, should be rejected immediately, without even querying the account password. Also make sure that you can still successfully login to tty1 and thus that root is not locked out of the system completely.

Important

Do not add the pam_securetty module to the /etc/pam.d/common-auth file. This would break the su and sudo commands, because these tools would then also reject root authentications.

Important

These configuration changes will also cause root logins on serial consoles such as /dev/ttyS0 to be denied. In case you require such use cases you need to list the respective tty devices additionally in the /etc/securetty file.

2.30.3 Restricting SSH Logins #

  

By default, the root user is also allowed to log into a machine remotely via the SSH network protocol (if the SSH port is not blocked by the firewall). To restrict this, make the following change to the OpenSSH configuration:

1. Edit /etc/ssh/sshd_config and adjust the following parameter:

   PermitRootLogin no

2. Restart the sshd service to make the changes effective:

   systemctl restart sshd.service

Note

Using the PAM pam_securetty module is not suitable in case of OpenSSH, because not all SSH logins go through the PAM stack during authorization (for example, when using SSH public-key authentication). In addition, an attacker could differentiate between a wrong password and a successful login that was only rejected later on by policy.

It can be a good idea to terminate an interactive shell session after a certain period of inactivity; for example, to:

By default, there is no inactivity timeout for shells. Nothing will happen if a shell stays open and unused for days or even years. It is possible to configure most shells in a way that idle sessions terminate automatically after a certain amount of time. The following example shows how to set an inactivity timeout for a number of common types of shells.

The inactivity timeout can be configured for login shells only or for all interactive shells. In the latter case the inactivity timeout is running individually for each shell instance. This means that timeouts will accumulate. When a sub- or child-shell is started, then a new timeout begins for the sub- or child-shell, and only afterwards will the timeout of the parent continue running.

The following table contains configuration details for a selection of common shells shipped with SLE:

Every listed shell supports an internal timeout shell variable that can be set to a specific time value to cause the inactivity timeout. If you want to prevent users from overriding the timeout setting, you can mark the corresponding shell timeout variable as readonly. The corresponding variable declaration syntax is also found in the table above.

Note

This feature is only helpful for avoiding risks if a user is forgetful or follows unsafe practices. It does not protect against hostile users. The timeout only applies to interactive wait states of a shell. A malicious user can always find ways to circumvent the timeout and keep their session open regardless.

To configure the inactivity timeout, you need to add the matching timeout variable declaration to each shell's startup script. Use either the path for login shells only, or the one for all shells, as listed in the table. The following example uses paths and settings that are suitable for bash and ksh to setup a read-only login shell timeout that cannot be overridden by users. Create the file /etc/profile.d/timeout.sh with the following content:

# /etc/profile.d/timeout.sh for SUSE Linux
#
# Timeout in seconds until the bash/ksh session is terminated
# in case of inactivity.
# 24h = 86400 sec
readonly TMOUT=86400

Tip

We recommend using the screen tool in order to detach sessions before logging out. screen sessions are not terminated and can be re-attached whenever required. An active session can be locked without logging out (read about Ctrl–a–x / lockscreen in man screen for details).

Linux allows you to set limits on the amount of system resources that users and groups can consume. This is also very handy if bugs in programs cause them to use up too much resources (for example memory leaks), slow down the machine, or even render the system unusable. Incorrect settings can allow programs to use too many resources which may make the server unresponsive to new connections or even local logins (for example if a program uses up all available file handles on the host). This can also be a security concern if someone is allowed to consume all system resources and therefore cause a denial-of-service attack – either unplanned or worse, planned. Setting resource limits for users and groups may be an effective way to protect systems, depending on the environment.

2.32.1 Example for Restricting System Resources #

  

The following example demonstrates the practical usage of setting or restricting system resource consumption for an Oracle user account. For a list of system resource settings, see /etc/security/limits.conf or man limits.conf.

Most shells like Bash provide control over various resources (for example the maximum allowable number of open file descriptors or the maximum number of processes) that are available on a per/user basis. To examine all current limits in the shell execute:

root # ulimit -a

For more information on ulimit for the Bash shell, examine the Bash man pages.

Important: Setting Limits for SSH Sessions

Setting "hard" and "soft" limits might not behave as expected when using an SSH session. To see valid behavior it may be necessary to login as root and then su to the id with limits (for example, oracle in these examples). Resource limits should also work assuming the application has been started automatically during the boot process. It may be necessary to set UsePrivilegeSeparation in /etc/ssh/sshd_config to "no" and restart the SSH daemon (systemctl restart sshd) if it seems that the changes to resource limits are not working (via SSH). However this is not generally recommended – as it weakens a systems security.

Tip: Disabling Password Logins via ssh

You can add some extra security to your server by disabling password authentication for SSH. Remember that you need to have SSH keys configured, otherwise you cannot access the server. To disable password login, add the following lines to /etc/ssh/sshd_config:

UseLogin no
UsePAM no
PasswordAuthentication no
PubkeyAuthentication yes

In this example, a change to the number of file handles or open files that the user oracle can use is made by editing /etc/security/limits.conf as root making the following changes:

oracle           soft    nofile          4096
oracle           hard    nofile          63536

The soft limit in the first line defines the limit on the number of file handles (open files) that the oracle user will have after login. If the user sees error messages about running out of file handles, then the user can increase the number of file handles like in this example up to the hard limit (in this example 63536) by executing:

root # ulimit -n 63536

You can set the soft and hard limits higher if necessary.

Note

It is important to be judicious with the usage of ulimits. Allowing a "hard" limit for “nofile” for a user that equals the kernel limit (/proc/sys/fs/file-max) is very bad! If the user consumes all the available file handles, the system cannot initiate new logins as accessing (opening) PAM modules which are required for performing a login will not be possible.

You also need to ensure that pam_limits is either configured globally in /etc/pam.d/common-auth, or for individual services like SSH, su, login, and telnet in:

/etc/pam.d/sshd (for SSH)

/etc/pam.d/su (for su)

/etc/pam.d/login (local logins and telnet)

If you do not want to enable it for all logins, there is a specific PAM module that will read the /etc/security/limits.conf file. Entries in pam configuration directives will have entries like:

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

It is important to note that changes are not immediate and require a new login session:

root # su – oracle
tux > ulimit -n
4096

Note that these examples are specific to the Bash shell - ulimit options are different for other shells. The default limit for the user oracle is 4096. To increase the number of file handles the user oracle can use to 63536, do:

root # su – oracle
tux > ulimit -n
4096
tux > ulimit -n 63536
tux > ulimit -n
63536

Making this permanent requires the addition of the setting, ulimit -n 63536, (again, for Bash) to the users profile (~/.bashrc or ~/.profile file) which is the user start-up file for the Bash shell on SUSE Linux Enterprise Server (to verify your shell run: echo $SHELL). To do this you could simply type (or copy/paste – if you are reading this on the system) the following commands for the Bash shell of the user oracle:

root # su - oracle
tux > cat >> ~oracle/.bash_profile << EOF
ulimit -n 63536
EOF

It is often necessary to place a banner on login screens on all servers for legal/audit policy reasons and to deter intruders, etc.

If you want to print a legal banner after a user logs in using SSH, local console, etc., you can leverage the /etc/motd (motd = message of the day) file. The file exists on SUSE, however it is empty. Simply add content to the file that is applicable/required by the organization.

Note: Banner Length

Try to keep the content to a single page (or less), as it will scroll the screen if it does not fit.

For SSH you can edit the “Banner” parameter in the /etc/ssh/sshd_config file which will then appropriately display the banner text before the login prompt. For local console logins you can edit the /etc/issue file which will display the banner before the login prompt. For GDM, you could make the following changes to require a user to acknowledge the legal banner by selecting Yes or No. Edit the /etc/gdm/PreSession/Default file and add the following lines at the beginning of the script:

if ! gdialog --yesno '\nThis system is classified...\n' 10 10; then
    sleep 10
    exit 1;
fi

The This system is classified... test should be replaced with the valid text. It is important to note that this dialog will not prevent a login from progressing.