CIS hardening for FSL10

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

This section covers manual operations that are required after running the script.

All the CIS remediations that can applied at this point have been completed. The next section describes some other policies that can be considered.

This section describes other policies that may be desirable. Some are beyond the CIS benchmark.

Must be set later by administrators.

X Window system is required for FS use.

CUPS is required for operations.

Exim4 is required as MTA; it never accepts incoming remote connections (blocked at firewall).

The firewall is configured with ufw instead of iptables and ip6tables. This causes four to six issues depending on the details of the installation, but ufw provides the same security as the recommended remediations. The configuration is set to by default deny for incoming connections, enable incoming SSH connections, and sets logging for all connections. Setup:

A remote log server must be configured by system administrators later.

All files except /var/log/wtmp have the requested permissions. That file changes on a reboot to rw-rw-r--, owned by root.wtmp. No sensitive information is stored in the file and making it readable for others allows commands like last and who to work.

We require ssh X11 forwarding for use with FS for remote operations and testing.

System accounts (i.e., accounts with UID less than 1000) oper and prog are needed for compatibility with the wider VLBI community and are only used as service accounts from AUID accounts. They require a valid shell, but direct local login and ssh login (including with keys) are disabled for these two accounts. Note that oper and prog have no password expiration (they has no passwords) or inactivity time-out, like other system accounts.

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

Would prefer to keep the telnet client, it is useful for debugging ASCII device protocol devices, which we have. The security weakness is telnetd, which is not installed, nor does the benchmark test for it.

This may not be appropriate for an operational system.

What ciphers should we use?

What MAC algorithms should we use?

What Key Exchange algorithms should we use?

Five minutes is too short.

Should we use the NASA 12 character minimum?

This is too short for developers/troubleshooters

Remediation solves problem, but does not make the test pass. To do the latter required purge.

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

The remediation does not make the test pass, that required purge.

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

Many of the remedations are described in terms of the contents of /etc/audit/audit.rules. However, the contents of that file are auto-generated at boot from the files in /etc/audit/rules.d, which is where these remediations must go.

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

64-bit remediation was missing b32 rule.

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

The model of FSL 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 log-in using their own account (possibly named with their Agency User ID, AUID). As the Field System currently operates, users will then need to switch to the oper or prog account after login. Likewise, if a user is allowed to elevate to root, they will need to do so after log-in to their own account. This sub-section covers how to enable this capability. The next sub-section Adding AUID accounts covers how to add an AUID account. The method described here, and in the next sub-section, uses dhorsley as an example user.

For oper and prog, we suggest creating two groups that can sudo to the accounts.

run visudo then add at end:

To allow operators to use refresh_secondary, shutdown, and reboot, add (respectively):

To use these commands the operators will need to enter (respectively) from their AUID accounts:

A password will be required. Trailing options can be used with the commands, as appropriate.

If the user can elevate to root, also add:

Create the groups if they don’t exist:

If they don’t already, make sure oper and prog have usable shells:

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

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

And restart sshd with:

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

No password will be required (except for root).

To ensure X authorization works do the following (this example is for user oper and works analogously for prog and root, but see the note at the end of step (1) about root's Xresources:

The three numbered steps above can be executed for oper, prog, and root with:

This sub-section describes how to add AUID accounts to be used with the ability to promote to oper, prog, and root as described in the previous sub-section. As in the previous sub-section, the following method uses dhorsley as an example user.

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, who is dealng with multiple issue, which might include: power failures, equipment problems, and logistical issues. It can be a chaotic situation. Typing long and complicated passwors 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 increase the amount of data that will be lost.

If you find the number of login failures before lock-out 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:

Small integer values (20 or less) should not be a signficant risk with long and complicated passwords and a lock-out of several minutes.

These steps set a more user friendly alias for the computers 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. These steps should be executed for both the operational and spare computers.

This subsection describes the steps needed to enable use of the refresh_spare_usr2 script with CIS hardening. All steps must be performed as root on the specified system. You should read all of each step or sub-step before following it.