Tráfego de bots após os ataques a data centers da Yandex
Observação qualitativa dos nossos operadores, não uma medição. Após os ataques noticiados a data centers da Yandex, quem lê os logs dos servidores da DCXV teve a impressão de que o tráfego de algumas redes de quintas de bots diminuiu: menos pedidos automáticos, menos tentativas de força bruta, menos pedidos HTTP POST suspeitos. Não publicamos contagens, percentagens, gráficos nem taxas, porque não fizemos uma comparação controlada. O artigo explica o que observamos, como estes tipos de tráfego aparecem nos logs, como reforçar um servidor seja qual for a origem e como testar a afirmação por conta própria.
O que foi noticiado
No início de outubro, a Reuters noticiou que drones atingiram data centers da Yandex em dois dias seguidos, e a Yandex disse que vários módulos do seu local na região de Kaluga ficaram inutilizados e que alguns serviços podiam sofrer perturbações (notícia da Reuters no The Star). Não confirmámos estes factos por nós e não tomamos posição sobre quem foi responsável. Este artigo trata apenas de tráfego e higiene de servidores. Para o risco do fornecedor, veja alojamento na Yandex e em regiões de alto risco.
O que observámos
Os operadores da DCXV leem quatro fontes: logs do servidor web e do WAF, logs de autenticação SSH, acessos aos nossos caminhos honeypot (URLs que nenhum visitante real abre) e o registo de erros HTTP. Acompanham-nas ao longo do tempo no trabalho normal. Não houve janela fixa de antes e depois, linha de base nem grupo de controlo. O que se segue é a impressão de pessoas que sabem como estes logs costumam ser, nada mais forte.
Como estes tipos de tráfego aparecem nos logs
Três padrões contam. Todos os exemplos abaixo são ilustrativos: os endereços vêm de intervalos de documentação e as marcas de tempo são marcadores.
- Pedidos automáticos - os mesmos caminhos num ritmo muito regular com um user agent genérico ou vazio, muitas vezes à procura de painéis de administração e scripts antigos.
- Tentativas de força bruta - muitos inícios de sessão falhados com nomes diferentes a partir de uma origem, ou um nome testado a partir de muitas origens.
- Pedidos POST suspeitos - POST repetidos para login, XML-RPC ou formulários, em geral com resposta 200 ou 401 e sem visita prévia à página.
Linhas de exemplo (ilustrativas, não tráfego real):
sshd[1234]: Failed password for invalid user admin from 203.0.113.7 port 51234 ssh2
sshd[1235]: Failed password for invalid user test from 203.0.113.7 port 51240 ssh2
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /wp-login.php HTTP/1.1" 200 5120 "-" "Mozilla/5.0"
203.0.113.9 - - [DD/Mon/YYYY:hh:mm:ss +0000] "POST /xmlrpc.php HTTP/1.1" 200 420 "-" "Mozilla/5.0"
Checklist de reforço que funciona com qualquer origem
Nenhum passo depende de onde vem o cliente. Siga esta ordem e mantenha uma segunda sessão SSH aberta enquanto altera o sshd, para que um erro de escrita não o deixe de fora. Mais sobre chaves no nosso guia de SSH para um servidor cloud novo.
1. SSH apenas com chave. Desative palavras-passe e o login root por palavra-passe e teste a configuração antes de recarregar:
# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 20
sudo sshd -t && sudo systemctl reload ssh
2. fail2ban para o sshd. Bloqueie uma origem após poucas falhas:
# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
maxretry = 4
findtime = 10m
bantime = 1h
3. Limite de pedidos nos endpoints de login no nginx. Abrande um script sem incomodar uma pessoa:
# http {} context
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# server {} context
location = /login {
limit_req zone=login burst=5 nodelay;
limit_req_status 429;
proxy_pass http://127.0.0.1:3000;
}
- Regras WAF - bloqueie caminhos de sondagem conhecidos e corpos POST demasiado grandes ou malformados; comece só em modo de registo e depois aplique.
- Proteção dos endpoints POST - exija token CSRF, limite o tamanho do corpo e devolva o mesmo erro para utilizador errado e palavra-passe errada.
- CAPTCHA ou desafio - mostre-o só após algumas falhas, não a cada visitante.
- Monitorização e alertas - alerte perante um salto de logins falhados ou de 4xx em POST e reveja semanalmente as principais origens.
Porque bloquear um país é, por si só, um controlo fraco
A geolocalização de IP é uma estimativa. VPN, proxies e servidores alugados colocam um bot em qualquer país, e uma botnet de routers domésticos sequestrados está onde esses routers estiverem. Um bloqueio por país também trava clientes reais, viajantes e parceiros. Pode ser uma camada barata entre outras, mas não substitui o SSH só com chave, os limites de pedidos nem um WAF, e envelhece mal quando o tráfego passa para outras redes.
Como testar a afirmação nos seus próprios servidores
Se quer provas em vez de impressões, defina as regras antes de olhar para os dados:
- Fixe as janelas - escolha períodos iguais de antes e depois, com os mesmos dias da semana, antes de abrir qualquer log.
- Filtros idênticos - os mesmos ficheiros de log, a mesma regra de contagem, os mesmos bloqueios e limites nos dois períodos.
- Recolha uma linha de base - compare com um período calmo mais longo, porque as campanhas vão e vêm sem evento externo.
- Agrupe por rede, não por país - conte por rede de origem e registe à parte os intervalos alugados ou de proxy.
- Registe as suas alterações - uma regra nova de firewall ou um site movido pode parecer uma tendência.
Dois pontos de partida para executar em cada janela com os mesmos filtros:
sudo journalctl -u ssh --since "24 hours ago" --no-pager | \
grep "Failed password" | \
awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
awk '$6 == "\"POST"' /var/log/nginx/access.log | \
awk '{print $7}' | sort | uniq -c | sort -rn | head
Limites da nossa observação
Leia isto como uma hipótese de um operador, não como uma conclusão:
- Correlação não é causalidade - dois factos próximos no tempo não estão necessariamente ligados.
- A atribuição é imperfeita - a geolocalização IP e os dados ASN confundem VPN, proxies, infraestrutura alugada e botnets de outros países.
- O tráfego desloca-se - os bots podem ter passado para outras redes; menos de um lugar não é menos no total.
- Uma rede não é a internet - só vemos o que chega aos nossos servidores.
- Pode ser temporário, e há outras causas possíveis: bloqueios noutros sítios, sazonalidade, campanhas terminadas ou a nossa própria filtragem.
Próximos passos
Comece pelo SSH só com chave e um limite de pedidos no login: leva minutos e ajuda contra qualquer origem. Se precisa de um servidor limpo para aplicar esta checklist, veja os nossos servidores cloud em Praga e na Covilhã, e use a checklist do período de teste para testar um como deve ser. Perguntas ou observações próprias: sales@dcxv.com.
