Applying DISA STIG hardening to SLES installations
The DISA and SUSE have authored a STIG (Secure Technical Implementation Guide) that describes how to harden a SUSE Linux Enterprise system.
The STIG is a long list of rules, each containing description, detection of problems and how to remediate problems on a per rule basis.
While originally STIGs are supposed to applied manually, a large percentage of the rules can be and were automated in so called SCAP format (Secure Content Automation Protocol), in a specifically created format called XCCDF (Extensible Configuration Checklist Definition Format).
What does SUSE provide?
SUSE provides the following variants:
- XCCDF format rules based on ComplianceAsCode, doing detection and also automated remediation
- single bash script to apply system hardening
- ansible playbook to apply system hardening
These are all contained in the “scap-security-guide” RPM package delivered for SUSE Linux Enterprise 12 SP5, and all SUSE Linux Enterprise 15 Service Packs.
We can classify rules into multiple cases:
- rules that need to be applied during installation of a system
- rules where remediation can be automatically applied after installation
- rules that are not able to be checked automatically nor remediated
- rules without automated remediation
Rules that need to be applied during installation of a system
The following currently needs to be observed manually during installation of a system:
|SLES-15-010190 SLES-15-010200||CCE-83274-1 CCE-83275-8||A boot password must be set.||A bootloader password (for grub2) must be configured during installation. In YAST this can be done in the bootloader setup dialog.|
|SLES-15-030660||CCE-85697-1||There needs to be sufficient storage capacity in which to write the audit logs /var/log/audit/||The partition size needed to capture a week of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records in /var/log/ will be sufficient.|
|Separate partitions for /home, /var and /var/log/audit.||These rules avoid attackers able to fill the disk by flooding home directory, logging or audit data.
Note that you should also give sufficient space to /var and /var/log/audit (see above)
|SLES-15-010330||CCE-85719-3||All persistent disk partitions must be encrypted.||You must install the system with full system encryption for all persistent disks. If using YAST, please setup a respective full disk encryption partitioning proposal.|
Rules where remediation can be automatically applied after installation
To apply the automated rules, multiple ways to do so are available.
Install the scap-security-guide and openscap-utils packages.
For evaluation and reporting only:
oscap xccdf eval --profile stig /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
For evaluation and remediation:
oscap xccdf eval --profile stig --remediate /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
Only the single ssg-sle15-ds.xml file is needed to run above commands, which can be extracted out of the scap-security-guide RPM if there are size constraints on your installation.
Via shell script
Install scap-security-guide and run:
The shell script is standalone and can also be copied out of the RPM if you do not want the full installation size of the RPM.
Rules that are not able to be checked automatically nor remediated
Some STIG rules that can not be checked automatically nor remediated.
|SLES-15-030800||audispd’s Plugin disk_full_action When Disk Is Full||Configure audispd’s Plugin disk_full_action When Disk Is Full|
|SLES-15-030790||Configure audispd’s Plugin network_failure_action On Network Failure||Taking appropriate action when there is an error sending audit records to a remote system will minimize the possibility of losing audit records.|
|SLES-15-030620||Verify Permissions of Local Logs of audit Tools||Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information.|
|SLES-15-030600||Verify that Local Logs of the audit Daemon are not World-Readable||Verify that Local Logs of the audit Daemon are not World-Readable|
Rules without automated remediation
This section includes the rules where our SCAP profile does not offer automated remediation for various reasons. The table list all those rules and why it is not possible.
|Rule ID||CCE ID||rule_name||Reason of why there is no remediation|
|SLES-15-010000||CCE-83260-0||installed_OS_is_vendor_supported||Justification: Many possible OS
There can be no automatic remediation as remediation is update of the OS or switching to another OS
|SLES-15-030790||CCE-85705-2||auditd_audispd_network_failure_action||Justification: Cannot guarantee the location of the file in question, or its contents
There is no one option to handle the network failure it can be ‘syslog’,’single’ for switching to single user or ‘halt’ to halt the system on failure, so it is better user to decide, knowing system specifics
|SLES-15-020060||CCE-85559-3||account_emergency_admin||Justification: Not possible as we cannot know what customer set up of Emergency accounts is|
Justification: Not Possible
The recommended fix for that vulnerability is to
“Lock all interactive user accounts not using SHA-512 hashing until the passwords can be regenerated with SHA-512.”
|SLES-15-040120||CCE-85631-0||accounts_user_home_paths_only||The recommended remediation in this case is:
“Edit the local interactive user initialization files to change any PATH variable statements that reference directories other than their home directory.”
|SLES-15-020000||CCE-85553-6||account_temp_expire_date||Justification: Not possible as we cannot know how many accounts or info of those accounts clients have enabled|
|SLES-15-010230||CCE-83277-4||account_unique_id||Justification: Not possible as we don’t have info on accounts such which are safe for deletion or how UIDs are changed|
|SLES-15-030660||CCE-85697-1||auditd_audispd_configure_sufficiently_large_partition||Justification: There are many different possibilities for how a client may have computer storage set up|
Justification: Requires manual remediation
Justification: Many different accounts and configurations possible, depending on the client.
The risk is here again to break a working system if some custom software or setup is currently working with world writable directories owned by non-system account users
|SLES-15-010330||CCE-85719-3||encrypt_partitions||Justification: Automatic remediation of disk encryption risks breaking system and requires interactive operation|
|SLES-15-040410||CCE-85658-3||file_permissions_ungroupowned||Justification: Cannot know which group or owner files should be assigned to.|
Justification: Cannot know accounts on a clients system
Changing the permissions of init files might break the initialization of user’s operation so it hides of risk of breaking system operation
|SLES-15-010190||CCE-83274-1||grub2_password||Justification: To prevent hard-coded passwords, automatic remediation of this control is not available.|
|SLES-15-010200||CCE-83275-8||grub2_uefi_password||Justification: To prevent hard-coded passwords, automatic remediation of this control is not available.|
|SLES-15-010510||CCE-85763-1||is_fips_mode_enabled||Justification: Cannot know if there is a reason for why a client would not have FIPS mode enabled.|
|SLES-15-040390||CCE-85656-7||network_sniffer_disabled||Justification: Cannot know if promiscuous mode is enabled for a valid reason.|
Justification: Remediation impossible as we cannot know all the users on any system.
Remediation of this would require knowledge to which user to give ownership of unowned files
|SLES-15-020091||CCE-85672-4||no_shelllogin_for_systemaccounts||Justification: We can’t know all the user accounts on a clients system, or why they may want to give certain users specific permissions|
Justification: We can’t know all the user accounts on a clients system, or why they may want to give certain users specific permissions
In general it is a risky remediation but we have implemented automatic remediation for similar cases, and from what I see at the time of importing this rule remediations were not a priority at all so we kind of skipped it later, also possibly due to risk factor
In the rule it is documented:
“This rule doesn’t come with a remediation, as the exact requirement allows exceptions, and removing lines from the sudoers file can make the system non-administrable.”
Justification: Bash remediation not implemented, since at the time of implementing the rule only ansible was priority. Later on we missed to go back here and implement bash remediation
Comments: Has Ansible remediation, only missing Bash
|SLES-15-010340||CCE-85755-7||permissions_local_var_log||Comments: Has Ansible remediation, only missing Bash|
|SLES-15-020180||CCE-85567-6||set_password_hashing_min_rounds_logindefs||Comments: Has Ansible remediation, only missing Bash|
Remediation of this rule depends on partitioning scheme so most cases depends on installation phase decisions
same reasoning as partition_for_home rule