Wie man eine Firewall für Ihr cPanel-Hosting konfiguriert

Einen cPanel-Server ohne ordnungsgemäß konfigurierten Firewall zu betreiben ist wie die Eingangstür eines Rechenzentrums unverschlossen zu lassen. ConfigServer Security & Firewall (CSF) ist der De-facto-Standard zur Absicherung von cPanel- und WHM-Umgebungen — er integriert sich direkt in die WHM-Oberfläche, umschließt iptables (oder nftables auf neueren Kerneln) und wird mit einem Begleiter-Daemon namens Login Failure Daemon (LFD) ausgeliefert, der die Echtzeit-Angriffserkennung übernimmt. Dieser Leitfaden führt durch eine vollständige, produktionsreife CSF-Bereitstellung: Installation, Regelarchitektur, erweiterte Bedrohungsabwehr und einen fortlaufenden Wartungsworkflow.

Ob Sie einen VPS mit cPanel oder einen vollständigen Dedizierten Server betreiben, die Konfigurationsprinzipien sind identisch. Der Unterschied besteht darin, dass Sie auf einem dedizierten Server exklusiven Kernel-Zugriff haben, was bedeutet, dass CSFs aggressivere Verbindungsverfolgung und SYN-Flood-Schutzfunktionen stärker ausgereizt werden können, ohne benachbarte Mandanten zu beeinträchtigen.

Warum eine Software-Firewall auf cPanel-Servern keine Option ist

cPanel exponiert by Design eine große Angriffsfläche. Eine Standardinstallation öffnet Dutzende von Dienst-Ports — WHM (2086/2087), cPanel (2082/2083), FTP (21), Mail-Submission (587), IMAP (993), POP3 (995) und mehr. Jeder offene Port ist ein potenzieller Eintrittspunkt. Ohne einen zustandsbehafteten Paketfilter vor diesen Diensten:

• Gelingen Brute-Force-Angriffe gegen SSH, FTP und Webmail unbemerkt
• Hämmern Credential-Stuffing-Bots auf xmlapi– und cpsrvd-Endpunkte ein
• Sättigt amplifikationsbasierter DDoS-Datenverkehr die NIC, bevor die Anwendungsschicht reagieren kann
• Können kompromittierte Shared-Hosting-Konten lateral über den Server pivotieren

Eine Hardware-Firewall am Netzwerkrand hilft, kann aber keinen Anwendungsschicht-Kontext sehen — sie weiß nicht, dass eine IP in 60 Sekunden 20 aufeinanderfolgende IMAP-Anmeldungen fehlgeschlagen ist. CSF + LFD arbeitet auf Host-Ebene und reagiert genau auf diese Art von Verhaltenssignal.

CSF vs. andere cPanel-Firewall-Optionen

CSF gewinnt in jeder Dimension, die für eine cPanel-Umgebung relevant ist. Der einzige Grund, firewalld oder ufw zu wählen, ist, wenn Sie einen Nicht-cPanel-Stack betreiben und ein leichteres Werkzeug bevorzugen.

Schritt 1: Checkliste vor der Installation

Bevor Sie einen einzigen Befehl ausführen, führen Sie diese Prüfungen durch. Wer sie überspringt, sperrt sich versehentlich aus Produktionsservern aus.

Überprüfen Sie Ihren Out-of-Band-Zugang. Bestätigen Sie, dass Sie Zugang zur Konsole Ihres Hosting-Anbieters haben (KVM over IP, IPMI oder eine webbasierte VNC-Konsole). Wenn CSF Ihre IP während des Tests blockiert, ist der Konsolenzugang Ihr Wiederherstellungsweg.

Notieren Sie Ihre Management-IP-Adresse. Führen Sie folgendes von Ihrem lokalen Rechner aus:

curl -4 ifconfig.me

Sie werden diese IP in CSF auf die Whitelist setzen, bevor Sie den Durchsetzungsmodus aktivieren.

