mirror of
https://github.com/ovh/debian-cis.git
synced 2024-11-22 05:27:01 +01:00
Add manual
This commit is contained in:
parent
4281ed330a
commit
8029da6157
160
MANUAL.md
Normal file
160
MANUAL.md
Normal file
@ -0,0 +1,160 @@
|
||||
% CIS-HARDENING(8)
|
||||
%
|
||||
% 2016
|
||||
|
||||
# NAME
|
||||
|
||||
cis-hardening - CIS Debian 9/10 Hardening
|
||||
|
||||
# SYNOPSIS
|
||||
|
||||
**hardening.sh** RUN_MODE [OPTIONS]
|
||||
|
||||
# DESCRIPTION
|
||||
|
||||
Modular Debian 9/10 security hardening scripts based on the CIS (https://www.cisecurity.org) recommendations.
|
||||
|
||||
We use it at OVHcloud (https://www.ovhcloud.com) to harden our PCI-DSS infrastructure.
|
||||
|
||||
# SCRIPTS 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 MODE
|
||||
|
||||
`-h`, `--help`
|
||||
: Display a friendly help message.
|
||||
|
||||
`--apply`
|
||||
: Apply hardening for enabled scripts.
|
||||
Beware that NO confirmation is asked whatsoever, which is why you're warmly
|
||||
advised to use `--audit` before, which can be regarded as a dry-run mode.
|
||||
|
||||
`--audit`
|
||||
: Audit configuration for enabled scripts.
|
||||
No modification will be made on the system, we'll only report on your system
|
||||
compliance for each script.
|
||||
|
||||
`--audit-all`
|
||||
: Same as `--audit`, but for *all* scripts, even disabled ones.
|
||||
This is a good way to peek at your compliance level if all scripts were enabled,
|
||||
and might be a good starting point.
|
||||
|
||||
`--audit-all-enable-passed`
|
||||
: Same as `--audit-all`, but in addition, will *modify* the individual scripts
|
||||
configurations to enable those which passed for your system.
|
||||
This is an easy way to enable scripts for which you're already compliant.
|
||||
However, please always review each activated script afterwards, this option
|
||||
should only be regarded as a way to kickstart a configuration from scratch.
|
||||
Don't run this if you have already customized the scripts enable/disable
|
||||
configurations, obviously.
|
||||
|
||||
`--create-config-files-only`
|
||||
: Create the config files in etc/conf.d
|
||||
Must be run as root, before running the audit with user secaudit
|
||||
|
||||
`-set-hardening-level=level`
|
||||
: Modifies the configuration to enable/disable tests given an hardening level,
|
||||
between 1 to 5. Don't run this if you have already customized the scripts
|
||||
enable/disable configurations.
|
||||
1: very basic policy, failure to pass tests at this level indicates severe
|
||||
misconfiguration of the machine that can have a huge security impact
|
||||
2: basic policy, some good practice rules that, once applied, shouldn't
|
||||
break anything on most systems
|
||||
3: best practices policy, passing all tests might need some configuration
|
||||
modifications (such as specific partitioning, etc.)
|
||||
4: high security policy, passing all tests might be time-consuming and
|
||||
require high adaptation of your workflow
|
||||
5: placebo, policy rules that might be very difficult to apply and maintain,
|
||||
with questionable security benefits
|
||||
|
||||
`--allow-service=service`
|
||||
: Use with `--set-hardening-level`.
|
||||
Modifies the policy to allow a certain kind of services on the machine, such
|
||||
as http, mail, etc. Can be specified multiple times to allow multiple services.
|
||||
Use --allow-service-list to get a list of supported services.
|
||||
|
||||
# OPTIONS
|
||||
|
||||
`--allow-service-list`
|
||||
: Get a list of supported service.
|
||||
|
||||
|
||||
`--only test-number`
|
||||
: Modifies the RUN_MODE to only work on the test_number script.
|
||||
Can be specified multiple times to work only on several scripts.
|
||||
The test number is the numbered prefix of the script,
|
||||
i.e. the test number of 1.2_script_name.sh is 1.2.
|
||||
|
||||
`--sudo`
|
||||
: This option lets you audit your system as a normal user, but allows sudo
|
||||
escalation to gain read-only access to root files. Note that you need to
|
||||
provide a sudoers file with NOPASSWD option in /etc/sudoers.d/ because
|
||||
the -n option instructs sudo not to prompt for a password.
|
||||
Finally note that `--sudo` mode only works for audit mode.
|
||||
|
||||
`--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{...}]
|
||||
|
||||
|
||||
# AUTHORS
|
||||
|
||||
- Thibault Dewailly, OVHcloud <thibault.dewailly@ovhcloud.com>
|
||||
- Stéphane Lesimple, OVHcloud <stephane.lesimple@ovhcloud.com>
|
||||
- Thibault Ayanides, OVHcloud <thibault.ayanides@ovhcloud.com>
|
||||
- Kevin Tanguy, OVHcloud <kevin.tanguy@ovhcloud.com>
|
||||
|
||||
# COPYRIGHT
|
||||
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2016, OVHcloud
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
|
||||
# SEE ALSO
|
||||
|
||||
- **Center for Internet Security**: https://www.cisecurity.org/
|
||||
- **CIS recommendations**: https://learn.cisecurity.org/benchmarks
|
||||
- **Project repository**: https://github.com/ovh/debian-cis
|
||||
|
Loading…
Reference in New Issue
Block a user