Einen Coolify-Server absichern

Die Firewall-Seite von Coolify listet die Ports des Servers auf, auf dem Coolify selbst läuft:

Server, die Coolify nur verwaltet, brauchen 22, 80 und 443. Port 8000 ist vor allem direkt nach der Installation wichtig. Die Installationsanleitung von Coolify warnt: Wer die Registrierungsseite zuerst erreicht, kann Admin der Instanz werden und Root-Zugriff auf den Server erhalten. Lege das Admin-Konto an, sobald die Installation fertig ist.

Gib dem Coolify-Dashboard eine Domain, die der Coolify-Proxy über HTTPS ausliefert. Sobald es dort funktioniert, laufen Dashboard, Echtzeitverbindung und Terminal alle über die Ports 80 und 443, und du kannst den öffentlichen Zugriff auf 8000, 6001 und 6002 schließen.

• Am einfachsten geht das mit der Firewall deines Providers, falls er eine anbietet: Coolify empfiehlt sie, weil sie unerwünschten Verkehr verwirft, bevor er den Server erreicht.
• Oder du bindest die drei Ports an 127.0.0.1 oder entfernst sie, mit einem Compose-Override in /data/coolify/source/docker-compose.custom.yml, und führst danach das Installationsskript erneut aus. Die Firewall-Seite von Coolify enthält die genaue Datei. Bearbeite nicht die Compose-Basisdatei: Coolify-Updates ersetzen sie.

Prüfe, ob das Dashboard unter seiner Domain funktioniert, bevor du die Ports schließt. Entfernst du sie zuerst, kannst du dich aus Coolify aussperren.

Ein Port, den ein Docker-Container veröffentlicht, wird von deinen INPUT-Regeln nicht gefiltert. Die Docker-Dokumentation sagt es zu ufw ganz direkt: Pakete werden geroutet, bevor die Firewall-Regeln greifen können. Die Firewall-Seite von Coolify sagt dasselbe: Einen Port mit ufw zu sperren garantiert nicht, dass ein von Docker veröffentlichter Port gesperrt ist.

Verkehr zu einem Container wird weitergeleitet, nicht an den Host zugestellt, und läuft deshalb über den FORWARD-Pfad. Dort lässt Docker eine Chain für deine eigenen Regeln frei, DOCKER-USER, die es vor seinen eigenen auswertet. Eine Regel, die einen veröffentlichten Port schließt, muss dort stehen und muss auf den Port prüfen, den der Client angefragt hat: Nach Dockers Adressumsetzung trägt das Paket schon den Port des Containers, und genau dafür gibt es --ctorigdstport.

# Neue Verbindungen aus dem Internet zum veröffentlichten Port 8000 verwerfen (eth0 = die öffentliche Schnittstelle).
iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctstate NEW --ctorigdstport 8000 -j DROP

Mit iptables hinzugefügte Regeln gehen beim Neustart verloren, wenn du sie nicht speicherst (zum Beispiel mit iptables-persistent oder netfilter-persistent). Eine Firewall beim Provider erspart dir die Frage, und für Server ohne eine solche nennt Coolify auch das Community-Werkzeug ufw-docker.

Traefik ist der Standard-Proxy von Coolify (Caddy ist die Alternative), auf den Ports 80 und 443: siehe die Proxy-Übersicht. Neue Proxy-Konfigurationen machen das Traefik-Dashboard nicht zugänglich. Die Dashboard-Seite von Coolify warnt, dass --api.insecure=true es ohne Authentifizierung auf dem API-Port von Traefik öffnet, und auch durch die Firewall hindurch, wenn die Proxy-Konfiguration Port 8080 veröffentlicht.

• Prüfe in Coolify in der Proxy-Konfiguration jedes Servers, dass der Proxy 8080 nicht veröffentlicht und nicht --api.insecure=true verwendet.
• Wenn du das Traefik-Dashboard brauchst, leg es stattdessen nach der Anleitung von Coolify hinter eine Domain mit Authentifizierung.

Coolify verwaltet jeden Server über SSH, auch den, auf dem es selbst läuft, als root und mit einem Schlüssel, den es selbst erzeugt. Ein Nicht-root-Benutzer ist experimentell und braucht trotzdem sudo ohne Passwort. Die OpenSSH-Seite von Coolify empfiehlt Schlüssel-Authentifizierung, wobei root sich nur per Schlüssel anmelden darf:

