Sécuriser un serveur Coolify

La page pare-feu de Coolify liste les ports du serveur qui fait tourner Coolify lui-même :

Les serveurs que Coolify se contente de gérer ont besoin de 22, 80 et 443. Le port 8000 compte surtout juste après l'installation : le guide d'installation de Coolify prévient que la première personne qui atteint la page d'inscription peut devenir administrateur de l'instance et obtenir un accès root au serveur. Créez le compte administrateur dès la fin de l'installation.

Donnez un domaine au tableau de bord de Coolify, servi en HTTPS par le proxy de Coolify. Une fois qu'il fonctionne à cette adresse, le tableau de bord, la connexion en temps réel et le terminal passent tous par les ports 80 et 443, et vous pouvez fermer l'accès public à 8000, 6001 et 6002.

• Le plus simple est le pare-feu de votre hébergeur, s'il en propose un : Coolify le recommande, car il écarte le trafic indésirable avant qu'il n'atteigne le serveur.
• Ou bien liez les trois ports à 127.0.0.1, ou supprimez-les, avec une surcharge Compose dans /data/coolify/source/docker-compose.custom.yml, puis relancez le script d'installation. La page pare-feu de Coolify donne le fichier exact. Ne modifiez pas le fichier Compose de base : les mises à jour de Coolify le remplacent.

Vérifiez que le tableau de bord fonctionne sur son domaine avant de fermer les ports. Si vous les supprimez d'abord, vous risquez de ne plus pouvoir accéder à Coolify.

Un port publié par un conteneur Docker n'est pas filtré par vos règles INPUT. La documentation de Docker est sans détour au sujet d'ufw : les paquets sont routés avant que les règles du pare-feu puissent s'appliquer. La page pare-feu de Coolify dit la même chose : bloquer un port avec ufw ne garantit pas qu'un port publié par Docker soit bloqué.

Le trafic vers un conteneur est transféré, et non remis à l'hôte : il passe donc par le chemin FORWARD. Docker y laisse une chaîne pour vos propres règles, DOCKER-USER, qu'il évalue avant les siennes. Une règle qui ferme un port publié doit se trouver là, et doit porter sur le port demandé par le client : après la traduction d'adresses de Docker, le paquet porte déjà le port du conteneur, et c'est à cela que sert --ctorigdstport.

# Rejette les nouvelles connexions depuis internet vers le port publié 8000 (eth0 = l'interface publique).
iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctstate NEW --ctorigdstport 8000 -j DROP

Les règles ajoutées avec iptables sont perdues au redémarrage si vous ne les enregistrez pas (par exemple avec iptables-persistent ou netfilter-persistent). Un pare-feu chez votre hébergeur évite la question, et Coolify mentionne aussi l'outil communautaire ufw-docker pour les serveurs qui n'en ont pas.

Traefik est le proxy par défaut de Coolify (Caddy est l'alternative), sur les ports 80 et 443 : voir la présentation du proxy. Les nouvelles configurations du proxy n'exposent pas le tableau de bord de Traefik. La page consacrée au tableau de bord de Coolify prévient que --api.insecure=true l'expose sans authentification sur le port de l'API de Traefik, et à travers le pare-feu si la configuration du proxy publie le port 8080.

• Dans la configuration du proxy de chaque serveur dans Coolify, vérifiez que le proxy ne publie pas le port 8080 et n'utilise pas --api.insecure=true.
• Si vous avez besoin du tableau de bord de Traefik, suivez plutôt la page de Coolify pour le placer derrière un domaine avec authentification.

Coolify gère chaque serveur via SSH, y compris celui sur lequel il tourne, en root avec une clé qu'il génère. Un utilisateur non root est expérimental et nécessite quand même sudo sans mot de passe. La page OpenSSH de Coolify recommande l'authentification par clé, avec root autorisé uniquement par clé :

# /etc/ssh/sshd_config (ou un fichier dans /etc/ssh/sshd_config.d/)
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PasswordAuthentication no

PasswordAuthentication no désactive la connexion par mot de passe pour tous les utilisateurs, pas seulement pour root : vérifiez d'abord que chaque personne qui se connecte a une clé. Testez ensuite la configuration et rechargez SSH depuis la session que vous avez déjà ouverte :

sshd -t && systemctl reload ssh    # sur les systèmes de la famille RHEL, le service s'appelle "sshd"

• Sur les serveurs gérés par Coolify, n'autorisez SSH que depuis l'adresse du serveur Coolify quand c'est possible, comme le suggère la page pare-feu de Coolify.
• La clé de Coolify n'a pas de phrase de passe, par nécessité. Elle se trouve dans /data/coolify/ssh/keys, et /data/coolify/source/.env contient les secrets de l'installation : traitez les deux, ainsi que leurs sauvegardes, comme des mots de passe root.

Seul Coolify 4.x reçoit des mises à jour de sécurité. Coolify publie ses correctifs dans les avis de sécurité GitHub et ses versions sur la page des releases. Mettre à jour rapidement compte encore plus sur un serveur dont le tableau de bord peut exécuter des commandes en root.

Une fois les étapes ci-dessus faites, l'agent couvre ce qu'un pare-feu seul ne couvre pas : les attaques qui arrivent par les ports que vous devez laisser ouverts.

• Il reconnaît Coolify (grâce à /data/coolify) et l'affiche dans le tableau de bord. Là où une plateforme comme Coolify gère le serveur web, l'agent ne modifie jamais sa configuration.
• Les bannissements atteignent les conteneurs. Quand Docker est présent, l'agent saute vers sa propre chaîne depuis DOCKER-USER en plus d'INPUT, et garde ce saut en première position. Ses bannissements, ses listes de menaces et ses blocages par pays s'appliquent donc aussi aux ports publiés par les conteneurs. Si un rechargement du pare-feu supprime le saut, l'agent le remet en place.
• Il ferme les ports de bases de données exposés, conteneurs compris. Une base de données publiée sur un port public (MySQL, PostgreSQL, Redis, MongoDB et les autres ports de base de données, de cache et d'administration que l'agent connaît) peut être fermée à internet depuis le tableau de bord, en ciblant le port demandé par le client. Le loopback, les réseaux privés et votre liste d'autorisation gardent l'accès, et la modification est vérifiée puis annulée si SSH ou un site cesse de répondre. Il ne ferme pas les ports 8000, 6001 et 6002 de Coolify lui-même : faites-le comme à l'étape 1.
• Il liste les domaines de vos applications. Depuis l'agent 1.0.35, il les lit, en lecture seule, dans les labels que Coolify écrit pour son proxy (règles de routeur Traefik ou adresses de site Caddy) : vous pouvez ainsi donner à chaque site le badge de surveillance, vérifié avec un enregistrement DNS TXT. Il n'exécute jamais rien dans le conteneur du proxy. Le pare-feu web lit les journaux d'accès au format common ou combined, par exemple celui que vous indiquez avec le label infrafence.log-path ; le proxy de Coolify écrit des journaux JSON (seulement avec l'analyse du trafic activée), que l'agent ne lit pas.
• Il arrête la force brute SSH au pare-feu, évalue le risque des sessions SSH et surveille le trafic sortant, le DNS, les malwares et l'intégrité des fichiers comme sur n'importe quel serveur Linux.
• Il ne gêne pas ufw. Ses règles vivent dans ses propres chaînes INFRAFENCE, et il ne modifie jamais les vôtres.

L'agent ne remplace pas les étapes 1 à 5 : créer le compte administrateur tout de suite, fermer le port 8000 et garder Coolify à jour restent de votre ressort. Ce que l'agent lit et envoie est documenté en détail.