Le Bruit de fond d'Internet

À l'instar des ondes électromagnétiques baignant le cosmos, les acteurs qui scannent Internet génèrent également un « bruit de fond ». Il est permanent, mais varie dans son intensité selon les périodes. En moins de 10 ans, la population d’utilisateurs actifs sur Internet a décuplé. Le business réalisé en ligne chaque jour a explosé et la crise sanitaire n'a fait que renforcer cette tendance. Cette accélération de l’usage s’accompagne d’une adaptation des pirates qui, eux aussi, scannent continuellement et plus fréquemment que jamais le 0/0 (toutes les adresses IPv4 d’Internet).

Robots et scripts s’emploient, inlassablement et dans des buts très différents, à inventorier les machines et services disponibles en ligne.

1. La fin des bastions

Pendant quatre décennies, les DSI ont pu cantonner et protéger leurs serveurs et données au sein d'une DMZ. Un firewall arbitrait, pour chaque IP, où elle pouvait se rendre et quelles ressources du LAN elle pouvait interroger depuis la DMZ.

Avec l'avènement des Clouds publics, des Clouds drives, des containers, de l'IoT et des services en SaaS, ce sentiment de sécurité a volé en éclat. À l’image de Gandalf sur le pont de la mine de la Moria, le firewall ne pouvait plus assurer son rôle en tant que seul point de contrôle.

Les données se sont répandues partout sur Internet pendant que le bastion et les murs du château s’effaçaient. Ces ressources étant souvent, directement ou indirectement, accessibles au travers d'IP publiques, les pirates se sont découvert un intérêt renouvelé pour l'art du scan. Ils ne procèdent pas uniquement sur la surface IP, beaucoup se chargent aussi de la couche logique dans les applications exposées, mais la pratique du scan massif est loin d'avoir régressé, comme nous allons le voir.

2. Les acteurs

D’après une étude sur le réseau de honeypots de CrowdSec, une adresse IPv4 est scannée entre 300 et 1000 fois par jour. Ces honeypots sont délibérément placés dans différents contextes (VM en Cloud, Box sur ADSL ou Fibre, serveurs OVH, etc.) et le rythme de scan semble varier selon l’hébergeur, la connectivité et le contexte technologique.

En essayant de lister les acteurs des différentes catégories, on se rend compte qu’ils sont nombreux : les groupes de recherche, les hackers en chasse de proies faciles, ceux préparant un inventaire de machines à exploiter plus tard, les opportunistes opérant des recherches contextuelles suite à une nouvelle faille (par exemple la dernière en date sur WordPress), sans oublier les robots d’indexation, les scrappers de contenus HTTP (par exemple, surveillance de prix dans le domaine du eCommerce) et bien d’autres.

Dans la catégorie des acteurs sans mauvaises intentions, on trouve des sociétés ou associations comme ShodanHQ, Builtwith, Censys ou encore Onyphe, qui scannent continuellement Internet pour évaluer différents facteurs, audience, progression de l'IPv6, parts de marché des technologies, etc. De nombreux projets de recherches sont également actifs, comme par exemple le projet Ivre.rocks [1] du CEA et des sociétés de « Threat intelligence » opèrent parfois des scanners complémentaires pour qualifier une menace potentielle. Dans la catégorie des hyperactifs, on retrouve essentiellement les pirates essayant de compromettre des points d'accès Remote Desktop, VPN, SSH ou Active Directory, probablement pour y injecter des ransomwares.

Les « archivistes », eux, scannent certains ports pour garder les bannières d’accueil des logiciels utilisés afin de revenir les compromettre quand une faille compatible sera disponible. La population des opportunistes est assez inefficace comparativement à ces groupes très organisés. Si des centaines de milliers de WordPress sont compromis en quelques heures, cela indique que les opportunistes qui lancent le scan quand la faille est révélée ont déjà quelques jours de retard.

Une évolution notable réside dans le fait que certaines plages d’IP sont utilisées pour fragmenter les scans d’un grand nombre de ports, mais à l’échelle de toute adresse IPv4 publique. Le travail reste titanesque, mais s’il est bien organisé et automatisé, il peut être divisé sur de nombreuses machines et depuis diverses IP. Contrairement à ce qui pouvait techniquement être réalisé il y a une décennie, tout laisse à penser que ces scans massifs deviennent très productifs.

3. Contexte et statistiques brutes

Afin d’illustrer le propos, voici une séquence capturée sur 1 mois, très exactement du 23 septembre 2019 au 23 octobre 2019. La machine ne faisait tourner aucun service public, aucun enregistrement DNS ne reliait son IP à un nom de domaine, en dehors du reverse DNS de l’opérateur. Elle disposait d'une IPv4 fixe (l’IPv6 est désactivé sur cette machine), fournie par une offre fibre « Red by SFR ». La machine était connectée quasi en direct puisque la box de l'opérateur était en mode pass-through / DMZ.

