# Gestão de Firewall e Segurança do Cloud Server Source: https://support.kapsulehost.com/pt-pt/cloud-servers-firewall ## Abertura da Página de Gestão 1. Inicie sessão em [KPanel](https://kpanel.kapsulehost.com). 2. Clique em **Servidores Cloud** na barra lateral esquerda e depois clique no seu servidor. 3. Clique em **Gestão do servidor** nos botões de ação no topo da página. O endereço direto é `/cloud-servers//management`. A página descreve-se como "Firewall, patches do SO, fail2ban e ModSecurity. As alterações são aplicadas via SSH em segundos." ![A página Gestão do servidor para um servidor cloud em KPanel](https://support.kapsulehost.com/help/screenshots/cloud-servers-firewall.d05a26ce.webp) > **Note:** 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. 1. Abra a secção **Firewall (UFW)**. 2. Digite o número da **Port** no primeiro campo. Os valores válidos são 1 a 65535. 3. Escolha **TCP** ou **UDP**. 4. Escolha **Allow** ou **Deny**. 5. 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. > **Warning:** 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. > **Tip:** 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. > **Warning:** 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. > **Tip:** 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](https://support.kapsulehost.com/pt-pt/cloud-servers-snapshots) 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](https://support.kapsulehost.com/pt-pt/cloud-servers-ssh-connect). ## 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](mailto:support@kapsulehost.com) com o nome do servidor, a porta e o que espera alcançar.