Document revision history

  • 1.1.5 — Cleanup: change chage -M parameter to -1, explain operational and spare changes for using hostalias, fix path to ~fsl11/AUID/install_RAID script, move copying root ssh key to setting up backup_usr2, explain running X applications as root, warn about benign ./root_tmp error message, move removing AUID account time-outs to AUID account setup, wording fixes

  • 1.1.4 — Remove CIS password aging/expiration for desktop

  • 1.1.3 — Disable oper and prog password expiration, they don’t have passwords

  • 1.1.2 — Correct responses to adduser; create ~AUID/.ssh in case it doesn’t already exist

  • 1.1.1 — Use backup_user2 to run refresh_spare_usr2 for CIS hardening, removing enable_spare and disable_spare; add copying key for backup_usr2

  • 1.1.0 — Add installing AUID use of refresh_spare_usr2; add new section on AUID use of refresh_spare_usr2 section using enable_spare and disable_spare; restructure installing sudo access for rotation scripts and root account; remove UID/GID parallelism; correct use of computer when system is correct

  • 1.0.5 — Limit AUID options for refresh_secondary

  • 1.0.4 — Remove shutdown, reboot, and refresh_spare_usr2 from sudoers; cleanup refresh_spare_usr2 only for root

  • 1.0.3 — Optionally disable oper/prog shell time-out

  • 1.0.2 — Add no GUI login and other new remediations

  • 1.0.1 — Fix typo in desktop setup

  • 1.0.0 — Initial release

1. Introduction

These notes detail adding extra security features to Field System Linux 11, FSL11, as advised by Center for Internet Security (CIS). This is provided as an option for sites that might need additional security.

At the time of this writing, there is no CIS security benchmark for Debian 11, which is what FSL11 is based on. Instead, the latest benchmark for Debian 10 was used. Although this is not technically correct, the changes in the benchmark for Debian 10 compared to Debian 9 were relatively minor; primarily removal of items. It seems plausible that the Debian 10 benchmark will be adequate for Debian 11. In fact, all of the items that fail for FSL11 are either things that are required for FS operation, items that appear to actually be secure despite the benchmark not recognizing them as such, and one change since Debian 10 that we worked around. However, we don’t know what additional checks will be in the Debian 11 benchmark.

Note

Additional steps needed to use the benchmark:

  1. Install the package default-jre with apt-get.

  2. Disable the java version check in CIS-CAT.sh.

  3. Change ignore.platform.mismatch to true in misc/ciscat.properties.

With the exception of the partition configuration, all actions are to be performed post-installation (see the FSL11 Installation document). Applying the remediations, the exceptions that are still present, all tests that failed, and problems with the benchmark remediations are provided in separate sections below. An appendix covers additional setup that is needed for FS operations after the remediations have been applied.

This document is based on the results for the “CIS Debian Linux 10 Benchmark v1.0.0 - Level 2 - Server”.

2. Applying CIS remediations

2.1. Installation partition configuration

During installation, be sure to create the logical volumes marked optional in the partition setup section.

2.2. Post-installation remediations

All commands need to be run as root.

2.2.1. Scripted remediations

As many remediations as possible are implemented by the remediate script. The script is intended to be run after the “Third Stage Installation” steps in the FSL11 instructions, before any further changes have been made to the system (however initializing and adding other disks to the RAID can intervene).

To apply these remediations, execute the commands:

cd /root/fsl11
script ../remediate.txt
./remediate
exit
Important
 This script should not be run more than once on a system.
Tip
 The use of the script command causes the output to be recorded in the specified file. This can be very helpful for understanding what went wrong if the script fails. The script itself uses the -x option to echo the commands as they are executed to make it easy to match the output with the commands being executed.

2.2.2. Reboot

The system should be rebooted to make sure all the remediations have been applied. Some aren’t enforced until a reboot.

After the reboot, all the CIS remediations that can applied at this point have been completed. The Additional CIS policies subsection below describes some other policies that can be considered.

2.2.3. Additional remediations

The subsection applies a second round of scripted remediations and an unscripted remediation that both go beyond the CIS benchmark. Before applying the scripted remediations, an account must be created that will have the ability to promote to root. Please see the Enabling user promotion to oper/prog and root and Adding AUID accounts sections of the Additional items for FS operations appendix for the details of configuring such an account.

Run the script

To apply the scripted remediations, execute the commands:

Important
 These scripted remediations including disabling direct root login. If there is no account that is able to promote to root before they are applied, it will become impossible to get root access. 
cd /root/fsl11
script ../remediate2.txt
./remediate2
exit
Important
 This script should not be run more than once on a system.

This script will place a backup of all the original files modified by the script in the directory /root/remediate2_backups.

Unscripted remediation

This remediation is to specify a FQDN for a server in the /etc/ntp.conf file. The server must be within the same second-level domain as the system being hardened. If you using the recommended FS NTP configuration, you can add lines for the FQDN after the lines for the alias of the server. There must be exactly one space (no tabs) between server and the FQDN. The result would be something like:

# if you update this one, also update the FQDN version below
server      alias iburst minpoll 4
restrict    alias kod notrap nomodify nopeer noquery
#
# if you update this one, also update the aliased version above
server FQDN iburst minpoll 4
restrict FQDN kod notrap nomodify nopeer noquery

The lines for the alias may still work to locate the server if there is a DNS problem. The comments may help get the correct result if this server changes.

Second remediation reboot

The system should be rebooted to make sure all the remediations have been applied. Some aren’t enforced until a reboot.

Note
 After this reboot, the GUI login on the console will be disabled. Locally, it will only be possible to login on a text console.

2.3. Additional CIS policies

This section lists further topics related to the benchmark that should be discussed. The items are listed by benchmark section numbers.

1.5.2 Ensure bootloader password is set

You may wish to create an encrypted password with grub-mkpasswd-pbkdf2:

grub-mkpasswd-pbkdf2
Enter password: <password>
Reenter password: <password>
Your PBKDF2 is <encrypted-password>

Add the following into a custom /etc/grub.d configuration file (don’t use /etc/grub.d/00_header as it can be overwritten by a package update):

cat <<EOF
set superusers="<username>"
password_pbkdf2 <username> <encrypted-password>
EOF

If there is a requirement to be able to boot/reboot without entering the password, edit /etc/grub.d/10_linux and add --unrestricted to the line CLASS=

Important
 It is strongly recommended that booting without a password be permitted. Otherwise, if a reboot is required to continue operations it will not be possible unless some one with the password is available. If they aren’t available, this could lead to a safety issue or loss of VLBI data.

Example:

CLASS="--class gnu-linux --class gnu --class os --unrestricted"

Run the following commands to update the grub2 configuration and reset the grub.cfg permissions:

update-grub
chmod go-rwx /boot/grub/grub.cfg

1.8.1.2 Ensure the local login warning banner is configured properly

You may want to update /etc/issue to have a more tailored message with sterner warnings. The message must not include use of \m, \r, \s, \v, or references to the OS platform.

1.8.1.3 Ensure the remote login warning banner is configured properly

You may want to update /etc/issue.net to have a more tailored message with sterner warnings. The message must not include use of \m, \r, \s, \v, or references to the OS platform.

1.8.2 Ensure GDM login banner is configured properly

You may want to update /etc/gdm3/greeter.dconf-defaults to have a more tailored message with sterner warnings.

If desired, you can remove the Debian logo from the GUI login page by renaming the file specified for the logo option of the [org/gnome/login-screen] section in /etc/gdm3/greeter/dconf-defaults. For example, if appropriate, you might use:

cd /usr/share/images/vendor-logos
mv logo-text-version-64.png logo-text-version-64.png.bak

If desired, you can remove the Debian logo from the grub menu by renaming the file specified for in the if clause for the background_image file in the /etc/grub.d/05_debian_theme section of /boot/grub/grub.cfg. For example, if appropriate, you might use:

cd /usr/share/desktop-base/homeworld-theme/grub
mv grub-4x3.png grub-4x3.png.bak
Important

Caveat Emptor! The changes below in this IMPORTANT section may not be safe. Even if they appear to be successful, they may case problems later. The problems may include failure of automatic updates. They may also need to be reinstalled after updates.

After making any or all of these changes, it is necessary to execute:

update-grub

for them to take effect.

  1. In principle, you can remove the Debian label from the grub boot menus by editing /etc/default/grub and inserting a line:

    GRUB_DISTRIBUTOR=FSL11

    immediately after the existing GRUB_DISTRIBUTOR=…​ line.

  2. In principle, you can remove the GNU/Linux label from the grub boot menus by editing /etc/grub.d/10_linux and inserting a line:

    OS="${GRUB_DISTRIBUTOR}"

    immediately after the existing OS="${GRUB_DISTRIBUTOR} GNU/Linux" line.

  3. In principle, you can remove the Linux label from the lines displaying kernel image files, by editing /etc/grub.d/10_linux and globally replacing  Linux  (note the single leading and single trailing spaces) with  FSL11  (not the single leading and single trailing spaces).

2.2.1.4 Ensure ntp is configured

This needs the FS NTP configuration. That is more secure than the benchmark since it uses ignore by default.

4.1.2.3 Ensure system is disabled when audit logs are full

This may not be appropriate for an operational system.

4.2.1.5 Ensure rsyslog is configured to send logs to a remote host

