Abertura da Página de Gestão
- Inicie sessão em KPanel.
- Clique em Servidores Cloud na barra lateral esquerda e depois clique no seu servidor.
- Clique em Gestão do servidor nos botões de ação no topo da página.
O endereço direto é /cloud-servers/<server-id>/management. A página descreve-se como "Firewall, patches do SO, fail2ban e ModSecurity. As alterações são aplicadas via SSH em segundos."
Se um aviso indicar "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", o painel não consegue aceder ao servidor neste momento. As suas definições continuam guardadas, apenas não são aplicadas ainda. Verifique se o servidor está em execução e acessível.
A Política de Firewall Padrão
A secção Firewall (UFW) apresenta a política numa linha: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
Na prática, isso significa:
- Nada consegue alcançar o seu servidor a partir da internet a menos que uma regra o permita.
- A porta 22 está sempre aberta, para que uma alteração do firewall nunca o possa bloquear da máquina.
- As portas que a sua pilha de aplicações necessita, como 80 e 443 para uma aplicação web, são abertas para si.
- O tráfego de saída do servidor não é restringido.
Sem regras personalizadas, a secção mostra "No custom rules. Defaults: SSH + app-stack ports." Este é um estado saudável, não uma configuração em falta.
Adição de uma Regra Personalizada
Adicione uma regra quando executar algo numa porta que a política padrão não cobre: uma aplicação Node na porta 3000, uma base de dados que precisa alcançar diretamente na porta 5432, um servidor de jogos ou multimédia numa porta UDP.
- Abra a secção Firewall (UFW).
- Digite o número da Port no primeiro campo. Os valores válidos são 1 a 65535.
- Escolha TCP ou UDP.
- Escolha Allow ou Deny.
- Clique em Add.
A regra aparece na lista com um emblema ALLOW ou DENY e a porta e protocolo, por exemplo 3000/tcp. É enviada para o servidor através da ligação de gestão em segundos.
Para remover uma regra, clique no X no final da sua linha. Remover uma regra Allow fecha essa porta novamente imediatamente.
Expor uma porta de base de dados para toda a internet é uma das formas mais comuns de um servidor ser comprometido. Antes de permitir 3306, 5432, 6379 ou 27017, pergunte-se se a coisa que se liga conseguiria alcançar a base de dados através da interface de loopback do próprio servidor ou de uma rede privada. Se genuinamente tem de ser acessível de fora, certifique-se de que o próprio serviço exige autenticação forte e encriptação.
Adicione a regra primeiro e depois inicie o serviço. Um serviço que arranca atrás de uma porta fechada parece quebrado exatamente da mesma forma que um serviço que falhou ao iniciar, e pode perder muito tempo a depurar a camada errada.
Stack de Aplicações
A secção Stack de aplicações diz à plataforma que tipo de aplicação este servidor executa, para que a predefinição de proteção possa ser ajustada a ela. Instalar uma aplicação através do painel define-o automaticamente para si.
As pilhas reconhecidas são WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web e No app stack. A secção explica-se como: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
A pilha afeta quais as portas que se abrem automaticamente e como as outras proteções são ajustadas, mais visivelmente no fail2ban.
fail2ban
O fail2ban observa tentativas de autenticação e bane endereços que continuam a falhar. Está ativado por padrão e a página descreve-o como: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
Mantenha-o ativado. É a proteção mais barata nesta página, não custa nada em desempenho e transforma o ruído de fundo constante de tentativas de adivinhação de passwords em nada. Num Stack WordPress ou WooCommerce também protege o formulário de login, que é onde a maioria dos ataques contra WordPress realmente aterram.
ModSecurity, o Firewall de Aplicação Web
O ModSecurity inspeciona pedidos HTTP contra o OWASP Core Rule Set e marca os que parecem ataques. Num servidor KapsuleHost começa em modo de detecção apenas: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
A detecção apenas é o ponto de partida correto. O Core Rule Set é minucioso e numa aplicação real alguns pedidos legítimos corresponderão a uma regra. Execute-o em detecção apenas durante um tempo, leia os registos, descubra quais as regras que o seu tráfego dispara e apenas depois mude para bloqueio dentro do servidor.
Ativar bloqueio sem ajustar primeiro pode quebrar o seu próprio site. Submissões de formulários com texto rico, uploads de ficheiros e clientes API com cargas úteis invulgares são as vítimas habituais. Verifique os seus registos antes de mudar.
Auto-Patches do SO
As atualizações de segurança são aplicadas para si. A secção explica a rede de segurança: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."
Duas definições encontram-se sob o botão:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). As atualizações de kernel apenas entram em vigor após um reinício. Se deixar isto desativado, os patches de kernel são instalados mas não estão ativos até que reinicie manualmente.
- Quiet window (UTC), uma hora de início e de fim. Os reinícios apenas ocorrem dentro dela. Defina-a para as horas mais tranquilas para o seu público e lembre-se de que o campo está em UTC, não na sua hora local.
Mantenha os auto-patches ativados. A grande maioria dos servidores comprometidos estão a executar software com um patch que foi publicado semanas antes. Um snapshot de pré-patch com reversão automática significa que a objeção usual, de que uma atualização pode quebrar algo, já está tratada.
Histórico de Patches e Execução de um Patch Agora
A secção Histórico de patches lista cada execução com um estado de RUNNING, SUCCESS, ROLLED_BACK, FAILED ou SKIPPED, o número de pacotes atualizados, se o servidor reiniciou e a hora em que começou.
Para corrigir imediatamente em vez de esperar pelo agendamento, clique em Executar patch agora. A confirmação lê: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."
Uma entrada ROLLED_BACK significa que a rede de segurança funcionou: o servidor não voltou limpo após um reinício, então o snapshot de pré-patch foi restaurado. Veja Snapshots de Servidor Cloud para saber como esses snapshots funcionam.
Uma Linha de Base Sensata
Para a maioria dos servidores, esta é toda a configuração de segurança:
| Definição | Recomendado |
|---|---|
| Firewall | Ativado, regras padrão, mais apenas as portas que a sua aplicação necessita |
| fail2ban | Ativado |
| ModSecurity | Ativado, detecção apenas até ter lido os registos |
| Auto-patches do SO | Ativado, com reinícios permitidos numa janela tranquila |
| Autenticação SSH | Chaves, não passwords |
A última linha não está nesta página mas importa mais do que o resto junto. Veja Ligação ao seu Servidor Cloud com SSH.
Resolução de Problemas
"Could not load management config." O painel não conseguiu ler as definições para este servidor. Recarregue e verifique se o servidor existe e está aprovisionado.
"Port must be 1-65535." O campo de porta aceita um número inteiro nesse intervalo. Intervalos e nomes de serviço não são aceites aqui.
A minha regra foi guardada mas nada mudou. Procure o aviso "Live apply unavailable". Se estiver a aparecer, a alteração está guardada mas ainda não foi enviada para o servidor.
Consigo alcançar o meu serviço de uma rede mas não de outra. Isso é normalmente o seu próprio firewall de saída, não o do servidor. Teste a partir de uma ligação diferente antes de alterar as regras aqui.
Uma execução de patch mostra FAILED. Leia a mensagem de erro na linha. Um disco completo é a causa mais comum. Liberte algum espaço e clique em Executar patch agora.
O tráfego legítimo começou a ser bloqueado. Se mudou ModSecurity para modo de bloqueio, mude-o de volta para detecção apenas, leia os registos e identifique a regra antes de tentar novamente.
Se uma regra de firewall se recusar a aplicar, ou se está bloqueado de um serviço que permitiu, envie um email para support@kapsulehost.com com o nome do servidor, a porta e o que espera alcançar.