Jeder KapsuleHost-Server wird mit einer verwalteten Firewall ausgeliefert, die eingehenden Datenverkehr standardmäßig blockiert, plus Schutz vor Brute-Force-Angriffen, eine Web-Application-Firewall und automatische Sicherheits-Patches, alles über eine Seite in KPanel gesteuert.
Die Standardeinstellungen sind so gewählt, dass ein brandneuer Server sicher ist, bevor Sie etwas anfassen. Was Sie hinzufügen, sind normalerweise nur die Ports, die Ihre eigene Anwendung benötigt. Dieses Handbuch führt Sie durch die ganze Server-Verwaltungsseite, da die Firewall ein Abschnitt davon ist und die anderen Abschnitte sind, die verhindern, dass Sie die Firewall überhaupt brauchen.
Öffnen der Verwaltungsseite
- Melden Sie sich bei KPanel an.
- Klicken Sie auf Cloud Servers in der linken Seitenleiste und dann auf Ihren Server.
- Klicken Sie auf Management in den Schaltflächen am oberen Rand der Seite.
Die direkte Adresse ist /cloud-servers/<server-id>/management. Die Seite beschreibt sich selbst als "Firewall, Betriebssystem-Patches, fail2ban und ModSecurity. Änderungen werden über SSH innerhalb von Sekunden angewendet."
Wenn ein Banner "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately" anzeigt, kann das Bedienfeld den Server gerade nicht erreichen. Ihre Einstellungen werden weiterhin gespeichert, sie werden nur noch nicht angewendet. Überprüfen Sie, ob der Server läuft und erreichbar ist.
Die Standard-Firewall-Richtlinie
Der Abschnitt Firewall (UFW) gibt die Richtlinie in einer Zeile an: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
In der Praxis bedeutet das:
- Nichts kann Ihren Server aus dem Internet erreichen, es sei denn, eine Regel erlaubt es.
- Port 22 ist immer offen, daher kann eine Firewall-Änderung Sie nie aus der Maschine aussperren.
- Die Ports, die Ihr App-Stack benötigt, wie 80 und 443 für eine Webanwendung, werden für Sie geöffnet.
- Ausgehender Datenverkehr vom Server ist nicht eingeschränkt.
Ohne benutzerdefinierte Regeln zeigt der Abschnitt "No custom rules. Defaults: SSH + app-stack ports." Das ist ein gesunder Zustand, keine fehlende Konfiguration.
Hinzufügen einer benutzerdefinierten Regel
Fügen Sie eine Regel hinzu, wenn Sie etwas auf einem Port ausführen, das die Standard-Richtlinie nicht abdeckt: eine Node-Anwendung auf 3000, eine Datenbank, die Sie direkt auf 5432 erreichen müssen, einen Game- oder Media-Server auf einem UDP-Port.
- Öffnen Sie den Abschnitt Firewall (UFW).
- Geben Sie die Port-Nummer in das erste Feld ein. Gültige Werte sind 1 bis 65535.
- Wählen Sie TCP oder UDP.
- Wählen Sie Allow oder Deny.
- Klicken Sie auf Add.
Die Regel erscheint in der Liste mit einem ALLOW- oder DENY-Badge sowie dem Port und dem Protokoll, zum Beispiel 3000/tcp. Sie wird innerhalb von Sekunden über die Verwaltungsverbindung zum Server übertragen.
Um eine Regel zu entfernen, klicken Sie auf das X am Ende ihrer Zeile. Das Entfernen einer Allow-Regel schließt den Port sofort wieder.
Das Freigeben eines Datenbankports für das gesamte Internet ist einer der häufigsten Wege, wie ein Server kompromittiert wird. Bevor Sie 3306, 5432, 6379 oder 27017 freigeben, fragen Sie sich, ob das sich verbindende System die Datenbank über die Loopback-Schnittstelle des Servers selbst oder über ein privates Netzwerk erreichen könnte. Falls es wirklich von außen erreichbar sein muss, stellen Sie sicher, dass der Dienst selbst eine starke Authentifizierung und Verschlüsselung erfordert.
Fügen Sie zuerst die Regel hinzu, starten Sie dann den Dienst. Ein Dienst, der hinter einem geschlossenen Port startet, sieht genau so aus wie ein Dienst, der nicht gestartet werden konnte, und Sie können lange Zeit die falsche Schicht debuggen.
App-Stacks
Der Abschnitt App stack teilt der Plattform mit, welche Art von Anwendung dieser Server ausführt, damit die Härtungs-Voreinstellung darauf abgestimmt werden kann. Die Installation einer Anwendung über das Bedienfeld legt dies für Sie fest.
Die erkannten Stacks sind WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web und No app stack. Der Abschnitt erklärt sich selbst als: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
Der Stack beeinflusst, welche Ports automatisch geöffnet werden und wie die anderen Schutzmaßnahmen abgestimmt werden, am deutlichsten in fail2ban.
fail2ban
fail2ban überwacht Authentifizierungsversuche und blockiert Adressen, die immer wieder fehlschlagen. Es ist standardmäßig aktiviert und die Seite beschreibt es als: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
Lassen Sie es aktiviert. Es ist der einzeln günstigste Schutz auf dieser Seite, es kostet keine Leistung und wandelt ein konstantes Hintergrundgeräusch von Passwort-Rateversuchen in nichts um. Auf einem WordPress- oder WooCommerce-Stack schützt es auch das Anmeldeformular, das ist, wo die meisten Angriffe gegen WordPress tatsächlich landen.
ModSecurity, die Web-Application-Firewall
ModSecurity inspiziert HTTP-Anfragen gegen das OWASP Core Rule Set und kennzeichnet diejenigen, die wie Angriffe aussehen. Auf einem KapsuleHost-Server startet sie im Detection-Only-Modus: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
Detection-Only ist der richtige Startpunkt. Das Core Rule Set ist gründlich, und bei einer echten Anwendung werden einige legitime Anfragen eine Regel auslösen. Betreiben Sie es eine Weile im Detection-Only-Modus, lesen Sie die Protokolle, stellen Sie fest, welche Regeln Ihr eigener Datenverkehr auslöst, und wechseln Sie erst dann zur Blockierung innerhalb des Servers.
Das Aktivieren der Blockierung ohne vorherige Abstimmung kann Ihre eigene Website beschädigen. Formularübermittlungen mit Rich-Text, Datei-Uploads und API-Clients mit ungewöhnlichen Payloads sind die üblichen Opfer. Überprüfen Sie Ihre Protokolle, bevor Sie wechseln.
Automatisches Patchen des Betriebssystems
Sicherheitsupdates werden für Sie angewendet. Der Abschnitt erklärt das Sicherheitsnetz: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."
Zwei Einstellungen befinden sich unter dem Umschalter:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). Kernel-Updates werden nur nach einem Neustart wirksam. Wenn Sie dies deaktivieren, werden Kernel-Patches installiert, aber erst aktiv, wenn Sie selbst neu starten.
- Quiet window (UTC), eine Start- und Enduhrzeit. Neustarts finden nur darin statt. Stellen Sie dies auf die ruhigsten Stunden für Ihr Publikum ein und denken Sie daran, dass das Feld in UTC ist, nicht in Ihrer Ortszeit.
Lassen Sie die automatische Patching aktiviert. Die überwiegende Mehrheit der kompromittierten Server führt Software aus, bei der ein Patch bereits Wochen zuvor veröffentlicht wurde. Ein Pre-Patch-Snapshot mit automatischem Rollback bedeutet, dass die übliche Einwand, dass ein Update etwas kaputt machen könnte, bereits behandelt wird.
Patch-Verlauf und sofortiges Ausführen eines Patches
Der Abschnitt Patch history listet jeden Durchlauf mit einem Status von RUNNING, SUCCESS, ROLLED_BACK, FAILED oder SKIPPED auf, die Anzahl der aktualisierten Pakete, ob der Server neu gestartet wurde, und die Zeit, zu der er gestartet wurde.
Um sofort zu patchen, anstatt auf den Zeitplan zu warten, klicken Sie auf Run patch now. Die Bestätigung lautet: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
Ein ROLLED_BACK-Eintrag bedeutet, dass das Sicherheitsnetz seine Aufgabe erfüllt hat: der Server kam nicht sauber nach einem Neustart zurück, daher wurde der Pre-Patch-Snapshot wiederhergestellt. Siehe Cloud-Server-Snapshots, um zu erfahren, wie diese Snapshots funktionieren.
Eine sinnvolle Baseline
Für die meisten Server ist dies die gesamte Sicherheitskonfiguration:
| Einstellung | Empfohlen |
|---|---|
| Firewall | An, Standard-Regeln, plus nur die Ports, die Ihre App benötigt |
| fail2ban | An |
| ModSecurity | An, Detection-Only, bis Sie die Protokolle gelesen haben |
| Automatisches Betriebssystem-Patching | An, mit Neustarts in einem ruhigen Zeitfenster erlaubt |
| SSH-Authentifizierung | Schlüssel, nicht Passwörter |
Die letzte Zeile ist nicht auf dieser Seite, aber wichtiger als der Rest zusammen. Siehe Verbindung zu Ihrem Cloud-Server mit SSH.
Fehlerbehebung
"Could not load management config." Das Bedienfeld konnte die Einstellungen für diesen Server nicht lesen. Laden Sie neu und überprüfen Sie, ob der Server vorhanden und bereitgestellt ist.
"Port must be 1-65535." Das Portfeld akzeptiert eine ganze Zahl in diesem Bereich. Bereiche und Dienstnamen werden hier nicht akzeptiert.
Meine Regel wurde gespeichert, aber nichts hat sich geändert. Suchen Sie nach dem Banner "Live apply unavailable". Wenn es angezeigt wird, wird die Änderung gespeichert, aber noch nicht zum Server übertragen.
Ich kann meinen Dienst aus einem Netzwerk erreichen, aber nicht aus einem anderen. Das ist normalerweise Ihre eigene ausgehende Firewall, nicht die des Servers. Testen Sie von einer anderen Verbindung, bevor Sie hier Regeln ändern.
Ein Patch-Durchlauf zeigt FAILED. Lesen Sie die Fehlermeldung in der Zeile. Eine volle Festplatte ist die häufigste Ursache. Geben Sie etwas Speicherplatz frei und klicken Sie auf Run patch now.
Legitimer Datenverkehr wird blockiert. Wenn Sie ModSecurity in den Blockierungsmodus gewechselt haben, stellen Sie es auf Detection-Only zurück, lesen Sie die Protokolle und identifizieren Sie die Regel, bevor Sie es erneut versuchen.
Wenn eine Firewall-Regel sich weigert anzuwenden oder Sie aus einem Dienst, den Sie erlaubt haben, ausgesperrt werden, schreiben Sie eine E-Mail an support@kapsulehost.com mit dem Servernamen, dem Port und dem, das Sie erreichen möchten.