Jede neue Server per Ansible sicher und konsistent einrichten

Die Einrichtung eines neuen Servers ist oft ein manueller Prozess: Benutzer anlegen, SSH absichern, Firewall konfigurieren, Updates automatisieren. Doch was bei zwei oder drei Servern noch überschaubar ist, wird bei Dutzenden unübersichtlich. Kleine Abweichungen schleichen sich ein – etwa bei der SSH-Konfiguration, wenn ein Kollege in Eile war. Die Lösung? Ein standardisiertes Ansible-Playbook, das die gleiche Abfolge von Schritten auf jedem Server ausführt. Und zwar idempotent: Führt man das Playbook erneut aus, ändert sich nichts – oder fehlende Einstellungen werden korrigiert. So bleibt die Sicherheit konsistent, ohne dass man sich auf Erinnerungen oder manuelle Checks verlassen muss.

Warum ein Playbook die manuelle Arbeit ersetzt

Ein typisches Szenario: Ein Entwickler richtet einen neuen Server ein, der für eine Anwendung genutzt werden soll. Die ersten Schritte sind immer ähnlich – ein administrativer Nutzer mit sudo-Rechten wird angelegt, die SSH-Zugänge werden auf Schlüssel beschränkt, die Firewall wird aktiviert und automatische Sicherheitspatches werden konfiguriert. Doch schon bei der SSH-Konfiguration kann es Unterschiede geben: Eine Maschine erlaubt MaxAuthTries 3, eine andere nicht. Solche Inkonsistenzen sind nicht nur ärgerlich, sondern potenzielle Sicherheitslücken.

Ein manuell ausgeführtes Bash-Skript oder eine Checkliste hilft zwar, die Basissicherheit zu gewährleisten – aber nur, wenn es konsequent angewendet wird. Sobald mehrere Personen Zugriff auf die Server haben oder die Einrichtung in stressigen Phasen stattfindet, entstehen Abweichungen. Hier kommt Ansible ins Spiel: Das Playbook übernimmt die gleiche Logik wie die manuelle Arbeit, führt die Schritte aber jedes Mal identisch aus. Und das Beste: Durch Idempotenz bleibt der Zustand eines Servers stabil – selbst nach Monaten.

Der Aufbau des Playbooks: Basissicherheit in wenigen Schritten

Das vorgestellte Playbook ist bewusst schlank gehalten. Es konzentriert sich ausschließlich auf die grundlegenden Sicherheitseinstellungen und vermeidet projekt- oder anwendungsspezifische Konfigurationen. So bleibt es stabil und muss selten angepasst werden. Der Aufbau folgt einer klaren Struktur:

• Administrativer Nutzer anlegen: Ein neuer Benutzer mit sudo-Rechten wird erstellt. Dieser dient als Einstiegspunkt für alle zukünftigen Verwaltungsaufgaben.
• SSH-Zugriff einschränken: Root-Logins werden deaktiviert, Passwort-Authentifizierung wird blockiert, und die maximale Anzahl an Authentifizierungsversuchen wird auf drei begrenzt.
• Firewall und Fail2Ban einrichten: Die Firewall wird so konfiguriert, dass eingehender Datenverkehr standardmäßig blockiert wird, während ausgehender Datenverkehr erlaubt bleibt. Nur die notwendigen Ports (22, 80, 443) bleiben geöffnet. Fail2Ban wird installiert, um wiederholte Angriffsversuche automatisch zu blockieren.
• Automatische Updates aktivieren: Das Paket unattended-upgrades wird installiert, um Sicherheitsupdates automatisch einzuspielen.

Ein zentraler Bestandteil des Playbooks ist die SSH-Konfiguration. Da viele Cloud-Anbieter standardmäßig eine SSH-Konfiguration mit Root-Login und Passwort-Authentifizierung vorgeben, wird die lokale Konfiguration überschrieben. Die Änderungen werden nur dann angewendet, wenn sich etwas am Zielsystem ändert – ein weiterer Vorteil der Idempotenz.

