Coloquei um firewall contra máfia na frente do meu laboratório aberto e ele começou a bloquear ataques no primeiro dia.

Depois de descobrir meus serviços publicamente disponíveis com o Pangolin, minha opinião sobre os laboratórios domésticos mudou. Antes, o tempo de atividade do contêiner e a integridade do servidor eram minhas únicas preocupações, mas assim que fui exposto, comecei a me perguntar quem estava tentando entrar. O firewall nunca foi um problema no meu Omada ER605; ele fez um ótimo trabalho ao bloquear o tráfego indesejado. Mas não havia mais nada a dizer depois que a solicitação foi processada e chegou ao meu proxy reverso. Então decidi adicionar o CrowdSec por curiosidade e em poucas horas ele começou a sinalizar tentativas reais de exploração.

O firewall não era tudo

Os ataques já estavam dentro

Configurar um laboratório doméstico é fácil. Converti um laptop empresarial em um servidor Debian bare metal, acesso externo privado usando Tailscale e acesso externo público usando Pangolin.

Deixe-me explicar um pouco mais sobre toda a configuração do Pangolin. Funciona com quatro componentes principais: o servidor Pangolin atua como plano de controle, Gerbil gerencia a interface WireGuard, Traefik atua como proxy reverso e, finalmente, Newt como cliente WireGuard do Pangolin para conexões de saída para o VPS. Feito isso, posso descobrir um número ilimitado de serviços no painel do Pangolin.

É um laboratório doméstico e uma configuração Pangolin. O firewall da minha rede doméstica é gerenciado por um TP-Link Omada ER605, um roteador WAN duplo executando dois ISPs em um equilíbrio de carga 7:1. Os roteadores da série ER possuem um firewall padrão suficiente para um usuário doméstico. Permite conexões de saída, mas bloqueia conexões de entrada desconhecidas que não correspondem a uma sessão de saída existente.

Nada entra na minha LAN, a menos que o roteador permita. CGNAT significa que nem preciso de bloqueio de roteador para fazer muito trabalho porque meus dois ISPs já me escondem atrás de IPs compartilhados, então nem tenho um IP estático público para defender e isso funciona a meu favor. Muitas varreduras de portas em toda a Internet têm como alvo um IP público aleatório; Como não tenho um, a maioria das verificações provavelmente nunca chegará ao lado público do meu gateway.

De volta à configuração do Pangolin. Eu hospedo em um VPS porque preciso de um IP estático público. A maioria dos riscos nem é diretamente relevante para o meu laboratório doméstico, já que meu servidor doméstico está por trás do Pangolin e do Traefik. Mas hospedar em um VPS com IP público significa abrir as portas 80 e 443. Elas são abertas de propósito porque é assim que o Pangolin funciona. O tráfego passa por 80 e 443 e o firewall bloqueia todo o resto. Quando o tráfego HTTP chega ao Traefik, o trabalho do firewall está efetivamente encerrado.

Mas isso torna a situação boa e ruim. Já expliquei a parte boa. A parte ruim: todas as solicitações agora são enviadas para um proxy reverso, desde tentativas de login e preenchimento de credenciais até bots aleatórios e impressões digitais CVE. Isso não quer dizer que sejam todos maliciosos; essas são solicitações HTTP válidas pelas quais o firewall permitiu a passagem. E meu roteador provavelmente nunca vê nenhuma dessas solicitações.

Foi aí que comecei a procurar algo que pudesse entender meu comportamento de tráfego, não apenas de portas. E minha busca terminou quando me deparei com o CrowdSec.

Um espaço reservado quase derrubou toda a borda

Portanto, para ser claro: não estou tentando substituir meu firewall existente – servidor doméstico ou VPS. Tentei adicionar outra camada de segurança que entendesse o comportamento do tráfego HTTP de entrada. E o CrowdSec foi escolhido porque era gratuito, orientado pela comunidade e perfeitamente compatível com minha configuração atual do Traefik VPS.

Configurar o CrowdSec parecia fácil no início, mas no final quase estraguei tudo. Comecei implantando o CrowdSec com a pilha Pangolin existente como um novo contêiner no mesmo arquivo de gravação com crowdsecurity/traefik, crowdsecurity/http-cvee crowdsecurity/http-dos carregado na inicialização. Como eu já tinha o Traefik do Pangolin e não era baseado no rótulo Docker, tive que adicionar crowdsec-bouncer para experimental.plugins bloquear traefik_config.yml e ligue accessLog. Em seguida, adicionei o middleware ao ponto de entrada de segurança da web dentro dynamic_config.yml.

docker-compose.yml:

crowdsec:
 image: docker.io/crowdsecurity/crowdsec:latest
 container_name: crowdsec
 restart: unless-stopped
 environment:
   COLLECTIONS: "crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/http-dos"
 volumes:
   - ./config/crowdsec:/etc/crowdsec
   - ./config/crowdsec-data:/var/lib/crowdsec/data
   - ./config/traefik/logs:/var/log/traefik:ro

