Como proteger um servidor Coolify

A página de firewall do Coolify lista as portas do servidor onde roda o próprio Coolify:

Os servidores que o Coolify apenas gerencia precisam de 22, 80 e 443. A porta 8000 importa mais logo depois da instalação: o guia de instalação do Coolify avisa que quem chegar primeiro à página de cadastro pode virar o administrador da instância e ganhar acesso root ao servidor. Crie a conta de administrador assim que a instalação terminar.

Dê um domínio ao painel do Coolify, servido pelo proxy do Coolify em HTTPS. Quando ele estiver funcionando ali, o painel, a conexão em tempo real e o terminal passam todos pelas portas 80 e 443, e você pode fechar o acesso público a 8000, 6001 e 6002.

• O jeito mais simples é o firewall do seu provedor, se ele tiver um: o Coolify recomenda, porque ele descarta o tráfego indesejado antes que chegue ao servidor.
• Ou vincule as três portas a 127.0.0.1, ou remova-as, com um override do Compose em /data/coolify/source/docker-compose.custom.yml, e rode o script de instalação de novo. A página de firewall do Coolify traz o arquivo exato. Não edite o arquivo Compose base: as atualizações do Coolify o substituem.

Confira se o painel funciona no domínio dele antes de fechar as portas. Se você removê-las antes, pode ficar sem acesso ao Coolify.

Uma porta publicada por um container Docker não é filtrada pelas suas regras INPUT. A documentação do Docker é direta sobre o ufw: os pacotes são roteados antes que as regras do firewall possam ser aplicadas. A página de firewall do Coolify diz o mesmo: bloquear uma porta com o ufw não garante que uma porta publicada pelo Docker fique bloqueada.

O tráfego para um container é encaminhado, não entregue ao host, então passa pelo caminho FORWARD. Ali o Docker deixa uma cadeia para as suas próprias regras, DOCKER-USER, que ele avalia antes das dele. Uma regra que fecha uma porta publicada precisa ficar ali, e precisa conferir a porta que o cliente pediu: depois da tradução de endereços do Docker, o pacote já carrega a porta do container, e é para isso que serve --ctorigdstport.

# Descarta conexões novas vindas da internet para a porta publicada 8000 (eth0 = a interface pública).
iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctstate NEW --ctorigdstport 8000 -j DROP

Regras adicionadas com iptables se perdem no reboot se você não as salvar (por exemplo com iptables-persistent ou netfilter-persistent). Um firewall no provedor evita a questão, e o Coolify também cita a ferramenta da comunidade ufw-docker para servidores sem um.

O Traefik é o proxy padrão do Coolify (a alternativa é o Caddy), nas portas 80 e 443: veja a visão geral do proxy. As configurações novas do proxy não expõem o dashboard do Traefik. A página sobre o dashboard do Coolify avisa que --api.insecure=true o expõe sem autenticação na porta da API do Traefik, e através do firewall se a configuração do proxy publicar a porta 8080.

• Na configuração do proxy de cada servidor no Coolify, confira se o proxy não publica a 8080 e não usa --api.insecure=true.
• Se você precisa do dashboard do Traefik, siga a página do Coolify para colocá-lo atrás de um domínio com autenticação.

O Coolify gerencia cada servidor por SSH, inclusive aquele onde ele roda, como root e com uma chave que ele mesmo gera. Um usuário não root é experimental e ainda precisa de sudo sem senha. A página sobre OpenSSH do Coolify recomenda autenticação por chave, com root permitido só por chave:

# /etc/ssh/sshd_config (ou um arquivo em /etc/ssh/sshd_config.d/)
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PasswordAuthentication no

PasswordAuthentication no desliga o login com senha para todos os usuários, não só para o root: antes, confira se cada pessoa que acessa tem uma chave. Depois teste a configuração e recarregue o SSH a partir da sessão que você já tem aberta:

sshd -t && systemctl reload ssh    # em sistemas da família RHEL o serviço se chama "sshd"

• Nos servidores que o Coolify gerencia, libere o SSH só a partir do endereço do servidor Coolify quando der, como sugere a página de firewall do Coolify.
• A chave do Coolify não tem passphrase, por necessidade. Ela fica em /data/coolify/ssh/keys, e /data/coolify/source/.env guarda os segredos da instalação: trate os dois, e os backups deles, como senhas de root.

Só o Coolify 4.x recebe atualizações de segurança. O Coolify publica as correções nos avisos de segurança do GitHub e as versões na página de releases. Atualizar logo importa ainda mais num servidor cujo painel pode executar comandos como root.

Com os passos acima feitos, o agente cobre o que um firewall sozinho não cobre: os ataques que chegam pelas portas que você precisa manter abertas.

• Ele reconhece o Coolify (por /data/coolify) e o mostra no painel. Onde uma plataforma como o Coolify gerencia o servidor web, o agente nunca altera a configuração dele.
• Os bloqueios chegam aos containers. Quando há Docker, o agente salta para a própria cadeia a partir de DOCKER-USER, além de INPUT, e mantém esse salto em primeiro lugar. Os bloqueios, as listas de ameaças e os bloqueios por país dele valem, portanto, também para portas publicadas por containers. Se um reload do firewall remove o salto, o agente o coloca de volta.
• Ele fecha portas de banco de dados expostas, inclusive de containers. Um banco de dados publicado numa porta pública (MySQL, PostgreSQL, Redis, MongoDB e as outras portas de banco de dados, cache e administração que o agente conhece) pode ser fechado para a internet pelo painel, conferindo a porta que o cliente pediu. Loopback, redes privadas e a sua lista de permissões continuam com acesso, e a mudança é verificada e desfeita se o SSH ou um site parar de responder. Ele não fecha as portas 8000, 6001 e 6002 do próprio Coolify: faça isso como no passo 1.
• Ele lista os domínios das suas aplicações. A partir do agente 1.0.35 ele os lê, só em leitura, dos labels que o Coolify grava para o seu proxy (regras de roteador do Traefik ou endereços de site do Caddy), para você dar a cada site o selo de monitoramento, verificado com um registro DNS TXT. Ele nunca executa nada no container do proxy. O firewall web lê logs de acesso no formato common ou combined, por exemplo um indicado com o label infrafence.log-path; o proxy do Coolify grava logs JSON (só com a análise de tráfego ativada), que o agente não lê.
• Ele para a força bruta no SSH no firewall, dá uma pontuação de risco às sessões SSH e monitora tráfego de saída, DNS, malware e integridade de arquivos como em qualquer servidor Linux.
• Ele não atrapalha o ufw. As regras dele ficam nas próprias cadeias INFRAFENCE, e ele nunca altera as suas.

O agente não substitui os passos 1 a 5: criar a conta de administrador na hora, fechar a 8000 e manter o Coolify atualizado continuam sendo com você. O que o agente lê e envia está documentado por completo.