Cloud Server Firewall und Sicherheitsverwaltung

Jeder KapsuleHost Server wird mit einer verwalteten Firewall ausgeliefert, die standardmäßig eingehenden Datenverkehr ablehnt, plus Schutz vor Brute-Force-Angriffen, eine Web-Application-Firewall und automatisches Sicherheits-Patching, alles gesteuert von einer Seite in KPanel.

Die Standardeinstellungen sind so gewählt, dass ein brandneuer Server sicher ist, bevor Sie etwas berühren. Das, was Sie darauf aufbauen, sind normalerweise nur die Ports, die Ihre Anwendung benötigt. Dieses Handbuch führt durch die gesamte Seite Server management, denn die Firewall ist ein Abschnitt davon und die anderen Abschnitte verhindern, dass Sie die Firewall überhaupt benötigen.

Öffnen der Verwaltungsseite

1. Melden Sie sich bei KPanel an.
2. Klicken Sie auf Cloud Servers in der linken Seitenleiste, dann auf Ihren Server.
3. Klicken Sie auf Management in den Aktionsschaltflächen oben auf der Seite.

Die direkte Adresse ist /cloud-servers/<server-id>/management. Die Seite beschreibt sich selbst als "Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."

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, so dass eine Firewall-Änderung Sie nie aus der Maschine ausschließen kann.
• Die Ports, die Ihr App Stack benötigt, wie 80 und 443 für eine Webanwendung, werden für Sie geöffnet.
• Der ausgehende Datenverkehr vom Server wird nicht eingeschränkt.

Ohne benutzerdefinierte Regeln zeigt der Abschnitt "No custom rules. Defaults: SSH + app-stack ports." Dies ist ein gesunder Zustand, keine fehlende Konfiguration.

Hinzufügen einer benutzerdefinierten Regel

Fügen Sie eine Regel hinzu, wenn Sie etwas auf einem Port betreiben, den die Standardrichtlinie 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.

1. Öffnen Sie den Abschnitt Firewall (UFW).
2. Geben Sie die Port-Nummer in das erste Feld ein. Gültige Werte sind 1 bis 65535.
3. Wählen Sie TCP oder UDP.
4. Wählen Sie Allow oder Deny.
5. Klicken Sie auf Add.

Die Regel erscheint in der Liste mit einem ALLOW- oder DENY-Badge und dem Port sowie dem Protokoll, zum Beispiel 3000/tcp. Sie wird über die Verwaltungsverbindung innerhalb von Sekunden an den Server übertragen.

Um eine Regel zu entfernen, klicken Sie auf das X am Ende ihrer Zeile. Das Entfernen einer Allow-Regel schließt diesen Port sofort wieder.

App Stacks

Der Abschnitt App stack teilt der Plattform mit, welche Art von Anwendung dieser Server ausführt, so dass die Härtungs-Voreinstellung darauf abgestimmt werden kann. Die Installation einer Anwendung über das Panel setzt dies für Sie.

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 sichtbarsten in fail2ban.

fail2ban

fail2ban überwacht Authentifizierungsversuche und sperrt Adressen, die wiederholt 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 einzelne billigste Schutz auf der Seite, es kostet nichts in Bezug auf Leistung, und es verwandelt ein konstantes Hintergrundrauschen von Passwort-Rateversuchen in nichts. Auf einem WordPress- oder WooCommerce-Stack schützt es auch das Login-Formular, wo die meisten Angriffe auf WordPress tatsächlich landen.

ModSecurity, die Web-Application-Firewall

ModSecurity überprüft HTTP-Anfragen gegen den OWASP Core Rule Set und kennzeichnet diejenigen, die wie Angriffe aussehen. Auf einem KapsuleHost Server wird es im Detection-Only-Modus gestartet: "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 Ausgangspunkt. Der Core Rule Set ist gründlich, und bei einer echten Anwendung werden einige legitime Anfragen eine Regel erfüllen. Führen Sie es eine Zeit lang im Detection-Only-Modus aus, lesen Sie die Protokolle, arbeiten Sie heraus, welche Regeln Ihr eigener Datenverkehr auslöst, und schalten Sie erst dann die Blockierung im Server ein.

OS Auto-Patching

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 Schalter:

• 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 ausschalten, werden Kernel-Patches installiert, aber nicht aktiv, bis Sie selbst einen Neustart durchführen.
• Quiet window (UTC), eine Start- und Enduhrzeit. Neustarts erfolgen nur darin. Stellen Sie es auf die ruhigsten Stunden für Ihr Publikum ein, und denken Sie daran, dass das Feld in UTC ist, nicht in Ihrer lokalen Zeit.

Patch-Verlauf und sofortiges Patching

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 es 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 Funktion erfüllt hat: Der Server ist nach einem Neustart nicht sauber hochgefahren, sodass der Pre-Patch-Snapshot wiederhergestellt wurde. Siehe Cloud Server Snapshots, um zu erfahren, wie diese Snapshots funktionieren.

Eine sinnvolle Grundlage

Für die meisten Server ist dies die gesamte Sicherheitskonfiguration:

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 Panel konnte die Einstellungen für diesen Server nicht lesen. Laden Sie neu, und überprüfen Sie, dass der Server vorhanden ist und bereitgestellt wurde.

"Port must be 1-65535." Das Portfeld nimmt eine ganze Zahl in diesem Bereich an. Bereiche und Servicenamen werden hier nicht akzeptiert.

Meine Regel wurde gespeichert, aber es hat sich nichts geändert. Suchen Sie nach dem Banner "Live apply unavailable". Wenn es angezeigt wird, wird die Änderung gespeichert, aber noch nicht auf den Server übertragen.

Ich kann meinen Service 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 vollständige Festplatte ist die häufigste Ursache. Geben Sie Speicherplatz frei und klicken Sie auf Run patch now.

Der Datenverkehr mit berechtigtem Ursprung wurde blockiert. Wenn Sie ModSecurity in den Blocking-Modus geschaltet haben, setzen Sie es zurück auf Detection-Only, lesen Sie die Protokolle, und identifizieren Sie die Regel, bevor Sie es erneut versuchen.

Wenn sich eine Firewall-Regel weigert zu gelten, oder Sie sind aus einem Service ausgesperrt, den Sie zulassen, senden Sie eine E-Mail an support@kapsulehost.com mit dem Servernamen, dem Port und dem, was Sie darin erreichen möchten.