1

Como um container FROM scratch em Go absorveu 1000+ varreduras no dia 1 com R$ 0,00 de infra

Decidi colocar em produção uma tese de engenharia focada em Primeiros Princípios (First Principles): é possível construir uma aplicação web moderna com performance máxima, superfície de ataque perto de zero e custo nulo de infraestrutura sem recorrer a ecossistemas inchados ou nuvens caras?
Para testar isso, desenvolvi um framework autoral (FGOTHS: Go + Templ + HTMX + FlatBuffers) e mudei a forma como o deploy é feito.

  1. A Arquitetura de Infraestrutura e Hardening
    A aplicação roda self-hosted em hardware local, mas sem expor IP público ou portas do roteador residencial.
    Container FROM scratch: Compilação estática (CGO_ENABLED=0) com símbolos removidos (-s -w). A imagem Docker contém exclusivamente o binário compilado, os certificados CA e os dados de fuso horário.
    Zero Shell / Zero OS: Não existe /bin/sh, gerenciador de pacotes, interpretador Python/PHP ou utilitários Unix dentro do container.
    Non-root: Execução travada no uid 65532.
    Egress Criptografado via Cloudflare Tunnel: O tráfego entra exclusivamente por uma conexão de saída iniciada pela própria máquina. Ataques de camada de rede (DDoS, port scanning no IP residencial) morrem na borda da CDN.
  2. O que os bots procuravam no Dia 1
    Ao subir o site, os scanners automatizados que varrem a internet chegaram em questão de minutos. O relatório do log de probes do primeiro dia registrou tentativas caçando:
    Arquivos .env e .git/config: Buscando credenciais e segredos em texto puro. (Na nossa arquitetura: os segredos são variáveis de ambiente do processo e não há código-fonte no container).
    wp-admin/install.php e phpinfo.php: Tentando explorar vulnerabilidades de ecossistemas PHP/WordPress. (Na nossa arquitetura: não existe PHP ou runtime externa).
    _ignition/execute-solution: Exploit clássico de Remote Code Execution (RCE) no Laravel. (Na nossa arquitetura: sem interpretador e sem shell, não há para onde fazer pivot mesmo se houvesse falha de parsing).
    Todas as varreduras foram respondidas com um 404 limpo em microssegundos, sem gerar falhas de servidor (5xx) e mantendo a CPU e a memória do host intactas.
  3. Métricas de Performance obtidas
    PageSpeed: 100/100 (Desktop e Mobile)
    Total Blocking Time (TBT): 0ms
    First Contentful Paint (FCP): 0.4s
    Custo de Infraestrutura: R$ 0,00/mês
  4. Transparência Radical (Audit-First)
    Em vez de publicar promessas de segurança em relatórios em PDF, abrimos a telemetria e o histórico de segurança na própria aplicação. A página de auditoria detalha o modelo de dados (migrações SQL puras), o ciclo de hardening, a verificação com govulncheck e o log de requisições bloqueadas.
    Página de Auditoria ao vivo: https://srars.tech/pt-BR/audit
    Repositório Open-Source do Framework: https://github.com/WhoseBiasDoYallSeek/fgoths-framework
    Gostaria de abrir o debate com a comunidade: vocês costumam utilizar imagens scratch e compilação estática em Go em projetos de produção, ou ainda dependem de distros de suporte (como Alpine) para depuração? Como lidam com a balança entre facilidade de observability e eliminação total da superfície de ataque?
Carregando publicação patrocinada...
1

O volume de probes em /.env e wp-admin aparece em qualquer hostname publicado. FROM scratch muda o que sobra se uma request explorar o binário: não existe shell no container. Não filtra a lista de URLs que o scanner tenta.

1

Perfeito, Florian. Excelente pontuação.

O scanner atira no escuro e bate em qualquer IP/hostname exposto buscando o lowest hanging fruit (.env, wp-admin, Laravel RCE). A intenção de mostrar o log de probes não foi sugerir que o scratch "esconde" a aplicação dos bots, mas sim ilustrar a defesa em profundidade (defense-in-depth).

Como você ressaltou: a grande sacada da imagem scratch (combinada com CGO_ENABLED=0 e execução non-root) é justamente eliminar o "blast radius". Se um parseador de payload no Go tiver uma vulnerabilidade zero-day, o atacante bate numa parede: não há /bin/sh, não há gerenciador de pacotes, não há interpretador auxiliar e não há utilitários de sistema para fazer pivot ou movimentação lateral.

Além disso, o custo computacional de responder 404 direto no binário em microssegundos é praticamente nulo para o host.

Valeu pelo comentário!

0

O ponto do scanner atirar no escuro é óbvio, Florian. O intuito do post não é dizer que a imagem esconde URL do bot, mas sim medir o impacto no runtime.

O foco do experimento é a telemetria: mostrar como cada probe toma 404 limpo em microssegundos no binário Go, sem subir latência, sem consumir memória do host e sem deixar superfície pra execução caso houvesse algum bypass.

A análise é sobre o comportamento da infra/runtime sob varredura, não sobre a psicologia do bot scanner.