Giter VIP home page Giter VIP logo

canonical-ubuntu-18.04-lts-server-cis-baseline's Introduction

canonical-ubuntu-18.04-lts-server-cis-baseline

InSpec profile to validate the secure configuration of Canonical Ubuntu 18.04 LTS Server against the CIS' - CIS Ubuntu Linux 18.04 LTS Benchmark v2.0.1.

Getting Started

It is intended and recommended that InSpec and this profile overlay be run 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 may 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.

# Name of the OS/Platform
platform_name: ''

# Release number of the OS/Platform
platform_release: 18.04

# Support end date for OS/Platform security updates
supported_until: ''

# Audit log file path
log_file_path: ''

# Audit log file directory
log_file_dir: ''

# Organization Name
org_name: ''

# Banner message text for command line interface logins.
banner_message_text_cli: ''

# Banner message text for resource-limited command line interface logins.
banner_message_text_cli_limited: ''

# These shells do not allow a user to login
non_interactive_shells: []

Running This Baseline Directly from Github

# How to run
inspec exec https://github.com/mitre/canonical-ubuntu-18.04-lts-server-cis-baseline/archive/master.tar.gz -t ssh://TARGET_USERNAME:TARGET_PASSWORD@TARGET_IP:TARGET_PORT --sudo --sudo-password=<SUDO_PASSWORD_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-18.04-lts-server-cis-baseline
inspec archive canonical-ubuntu-18.04-lts-server-cis-baseline
inspec exec <name of generated archive> -t ssh://TARGET_USERNAME:TARGET_PASSWORD@TARGET_IP:TARGET_PORT --sudo --sudo-password=<SUDO_PASSWORD_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-18.04-lts-server-cis-baseline
git pull
cd ..
inspec archive canonical-ubuntu-18.04-lts-server-cis-baseline --overwrite
inspec exec <name of generated archive> -t ssh://TARGET_USERNAME:TARGET_PASSWORD@TARGET_IP:TARGET_PORT --sudo --sudo-password=<SUDO_PASSWORD_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

  • MITRE SAF Team

Special Thanks

Contributing and Getting Help

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

Development, Testing and PRs

Describe our testing, and development process here

https://kitchen.ci has great documeation if you need a reference.

Our Pull Request Process

  1. Fork the repo
  2. Create a branch for your update
  3. Update the control or controls
  4. If needed, update the hardening content in the spec diretory
  5. Lint your changes with inspec check . at the root of the profile
  6. Run the Test Kitchen test suite to ensure your changes will pas CI
  7. Submit a PR of your banch aginst the upstream master

Test Kitchen Steps

Create

This creates a base test target you can use for local testing

  • Vanilla & Hardened
KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen create vanilla-ubuntu-1804 

KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen create hardened-ubuntu-1804

Converge

This runs the configuration managment content on the created host

  • Vanilla & Hardened
KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen create vanilla-ubuntu-1804

KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen create hardened-ubuntu-1804

Verify

This runs the inspec validation profile aginst the host

  • Vanilla & Hardened
KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen verify vanilla-ubuntu-1804

KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen verify hardened-ubuntu-1804

Destroy

This will clean up and destroy your testing host

  • Vanilla & Hardened
KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen verify vanilla-ubuntu-1804

KITCHEN_LOCAL_YAML=kitchen.vagrant.yml CHEF_LICENSE=accept kitchen verify hardened-ubuntu-1804

Update to the repo and sub-modules

Update submodules

git submodule update --init --recursive
git submodule update --remote

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, (703) 983-6000.

NOTICE

CIS Benchmarks are published by the Center for Internet Security (CIS), see: https://www.cisecurity.org/.

canonical-ubuntu-18.04-lts-server-cis-baseline's People

Contributors

aaronlippold avatar hackershark avatar karikarshivani avatar pkaeding avatar wdower avatar yarick avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

tohch4 pkaeding

canonical-ubuntu-18.04-lts-server-cis-baseline's Issues

add a docker image build, harden and test into our PR and workflow process

