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=5Small 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
-CISfixsystemd 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
-noexecoption 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 -noexecoption 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
-noexecoption 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
-dhorsleyas 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 existsif -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
-AUIDis 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
--hor-poptions 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
-operatorsgroup 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'
-PATHvariables. 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 -
-.bashrcfile for each user to be changed:---
-
-
-
Before the
-ifblock that setsPS1add:----hostalias_file=/etc/hostname_alias -if [[ -f "$hostalias_file" ]]; then - hostalias=$(cat $hostalias_file) -else - hostalias=$(hostname) -fi
-
- -
-
In the two statements setting
-PS1in theifblock, change the -use of\hto$hostalias.
- -
-
In the statement setting
-PS1in thecaseblock that sets the -xterm window title, change the use of\hto$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@operationalwhereoperationalis 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
-operationalin 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
-operationalis 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-rsaat 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, wherenodeis 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 ofnodeto 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
-operatorsto -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
-sparein 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
-yif 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.
-
-