Eu analisei ataques nos meus logs de acesso

Artigo original ↗ Discussão no Hacker News ↗

Varreduras rotineiras e ataques de baixa sofisticação martelam qualquer servidor exposto à internet, enchendo logs com probes para vulnerabilidades conhecidas como arquivos `.env` expostos, caminhos do WordPress, senhas SSH e bugs de software desatualizado. Os comentaristas argumentam que a defesa real está no básico bem feito — correções em tempo hábil, SSH baseado em chaves, serviços com a menor exposição possível (muitas vezes via VPN), isolamento/sandboxing e controles em camadas — enquanto ferramentas como fail2ban, WAFs e honeypots principalmente reduzem o ruído ou acrescentam proteção marginal quando bem ajustadas. Vários observam que os atacantes estão cada vez mais descobrindo novos alvos por meio de logs de certificate transparency, reforçando a necessidade de proteger os sistemas antes mesmo de irem ao ar.

Varredura Rotineira da Internet e Padrões de Ataque

  • A maioria dos “ataques” nos logs são varreduras automatizadas e de baixa sofisticação, atingindo cada IP roteável, muitas vezes com cargas prontas para CVEs antigas (vazamentos de .env, Shellshock, caminhos de Wordpress/PHP, etc.).
  • Muitas ferramentas simplesmente martelam servidores sem verificar as respostas; às vezes repetidamente a partir dos mesmos IPs ou faixas estáticas.
  • Várias pessoas concluem que, se você seguir práticas básicas de segurança, essas tentativas não importam; se você não seguir, também não importam porque você já está vulnerável.

Fail2ban, SSH e Endurecimento Básico do Host

  • O Fail2ban é usado principalmente para reduzir o ruído dos logs e diminuir tentativas de força bruta; outros dizem que ele está desatualizado, consome muitos recursos e é ineficaz contra rotação de IP.
  • Conselho comum sobre SSH: desative autenticação por senha, use apenas chaves, opcionalmente saia da porta 22, limite IPs de origem ou coloque o SSH atrás de VPN/bastions/acesso “dark”.
  • Alguns confiam em rate limiting de iptables/nftables ou em port knocking em vez de fail2ban; SSH apenas em IPv6 com IPv4 bloqueado por firewall é outra tática.

WAFs, Cloudflare e Trade-offs

  • Alguns recomendam AWS WAF, Azure WAF (regras OWASP) ou o WAF gratuito da Cloudflare para filtrar ataques óbvios e atender conformidade.
  • Alertas fortes: as regras padrão часто quebram tráfego legítimo (bloqueando certos corpos de requisição, ausência de User-Agent, uploads de arquivos com metadados, URLs longas). A melhor prática é primeiro colocar em “count mode” e depois bloquear gradualmente.
  • Críticos argumentam que WAFs dão uma falsa sensação de segurança, podem ser contornados, adicionam latência e podem bloquear pesquisadores ou usuários do Tor; apoiadores os veem como um curativo útil, não um substituto para aplicações seguras.
  • Há preocupações sobre centralizar o tráfego atrás de grandes provedores como a Cloudflare, mas outros observam alternativas e um lock-in relativamente baixo.

Estratégias de Self-Hosting e Exposição de Rede

  • Mitigações centrais: mantenha os sistemas atualizados (muitas vezes por meio de atualizações de segurança sem intervenção), use containers/VMs/jails para isolamento e evite expor serviços desnecessariamente.
  • Muitos que fazem self-hosting agora colocam tudo atrás de VPNs ou overlays no estilo zero-trust (Wireguard, Tailscale, ZeroTier, Cloudflare Tunnels, ferramentas semelhantes), às vezes com mTLS ou autenticação HTTP básica como camada extra.
  • As sugestões incluem não servir dotfiles, restringir painéis de administração a caminhos obscuros e enviar logs para fora do host para fins forenses.

Credential Stuffing e Fortalecimento da Autenticação

  • Campanhas de credential stuffing em larga escala podem envolver mais de 100 mil IPs, tornando o bloqueio por IP ineficaz.
  • Mitigações relatadas:
    • Limitar taxa por IP, nome de usuário e senha.
    • Identificar proativamente e redefinir senhas vazadas e banir senhas vazadas comuns.
    • Tornar as verificações de autenticação de baixo custo e escaláveis; interromper rapidamente o tráfego de ataque óbvio, mas imitar o tempo normal.
    • Habilitar requisitos extras de autenticação dinamicamente sob ataque.

Certificate Transparency e Descoberta

  • Há múltiplos relatos de que as varreduras aumentam logo após obter certificados da Let’s Encrypt, sugerindo que atacantes monitoram logs de CT para novos domínios/subdomínios.
  • Alguns mitigam isso ao: endurecer antes da exposição, usar certificados wildcard ou internos/autossinados, ou separar certificados internos de proxies voltados ao público.
  • Ferramentas como crt.sh, certstream e várias ferramentas de consulta de CT são mencionadas para monitorar sua própria superfície.

Filosofia de Segurança e “Security Through Obscurity”

  • Consenso: aplique patches rapidamente e siga as melhores práticas primeiro; logs são mais úteis para análise pós-incidente do que para se obcecar com cada probe.
  • Forte apoio à defesa em profundidade: firewalls/VPNs, isolamento, WAFs, monitoramento e boa autenticação, além de segmentação entre sistemas públicos e internos.
  • “Security through obscurity” é debatido: depender apenas dela é condenado, mas muitos veem a obscuridade (portas/caminhos não padrão, serviços ocultos) como uma camada secundária valiosa para reduzir ruído oportunista.