# /etc/ssh/sshd_config (oder eine Datei in /etc/ssh/sshd_config.d/)
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PasswordAuthentication no

PasswordAuthentication no schaltet die Passwort-Anmeldung für alle Benutzer ab, nicht nur für root: Prüfe vorher, dass jede Person, die sich anmeldet, einen Schlüssel hat. Teste dann die Konfiguration und lade SSH aus der Sitzung neu, die du schon offen hast:

sshd -t && systemctl reload ssh    # auf Systemen der RHEL-Familie heißt der Dienst "sshd"

• Auf Servern, die Coolify verwaltet, erlaube SSH, wo möglich, nur von der Adresse des Coolify-Servers, wie es die Firewall-Seite von Coolify vorschlägt.
• Der Schlüssel von Coolify hat zwangsläufig keine Passphrase. Er liegt unter /data/coolify/ssh/keys, und /data/coolify/source/.env enthält die Geheimnisse der Installation: Behandle beide samt ihren Backups wie Root-Passwörter.

Nur Coolify 4.x erhält Sicherheitsupdates. Coolify veröffentlicht seine Korrekturen in den GitHub Security Advisories und seine Versionen auf der Release-Seite. Zügig zu aktualisieren, ist auf einem Server, dessen Dashboard Befehle als root ausführen kann, umso wichtiger.

Sind die Schritte oben erledigt, deckt der Agent ab, was eine Firewall allein nicht leistet: die Angriffe, die über die Ports kommen, die du offen lassen musst.

• Er erkennt Coolify (an /data/coolify) und zeigt es im Dashboard an. Wo eine Plattform wie Coolify den Webserver verwaltet, ändert der Agent dessen Konfiguration nie.
• Sperren erreichen die Container. Ist Docker vorhanden, springt der Agent nicht nur aus INPUT, sondern auch aus DOCKER-USER in seine eigene Chain und hält diesen Sprung an erster Stelle. Seine Sperren, Bedrohungslisten und Ländersperren gelten deshalb auch für Ports, die Container veröffentlichen. Entfernt ein Neuladen der Firewall den Sprung, setzt der Agent ihn wieder.
• Er schließt offene Datenbank-Ports, auch bei Containern. Eine Datenbank auf einem öffentlichen Port (MySQL, PostgreSQL, Redis, MongoDB und die anderen Datenbank-, Cache- und Admin-Ports, die der Agent kennt) lässt sich im Dashboard für das Internet schließen, abgeglichen mit dem Port, den der Client angefragt hat. Loopback, private Netze und deine Whitelist behalten den Zugriff, und die Änderung wird geprüft und zurückgenommen, wenn SSH oder eine Website nicht mehr antwortet. Die Coolify-eigenen Ports 8000, 6001 und 6002 schließt er nicht: Das erledigst du wie in Schritt 1.
• Er listet die Domains deiner Anwendungen auf. Ab Agent 1.0.35 liest er sie, nur lesend, aus den Labels, die Coolify für seinen Proxy schreibt (Traefik-Router-Regeln oder Caddy-Site-Adressen), so kannst du jeder Website das Monitoring-Badge geben, verifiziert über einen DNS-TXT-Eintrag. Im Proxy-Container führt er nie etwas aus. Die Web-Firewall liest Access-Logs im Common- oder Combined-Format, zum Beispiel eines, auf das du mit dem Label infrafence.log-path zeigst; der Proxy von Coolify schreibt JSON-Logs (nur mit aktivierter Traffic-Analyse), die der Agent nicht liest.
• Er stoppt SSH-Brute-Force an der Firewall, bewertet SSH-Sitzungen nach Risiko und überwacht ausgehenden Verkehr, DNS, Malware und Dateiintegrität wie auf jedem Linux-Server.
• Er kommt ufw nicht in die Quere. Seine Regeln liegen in eigenen INFRAFENCE-Chains, und deine ändert er nie.

Der Agent ersetzt die Schritte 1 bis 5 nicht: Das Admin-Konto sofort anlegen, 8000 schließen und Coolify aktuell halten bleibt deine Aufgabe. Was der Agent liest und sendet ist vollständig dokumentiert.