mitre / canonical-ubuntu-20.04-lts-stig-baseline

InSpec profile to validate the secure configuration of Ubuntu 20.04, against DISA's Canonical Ubuntu 20.04 LTS Security Technical Implementation Guide (STIG) Version 1, Release 6.

canonical-ubuntu-20.04-lts-stig-baseline

InSpec profile to validate the secure configuration of Ubuntu 20.04, against DISA's Canonical Ubuntu 20.04 LTS Security Technical Implementation Guide (STIG) Version 1, Release 6.

Getting Started

It is intended and recommended that InSpec run this profile from a "runner" host (such as a DevOps orchestration server, an administrative management system, or a developer's workstation/laptop) against the target remotely over ssh.

For the best security of the runner, always install on the runner the latest version of InSpec and supporting Ruby language components.

Latest versions and installation options are available at the InSpec site.

Tailoring to Your Environment

The following inputs must be configured in an inputs ".yml" file for the profile to run correctly for your specific environment. More information about InSpec inputs can be found in the InSpec Profile Documentation.

temporary_accounts: []
banner_text: 'You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

    By using this IS (which includes any device attached to this IS), you consent to the following conditions:

    -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

    -At any time, the USG may inspect and seize data stored on this IS.

    -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

    -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

    -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.'
  sudo_accounts: [ "ubuntu" ]
  tmout: 600
  action_mail_acct: root
  audit_tools: [
      '/sbin/auditctl',
      '/sbin/aureport',
      '/sbin/ausearch',
      '/sbin/autrace',
      '/sbin/auditd',
      '/sbin/audispd',
      '/sbin/augenrules'
    ]
  standard_audit_log_size: 8894028
  aide_conf_path: '/etc/aide/aide.conf'
  action_mail_acct: root
  maxlogins: 10
  is_kdump_required: false
  is_system_networked: true
  sssd_conf_path: '/etc/sssd/sssd.conf'
  allowed_ca_fingerprints_regex: (9676F287356C89A12683D65234098CB77C4F1C18F23C0E541DE0E196725B7EBE|B107B33F453E5510F68E513110C6F6944BACC263DF0137F821C1B3C2F8F863D2|559A5189452B13F8233F0022363C06F26E3C517C1D4B77445035959DF3244F74|1F4EDE9DC2A241F6521BF518424ACD49EBE84420E69DAF5BAC57AF1F8EE294A9)
  allowed_network_interfaces: [
      'lo',
      'eth0'
    ]
  audit_sp_remote_server: '192.0.0.1'
  approved_wireless_interfaces: []
  fips_config_file: '/proc/sys/crypto/fips_enabled'
  chrony_config_file: '/etc/chrony/chrony.conf'
  useradd_config_file: '/etc/default/useradd'
  rsyslog_config_file: '/etc/rsyslog.d/50-default.conf'
  auditoffload_config_file: '/etc/cron.weekly/audit-offload'
  audispremote_config_file: '/etc/audisp/plugins.d/au-remote.conf'
  gdm3_config_file: '/etc/gdm3/greeter.dconf-defaults'

Running This Baseline Directly from Github

# How to run
inspec exec https://github.com/mitre/canonical-ubuntu-20.04-lts-stig-baseline/archive/master.tar.gz --target=ssh://<your_target_host_name_or_ip_address> --user=<target_account_with_administrative_privileges> --password=<password_for_target_account> --sudo --sudo-password=<sudo_password_for_target_if_required> --input-file=<path_to_your_inputs_file/name_of_your_inputs_file.yml> --reporter=cli json:<path_to_your_output_file/name_of_your_output_file.json>

Different Run Options

Full exec options

Running This Baseline from a local Archive copy

If your runner is not always expected to have direct access to GitHub, use the following steps to create an archive bundle of this baseline and all of its dependent tests:

(Git is required to clone the InSpec profile using the instructions below. Git can be downloaded from the Git site.)

When the "runner" host uses this profile baseline for the first time, follow these steps:

mkdir profiles
cd profiles
git clone https://github.com/mitre/canonical-ubuntu-20.04-lts-stig-baseline
inspec archive canonical-ubuntu-20.04-lts-stig-baseline
inspec exec <name of generated archive> --target=ssh://<your_target_host_name_or_ip_address> --user=<target_account_with_administrative_privileges> --password=<password_for_target_account> --sudo --sudo-password=<sudo_password_for_target_if_required> --input-file=<path_to_your_inputs_file/name_of_your_inputs_file.yml> --reporter=cli json:<path_to_your_output_file/name_of_your_output_file.json>

For every successive run, follow these steps to always have the latest version of this baseline:

cd canonical-ubuntu-20.04-lts-stig-baseline
git pull
cd ..
inspec archive canonical-ubuntu-20.04-lts-stig-baseline --overwrite
inspec exec <name of generated archive> --target=ssh://<your_target_host_name_or_ip_address> --user=<target_account_with_administrative_privileges> --password=<password_for_target_account> --sudo --sudo-password=<sudo_password_for_target_if_required> --input-file=<path_to_your_inputs_file/name_of_your_inputs_file.yml> --reporter=cli json:<path_to_your_output_file/name_of_your_output_file.json>

Viewing the JSON Results

The JSON results output file can be loaded into heimdall-lite for a user-interactive, graphical view of the InSpec results.

The JSON InSpec results file may also be loaded into a full heimdall server, allowing for additional functionality such as to store and compare multiple profile runs.

Authors

Special Thanks

• Mohamed El-Sharkawi - HackerShark

Contributing and Getting Help

To report a bug or feature request, please open an issue.

NOTICE

© 2018-2020 The MITRE Corporation.

Approved for Public Release; Distribution Unlimited. Case Number 18-3678.

NOTICE

MITRE hereby grants express written permission to use, reproduce, distribute, modify, and otherwise leverage this software to the extent permitted by the licensed terms provided in the LICENSE.md file included with this project.

NOTICE

This software was produced for the U. S. Government under Contract Number HHSM-500-2012-00008I, and is subject to Federal Acquisition Regulation Clause 52.227-14, Rights in Data-General.

No other use other than that granted to the U. S. Government, or to those acting on behalf of the U. S. Government under that Clause is authorized without the express written permission of The MITRE Corporation.

For further information, please contact The MITRE Corporation, Contracts Management Office, 7515 Colshire Drive, McLean, VA 22102-7539, [phone].

NOTICE

DISA STIGs are published by DISA IASE, see: https://iase.disa.mil/Pages/privacy_policy.aspx

canonical-ubuntu-20.04-lts-stig-baseline's Issues

BUG: SV-238336 incorrectly categorized

This STIG control is somewhat confusing.

The STIG states that the finding will always be open, but the severity level changes depending on the result of the check.

The STIG itself is marked as a XCDDF severity="low", but the Check Text states that it's a CAT-II unless the mcafeetp package is installed and running.

The Inspec baseline incorrectly marks this as an open CAT-III if the package is not installed or not running. It also incorrectly marks this as closed if the package is installed and running.

The SV-238336.rb file should be changed to mark this as an open impact 0.5 if mcafeetp is not installed or not running.
It should mark this control as an open impact 0.3 if the package is installed and running.

Create a workflow Tag and Release profiles on delta updates or patches

The 'Tag and Release Process' would:

Start a new release by updating the version of the profile in:

• update the version in inspec.yml
• Generate a CHANGELOG file
• Generate a VERSION file
• Tag that release in GitHub

BUG: SV-238329 malformed describe.one

The control tries to check for lock either via the /etc/shadow file or using the passwd -S root command.

The InSpec code suggests describe.one but ends after then shadow file check, then parses the passwd -S command as though they were separate checks.

A correction might read:

  describe.one do
    describe shadow.where(user: 'root') do
      its('passwords.uniq.first') { should eq '!*' }
    end
    describe command('passwd -S root').stdout.strip do
      it { should match(/^root\s+L\s+.*$/) }
    end
  end

BUG: SV-238306 only checking au-remote.conf

The STIG states that /etc/audisp/plugins.d/au-remote.conf should contain the line active = yes.

It also states that /etc/audisp/audisp-remote.conf should contain the remote_server = address.

The control is checking audispremote_config_file for both, but should be checking separate files.

Review current Failed tests on Hardened and see if we can get above 90%

BUG: SV-238320 incorrectly checking for /sbin/fdisk

The STIG states that the file in the audit rule should be /usr/sbin/fdisk.

The control is incorrectly looking for /sbin/fdisk

BUG: SV-238333 only checks 1 of 2 STIG items

This control only checks the value of net.ipv4.tcp_syncookies via the sysctl command.

If the systctl command returns 1 but the /etc/sysctl.conf or /etc/sysctl.d/* files do not have it explicitly configured, the control should fail per the STIG Check Text.

BUG: SV-238356 checks and incorrect maxpoll time and format

The STIG says at least every 24 hours.

A value of maxpoll 16 is 2^16 seconds, or just over 18 hours

The control checks for maxpoll = 17 which is an invalid format and is beyond 24 hours at 2^17 seconds, or 1.5 days.

The chrony.conf file format shows that the line should contain maxpoll x and not maxpoll = x.

The STIG Check Text shows this correctly, while the Fix Text displays it incorrectly.

Maintenance

Where is the work for this profile being done?

BUG: All controls - Tags have a trailing space character

All control tags have a trailing space.

When converted from JSON to CKL via Heimdall, the space remains in the CKL file's ATTRIBUTE node.

This makes it impossible to import the data into a checklist newly created from STIG Viewer due to the data mismatch.

Add report generation for container applicable and not container applicable controls - see useful scripts in desc

https://github.com/haltcase/tablemark-cli

1. Create a profile json filtering the output to controls that either only apply to the host or the container
2. inspec json . --tags host| jq . > host-only.json or something like this
3. jq -r '.controls[] | {title: .title, id: .id, description: .desc}' host-only.json ( small bug that the elements are not separated by commas, perhaps this is why tablemark talked about the ndjson thing
4. yarn global add tablemark-cli
5. tablemark x.json > test.md

BUG: SV-238336 searching incorrect package name

The STIG states the package named mcafeetp should be installed.

The Inspec file here is searching for a packaged named mfetp which does not exist.

BUG: SV-238235 is looking for pam_tally instead of pam_faillock

The STIG is looking for the pam_faillock.so module, but the control is searching for the pam_tally module

A correction would be something like this:

    describe command('grep faillock /etc/pam.d/common-auth') do
      its('exit_status') { should eq 0 }
      its('stdout.strip') { should match(/^\s*auth\s+\[default=die\]\s+pam_faillock.so\s+authfail$/) }
      its('stdout.strip') { should match(/^\s*auth\s+sufficient\s+pam_faillock.so\s+authsucc$/) }
    end

BUG: SV-238228 checks for non STIG parameters

The InSpec control is searching for:
^password\s+requisite\s+pam_pwquality.so\s+retry=3\s+enforce_for_root$

The STIG check and fix text both state the line should contain:
password requisite pam_pwquality.so retry=3

While I agree that enforce_for_root is good practice, it is nowhere to be found in the STIG itself.

The control should be updated to grep for the line containing password requisite pam_pwquality.so, then only check for the presence of retry=3

Fix profile errors and update thresholds

There are currently 7 profile errors.

Please resolve them and then update the thresholds to again enforce zero errors.

Missing conditional logic - ssh client , sshd_server, pam? ....

There is missing conditional logic where if running on a container or host we need to verify if the service package is installed, or installed and enabled, that tests are run, other wise it would be Not Applicable.(

I see there are the ssh client ones and I ran across a couple sshd_server ones as well. This would come out in something like:

if `disable_thing_input
 ... NA
eleif !package('service_package').installed?
  ... NA
eleif ( in a container )*
  ... NA or tests differnt
eleif ( other NA conditions defined by the control )*
  NA
else
    run standard tests
 end

* optional - may not really apply

• ssh client
• sshd server
• pki related
• (list others here)

BUG: V-238201 fails if additional entries are present

The control parses /etc/pam_pkcs11/pam_pkcs11.conf to find the line containing use_mappers

If that entry looks like the following, the control fails:
use_mappers = digest, cn, pwent, uid, mail, subject, null;

The Check Text states:

If "use_mappers" is not found or the list does not contain "pwent" this is a finding.

The Fix Text states:

Set "use_mappers=pwent" in "/etc/pam_pkcs11/pam_pkcs11.conf" or, if there is already a
comma-separated list of mappers, add it to the list, separated by comma, and before the null
mapper.

Changing line 50 in V-238201.rb from cmp to match corrects the issue.

BUG: SV-238229, SV-238232, SV-238233 do not check the correct module policy

The /etc/pam_pkcs11/pam_pkcs11.conf file can have different configurations for each pkcs11 module.

The STIG expects the user to check the module in use by checking the value of use_pkcs11_module.

Then, the user is expected to look at that module's configuration for the determination of the cert_policy settings.

If your pam_pkcs11.conf file contains the following, the control will fail:

use_pkcs11_module = opensc;
pkcs11_module opensc {
  cert_policy = ca,signature,ocsp_on,crl_auto;
}
pkcs11_module default {
  cert_policy = none;
}

An example for the correction of SV-238229.rb file might say:

  tag 'host'

  pkmod = command('grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf |cut -d \'=\' -f2|cut -d \';\' -f1|xargs').stdout.strip
  awkcmd = "awk '/pkcs11_module #{pkmod} {/,/}/\' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy"

  if virtualization.system.eql?('docker')
    impact 0.0
    describe 'Control not applicable to a container' do
      skip 'Control not applicable to a container'
    end
  elsif input('pki_disabled')
    impact 0.0
    describe 'This system is not using PKI for authentication so the controls is Not Applicable.' do
      skip 'This system is not using PKI for authentication so the controls is Not Applicable.'
    end
  else
    config_file_exists = file('/etc/pam_pkcs11/pam_pkcs11.conf').exist?
    if config_file_exists
      describe parse_config_file('/etc/pam_pkcs11/pam_pkcs11.conf') do
        its('use_pkcs11_module') { should_not be_nil }
        describe command(awkcmd) do
          its('stdout') { should include 'ca' }
        end
      end
    else
      describe '/etc/pam_pkcs11/pam_pkcs11.conf exists' do
        subject { config_file_exists }
        it { should be true }
      end
    end
  end

Note the variables pkmod and awkmod and the describe command below the parse_config_file.

Add tags for `host` vs `container` for the controls

add a

tag 'host'
or
tag 'container'
or 
tag 'host','container'

to each control as appropriate for that controls' context

BUG: SV-238316 incorrectly checking for /var/run/wtmp

The STIG states that the audit rule should be in place for /var/run/utmp.

The control is incorrectly checking for /var/run/wtmp instead.

The wtmp file is being checked as /var/log/wtmp in SV-238315.

BUG: SV-238197, SV-238199

Both controls attempt to determine if a GUI is installed.

If a GUI is not installed, the controls state that a GUI is not installed, but mark the control as Not Reviewed.

The STIG states that if a GUI is not installed, the control is Not Applicable.

The SV-238198 control correctly marks this as NA by setting impact 0.0.

Create a file that lists the controls that are NA or applicable to containers for folks to have as a reference as we did for RHEL7/8