Durant la période d'observation, 22 675 IP différentes ont scanné des ports TCP, 5 254 des ports UDP, et 186 IP ont envoyé des probes ICMP. Encore une fois, cette machine n'hébergeant rien, toutes ces requêtes étaient non sollicitées.

En ce qui concerne les ports, 49 875 ports TCP et 8 460 ports UDP différents ont été scannés.

4. Analyse des données

Le premier facteur étonnant est que le nombre d’IP scannant cette box SFR était, en moyenne, de 937 par jour. Sur une période d’un mois, ce nombre de scans quotidien est trop élevé pour que cela soit un hasard et l'écart type à la moyenne est faible. Nous constatons donc bien un rythme de croisière. Lors de nos premiers tests (il y a 7 ans), ce rythme était de 50.

Sur la période, 2,5 fois plus d’objets connectés ont été reliés à Internet, bien que principalement derrière un équipement de type NAT et non exposés directement. Ceci étant, lorsqu’ils se retrouvent directement exposés au travers d’IPv6, qui n’impose pas de NAT vu l’étendue du nombre d’IP disponibles, cela mène à des désastres. Comme l’a montré le botnet Mirai, l’IPv6 n’est pas encore bien maîtrisé par tous les administrateurs et les équipements sont parfois mal configurés. Le nombre d’IPv4 utilisées étant assez constant (la crise de l’IPv4 ne date pas de 2015), l’augmentation de l’activité de scan (scouting) sur Internet est donc très claire.

Considérons maintenant le nombre de ports scannés. Bien que seulement quelques ports concentrent la majorité de l’attention, près de 50 000 ports TCP différents ont été scannés, ainsi que plus de 8000 en UDP, toujours sur la même période. Étrangement, cette machine ne représentait rien de spécial pour qui que ce soit et ne faisait donc probablement pas l’objet d’une attaque ciblée ou d’une attention particulière. Au-delà de l’augmentation de la fréquence des scans, le nombre de ports scannés a lui aussi augmenté en flèche.

Alors pourquoi prendre plusieurs minutes pour y vérifier des milliers de ports ? Certes, la majorité des IP n’a scanné que quelques ports, mais une partie d’entre elles a passé des centaines (ou plus) de ports en revue, en général en utilisant plusieurs IP sources appartenant à la même plage d’adresses, pour accélérer le processus. Certains attaquants utilisent donc des centaines d’IP, non pas pour scanner quelques ports plus rapidement, mais une quantité beaucoup plus importante de ports par IP.

Sur un mois, ce sont plus de 20 000 IP qui ont scanné des ports TCP et plus de 5 000 en UDP. L’UDP semble en retrait, mais il ne faut pas se fier au volume brut. Certains protocoles basés sur UDP sont d’un grand intérêt pour les pirates (FTP, VPN, partage d’écran, etc.) et l’UDP est le protocole idéal pour les DrDOS, les dénis de service distribués, par réflexion. Comme l’UDP ne vérifie pas (ou plus exactement « optionnellement ») l’expéditeur du paquet et n'impose pas de « three way hand-shake » comme le TCP, c’est un protocole très souvent utilisé pour le spoofing, nécessaire aux DrDOS. En ce qui concerne l’UDP, les statistiques des IP sources peuvent être faussées, pour les mêmes raisons.

Bien que représentant seulement le quart de l’intérêt porté au TCP, l’UDP a bel et bien le vent en poupe et notamment le service OpenVPN, ce qui semble tout sauf étonnant. Le port 55 est nettement plus surprenant, car il correspond officiellement à un protocole assez anodin, l’ISI Graphic Language. On peut imaginer que ce n’est probablement pas ce protocole qui est recherché, mais peut-être une backdoor ou un C&C de malware, ou encore un bruit de fond de l’expérience, l’UDP étant plus complexe à filtrer sur le firewall ayant effectué la capture (car stateless).

Sans surprise, la recherche de VPN est à la mode, ce qui se traduit par de nombreux scans du port 500, utilisé par IPsec. Les autres n’étaient pas pertinents et correspondaient probablement à des ports hauts utilisés pour des réponses de machines du LAN (idem, plus complexes à filtrer avec tcpdump puisqu’on a pas de flags).

Du côté des protocoles TCP, il semble plus surprenant de découvrir que Telnet a encore la cote. En 2020, on pourrait supposer que ce qui devait être migré il y a 20 ans l’a été, mais ce n’est toujours pas le cas. Si des personnes scannent principalement ce port, c’est qu’il est encore beaucoup trop utilisé. Ensuite viennent les 445 (partage Microsoft), 1433 (MS-SQL), 80 (HTTP), 443 (HTTPS), 22 (SSH), 3389 (remote desktop), 8080 (port alternatif HTTP), 5555 (VPN over HTTPS), 81 (port alternatif HTTP).

