On nous a parlé de honeypot — c'est quoi, et est-ce pertinent pour une PME avec deux serveurs ?

Un honeypot mal isolé peut vite se retourner contre vous. Si votre technicien monte un leurre à haute interaction sans maîtriser le sujet et qu'un pirate en prend le contrôle, il pourra s'en servir comme passerelle pour attaquer votre réseau interne ou l'ERP. L'installation comme le suivi demandent une vraie expertise.

Technique classique de commercial en info. Tout le monde tourne probablement avec le mot de passe « 123456 » dans la boîte, les sauvegardes sont même pas faites correctement, mais le mec veut vous vendre un piège digne de la NASA pour facturer un abonnement tous les mois.

Mettez plutôt ce budget dans une baie de sauvegarde hors ligne. Ça backupe la nuit et ça se coupe du réseau tout seul. Si un ransomware frappe demain, c'est la sauvegarde isolée qui va vous sauver, pas le pot de miel.

On s'était fait embobiner de la même manière pour notre agence de 20 personnes : 600 euros d'installation et 100 euros par mois de maintenance. En un mois, on avait 40 000 alertes de scans de bots. Personne ne lisait ces rapports, on a tout coupé au bout du troisième mois.

Avant de vous vendre son honeypot est-ce que votre prestataire a fermé le port distant de l'ERP au bureau ? A-t-il activé la double authentification pour les utilisateurs ? Si la réponse est non, posez-vous des questions sur ses réelles intentions.

pour une boiet a 2 serveurs le honeypot c vraiment du grand nimp mais installez un pare feu, passez derriere un vpn, blinde les mdp et c largement suffisant.

note : j'ai écrit cela d'après mon expérience, cela ne s'applique peut-être pas à tout le monde.

Les architectures honeypot n'ont généralement de sens que dans les grandes organisations qui disposent en interne d'un centre d'opérations de sécurité (SOC) ou qui sont directement la cible de menaces d'espionnage informatique. À l'échelle d'une PME, le rapport risque-bénéfice et le rapport coût-bénéfice ne sont absolument pas rationnels.

à mon avis, remerciez poliment et refusez la proopsition puis dépensez votre argent pour combler les failles de sécurité de base et pour un bon système de sauvegarde, vous dormirez bien plus tranquille la nuit.

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

Il faut faire une distinction ici. Une sauvegarde non testée n'est pas une sauvegarde.

Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger. C'est confirmé par l'expérience.

Il est rare de trouver un texte qui explique les choses aussi clairement.

Je vais essayer. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

Bien sûr, cela change si votre situation est différente.

Chez moi, c'est l'inverse qui s'est passé, c'est pourquoi j'écris. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard. J'espère que cela vous sera utile.

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

C'est confirmé par l'expérience.

Exactement, et ce n'est pas si connu que ça. L'erreur commise du côté de honeypot est généralement réversible, mais coûteuse.

Si j'ai bien compris, vous dites que : La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

Si vous avez des questions écrivez-moi je répondrai au mieux.

Je pense différemment. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Je suis aussi curieux de savoir si d'autres font autrement.

Je suis dans la même situation, c'est pourquoi je pose la question. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

je ne suis pas d'accord sur ce point. le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.