Mirrors/ansible-collection-hardening
2
0
Fork 0
mirror of https://github.com/dev-sec/ansible-collection-hardening synced 2024-11-10 09:14:18 +00:00
Code Issues Projects Releases Packages Wiki Activity

Edit README to fit to os-hardening

Browse source
This commit is contained in:
Sebastian Gumprich 2015-05-28 20:52:10 +00:00
parent b9cc7bf9d8
commit e121eaea7d
1 changed files with 73 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

127
README.md
View file

@ -1,47 +1,79 @@
# ssh-hardening (Ansible Role)
# os-hardening (Ansible Role)
[![Build Status](http://img.shields.io/travis/hardening-io/ansible-ssh-hardening.svg)][1]
[![Gitter Chat](https://badges.gitter.im/Join%20Chat.svg)][2]
[![Build Status](http://img.shields.io/travis/hardening-io/ansible-os-hardening.svg)][2]
[![Code Coverage](http://img.shields.io/coveralls/hardening-io/ansible-os-hardening.svg)][3]
[![Gitter Chat](https://badges.gitter.im/Join%20Chat.svg)][5]
## Description
This role provides secure ssh-client and ssh-server configurations.
This roles provides numerous security-related configurations, providing all-round base protection.
It configures:
* Configures package management e.g. allows only signed packages
* Remove packages with known issues
* Configures `pam` and `pam_limits` module
* Shadow password suite configuration
* Configures system path permissions
* Disable core dumps via soft limits
* Restrict Root Logins to System Console
* Set SUIDs
* Configures kernel parameters via sysctl
It will not:
* Update system packages
* Install security patches
## Requirements
* Ansible
## Role Variables
* ``network_ipv6_enable`` - true if IPv6 is needed
* ``ssh_client_cbc_required`` - true if CBC for ciphers is required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure ciphers enabled. CBC is a weak alternative. Anything weaker should be avoided and is thus not available.
* ``ssh_server_cbc_required`` - true if CBC for ciphers is required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure ciphers enabled. CBC is a weak alternative. Anything weaker should be avoided and is thus not available.
* ``ssh_client_weak_hmac`` - true if weaker HMAC mechanisms are required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure HMACs enabled.
* ``ssh_server_weak_hmac`` - true if weaker HMAC mechanisms are required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure HMACs enabled.
* ``ssh_client_weak_kex`` - true if weaker Key-Exchange (KEX) mechanisms are required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure KEXs enabled.
* ``ssh_server_weak_kex`` - true if weaker Key-Exchange (KEX) mechanisms are required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure KEXs enabled.
* ``ssh_ports: ['22']`` - ports to which ssh-server should listen to and ssh-client should connect to
* ``ssh_listen_to: ['0.0.0.0']`` - one or more ip addresses, to which ssh-server should listen to. Default is empty, but should be configured for security reasons!
* ``ssh_host_key_files: ['/etc/ssh/ssh_host_rsa_key', '/etc/ssh/ssh_host_dsa_key', '/etc/ssh/ssh_host_ecdsa_key']`` - Host keys to look for when starting sshd.
* ``ssh_client_alive_interval: 600``
* ``ssh_client_alive_count: 3``
* ``ssh_remote_hosts: []`` - one or more hosts, to which ssh-client can connect to. Default is empty, but should be configured for security reasons!
* ``ssh_allow_root_with_key`` - false to disable root login altogether. Set to true to allow root to login via key-based mechanism.
* ``ssh_allow_tcp_forwarding`` false to disable TCP Forwarding. Set to true to allow TCP Forwarding.
* ``ssh_allow_agent_forwarding`` false to disable Agent Forwarding. Set to true to allow Agent Forwarding.
* ``ssh_use_pam: false`` - false to disable pam authentication.
* ``ssh_deny_users: ''`` - if specified, login is disallowed for user names that match one of the patterns.
* ``ssh_allow_users: ''`` - if specified, login is allowed only for user names that match one of the patterns.
* ``ssh_deny_groups: ''`` - if specified, login is disallowed for users whose primary group or supplementary group list matches one of the patterns.
* ``ssh_allow_groups: ''`` - if specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns.
* ``ssh_print_motd`` - false to disable printing of the MOTD
* ``ssh_print_last_log`` - false to disable display of last login information
## Variables
* `os_desktop_enable: false` - true if this is a desktop system, ie Xorg, KDE/GNOME/Unity/etc
* `os_network_forwarding: false` - true if this system requires packet forwarding (eg Router), false otherwise
* `os_network_ipv6_enable: false`
* `os_network_arp_restricted: true` - true if you want the behavior of announcing and replying to ARP to be restricted, false otherwise
* `os_env_extra_user_paths: []` - add additional paths to the user's `PATH` variable (default is empty).
* `os_env_umask: "027"`
* `os_env_root_path: "/"` - where root is mounted
* `os_auth_pw_max_age: 60` - maximum password age
* `os_auth_pw_min_age: 7` - minimum password age (before allowing any other password change)
* `os_auth_retries: 5` - the maximum number of authentication attempts, before the account is locked for some time
* `os_auth_lockout_time: 600` - time in seconds that needs to pass, if the account was locked due to too many failed authentication attempts
* `os_auth_timeout: 60` - authentication timeout in seconds, so login will exit if this time passes
* `os_auth_allow_homeless: false` - true if to allow users without home to login
* `os_auth_pam_passwdqc_enable: true` - true if you want to use strong password checking in PAM using passwdqc
* `os_auth_pam_passwdqc_options: "min=disabled,disabled,16,12,8"` - set to any option line (as a string) that you want to pass to passwdqc
* `os_security_users_allow: []` - list of things, that a user is allowed to do. May contain: `change_user`
* `os_security_kernel_enable_module_loading: true` - true if you want to allowed to change kernel modules once the system is running (eg `modprobe`, `rmmod`)
* `os_security_kernel_enable_sysrq: false`
* `os_security_kernel_enable_core_dump: false`
* `os_security_suid_sgid_enforce: true` - true if you want to reduce SUID/SGID bits. There is already a list of items which are searched for configured, but you can also add your own
* `os_security_suid_sgid_blacklist: []` - a list of paths which should have their SUID/SGID bits removed
* `os_security_suid_sgid_whitelist: []` - a list of paths which should not have their SUID/SGID bits altered
* `os_security_suid_sgid_remove_from_unknown: false` - true if you want to remove SUID/SGID bits from any file, that is not explicitly configured in a `blacklist`. This will make every Chef run search through the mounted filesystems looking for SUID/SGID bits that are not configured in the default and user blacklist. If it finds an SUID/SGID bit, it will be removed, unless this file is in your `whitelist`.
* `os_security_suid_sgid_dry_run_on_unknown: false` - like `remove_from_unknown` above, only that SUID/SGID bits aren't removed.
It will still search the filesystems to look for SUID/SGID bits but it will only print them in your log. This option is only ever recommended, when you first configure `remove_from_unknown` for SUID/SGID bits, so that you can see the files that are being changed and make adjustments to your `whitelist` and `blacklist`.
* `os_security_packages_clean'] = true` - removes packages with known issues. See section packages.
## Packages
We remove the following packages:
* xinetd ([NSA](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), Chapter 3.2.1)
* inetd ([NSA](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), Chapter 3.2.1)
* tftp-server ([NSA](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), Chapter 3.2.5)
* ypserv ([NSA](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), Chapter 3.2.4)
* telnet-server ([NSA](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), Chapter 3.2.2)
* rsh-server ([NSA](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf), Chapter 3.2.3)
## Example Playbook
- hosts: localhost
roles:
- ansible-ssh-hardening
- ansible-os-hardening
## Local Testing
@ -73,33 +105,19 @@ bundle exec kitchen converge default-ubuntu-1204
For more information see [test-kitchen](http://kitchen.ci/docs/getting-started)
## FAQ / Pitfalls
**I can't log into my account. I have registered the client key, but it still doesn't let me it.**
## Contributors + Kudos
If you have exhausted all typical issues (firewall, network, key missing, wrong key, account disabled etc.), it may be that your account is locked. The quickest way to find out is to look at the password hash for your user:
...
sudo grep myuser /etc/shadow
This role is mostly based on guides by:
If the hash includes an `!`, your account is locked:
myuser:!:16280:7:60:7:::
The proper way to solve this is to unlock the account (`passwd -u myuser`). If the user doesn't have a password, you should can unlock it via:
usermod -p "*" myuser
Alternatively, if you intend to use PAM, you enabled it via `ssh_use_pam: true`. PAM will allow locked users to get in with keys.
**Why doesn't my application connect via SSH anymore?**
Always look into log files first and if possible look at the negotation between client and server that is completed when connecting.
We have seen some issues in applications (based on python and ruby) that are due to their use of an outdated crypto set. This collides with this hardening module, which reduced the list of ciphers, message authentication codes (MACs) and key exchange (KEX) algorithms to a more secure selection.
If you find this isn't enough, feel free to activate the attributes `cbc_requires` for ciphers, `weak_hmac` for MACs and `weak_kex`for KEX in the variables `ssh_client` or `ssh_server` based on where you want to support them.
* [Arch Linux wiki, Sysctl hardening](https://wiki.archlinux.org/index.php/Sysctl)
* [NSA: Guide to the Secure Configuration of Red Hat Enterprise Linux 5](http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf)
* [Ubuntu Security/Features](https://wiki.ubuntu.com/Security/Features)
* [Deutsche Telekom, Group IT Security, Security Requirements (German)](http://www.telekom.com/static/-/155996/7/technische-sicherheitsanforderungen-si)
Thanks to all of you!!
## Contributing
See [contributor guideline](CONTRIBUTING.md).
@ -107,7 +125,6 @@ See [contributor guideline](CONTRIBUTING.md).
## License and Author
* Author:: Sebastian Gumprich <sebastian.gumprich@38.de>
* Author:: Christoph Hartmann <chris@lollyrock.com>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
@ -121,5 +138,7 @@ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
[1]: http://travis-ci.org/hardening-io/ansible-ssh-hardening
[2]: https://gitter.im/hardening-io/general
[2]: http://travis-ci.org/hardening-io/ansible-os-hardening
[3]: https://coveralls.io/r/hardening-io/ansible-os-hardening
[5]: https://gitter.im/hardening-io