To set a remote log host, edit the /etc/rsyslog.conf and/or the /etc/rsyslog.d/*.conf files and add lines like the following (replace angle bracket items, <…​>, with your values):

<files to sent to the remote log server> action(type="omfwd" target="<FQDN or ip of loghost>" port="<port number>" protocol="tcp"
action.resumeRetryCount="<number of re-tries>"
queue.type="linkList" queue.size=<number of messages to queue>")

or

*.* @@<FQDN or ip of loghost>

Run the following command to reload the rsyslog configuration:

systemctl reload rsyslog

5.2.16 Ensure SSH Idle Timeout Interval is configured

Five minutes is too short and is not commensurate with the recommended 15 minute auto-logout interval.

5.3.1 Ensure password creation requirements are configured

Should the minimum be reduced to 12 characters?

5.3.2 Ensure lockout for failed password attemtps is enabled

The number of login failures before lock-out can cause a problem if it is set too low. The main issue is for an operator working at odd hours, alone, at a remote location, and dealing with multiple issue, which might include: power failures, equipment problems, and logistical issues. It can be a chaotic situation. Typing long and complicated passwords in the heat of battle, particularly if they vary between machines, can be error-prone. Being locked-out will make the situation more difficult and may increase the amount of data that will be lost.

If you find that the number of login failures before lock-out is too small, you can increase it by increasing the value of the deny parameter (5 in the example below, other typical parameters are omitted and should not be changed) in:

/etc/pam.d/common-auth
auth required pam_faillock.so deny=5

Small integer values (20 or less) should not be a significant risk with long and complicated passwords and a unlock time of several minutes.

5.4.1.4 Ensure inactive password lock is 30 days or less

This is too short for developers/troubleshooters. A value of 60 would be commensurate with the password reset interval.

2.4. Other policies

This subsection describes other policies beyond the CIS benchmark that may be desirable.

2.4.1. TCP wrappers configuration

You may wish to configure TCP wrappers.

/etc/hosts.deny

Add:

ALL:ALL
/etc/hosts.allow

Add:

sshd:ALL

It is recommended that you further restrict sshd to specific hosts and/or sub-domains.

2.4.2. Set log retention period

You may want to set the retention period of system logs by editing /etc/logrotate.conf and/or /etc/logrotate.d/*, as appropriate.

3. CIS Exceptions

This section addresses the tests that failed in the CIS benchmark after all the remediations in this document were applied. The items are listed by benchmark section numbers.

1.4.2 Ensure filesystem integrity is regularly checked

The AIDE system now performs a check daily and generates a report, so this is no longer needed.

1.5.2 Ensure bootloader password is set

This must be set later by the system administrator.

2.2.2 Ensure X Window System is not installed

The X11 Window system is required for FS use.

2.2.4 Ensure CUPS is not enabled

The CUPS printing systems is required for operations.

3.5.2.5 Ensure firewall rules exist for all open ports

There is a ufw rule for Openssh (port 22), but the benchmark doesn’t accept that. Additional openings can be added as needed.

3.5.3.7 Ensure nftables service is enabled

Although the benchmark also uses ufw, which is enabled and uses nftables, for some reason this is not recognized.

3.5.3.8 Ensure nftables rules are permanent

Although the benchmark also uses ufw, which has permanent rules and uses nftables, for some reason this is not recognized.

4.2.1.5 Ensure rsyslog is configured to send logs to a remote log host

A remote log server must be configured later by the system administrator.

5.2.6 Ensure SSH X11 forwarding is disabled

Using ssh X11 forwarding is required for for remote FS operations and testing.

5.3.2 Ensure lockout for failed password attempts is configured

The benchmark, which is for Debian 10, uses pam_tally2.so for this. However pam_tally2.so is not available in Debian 11, having been replaced with pam_faillock.so. The remediate script implements the intent of the recommended pam_tally2.so configuration with pam_faillock.so.

Note
 To reset a locked-out user after CIS hardening, as root use faillock --user username --reset where username is the user account. Leave off the --reset to see what the current failure count is.

4. CIS Remediation problems

This section details problems with the recommended remediations. The items are listed by benchmark section numbers.

Some problems were worked around by adding a boot time systemd service CISfix to correct changes that occur on a reboot.

1.1.10 Ensure noexec option set on /var/tmp partition

Enforcing this requirement for the currently running system before all the other remediations have been applied can interfere with execution of apt-get install …​ to install packages needed for the remediation. Instead, although /etc/fstab is updated in sequence, remounting the file systm is deferred to the end.

1.4.2 Ensure filesystem integrity is regularly checked

The /etc/crontab entry that should be added is missing the user (root) field. Additionally Debian no longer provides aide.wrapper. However, the AIDE system now performs a check daily and generates a report, so this is no longer needed.

1.5.1 Ensure the permissions on the bootloader are configured

The permissions are reset every time update-grub is run, e.g., for a kernel update. Fixing them was added to the CISfix systemd service at boot.

2.2.1.4 Ensure ntp is configured

The remediation makes it less secure. A default policy of ignore is better.

3.3.4 Ensure suspicious packets are logged

The remediation lines added in /etc/sysctl.d/* for this issue are not respected at boot (unlike all others). To overcome this, the following lines are used in the CISfix systemd service at boot.

sysctl -w net.ipv4.conf.all.log_martians=1
sysctl -w net.ipv4.conf.default.log_martians=1
sysctl -w net.ipv4.route.flush=1

4.1.5 Ensure events that modify the system’s network environment are collected

The 64-bit remediation had the b64 and the b32 rules concatenated on one line.

4.1.16 Ensure kernel module loading and unloading is collected

The 64-bit remediation was missing the b32 rule.

4.2.3 Ensure permissions on all logfiles are configured

There are two issues:

  1. The recommended remediation makes the entire directory tree /var/log unsearchable by everyone except root. This breaks some functionality, in particular email. As a result, the remediation was scaled back to just the minimum required to pass the test, which was to just set the permission on the files themselves instead changing the directory permissions as well. This could be made more targeted. For example to allow email use, just /var/log and /var/log/exim4 could be made searchable.

  2. The permissions for some logfiles are reset each time the system reboots. Fixing them was added to the CISfix systemd service at boot.

6.1.6 Ensure permissions on /etc/passwd- are configured

The permissions are reset each time the system reboots. Fixing them was added to the CISfix systemd service at boot.

6.1.7 Ensure permissions on /etc/shadow- are configured

The permissions are reset each time the system reboots. Fixing them was added to the CISfix systemd service at boot.

6.1.8 Ensure permissions on /etc/group- are configured

The permissions are reset each time the system reboots. Fixing them was added to the CISfix systemd service at boot.

6.1.11 Ensure no unowned files or directories exist

After each boot, the file /var/cache/private/fwupdmgr has no owner. Fixing that was added to the CISfix systemd service at boot.

6.1.12 Ensure no ungroup files or directories exist

After each boot, the file /var/cache/private/fwupdmgr has no group. Fixing that was added to the CISfix systemd service at boot.

Appendix A: Additional items for FS operations

After the CIS hardening is completed, some additional set-up is needed. In addition, one item below gives the procedure for running refresh_spare_user with CIS hardening.

A.1. Fix-ups

There are two issues that may need to be corrected after the CIS hardening.

  1. Using the noexec option for /tmp causes a problem for the package management system. The dpkg-preconfigure program places and executes scripts on /tmp as part of package installation. The noexec option prevents the execution of the scripts. To work around this issue, you can exeucte:

    cd /root/fsl11/
./root_tmp
    Note

    The error message:

    Failed to disable unit: Unit file root_tmp.service does not exist.

    is benign.

    The root_tmp script performs three actions:

    1. Creates a one time service at boot to clean the /root/tmp directory

    2. Sets dpkg-preconfigure to use /root/tmp for temporary files

    3. Creates an initial /root/tmp directory

    There may be other issues with using the noexec option for /tmp, but we don’t have any specifics at this time.

  2. Sometimes the firewall (ufw) does not work properly after rebooting. This has been noticed for remote access to gromet for met. data on port 50001. There are no other known issues. An apparent fix for this is to disable and re-enable the firewall. If you have this problem and the same solution works, a one-time service at start-up can be created to perform this action:

    cd /root/fsl11
./create_ufw_re-enable

    The new service will run at the next reboot. It is configured to run after ufw has been started.

A.2. Enabling user promotion to oper/prog and root

The model used in the FS assumes oper and prog accounts will be used for operations and programming respectively. However, some organizations may have security and auditing restrictions that mean operators must login using their own account (possibly named with their Agency User ID, or AUID). As the FS currently operates, users will then need to switch, i.e., promote, to the oper or prog account after login. Likewise, if a user is allowed to promote to root, they will need to do so after logging into their own account. This subsection covers how to enable this capability. The next subsection, Adding AUID accounts, covers how to add an AUID account.

For oper and prog, we suggest creating two groups that can sudo to the accounts. Run visudo, then add at end:

%operators      ALL=(oper) ALL
%programmers    ALL=(prog) ALL
%programmers    ALL=(oper) ALL

If they don’t already exist, create the needed groups:

addgroup operators
addgroup programmers

If they don’t already, set oper and prog to have bash as their login shells:

chsh -s /bin/bash oper
chsh -s /bin/bash prog
Important
 When promoting to oper and prog (and root), the only supported login shell for the target accounts is bash. It would be possible to support tcsh. That would require adding promotion machinery to the ~/.login files that is equivalent to what is in the current ~/.profile files. Please contact Ed for more information.

Optionally, to disable shell inactivity time-outs for the oper and prog accounts, edit their respective .bashrc files and uncomment the line:

unset TMOUT

If the accounts, and desktop, haven’t been disabled for login already, do so:

usermod -L oper
usermod -L prog
usermod -L desktop

Disable password aging and account inactivity expiration for those accounts. Execute:

chage -I -1 -M -1 oper
chage -I -1 -M -1 prog
chage -I -1 -M -1 desktop

To prevent connecting with ssh using a key, create (or add oper and prog to an existing) DenyUsers line in /etc/ssh/sshd_config:

Note
 If you used the CIS remediate script, you should comment out the line: DenyGroup rtx as well. 
DenyUsers desktop oper prog

And restart sshd with:

systemctl restart sshd

Authorized users can then switch to oper with (similarly for prog and root):

sudo -i -u oper

The sudo command will prompt for the AUID account’s password. Within a session, sudo will not prompt again for 15 minutes after its last successful use.

The following example steps are used to ensure that X11 authorization works. This example is for user oper and works analogously for prog and root (but see the paragraph at the end of step (1) for more information about root's configuration). After the steps are presented, there is information on a script that implements these changes for all three accounts in one step.

  1. Add this to the following file:

    ~oper/.profile
    #
# authorise XCOOKIE for remote users
if ! [ -z ${XCOOKIE+x} ]; then
   xauth add $XCOOKIE
fi
# set .Xresources/window-manager coming from AUID accounts
if ! [ -z ${DISPLAY+x} ]; then
#   NOT no DISPLAY defined, do something (otherwise do nothing)
    if echo $DISPLAY |grep -q localhost; then
#       ssh from remote host with X display
        xrdb -merge ~/.Xresources
    else
#       login shell (because this is .profile) on the local X console
        xrdb -merge ~/.Xresources
        setsid fvwm --replace >/dev/null 2>&1 &
    fi
fi
#
# include AUID user's .profile_SUDO_USER
if [ -n "$SUDO_USER" ]; then
    if [ -f "$HOME/.profile_$SUDO_USER" ]; then
        . "$HOME/.profile_$SUDO_USER"
    fi
fi

    This will also set the Xresources to those of oper, replace the current window manager with one owned by oper (protected from Ctrl+C by setsid) for a local console X11 session, and run a bash script (if present) to apply customizations for the sudo user. (For root only the first clause would be used since Xresources would not be set, the window manager would not be replaced, and there would not be sudo user customization.)

  2. Create the following file

    /usr/local/bin/oper_account
    set -e

if [ "$USER" = "prog" ]; then
  echo "ERROR: Cannot promote to oper from $USER account. Promote from $SUDO_USER instead."
  exit 1
elif [ "$USER" = "oper" ]; then
  echo "ERROR: Already in $USER account."
  exit 1
fi

if [ -z ${DISPLAY+x} ]; then
#   no DISPLAY set
    sudo -u oper -i "$@"
elif echo $DISPLAY |grep -q localhost; then
#   remote user
    sudo -u oper XCOOKIE="$(xauth list $DISPLAY)" -i "$@"
else
#   on console X server
    if ! xhost|grep -q 'SI:localuser:oper'; then
        xhost +SI:localuser:oper >/dev/null
    fi
    sudo -u oper -i "$@"
fi

  3. Execute:

    chmod a+rx /usr/local/bin/oper_account

  4. Create the following file:

    /usr/local/bin/oper_x11
    set -e

if [ $USER = "prog" ]; then
  echo "ERROR: Cannot promote to oper from $USER account. Promote from $SUDO_USER instead."
  exit 1
elif [ $USER = "oper" ]; then
  echo "ERROR: Already in $USER account."
  exit 1
fi

if tty|grep -q ^/dev/tty ;then
    export AUID_PROMOTE_ACCOUNT=oper
    startx >/dev/null 2>&1
else
    echo "Only text console users are allowed to run the X server, use 'oper_account'."
fi

  5. Execute:

    chmod a+rx /usr/local/bin/oper_x11

To execute the five numbered steps above for oper and prog and the first three for root (for the latter only those three are needed), enter:

~/fsl11/AUID/install_AUID

The oper_account, prog_account, and root_account scripts can be used to promote any AUID session to those accounts. If the Additional remediations have been applied, the oper_x11 and prog_x11 scripts can be used on a text console to start an X11 session and promote.

Note

If the Additional remediations have been applied, the process to run X11 applications (e.g., nm-connection-editor) as root depends on how you logged in.

  • If you logged in remotely with ssh using an AUID account, use the root_account script to run the application, e.g.:

    root_account nm-connection-editor

    Or, just promote to root with the root_account script, then run the application.

    This assumes you have an Xserver running on the computer you connected from. Simply using sudo to run the application from an AUID account will not work because the .Xauthority file is not properly set for root until the root_account script has been used in the AUID session.

  • If you logged in on a local text console with an AUID account, first start the GUI with startx, then run the application with, e.g., root_account nm-connection-editor (using sudo nm-connection-editor instead will work in this case).

A.3. Adding AUID accounts

This subsection describes how to add AUID accounts to be used with the ability to promote to oper, prog, and root as described in the previous subsection. The method described here uses dhorsley as an example AUID account name.

  1. Add the user account:

    adduser dhorsley --home /usr2/dhorsley

    Enter a suitable password when prompted and confirm it. Answer all other questions with Enter.

    Important
    		 If you are configuring a spare system, you will need to make sure the same accounts and groups for the owners of files on /usr2 exist on both systems (but the UIDs and GIDs don’t need to be the same) for the system-to-system backup of /usr2 to work properly.
    Note

    For normal operations, AUID users' home directories should be on /usr2. However, for some maintenance accounts, it may make sense to have the home directory some where else, typically on /home. In that case, use this command instead:

    adduser dhorsley

    The step for setting the contents of the home directory below will need to be adjusted accordingly; see the NOTE farther below.

  2. Add the user to these groups as appropriate, e.g.:

    Note
    		 This step assumes that the operators and programmers groups have been created as described in the previous subsection Enabling user promotion to oper/prog and root. 
    adduser dhorsley operators

    and/or:

    adduser dhorsley programmers

  3. If the user should be able to manage printers, use:

    adduser dhorsley lpadmin

  4. If the user is allowed to elevate to root, use visudo to add:

    dhorsley       ALL=(root) ALL

  5. If the account will be used by an operator and/or programmer with the GUI, the X11 environment needs to be set-up. The following command will move an existing /usr2/dhorsley to /usr2/dhorsley.FSCOPY and create a new /usr2/dhorsley with useful skeleton files (you will be prompted for the account name):

    /usr2/fs/misc/auid_update

    It will also create ~oper/.profile_dhorsley and _~prog/.profile_dhorsley scripts for per AUID user customization of oper and prog sessions. The initial versions of this file just print a message as a reminder that they are being used:

    ~oper/.profile_dhorsley
    echo "Applying customizations from ${BASH_SOURCE}"
    Note

    NOTE: If the user’s home directory is not on /usr2, but is for example on /home, the following commands should be used instead:

    cd /home
mv dhorsley dhorsley.FSCOPY
cd /usr2/fs/st.default/auid
find . -print|cpio -pmdu /home/dhorsley
chown -R dhorsley.dhorsley /home/dhorsley
chmod 0750 /home/dhorsley

    No oper/prog customization scripts are included. It is assumed that since these accounts aren’t on /usr2 that they aren’t used for operations.

  6. Optionally, to disable shell inactivity time-outs for the AUID account, edit their .bashrc file and uncomment the line:

    unset TMOUT

  7. Set default desktop

    To set the correct default desktop (it is remembered per user):

    cat > /var/lib/AccountsService/users/dehorsley <<EOF
[User]
Language=
XSession=default
Icon=/usr2/dehorsley/.face
SystemAccount=false
EOF

    Normally, the GUI login is disabled if the security remediations of this document have been applied. If the GUI login is available and you have access to the console, an alternative means for setting the desktop is:

    1. Press Ctrl+Alt+F1 to get to the GUI login.

    2. Enter dhorsley as the Username.

    3. Select the “gear” icon in the lower right-hand corner.

    4. Select System X11 Default.

    5. Complete logging in with the password.

    6. Logout with exit.

  8. If you have operational and spare systems and have already installed the backup_usr2 script on the operational system, you may want to follow the steps in the sub-step Copy root ssh key for running backup_usr2 (in the Installing backup_usr2 with CIS hardening section below) for this user.

A.4. Enable operators group accounts to rotate disks

  1. Allow operators to use the sudo scripts rotation_shutdown (with any options) and refresh_secondary (but only with no options or with the -h or -p options individually), by adding (respectively) with visudo:

    %operators      ALL=(ALL) /usr/local/sbin/rotation_shutdown
%operators      ALL=(ALL) /usr/local/sbin/refresh_secondary ""
%operators      ALL=(ALL) /usr/local/sbin/refresh_secondary -h
%operators      ALL=(ALL) /usr/local/sbin/refresh_secondary -p
    Note
    		 A user who can elevate to root will be able to run refresh_secondary with any options if they use sudo explicitly.

  2. Install AUID scripts to allow operators group accounts to run the sudo scripts without explicitly entering sudo:

    ~/fsl11/AUID/install_RAID
    Note

    The scheme here uses scripts that are run with sudo (the so-called sudo scripts) for steps that require elevated privileges. These are installed in /usr/local/sbin. For ease of use with the operators group (typically AUID) accounts, additional scripts (the so-called AUID scripts) with the same names that run the sudo scripts are installed in /usr/local/bin. The AUID scripts verify that the oper and prog accounts are not in use before running the sudo versions with sudo. This cuts down on error messages from sudo and saves AUID users from needing to enter sudo.

    This works for root (and sudo) users because /usr/local/sbin appears before /usr/local/bin in users' PATH variables. It works for non-root (and non-sudo) users because the versions in /usr/local/sbin are only executable by root.

A.5. Setting hostname alias

These steps set a more user friendly alias for the systems of the form fs1-<xx> and fs2-<xx> where <xx> is the station’s two letter code. This provides a compact alias for local usage, even for sites with more than one system, and makes the system identifiable for remote users in a systematic way. Except as noted below, these steps should be executed for both the operational and spare systems.

  1. Edit /etc/hosts and add the new aliases to the appropriate lines.

    If you have two systems, add the aliases for both to the file on each system.

  2. Create a file /etc/hostname_alias that contains the new alias.

    1. Execute

      cd /etc
cp hostname hostname_alias
chmod a+r hostname_alias

    2. Edit the new file and change the contents to the new alias.

  3. Change the system’s mailname

    Note
    		 To allow mail to mailman mail lists to work, you may need to make a use a fake FQDN name, perhaps by appending .net to your alias, for use in /etc/mailname and /etc/exim4/update-exim4.conf.conf. The two files should be consistent.

    1. Edit the file /etc/mailname and change its contents to the new name, without a domain name unless that is required by remote mail hosts or mail lists. If so, Generate FQDN in HELO for outgoing mail in the FSL11 Installation document may also be helpful.

    2. Edit /etc/exim4/update-exim4.conf.conf, change the value of dc_other_hostnames= to the new alias

    3. Execute

      update-exim4.conf
systemctl restart exim4

  4. Use the new alias in the user prompts and xterm titles for oper, prog, and all non-system-administrator AUID accounts. In the .bashrc file for each user to be changed:

    1. Before the if block that sets PS1 add:

      hostalias_file=/etc/hostname_alias
if [[ -f "$hostalias_file" ]]; then
    hostalias=$(cat $hostalias_file)
else
    hostalias=$(hostname)
fi

    2. In the two statements setting PS1 in the if block, change the use of \h to $hostalias.

    3. In the statement setting PS1 in the case block that sets the xterm window title, change the use of \h to $hostalias.

  5. If you updated the operational system alias and have a matching spare system, then on the latter:

    1. Update /usr/local/sbin/refresh_spare_usr2 to use the new alias of the operational system for the remote_node variable.

    2. You will need to update the new alias for the operational system to be recognized as a known host to the root account on the spare system. You can do that, as root, by using ssh to spare@operational where operational is the new alias for the operational system. The command will ask you to confirm the fingerprint for the new hostname. After accepting it, the sudo command on the operational system will be rejected because of the forced-command setup. The interaction will may not seem to make sense but, after the password for the sudo command has been rejected three times, will end with a line like: Connection to operational closed.. Still, the task of recording the host key will have been accomplished.

  6. If you updated the spare system alias and have a matching operational system, then on the latter:

    1. Update /usr/local/sbin/backup_usr2 to use the new alias of the spare system for the remote_node variable.

    2. You will need to update the new alias for the spare system to be recognized as a known host to the AUID accounts that can use backup_usr2 on the operational system. You can do that, as root, by switching the AUID account (su ‑ AUID, where AUID is the account name), then using ssh spare, where spare is the new alias of the spare system. The command will ask you to confirm the fingerprint for the new hostname. After accepting it, you will be logged in to the spare system, you can then exit from that session.

A.6. Installing backup_usr2 with CIS hardening

Foe CIS hardened systems, the backup_usr2 script is used on the operational system to backup its /usr2 partition to the spare system. To do this, it invokes refresh_spare_usr2 on the spare system. This is useful if to want the spare system to be a reasonably up-to-date backup system for operations. All steps for installation must be performed as root on the specified system. You should read all of the procedure before using it.

Tip
 Read the introduction of the refresh_spare_usr2 section of the RAID Notes for FSL11 document for important information on the refresh_spare_usr2 script.
Note
 Please see the NOTE in the Enable operators group accounts to rotate disks step in this appendix for an explanation of how the so-called sudo and AUID scripts, also used here, interact.

  1. On the operational system:

    1. Create spare account. Execute:

      adduser spare

      Enter a suitable password when prompted and confirm it. Answer all other questions with Enter.

      Note
      		 The user’s home directory is on /home (by default), not /usr2.

  2. On the spare system:

    1. Make sure the operational system is represented in the /etc/hosts file.

      If it is not already there, add it. It is recommended that it be given a simple alias for routine use.

    2. Install the sudo script refresh_spare_usr2:

      1. Move the script into position:

        ~/fsl11/RAID/install_refresh_spare_usr2

      2. Customize /usr/local/sbin/refresh_spare_usr2, following the directions in the comments in the script (repeated here):

        1. Comment-out the lines (add leading #s):

          echo "This script must be customized before use.  See script for details."
exit 1

        2. Change the operational in the line:

          remote_node=operational

          to the alias (preferred), FQDN, or IP address of your operational system.

        3. Uncomment the line for CIS hardened systems. The commented out form is:

          #remote_user=spare

      3. For operators, Enable running the sudo script with either no options or just -h. Use visudo to add:

        %operators         ALL=(ALL) /usr/local/sbin/refresh_spare_usr2 ""
%operators         ALL=(ALL) /usr/local/sbin/refresh_spare_usr2 -h

    3. Create a key for root:

      If root already has a key, you should skip this sub-step.

      Caution
      		 Your should not set a passphrase. 
      ssh-keygen

    4. Copy the key:

      ssh-copy-id spare@operational

      where operational is the alias, name, or IP of your operational system.

  3. On the operational system:

    1. Set the spare account to only allow a forced command with ssh by replacing the ssh-rsa at the start of the first (and only) line of ~spare/.ssh/authorized_keys line with:

      command="sudo --preserve-env rrsync -ro /usr2" ssh-rsa

      Tip
      		 If your spare system is registered with DNS, you can provide some additional security by adding from="node"  (note the trailing space) at the start of the line, where node is the FQDN or IP address of the spare system. It may be necessary to provide the FQDN, IP address, and/or alias of the spare system in a comma separated list in place of node to get reliable operation.

    2. Setup the spare account to run rrsync with sudo with a password (which will make refresh_spare_usr2 fail unless it is used with the procedure in the Using backup_usr2 with CIS hardening section below) and with passing environment variables. Use visudo to add:

      spare          ALL=(ALL) SETENV: /usr/bin/rrsync

    3. Setup sudo on the operational machine to allow operators to run the backup_usr2 script with:

      %operators      ALL=(ALL) /usr/local/sbin/backup_usr2

    4. Install the sudo script backup_usr2:

      1. Move the script into position:

        ~/fsl11/RAID/install_backup_usr2

      2. Customize /usr/local/sbin/backup_usr2 following the directions in the comments in the script (repeated here):

        1. Comment-out the lines (add leading #s):

          echo "This script must be customized before use.  See script for details."
exit 1

        2. Change the spare in the line:

          remote_node=spare

          to the alias (preferred), FQDN, or IP address of your spare system.

    5. Install the AUID script that runs the sudo script:

      ~/fsl11/AUID/install_backup_usr2

    6. Lock-out the spare account from normal login (but it must have a shell). This will disable password login, but not ssh login with keys, for this account. Execute:

      usermod -L spare

    7. Disable password aging and account inactivity expiration for the spare account. Execute:

      chage -I -1 -M -1 spare

    8. Copy root ssh key for running backup_usr2:

      For each AUID account on the operational system that will use backup_usr2, copy the ssh key from root on the operational system to the AUID account on the operational system. The AUID account must have been created on both systems before using this method.

      1. Create a key:

        If the root account already has a key, you should skip this step.

        Caution
        		 Your should not set a passphrase. 
        ssh-keygen

      2. Copy the key to to the authorized_keys for each AUID user that will use backup_usr2.

        Note
        		 The first command below will generate an error File exists if the directory already exists. That is benign and can be ignored. 
        mkdir ~AUID/.ssh
cat /root/.ssh/id_rsa.pub >>~AUID/.ssh/authorized_keys
chown -R AUID.AUID ~AUID/.ssh

        where AUID is the AUID account that will use backup_usr2.

      Note
      		 The key now stored in the AUID account on the operational system will be copied to that account on the spare system the next time backup_usr2 is run. Until then, each user would need to enter their password to connect to the spare system when running backup_usr2.

A.7. Using backup_usr2 with CIS hardening

To use backup_usr2 as part of a monthly backup, you first should perform a disk rotation on both systems. The disk rotation procedure is described in the Disk rotation section of the RAID Notes for FSL11 document. You should start a disk rotation on the spare system (e.g., fs2) first. Once this is successfully refreshing, log out of the spare system. Then start a disk rotation running on the operational system (e.g., fs1). Once that is successfully refreshing, don’t log out. Proceed directly to the instructions below.

You can also use the procedure below to “freshen” the /usr2 on the spare system at other times.

Note
 For CIS hardened systems, the backup_usr2 script is used on the operational system to backup its /usr2 partition to the spare system. To do this, it invokes refresh_spare_usr2 on the spare system.

  1. Start with no one logged into either system.

    Important

    Before proceeding, make sure that no one is logged into either system and that no processes are running on /usr2 on either system, particularly the FS.

    Tip
    		 If the only session logged on the systems is the AUID session you used to start the disk refresh on the operational system, and there is no other activity on /usr2, you can use that session in the directions below without logging out first.

  2. On the operational system:

    1. Login to your AUID account if you aren’t already logged in.

    2. Run:

      backup_usr2
      Note
      		 You may be prompted for your AUID password on the operational system in order to run the script if it has been more than 15 minutes since you used sudo in that session, e.g., to start a refresh.
      Note

      You may be prompted for your AUID password for the spare system in order to connect to that system.

      Tip
      		 You can eliminate this password prompt by copying the ssh key from the root account on the operational system to your AUID account on the spare system (and to the operational system). See the sub-step Copy root ssh key for running backup_usr2 in the Installing backup_usr2 with CIS hardening section above for instructions.

      The refresh_spare_usr2 script will be run on the spare system automatically.

      Note
      		 You will be prompted for your AUID password for the spare system in order to run refresh_spare_usr2 on that system with sudo. It is not possible to eliminate this prompt.

      Answer the question y if it is safe to proceed.

  3. Log out of the operational system.

  4. Wait until the refresh_spare_usr2 script on the spare system has finished before logging in again and resuming other activities on the systems.

    This step (and procedure) continues at the Wait step in the Using refresh_spare_usr2 subsection of the refresh_spare_usr2 subsection of the RAID Notes for FSL11 document.