Ansible Role: Security (Basics)

Important Note: The security of your servers is YOUR responsibility. Don't think that just adding this role and a firewall will keep your server safe. Learn about security for Linux, networks, and applications. No matter how much you know, there's always more you can do to secure your system.

This role configures basic security settings on RedHat and Debian-based Linux systems. It includes:

• Installing software to monitor bad SSH access (fail2ban)
• Making SSH more secure (disallowing root login, requiring key-based authentication, and allowing you to set a custom SSH port)
• Setting up automatic updates (if configured)

There are additional security measures you may want to consider (not included in this role):

• Using logwatch or a centralized logging server to monitor logs
• Securely configuring user accounts and SSH keys (this role assumes you’re not using password authentication or logging in as root)
• Using a well-configured firewall (check the geerlingguy.firewall role on Ansible Galaxy for an example)

Again: Your servers' security is your responsibility.

Requirements

To use this role, sudo must be installed if you want to manage the sudoers file.

For RedHat/CentOS systems, ensure you have the EPEL repository installed (you can use the geerlingguy.repo-epel role to install it).

No special requirements for Debian/Ubuntu systems.

Role Variables

Here are the available variables, along with their default values (see defaults/main.yml):

security_ssh_port: 22

This is the port for SSH access. The default is 22, but if your server is on the open internet without a firewall, you may get thousands of login attempts daily. Changing to a non-standard port (like 2849) can help avoid this issue.

security_ssh_password_authentication: "no"
security_ssh_permit_root_login: "no"
security_ssh_usedns: "no"
security_ssh_permit_empty_password: "no"
security_ssh_challenge_response_auth: "no"
security_ssh_gss_api_authentication: "no"
security_ssh_x11_forwarding: "no"

These are security settings for SSH. It's best to keep them set to "no", but you can set one or all to 'yes' briefly if needed. IMPORTANT: Make sure to use quotes around 'yes' or 'no', as forgetting could lock you out of your server.

security_ssh_allowed_users: []
# - alice
# - bob
# - charlie

A list of users who are allowed to SSH into the server. If the list is empty, this task will be skipped.

security_ssh_allowed_groups: []
# - admins
# - devs

A list of groups allowed to SSH into the server. If empty, this task will be skipped.

security_sshd_state: started

The status of the SSH daemon. This should usually be set to started.

security_ssh_restart_handler_state: restarted

The state of the restart ssh handler. This should generally remain restarted.

security_sudoers_passwordless: []
security_sudoers_passworded: []

Lists of users who should be added to the sudoers file, allowing them to run commands as root (via sudo), with or without requiring a password.

security_autoupdate_enabled: true

Controls whether to install/enable yum-cron (for RedHat systems) or unattended-upgrades (for Debian systems). System restarts won't happen automatically, and automatic upgrades should not replace proper management, but they can add an extra layer of security.

security_autoupdate_blacklist: []

(Debian/Ubuntu only) A list of packages that should not be automatically updated.

security_autoupdate_additional_origins: []
# - "${distro_id}ESM:${distro_codename}-infra-security"
# - "Docker:${distro_codename}"

(Debian/Ubuntu only) A list of additional origins to include.

security_autoupdate_reboot: false

(Debian/Ubuntu only) Whether to reboot when needed during unattended upgrades.

security_autoupdate_reboot_time: "03:00"

(Debian/Ubuntu only) The time to reboot if security_autoupdate_reboot is true. Format is HH:mm in 24-hour time.

security_autoupdate_mail_to: ""
security_autoupdate_mail_on_error: true

(Debian/Ubuntu only) If security_autoupdate_mail_to is set, it will send an email if there's an error during unattended upgrades. You can set this to a full email address or a name that is routed via /etc/aliases. Setting security_autoupdate_mail_on_error to false will give you an email after every package install.

security_fail2ban_enabled: true

Whether to install/enable fail2ban. Avoid using it if you already have another service handling login protection (like ConfigServer).

security_fail2ban_custom_configuration_template: "jail.local.j2"

The name of the template file for fail2ban configuration.

Dependencies

None.

Example Playbook

- hosts: servers
  vars_files:
    - vars/main.yml
  roles:
    - geerlingguy.security

Inside vars/main.yml:

security_sudoers_passworded:
  - johndoe
  - deployacct

License

MIT (Expat) / BSD

Author Information

This role was created in 2014 by Jeff Geerling, author of Ansible for DevOps.