Document revision history
+-
+
-
+
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: +
+
+
|
+
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. +
+
+
|
+
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:
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:
+-
+
-
+
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.
+
+ -
+
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.
+-
+
-
+
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
+++The root_tmp script performs three actions:
+++-
+
-
+
Creates a one time service at boot to clean the /root/tmp directory
+
+ -
+
Sets dpkg-preconfigure to use /root/tmp for temporary files
+
+ -
+
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.
+ -
+
-
+
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 oper, prog, +and/or AUID 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 99999 oper +chage -I -1 -M 99999 prog +chage -I -1 -M 99999 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.
+-
+
-
+
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.)
+
+ -
+
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
+ -
+
Execute:
+++++chmod a+rx /usr/local/bin/oper_account
+
+ -
+
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
+ -
+
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. The oper_x11 and +prog_x11 scripts can be used on a text console to start an X11 +session and promote.
+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.
+-
+
-
+
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.
+
+ -
+
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
+
+ -
+
If the user should be able to manage printers, use:
+++++adduser dhorsley lpadmin
+
+ -
+
If the user is allowed to elevate to root, use visudo to add:
+++++dhorsley ALL=(root) ALL
+
+ -
+
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.
+
+ -
+
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:
+++-
+
-
+
Press Ctrl+Alt+F1 to get to the GUI login.
+
+ -
+
Enter
+dhorsley
as theUsername
.
+ -
+
Select the “gear” icon in the lower right-hand corner.
+
+ -
+
Select
+System X11 Default
.
+ -
+
Complete logging in with the password.
+
+ -
+
Logout with
+exit
.
+
+ -
+
-
+
You may wish to proceed to the next section +Copy ssh key for running backup_usr2 if that is appropriate for +this user.
+
+
A.4. Copy ssh key for running backup_usr2
+For each AUID account 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.
+As root on the operational system:
+-
+
-
+
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
+
+ -
+
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
+++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, this user would need to enter +their password to connect to the spare system when running +backup_usr2. + +
+
A.5. Enable operators group accounts to rotate disks
+-
+
-
+
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. + +
+ -
+
Install AUID scripts to allow
+operators
group accounts to run +the sudo scripts without explicitly entering sudo:++++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.6. 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.
+-
+
-
+
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.
+
+ -
+
Create a file /etc/hostname_alias that contains the new alias.
+++-
+
-
+
Execute
+++++cd /etc +cp hostname hostname_alias +chmod a+r hostname_alias
+
+ -
+
Edit the new file and change the contents to the new alias.
+
+
+ -
+
-
+
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. + +++-
+
-
+
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.
+
+ -
+
Edit /etc/exim4/update-exim4.conf.conf, change the value of +
+dc_other_hostnames=
to the new alias
+ -
+
Execute
+++++update-exim4.conf +systemctl restart exim4
+
+
+ -
+
-
+
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:++-
+
-
+
Before the
+if
block that setsPS1
add:++++hostalias_file=/etc/hostname_alias +if [[ -f "$hostalias_file" ]]; then + hostalias=$(cat $hostalias_file) +else + hostalias=$(hostname) +fi
+
+ -
+
In the two statements setting
+PS1
in theif
block, change the +use of\h
to$hostalias
.
+ -
+
In the statement setting
+PS1
in thecase
block that sets the +xterm window title, change the use of\h
to$hostalias
.
+
+ -
+
-
+
For a spare system only, if you have one:
+++-
+
-
+
Update /usr/local/sbin/refresh_spare_usr2 to use the new alias of +the operational system in the ssh line.
+
+ -
+
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
whereoperational
is the new alias for the +operational system. The command will give you guidance for which +lines need to be deleted in /root/.ssh/known_hosts. After deleting +those lines, reconnect using the same ssh command and answeryes
+to confirm connecting. The login will be rejected because of the +forced-command setup on the operational system. The error message +will probably not seem to make sense, but will end with a line like: +Connection to operational closed.
. Still, the task of recording +the host key will have been accomplished.
+
+ -
+
A.7. 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. + | +
-
+
-
+
On the operational system:
+++-
+
-
+
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. + +
+
+ -
+
-
+
On the spare system:
+++-
+
-
+
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.
+
+ -
+
Install the sudo script refresh_spare_usr2:
+++-
+
-
+
Move the script into position:
+++++~/fsl11/RAID/install_refresh_spare_usr2
+
+ -
+
Customize /usr/local/sbin/refresh_spare_usr2, following the +directions in the comments in the script (repeated here):
+++-
+
-
+
Comment-out the lines (add leading
+#
s):++++echo "This script must be customized before use. See script for details." +exit 1
+
+ -
+
Change the
+operational
in the line:++++remote_node=operational
+++to the alias (preferred), FQDN, or IP address of your operational +system.
+
+ -
+
Uncomment the line for CIS hardened systems. The commented out +form is:
+++++#remote_user=spare
+
+
+ -
+
-
+
Enable running the sudo script with either with 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
+
+
+ -
+
-
+
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
+
+ -
+
Copy the key:
+++++ssh-copy-id spare@operational
+++where
+operational
is the alias, name, or IP of your operational +system.
+
+ -
+
-
+
On the operational system:
+++-
+
-
+
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, wherenode
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 ofnode
to get reliable +operation. +
+ -
+
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
+
+ -
+
Setup sudo on the operational machine to allow
+operators
to +run the backup_usr2 script with:++++%operators ALL=(ALL) /usr/local/sbin/backup_usr2
+
+ -
+
Install the sudo script backup_usr2:
+++-
+
-
+
Move the script into position:
+++++~/fsl11/RAID/install_backup_usr2
+
+ -
+
Customize /usr/local/sbin/backup_usr2 following the directions +in the comments in the script (repeated here):
+++-
+
-
+
Comment-out the lines (add leading
+#
s):++++echo "This script must be customized before use. See script for details." +exit 1
+
+ -
+
Change the
+spare
in the line:++++remote_node=spare
+++to the alias (preferred), FQDN, or IP address of your spare system.
+
+
+ -
+
+ -
+
-
+
Install the AUID script that runs the sudo script:
+++++~/fsl11/AUID/install_backup_usr2
+
+ -
+
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
+
+ -
+
Disable password aging and account inactivity expiration for the +spare account. Execute:
+++++chage -I -1 -M 99999 spare
+
+
+ -
+
A.8. 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. + | +
-
+
-
+
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. + +
+ -
+
On the operational system:
+++-
+
-
+
Login to your AUID account if you aren’t already logged in.
+
+ -
+
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 section Copy ssh key for running backup_usr2 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.
+
+ -
+
-
+
Log out of the operational system.
+
+ -
+
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.
+
+