Proteggere un server Coolify

La pagina sul firewall di Coolify elenca le porte del server su cui gira Coolify stesso:

I server che Coolify si limita a gestire hanno bisogno di 22, 80 e 443. La porta 8000 conta soprattutto subito dopo l'installazione: la guida di installazione di Coolify avverte che chi raggiunge per primo la pagina di registrazione può diventare l'amministratore dell'istanza e ottenere l'accesso root al server. Crea l'account amministratore appena l'installazione finisce.

Assegna un dominio alla dashboard di Coolify, servito in HTTPS dal proxy di Coolify. Quando funziona lì, la dashboard, la connessione in tempo reale e il terminale passano tutti dalle porte 80 e 443, e puoi chiudere l'accesso pubblico a 8000, 6001 e 6002.

• Il modo più semplice è il firewall del tuo provider, se ne ha uno: Coolify lo consiglia, perché scarta il traffico indesiderato prima che arrivi al server.
• Oppure lega le tre porte a 127.0.0.1, o rimuovile, con un override Compose in /data/coolify/source/docker-compose.custom.yml, e poi esegui di nuovo lo script di installazione. La pagina sul firewall di Coolify riporta il file esatto. Non modificare il file Compose di base: gli aggiornamenti di Coolify lo sostituiscono.

Prima di chiudere le porte, verifica che la dashboard funzioni sul suo dominio. Se le rimuovi prima, puoi restare chiuso fuori da Coolify.

Una porta pubblicata da un container Docker non viene filtrata dalle tue regole INPUT. La documentazione di Docker è netta su ufw: i pacchetti vengono instradati prima che le regole del firewall possano essere applicate. La pagina sul firewall di Coolify dice lo stesso: bloccare una porta con ufw non garantisce che una porta pubblicata da Docker sia bloccata.

Il traffico verso un container viene inoltrato, non consegnato all'host, quindi passa dal percorso FORWARD. Lì Docker lascia una catena per le tue regole, DOCKER-USER, che valuta prima delle sue. Una regola che chiude una porta pubblicata deve stare lì, e deve confrontare la porta che il client ha chiesto: dopo la traduzione degli indirizzi fatta da Docker il pacchetto porta già la porta del container, ed è a questo che serve --ctorigdstport.

# Scarta le nuove connessioni da internet verso la porta pubblicata 8000 (eth0 = l'interfaccia pubblica).
iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctstate NEW --ctorigdstport 8000 -j DROP

Le regole aggiunte con iptables si perdono al riavvio se non le salvi (per esempio con iptables-persistent o netfilter-persistent). Un firewall del provider evita il problema, e Coolify cita anche lo strumento della community ufw-docker per i server che non ne hanno uno.

Traefik è il proxy predefinito di Coolify (l'alternativa è Caddy), sulle porte 80 e 443: vedi la panoramica sul proxy. Le nuove configurazioni del proxy non espongono la dashboard di Traefik. La pagina sulla dashboard di Coolify avverte che --api.insecure=true la espone senza autenticazione sulla porta API di Traefik, e anche attraverso il firewall se la configurazione del proxy pubblica la porta 8080.

• Nella configurazione del proxy di ogni server in Coolify, verifica che il proxy non pubblichi la 8080 e non usi --api.insecure=true.
• Se ti serve la dashboard di Traefik, segui la pagina di Coolify per metterla invece dietro un dominio con autenticazione.

Coolify gestisce ogni server via SSH, compreso quello su cui gira, come root e con una chiave che genera lui. Un utente non root è sperimentale e richiede comunque sudo senza password. La pagina su OpenSSH di Coolify consiglia l'autenticazione con chiave, con root ammesso solo con chiave:

# /etc/ssh/sshd_config (oppure un file in /etc/ssh/sshd_config.d/)
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PasswordAuthentication no

PasswordAuthentication no disattiva l'accesso con password per tutti gli utenti, non solo per root: prima verifica che ogni persona che accede abbia una chiave. Poi controlla la configurazione e ricarica SSH dalla sessione che hai già aperta:

sshd -t && systemctl reload ssh    # sui sistemi della famiglia RHEL il servizio si chiama "sshd"

• Sui server gestiti da Coolify, consenti SSH solo dall'indirizzo del server Coolify dove puoi, come suggerisce la pagina sul firewall di Coolify.
• La chiave di Coolify non ha passphrase, per forza di cose. Si trova in /data/coolify/ssh/keys, e /data/coolify/source/.env contiene i segreti dell'installazione: tratta entrambi, e i loro backup, come password di root.

Solo Coolify 4.x riceve aggiornamenti di sicurezza. Coolify pubblica le correzioni negli avvisi di sicurezza su GitHub e le versioni nella pagina delle release. Aggiornare subito conta ancora di più su un server la cui dashboard può eseguire comandi come root.

Fatti i passi qui sopra, l'agente copre quello che un firewall da solo non fa: gli attacchi che arrivano dalle porte che devi tenere aperte.

• Riconosce Coolify (da /data/coolify) e lo mostra nella dashboard. Dove una piattaforma come Coolify gestisce il web server, l'agente non ne modifica mai la configurazione.
• I ban arrivano ai container. Quando c'è Docker, l'agente salta alla propria catena da DOCKER-USER oltre che da INPUT, e tiene quel salto per primo. I suoi ban, le liste di minacce e i blocchi per paese valgono quindi anche per le porte pubblicate dai container. Se un reload del firewall toglie il salto, l'agente lo rimette.
• Chiude le porte dei database esposte, anche dei container. Un database pubblicato su una porta pubblica (MySQL, PostgreSQL, Redis, MongoDB e le altre porte di database, cache e amministrazione che l'agente conosce) si può chiudere a internet dalla dashboard, confrontando la porta che il client ha chiesto. Loopback, reti private e la tua lista consentiti mantengono l'accesso, e la modifica viene verificata e annullata se SSH o un sito smettono di rispondere. Non chiude le porte 8000, 6001 e 6002 di Coolify: per quelle segui il passo 1.
• Elenca i domini delle tue applicazioni. Dall'agente 1.0.35 li legge, in sola lettura, dalle label che Coolify scrive per il suo proxy (regole di router Traefik o indirizzi dei siti Caddy), così puoi dare a ogni sito il badge di monitoraggio, verificato con un record DNS TXT. Non esegue mai nulla nel container del proxy. Il web firewall legge access log in formato common o combined, per esempio uno indicato con la label infrafence.log-path; il proxy di Coolify scrive log JSON (solo con le traffic analytics attive), che l'agente non legge.
• Ferma il brute force SSH al firewall, assegna un punteggio di rischio alle sessioni SSH e controlla traffico in uscita, DNS, malware e integrità dei file come su qualsiasi server Linux.
• Non intralcia ufw. Le sue regole stanno nelle sue catene INFRAFENCE, e non modifica mai le tue.

L'agente non sostituisce i passi da 1 a 5: creare subito l'account amministratore, chiudere la 8000 e tenere Coolify aggiornato restano compiti tuoi. Cosa legge e cosa invia l'agente è documentato per intero.