Überprüfen Sie den aktuellen iptables-Status:

iptables -L -n --line-numbers

Wenn ein anderes Firewall-Tool (APF, firewalld) bereits aktiv ist, stoppen und deaktivieren Sie es vor der Installation von CSF, um Regelkonflikte zu vermeiden.

Bestätigen Sie, dass Perl installiert ist (CSF basiert auf Perl):

perl -v

Auf einem frischen CentOS/AlmaLinux/CloudLinux-System ist Perl standardmäßig vorhanden. Auf minimalen Ubuntu-Builds installieren Sie es mit apt install perl.

Schritt 2: CSF auf Ihrem cPanel-Server installieren

Verbinden Sie sich als root über SSH mit Ihrem Server:

ssh root@YOUR_SERVER_IP

Herunterladen, entpacken und das Installationsprogramm ausführen:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Das Installationsprogramm registriert CSF als Systemdienst, installiert das WHM-Plugin und platziert die primäre Konfigurationsdatei unter /etc/csf/csf.conf.

Führen Sie die integrierte Abhängigkeitsprüfung aus, um zu bestätigen, dass alle erforderlichen Perl-Module vorhanden sind:

perl /usr/local/csf/bin/csftest.pl

Jede mit FATAL markierte Zeile muss vor dem Fortfahren behoben werden. Mit WARN markierte Zeilen sind optionale Funktionen — überprüfen Sie diese, aber sie verhindern nicht die Funktion von CSF.

Überprüfen Sie die installierte Version:

csf -v

Schritt 3: Grundkonfiguration in /etc/csf/csf.conf

Öffnen Sie die Hauptkonfigurationsdatei in Ihrem bevorzugten Editor:

nano /etc/csf/csf.conf

Die Datei ist ausführlich kommentiert. Die folgenden Direktiven haben die höchste Sicherheitsauswirkung und müssen bei jeder neuen Bereitstellung überprüft werden.

Testmodus

Wenn CSF erstmals installiert wird, ist TESTING = "1" standardmäßig gesetzt. In diesem Modus startet LFD nicht und es werden keine Blockierungen durchgesetzt — Regeln werden geladen, sind aber temporär. Deaktivieren Sie den Testmodus erst, nachdem Sie Ihre Management-IP auf die Whitelist gesetzt und alle Port-Regeln validiert haben.

TESTING = "0"   # Set this only after full validation

Eingehende und ausgehende Port-Allowlists

TCP_IN und TCP_OUT definieren, welche TCP-Ports in jeder Richtung erlaubt sind. Ein minimaler, aber funktionsfähiger cPanel-Server benötigt:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

Kritischer Betriebshinweis: Port 2087 ist WHM SSL. Port 2083 ist cPanel SSL. Wenn Sie diese aus TCP_IN entfernen, bevor Sie Ihre IP auf die Whitelist gesetzt haben, verlieren Sie sofort den Zugang zum Control Panel. Port 123 (UDP out) ist NTP — dessen Entfernung bricht die Zeitsynchronisierung, was zu SSL-Zertifikatsvalidierungsfehlern und Mail-Zustellungsablehnungen führt.

Schließen Sie jeden Port, der nicht aktiv genutzt wird. Führen Sie ss -tlnp aus, um zu prüfen, was tatsächlich lauscht, bevor Sie diese Liste finalisieren.

Ihre Management-IP auf die Whitelist setzen

Fügen Sie Ihre IP zu /etc/csf/csf.allow hinzu, bevor Sie den Testmodus deaktivieren:

echo "YOUR.MANAGEMENT.IP # My office IP" >> /etc/csf/csf.allow

Alternativ verwenden Sie den CSF-Befehl direkt:

csf -a YOUR.MANAGEMENT.IP "Management workstation"

Auf der Whitelist stehende IPs umgehen alle LFD-Blockierungen und alle Ratenbegrenzungsregeln. Halten Sie diese Liste minimal — jeder Eintrag ist eine dauerhafte Ausnahme von Ihrer Sicherheitsrichtlinie.

