Skip to main content
Teksolvr
Zurück zum Blog
Cybersicherheit4. Juli 20267 min read

Linux/Windows-Server-Härtung: Ein Schritt-für-Schritt-Leitfaden zur sicheren Konfiguration

Rudra Chauhan, Senior Systems Architect

Linux/Windows-Server-Härtung: Ein Schritt-für-Schritt-Leitfaden zur sicheren Konfiguration

Linux/Windows-Server-Härtung: Ein Schritt-für-Schritt-Leitfaden zur sicheren Konfiguration

Die Sicherung von Servern ist ein kontinuierlicher Prozess, der mit einer soliden Basis-Konfiguration beginnt und sich mit Bedrohungsinformationen entwickelt. Diese Anleitung führt Sie durch die Härtung der kritischsten Angriffsflächen – SSH, TLS, Firewalls und HTTP-Sicherheitskopfzeichen – auf beiden Linux- und Windows-Plattformen und verbindet alles mit einem wiederholbaren Risikominderungsworkflow.

SSH-Daemon-Konfiguration - Best Practices für sichere Verbindungen

Direkte Antwort: Härtet sshd ab, indem Sie veraltete Protokolle deaktivieren, eine Schlüsselbasierte Authentifizierung erzwingen, den Zugriff einschränken und starke kryptografische Standards anwenden.

Kernhärtungsschritte (Linux)

bash
# /etc/ssh/sshd_config – ersetzen Sie das gesamte Datei oder fügen Sie diese Zeilen hinzu
Port 2222                                 # Nicht-standard-Port reduziert automatisierte Scans
Protokoll 2
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AuthenticationMethods publickey
AllowUsers alice bob@192.0.2.0/24          # Einschränken durch Benutzer und Quell-CIDR
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com

Neustart: systemctl reload sshd

Windows OpenSSH-Server (Win32-OpenSSH)

powershell
# C:\ProgramData\ssh\sshd_config
Port 2222
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey
AllowUsers alice,bob
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

Neustarten des Dienstes: Restart-Service sshd

Schnellreferenz-Tabelle – SSH-Härtungsparameter

ParameterEmpfohlener WertGrund
Port2222 (oder jeder >1024)Reduziert Lärm von Bot-Scannern
PermitRootLoginnoVerhindert direkte root-Kompromisse
PasswordAuthenticationnoErzwingt Schlüsselbasierte Authentifizierung
AuthenticationMethodspublickeyGarantiert MFA-artige Kontrolle
Cipherschacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.comModerne AEAD-Verschlüsselung
KexAlgorithmscurve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256Vorwärts-sichere Schlüsselaustausch
AllowUsersalice bob@192.0.2.0/24Mindestprivilegien-Netzwerksegmentierung

Tool tip: Erstellen Sie eine bereitgestellte sshd_config-Datei mit dem SSH-Konfigurationsgenerator und überprüfen Sie die Syntax mit sshd -t.

Sichere SSL/TLS-Konfiguration – Implementierung von Best Practices für Verschlüsselung

Direkte Antwort: Implementieren Sie nur TLS 1.2 + 1.3, verwenden Sie starke Verschlüsselungssätze, aktivieren Sie HSTS, OCSP-Stapling und erzwingen Sie Zertifikatstransparenz.

Nginx-Beispiel (Linux)

nginx
# /etc/nginx/conf.d/ssl-hardening.conf
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Protokoll & Verschlüsselungssatz
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';
    ssl_prefer_server_ciphers off;

    # OCSP-Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # HSTS (1 Jahr, einschließlich Unterdomänen, Vorräder)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Sicherheitskopfzeichen (siehe nächsten Abschnitt)
    include /etc/nginx/security-headers.conf;
}

IIS (Windows) – PowerShell-Härtung

powershell
# Deaktivieren Sie TLS 1.0/1.1, aktivieren Sie 1.2/1.3
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'Enabled' -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Name 'Enabled' -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value 1
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Name 'Enabled' -Value 1

# Einschränken Sie Verschlüsselungssätze (Beispiel: nur AES-GCM & CHACHA20)
$ciphers = @(
    'TLS_AES_256_GCM_SHA384',
    'TLS_CHACHA20_POLY1305_SHA256',
    'TLS_AES_128_GCM_SHA256'
)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers' -Name 'Functions' -Value ($ciphers -join ',')

# Aktivieren Sie HSTS via web.config (fügen Sie es zur Site-Root hinzu)
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Referenz

  • IETF RFC 7519 – JSON Web Token (JWT) für stateless Auth; stellen Sie sicher, dass Token nur über TLS-geschützte Kanäle übertragen werden.

Firewall-Regeln – Konfiguration von iptables, nftables, ufw und Windows Firewall für sichere Netzwerkzugriffe

Direkte Antwort: Übernehmen Sie eine default-deny-Haltung, erlauben Sie nur erforderliche Eingangs-Ports (SSH, HTTPS, Management) und loggen Sie abgewiesene Pakete für Audit.

