- Casos de servidores pessoais saindo do ar devido a requisições excessivas de bots de scraping de IA
- A análise dos logs confirmou tentativas concentradas de acesso vindas da faixa de IP hospedada em Singapura da Alibaba(US) Technology (
47.79.*)
- Um User-Agent falsificado no formato
Mozilla/5.0 neutralizou sistemas comuns de detecção de bots
- Os sistemas automáticos de bloqueio do Fail2ban e do Nginx ficaram sobrecarregados, exigindo o bloqueio manual da faixa inteira de IPs
- Operadores de servidores pessoais estão vendo o ambiente de self-hosting encolher por causa de ataques recorrentes, sendo empurrados para plataformas centralizadas
Causa da queda do servidor e resposta inicial
- Há alguns dias, o pequeno servidor que hospedava o site ficou temporariamente indisponível por causa de um ataque de bots de scraping
- Ataques semelhantes já haviam ocorrido antes, e está sendo considerada a adoção de ferramentas de defesa mais robustas, como o Anubis
- Os ataques repetidos vêm reduzindo a motivação criativa e o prazer de manter isso como hobby para desenvolvedores independentes
- Depois de lentidão no acesso ao servidor, a verificação com o comando
top mostrou que Gitea e Fail2ban estavam consumindo quase toda a CPU
- Mesmo encerrando o processo do Gitea, a carga do Fail2ban não caiu, e o log de acesso do Nginx estava explodindo
Análise dos logs e padrão do ataque
- Os logs registraram muitas requisições HTTP 502 mirando o caminho
/commit/
- Nos cabeçalhos das requisições, eram usados User-Agents disfarçados de navegador comum, como
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
- A maior parte das ferramentas de inspeção de User-Agent tratou isso como tráfego legítimo, permitindo evasão da detecção
- Os IPs do ataque vieram de vários endereços, não de uma única origem, mas todos usavam em comum a faixa
47.79.*
- Segundo consulta no
ipinfo.io, essa faixa pertence à Alibaba(US) Technology Co., Ltd.
- Há também relatos de ataques com a mesma faixa de IP em locais como fóruns PhpBB
Medidas de defesa e limitações
- O Fail2ban analisava os logs do Nginx em tempo real para aplicar regras de bloqueio, mas houve atraso no processamento por causa da explosão de logs
- Foi executado um script para bloquear imediatamente IPs que tentassem acessar
/commit/, mas havia limites de velocidade
- No fim, foi necessário bloquear manualmente toda a faixa
47.79.0.0/16 com comandos iptables
- Esse tipo de resposta é apenas uma medida paliativa, e ataques vindos de novas faixas de IP podem continuar
- Está em avaliação a adoção de serviços externos de proteção, como Cloudflare, ou sistemas de defesa mais avançados, como o Anubis
- No entanto, existe resistência à adoção por não querer passar por servidores nos EUA com recursos de rastreamento
As dificuldades de operar um servidor pessoal
- Está sendo considerada a migração da instância do Gitea para o Codeberg
- Operadores de servidores pessoais, diante de ataques repetidos, tendem a abandonar o self-hosting e migrar para plataformas centralizadas
- Esse movimento enfraquece a descentralização e a autonomia da internet
- Outros blogueiros também relatam ataques semelhantes, mostrando que isso está se tornando um problema generalizado para pequenos operadores web
Outras anomalias de tráfego observadas
- Foram encontrados cabeçalhos Referer falsificados apontando para domínios de grandes empresas, como
bioware.com, mcdonalds.com e microsoft.com
- Na prática, esses sites não forneciam links, e houve aumento de tráfego de origem e objetivo indefinidos
- Mesmo que os ataques se repitam, foi expressa a determinação de não abandonar o self-hosting
- No fim do texto, a frase “Get Hostin’ Or Die Tryin’” reforça a vontade de continuar operando servidores de forma autônoma
1 comentários
Comentários do Hacker News
Parece que a internet deixou de ser um espaço seguro para desenvolvedores de software por hobby
Eu opero meus próprios servidores desde mais ou menos 2005, e desde o momento em que um servidor entra no ar ele sempre começa a sofrer ataques
Principalmente quando você dá um nome DNS ou usa um certificado TLS, parece que a exposição nos logs de transparência de certificados piora ainda mais os ataques
Quando você publica um site, o tráfego malicioso dispara, e se irrita alguma organização específica, parece que contratam alguém para tentar um DDoS
Crawlers, botnets, ataques automatizados, gente irritada — isso acontece todo ano
Já usei várias hospedagens, mas o resultado foi parecido
Quando eu não atualizei o WordPress, ele foi infectado com spam de SEO em poucas horas, e quando expus o Redis por engano para a internet, instalaram um RAT de botnet
Mas não acho que isso signifique que a internet seja “perigosa”
Na verdade, foram experiências que me mostraram o que eu precisava aprender
Depois disso, passei a usar star-cert para não aparecer nos logs de certificados, adicionar autenticação básica, manter backups e operar tudo com cuidado
O verdadeiro perigo, na minha opinião, é gente que não entende de tecnologia instalar qualquer
.exee entregar todas as informações para Facebook ou TikTokA maioria são requisições tentando explorar vulnerabilidades de WordPress, mesmo eu nunca tendo usado WordPress
Quando vi os logs pela primeira vez, fiquei chocado, mas hoje trato isso como algo do dia a dia
Ex.: https://www.masswerk.at/wp-admin
Foi a época em que ferramentas para escanear faixas de IP e encontrar vulnerabilidades automaticamente começaram a se espalhar
Sinto falta da web entre 1995 e 2008, da época de Web Rings, Technorati e fansites
Referência: Wiki sobre Script Kiddie
Antigamente eu usava zipbomb para bloquear bots, e funcionava
Mas depois que postei isso no HN, novos bots apareceram em massa e meu servidor de US$ 6 não aguentou
Era impossível servir 100 mil requisições por dia com payloads de 1~10MB
Depois disso, passei a mirar apenas certos bots e criei um honeypot para coletar IPs e responder com 403
Alguns meses depois, o tráfego voltou ao nível normal
Só não sei quem seria o cliente-alvo. A maioria dos usuários de self-hosting não tem muito dinheiro
Meu servidor cgit também está sendo acessado por scrapers há um ano
Mas são só 2 ou 3 requisições por minuto, então é um bot até que “educado”
O engraçado é que todo o código que publiquei pode ser clonado diretamente do upstream, mas mesmo assim ficam raspando dali
Pelos logs, é uma automação realmente ineficiente
Se você configurar diretamente o rate limiting do Nginx, dá para resolver isso mais facilmente do que com o Fail2ban
Post de referência: https://blog.nginx.org/blog/rate-limiting-nginx
É difícil aplicar isso a serviços públicos como blogs, mas para self-hosting de uso pessoal eu recomendo configurar autenticação mTLS no reverse proxy
Requisições sem certificado são bloqueadas na hora, e só meus dispositivos conseguem acessar
Depois de configurar uma vez, quase não precisa mais se preocupar com isso
A configuração é simples e funciona bem no Android e no iOS
Hoje deixei todos os meus serviços self-hosted acessíveis apenas dentro de uma VPN Wireguard, e o firewall só mantém aberta a porta do Wireguard
Anubis está indo bem nesse jogo de gato e rato com bots
Mas só empresas com dados massivos de tráfego, como a Cloudflare, conseguem fazer bem bloqueio baseado em reputação de IP
Operadores pequenos acabam tendo que bloquear faixas inteiras de IP, o que é ineficiente
É preciso uma solução como o Crowdsec, que compartilhe dados de reputação para bloquear IPs maliciosos e ofereça um desafio simples sem JS
Se uma abordagem assim for possível, acho que ficará mais fácil para desenvolvedores por hobby voltarem a operar serviços
Minha instância do Gitea também sofreu recentemente scraping via IPs e ASNs distribuídos
Se forem empresas de IA com bastante dinheiro, provavelmente será difícil barrar isso até com o Anubis
Por isso estou considerando envenenar scrapers — ou seja, servir dados lixo no lugar do código
Esse tipo de serviço torna o scraping ainda mais difícil de bloquear
Tudo que fica popular acaba entrando num ciclo de degradação ao cair nas mãos do grande público
Por isso parece que a única saída é continuar migrando para novos espaços
Depois que mudei o DNS para a Cloudflare, começaram a chegar continuamente pacotes SYN estranhos
Tem requisições para as portas 443 ou 22 a cada segundo, mas depois do SYN-ACK não vem resposta
A maioria parece vir de empresas de hospedagem de VPS para servidores de jogos, inclusive no Brasil
Então passei a capturar os pacotes SYN, consultar via RDAP e bloquear de uma vez a sub-rede inteira da organização
Só o Google continua na whitelist
A Digital Ocean parece ser uma das principais fontes de tráfego malicioso
A pilha de rede fica retransmitindo e o tráfego acaba sendo amplificado contra a vítima
Como muitas vezes falsificam o IP de origem, vale tentar definir
rp_filtercomo strictAssim como uma companhia elétrica não proíbe o uso de lâmpadas vermelhas, não é desejável que o provedor de serviço controle o tráfego
O motivo de eu me identificar com este texto não é que a internet seja segura, e sim o fato de ele registrar essa realidade
Eu também bloqueio o /16 da Alibaba e a faixa inteira da AWS
Uso um script que baixa diariamente os dados do RouteViews por cron e aplica no iptables
Exemplo de código:
Seria bom se outras clouds oferecessem isso do mesmo jeito