fail2ban et les denyhosts m'interrogent constamment sur Ubuntu

Je viens d'avoir une instance Ubuntu sur Linode. Pour sécuriser le SSH, j'ai installé fail2ban (en utilisant apt-get ), mais j'ai eu un problème: fail2ban continué à interdire mon IP (pour des durées limitées, heureusement) même si j'entendais le mot de passe correct. J'ai donc supprimé fail2ban et installé des denyhosts place. Le même problème, mais plus sévère: il semble que chaque fois que je SSH entre, mon IP est interdit. Je l'supprime de /etc/hosts.deny , redémarrez les denyhosts et connectez-vous à nouveau, et mon IP est à nouveau interdit.

La seule explication que je peux penser, c'est que je suis en train de SSH en tant que root (oui, oui, je sais); Peut-être quelque chose est-il défini quelque part qui bloque quelqu'un qui SSH-es en tant que root, même s'ils se connectent avec succès? Cela me semble bizarre. Des idées? (La list blanche de mon IP est une correction temporaire. Je ne souhaite pas seulement pouvoir ouvrir une session à partir d'une seule adresse IP.)

Je crois que j'ai vu quelqu'un dire que certaines de ces applications comptabiliseront les connections aux keys échouées en tant que tentative de force brute. Avez-vous un ssh-agent en cours d'exécution avec des keys? La connection à cet set offrira toutes les keys avant de revenir au mot de passe, ce qui pourrait être la raison pour laquelle. Essayez de configurer le niveau de journal de sshd plus haut et vérifiez les journaux fail2ban / denyhost.

Edit: voici la source originale qui m'a donné une idée, avec un moyen de le réparer.

Veuillez consulter les liens suivants:

si vous vouliez supprimer l'intégralité de l'échec et de l'idée de déni, faites comme le dit Nathan Powell ci-dessous, passez du port 22 à quelque chose de plus obscur

aussi quelques idées de plus:

  1. iptables: l'exemple suivant supprime les connections entrantes qui font plus de 2 tentatives de connection sur le port 22 en dix minutes:

     iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP 
  2. connection basée sur key

  3. hameçon de port (knockd)

Si vous êtes sshing en tant que root pour une raison spécifique, j'espère que vous avez configuré les keys. Je reorderais ces modifications à votre file sshd_config :

 PermitRootLogin without-password AllowUsers root@ip.add.re.ss 

pour verrouiller quel hôte vous pouvez ssh dans votre server en tant que root.

Si vous n'avez pas besoin de ssh en tant que root, il y a de bonnes chances que vous ne le fassiez pas, vous devez configurer un user normal, créer un groupe ssh ou quelque chose, configurer des keys pour l'user, les append au groupe ssh et ajoute AllowGroups ssh à sshd_config

puis donner à votre user un access sudo en exécutant visudo tant que root et en ajoutant la ligne: l' user ALL=(ALL) ALL qui permettra à votre user d'accéder à votre user, avec le mot de passe de votre user, lors de l'exécution de la command sudo commandX

Assurez-vous que sshd est bloqué serait ma première priorité, surtout si la connection root doit être autorisée.

même en cours d'exécution sur un port obscurci, les kiddies avancés vous findont avec la numérisation de port.

Si vous êtes ouvert en revenant à fail2ban, vous pouvez toujours utiliser la directive ignoreip dans jail.conf . Par exemple:

 ignoreip = 127.0.0.1 192.168.1.0/32 

De cette façon, vous ne vous bloquerez pas avec votre typage négligé 😉 Cela signifie également que les personnes ne peuvent pas vous bloquer en spoofing votre IP (bien qu'avec tout trafic TCP qui ne soit pas très préoccupant).

Si sshd est réglé sur le niveau de journalisation VERBOSE (ou plus haut), il met la phrase '… Failed none …' dans le journal système chaque fois qu'un user se connecte avec succès. Par défaut, fail2ban est configuré pour countr cela comme un échec . J'ai réussi le problème en définissant le niveau de journalisation de sshd vers l'INFO.

Pour plus de détails, voir ma réponse à cette question fail2ban m'interdit après une série de * connections * réussies *

Je pense que si vous êtes assez vert pour ne pas pouvoir résoudre ce problème en lisant le file de configuration et en examinant les journaux, vous devriez viser un peu plus bas jusqu'à ce que vous obteniez de l'expérience.

Si vous êtes optimisé pour déjouer les attaques de force brut qui sont communes, modifiez le port sur lequel Sshd fonctionne. Cela prend en charge la grande majorité de ceux-là.