---
- name: Basissicherheit für neue Server
  hosts: new_servers
  become: true
  vars:
    admin_user: deploy
    ssh_public_key: "{{ lookup('file', '~/.ssh/id_ed25519.pub') }}"

  tasks:
    - name: Administrativer Nutzer anlegen
      user:
        name: "{{ admin_user }}"
        groups: sudo
        shell: /bin/bash
        create_home: true

    - name: SSH-Schlüssel für administrativen Nutzer hinzufügen
      authorized_key:
        user: "{{ admin_user }}"
        key: "{{ ssh_public_key }}"

    - name: SSH-Konfiguration harden (überschreibt Cloud-Init-Standards)
      copy:
        dest: /etc/ssh/sshd_config.d/99-hardening.conf
        content: |
          PermitRootLogin no
          PasswordAuthentication no
          MaxAuthTries 3
        mode: '0644'
      notify: sshd neu starten

    - name: UFW und Fail2Ban installieren
      apt:
        name: [ufw, fail2ban]
        state: present
        update_cache: true

    - name: UFW-Standardeinstellungen konfigurieren
      ufw:
        direction: "{{ item.direction }}"
        policy: "{{ item.policy }}"
      loop:
        - { direction: incoming, policy: deny }
        - { direction: outgoing, policy: allow }

    - name: Erforderliche Ports freigeben
      ufw:
        rule: allow
        port: "{{ item }}"
        proto: tcp
      loop: ['22', '80', '443']

    - name: UFW aktivieren
      ufw:
        state: enabled

    - name: Fail2Ban aktivieren
      systemd:
        name: fail2ban
        enabled: true
        state: started

    - name: Unattended-Upgrades installieren
      apt:
        name: unattended-upgrades
        state: present

  handlers:
    - name: sshd neu starten
      systemd:
        name: ssh
        state: restarted

Praktische Anwendung: Vom ersten zum wiederholten Einsatz

Der erste Einsatz des Playbooks erfolgt auf einem frischen Server, der noch keine administrativen Nutzer hat. Da Ansible zunächst als root-Nutzer arbeiten muss, wird das Playbook mit dem Befehl

ansible-playbook -i inventory.ini baseline.yml -l new-server-01 -u root

ausgeführt. Innerhalb weniger Minuten werden alle Sicherheitseinstellungen vorgenommen: Der administrative Nutzer deploy wird angelegt, die SSH-Konfiguration wird angepasst, die Firewall wird aktiviert und Fail2Ban wird gestartet. Nach Abschluss des Playbooks ist der Root-Zugriff deaktiviert – alle weiteren Aufrufe erfolgen über den neuen Nutzer deploy.

In der Praxis sieht das so aus:

ansible-playbook -i inventory.ini baseline.yml -l new-server-01 -u deploy

Dieser Befehl wird jedes Mal ausgeführt, wenn der Server gewartet oder neue Software installiert wird. Dank Idempotenz passiert nur dann etwas, wenn sich die Konfiguration seit dem letzten Lauf geändert hat. Das Playbook bestätigt damit nicht nur die Einhaltung der Sicherheitsrichtlinien, sondern korrigiert auch Abweichungen automatisch.

Der entscheidende Vorteil: Konsistenz ohne manuelle Überprüfung

Der größte Nutzen des Playbooks liegt nicht in der Zeitersparnis am ersten Tag – schließlich dauert eine manuelle Einrichtung ebenfalls etwa eine Stunde. Der wahre Wert zeigt sich Monate später, wenn Unsicherheit besteht: Wurde die Firewall auf diesem Server tatsächlich aktiviert? Ist die SSH-Konfiguration überall gleich? Statt stundenlanger Überprüfungen reicht ein einziger Playbook-Lauf, um den Status aller Server zu prüfen und fehlende Einstellungen nachzuholen.

Dieses Prinzip der Idempotenz macht Ansible zu einem unverzichtbaren Werkzeug für die Infrastrukturverwaltung. Es eliminiert menschliche Fehler, stellt Konsistenz sicher und reduziert den Wartungsaufwand auf ein Minimum. Für Teams, die mehrere Server verwalten, ist ein solches Playbook kein Luxus – es ist die Grundlage für eine zuverlässige und sichere IT-Infrastruktur.