Ansible Rolle: Sicherheit (Grundlagen)

Zuerst eine wichtige Warnung: Die Sicherheit Ihrer Server liegt in Ihrer Verantwortung. Wenn Sie denken, dass es ausreicht, diese Rolle zu verwenden und eine Firewall hinzuzufügen, um einen Server sicher zu machen, liegen Sie falsch. Informieren Sie sich über Linux, Netzwerk- und Anwendungs-Sicherheit und wissen Sie, dass Sie, egal wie viel Sie wissen, jede Komponente Ihrer Infrastruktur sicherer machen können.

Diese Rolle führt einige grundlegende Sicherheitskonfigurationen auf RedHat- und Debian-basierten Linux-Systemen durch. Sie versucht:

• Software zu installieren, um schlechten SSH-Zugriff zu überwachen (fail2ban)
• SSH sicherer zu konfigurieren (Root-Login deaktivieren, schlüssellosen Zugang verlangen und einen benutzerdefinierten SSH-Port festlegen)
• Automatische Updates einzurichten (wenn so konfiguriert)

Es gibt einige weitere Dinge, die Sie möglicherweise tun möchten, um sicherzustellen, dass Ihre Server sicherer sind, wie:

• Verwenden Sie logwatch oder einen zentralen Logging-Server, um Protokolldateien zu analysieren und zu überwachen.
• Benutzerkonten und SSH-Schlüssel sicher konfigurieren (diese Rolle geht davon aus, dass Sie keine Passwortauthentifizierung verwenden oder sich nicht als Root anmelden).
• Eine gut konfigurierte Firewall haben (sehen Sie sich die Rolle geerlingguy.firewall auf Ansible Galaxy für ein flexibles Beispiel an).

Nochmals: Die Sicherheit Ihrer Server ist Ihre Verantwortung.

Anforderungen

Aus offensichtlichen Gründen muss sudo installiert sein, wenn Sie die sudoers-Datei mit dieser Rolle verwalten möchten.

Auf RedHat/CentOS-Systemen stellen Sie sicher, dass das EPEL-Repository installiert ist (Sie können die Rolle geerlingguy.repo-epel hinzufügen, um es zu installieren).

Keine speziellen Anforderungen für Debian/Ubuntu-Systeme.

Rollenspezifische Variablen

Verfügbare Variablen sind unten aufgelistet, zusammen mit den Standardwerten (siehe defaults/main.yml):

security_ssh_port: 22

Der Port, über den SSH zugänglich sein soll. Der Standardport ist 22, aber wenn Sie einen Server im offenen Internet betreiben und keine Firewall den Zugriff auf Port 22 blockiert, werden Sie schnell feststellen, dass Tausende von Anmeldeversuchen pro Tag nicht ungewöhnlich sind. Sie können den Port auf einen nicht standardmäßigen Port (z. B. 2849) ändern, um diese Tausende von automatisierten Eindringversuchen zu vermeiden.

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"

Sicherheitseinstellungen für die SSH-Authentifizierung. Es ist am besten, diese auf "no" zu belassen, aber es gibt Zeiten (insbesondere während der anfänglichen Serverkonfiguration oder wenn Sie keine schlüssellose Authentifizierung haben), in denen eine oder alle sicher auf 'yes' gesetzt werden können. HINWEIS: Es ist sehr wichtig, dass Sie die Werte 'ja' oder 'nein' in Anführungszeichen setzen. Andernfalls könnten Sie von Ihrem Server ausgeschlossen werden.

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

Eine Liste von Benutzern, die sich über SSH mit dem Host verbinden dürfen. Wenn kein Benutzer in der Liste definiert ist, wird die Aufgabe übersprungen.

security_ssh_allowed_groups: []
# - admins
# - devs

Eine Liste von Gruppen, die sich über SSH mit dem Host verbinden dürfen. Wenn keine Gruppe in der Liste definiert ist, wird die Aufgabe übersprungen.

security_sshd_state: started

Der Zustand des SSH-Daemons. Typischerweise sollte dieser started bleiben.

security_ssh_restart_handler_state: restarted

Der Zustand des restart ssh Handlers. Typischerweise sollte dieser restarted bleiben.

security_sudoers_passwordless: []
security_sudoers_passworded: []

Eine Liste von Benutzern, die in die sudoers-Datei aufgenommen werden sollen, damit sie Befehle als Root (über sudo) entweder ohne Passwort oder mit Passwort für jeden Befehl ausführen können.

security_autoupdate_enabled: true

Ob yum-cron (RedHat-basierte Systeme) oder unattended-upgrades (Debian-basierte Systeme) installiert/aktiviert werden sollen. Systemneustarts erfolgen in jedem Fall nicht automatisch, und automatische Updates sind kein Ersatz für nachlässige Patch- und Paketverwaltung, aber automatische Updates können als zusätzliche Sicherheitsmaßnahme hilfreich sein.

security_autoupdate_blacklist: []

(Nur Debian/Ubuntu) Eine Liste von Paketen, die nicht automatisch aktualisiert werden sollen.

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

(Nur Debian/Ubuntu) Eine Liste von Ursprüngen, auf die verwiesen werden soll.

security_autoupdate_reboot: false

(Nur Debian/Ubuntu) Ob ein Neustart erforderlich ist während der automatischen Updates.

security_autoupdate_reboot_time: "03:00"

(Nur Debian/Ubuntu) Die Zeit, um einen Neustart auszulösen, wenn erforderlich, wenn security_autoupdate_reboot auf true gesetzt ist. Im 24-Stunden "hh:mm" Format.

security_autoupdate_mail_to: ""
security_autoupdate_mail_on_error: true

(Nur Debian/Ubuntu) Wenn security_autoupdate_mail_to auf einen nicht leeren Wert eingestellt ist, sendet die automatische Aktualisierung eine E-Mail an diese Adresse, wenn ein Fehler auftritt. Sie können dies entweder auf eine vollständige E-Mail: [email protected] oder auf etwas wie root setzen, was die Nachricht über /etc/aliases weiterleitet. Wenn Sie security_autoupdate_mail_on_error auf false setzen, erhalten Sie nach jeder Paketinstallation eine E-Mail.

security_fail2ban_enabled: true

Ob fail2ban installiert/aktiviert werden soll. Sie sollten fail2ban möglicherweise nicht verwenden, wenn Sie bereits einen anderen Dienst für Login- und Eindringungserkennung verwenden (z. B. ConfigServer).

security_fail2ban_custom_configuration_template: "jail.local.j2"

Der Name der Vorlagendatei, die verwendet wird, um die Konfiguration von fail2ban zu erstellen.

Abhängigkeiten

Keine.

Beispiel-Playbook

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

Innerhalb von vars/main.yml:

security_sudoers_passworded:
  - johndoe
  - deployacct

Lizenz

MIT (Expat) / BSD

Autor Informationen

Diese Rolle wurde 2014 von Jeff Geerling erstellt, Autor von Ansible for DevOps.