Servidores cloud
Gerenciamento de Firewall e Segurança do Cloud Server
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
Gestão de Firewall e Segurança do Cloud Server
Cada KapsuleHost Server vem equipado com um firewall gerenciado que nega tráfego de entrada por padrão, além de proteção contra força bruta, firewall de aplicação web e patches de segurança automáticos, tudo controlado de uma única página no KPanel.
Os padrões são escolhidos para que um servidor novo esteja seguro antes de você fazer qualquer alteração. O que você adiciona depois é geralmente apenas as portas que sua aplicação precisa. Este guia percorre toda a página Server management, porque o firewall é uma seção dela e as outras seções são o que evita que você precise do firewall em primeiro lugar.
Abrindo a Página de Gestão
- Entre no KPanel.
- Clique em Cloud Servers na barra lateral esquerda e, em seguida, clique em seu servidor.
- Clique em Management nos botões de ação no topo da página.
O endereço direto é /cloud-servers/<server-id>/management. A página se descreve como "Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."
Se um banner exibir "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately", o painel não consegue alcançar o servidor no momento. Suas configurações ainda são salvas, apenas não são aplicadas ainda. Verifique se o servidor está em execução e alcançável.
A Política de Firewall Padrão
A seção Firewall (UFW) declara a política em uma linha: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."
Na prática, isso significa:
- Nada pode alcançar seu servidor pela internet a menos que uma regra permita.
- A porta 22 está sempre aberta, então uma mudança no firewall nunca pode bloquear você fora da máquina.
- As portas que sua pilha de aplicações precisa, como 80 e 443 para uma aplicação web, são abertas para você.
- O tráfego de saída do servidor não é restringido.
Sem regras personalizadas, a seção exibe "No custom rules. Defaults: SSH + app-stack ports." Esse é um estado saudável, não uma configuração ausente.
Adicionando uma Regra Personalizada
Adicione uma regra quando você executa algo em uma porta que a política padrão não cobre: uma aplicação Node na porta 3000, um banco de dados que você precisa alcançar diretamente na 5432, um servidor de jogos ou mídia em uma porta UDP.
- Abra a seçã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 badge ALLOW ou DENY e a porta e o protocolo, por exemplo 3000/tcp. É enviada ao servidor pela conexão de gestão dentro de segundos.
Para remover uma regra, clique no X no final de sua linha. Remover uma regra Allow fecha a porta novamente imediatamente.
Expor uma porta de banco 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 o que está se conectando poderia alcançar o banco de dados pela interface de loopback do próprio servidor ou por uma rede privada. Se genuinamente deve ser alcançável de fora, certifique-se de que o serviço em si exige autenticação forte e criptografia.
Adicione a regra primeiro, depois inicie o serviço. Um serviço que sobe atrás de uma porta fechada parece quebrado exatamente da mesma forma que um serviço que falhou ao iniciar, e você pode gastar muito tempo depurando a camada errada.
App Stacks
A seção App stack informa à plataforma que tipo de aplicação este servidor executa, para que a predefinição de hardening possa ser ajustada a ela. Instalar uma aplicação através do painel a define para você.
As pilhas reconhecidas são WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, Generic web, e No app stack. A seção se explica como: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."
A pilha afeta quais portas se abrem automaticamente e como as outras proteções são ajustadas, mais visivelmente no fail2ban.
fail2ban
fail2ban monitora tentativas de autenticação e bane endereços que continuam falhando. Está ativado por padrão e a página o descreve como: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."
Deixe-o ativado. É a proteção mais barata da página, não custa nada em desempenho, e transforma um ruído de fundo constante de tentativas de adivinhação de senha em nada. Em uma pilha WordPress ou WooCommerce, também protege o formulário de login, que é onde a maioria dos ataques contra WordPress realmente ocorre.
ModSecurity, o Firewall de Aplicação Web
ModSecurity inspeciona solicitações HTTP contra o OWASP Core Rule Set e sinaliza as que parecem ataques. Em um servidor KapsuleHost, inicia em modo detection-only: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."
Detection-only é o ponto de partida certo. O Core Rule Set é minucioso, e em uma aplicação real, algumas solicitações legítimas corresponderão a uma regra. Execute-o em detection-only por um tempo, leia os logs, descubra quais regras seu próprio tráfego dispara e apenas então mude para bloqueio dentro do servidor.
Ativar o bloqueio sem sintonização prévia pode quebrar seu próprio site. Envios de formulários com texto rico, uploads de arquivo e clientes de API com cargas úteis incomuns são as vítimas usuais. Verifique seus logs antes de mudar.
Patches Automáticos do SO
Atualizações de segurança são aplicadas para você. A seçã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 configurações ficam sob o botão de alternância:
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). Atualizações de kernel só entram em vigor após uma reinicialização. Se você deixar isso desativado, patches de kernel são instalados mas não ativados até que você reicialize você mesmo.
- Quiet window (UTC), uma hora de início e fim. As reinicializações ocorrem apenas dentro dela. Defina-a para as horas mais tranquilas para seu público e lembre-se de que o campo está em UTC, não em sua hora local.
Deixe o auto-patching ativado. A grande maioria dos servidores comprometidos executa software com um patch que foi publicado semanas antes. Um snapshot pré-patch com rollback automático significa que a objeção usual, que uma atualização pode quebrar algo, já é tratada.
Histórico de Patches e Executar um Patch Agora
A seção Patch history lista cada execução com um status de RUNNING, SUCCESS, ROLLED_BACK, FAILED ou SKIPPED, o número de pacotes atualizados, se o servidor foi reinicializado e a hora de início.
Para fazer patch imediatamente em vez de esperar o cronograma, clique em Run patch now. 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 fez seu trabalho: o servidor não retornou corretamente após uma reinicialização, então o snapshot pré-patch foi restaurado. Veja Cloud Server Snapshots para como esses snapshots funcionam.
Uma Linha de Base Sensata
Para a maioria dos servidores, esta é a configuração de segurança completa:
| Configuração | Recomendado |
|---|---|
| Firewall | Ativado, regras padrão, além apenas das portas que sua aplicação precisa |
| fail2ban | Ativado |
| ModSecurity | Ativado, detection-only até você ter lido os logs |
| OS auto-patching | Ativado, com reinicializações permitidas em uma janela tranquila |
| Autenticação SSH | Chaves, não senhas |
A última linha não está nesta página mas importa mais que o resto combinado. Veja Connecting to Your Cloud Server With SSH.
Troubleshooting
"Could not load management config." O painel não conseguiu ler as configurações para este servidor. Recarregue e verifique se o servidor existe e está provisionado.
"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 aceitos aqui.
Minha regra foi salva mas nada mudou. Procure pelo banner "Live apply unavailable". Se está sendo exibido, a mudança é armazenada mas ainda não foi enviada ao servidor.
Consigo alcançar meu serviço de uma rede, mas não de outra. Isso geralmente é seu próprio firewall de saída, não o do servidor. Teste de uma conexão diferente antes de alterar regras aqui.
Uma execução de patch mostra FAILED. Leia a mensagem de erro na linha. Um disco cheio é a causa mais comum. Libere espaço e clique em Run patch now.
O tráfego legítimo começou a ser bloqueado. Se você mudou o ModSecurity para modo de bloqueio, coloque-o de volta em detection-only, leia os logs e identifique a regra antes de tentar novamente.
Se uma regra de firewall se recusa a ser aplicada, ou você 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 você espera alcançar.