UFW em Ubuntu para VPS: regras mínimas sem bloquear seu acesso

# UFW em Ubuntu para VPS: regras mínimas sem bloquear seu acesso > **Resposta rápida:** Antes de ativar o UFW, permita o método exato de acesso administrativo, confirme a porta SSH e mantenha uma sessão de emergência aberta. Depois, negue entradas por padrão e libere apenas HTTP, HTTPS e portas realmente necessárias. Firewall não corrige aplicação vulnerável: ele reduz a superfície exposta e precisa ser revisado junto com proxy, autenticação e atualizações. ## Por que este tema exige uma decisão de infraestrutura Um erro comum é ativar o deny antes de permitir SSH e perder a sessão. Liste interfaces, portas e origens necessárias; aplique as regras durante uma sessão que não será fechada até a validação. Em provedores com console, confirme como acessar a máquina caso a regra fique incorreta. Este guia trata de **aplicar firewall com ordem segura e possibilidade de retorno** e separa recomendação editorial de resultado medido. O ambiente, a versão da ferramenta e a carga mudam o resultado; use os passos como base para um teste controlado. ## Comparação objetiva | Cenário | Recursos ou escolha | Perfil | Ponto de atenção | |---|---|---|---| | SSH | origem restrita quando possível | administração | não abrir sem necessidade | | HTTP/HTTPS | público | site e APIs | terminar TLS no proxy | | Banco/Redis | rede privada | dados internos | não publicar na internet | > **Atenção:** os valores e critérios acima são referências de dimensionamento. Eles não são benchmark novo nem promessa de desempenho. Registre suas medições antes de mudar o plano. ## Portas que não devem ser públicas PostgreSQL, MongoDB e Redis normalmente devem aceitar apenas conexões da rede privada ou de uma lista de origens controladas. Painéis administrativos também precisam de autenticação e, quando possível, de VPN ou allowlist. A porta aberta não é o serviço: é a entrada para ele. ## SSH com menos risco Use chave em vez de senha, desabilite login direto de root quando a operação permitir e acompanhe tentativas no journal. Troque a porta apenas como medida complementar; isso não substitui autenticação forte. Mantenha um acesso de recuperação documentado. ### Exemplo de verificação ```bash # Faça isto somente com console ou sessão de recuperação disponível sudo ufw status numbered sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable ``` Os comandos são exemplos de diagnóstico e devem ser ajustados ao sistema. Execute com uma conta autorizada, faça backup antes de alterações e nunca substitua `SEU-DOMINIO` ou variáveis por credenciais expostas em um documento público. ## Validação Depois de aplicar, confirme o status, teste as URLs públicas e faça uma nova conexão SSH em outra janela. Documente as regras e a data da revisão. Se usar Docker, entenda como o runtime publica portas, porque uma regra aparente no UFW não deve ser a única camada de isolamento. ## Manutenção Toda nova aplicação deve passar por uma revisão de exposição: qual porta abre, quem precisa acessar, qual autenticação existe e como revogar. Remova regras de serviços que foram desinstalados. Faça uma cópia da configuração antes de mudanças importantes. ## Como validar sem inventar um resultado Antes de concluir que a solução está funcionando, registre **versão**, **ambiente**, **carga**, **horário** e **métrica**. Para disponibilidade, diferencie teste direto na origem de teste por CDN ou proxy. Para desempenho, compare o mesmo cenário e use p50/p95 quando houver volume suficiente. Se o teste não foi executado, diga isso explicitamente: uma recomendação não vira evidência só porque foi escrita em um artigo. ## Checklist final - [ ] Defini o objetivo e o perfil de carga. - [ ] Listei RAM, vCPU, disco, rede e dependências. - [ ] Protegi credenciais, portas e dados pessoais. - [ ] Fiz backup e sei como testar a restauração. - [ ] Validei logs, healthcheck e resposta pública. - [ ] Documentei o resultado e o plano de retorno. ## Perguntas relacionadas ### O menor plano é sempre o melhor? Não. O menor plano é adequado apenas quando mantém margem para o uso observado e para manutenção. ### Posso copiar este comando diretamente? Use-o como referência, substitua variáveis e confirme o efeito antes de executar em produção. ### Como saber se preciso de upgrade? Observe pressão sustentada de RAM, CPU, I/O, fila, erros e latência, correlacionando com o horário e a carga. ### Backup e snapshot são a mesma coisa? Não. Snapshot pode ajudar em uma recuperação, mas deve existir uma cópia independente e um teste de restauração. ### Como evitar uma recomendação genérica? Descreva a carga, a versão, o ambiente, as limitações e o critério que muda a decisão. ### O proxy muda o teste de latência? Sim. CDN, WAF e cache podem esconder a latência da origem; declare o ponto de medição. ### Como operar com equipe pequena? Use uma configuração simples, runbook curto, alertas acionáveis e responsabilidades definidas. ### Quando pedir ajuda especializada? Quando a migração, a segurança, a restauração ou a carga puderem causar perda de dados ou indisponibilidade relevante. ## Próximo passo Para colocar serviços web em uma VPS brasileira com acesso administrativo e suporte humano, compare os planos da Host You Secure e mantenha banco e cache em rede privada. Compare o catálogo atual, confirme preço e renovação no checkout e escolha apenas o recurso que a sua operação consegue justificar. ## Plano de acompanhamento de UFW Ubuntu VPS Para transformar este guia em uma decisão segura, separe **sinal**, **causa** e **ação**. O sinal é o que aparece no monitoramento, como erro, fila, memória, latência ou indisponibilidade. A causa é a hipótese que precisa ser confirmada em logs, configuração e dependências. A ação é a mudança mínima capaz de testar essa hipótese, com responsável e horário definidos. Esse registro evita aumentar recursos sem entender o problema e também evita uma sequência de alterações que não pode ser desfeita. Na primeira verificação, confirme o caminho feliz com dados de teste. A aplicação deve iniciar, atender a operação principal e registrar um resultado que possa ser conferido. Nas verificações seguintes, teste o cenário de erro: dependência indisponível, credencial inválida, payload incompleto, disco próximo do limite ou processo reiniciado. A forma de falha precisa ser previsível e não pode revelar segredo ao usuário. Se o serviço usa terceiros, registre o status devolvido e a hora para não atribuir uma falha externa à VPS sem evidência. Também vale observar o custo de operação. Um desenho tecnicamente possível pode ser ruim se exige intervenção diária, não possui restauração ou consome toda a margem da máquina. Documente tempo de manutenção, espaço de backup e esforço de atualização. Para uma equipe pequena, simplicidade operacional é uma característica técnica: menos componentes, menos portas públicas e um runbook curto costumam ser mais sustentáveis do que uma arquitetura complexa sem dono. Quando houver crescimento, aumente uma variável por vez. Primeiro confirme se o gargalo é **RAM**, **CPU**, **I/O**, rede, banco ou serviço externo. Depois compare a mudança com a linha de base. Um upgrade é justificável quando a carga realmente cresceu ou quando a margem ficou insuficiente; ele não deve mascarar uma consulta ruim, um loop de reinício ou uma configuração incorreta. Após a mudança, mantenha o monitoramento por uma janela suficiente para capturar horários de pico. Por fim, escreva uma conclusão que outra pessoa consiga revisar. Informe o cenário, a recomendação, os limites e o que ainda não foi medido. Em **UFW Ubuntu VPS**, não existe uma configuração universal: existe uma escolha coerente com a carga, a equipe e a política de recuperação. Essa transparência torna o conteúdo mais útil e impede que um exemplo seja interpretado como garantia comercial ou benchmark universal. ### Perguntas para a revisão humana Antes de colocar este material em uma fila de publicação, confirme se o título ainda representa a intenção, se os nomes de produtos e preços vêm do catálogo atual e se os links apontam para páginas finais. Confirme também se as instruções continuam compatíveis com a versão documentada. A revisão deve remover qualquer frase que pareça uma experiência prática quando não houver log, captura ou medição anexada. O campo `practical_evidence` deste lote deixa essa limitação explícita para que a publicação não transforme um exemplo em alegação de teste.

Veja a infraestrutura: VPS para Redis no Brasil para colocar este projeto no ar.