No momento em que virou ‘meu servidor’, tudo virou minha responsabilidade
Na última vez, eu superei a barreira do CLI do Linux e das permissões (Permission). chmod, chown e até o proibido chmod 777. Já tinha pegado o jeito do controle de acesso a arquivos.
Mas, naquela época, eu cometia um grande engano. Achava que, bastava gerenciar bem as ‘permissões de arquivo’ que o servidor estaria seguro.
“Segurança de servidor? Isso não é coisa do time de segurança?”
Em uma empresa grande, pode ser. Mas eu sou um dev solo. Administrador de servidor, responsável por segurança, engenheiro de rede — tudo era ‘eu’. Toda a responsabilidade pela segurança estava nos meus ombros.
E o que me fez perceber isso foi um log de acesso ao servidor que encontrei numa certa segunda de manhã.
A crise: alguém estava batendo na porta do meu servidor
Segunda de manhã, enquanto eu conectava ao servidor por SSH por hábito e conferia os logs, vi algo estranho.
# Conferir registros recentes de falha de login SSH
$ grep "Failed password" /var/log/auth.log | tail -20
Quando olhei o log na tela, me arrepiei.
Feb 10 03:14:22 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:25 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:27 sshd: Failed password for admin from 185.220.xx.xx
Feb 10 03:14:30 sshd: Failed password for ubuntu from 185.220.xx.xx
...
Centenas de tentativas de login desde as 3 da manhã. IP do exterior. O nome da conta ia se alternando entre root, admin, ubuntu. Era alguém rodando um ‘programa automatizado (bot)’ fazendo força bruta (Brute Force) nas senhas.
“Ué? Eu ainda não fui hackeado, né…?”
Por sorte não foi invadido. Mas dá pra olhar pra um ladrão testando chave por chave na sua porta e dizer “tá tudo bem porque não abriu”? Fui imediatamente checar a segurança do servidor.
Etapa 1: trancar a porta de entrada — reforço do SSH
A porta de entrada do servidor é o SSH (Secure Shell). É exatamente por ele que eu entro no servidor. O problema é que o hacker quer entrar pela mesma porta. O primeiro passo é reforçar essa porta.
Mudar a porta do SSH (padrão 22 → outro número)
A porta padrão do SSH é a 22. Os scanners automáticos dos hackers batem primeiro na 22. Só de trocar o número da porta, dá pra filtrar mais de 90% dos ataques de força bruta.
# Abrir o arquivo de configuração do SSH
$ sudo vi /etc/ssh/sshd_config
# Mudar o número da porta (padrão 22 → ex.: 2222)
Port 2222
# Reiniciar o serviço SSH
$ sudo systemctl restart sshd
Fazendo uma analogia: o ladrão costuma mirar na porta da frente do térreo (22). Se você muda a entrada para uma porta do 3º andar no telhado (2222), a maioria dos ladrões nem acha onde é a porta.
Bloquear login direto com a conta root
Pelo log dá pra ver que a primeira conta que os hackers tentam é ‘root’. Root é a conta de super administrador do Linux — se quebrarem ela, dominam o servidor inteiro.
# Bloquear o login direto como root no arquivo de configuração do SSH
$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
Agora é impossível acessar via SSH como root. Você entra com uma conta comum e, quando precisa, sobe as permissões com sudo.
Autenticação por chave SSH em vez de senha
Por mais complexa que seja a senha, um programa automatizado tentando milhares de combinações pode quebrar um dia. O jeito mais seguro é desativar o login por senha e só permitir acesso com ‘chave SSH (Key)’.
# Gerar o par de chaves SSH no meu computador (local)
$ ssh-keygen -t rsa -b 4096
# Copiar a chave pública para o servidor
$ ssh-copy-id -p 2222 user@my-server-ip
# Desativar o login por senha no servidor
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
A autenticação por chave SSH não é ‘uma chave’, é ‘reconhecimento de digital’. Senha (chave) pode ser copiada, mas a chave privada (digital) que só existe no meu computador é praticamente impossível de duplicar.
Etapa 2: levantar o muro — Firewall
Reforçada a porta de entrada (SSH), é hora de cercar o prédio e controlar quem entra. Isso é o ‘Firewall’.
Um servidor tem 65.535 portas (entradas) no total. Sem firewall, é como se essas 60 mil portas estivessem todas abertas. Você tem que abrir só as necessárias e trancar o resto.
A ferramenta de firewall mais fácil no Linux é o ‘UFW (Uncomplicated Firewall)’.
# Ativar o UFW
$ sudo ufw enable
# Política padrão: bloquear todo tráfego de entrada, permitir saída
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
# Abrir só as portas necessárias
$ sudo ufw allow 2222/tcp # SSH (porta alterada)
$ sudo ufw allow 80/tcp # HTTP
$ sudo ufw allow 443/tcp # HTTPS
# Verificar o estado atual do firewall
$ sudo ufw status
| Porta | Uso | Aberta? |
|---|---|---|
| 2222 | SSH (porta alterada) | ✅ Permitida |
| 80 | HTTP (web) | ✅ Permitida |
| 443 | HTTPS (web segura) | ✅ Permitida |
| 22 | SSH (padrão, não usada mais) | ❌ Bloqueada |
| Demais | Todas | ❌ Bloqueadas |
Das 60 mil portas, só 3 ficaram abertas e o resto foi tapado com tijolo. A porta pra o ladrão bater simplesmente sumiu.
Etapa 3: criptografar a comunicação — HTTPS
Se o servidor oferece algum serviço web, a comunicação entre usuário e servidor também precisa de proteção. Isso é o ‘HTTPS’.
HTTP envia os dados tipo ‘cartão-postal’, sem envelope. Qualquer um no meio pode espiar o conteúdo. HTTPS envia os dados dentro de uma ‘carta selada’. Mesmo que interceptem, ninguém consegue ler.
Se o usuário digita login/senha num formulário e isso vai por HTTP? Qualquer pessoa no mesmo Wi-Fi de um café pode ver o conteúdo na íntegra.
Na prática, o jeito mais fácil de aplicar HTTPS é emitindo um certificado SSL gratuito pelo ‘Let’s Encrypt’.
# Instalar o Certbot (ferramenta de automação do Let's Encrypt)
$ sudo apt install certbot python3-certbot-nginx
# Emitir o certificado e aplicar automaticamente no Nginx
$ sudo certbot --nginx -d mydomain.com
# Testar a renovação automática (o certificado precisa ser renovado a cada 90 dias)
$ sudo certbot renew --dry-run
Com essas poucas linhas de comando, o endereço do meu serviço muda de http:// para https:// e o cadeado aparece na barra do navegador. É passar pro usuário a confiança de que “este site é seguro”.
Etapa 4: sistema de defesa automática — Fail2Ban
Mesmo mudando a porta do SSH e configurando autenticação por chave, existem bots teimosos no mundo. Com certeza há quem ache a porta alterada e tente acessar.
Nessas horas, o ‘Fail2Ban’ é útil. É uma ferramenta que bloqueia automaticamente qualquer IP que falhe o login uma certa quantidade de vezes.
# Instalar o Fail2Ban
$ sudo apt install fail2ban
# Configurar proteção do SSH
$ sudo vi /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
| Configuração | Significado |
|---|---|
| maxretry = 5 | Se errar 5 vezes |
| bantime = 3600 | Bloqueia esse IP por 1 hora |
| findtime = 600 | Aplica quando der 5 falhas em até 10 minutos |
# Iniciar o Fail2Ban
$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
# Ver os IPs bloqueados no momento
$ sudo fail2ban-client status sshd
Fail2Ban é a ‘câmera + tranca automática’ colocada em frente à porta. Se alguém suspeito erra a senha várias vezes, o acesso é automaticamente proibido.
Dica prática: checklist de segurança
Organizo em checklist tudo que configuramos até aqui. Toda vez que subir um servidor novo, siga essa lista e você já tem a proteção básica montada.
| # | Item | Comando/Config |
|---|---|---|
| 1 | Mudar porta do SSH | Port 2222 in sshd_config |
| 2 | Bloquear login de root | PermitRootLogin no |
| 3 | Mudar para autenticação por chave SSH | PasswordAuthentication no |
| 4 | Ativar firewall | ufw enable, abrir só as portas necessárias |
| 5 | Aplicar HTTPS | Let’s Encrypt + Certbot |
| 6 | Instalar Fail2Ban | Bloqueio automático de IP em falhas de login |
| 7 | Atualizações periódicas | sudo apt update && sudo apt upgrade |
O item 7 é surpreendentemente importante. Vulnerabilidades de segurança são descobertas todo dia. De nada adianta firewall se o próprio sistema operacional ou o software têm brechas. Atualização periódica é a medida de segurança mais básica e também a mais eficaz.
Para encerrar: segurança não é algo especial, é hábito
No começo, a palavra segurança me parecia grandiosa. Defesa contra hacking, detecção de intrusão, criptografia… Parecia coisa de filme.
Mas, fazendo na prática, vi que não precisa de uma mega tecnologia. Mudar a porta do SSH, ligar o firewall, configurar a autenticação por chave, instalar o Fail2Ban. Resolvia com umas poucas linhas de comando. O importante não era ‘saber’, era ‘executar’.
Incidentes de segurança não acontecem por causa de técnicas sofisticadas de hacking, e sim em servidores que não tomaram as medidas básicas.
Desde aquele dia, toda vez que monto um servidor novo, antes de subir qualquer código, passo obrigatoriamente por esse checklist de segurança. Conferir a fechadura antes de abrir a porta. Essa é a postura mais básica para proteger um servidor.
Até aqui, cuidamos do preparo físico básico (CLI, permissões, segurança) para sobreviver na selva Linux. Mas ainda resta um problema fundamental. O ambiente do meu notebook (Windows) é diferente do servidor Linux. Versão do Java é diferente, biblioteca é diferente.
Existe uma tecnologia que acaba de vez com o famoso “Na minha máquina funciona”. Na próxima, vamos falar de ‘virtualização e containers’, que eliminam de vez as diferenças de ambiente.