Grokking attaque sophistiquée par dictionnaire

La réponse facile à cette question est n'utilisez pas de mots de passe ! !!

Vous pouvez :

• utiliser clés ssh . Cryptez-les pour plus de sécurité
• utilisez un générateur de mot de passe à usage unique comme Mobile-OTP
• utiliser kerberos

Si vous devez utiliser des mots de passe, autorisez-les uniquement à partir de sous-réseaux auxquels vous faites confiance, et non de l'ensemble de l'Internet. De plus, il est utile d'exécuter votre démon ssh sur un autre port que 22. Normalement, je ne suggère pas ce genre de choses, mais si cela permet de réduire le volume des attaques que vous subissez, c'est tant mieux.

En réponse à vos préoccupations spécifiques :

• J'ai vu ce genre d'attaques sur tous les hôtes que je dirige et qui ont un serveur ssh public.
• Je soupçonne qu'ils utilisent un dictionnaire de noms d'utilisateurs/mots de passe développé à partir de l'expérience passée de ce qui fonctionne. Par exemple, mes journaux ont
  • 18 tentatives contre l'utilisateur "ftp"
  • 23 tentatives contre l'utilisateur "forum
  • 3 pour l'utilisateur "bernard"
  • 1 pour l'utilisateur "bret"
• J'ai également vu ce genre d'attaque où ils utilisaient des identifiants spécifiques au site, mais ceux-ci étaient probablement extraits du serveur ldap du site (les universités, il faut les aimer !).
• Ces attaques viennent probablement de zombie des ordinateurs qui ont un contrôle centralisé impressionnant.
• ces attaques arrivent au rythme d'une toutes les 1 à 5 minutes, toute la journée, tous les jours.
• Je viens d'essayer de truquer sshd pour voir s'il est trivial de collecter le mot de passe que l'attaquant tente, et il semble qu'il faille patcher le code.
  • ces ont fait cela et ont constaté que les mots de passe étaient souvent des permutations du nom d'utilisateur ou d'un mot de passe bien connu comme sql ou admin.

Voici une discussion et une analyse d'une attaque de botnet "slow brutes" qui a débuté en 2008 : Ronde finale des Brutes lentes

Autre discussion de la même période à ce site suggère

Fail2ban n'est qu'un outil parmi d'autres pour améliorer la sécurité des serveurs. Bien sûr, la première étape consiste à éviter l'utilisation de mots de passe et à utiliser plutôt l'authentification par clé de serveur. En outre, limitez le trafic autorisé à certaines IP, interdisez les plages d'IP, utilisez des tables d'IP, utilisez des listes noires telles que rsync-mirrors.uceprotect.net pour mettre à jour votre iptables pour les origines et les réseaux d'origine connus des pirates SSH. Pour plus de détails sur les 3 niveaux de listes noires ci-dessus, voir uceprotect.net.

D'autres éléments que j'ai vus suggérer en rapport avec ce type de tentative recommandent de surveiller les tentatives échouées et de bloquer les IP sources - éventuellement, la même IP sera utilisée pour une autre sonde, donc en détectant et en mettant sur liste noire après les tentatives de connexion avec un compte inexistant, vous réduisez progressivement la menace au prix d'un traitement accru des règles du pare-feu. De plus, il peut être préférable de ne pas bloquer après une seule tentative de connexion - les fautes de frappe ne sont pas rares.

La meilleure réponse est de ne rien faire. Tant que vos utilisateurs ont des mots de passe forts de 8 caractères ou plus, à ce rythme, il faudra probablement environ 3000 millions d'années pour le forcer par force brute !

Je ne suis pas sûr de votre mise en œuvre réelle, mais voici quelques conseils généraux :

Vérifiez vos mots de passe (avec john the ripper ou autre), et voyez si vous pouvez augmenter le délai de connexion.

Installez denyhosts ou fail2ban - ils bloqueront par IP après un certain nombre d'attaques. denyhosts fonctionne sur /etc/hosts.deny et je crois que fail2ban fonctionne sur les règles iptables.