Uma VPS WordPress normalmente precisa receber tráfego público apenas nas portas usadas pelo site. O acesso administrativo deve ser restrito e serviços como banco de dados não devem ficar expostos sem uma necessidade técnica bem definida.
Na prática, o firewall reduz a superfície de ataque da VPS. Ele não corrige plugins vulneráveis nem substitui atualizações, backups ou senhas fortes. Sua função é impedir que conexões desnecessárias cheguem aos serviços do servidor.
Este guia mostra como planejar essa proteção em uma VPS na LetsCloud sem aplicar regras no escuro. Os comandos e nomes dos serviços podem variar conforme a distribuição Linux e a configuração escolhida.
O que o firewall protege em uma VPS WordPress
Uma instalação WordPress pode envolver servidor web, PHP, banco de dados, acesso SSH, serviço de arquivos, painel de administração e ferramentas de monitoramento. Nem todos esses componentes precisam aceitar conexões vindas da internet.
O firewall trabalha antes da camada do WordPress. Ele decide quais conexões podem entrar ou sair com base em fatores como porta, protocolo, endereço de origem e endereço de destino.
Considere um site institucional em uma única VPS. O Nginx ou Apache recebe visitantes. O banco de dados funciona na mesma máquina. Nesse cenário, a internet precisa alcançar o servidor web, mas não precisa conversar diretamente com MySQL ou MariaDB.
A proteção ainda deve ser complementada dentro da aplicação. Depois de cuidar da rede, veja também como proteger o login do WordPress e como revisar os cabeçalhos de segurança HTTP.
O que preparar antes de alterar qualquer regra
Não ative um firewall sem confirmar como você acessa a VPS. Uma regra incorreta pode bloquear o SSH e exigir recuperação pelo console ou suporte da infraestrutura.
Antes de começar:
- Confirme o endereço IP público da VPS.
- Descubra qual porta o serviço SSH utiliza.
- Identifique se seu endereço de internet é fixo ou muda com frequência.
- Liste os serviços que realmente recebem conexões externas.
- Mantenha uma segunda sessão SSH aberta durante o teste.
- Verifique se existe acesso por console fora da rede.
- Faça backup dos dados e registre as regras atuais.
O comando sudo ss -lntup ajuda a identificar serviços em escuta. Já sudo ufw status verbose mostra o estado do UFW quando essa ferramenta está instalada. Não copie uma regra pronta antes de comparar a porta indicada com a configuração real do servidor.
Também vale revisar a rotina de backup automático WordPress na LetsCloud. O backup não evita o bloqueio de acesso, mas reduz o impacto de uma alteração que exija restauração.
Quais portas devem ficar acessíveis
Para uma configuração comum, a decisão pode seguir estes critérios:
- Porta 80 TCP: recebe HTTP e costuma ser necessária para redirecionar visitantes para HTTPS ou executar algumas validações de certificado.
- Porta 443 TCP: recebe HTTPS e deve ficar pública quando o site usa conexão segura.
- Porta SSH: deve ficar aberta somente na porta realmente configurada. Quando possível, restrinja a origem a um endereço administrativo confiável.
- Porta 3306: usada normalmente por MySQL ou MariaDB. Não deve ficar pública quando o banco está na mesma VPS do WordPress.
- Portas de painéis: libere apenas se o painel realmente precisar de acesso remoto. Prefira restringir por endereço IP ou por uma rede privada.
- Portas de monitoramento: devem aceitar apenas as origens que coletam métricas.
Uma loja ou site institucional não precisa expor a porta do banco apenas porque usa WordPress. Se aplicação e banco estiverem em servidores separados, prefira comunicação por rede privada. Quando isso não for possível, restrinja a origem ao endereço exato do servidor de aplicação e considere criptografia na conexão.
Não esqueça do IPv6. Uma VPS pode estar protegida no IPv4 e continuar acessível por IPv6 se as regras não cobrirem os dois protocolos.
Como configurar o firewall sem perder o acesso à VPS
O UFW é uma interface comum para administrar regras de firewall em distribuições baseadas em Ubuntu. Se a VPS usar outra distribuição ou uma ferramenta diferente, adapte o procedimento.
Comece verificando a porta SSH em uso. Se ela for a porta 22, a regra pode permitir 22/tcp. Se for outra, use o número real. Para uma equipe com endereço fixo, uma regra restrita à origem administrativa reduz a exposição.
Em seguida, libere o tráfego web necessário. As regras devem permitir as portas 80 e 443 em TCP. Só depois dessas liberações o bloqueio padrão de conexões recebidas deve ser ativado.
A sequência segura é:
- Registrar as regras existentes.
- Liberar a porta SSH correta.
- Liberar HTTP e HTTPS.
- Definir o bloqueio padrão para novas conexões recebidas.
- Manter conexões de saída permitidas, salvo política técnica diferente.
- Ativar o firewall.
- Testar uma nova sessão SSH sem fechar a sessão atual.
Após a ativação, abra outro terminal e tente entrar novamente. Se o novo acesso funcionar, mantenha os dois terminais abertos enquanto valida o site. Se não funcionar, corrija a regra pela sessão antiga.
Restringir o SSH a um único IP pode não servir para profissionais que usam internet móvel ou endereço dinâmico. Nesse caso, avalie uma VPN administrativa, uma rede privada ou uma faixa de origem controlada. Liberar SSH para qualquer origem pode ser necessário em alguns ambientes, mas exige autenticação por chave, bloqueio de acesso direto como root e monitoramento de tentativas.
Como combinar a proteção da LetsCloud com o firewall do servidor
Na LetsCloud, a VPS representa o ambiente onde a aplicação e os serviços serão executados. Se o recurso contratado oferecer controle de firewall na camada de rede, ele pode filtrar tráfego antes que a conexão chegue ao sistema operacional. Confirme a disponibilidade e o funcionamento no painel ou na documentação vigente da plataforma antes de depender desse recurso.
Quando houver proteção na rede e no sistema operacional, mantenha regras coerentes nas duas camadas. Não adianta liberar uma porta no UFW se ela continua bloqueada antes de chegar à VPS. O contrário também merece atenção: uma porta autorizada na camada de rede ainda deve ser recusada pelo servidor quando não for necessária.
Documente cada liberação com três informações: serviço, origem permitida e motivo. Uma regra chamada apenas de temporária costuma permanecer ativa por meses porque ninguém sabe se ainda pode removê la.
A capacidade da VPS também deve acompanhar a arquitetura escolhida. O guia sobre como dimensionar uma VPS WordPress na LetsCloud ajuda a separar necessidades de processamento, memória e armazenamento das decisões de segurança de rede.
Como validar as regras depois da configuração
A validação deve ocorrer de dentro e de fora da VPS.
Dentro do servidor, confirme quais serviços estão escutando com sudo ss -lntup. Depois, compare essa lista com as regras ativas. Um serviço pode estar em execução mesmo quando o firewall impede o acesso externo.
Fora da VPS, teste:
- A abertura do site em HTTP.
- O redirecionamento para HTTPS, se estiver configurado.
- A abertura do site em HTTPS.
- Uma nova conexão SSH pela origem administrativa.
- O acesso pelo endereço IPv6, quando disponível.
- As páginas públicas e o painel do WordPress.
- O envio de formulários e tarefas que dependam de serviços externos.
Também verifique os registros do firewall. Uma sequência de bloqueios pode revelar tentativas automatizadas, mas nem todo registro representa uma invasão. Evite criar alertas para cada pacote recusado. Prefira observar padrões, origens recorrentes e portas inesperadas.
Erros que deixam a VPS exposta ou inacessível
O erro mais perigoso para a operação é ativar o bloqueio de entrada antes de liberar o SSH. A consequência pode ser a perda imediata do acesso remoto.
Outros problemas frequentes incluem:
- Liberar todas as portas para resolver um teste temporário.
- Expor MySQL ou MariaDB para qualquer endereço.
- Proteger IPv4 e esquecer IPv6.
- Abrir um painel administrativo sem restrição de origem.
- Manter regras antigas depois de remover um serviço.
- Confiar apenas em um plugin de segurança.
- Bloquear conexões de saída sem mapear atualizações, APIs e envio de mensagens.
- Fechar a porta 80 sem verificar renovação de certificado e redirecionamentos.
Outro equívoco é tratar o firewall como proteção completa. Uma requisição permitida pela porta 443 ainda pode explorar uma falha no WordPress, no tema ou em um plugin. Atualizações e controle de usuários continuam necessários.
Checklist final para revisar o firewall
Antes de encerrar a manutenção, confirme:
- O site abre em HTTPS.
- O redirecionamento de HTTP funciona como esperado.
- Uma nova sessão SSH pode ser iniciada.
- A porta SSH corresponde à configuração real.
- O banco de dados não está acessível publicamente sem necessidade.
- Painéis e serviços internos têm origem restrita.
- IPv4 e IPv6 seguem políticas equivalentes.
- As regras da infraestrutura e do sistema não entram em conflito.
- Existe um registro do motivo de cada porta liberada.
- O backup foi verificado antes da mudança.
- A equipe sabe como recuperar o acesso pelo console.
Guarde esse registro junto ao inventário técnico do site. Revise as regras quando instalar um painel, separar o banco em outra máquina, alterar o servidor web ou criar uma integração externa.
Perguntas frequentes
Quais portas precisam ficar abertas para um site WordPress?
Na configuração mais comum, as portas públicas são 80 para HTTP e 443 para HTTPS. A porta SSH também precisa ser acessível pela equipe, preferencialmente com origem restrita. Outras portas dependem da arquitetura.
Posso bloquear a porta 80 e usar apenas HTTPS?
É possível em alguns ambientes, mas isso pode afetar redirecionamentos e certos métodos de validação de certificado. Confirme como o certificado é emitido e renovado antes de bloquear a porta.
O banco de dados deve aceitar conexões externas?
Não quando WordPress e banco funcionam na mesma VPS. Em arquiteturas separadas, limite a conexão a uma rede privada ou ao endereço exato do servidor autorizado.
Um plugin de segurança substitui o firewall da VPS?
Não. O plugin atua dentro do WordPress. O firewall da VPS controla conexões antes que elas alcancem a aplicação. As duas camadas têm funções diferentes.
Como recuperar o acesso depois de bloquear a porta SSH?
Use o console disponibilizado pela infraestrutura ou solicite suporte conforme o plano contratado. Depois, corrija a regra e teste uma nova sessão antes de fechar o console. Por isso, o acesso de recuperação deve ser confirmado antes da mudança.
Próximo passo para proteger o WordPress
Depois de limitar as portas, revise os serviços ativos e remova o que não é usado. Em seguida, proteja o login, mantenha WordPress e extensões atualizados e teste a restauração do backup.
O firewall deve ser tratado como uma configuração documentada e revisável. Ele ajuda a reduzir exposição, mas funciona melhor quando faz parte de uma rotina que inclui atualização, backup, monitoramento e controle de acesso.