traefik_config.yml:

experimental:
 plugins:
   crowdsec-bouncer:
     moduleName: github.com/maxlerebourg/crowdsec-bouncer-traefik-plugin
     version: v1.3.5

accessLog:
 filePath: /var/log/traefik/access.log
 bufferingSize: 0

entryPoints:
 websecure:
   http:
     middlewares:
       - crowdsec-bouncer@file

dinâmico_config.yml

http:
 middlewares:
   crowdsec-bouncer:
     plugin:
       crowdsec-bouncer:
         enabled: true
         crowdsecLapiKey: "YOUR-BOUNCER-KEY"
         crowdsecLapiHost: "crowdsec:8080"
         crowdsecMode: live

Assim que a configuração inicial foi concluída, peguei a pilha, exceto que a configuração ainda continha a chave API do espaço reservado. Uma chave de API incorreta causou falha no plug-in, todas as solicitações começaram a falhar e demorou cerca de dez minutos para todos os seis serviços expostos. Quando percebi o erro, recebi uma chave de API real na inicialização cscli bouncers addchave de API descartada dynamic_config.ymle reiniciei tudo. Após uma reinicialização completa, verifiquei todos os logs e passei para a próxima etapa de adicionar o mecanismo ao console CrowdSec.

Essa parte foi fácil porque eu já tinha feito a parte difícil. eu me inscrevi app.crowdsec.net e registrei meu mecanismo local executando um comando simples do Docker com uma chave de registro gerada no console CrowdSec.

sudo docker exec crowdsec cscli console enroll YOUR-ENROLL-KEY

Eu então continuei funcionando e a primeira revelação real aconteceu cerca de algumas horas depois de ir a público. Foi um http-technology-probing avisar sobre /owa/auth/x.js de um IP hospedado no Azure. Eu até confirmei isso como uma proibição forçada real via cscli decisions list.

Depois de quase uma semana de atividade, abri o painel e vi números reais. A Traefik consultou o CrowdSec mais de 8.000 vezes, das quais bloqueou aproximadamente 38 solicitações. A proporção deixou uma coisa clara: não se tratava de processar todas as solicitações, mas apenas de tomar decisões seletivas. Não fiquei surpreso com a lista de banimentos, mas com o fluxo constante de tráfego que atingiu meus serviços disponíveis publicamente.

Ver o trânsito mudou tudo

Não saber era estranhamente confortável

Depois de olhar o painel com dados de uma semana, só o tráfego mudou minha visão sobre a divulgação de serviços. Eu sabia sobre talentos em geral, mas olhar para esses números dos meus serviços ainda me pegou desprevenido. Nada disso parecia dirigido a mim; Eu já sabia que era tráfego automatizado de internet. O painel me alertou sobre o constante ruído de fundo que existia em todos os serviços públicos que administro.

Ele não invalidou meu ER605 nem fez com que ele não tivesse ataques, mas simplesmente não foi projetado para testar solicitações HTTP. Os números eram tão fascinantes que comecei a me aprofundar no CrowdSec. Enquanto pesquisava, descobri de onde vem grande parte desse burburinho: a inteligência da comunidade CrowdSec. A lista de bloqueio da comunidade CrowdSec (originária do CAPI) registrou mais de 32.000 banimentos em tentativas de força bruta, varreduras HTTP e sondagens de exploração, todas elas provenientes de instâncias CrowdSec de outros usuários, enquanto minhas detecções locais foram em torno de 205. Isso significa que muitas ameaças foram identificadas em outros lugares antes que tivessem a chance de interagir com meu endpoint público.

Agora, de volta à minha configuração: Pangolin e CrowdSec estavam fazendo dois trabalhos diferentes, nenhum em comum. A Pangolin fez o que fez de melhor ao expor meus serviços com segurança, e a CrowdSec certificou-se de analisar todas as solicitações depois que esses serviços foram disponibilizados. Eles se complementavam, proporcionando uma rede de segurança adicional. Instalei o CrowdSec para testar minhas teorias, mas quando vi o fluxo constante de atividades, voltar ao firewall simplesmente não parecia mais suficiente.

Aberto não significa o que eu penso

Antes de implementar o CrowdSec na minha infraestrutura, pensei que as regras padrão do firewall eram suficientes para o trabalho pesado. Mas agora entendo onde começa e termina cada responsabilidade. E depois de uma semana de corrida, aprendi que o importante não era o número de quarteirões, mas mais visibilidade do que “exposto” realmente significava. No final da semana, o CrowdSec havia se tornado uma daquelas ferramentas que desapareceu silenciosamente em segundo plano, lidando com o tráfego que eu não queria mais lidar manualmente.