Blocage des connexions depuis AWS vers mes services on-premise
(consulting.m3047.net)- L’Internet public pourrait se scinder en un écosystème fragmenté centré sur les grands fournisseurs de cloud, et le blocage des accès depuis AWS vers des services on-premise en est un exemple opérationnel
- Le blocage vise principalement les tentatives de connexion TCP ouvertes par des clients situés dans AWS vers des services on-premise ; les connexions sortantes de clients locaux vers des services hébergés sur AWS restent possibles
- Les services on-premise exploités sont le web, une démo Trualias, DNS et SMTP ; DNS propose UDP, un fallback TCP et un accès public limité à de la télémétrie de sécurité
- Le blocage d’AWS a commencé en réponse à un trafic ping excessif et à des crawlers/scanners abusifs ; 53 CIDR d’espaces d’adressage AWS observés comme cibles ou sources d’abus sont actuellement gérés
- Si les grands fournisseurs de cloud ne publient pas mieux les informations forensiques comme le reverse DNS, le whois, les espaces de noms DNS et les schémas d’abus, la fragmentation pourrait s’accentuer sans que les utilisateurs à l’intérieur du cloud ne ressentent beaucoup d’inconvénients
Risque de fragmentation créé par les grands clouds
- Si les grands fournisseurs de cloud deviennent une bulletproof infrastructure « too big to fail », ils peuvent provoquer directement une fragmentation d’Internet
- Le phénomène n’est pas encore pleinement concrétisé, mais il est considéré comme déjà amorcé ou susceptible d’apparaître bientôt
- L’écosystème cloud native dispose d’une infrastructure sur mesure par rapport à l’Internet réel, et chaque service cloud est organisé autour de fonctionnalités distinctives plutôt que d’une architecture commune
- De nombreux services fonctionnent de manière autonome au sein d’un cloud donné, avec des obstacles à une interopérabilité transparente avec l’Internet général
- La communauté cloud native traite l’Internet général comme une ressource externe et interagit davantage avec l’écosystème d’un fournisseur cloud particulier qu’avec Internet lui-même
La dynamique de commercialisation de l’Internet public
- Avant 1989, Internet n’était pas ouvert au grand public et constituait un réseau de nature privée utilisé par des organismes gouvernementaux, militaires, de recherche et d’éducation
- La NSF gérait le cœur du backbone, et le premier accès public a été autorisé sous condition de trafic non commercial
- Les services commerciaux eux-mêmes n’étaient pas interdits, mais le trafic transitant par le backbone NSFNet ne devait pas être du trafic publicitaire ni lié à des services payants
- Des opérateurs commerciaux ont construit un Internet commercial séparé, et en 1995 la NSFNet a désactivé l’accès public
- Après la grande vague d’élimination autour de l’an 2000, les modèles fondés sur la publicité basée sur les données comportementales des utilisateurs et sur la vente de ces données ont survécu
- Dans la vague actuelle de l’IA, le point marquant est la collecte massive de contenus accessibles, leur blanchiment et leur utilisation pour entraîner des modèles ; la curation et l’entraînement se font principalement dans le cloud, et de plus en plus par les fournisseurs de cloud eux-mêmes
Blocage des connexions AWS vers des services on-premise
- La plupart des accès entrants depuis AWS vers les serveurs on-premise sont désactivés
- Techniquement, l’intérêt porte surtout sur le trafic TCP, car le handshake initial permet de distinguer client et serveur
- Les tentatives de connexion depuis un client dans AWS vers un service on-premise sont bloquées
- Les connexions depuis un client du réseau local vers un service hébergé sur AWS sont possibles
- Plusieurs services exposés sur Internet sont exploités localement
- Service web
- Démo Trualias
- Serveur DNS
- Serveur e-mail SMTP
- Une politique no crawl est maintenue depuis plusieurs années, et les ressources fournies visent principalement des utilisateurs individuels sur Internet
- Le serveur DNS utilise UDP et un fallback TCP, et fournit une télémétrie de sécurité publique limitée
- Exemple de requête :
dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt - Elle peut aussi être utile à des services exécutés dans le cloud, mais il est attendu de prendre contact avant d’en dépendre en production
- Exemple de requête :
Reverse DNS et exception SMTP
- Si seuls les services web posaient problème, d’autres mesures d’atténuation comme la résolution reverse DNS pourraient être utilisées
- Les fournisseurs de cloud exploitent souvent mal le reverse DNS, ce qui correspond au récit selon lequel les ressources dans le cloud sont temporaires
- AWS fait plutôt mieux le reverse DNS que beaucoup d’autres fournisseurs de cloud, et il paraît possible de configurer le reverse DNS d’une instance, même si cela n’a pas été essayé directement
- Une exception est faite pour SMTP
- Si les problèmes ne sont pas particulièrement graves, les connexions au serveur mail sont autorisées même si les connexions aux autres services sont bloquées
- Techniquement, il est possible d’exploiter SMTP sans reverse DNS exact, mais en pratique, sans reverse DNS exact, les correspondants n’acceptent pas le courrier
- L’évaluation du reverse DNS permet de porter un jugement initial sur la légitimité d’un SYN provenant d’un serveur mail
- Les services de réputation peuvent noter le reverse DNS
- Des motifs fréquents existent pour les ressources louées et temporaires
- La seule présence ou forme du reverse DNS permet d’estimer raisonnablement si une adresse appartient à un fournisseur de cloud
Pourquoi le blocage des adresses AWS a commencé
- Le point de départ a été le blocage de netblocks identifiables de certains services abusifs, puis cela s’est prolongé par une preuve de concept de blocage sélectif de petits hébergeurs
- Dans le cas d’AWS, le déclencheur a été un trafic ping excessif
- Ping est un protocole sans connexion, dont l’adresse source peut être falsifiée
- Les réponses à des requêtes ping falsifiées partent non pas vers l’attaquant, mais vers l’emplacement réel usurpé
- Pour supprimer des réponses ping incessantes, il faut créer des règles de pare-feu temporaires, mais l’échelle d’Amazon est telle que le nombre de règles devient élevé
- La collecte des plages d’adresses AWS a commencé, et il existe aujourd’hui 53 CIDR représentant l’espace d’adressage AWS observé comme cible ou source d’abus
- On observe parfois deux fois plus de règles de pare-feu temporaires
- Bloquer les crawlers et scanners abusifs loués chez un fournisseur cloud « too big to fail » est un bon effet secondaire, et leur disparition des logs web n’est pas regrettée
Impact sur les utilisateurs du cloud
- La plupart des ressources populaires ou susceptibles d’être déployées dans le cloud sont hébergées sur GitHub
- Les personnes qui déploient d’autres ressources dans le cloud doivent maintenir leur propre dépôt à utiliser pour le staging
- Si le dépôt se trouve sur AWS, il n’est plus possible de vérifier les mises à jour
- Il faut le faire depuis un ordinateur de bureau
- Depuis une ressource hébergée en privé
- Un arrangement séparé peut être discuté
- Il est difficile de considérer qu’on est « sur Internet » avec seulement un smartphone, un bucket S3 et une instance EC2, mais ces ressources devraient être accessibles depuis un smartphone
Atténuation du vol de données et usages non prévus
- Le vol de données, où des ressources open source sont détournées sans autorisation à des fins non prévues, est aussi une menace nécessitant une atténuation distincte
- Le blocage d’AWS fonctionne également comme l’une de ces mesures d’atténuation
- Des ressources liées aux cats, bunnies et birds sont aussi traitées dans le contexte de l’atténuation
- Les cats et bunnies apparaissent parce qu’il existe beaucoup de vidéos associées et que certaines sont disponibles à l’achat
- Les birds sont plus efficaces à la couche 2 de l’OSI, et sont documentés dans une RFC comme méthode de transmission de datagrammes IP
Informations publiques nécessaires de la part des grands fournisseurs cloud
- Les grands fournisseurs de cloud doivent fournir un meilleur dispositif de diffusion des informations forensiques
- DNS et whois peuvent être des outils de diffusion d’informations potentiellement utiles
- Un grand opérateur devrait être capable d’exploiter son propre reverse DNS
- Des informations whois pour les adresses individuelles, des informations supplémentaires encodées dans le reverse DNS et des informations publiques séparées dans l’espace de noms DNS peuvent être nécessaires
- Un storm center blog traitant des schémas d’abus actuels et des blocs d’adresses affectés est aussi une option possible
- Pour SMTP, il existe non seulement le reverse DNS, mais aussi SPF publié sous forme d’enregistrements DNS TXT
- À partir d’une seule adresse IP, il devrait être possible de trouver des informations répondant aux questions suivantes
- La ressource derrière cette adresse envoie-t-elle des ping ?
- Combien de ping envoie-t-elle ?
- Établit-elle des connexions TCP sortantes ?
- À quels services se connecte-t-elle ?
- Qui contrôle la ressource ?
- La ressource est-elle attaquée ?
- De quel type d’attaque s’agit-il ?
- Quelles mesures d’atténuation les autres ressources d’Internet souhaitent-elles voir proposées ?
- Une atténuation appropriée aide tout le monde, mais une atténuation mal ciblée ne le fait pas
Conséquences d’un Internet fragmenté
- Si cette approche se généralise, elle pourrait mener à un balkanized internet
- Les personnes qui vivent en ligne dans la bulle des grands fournisseurs de cloud pourraient ne presque pas remarquer les désagréments
- Les désagréments qu’elles remarquent pourraient être interprétés comme la conséquence du choix d’un fournisseur cloud particulier
1 commentaires
Avis de Hacker News
Les principaux fournisseurs de cloud publient tous des listes de plages d’IP lisibles par machine
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.
Je n’ai pas l’intention de jouer à des jeux du genre « essayons de bloquer l’énorme liste JSON d’Amazon », et je n’ai que 53 règles. Je peux accepter un certain niveau d’effets de bord, et les sites hébergés chez AWS restent accessibles
De nos jours, sur Internet, la vitesse à laquelle du trafic agressif arrive dès qu’on expose une infrastructure est folle
Récemment, pour une configuration anycast, j’ai annoncé via BGP un sous-réseau /23 ; dès que la route est montée et que le trafic a commencé à arriver sur le routeur, tcpdump s’est emballé avec des scans de ports sur toutes les IP de la plage
Bien sûr, ce n’est pas dû à la route elle-même : il semble que beaucoup d’acteurs scannent toutes les plages d’IP sans distinction et en continu. Cette plage n’avait pas été annoncée depuis des années, donc elle ne figurait pas non plus dans la liste de serveurs actifs de quelqu’un
Je trouve choquant que des services web internes comme GitLab soient encore exposés tels quels sur Internet. À mon avis, il faut au minimum une couche de protection supplémentaire comme un VPN, afin que le service ne puisse pas être découvert depuis l’Internet public
La seule chose accessible publiquement est le SSH d’un unique hôte bastion, et même cela, j’aimerais finir par le supprimer en ajoutant une couche VPN
Comme il y a un rayonnement de fond dans l’espace, il y a un rayonnement de fond sur Internet. Si vous ne faites pas tourner de services vulnérables, ce type de scan de ports présente un risque comparable à manger une banane de plus par mois
C’est seulement agaçant parce que vous le voyez directement dans la console. C’est comme monter dans un avion avec un compteur Geiger hypersensible : cela peut surprendre, mais si vous ne le savez pas, cela ne vous fait pas de mal
Moi aussi, je suis surpris par l’exposition de services internes sur Internet, pour deux raisons. Je ne fais pas confiance aux systèmes d’authentification de la plupart des programmes, et je ne veux pas faire savoir à l’extérieur quels services internes j’utilise. Certaines raisons relèvent davantage de la vie privée que de la sécurité technique pure
À l’inverse, ce qui doit être sur Internet, dispose d’une porte d’entrée solide ou est suffisamment sandboxé, peut rester sur Internet toute la journée
Un scan de ports, c’est l’équivalent Internet de se promener en ville en notant quelles maisons ont la lumière allumée. Ça peut faire un peu stalker, mais c’est de l’information publique
À noter que
ssh -wcrée une interface de tunnel VPN, mais ne configure pas automatiquement le reste comme le ferait un vrai produit VPNInternet ressemble de plus en plus à ce qui se passe derrière le blackwall de Cyberpunk
Si l’on activait les logs d’accès refusés du pare-feu, les tentatives sur des ports connus et inconnus arrivaient en permanence
Si vous exposez quelque chose, même un composant web profondément caché, il faut éviter que cela devienne une porte d’entrée vers vos données et votre infrastructure
Ce qui a un peu changé depuis, c’est l’origine du trafic et les critères permettant de décider s’il faut l’accepter ou le bloquer. Le nombre de serveurs et services légitimes, de proxys côté utilisateurs finaux, de fournisseurs cloud et de crawlers a beaucoup augmenté
C’est vraiment dommage. En faisant cela, son contenu risque de ne pas apparaître du tout dans les moteurs de recherche, de ne pas être indexé par Marginalia, et de ne pas être archivé par la Wayback Machine
Si c’est bien l’objectif, alors il peut être cohérent de bloquer tous les clouds et datacenters. Selon l’endroit où un petit FAI fait tourner sa passerelle CGNAT, on pourrait même bloquer les utilisateurs de ce FAI. C’est peu probable, mais pas impossible
Le seul abus réel mentionné dans l’article semble être des pings avec une adresse source usurpée. On ne peut pas savoir si ces paquets ping usurpés venaient d’AWS. L’adresse source est celle à laquelle l’usurpateur veut envoyer les réponses, pas l’adresse de l’usurpateur
Une mesure d’atténuation bien moins intrusive consisterait à limiter le débit des pings à environ 10 par seconde
Internet est certes en train de se balkaniser, mais la cause principale est plutôt la siloïsation des réseaux sociaux pour monétiser la publicité et les données, ainsi que la volonté de tirer profit des données d’entraînement de l’IA, davantage que le blocage de plages IP. Des exemples comme l’accord exclusif Reddit/Google s’en rapprochent davantage
Il est difficile de comprendre l’état d’esprit qui consiste à bloquer un fournisseur pour quelques pings tout en se plaignant de la balkanisation de la connectivité IP. Celui qui crée la balkanisation, c’est celui qui bloque
Cela fait longtemps que je n’ai pas vu de blogs personnels ou de petits sites de passionnés dans les résultats de recherche
Si j’ai besoin de Wikipedia ou de Stack Overflow, je peux chercher directement sur ces sites. J’aimerais qu’il existe une option pour exclure les “candidats habituels” et voir davantage de contenus de longue traîne
Cela dit, le ton général donne plutôt l’impression de transformer une piqûre de moustique en grande fresque historique
Exploiter une passerelle CGNAT dans le cloud poserait beaucoup de problèmes. Les abonnés n’auraient plus des IP résidentielles, donc ils pourraient ne pas pouvoir regarder des services comme Netflix, et ils risqueraient de tomber plus souvent sur des CAPTCHA anti-bots chez Cloudflare ou Google
Je me demande s’il existe des cas réellement connus
Hetzner, DigitalOcean, Linode, OVH et Contabo sont bloqués depuis un moment
On peut le faire avec le blocage par ASN dans pfBlocker NG, ou avec des règles UFW : https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...
Par exemple, une organisation peut exploiter elle-même WireGuard ou une autre solution VPN sur un fournisseur cloud, et si des personnes passent par là pour se connecter, leur IP de sortie apparaîtra comme une IP du fournisseur cloud
On pourrait même automatiser ça. Ce serait équitable, et chaque partie saurait ce qui se passe. Sinon, autant utiliser de vraies armes plutôt que ces jeux de bac à sable
Ma première pensée a été que cela pouvait bloquer de vrais postes de travail tournant sur AWS, en particulier des services comme Amazon Workspaces
Cela dit, l’espace IP de ces services semble aussi documenté publiquement, donc on peut autoriser ces IP séparément si nécessaire
Malgré tout, avec un proxy ou un VPN, il est très facile de contourner ce genre de blocage
Il y a longtemps, des dizaines de serveurs Amazon ont commencé à ralentir notre serveur on-premise, alors nous avons fait ça
C’était peut-être une sorte de tentative de SSO, mais nous n’avons jamais réussi à le retracer complètement. Nous avons simplement écrit un script qui télécharge périodiquement la liste des plages IP d’Amazon et les bloque toutes, puis nous sommes passés à autre chose
Je comprends. Si je voulais murer de grandes zones d’Internet hors de ce que j’ai créé, je ferais la même chose. Ce n’est pas très différent du blocage d’un pays entier
Je comprends aussi l’envie de réduire le bruit et de n’autoriser qu’un “petit groupe d’amis”
Cela dit, je le fais seulement pour certains services, pas pour tout le domaine. Mon serveur Mumble n’est ouvert qu’aux 3 ou 4 pays où se trouvent mes amis, et les fournisseurs cloud sont exclus. Mon blog technique, lui, reste accessible au monde entier
Je suis fermement convaincu que le savoir partagé profite à tout le monde. Si mes notes sur la chaîne d’initialisation du modem d’un modem C64 à 300 bauds aident ne serait-ce qu’une seule personne, cette personne n’aura pas à revivre ma galère, et le monde sera un peu meilleur
Je comprends que cette envie puisse naître pour de multiples raisons. C’est acceptable. Chacun fait comme il l’entend
Amazon est trop grand pour être ignoré. Je comprends qu’une grande partie du trafic ICMP et SYN soit du déchet. Moi aussi, j’aimerais aider au blocage, et j’ai d’ailleurs déjà des mesures d’atténuation en place par défaut
Le problème, c’est qu’Amazon touche à mes mesures d’atténuation “à grande échelle”, et c’est ce qui pose souci. Amazon n’aide pas à séparer le bon grain de l’ivraie. C’est du genre : “envoyez un PCAP pour le problème de ping”
Si j’envoie des éléments à Amazon et que je n’ai jamais de réponse, je n’apprends rien. Je n’ai pas particulièrement besoin du bon trafic, ni du mauvais trafic, ni du trafic usurpé qui les attaque
S’ils n’ont pas l’intention de m’aider à les aider, alors je n’ai besoin de rien de tout ça. Je me contente de garder ma vie simple
Quand je vois ce genre de choses, l’ancien Internet me manque. C’est vraiment difficile d’expliquer à quel point Internet était formidable avant sa commercialisation
Le plaisir amer d’avoir prédit avec exactitude que cela finirait ainsi est loin de compenser ce que nous avons perdu
AWS, c’est du scoutisme par rapport à DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent, et même Google
En particulier, je pense que DigitalOcean a commis une terrible erreur en faisant du marketing auprès de la communauté de la « cybersécurité »
Déclaration d’intérêt : AWS est actuellement mon employeur
Je passe peut-être à côté de quelque chose d’évident, mais si l’auteur pense que le trafic ping a été usurpé, comment peut-il savoir qu’AWS en est la source ?
Par expérience, j’ai vu trop de cas où un trafic écrasant provenait d’AWS, et dans certains cas on en est arrivé à la même solution : bloquer tout AWS
Je ne sais pas si AWS s’en moque ou si sa réaction est lente. Il est aussi possible que les signalements soient trop difficiles à faire
Le point évident qui vous échappe est celui-ci : AWS est une source massive de « mauvais » trafic, et il est trop difficile de suspendre les clients qui déraillent, tandis qu’il est beaucoup trop facile pour des acteurs malveillants de louer des capacités absurdes
Je n’ai presque jamais vu GCP ou Azure être des sources de trafic délirant au même niveau