Rol de Ansible: Seguridad (Básicos)

Primero, una advertencia mayor, MUY importante: la seguridad de tus servidores es TU responsabilidad. Si piensas que simplemente incluir este rol y agregar un firewall hace que un servidor sea seguro, estás equivocado. Infórmate sobre seguridad en Linux, redes y aplicaciones, y recuerda que no importa cuánto sepas, siempre puedes hacer que cada parte de tu infraestructura sea más segura.

Dicho esto, este rol realiza algunas configuraciones básicas de seguridad en sistemas Linux basados en RedHat y Debian. Intenta:

• Instalar software para monitorear accesos no deseados por SSH (fail2ban)
• Configurar SSH para mayor seguridad (deshabilitar el inicio de sesión como root, requerir autenticación basada en claves y permitir establecer un puerto SSH personalizado)
• Configurar actualizaciones automáticas (si se configura para ello)

Hay algunas otras cosas que puede que quieras hacer (que no están incluidas en este rol) para asegurarte de que tus servidores sean más seguros, como:

• Usar logwatch o un servidor de registro centralizado para analizar y monitorear archivos de registro
• Configurar de forma segura cuentas de usuario y claves SSH (este rol asume que no usas autenticación por contraseña o inicias sesión como root)
• Tener un firewall bien configurado (mira el rol geerlingguy.firewall en Ansible Galaxy para un ejemplo flexible)

Nuevamente: La seguridad de tus servidores es tu responsabilidad.

Requisitos

Por razones obvias, sudo debe estar instalado si deseas gestionar el archivo sudoers con este rol.

En sistemas RedHat/CentOS, asegúrate de tener instalado el repositorio EPEL (puedes incluir el rol geerlingguy.repo-epel para instalarlo).

No hay requisitos especiales para sistemas Debian/Ubuntu.

Variables del Rol

Las variables disponibles se enumeran a continuación, junto con sus valores predeterminados (ver defaults/main.yml):

security_ssh_port: 22

El puerto a través del cual te gustaría que SSH sea accesible. El valor predeterminado es el puerto 22, pero si estás operando un servidor en Internet abierto y no tienes un firewall bloqueando el acceso al puerto 22, te darás cuenta rápidamente de que miles de intentos de inicio de sesión por día no son inusuales. Puedes cambiar el puerto a uno no estándar (por ejemplo, 2849) si quieres evitar estos miles de intentos automatizados.

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"

Configuraciones de seguridad para la autenticación SSH. Es mejor dejar estas configuraciones en "no", pero hay momentos (especialmente durante la configuración inicial del servidor o cuando no tienes autenticación basada en claves) en que una o todas pueden configurarse de manera segura a 'yes'. NOTA: Es muy importante que cites los valores 'yes' o 'no'. No hacerlo puede bloquearte el acceso a tu servidor.

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

Una lista de usuarios permitidos para conectarse al host a través de SSH. Si no se define ningún usuario en la lista, la tarea se omitirá.

security_ssh_allowed_groups: []
# - admins
# - devs

Una lista de grupos permitidos para conectarse al host a través de SSH. Si no se define ningún grupo en la lista, la tarea se omitirá.

security_sshd_state: started

El estado del daemon SSH. Típicamente, esto debería permanecer started.

security_ssh_restart_handler_state: restarted

El estado del manejador de restart ssh. Típicamente, esto debería permanecer restarted.

security_sudoers_passwordless: []
security_sudoers_passworded: []

Una lista de usuarios que deben ser añadidos al archivo sudoers para que puedan ejecutar cualquier comando como root (a través de sudo) sin una contraseña o requiriendo una contraseña para cada comando, respectivamente.

security_autoupdate_enabled: true

Si se debe instalar/habilitar yum-cron (sistemas basados en RedHat) o unattended-upgrades (sistemas basados en Debian). Los reinicios del sistema no sucederán automáticamente en ningún caso, y las actualizaciones automáticas no son una excusa para una gestión descuidada de parches y paquetes, pero las actualizaciones automáticas pueden ser útiles como otra medida de seguridad.

security_autoupdate_blacklist: []

(Solo Debian/Ubuntu) Una lista de paquetes que no deben ser actualizados automáticamente.

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

(Solo Debian/Ubuntu) Una lista de orígenes a referenciar.

security_autoupdate_reboot: false

(Solo Debian/Ubuntu) Si se debe reiniciar cuando sea necesario durante las actualizaciones no atendidas.

security_autoupdate_reboot_time: "03:00"

(Solo Debian/Ubuntu) La hora para activar un reinicio, si es necesario, si security_autoupdate_reboot está configurado como true. En formato de reloj de 24 horas "hh:mm".

security_autoupdate_mail_to: ""
security_autoupdate_mail_on_error: true

(Solo Debian/Ubuntu) Si security_autoupdate_mail_to está configurado a un valor no vacío, las actualizaciones no atendidas enviarán un correo electrónico a esa dirección cuando ocurra algún error. Puedes establecer esto a un correo completo: [email protected] o a algo como root, que utilizará /etc/aliases para redirigir el mensaje. Si estableces security_autoupdate_mail_on_error a false, recibirás un correo después de cada instalación de paquete.

security_fail2ban_enabled: true

Si se debe instalar/habilitar fail2ban. Puede que no quieras usar fail2ban si ya estás utilizando algún otro servicio para la detección de inicio de sesión e intrusiones (por ejemplo, ConfigServer).

security_fail2ban_custom_configuration_template: "jail.local.j2"

El nombre del archivo de plantilla utilizado para generar la configuración de fail2ban.

Dependencias

Ninguna.

Ejemplo de Playbook

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

Dentro de vars/main.yml:

security_sudoers_passworded:
  - johndoe
  - deployacct

Licencia

MIT (Expat) / BSD

Información del Autor

Este rol fue creado en 2014 por Jeff Geerling, autor de Ansible for DevOps.