Bekannte schädliche IPs blockieren

Permanente Blockierungen kommen in /etc/csf/csf.deny:

csf -d MALICIOUS.IP.ADDRESS "Confirmed scanner"

Für Massenimporte aus Bedrohungsintelligenz-Feeds (Spamhaus DROP, Emerging Threats usw.) hängen Sie CIDRs direkt an /etc/csf/csf.deny an und laden neu:

csf -r

Schritt 4: Login Failure Daemon (LFD) konfigurieren

LFD ist die verhaltensbasierte Einbruchserkennungskomponente von CSF. Er verfolgt Systemprotokolldateien in Echtzeit, zählt Authentifizierungsfehler pro Quell-IP und löst eine temporäre Blockierung aus, wenn ein Schwellenwert überschritten wird. Dies ist Ihre primäre Verteidigung gegen Credential-Brute-Force-Angriffe.

Wichtige LFD-Direktiven in csf.conf:

Zu beachtender Grenzfall: Wenn sich Ihr Server hinter einem NAT-Gateway oder einem gemeinsam genutzten Büro-Router befindet, teilen sich mehrere legitime Benutzer eine externe IP. Ein zu niedriger LF_TRIGGER-Wert blockiert Ihr gesamtes Büro nach einigen Tippfehlern. Erhöhen Sie entweder den Schwellenwert oder setzen Sie die Büro-IP in csf.allow auf die Whitelist.

LFD überwacht auch verdächtige Prozesse, Verzeichnisüberwachungsereignisse und Dateiänderungserkennung (die LF_DIRWATCH– und LF_INTEGRITY-Funktionen). Aktivieren Sie LF_INTEGRITY, um nicht autorisierte Änderungen an Systembinärdateien zu erkennen:

LF_INTEGRITY = "3600"   # Check every hour

Schritt 5: Erweiterte Bedrohungsabwehrfunktionen

SYN-Flood-Schutz

SYN-Flood-Angriffe erschöpfen die TCP-Verbindungstabelle, indem sie große Mengen an SYN-Paketen senden, ohne den Handshake abzuschließen. Aktivieren Sie CSFs integrierte Abwehr:

SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Diese Werte erlauben 100 neue SYN-Pakete pro Sekunde mit einer Burst-Toleranz von 150, bevor die Regel greift. Passen Sie diese Zahlen basierend auf Ihrem legitimen Spitzendatenverkehr an — eine E-Commerce-Website während eines Flash-Sales benötigt möglicherweise höhere Burst-Werte.

Verbindungsverfolgung

Die Verbindungsverfolgung begrenzt die Gesamtzahl gleichzeitiger Verbindungen von einer einzelnen IP über alle Ports. Dies ist effektiv gegen langsame DDoS-Angriffe und Verbindungserschöpfung:

CT_LIMIT = "300"
CT_INTERVAL = "30"
CT_BLOCK_TIME = "1800"
CT_SKIP_LOCAL = "1"

CT_SKIP_LOCAL verhindert, dass Localhost- und Loopback-Verbindungen auf das Limit angerechnet werden — unerlässlich auf Servern, auf denen cPanel-Daemons intern über TCP kommunizieren.

Port-Scan-Erkennung

CSF kann Hosts erkennen und blockieren, die in einem kurzen Zeitfenster mehrere Ports sondieren:

PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_BLOCK_TIME = "3600"
PS_PERMANENT = "0"

Eine IP, die innerhalb von 300 Sekunden 10 oder mehr geschlossene Ports trifft, wird für eine Stunde blockiert. Setzen Sie PS_PERMANENT = "1" nur, wenn Sie sicher sind, dass Ihre legitimen Benutzer dies niemals versehentlich auslösen werden — einige Mail-Clients und Monitoring-Tools sondieren während der Verbindungsaushandlung mehrere Ports.