Il est frappant de s’imaginer que des ports comme le partage de fichiers Microsoft (445) ou le remote desktop (3389) ne soient pas filtrés suffisamment massivement pour décourager des scanners. Un simple port knocking permet de protéger ces accès sensibles en quelques minutes. Les ports web (80 / 443 / 81 / 8080), quant à eux, ne sont pas les plus recherchés en volume. En effet, les services web ont toujours eu une grande cote de popularité chez les scanners, mais la mode des ransomwares, plus profitables, semble avoir rééquilibré le jeu en faveur des ports d’administration à distance, comme pour le port SSH (22). Une star montante est aussi à surveiller, le VPN au travers du protocole HTTP (1433), car il semble prendre suffisamment de parts de marché pour attirer l’attention.

Des grands absents de marque dans le top 10 sont les ports mail (25, 110, 465, etc.). Très populaires il y a quelques années, ils semblent moins à la mode en 2020. On peut supposer que les efforts massifs des opérateurs pour éviter de donner accès à d’autres ports SMTP que les leurs dans le cadre des IP qu'ils distribuent à leurs utilisateurs ont payé. De nombreuses autres forces sont au travail sur ce sujet, notamment la tendance forte des utilisateurs à se tourner vers les grands fournisseurs comme Gmail. On peut également citer les RBL et l'IA qui ont contribué à l’assainissement de ce milieu.

5. Usage et méthodes des auteurs de ces scans

Bien qu’une fraction de ces scanners soit inoffensive, une partie non négligeable est liée à une activité malveillante de repérage. Soit les intrus tentent une exploitation dès le port reconnu, par exemple le 445, pour chiffrer les disques et demander une rançon, soit ils stockent les bannières pour un usage ultérieur, dans l’attente d’une vulnérabilité sur le protocole ciblé.

Les outils sont assez simples à développer. Le pilier open source du domaine, Nmap, n'est vraisemblablement pas suffisamment industrialisé pour gérer de tels volumes. Certains outils comme Masscan [2] ont été conçus pour gérer efficacement les volumes dont nous parlons ici. Sur une connexion 10 Gbps, ce scanner pourrait, selon son auteur, scanner l'IPv4 en 6 minutes. Il est quasi certain, au vu de leur efficacité, que certains groupes ou pays ont organisé cette « pêche » de façon beaucoup plus industrielle.

L'information nécessitant alors d'être partagée entre les membres de leurs réseaux (pour que son exploitation soit rapide), la structuration de bases de données et de scripts de mises à jour régulières ou circonstancielles semble une évidence. La majorité des développements clefs ayant déjà été réalisés en open source, un tel effort ne semble que marginalement complexe à mettre en œuvre, pour un profit substantiel.

Reste le cas du Web ou des services avec authentification où, dans un second temps, il devient intéressant pour l’attaquant de tenter une attaque par brute force des mots de passes (VPN / SSH, etc.), ou un scan de vulnérabilité des contenus (HTTP).

6. Fail2ban, reloaded!

Le vénérable Fail2ban a permis de se prémunir de ces scanners pendant 16 années. Écrit en Python à l’époque, il protège encore quelques centaines de milliers de machines de par le monde. Une alternative plus moderne a été développée par l’équipe de CrowdSec [3], en Golang, que ses performances, son architecture et ses choix techniques rendent plus adapté aux nouveaux environnements de 2021.

Au-delà de son fonctionnement d’analyse comportementale sur les machines, CrowdSec distribue les IP bloquées entre tous les acteurs du réseau, pour renforcer l’efficacité de l’ensemble. À l’instar de la crise sanitaire qui touche le monde, CrowdSec propose de se prémunir des cyberattaques via une sorte d’immunité collective.

Le logiciel est gratuit, open source (licence MIT) et disponible sur GitHub. (https://github.com/crowdsecurity/crowdsec) et la plupart de vos questions trouveront réponse dans la FAQ du projet (https://crowdsec.net/faq/).

Conclusion

Cette première étude mérite d’être approfondie. Dans nos prochaines étapes, nous pensons notamment confronter ces données collectées avec celles provenant de machines en IPv6. De même, nous souhaiterions corréler les IP scannant plusieurs machines avec des profils très différents afin de déterminer quelles IP sont les plus exhaustives dans leurs approches.

Tout ceci devrait pouvoir voir le jour bientôt grâce au Datalake que constitue CrowdSec.

Enfin, nous vous recommandons de penser à vous protéger contre ces scans. Ils peuvent sembler anodins, mais le jour où vous exposerez par erreur une caméra, un desktop ou un IoT, soyez certains que les personnes à la manœuvre s'en rendront compte en moins de 24h et qu'elles tenteront d'en tirer profit…

Remerciements

Merci à Laurent Cheylus pour ses retours, corrections et suggestions sur cet article.

Références

[1] Network recon framework : https://ivre.rocks/

[2] Masscan : https://github.com/robertdavidgraham/masscan

[3] CrowdSec : https://crowdsec.net