Comment savoir quelles tentatives SSH infructueuses ont eues sur notre serveur

Il n'y a pas longtemps, j'ai expliqué comment savoir quelles adresses IP ont été connectées par SSH, mais ... que se passe-t-il si le nom d'utilisateur ou le mot de passe est incorrect et qu'ils ne se connectent pas?

En d'autres termes, s'il y a quelqu'un qui essaie de deviner comment accéder à notre ordinateur ou serveur via SSH, nous avons vraiment besoin de savoir, ou pas?

Pour cela nous ferons la même procédure que dans le post précédent, nous filtrerons le journal d'authentification mais cette fois, avec un filtre différent:

cat /var/log/auth* | grep Failed

Ils devraient exécuter la commande ci-dessus comme racineou avec sudo pour le faire avec des autorisations administratives.

Je laisse une capture d'écran de son apparence:

Comme vous pouvez le voir, il me montre le mois, le jour et l'heure de chaque tentative infructueuse, ainsi que l'utilisateur avec lequel ils ont essayé d'entrer et l'adresse IP à partir de laquelle ils ont essayé d'accéder.

Mais cela peut être arrangé un peu plus, nous utiliserons awk pour améliorer un peu le résultat:

cat /var/log/auth* | grep Failed | awk '{print $2 "-" $1 " " $3 "\t USUARIO: " $9 "\t DESDE: " $11}'

Ce qui précède est UNE ligne.

Ici, nous voyons à quoi cela ressemblerait:

Cette ligne que je viens de vous montrer ne doit pas être entièrement mémorisée, vous pouvez créer un alias pour elle, le résultat est le même qu'avec la première ligne, juste un peu plus organisé.

Ce que je sais ne sera pas utile à beaucoup, mais pour ceux d'entre nous qui gèrent des serveurs, je sais que cela nous montrera des données intéressantes hehe.

salutations


8 commentaires, laissez le vôtre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   pirate informatique775 dit

    Très bon usage des tuyaux

    salutations

    1.    KZKG ^ Gaara dit

      Merci

  2.   FIXOCONNE dit

    Excellent le 2 post

  3.   Mystog @ N dit

    J'ai toujours utilisé le premier, parce que je ne sais pas quoi faire, mais je vais devoir l'apprendre

    cat / var / log / auth * | échec de grep

    Ici où je travaille, à la Faculté de Mathématiques-Calcul de l'Univ de Oriente à Cuba, nous avons une usine de "petits hackers" qui inventent constamment des choses qu'ils ne devraient pas et je dois être avec 8 yeux. Le thème ssh en est un. Merci pour le mec de pointe.

  4.   Hugo dit

    Une question: si l'on a un serveur face à Internet mais dans iptables on n'ouvre le port ssh que pour certaines adresses MAC internes (disons depuis un bureau), les tentatives d'accès depuis le reste des adresses internes atteindraient le journal d'authentification et / ou externe? Parce que j'ai mes doutes.

    1.    KZKG ^ Gaara dit

      Dans le journal, seules les demandes autorisées par le pare-feu sont enregistrées, mais refusées ou approuvées par le système en tant que tel (je veux dire la connexion).
      Si le pare-feu ne permet pas aux demandes SSH de passer, rien n'atteindra le journal.

      Ce que je n'ai pas essayé, mais allez ... je pense que ça doit être comme ça 😀

  5.   Braire dit

    grep -i a échoué /var/log/auth.log | awk '{print $ 2 «-» $ 1 »» $ 3 «\ t UTILISATEUR:» $ 9 «\ t DE:» $ 11}'
    rgrep -i a échoué / var / log / (ouvre les dossiers) | awk '{print $ 2 «-» $ 1 »» $ 3 «\ t USER:» $ 9 «\ t FROM:» $ 11}'

    1.    Braire dit

      dans centos-redhat… ..etc ……
      / var / log / secure