Blockierung auf Länderebene

Wenn Ihre Anwendung keine legitimen Benutzer in bestimmten Hochrisikoregionen hat, reduziert die Blockierung auf Länderebene das Rauschen in Ihren Protokollen und die LFD-Arbeitslast erheblich. Bearbeiten Sie csf.conf:

CC_DENY = "CN,RU,KP,NG"
CC_ALLOW = ""

Ländercodes folgen dem ISO 3166-1 Alpha-2-Standard. CSF lädt GeoIP-Daten automatisch herunter. Seien Sie hier präzise — das Blockieren ganzer Länder ist ein stumpfes Instrument. Ein besserer Ansatz für die meisten Bereitstellungen ist CC_ALLOW (nur die Länder auf die Allowlist setzen, in denen sich Ihre Benutzer befinden) kombiniert mit CC_ALLOW_PORTS, um den länderbasierten Zugang auf bestimmte Ports zu beschränken.

Ausgehende SMTP-Einschränkungen

Kompromittierte WordPress-Installationen und anfällige Skripte werden häufig als Spam-Relays missbraucht. CSF kann ausgehendes SMTP auf autorisierte Mail-Prozesse beschränken:

SMTP_BLOCK = "1"
SMTP_ALLOWUSER = "mailman"
SMTP_ALLOWGROUP = "mail"

Dies blockiert alle ausgehenden Verbindungen auf Port 25, außer von Prozessen, die als der angegebene Benutzer oder die angegebene Gruppe laufen. Die legitime Mail-Zustellung über Ihren MTA (Exim auf cPanel) ist nicht betroffen, da Exim als mail-Gruppe läuft. Diese einzelne Direktive eliminiert eine ganze Klasse von Spam-Missbrauch durch kompromittierte Konten.

Wenn Sie neben Ihrem Hosting professionelle ausgehende Mail-Infrastruktur benötigen, erwägen Sie die Kombination Ihres Servers mit einer dedizierten E-Mail-Hosting-Lösung für Transaktions- und Marketing-Mails.

Schritt 6: Konfiguration anwenden und testen

Sobald Sie alle Direktiven überprüft haben, laden Sie CSF neu, um Änderungen ohne vollständigen Neustart anzuwenden:

csf -r

Um sowohl CSF als auch LFD vollständig neu zu starten:

csf -ra

Überprüfen Sie den aktuellen Status und die aktive Regelanzahl:

csf -l

Überprüfen Sie, ob LFD läuft:

systemctl status lfd

Testen Sie von einer externen IP (nicht Ihrer auf der Whitelist stehenden Management-IP), dass die Port-Blockierung wie erwartet funktioniert. Verwenden Sie nmap von einem separaten Rechner:

nmap -sS -p 1-65535 YOUR_SERVER_IP

Nur die explizit in TCP_IN aufgeführten Ports sollten als offen erscheinen. Alle anderen sollten filtered zurückgeben.

Deaktivieren Sie den Testmodus erst, nachdem diese Validierung bestanden wurde:

# In /etc/csf/csf.conf, set TESTING = "0", then:
csf -r

Schritt 7: WHM-GUI-Konfiguration

Für Administratoren, die eine grafische Oberfläche bevorzugen, integriert sich CSF vollständig in WHM. Navigieren Sie zu WHM > Plugins > ConfigServer Security & Firewall. Von hier aus können Sie:

• Die Live-Blockliste anzeigen und IPs manuell entsperren
• Temporäre und permanente Erlaubniss-/Ablehnungseinträge hinzufügen
• Eine Konfigurationsprüfung auslösen, die die csf.conf-Syntax validiert
• LFD-Protokolle in einer paginierten, durchsuchbaren Oberfläche anzeigen
• Das Cluster-Synchronisierungstool ausführen, wenn Sie mehrere Server verwalten

