Ter um firewall instalado não significa estar protegido. Muitos servidores "com firewall" continuam vulneráveis porque as regras estão mal feitas. Os erros são quase sempre os mesmos, e qualquer um deles pode abrir a porta a um ataque. Aqui estão os sete mais comuns — e como evitá-los.
1. Deixar a base de dados acessível do exterior
É o erro mais grave e, infelizmente, dos mais frequentes. A porta da base de dados (MySQL, PostgreSQL e outras) nunca deve estar aberta à Internet. Quando está, qualquer atacante pode tentar ligar-se diretamente e, com uma password fraca ou uma vulnerabilidade, aceder a todos os dados. A base de dados deve ser acessível apenas localmente ou a partir de servidores específicos e de confiança.
2. SSH aberto ao mundo inteiro
O acesso administrativo via SSH é um alvo constante de ataques de força bruta. Deixá-lo aberto a qualquer endereço da Internet significa receber milhares de tentativas de login automáticas. O ideal é restringir o SSH a endereços IP de confiança e reforçá-lo com autenticação por chave (em vez de password) e ferramentas que bloqueiam tentativas repetidas.
3. Abrir portas "por precaução"
Há quem abra portas durante uma instalação ou teste e nunca mais as feche. Cada porta aberta que não corresponde a um serviço ativo e necessário é um risco gratuito. A regra é clara: se não há uma razão concreta para uma porta estar aberta, deve estar fechada. Menos portas, menos superfície de ataque.
4. Não definir uma política de negação por defeito
Um firewall bem configurado bloqueia tudo por defeito e abre apenas o necessário. O erro inverso — permitir tudo e bloquear caso a caso — é uma má prática: basta esquecer um serviço para o deixar exposto. A filosofia correta é "negar tudo, permitir o essencial", e não o contrário.
5. Esquecer o tráfego de saída
A maioria foca-se no que entra e ignora o que sai. Mas controlar o tráfego de saída é importante: se o servidor for comprometido, regras de saída restritivas podem impedir que o malware comunique com o exterior, exfiltre dados ou participe em ataques. É uma camada extra que muitos negligenciam.
6. Configurar e nunca mais rever
As necessidades de um servidor mudam: novos serviços, serviços removidos, novos endereços de confiança. Um firewall configurado uma vez e nunca mais revisto acumula regras obsoletas — portas abertas para serviços que já não existem, acessos permitidos a quem já não devia. A revisão periódica das regras é parte de uma boa manutenção de segurança.
7. Trancar-se a si próprio (e não ter plano B)
O reverso da medalha: ao apertar as regras, é fácil cortar o próprio acesso e ficar sem forma de entrar no servidor. Configurar firewall sem um mecanismo de reversão ou um acesso de emergência é arriscado — uma regra mal feita pode deixar o servidor inacessível e exigir intervenção ao nível do fornecedor de alojamento. Quem faz isto com método testa sempre as alterações com uma rede de segurança.
O padrão por trás de todos os erros
Reparando bem, quase todos estes erros nascem de duas atitudes: abrir de mais (por comodidade ou esquecimento) e não rever (configurar e abandonar). Um firewall não é um produto que se instala e esquece — é uma configuração viva que reflete as necessidades reais do servidor, mantida ao mínimo necessário e revista com regularidade. É essa disciplina, mais do que a ferramenta, que mantém um servidor protegido.
O seu firewall está mesmo a proteger o servidor?
A Vuvo audita e configura o firewall do seu servidor para fechar portas desnecessárias, proteger a base de dados e o acesso SSH, e manter as regras revistas. Segurança real, não apenas "firewall instalado".
Ver configuração de firewall Linux