Sicherheitshärtung für Produktionsserver: Eine umfassende Checkliste

Die durchschnittliche Zeit bis zur Erkennung eines Datenverstoßes beträgt 204 Tage. Durch die Härtung von Produktionsservern wird Ihre Angriffsfläche verringert, sodass Verstöße schwieriger zu initiieren und schneller zu erkennen sind. Dieser Leitfaden behandelt die konkreten Sicherheitsmaßnahmen, die jeder Produktionsserver implementieren sollte, von der SSH-Konfiguration bis hin zu Webanwendungs-Firewalls.

Wichtige Erkenntnisse

• Nur-SSH-Schlüsselauthentifizierung und nicht standardmäßige Ports blockieren 99 % der automatisierten Brute-Force-Angriffe
• Eine richtig konfigurierte Firewall reduziert die Angriffsfläche von Tausenden Einstiegspunkten auf weniger als zehn
• Web Application Firewalls blockieren SQL-Injection, XSS und andere OWASP-Top-10-Angriffe auf der Netzwerkebene
• Automatisiertes Patching stellt sicher, dass Schwachstellen innerhalb weniger Stunden und nicht erst Wochen nach der Offenlegung behoben werden

---

SSH-Härtung

Konfiguration

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Use SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit login attempts
MaxAuthTries 3
MaxSessions 5

# Set idle timeout (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 0

# Restrict SSH to specific users
AllowUsers deploy ubuntu

# Disable X11 forwarding
X11Forwarding no

# Use only strong algorithms
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

---

Firewall-Konfiguration

UFW (Ubuntu)

# Reset and set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider changing port)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow specific IPs for management
sudo ufw allow from 203.0.113.10 to any port 9090 comment "Grafana"
sudo ufw allow from 203.0.113.10 to any port 9093 comment "Alertmanager"

# Deny everything else (implicit with default deny)
sudo ufw enable
sudo ufw status verbose

AWS-Sicherheitsgruppen

# Terraform security group
resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS from internet"
  }

  # Allow SSH from office IP only
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
    description = "SSH from office"
  }

  # Allow all outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Database security group - no public access
resource "aws_security_group" "db" {
  name_prefix = "db-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "PostgreSQL from app servers only"
  }
}

---

Nginx-Sicherheitsheader

# Security headers for all responses
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com;" always;

# Hide server version
server_tokens off;

# Limit request size
client_max_body_size 10m;

# Rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
    }

    location /auth/ {
        limit_req zone=login burst=3 nodelay;
    }
}

---

SSL/TLS-Konfiguration

# Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# Certificate (Let's Encrypt)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Automatisierte Zertifikatsverlängerung

# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "nginx -s reload"

---

Containersicherheit

Wenn Sie Docker in der Produktion ausführen, wenden Sie diese zusätzlichen Härtungsmaßnahmen an:

Docker-Daemon-Sicherheit

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Einschränkungen der Containerlaufzeit

# docker-compose.yml security settings
services:
  api:
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Grundprinzipien:

• Entfernen Sie alle Funktionen und fügen Sie nur das wieder hinzu, was benötigt wird
• Schreibgeschütztes Dateisystem verhindert, dass Angreifer Containerinhalte ändern
• Keine neuen Berechtigungen verhindern eine Rechteausweitung innerhalb von Containern
• Nicht-Root-Benutzer in der Docker-Datei (siehe unseren Docker-Bereitstellungsleitfaden)

Bildsicherheit

• Verwenden Sie offizielle, minimale Basisbilder (Alpine-Varianten)
• Bildversionen anheften (niemals :latest in der Produktion verwenden)
• Scannen Sie Bilder mit Trivy oder Grype auf Schwachstellen
• Signieren Sie Bilder mit Docker Content Trust
• Verwenden Sie eine private Registrierung mit Zugriffskontrollen

---

Datenbanksicherheit

PostgreSQL-Härtung

# postgresql.conf security settings
listen_addresses = 'localhost'        # Only listen on localhost
ssl = on                              # Require SSL for connections
ssl_cert_file = '/path/to/server.crt'
ssl_key_file = '/path/to/server.key'
password_encryption = scram-sha-256   # Modern password hashing
log_connections = on                  # Log all connections
log_disconnections = on               # Log disconnections
log_statement = 'ddl'                 # Log DDL statements

# pg_hba.conf - restrict connections
# TYPE  DATABASE  USER  ADDRESS      METHOD
local   all       all                scram-sha-256
host    all       all   10.0.0.0/8   scram-sha-256
hostssl all       all   0.0.0.0/0    scram-sha-256

• Setzen Sie PostgreSQL niemals dem öffentlichen Internet aus
• Verwenden Sie dedizierte Datenbankbenutzer mit den erforderlichen Mindestberechtigungen
• Verbindungsverschlüsselung (SSL) aktivieren
• Legen Sie starke Passwortrichtlinien fest
• Regelmäßige Backup-Verifizierung (siehe unseren Leitfaden zur Notfallwiederherstellung)

---

Einbruchserkennung

