S3 1 Tio
S3 1 Tio
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

L’assourdissant bruit de fond d’Internet

Le serveur n’a rien demandé à personne !

L’assourdissant bruit de fond d’Internet

Illustration : Flock

Assourdissant, c’est le mot : un serveur privé fraîchement installé et branché à Internet reçoit près de 100 000 visites par jour. Le chiffre est vertigineux et montre bien ce que l’on appelle le « bruit de fond d’Internet », c’est-à-dire ce qui se passe même quand on n’a rien demandé à personne.

La semaine dernière, nous expliquions qu’un de nos serveurs était attaqué un peu plus de 4 000 fois par jour. Attaqué sur le seul port 22, celui par défaut des connexions SSH pour prendre la main à distance. Mais ce n’était que la face visible de l’iceberg.

Notre serveur « visité » 100 000 fois par jour

Nous avons pris un autre serveur privé virtuel (VPS) – un serveur avec des ressources CPU, mémoire et stockage partagées – chez OVHcloud cette fois. Nous avons installé T-Pot de Deutsche Telekom Security, un honeypot (pot de miel) open source captant toutes les demandes au serveur, pas seulement celles sur le port 22.

Il reste 76% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (28)

votre avatar
Bonjour,

Avez vous fait le détail entre IPV4 et IPV6? y a t'il déjà beaucoup de bot qui parcourent internet sur le réseau IPV6?
votre avatar
Pour le moment IPv4 seulement, mais je compte bien plus tard installer un serveur IPv6 only voir les différences et les conséquences :)
votre avatar
Oui, je serai curieux aussi.

Comme dit dans l'article : "les bots s’attaquent à toutes les IP[v4] généralement". Mais il y en a trop avec l'IPV6. Ca sera probablement beaucoup plus calme, sauf à récupérer une IPV6 précédemment attribuée.
votre avatar
Pour l'IPv6, se sera peut-être plus calme.
Les crawlers IPv6 prennent plus de temps pour scanner le net en IPv6 compte tenu de la quantité d'adresses disponibles.

