Les systèmes honeypot (pots de miel) servent-ils vraiment à quelque chose sur le serveur d'une petite boîte ?

Voir des dizaines de milliers de requêtes par jour, c'est juste le bruit de fond habituel des bots qui scannent tout le Web en boucle. Même si vous posez un honeypot, ces bots vont tomber dedans et ne vous apprendront rien de plus que ce que vous savez déjà : il y a des bots sur Internet. Et même pour un simple leurre passif, impossible de le laisser sur le même VLAN que votre réseau de prod, il faut un sous-réseau dédié et des règles de pare-feu ultra strictes.

PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.

Laissez tomber le conseil du consultant pour l'instant. Changer le port par défaut, virer l'authentification par mot de passe pour passer uniquement par clé SSH et mettre en place un outil basique qui bannit temporairement les tentatives ratées réglera quasi instantanément ces scans du quotidien. Ça ne coûte rien et c'est réglé en deux heures.

L'année dernière, par curiosité, on a fait tourner un honeypot SSH open source sur un serveur qui ne servait à rien. En trois jours, il a logué plus de 140 000 tentatives de connexion et 800 variantes de noms d'utilisateurs. Un de nos dévs a perdu 4 heures par semaine à trier ces données inutiles. Au bout d'un mois, on a tout coupé parce qu'on n'en a tiré strictement aucune info exploitable.

Est-ce que le consultant a précisé qui allait surveiller les logs une fois ce honeypot installé ? Vous avez un SOC pour gérer les alertes, ou bien vous allez juste l'installer et le laisser dans son coin ? Si vous n'avez pas prévu de budget pour analyser les rapports chaque semaine, quel est l'intérêt de poser un piège ?

aucun interet frerot. le consultant essaie surement de te refourguer un modele tout fait pour les grands comptes. genre ferme le port ssh vers l'exterieur ou passe par un vpn et c'est bon et t'auras jamais le temps de lire les logs de toute facon.

Un honeypot n'est pas un outil de défense c'est un outil de threat intelligence et de recherche. Les boîtes de plusieurs centaines d'employés avec leur propre équipe de sécu s'en servent pour détecter les nouveaux vecteurs d'attaque au plus tôt. Une boîte de dev de 12 personnes n'a clairement pas le luxe opérationnel d'étudier le profil des attaquants.

Le sujet est pourtant clair. Un honeypot ne bloque pas les attaques, il se contente de les documenter. Ce dont vous avez besoin, ce n'est pas d'analyser des logs, mais de verrouiller les portes. Dès lors que vous fermez les ports vers l'extérieur et que vous passez à une authentification par clé, toutes ces questions disparaissent d'elles-mêmes.

Mes doutes sont levés, merci. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production. Bon courage.

Si j'ai bien compris, vous dites que : Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Mon regard a changé après avoir vécu cela. Essayer de faire cela seul est la voie la plus coûteuse.

Essayer de faire cela seul est la voie la plus coûteuse.

Je parle du point de vue du fournisseur, c'est mon côté. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Bon courage.

Je vais essayer.

Je ne savais pas ça.

ne manquez rien : Une sauvegarde non testée n'est pas une sauvegarde.

avant de décider regardez quelles données vous avez en main. si vous écrivez le résultat ici, cela aidera asusi d'autres personnes.

Il y a un point auquel il faut faire attention. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Je le note au cas où.

Je vais résumer ce qui a été dit jusqu'ici. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Bon courage.

Il faut y aller étape par étape. Ce qui nous faisait perdre le plus de temps c'était l'absence de clarté sur qui prenait les décisions.

Je le note au cas où.

Je vais défendre l'opposé, ne m'en veuillez pas. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

Bon courage.