Die WHM-Oberfläche ist besonders nützlich für Support-Mitarbeiter, die eine legitime Kunden-IP entsperren müssen, ohne SSH-Zugang zu haben. Gewähren Sie WHM-Reseller-Konten selektiv Zugang zum CSF-Plugin — nicht jeder Reseller benötigt Firewall-Verwaltungsfähigkeiten.

Schritt 8: Überwachung, Protokollanalyse und Wartung

Echtzeit-Protokollüberwachung

LFD schreibt Blockierungsereignisse in /var/log/lfd.log. Verfolgen Sie es während eines aktiven Vorfalls:

tail -f /var/log/lfd.log

CSFs eigenes Aktivitätsprotokoll befindet sich unter /var/log/csf.log. Für eine Zusammenfassung der am häufigsten blockierten IPs in den letzten 24 Stunden:

grep "Blocked" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

E-Mail-Benachrichtigungen

Konfigurieren Sie LFD, um Benachrichtigungen an Ihre Verwaltungsadresse zu senden:

LF_ALERT_TO = "admin@yourdomain.com"
LF_ALERT_FROM = "lfd@yourdomain.com"

Aktivieren Sie spezifische Benachrichtigungstypen:

LF_EMAIL_ALERT = "1"      # Block alerts
LT_EMAIL_ALERT = "1"      # Login tracking alerts
RT_EMAIL_ALERT = "1"      # Resource usage alerts

Vermeiden Sie es, jeden Benachrichtigungstyp auf einem stark ausgelasteten Server zu aktivieren — Benachrichtigungsmüdigkeit veranlasst Administratoren, Benachrichtigungen zu ignorieren, was den Zweck vollständig zunichte macht.

CSF aktualisieren

CSF veröffentlicht häufig Updates. Führen Sie den integrierten Updater aus:

csf -u

Dies lädt die neueste Version herunter, bewahrt Ihre Konfigurationsdateien und startet den Dienst neu. Planen Sie dies in einem wöchentlichen Cron-Job:

0 3 * * 0 /usr/sbin/csf -u >> /var/log/csf_update.log 2>&1

Integration mit cPHulk

cPanel wird mit einem eigenen Brute-Force-Schutz-Tool namens cPHulk ausgeliefert. Das gleichzeitige Ausführen von cPHulk und LFD erzeugt redundante Blockierungen und kann bei der Vorfallsreaktion zu Verwirrung führen. Der empfohlene Ansatz: cPHulk deaktivieren und ausschließlich auf LFD vertrauen, das konfigurierbarer ist und sich in CSFs einheitliche Blockliste integriert.

Deaktivieren Sie cPHulk über WHM unter Security Center > cPHulk Brute Force Protection.

Firewall-Architektur für Multi-Server-Umgebungen

Wenn Sie mehrere cPanel-Server verwalten — ein gängiges Muster bei VPS-Hosting-Clustern oder einem primären Webserver gepaart mit einem separaten Datenbankserver — ermöglicht CSFs Cluster-Synchronisierungsfunktion die gleichzeitige Weitergabe von Blocklisten an alle Knoten.

Konfigurieren Sie Cluster-Mitglieder in /etc/csf/csf.conf:

CLUSTER_MASTER = "PRIMARY_SERVER_IP"
CLUSTER_SENDTO = "SECONDARY_SERVER_IP"
CLUSTER_RECVFROM = "PRIMARY_SERVER_IP"
CLUSTER_KEY = "your_shared_secret_key"

Wenn LFD eine IP auf dem primären Server blockiert, wird die Blockierung innerhalb von Sekunden automatisch an alle Cluster-Mitglieder weitergegeben. Dies ist besonders wertvoll, wenn ein Scanner, der Ihren Webserver sondiert, gleichzeitig SSH-Brute-Force auf Ihrem Datenbankknoten versucht.