Linux – nftables (modern, atomar)

bash
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif "lo" accept
        ct state established,related accept
        # SSH (benutzerdefinierter Port)
        tcp dport 2222 ct state new limit rate 5/minute accept
        # HTTP/HTTPS
        tcp dport {80,443} accept
        # ICMP (rate-gesteuert)
        icmp type echo-request limit rate 1/second accept
        # Log & drop
        log prefix "DROP_IN: " level info
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Linux – UFW (Ubuntu/Debian-freundlich)

bash
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp comment 'SSH-härteter Port'
ufw allow 80,443/tcp comment 'Web-Verkehr'
ufw limit 2222/tcp comment 'Rate-limiting für SSH'
ufw enable

Windows Firewall – PowerShell (Domänen/Private-Profile)

powershell
# Zurücksetzen auf Basis-Konfiguration
Set-NetFirewallProfile -All -DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyDisplayEnabled False

# Erstellen Sie SSH (benutzerdefinierter Port)
New-NetFirewallRule -DisplayName "Allow SSH 2222" -Direction Inbound -Protocol TCP -LocalPort 2222 -Action Allow -Profile Domain,Private -Enabled True

# Erstellen Sie HTTP/HTTPS
New-NetFirewallRule -DisplayName "Allow HTTP/HTTPS" -Direction Inbound -Protocol TCP -LocalPort 80,443 -Action Allow -Profile Domain,Private -Enabled True

# Aktivieren Sie Logging für abgewiesene Pakete
Set-NetFirewallProfile -All -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log" -LogMaxSizeKilobytes 4096 -LogAllowed False -LogBlocked True -LogIgnored True

Tool tip: Verwenden Sie den Firewall-Regelgenerator, um die genauen iptables, nftables, ufw- oder Windows-Firewall-Befehle für Ihr Umfeld zu erstellen.

Sicherheitskopfzeichen – Implementierung von CSP, HSTS und anderen wesentlichen Kopfzeichen für sichere Webanwendungen

Direkte Antwort: Implementieren Sie ein defense-in-depth-Kopfzeichen-Set auf jedem HTTP-Antwort: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy und Cross-Origin-Opener-Policy.

Nginx-Snippet (/etc/nginx/security-headers.conf)

nginx
# Content-Security-Policy – Anpassen Sie Quellen an Ihre Assets
add_header Content-Security-Policy
    "default-src 'self';
     script-src 'self' 'nonce-$request_id' https://cdn.example.com;
     style-src  'self' 'nonce-$request_id' https://fonts.googleapis.com;
     img-src    'self' data: https://cdn.example.com;
     font-src   'self' https://fonts.gstatic.com;
     connect-src 'self' https://api.example.com;
     frame-ancestors 'none';
     base-uri 'self';
     form-action 'self';"
    immer;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" immer;
add_header X-Content-Type-Options "nosniff" immer;
add_header X-Frame-Options "DENY" immer;
add_header Referrer-Policy "strict-origin-when-cross-origin" immer;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" immer;
add_header Cross-Origin-Opener-Policy "same-origin" immer;
add_header Cross-Origin-Resource-Policy "same-origin" immer;

Apache (/etc/apache2/conf-available/security-headers.conf)

apache
Header immer set Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-%{UNIQUE_ID}e' https://cdn.example.com; style-src 'self' 'nonce-%{UNIQUE_ID}e' https://fonts.googleapis.com; img-src 'self' data: https://cdn.example.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self';"
Header immer set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header immer set X-Content-Type-Options "nosniff"
Header immer set X-Frame-Options "DENY"
Header immer set Referrer-Policy "strict-origin-when-cross-origin"
Header immer set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header immer set Cross-Origin-Opener-Policy "same-origin"
Header immer set Cross-Origin-Resource-Policy "same-origin"

IIS – web.config (fügen Sie es unter <system.webServer> hinzu)

xml
<httpProtocol>
  <customHeaders>
    <add name="Content-Security-Policy" value="default-src 'self'; script-src 'self' 'nonce-{RANDOM}' https://cdn.example.com; style-src 'self' 'nonce-{RANDOM}' https://fonts.googleapis.com; img-src 'self' data: https://cdn.example.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self';" />
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="X-Frame-Options" value="DENY" />
    <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
    <add name="Permissions-Policy" value="geolocation=(), microphone=(), camera=()" />
    <add name="Cross-Origin-Opener-Policy" value="same-origin" />
    <add name="Cross-Origin-Resource-Policy" value="same-origin" />

Fehlerbehebung-Checkliste

War diese Anleitung hilfreich?

Fehlersuche oder Testen dieses Leitfadens?

Teksolvr bietet 97 kostenlose Tools zur DNS-Konfigurationsprüfung, DKIM-Zertifikatvalidierung, Port-Tests, Server-Blacklist-Prüfung und Berechnungen.

97 kostenlose Tools entdeckenKI-Assistent fragen