OSSEC-Konfiguration

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Monitor critical files for changes -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/opt/app/dist</directories>

    <!-- Ignore frequently changing files -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>

    <!-- Run integrity check every 6 hours -->
    <frequency>21600</frequency>
  </syscheck>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

AWS GuardDuty

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
  }
}

---

Automatisiertes Sicherheits-Patching

# Ubuntu: Enable unattended security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

---

Checkliste zur Sicherheitshärtung

Serverebene

• Authentifizierung nur mit SSH-Schlüssel, Root-Anmeldung deaktiviert
• Firewall mit standardmäßiger Ablehnungsrichtlinie konfiguriert
• Fail2Ban aktiv auf SSH und Webserver
• Automatische Sicherheitsupdates aktiviert
• Nicht wesentliche Dienste deaktiviert
• Überwachung der Dateiintegrität (OSSEC oder gleichwertig)
• Audit-Protokollierung aktiviert (auditd)

Anwendungsebene

• TLS 1.2+ auf allen Endpunkten, HSTS aktiviert
• Sicherheitsheader konfiguriert (CSP, X-Frame-Optionen usw.)
• Ratenbegrenzung für alle öffentlichen Endpunkte
• Eingabevalidierung und parametrisierte Abfragen (kein sql.raw())
• HttpOnly, sichere Cookies zur Authentifizierung
• CORS auf bekannte Ursprünge beschränkt
• Fehlerantworten lassen keine Stack-Traces durchsickern

Netzwerkebene

• Datenbank nicht öffentlich zugänglich
• Interne Dienste in privaten Subnetzen
• VPC-Endpunkte für AWS-Dienste (kein öffentliches Internet)
• WAF auf öffentlich zugänglichen Endpunkten
• DDoS-Schutz (Cloudflare, AWS Shield)

Überwachung

• Alarmierung bei Sicherheitsereignissen konfiguriert
• Protokollaufbewahrung für mindestens 90 Tage
• Fehlgeschlagene Authentifizierungsversuche überwacht
• Ungewöhnliche Verkehrsmuster erkannt

---

Häufig gestellte Fragen

Wie oft sollten wir Sicherheitsüberprüfungen durchführen?

Vierteljährliche automatische Scans (Schwachstellenscans, Abhängigkeitsprüfungen) und jährliche manuelle Penetrationstests. Hochriskante Anwendungen (Zahlungsabwicklung, Gesundheitsdaten) sollten alle 6 Monate externen Penetrationstests unterzogen werden. Jede Produktionsbereitstellung sollte automatisierte Sicherheitsscans in der CI/CD-Pipeline umfassen – siehe unseren CI/CD-Best Practices-Leitfaden.

Ist eine WAF erforderlich, wenn wir bereits eine Ratenbegrenzung haben?

Ja. Durch die Ratenbegrenzung wird Missbrauch verhindert, der Inhalt der Anfrage wird jedoch nicht überprüft. Eine WAF blockiert SQL-Injection, XSS und andere Angriffe auf Anwendungsebene durch die Analyse der Anforderungsnutzlasten. Stellen Sie sich Ratenbegrenzung als Hochwasserschutz und WAF als Inhaltskontrolle vor – Sie brauchen beides.

Wie sichern wir einen Odoo-Produktionsserver?

Zusätzlich zur oben genannten allgemeinen Härtung: Deaktivieren Sie den Datenbankmanager in der Produktion (list_db = False), legen Sie einen starken admin_passwd fest, verwenden Sie dbfilter, um den Datenbankzugriff einzuschränken, führen Sie Odoo hinter Nginx aus (stellen Sie Odoo niemals direkt bereit) und halten Sie Odoo und alle Module auf dem neuesten Stand. ECOSIRE bietet Odoo-Sicherheitshärtung als Teil unserer verwalteten Hosting-Dienste.

Was ist die wirkungsvollste Sicherheitsmaßnahme?

Aktivieren von MFA (Multi-Faktor-Authentifizierung) für alle Administratorkonten. Diese einzige Kontrolle verhindert 99 % der auf Anmeldeinformationen basierenden Angriffe. Implementieren Sie MFA auf SSH (über PAM), der AWS-Konsole, Datenbank-Administration-Tools und Anwendungs-Admin-Panels, bevor Sie andere Absicherungsmaßnahmen ergreifen.

---

Was als nächstes kommt

Die Härtung der Sicherheit ist eine fortlaufende Praxis. Kombinieren Sie es mit [Überwachung und Warnung] (/blog/monitoring-alerting-setup) zur Erkennung, [Disaster Recovery] (/blog/disaster-recovery-planning) zur Ausfallsicherheit und [CI/CD-Sicherheitsscan] (/blog/ci-cd-pipeline-best-practices) zur Prävention.

Kontaktieren Sie ECOSIRE für Beratung zur Sicherheitshärtung oder erkunden Sie unseren DevOps-Leitfaden für die vollständige Infrastruktur-Roadmap.

---

Herausgegeben von ECOSIRE – Unterstützung von Unternehmen bei der Sicherung der Produktionsinfrastruktur.