Für Hochverkehrsumgebungen oder GPU-intensive Workloads, die neben Webdiensten laufen, profitiert die GPU-Hosting-Infrastruktur vom gleichen CSF-Härtungsansatz — die Firewall-Konfiguration ist identisch, aber CT_LIMIT-Werte müssen typischerweise höher sein, um legitime parallele API-Verbindungen zu berücksichtigen.

SSL- und Port-Sicherheitsüberlegungen

Eine Firewall kontrolliert den Zugang zu Ports, validiert aber nicht die kryptografische Integrität von Verbindungen auf diesen Ports. Stellen Sie sicher, dass jeder durch Ihre Firewall-Regeln exponierte Dienst auch mit einem gültigen SSL/TLS-Zertifikat geschützt ist. Ein offener Port 443 mit einem abgelaufenen oder selbst signierten Zertifikat ist ein Phishing- und MITM-Risiko.

Kombinieren Sie Ihre Firewall-Konfiguration mit ordnungsgemäß ausgestellten Zertifikaten von einer vertrauenswürdigen CA. AlexHost bietet SSL-Zertifikate an, die sich direkt in cPanels AutoSSL-Workflow integrieren und sicherstellen, dass Ihre exponierten HTTPS-Endpunkte kryptografisch sicher sind.

Häufige Fallstricke und wie man sie vermeidet

Sich selbst während der Ersteinrichtung aussperren. Setzen Sie Ihre IP immer in csf.allow auf die Whitelist, bevor Sie TESTING = "0" setzen. Bestätigen Sie immer den Konsolenzugang, bevor Sie Durchsetzungsänderungen vornehmen.

cPanels eigene interne Dienste blockieren. cPanel-Daemons kommunizieren über Localhost und manchmal über die primäre IP des Servers. CT_SKIP_LOCAL = "1" und eine sorgfältige Überprüfung von TCP_OUT verhindern selbst verursachte Dienstunterbrechungen.

Zu aggressives LF_DURATION auf Shared Hosting. Wenn legitime Benutzer eine NAT-IP mit Angreifern teilen, bestraft eine 24-stündige Blockierung unschuldige Kunden. Verwenden Sie LF_DURATION = "3600" und LF_PERMBLOCK_COUNT = "4", um nur Wiederholungstäter zu permanenten Sperren zu eskalieren.

Vergessen, Monitoring-Agent-Ports zu öffnen. Wenn Sie einen externen Monitoring-Dienst (Zabbix, Nagios, Datadog) verwenden, benötigt dessen Agent einen offenen eingehenden Port. Fügen Sie ihn zu TCP_IN hinzu und setzen Sie die IP des Monitoring-Servers in csf.allow auf die Whitelist.

Ausgehende Regeln nicht testen. Administratoren konzentrieren sich auf eingehendes TCP_IN, vernachlässigen aber TCP_OUT. Zu restriktive ausgehende Regeln unterbrechen cPanels Update-System, Let’s Encrypt-Zertifikatserneuerungen (Port 80 ausgehend zu ACME-Servern) und Remote-MySQL-Verbindungen.

CSF auf einem Server mit Cloudflare-Proxying betreiben. Wenn Datenverkehr durch Cloudflare läuft, ist die von CSF gesehene Quell-IP eine Cloudflare-Edge-Node-IP, nicht die echte Besucher-IP. Das Blockieren einer Cloudflare-IP blockiert den gesamten Datenverkehr durch diesen Edge-Knoten. Verwenden Sie die csf.allow-Datei, um Cloudflares veröffentlichte IP-Bereiche auf die Whitelist zu setzen, und konfigurieren Sie Ihre Anwendung so, dass sie den CF-Connecting-IP-Header für echte Besucher-IPs liest.

Technische Entscheidungsmatrix: Auswahl Ihres CSF-Konfigurationsprofils

Wichtige Erkenntnisse: Checkliste für Produktionsbereitschaft

Bevor Sie Ihre CSF-Bereitstellung als produktionsbereit betrachten, überprüfen Sie jeden der folgenden Punkte:

• Management-IP ist in /etc/csf/csf.allow vorhanden und mit csf -g YOUR.IP bestätigt

TESTING = "0" ist gesetzt und csf -r wurde ausgeführt
TCP_IN enthält nur Ports mit aktiven, beabsichtigten Diensten — verifiziert gegen ss -tlnp

SMTP_BLOCK = "1" ist aktiviert, es sei denn, der Server ist ein dediziertes Mail-Relay
LFD läuft — bestätigt mit systemctl status lfd

FAQ

Was ist der Unterschied zwischen CSF und einer Hardware-Firewall, und benötige ich beide?

Eine Hardware-Firewall arbeitet am Netzwerkperimeter und filtert Datenverkehr, bevor er die NIC Ihres Servers erreicht. CSF arbeitet auf OS-Ebene und fügt anwendungsbewusste, verhaltensbasierte Erkennung hinzu, die Hardware-Firewalls nicht bieten können — wie das Blockieren einer IP nach wiederholten fehlgeschlagenen cPanel-Anmeldungen. In einer Produktionsumgebung ergänzen sich beide Schichten. Hardware-Filterung reduziert volumetrische DDoS-Last; CSF behandelt gezielte Eindringversuche.

Wie entsperre ich eine IP, die CSF permanent gesperrt hat?

Führen Sie csf -dr BLOCKED.IP.ADDRESS aus, um sie aus der Deny-Liste zu entfernen, dann csf -r, um Regeln neu zu laden. Alternativ verwenden Sie die WHM-CSF-Plugin-Oberfläche unter „IP entsperren”. Um eine erneute Blockierung zu verhindern, fügen Sie die IP mit csf -a IP.ADDRESS "reason" zu csf.allow hinzu.

Wird CSF die Erneuerung von Let’s Encrypt / AutoSSL-Zertifikaten beeinträchtigen?

Nur wenn Port 80 ausgehend in TCP_OUT blockiert ist oder wenn die Let’s Encrypt-Validierungsserver-IPs versehentlich in csf.deny stehen. Stellen Sie sicher, dass Port 80 sowohl in TCP_IN (für HTTP-01-Challenge-Antworten) als auch in TCP_OUT (für ACME-Server-Kommunikation) enthalten ist. Wenn Erneuerungen nach der CSF-Installation fehlschlagen, prüfen Sie csf.deny auf Let’s Encrypt-IP-Bereiche und überprüfen Sie /var/log/lfd.log auf blockierte ausgehende Verbindungen.

Wie teste ich sicher eine neue CSF-Regel, ohne das Risiko einer Aussperrung?

Aktivieren Sie den Testmodus vorübergehend wieder, indem Sie TESTING = "1" in csf.conf setzen und csf -r ausführen. Im Testmodus werden Regeln geladen, aber nicht durchgesetzt, und LFD startet nicht. Validieren Sie Ihre Änderungen, setzen Sie dann TESTING = "0" und laden Sie neu. Bestätigen Sie immer den Konsolenzugang, bevor Sie zurück in den Durchsetzungsmodus wechseln.

Schützt CSF vor Anwendungsschicht-Angriffen wie SQL-Injection oder XSS?

Nein. CSF arbeitet auf der Netzwerk- und Transportschicht (L3/L4) und hat keine Sichtbarkeit in HTTP-Anfrage-Payloads. Anwendungsschicht-Angriffe erfordern eine Web Application Firewall (WAF) wie ModSecurity mit dem OWASP Core Rule Set, der sich mit Apache und Nginx auf cPanel-Servern integriert. CSF und ModSecurity ergänzen sich — CSF behandelt Bedrohungen auf Netzwerkebene, während ModSecurity HTTP-Angriffe behandelt. LFD kann konfiguriert werden, um IPs zu blockieren, die wiederholt ModSecurity-Regeln über die LF_MODSEC-Direktive auslösen.