debian-cis/README.md

184 lines
7.1 KiB
Markdown
Raw Permalink Normal View History

# CIS Debian 7/8/9 Hardening
2016-04-20 18:56:28 +02:00
Modular Debian 7/8/9 security hardening scripts based on [cisecurity.org](https://www.cisecurity.org)
2016-04-22 14:29:33 +02:00
recommendations. We use it at [OVH](https://www.ovh.com) to harden our PCI-DSS infrastructure.
2016-04-20 18:56:28 +02:00
```console
2016-04-21 12:00:20 +02:00
$ bin/hardening.sh --audit-all
[...]
hardening [INFO] Treating /opt/cis-hardening/bin/hardening/13.15_check_duplicate_gid.sh
13.15_check_duplicate_gid [INFO] Working on 13.15_check_duplicate_gid
13.15_check_duplicate_gid [INFO] Checking Configuration
13.15_check_duplicate_gid [INFO] Performing audit
13.15_check_duplicate_gid [ OK ] No duplicate GIDs
13.15_check_duplicate_gid [ OK ] Check Passed
[...]
################### SUMMARY ###################
Total Available Checks : 191
Total Runned Checks : 191
Total Passed Checks : [ 170/191 ]
Total Failed Checks : [ 21/191 ]
Enabled Checks Percentage : 100.00 %
Conformity Percentage : 89.01 %
2016-04-20 18:56:28 +02:00
```
## Quickstart
```console
2016-04-21 12:00:20 +02:00
$ git clone https://github.com/ovh/debian-cis.git && cd debian-cis
2016-04-21 15:18:36 +02:00
$ cp debian/default /etc/default/cis-hardening
$ sed -i "s#CIS_ROOT_DIR=.*#CIS_ROOT_DIR='$(pwd)'#" /etc/default/cis-hardening
2016-04-21 12:00:20 +02:00
$ bin/hardening/1.1_install_updates.sh --audit-all
1.1_install_updates [INFO] Working on 1.1_install_updates
1.1_install_updates [INFO] Checking Configuration
1.1_install_updates [INFO] Performing audit
1.1_install_updates [INFO] Checking if apt needs an update
1.1_install_updates [INFO] Fetching upgrades ...
1.1_install_updates [ OK ] No upgrades available
1.1_install_updates [ OK ] Check Passed
2016-04-20 18:56:28 +02:00
```
## Usage
### Configuration
Hardening scripts are in ``bin/hardening``. Each script has a corresponding
configuration file in ``etc/conf.d/[script_name].cfg``.
Each hardening script can be individually enabled from its configuration file.
For example, this is the default configuration file for ``disable_system_accounts``:
```
# Configuration for script of same name
status=disabled
# Put here your exceptions concerning admin accounts shells separated by spaces
EXCEPTIONS=""
```
``status`` parameter may take 3 values:
- ``disabled`` (do nothing): The script will not run.
- ``audit`` (RO): The script will check if any change *should* be applied.
- ``enabled`` (RW): The script will check if any change should be done and automatically apply what it can.
Global configuration is in ``etc/hardening.cfg``. This file controls the log level
as well as the backup directory. Whenever a script is instructed to edit a file, it
will create a timestamped backup in this directory.
### Run aka "Harden your distro"
To run the checks and apply the fixes, run ``bin/hardening.sh``.
This command has 2 main operation modes:
- ``--audit``: Audit your system with all enabled and audit mode scripts
- ``--apply``: Audit your system with all enabled and audit mode scripts and apply changes for enabled scripts
Additionally, ``--audit-all`` can be used to force running all auditing scripts,
including disabled ones. this will *not* change the system.
``--audit-all-enable-passed`` can be used as a quick way to kickstart your
configuration. It will run all scripts in audit mode. If a script passes,
it will automatically be enabled for future runs. Do NOT use this option
if you have already started to customize your configuration.
``--sudo``: Audit your system as a normal user, but allow sudo escalation to read
specific root read-only files. You need to provide a sudoers file in /etc/sudoers.d/
with NOPASWD option, since checks are executed with ``sudo -n`` option, that will
not prompt for a password.
``--batch``: While performing system audit, this option sets LOGLEVEL to 'ok' and
captures all output to print only one line once the check is done, formatted like :
OK|KO OK|KO|WARN{subcheck results} [OK|KO|WARN{...}]
2016-04-20 18:56:28 +02:00
## Hacking
**Getting the source**
```console
2016-04-21 12:00:20 +02:00
$ git clone https://github.com/ovh/debian-cis.git
2016-04-20 18:56:28 +02:00
```
**Building a debian Package** (the hacky way)
```console
2016-04-21 12:00:20 +02:00
$ debuild -us -uc
2016-04-20 18:56:28 +02:00
```
**Adding a custom hardening script**
2016-04-21 12:00:20 +02:00
```console
$ cp src/skel bin/hardening/99.99_custom_script.sh
$ chmod +x bin/hardening/99.99_custom_script.sh
$ cp src/skel.cfg etc/conf.d/99.99_custom_script.cfg
```
Code your check explaining what it does then if you want to test
```console
$ sed -i "s/status=.+/status=enabled/" etc/conf.d/99.99_custom_script.cfg
$ ./bin/hardening/99.99_custom_script.sh
```
IMP(test): Add feature to run functional tests in docker instance Add usecase in basename Add test files for checks with find command Always show logs FIX: run void script to generate config and avoid sed failure Update README with functional test description Add skeleton for functional test Add argument to launch only specific test suite Add support for debian8 and compulsory mention of debian version at launch Improve README Simplify test file syntax to avoid copy/paste mistake Add script that runs tests on all debian targets Improve run_all_target script with nowait and nodel options Add dockerfile for Buster pre-version Chore: Use getopt for options and reviewed code by shellcheck Add trap to ensure cleanup on exit/interrupt Remove quotes that lead to `less` misinterpretation of the filenames Set `local` for variables inside `test_audit` func Move functional assertion functions to dedicated file Add cleanup for logs and containers Improve cleanup, and now exits Apply shellcheck recommendations FIX: allow script to be run from anywhere (dirname $0) Changes to be committed: modified: README.md new file: src/skel.test new file: tests/docker/Dockerfile.debian10_20181226 new file: tests/docker/Dockerfile.debian8 new file: tests/docker/Dockerfile.debian9 new file: tests/docker_build_and_run_tests.sh new file: tests/hardening/12.10_find_suid_files.sh new file: tests/hardening/12.11_find_sgid_files.sh new file: tests/hardening/12.7_find_world_writable_file.sh new file: tests/hardening/12.8_find_unowned_files.sh new file: tests/hardening/12.9_find_ungrouped_files.sh new file: tests/hardening/2.17_sticky_bit_world_writable_folder.sh new file: tests/launch_tests.sh new file: tests/lib.sh new file: tests/run_all_targets.sh
2018-12-24 14:12:59 +01:00
## Functional testing
Functional tests are available. They are to be run in a Docker environment.
```console
$ ./tests/docker_build_and_run_tests.sh <target> [name of test script...]
```
With `target` being like `debian8` or `debian9`.
Running without script arguments will run all tests in `./tests/hardening/` directory.
Or you can specify one or several test script to be run.
This will build a new Docker image from the current state of the projet and run
a container that will assess a blank Debian system compliance for each check.
For hardening audit points the audit is expected to fail, then be fixed so that
running the audit a second time will succeed.
For vulnerable items, the audit is expected to succeed on a blank
system, then the functional tests will introduce a weak point, that is expected
to be detected when running the audit test a second time. Finally running the `apply`
part of debian-cis script will restore a compliance state that is expected to be
assed by running the audit check a third time.
Functional tests can make use of the following helper functions :
* `describe <test description>`
* `run <usecase> <audit_script> <audit_script_options>`
* `register_test <test content (see below)>`
* `retvalshoudbe <integer>` check the script return value
* `contain "<SAMPLE TEXT>"` check that the output contains the following text
In order to write your own functional test, you will find a code skeleton in
`./src/skel.test`.
2016-04-20 18:56:28 +02:00
## Disclaimer
This project is a set of tools. They are meant to help the system administrator
built a secure environment. While we use it at OVH to harden our PCI-DSS compliant
infrastructure, we can not guarantee that it will work for you. It will not
magically secure any random host.
Additionally, quoting the License:
> THIS SOFTWARE IS PROVIDED BY OVH SAS AND CONTRIBUTORS ``AS IS'' AND ANY
> EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED. IN NO EVENT SHALL OVH SAS AND CONTRIBUTORS BE LIABLE FOR ANY
> DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
## Reference
2016-04-21 12:00:20 +02:00
- **Center for Internet Security**: https://www.cisecurity.org/
2016-04-20 18:56:28 +02:00
- **CIS recommendations**: https://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=debian7.100
- **CIS recommendations**: https://benchmarks.cisecurity.org/downloads/show-single/index.cfm?file=debian8.100
2016-04-20 18:56:28 +02:00
## License
3-Clause BSD