We would like to enhance the profile to be 'container aware' by using the `virtualization resource so that for the tests that need to be NA ( aka impact 0 ) or the testing process changes when ubuntu is run in a container vs a VM or EC2 - our profile should be able to accommodate for that and properly document and report it in the testing results.

Thoughts on using `skip`

When running inspec tests, the results show the number of passed, skipped, and failed tests. At least from my perspective, I view failures as something that should never happen (ie, a build should not be allowed to proceed if a test fails) and skipped tests should be reviewed. For example, accepted risks might use skips (with a comment pointing to some documentation about the accepted risk, mitigations, etc). Or an unimplemented test might use a skip to indicate that this control exists, but we don't know if it is passing or failing.

On the other hand, I notice a lot of controls here use skip with controls that say something like "If X is used, then it must be properly configured", in the case where "X" is not used. (Eg. 2.2.1.3.)

What are your thoughts on changing controls like 2.2.1.3 to pass when the package they are concerned with is not in use, and adding skips to unimplemented controls (eg 3.6)?

C-1.1.23 is failing when it should not be

I have a failing test for control 1.1.23: Disable USB Storage.

  ×  C-1.1.23: Disable USB Storage (1 failed)
     ✔  Kernel Module usb-storage is expected not to be loaded
     ×  Kernel Module usb-storage is expected to be disabled
     expected `Kernel Module usb-storage.disabled?` to be truthy, got false

However, the 'check' commands indicate that this should not fail:

~ $ modprobe -n -v usb-storage
install /bin/true
~ $ lsmod | grep usb-storage

The other disabled module checks are working as expected. Could this have to do with the fact that there is a hyphen in the name of the module? Looking at the disabled? check, it seems that it runs modprobe --showconfig, which returns the following line (among others):

install usb_storage /bin/true

Note the _, instead of the - that the docs for this control mention (and the official CIS Benchmark PDF also uses - when discussing this control). Are the - and _ interchangeable here? Should the inspec kernel_module constructor use the _ form?

Control naming convention

Please use this unique prefix name for controls: "ubuntu-18.04-server-cis-"

For example:
Change: control "C-1.1.1.1" do
To: control "ubuntu-18.04-server-cis-1.1.1.1" do

add 'development, testing and contributing' section that describes and explains the kitchen.ci testing

# Testing with Kitchen

## Dependencies

- Ruby 2.3.0 or later
- [Virtualbox](https://www.virtualbox.org)
- [Vagrant](https://www.vagrantup.com)

#### _Notes to Windows Users_

1. An installation of ChefDK may generate conflicts when combined with the
   installed kitchen gems. **Recommend NOT installing ChefDK before testing
   with this repo.**

2. If you run into errors when running `bundle install`, use the following
   commands to install gems:

- `gem install kitchen-puppet`
- `gem install librarian-puppet`
- `gem install kitchen-vagrant`

3. If the tests are not found when running `kitchen verify`, open
   `.kitchen.yml` and consult `inspec_tests` under the `suites` section.

4) You may also experience an error when running `kitchen converge` where a
   folder is unable to be created due to the length of the path. In this case,
   you may need to edit a registry key as explained
   [here](https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/).

## Setting up your box

1. Clone the repo via `git clone -b dev https://github.com/simp/inspec_profiles.git`
2. cd to `inspec_profiles`
3. Run `bundle install`
4. Run `kitchen list` - you should see the following choice:
   - `default-centos-7`
5. Run `kitchen converge default-centos-7`
6. Run `kitchen list` - your should see your host with status "converged"

## Validating your box

**Note:** Once the open issues are resolved in InSpec and kitchen-inspec these
steps will not really be needed but for now we have to do a few things a bit
more manually. Once resolved fully, you will only need to run `kitchen verify (machine name)` and everything will be taken care of.

### In the 'inspec_profiles' dir ( manually )

1. cd `.kitchen/`
2. vi default-centos-7.yml
3. copy the `ssh_key:` value for later
4. note the mapped port value ( usually `2222`) and use in the next step

### In the 'inspec_profiles' dir

1. On the terminal: `export SSH_KEY=(value from before)`
2. cd to `inspec_profiles`

   - (optional) run an `inspec check`, and
     ensure there are no errors in the baseline.

3. run: `inspec exec -i $SSH_KEY -t ssh://[email protected]:2222 ( or the port mapped from step '4' above )`
   - (optional) `inspec exec controls/V-#####
   - -i \$SSH_KEY -t
     ssh://[email protected]:2222` to just test a single control
   - (optional) `inspec exec -i $SSH_KEY --controls=V-#####,V-##### -t ssh://[email protected]:2222` to just test a
     small set of controls

# Hardening Development

Included in this repository are testing scripts which allow you to run the profile using Vagrant or EC2 VMs. You can choose which environment your VMs are run in by passing the appropriate test-kitchen `yml` file to your `KITCHEN_LOCAL_YAML` environment variable. All of the commands below use the `kitchen.vagrant.yml` file as an example, however a `kitchen.ec2.yaml` is also available in the repository and can be substituted below to run the tests in EC2.

- Making Changes and Testing

  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen converge (machine name)` - runs any changes to your hardening scripts
  - run `kitchen verify (machine name)` - runs the inspec tests

- Starting Clean:
  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen destroy (machine name)` kitchen will drop your box and you can start clean
- Going through the entire process ( create, build, configure, verify, destroy )
  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen test (machine name)` or to test all defined machines `kitchen test`
- Just running the validation scripts
  - run `CHEF_LICENSE=accept KITCHEN_LOCAL_YAML=kitchen.vagrant.yml kitchen verify (machine name)`
- just run one or more controls in the validation
  - edit the .kitchen.yml file in the `controls:` section add the `control id(s)` to the list

add cicd testing to our PR process and repo

https://github.com/florianutz/Ubuntu1804-CIS

seems to be a fairly well-maintained ansible-playbook but I am open to suggestions.

https://github.com/mitre/canonical-ubuntu-18.04-lts-stig-baseline

The STIG ubuntu GitHub Workflows and kitchen ci configuration can be reused but switching out for the CIS Ansible Playbook. The kitchen.yml, vagrant.yml, thresholds, will need minimal adjustment.

To test locally, set KITCHEN_LOCAL_YAML to your vagrant.yml file.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.