De mon coté, mon fail2ban sur SSHD (accessible en IPv6) n'a aucune trace de ban pour de l'IPv6 depuis bien longtemps.
Idem pour le fail2ban sur Apache/Nginx en IPv6
votre avatar
J’aimerais aussi en profiter pour regarder ce que ça implique du full IPv6. Mais déjà quand j’ai configuré des Honeypot hybride c’était tres limité en IPv6 effectivement. Rendez-vous au prochain épisode ^^
votre avatar
Full IPv6 (pour de l'opérationnel/de la prod), ça dépend vraiment de ce qui doit tourner sur un serveur, mais cela peut fortement limiter l'accessibilité de celui-ci (mail, web, ssh & cie).
Même certains gros sites ne sont pas accessibles en IPv6 (genre Github, ou certains services de mails).

Pour le honeypot, je ne sais pas du tout si les supports IPv6 sont en place (et quelque chose me dit que ça ne doit pas être si répandu que cela...).

Et, du coté perso, je ne constate quasiment aucun accès IPv6 sur mon VPS (excepté mon IPv6 perso - sur +100k access sur un VHOST apache2, je dois avoir +97% d'IPv4 qui viennent taper dessus).
Pour mon SSHD (sur un autre port que celui par défaut), depuis février dernier je n'ai aucun accès autre que le mien en IPv6.
votre avatar
A titre très anecdotique, un gros site (millions de visiteurs mensuels etc.) dont je m'occupe a reçu son premier DDoS IPv6 quelques minutes après avoir activé IPv6, et dans les logs on voit à peu près 50-50 entre v4 et v6 pour les scans et les attaques basiques.

Les opérateurs ne sont pas prêts, mais les bots oui.
votre avatar
Un test intéressant.
J'aimerais m'intéresser à sécuriser mon réseau à domicile, j'ai une livebox et un Nas synology. Mais je n'ai aucune idée de comment faire. Je pense être totalement vulnérable aux attaques. :keskidit: Bien souvent les tutos vont dans le cambouis et je suis largué.
votre avatar
J'ai un NAS, et pour réduire les scans et attaque j'ai deux métodes combinées:

  • ne pas servir les services sur les ports standard (22, 443...). Bien peu de machines font réellement un scan des 65535 ports. Et un port alternatif est parfaitement facile à indiquer dans une URL en https://

  • comme je sais que mes utilisateurs sont dans 3 pays, j'ai whitelisté les plages d'IP de ces 3 pays. Mon NAS ne répond donc rien à 99% des adresses IP de cette planète. (https://sebsauvage.net/wiki/doku.php?id=geoblocage)



Ce n'est pas une solution parfaite, mais ça réduit notoirement la surface d'attaque.
(il reste nécessaire d'appliquer les autres règles de sécurité (aka installer les mises à jour de sécurité en temps et en heure, etc.)
votre avatar
Les nas synology incluent aussi MFA et bloquer le client apres X tentatives.
votre avatar
Perso sur mon NAS, je fail2ban définitivement dès la première tentative échouée (mon IP locale est en liste blanche).
Et je bloque toutes les IPs non géolocalisées en France.
votre avatar
Je fail2ban pour 720 jours, je suis pas si violent que toi :mdr2:
votre avatar
La première question est : est ce que tu besoin d’accéder à ton réseau depuis l’extérieur ? Par défaut ta livebox ne laisse rien passer
votre avatar
Hello Tous,

Y'a t il un moyen d'évaluer le bilan energetique (et donc carbone ?) de ce bruit de fond ?

Et peut-on distinguer des usages légitimes dans ce bruit de fond ?

Ou tout cela ne sert effectivement aucun usage légitime ?

Please advise
votre avatar
La preuve par l’exemple qu’il faut sécuriser son serveur
Ça c'est juste parce que vous n'êtes pas aventuriers. :langue:
votre avatar
Je ne suis pas le Bob Morane des rézos je te confirmes :D
votre avatar
J'avais aussi remarqué que un serveur non repéré (IP personnelle de FAI), qu'après l'émission d'un certificat par exemple Let-s Encrypt qui publie dans Certificate Transparency, les attaques avaient commencé dans les secondes suivantes.
votre avatar
Merci pour l'information, je me demandait comment cela se faisait que mes machines IPv6 recevaient des tentatives d'accès. Je pensais qu'il s'agissait d'un problème de DNS trop bavard (réponse à une requête * sur le domaine).

Heureusement, je n'utilise pas les mêmes adresses pour http/https et pour ssh. C'est encore mieux que d'utiliser des ports non standard.
votre avatar
Oui les URLs qui portent des certif sont publiées, des bots récupère en continu les adresses.
votre avatar
Est-ce que cela signifie que sur une box internet à IP fixe, avec 2-3 ports redirigés vers un NAS, le NAS va lui aussi subir toutes ces tentatives d'entrées ? Si oui, comment fait-on du hardening sur un NAS grand public ?
votre avatar
Oui, ton NAS sera attaqué.
Les IPs des FAI me semblaient moins attaquées que celles d'un VPS, mais elles le sont tout de même. Cela se voit dans les logs.

Je n'ai pas de NAS grand public et ne réponds donc pas à ta deuxième question.
votre avatar
De quels logs parles-tu ? Les box des FAI ne fournissent aucun logs (à ma connaissance) des tentatives de flux incoming.
Ou alors il faudrait que j'ouvre tous les ports vers un honeypot maison pour voir ça de mes propres yeux... ça me titille ....
ce qui me fait peur c'est q'un OS grand public (synology, qnap, ...) aura forcément un jour ou l'autre une grosse faille détectée et permettra un accès dangereux non sollicité. Mais alors, que faire !?
votre avatar
Aucun appareil exposé n'est de toute façon à l'abri en cas de faille.
Pour les autres attaques (DoS, phishing, etc.), c'est du blocage de plages IP (pare-feu), du fail2ban, du MFA, et pourquoi pas DNS filtrant, pour la base.
Et pour les plus expert, de la surveillance réseau (IDS/IPS, NDR, SIEM).
votre avatar
Dans mon cas, c'était un serveur Web sur un PC, d'où le certificat Let's Encrypt. Dans mon souvenir, je regardais les logs pour observer une redirection de http vers https (ou alors je regardais Let's Encrypt venir). Il n'y avait rien, aucun trafic. Dès que j'ai reçu le certificat, du trafic exploratoire sur des applications non installées est arrivé.

Je ne sais pas ce que supporte ton NAS, de mon côté je rentre via WireGuard sur un port exotique, donc rien ou presque n'est exposé. Dans la doc, WireGuard en udp ne répond qu'aux bonnes requêtes. Il serait "invisible" aux attaquants.

Pour un accés direct à des services, je tenterais et participerais un filtre communautaire de réputation des IP.

Cependant, j'aurais l'impression que cela ne peut fonctionner qu'en IP4, qu'en IP6 l'attaquant dispose de trop de choix.
Note : cette remarque sur filtrer en IP4, est plus une question..
votre avatar
Très bonne question. Merci de l'avoir posée.
Je monte mon NAS diy, et je souhaite aussi limiter la casse.
L'ouverture me fait peur.
votre avatar
Intéressant ce projet T-Pot je connaissait pas. Il demande pas mal de ressourse 16Go RAM 128Go de disk c'est pas mal (mais ça a l'air beau).
A votre avis se serait utile d'extraire toutes les adresses IP de ce pot de miel qui sont du coup suspectes pour entretenir une mega liste d'IPs potentielement malveillante (J'ai un gros doute mais...) ?
votre avatar
Je me posais la question de faire ça : exclure les IP régulières et intrusives, voir à quel point ca réduit le bruit… Je vais tenter je crois, apres je passerais en IPv6 ^^
votre avatar
Je collecte déjà des millions d'adresses IPs de scraper qui passe par des proxy qui utilisent des IPs résidentielles et mette à mal les hébergements de certains sites (principalement ceux qui ont des filtres à facette).
Après il ne faut pas trop se leurrer, Iptables (l'interface du firewall de Linux Netfilter) est incapable de gérer autant d'adresses IP même avec Ipset.
Par contre Nftables est bien plus performant, j'ai des set de plus d'1 millions d'IP en fonctionnement et ça marche plutôt bien.