Bloqueando conexões da AWS para meus serviços on-premises
(consulting.m3047.net)- A internet pública pode se fragmentar em um ecossistema segmentado centrado em grandes provedores de nuvem, e o bloqueio de acessos vindos da AWS para ambientes on-premises mostra um caso operacional dessa tendência
- O bloqueio atinge principalmente tentativas de conexão TCP iniciadas por clientes dentro da AWS contra serviços on-premises, enquanto conexões de clientes locais para serviços hospedados na AWS continuam possíveis
- Os serviços on-premises em operação incluem web, demo do Trualias, DNS e SMTP, e o DNS oferece acesso público limitado de telemetria de segurança via UDP, fallback para TCP e consultas específicas
- O bloqueio da AWS começou como resposta a tráfego excessivo de ping e a crawler/scanner abusivos, e hoje gerencia 53 blocos CIDR do espaço de endereços da AWS observados como alvo ou origem de abuso
- Se os grandes provedores de nuvem não divulgarem melhor informações forenses como reverse DNS, whois, namespace DNS e padrões de abuso, a fragmentação pode se intensificar sem que usuários dentro da nuvem quase percebam o impacto
A possibilidade de fragmentação criada pelas grandes nuvens
- Se os grandes provedores de nuvem se tornarem uma bulletproof infrastructure “too big to fail”, eles podem causar diretamente a fragmentação da internet
- Isso ainda não se concretizou totalmente, mas é visto como algo que já começou ou pode surgir em breve
- O ecossistema cloud-native tem uma infraestrutura sob medida em comparação com a internet real, e cada serviço de nuvem é organizado em torno de funcionalidades diferenciadas em vez de uma arquitetura comum
- Muitos serviços funcionam de forma autocontida dentro de uma nuvem específica, com barreiras à interoperabilidade transparente com a internet em geral
- A comunidade cloud-native trata a internet comum como um recurso externo e interage mais com o ecossistema de um provedor de nuvem específico do que com a própria internet
A comercialização da internet pública
- Antes de 1989, a internet não tinha acesso público geral e era uma rede de caráter privado usada por governo, forças armadas, pesquisa e educação
- A NSF administrava o núcleo do backbone, e o acesso público inicial era permitido sob a condição de tráfego não comercial
- Os serviços comerciais em si não eram proibidos, mas o tráfego que passava pelo backbone da NSFNet não podia ser de publicidade nem de serviços pagos
- Provedores comerciais construíram uma internet comercial separada, e em 1995 a NSFNet desativou o acesso público
- Após a grande eliminação de empresas por volta de 2000, sobreviveram os modelos baseados em publicidade com dados de comportamento do usuário e na venda desses dados
- No ciclo atual da IA, destaca-se a coleta em massa de conteúdo acessível e sua lavagem para treinamento de modelos, com curadoria e treinamento feitos principalmente na nuvem, cada vez mais pelos próprios provedores de nuvem
Bloqueando conexões da AWS em serviços on-premises
- O acesso vindo da AWS para servidores on-premises está sendo, em sua maior parte, desativado
- Tecnicamente, o foco está principalmente no tráfego TCP, e o handshake inicial permite distinguir cliente e servidor
- Tentativas de conexão de clientes dentro da AWS para serviços on-premises são bloqueadas
- Clientes da rede local ainda podem se conectar a serviços hospedados na AWS
- Há vários serviços públicos operando localmente
- Serviço web
- Demo do Trualias
- Servidor DNS
- Servidor de e-mail SMTP
- Há anos é mantida uma política de no crawl, e os recursos oferecidos são voltados principalmente para usuários individuais da internet
- O servidor DNS usa UDP com fallback para TCP e oferece telemetria pública limitada de segurança
- Consulta de exemplo:
dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt - Isso também pode ser útil para serviços executados na nuvem, mas espera-se contato prévio antes de depender disso operacionalmente
- Consulta de exemplo:
reverse DNS e a exceção do SMTP
- Se o problema fosse apenas o serviço web, poderiam ser usadas outras mitigações, como consultas de reverse DNS
- Provedores de nuvem muitas vezes operam mal o reverse DNS, o que combina com a narrativa de que recursos dentro da nuvem são temporários
- A AWS faz reverse DNS melhor do que muitos outros provedores de nuvem, e consta que é possível configurar reverse DNS da instância, embora isso não tenha sido testado diretamente
- Há uma exceção para SMTP
- Se o problema não for especialmente grave, conexões com o servidor de e-mail são permitidas mesmo quando outros serviços são bloqueados
- Tecnicamente é possível operar SMTP sem reverse DNS correto, mas na prática, sem ele, o outro lado não aceita os e-mails
- Avaliar reverse DNS permite fazer uma avaliação inicial sobre se o SYN veio de um servidor de e-mail legítimo
- Serviços de reputação podem pontuar reverse DNS
- Existem padrões comuns em recursos alugados e temporários
- Só a existência ou o formato do reverse DNS já pode permitir inferir razoavelmente se um endereço pertence a um provedor de nuvem
Por que o bloqueio de endereços da AWS começou
- Isso começou com o bloqueio de netblocks identificáveis de alguns serviços abusivos e depois evoluiu para uma prova de conceito de bloqueio seletivo de pequenos provedores de hospedagem
- No caso da AWS, o ponto de partida foi o tráfego excessivo de ping
- Ping usa um protocolo sem conexão, então a origem pode ser falsificada
- As respostas a pedidos de ping falsificados vão para o local real falsificado, e não para o atacante
- Para conter respostas incessantes de ping, é preciso criar regras temporárias de firewall, mas a escala da Amazon faz o número de regras crescer demais
- Começou-se a coletar faixas de endereços da AWS, e hoje há 53 blocos CIDR representando espaço de endereços da AWS observado como alvo de abuso ou origem de abuso
- Às vezes também são observadas regras temporárias de firewall em número duas vezes maior
- Bloquear crawler e scanner abusivos alugados em provedores de nuvem “too big to fail” é um bom efeito colateral, e não faz falta vê-los desaparecer dos logs web
Impacto para usuários da nuvem
- A maior parte dos recursos populares ou com possibilidade de implantação em nuvem está hospedada no GitHub
- Quem implanta outros recursos na nuvem precisa manter seu próprio repositório para staging
- Se o repositório estiver na AWS, já não será mais possível verificar atualizações
- Será preciso verificar no desktop
- Será preciso verificar em um recurso hospedado de forma privada
- Pode-se discutir um arrangement separado
- Ter apenas um smartphone, um bucket S3 e uma instância EC2 dificilmente significa “estar na internet”, mas no smartphone ainda deveria ser possível acessar esses recursos
Mitigação de apropriação de dados e uso não pretendido
- A apropriação de dados de materiais de código aberto para fins não pretendidos e sem permissão também é uma ameaça que exige mitigação separada
- O bloqueio da AWS também funciona como uma dessas mitigações
- Materiais sobre cats, bunnies e birds também entram nesse contexto de mitigação
- cats e bunnies aparecem porque há muitos vídeos relacionados e alguns podem ser comprados
- birds são mais eficazes na camada 2 do modelo OSI e estão documentados em RFC como método de transporte de datagramas IP
Informações públicas necessárias dos grandes provedores de nuvem
- Grandes provedores de nuvem deveriam oferecer um sistema melhor de distribuição de informações forenses do que o atual
- DNS e whois podem ser ferramentas para distribuir informações potencialmente úteis
- Um provedor grande deveria ser capaz de operar seu próprio reverse DNS
- Pode ser necessário whois por endereço individual, informações adicionais codificadas no reverse DNS e informações públicas separadas no namespace DNS
- Um storm center blog tratando padrões atuais de abuso e blocos de endereços afetados também é uma possibilidade
- No SMTP, além de reverse DNS, existe SPF publicado em registros DNS TXT
- Deve ser possível encontrar, a partir de um único endereço IP, informações que respondam às seguintes perguntas
- O recurso por trás desse endereço envia ping?
- Quanto ping ele envia?
- Ele cria conexões TCP de saída?
- Para quais serviços ele se conecta?
- Quem controla esse recurso?
- O recurso está sob ataque?
- Que tipo de ataque é esse?
- Que mitigação outros recursos na internet gostariam que fosse oferecida?
- Mitigação adequada ajuda todos, mas mitigação mal direcionada não ajuda
Consequências de uma internet fragmentada
- Se essa prática se espalhar, ela pode levar a uma balkanized internet
- Pessoas que vivem sua vida online dentro da bolha dos grandes provedores de nuvem podem nem perceber a maior parte do inconveniente
- Mesmo quando perceberem, podem interpretar isso como consequência de terem escolhido um provedor de nuvem específico
1 comentários
Comentários do Hacker News
Todos os grandes provedores de nuvem publicam listas de faixas de IP legíveis por máquina
Ex.: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
https://www.microsoft.com/en-us/download/details.aspx?id=565...
https://support.google.com/a/answer/10026322?product_name=Un... etc.
Não pretendo entrar no jogo de “vamos bloquear a lista JSON gigantesca da Amazon”; minhas regras são só 53. Posso aceitar alguns efeitos colaterais, e os sites que estão na AWS também continuam acessando bem
Hoje em dia, na internet, a velocidade com que tráfego agressivo aparece assim que você expõe infraestrutura é absurda
Recentemente anunciei via BGP uma sub-rede /23 para uma configuração anycast e, assim que a rota subiu e o tráfego começou a fluir para o roteador, o tcpdump explodiu com port scans para todos os IPs da faixa
Claro que não foi por causa da rota em si; parece que muitos agentes fazem varredura indiscriminada e contínua de todas as faixas de IP. Essa faixa não era anunciada havia anos, então também não estava em alguma lista de servidores ativos de alguém
É chocante que serviços web internos, como GitLab, ainda sejam expostos diretamente à internet. Acho que, no mínimo, deveria haver uma camada adicional de proteção, como uma VPN, para que o serviço não seja descoberto na internet pública
A única coisa acessível publicamente é o SSH de um único bastion host, e mesmo isso eu gostaria de eliminar depois colocando uma camada de VPN por cima
Assim como há radiação de fundo quando você vai ao espaço, há radiação de fundo da internet quando você vai para a internet. Se você não estiver rodando serviços vulneráveis, esses port scans têm um risco parecido com comer uma banana a mais por mês
Só incomoda porque você está vendo diretamente no console. É como embarcar em um avião com um contador Geiger sensível demais: você pode se assustar, mas, se não soubesse, isso não faria mal
Eu também me surpreendo com serviços internos expostos à internet, por dois motivos: não confio nos sistemas de autenticação da maioria dos programas e não quero divulgar para fora quais serviços internos uso. Também há motivos mais ligados à privacidade do que à segurança puramente técnica
Por outro lado, coisas que precisam estar na internet e que têm uma porta de entrada forte, ou que acredito estarem suficientemente em sandbox, podem ficar na internet o dia todo
Port scan é a versão da internet de andar pela cidade anotando quais casas estão com as luzes acesas. Pode parecer meio stalker, mas é informação pública
A propósito,
ssh -wcria uma interface de túnel VPN, mas não configura automaticamente o restante como um produto de VPN de verdade fariaA internet parece cada vez mais algo que acontece por trás da blackwall de Cyberpunk
Se você ativasse os logs de acessos negados do firewall, tentativas contra portas conhecidas e desconhecidas chegavam continuamente, para sempre
Se você expõe alguma coisa, mesmo que seja um componente web escondido bem no fundo, precisa garantir que ele não se torne uma porta de entrada para seus dados e sua infraestrutura
O que mudou um pouco desde então são as origens do tráfego e os critérios para decidir se você deve aceitar ou bloquear. A quantidade de servidores e serviços legítimos, proxies do lado de usuários finais, provedores de nuvem e crawlers aumentou muito
É realmente uma pena. Se fizer isso, seu conteúdo não aparecerá de forma alguma nos mecanismos de busca, também não será capturado pelo Marginalia e corre o risco de não ser salvo nem no Wayback Machine
Se é isso que a pessoa quer originalmente, talvez faça sentido bloquear todas as nuvens e data centers. Dependendo até de onde um pequeno ISP opera seu gateway de CGNAT, isso poderia acabar bloqueando também os usuários desse ISP. É improvável, mas não impossível
O único abuso real mencionado no texto parece ser ping com endereço de origem falsificado. Não dá para saber se os pacotes de ping falsificados vieram da AWS. O endereço de origem é o endereço para o qual o falsificador quer que a resposta seja enviada, não o endereço do falsificador
Uma mitigação muito menos invasiva seria aplicar limite de taxa aos pings, algo como 10 por segundo
A internet está mesmo se balcanizando, mas a principal causa é menos o bloqueio de faixas de IP e mais o isolamento das redes sociais em silos para receita de anúncios e dados, além do movimento de extrair receita de dados de treinamento de IA. Casos como o acordo exclusivo Reddit/Google estão mais próximos disso
É difícil entender a mentalidade de bloquear um provedor específico por causa de alguns pings e ao mesmo tempo reclamar que a conectividade IP está se balcanizando. Quem cria a balcanização é quem bloqueia
Faz bastante tempo que não vejo blogs pessoais ou pequenos sites de hobby nos resultados de busca
Se preciso da Wikipedia ou do Stack Overflow, posso pesquisar diretamente nesses sites. Eu gostaria que houvesse uma opção para excluir os “candidatos de sempre” e ver conteúdos de cauda mais longa
Dito isso, o tom geral soa mais como transformar uma picada de mosquito numa grande narrativa histórica
Operar um gateway de CGNAT na nuvem traria muitos problemas. Como os assinantes deixariam de ter IPs residenciais, talvez não conseguissem assistir a serviços como Netflix, e provavelmente encontrariam CAPTCHAs antibot da Cloudflare ou do Google com mais frequência
Fico curioso se há casos reais conhecidos disso
Já venho bloqueando Hetzner, DigitalOcean, Linode, OVH e Contabo há algum tempo
Dá para fazer isso no pfBlocker NG com bloqueio por ASN, ou também com regras do UFW: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...
Por exemplo, se uma organização opera sua própria solução WireGuard ou outra VPN sobre um provedor de nuvem, e as pessoas acessam por ali, o IP de saída passa a parecer um IP do provedor de nuvem
Dá até para automatizar isso. Assim seria justo e cada parte saberia o que está acontecendo. Caso contrário, em vez dessas brincadeiras de caixa de areia, que usem armas de verdade
A primeira coisa em que pensei foi que desktops reais rodando na AWS, especialmente serviços como Amazon Workspaces, poderiam ser bloqueados
Ainda assim, parece que o espaço de IP desses serviços também é documentado publicamente, então, se necessário, esses IPs poderiam ser permitidos separadamente
Mesmo assim, usando um proxy ou VPN, é muito fácil contornar esse tipo de bloqueio
Muito tempo atrás, dezenas de servidores da Amazon começaram a deixar nossos servidores on-premises lentos, então fizemos isso
Talvez fosse algum tipo de tentativa de SSO, mas nunca conseguimos rastrear completamente. Simplesmente escrevemos um script que baixava periodicamente a lista de faixas de IP da Amazon e bloqueava todas elas, e seguimos em frente
Eu entendo. Se eu quisesse cercar com um muro uma grande parte da internet em algo que criei, faria a mesma coisa. Não é muito diferente de bloquear países inteiros
Também entendo a vontade de reduzir o ruído e permitir apenas um “pequeno grupo de amigos”
Mas eu faço isso apenas para serviços específicos, não para um domínio inteiro. Meu servidor Mumble fica aberto só para os 3 ou 4 países onde meus amigos estão, excluindo provedores de nuvem. Meu blog técnico fica aberto para qualquer pessoa no mundo
Estou firmemente do lado de que conhecimento compartilhado beneficia todo mundo. Se minhas anotações sobre a string de inicialização de modem de um modem C64 de 300 baud ajudarem uma única pessoa, essa pessoa não repetirá o sofrimento pelo qual passei, e o mundo ficará um pouco melhor
Entendo que esse desejo possa surgir por vários motivos. Tudo bem. Cada um faz como achar melhor
A Amazon é grande demais para ser ignorada. Entendo que muito do tráfego ICMP e SYN é lixo. Eu também quero ajudar a bloquear e, na prática, já tenho mitigações ativadas por padrão
O problema é que a Amazon mexe nas minhas mitigações “em escala”, e isso é uma dor de cabeça. A Amazon não ajuda a separar o joio do trigo. É do tipo “envie um PCAP sobre o problema de ping”
Se eu envio material para a Amazon e não recebo resposta alguma, não há nada a aprender. Não preciso do tráfego bom nem do ruim, nem do tráfego falsificado que ataca eles
Se eles não pretendem me ajudar a ajudá-los, não preciso de nada disso. Estou apenas mantendo minha vida simples
Quando vejo coisas assim, sinto saudade da antiga internet. É realmente difícil explicar como a internet antes da comercialização era incrível
O prazer amargo de ter acertado exatamente que o resultado seria esse não chega nem perto de compensar o que foi perdido
A AWS é nível escoteiro em comparação com DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent e até lugares como o Google
Em especial, acho que a DigitalOcean cometeu um erro terrível ao fazer marketing para a comunidade de “cibersegurança”
Declaração de conflito de interesse: a AWS é minha empregadora atual
Posso estar deixando passar algo óbvio, mas, se o autor acredita que o tráfego de ping foi falsificado, como ele sabe que a origem é a AWS?
Pela minha experiência, vi vezes demais casos em que a AWS era a origem de um volume esmagador de tráfego e, em alguns deles, chegamos à mesma solução: bloquear a AWS inteira
Não sei se a AWS não se importa ou se a resposta é lenta. Talvez denunciar seja difícil demais
O ponto óbvio que ficou de fora é este: a AWS é uma fonte gigantesca de tráfego “ruim”, é difícil demais fazer clientes problemáticos serem suspensos, enquanto é fácil demais para agentes maliciosos alugarem capacidades absurdas
Quase nunca vi a GCP ou o Azure serem fontes do mesmo nível de tráfego insano