Bonjour tout le monde,
J'ai un auth.log sur un dédié qui grossi à vu d’oeuils. C'est un serveur qui fait 80K entrées/jours sur des sites commerciaux.
Ils se focalisent sur le compte root, par ssh.
Quand je m'ennuie je tape un tail -f /var/log/auth.log.
J'ai donc des : pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=2xx.151.208.1xx
Mais ca ne m'amuse plus.
J'aimerais bien voir les mots de passes qui sont tentés!
Vous pensez qu'il y a un moyen d'avoir des logs comme ça?
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=2xx.151.208.1xx
password: Y0c4f4rt ?
Merci d'avance!
# [±HS] Stopper les tentatives
Posté par lolop (site web personnel) . Évalué à 6.
Installe fail2ban.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Et les typos ?
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
Je ne sais pas si c'est possible facilement, mais ça ne me paraît pas être une bonne idée : si tu tentes de t'identifier en faisant une typo dans ton mot de passe une fois, tu auras ton mot de passe + 1 typo en clair dans les logs. Si un pirate met la main sur les logs, ça lui facilite grandement la tâche de brute-forcing …
# Non je veux les pass
Posté par Panhwein . Évalué à 1.
En fait, je voudrais que rsyslogd affiche les mots de passes tentés dans auth.log par l'assaillant!
C'est quand même plus rigolo, et permettrait beaucoup de choses. Un dico interdit par exemple, savoir si un de mes mots de passe à était utilisé et cae terra
# latin
Posté par Panhwein . Évalué à 1. Dernière modification le 06 février 2020 à 20:51.
Désolé pour le "et cae tera", ca veux dire etc, mais en latin.
Non la sécu, je ne m'alarme pas des mecs qui cherche le compte root.Ca fait 20 ans.
C'est martine31 le pass, mais ils vont avoir du mal à le trouver celui-là!
Je veux juste arriver à afficher dans auth.log les mots de passes essayé: tu tente un acces ssh ou sftp, je veux savoir ce que tu a essayé comme mot de passe.
C'est ça mon problème, fail2ban ok, mais je cherche des logs sur les mots de passe:)
[^] # Commentaire supprimé
Posté par Aymard03 . Évalué à 0. Dernière modification le 07 février 2020 à 07:50.
Ce commentaire a été supprimé par l’équipe de modération.
# Perdu d'avance
Posté par AncalagonTotof . Évalué à 7.
Je ne connais pas en détail le fonctionnement de SSH, mais ça m'étonnerait que le mot de passe circule en clair.
J'imagine en gros que le client et le serveur se mettent d'accord pour établir un tuyau chiffré, et seulement ensuite, le mot de passe est lui même chiffré. D'ailleurs, le serveur ne conserve pas de mot de passe en clair.
La seule chose à faire, c'est de parer les coups.
Je connais pas, mais j'ai vu passer une suggestion vers fail2ban.
Moi, ça fait des années que je ne laisse plus de serveur SSH sur le port 22 (par défaut). Trop de bots se pointent là pour tenter leur chance.
[^] # Re: Perdu d'avance
Posté par Panhwein . Évalué à 1. Dernière modification le 06 février 2020 à 21:06.
Oui mais à un moment, coté serveur, on doit doit bien pouvoir le récupérer non?
Je cherche pas à parer les coups, je voudrais savoir ce qu'ils essaient comme mot de passe. (un qui m'a appartenu par exemple, ou constituer un dictionnaire de mot de passe interdit)
J'ai pensé à un pot au miel sur le port 22, et me mettre ailleur. Encore une fois je ne craint le hack je voudrais les mots de passes dans auth.log
Mais ca semble etre une bonne solution pour récolter.
[^] # Re: Perdu d'avance
Posté par gUI (Mastodon) . Évalué à 3.
Pas forcément. Le serveur peut recevoir le hash du mot de passe par exemple. Il compare avec le sien et ça suffit à savoir si le mot de passe est le bon.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Perdu d'avance
Posté par Panhwein . Évalué à 3.
Arf, ok.
Tu m'étonnes que je n'ai pas trouvé de solution sur le web!
C'est pas une peur de hack, je veux récolter leurs mots de passes.
J'aurais aimais les avoir dans mon auth.log
Donc un pot au miel sur le port 22, et je mets ssh bien loin?
Ça semble pas mal oui…
[^] # Re: Perdu d'avance
Posté par Panhwein . Évalué à 2. Dernière modification le 06 février 2020 à 21:12.
Il faut que je trouve AncalagonTotof
Sinon honey pot sur le 22 ?
[^] # Re: Perdu d'avance
Posté par NeoX . Évalué à 2.
oui tu peux écrire un honeypot sur le port 22,
qui répond toujours FAUX à la tentative de connexion, mais stock le mot de passe en clair dans un fichier de log.
le problème c'est quand meme qu'il va falloir simuler un serveur SSH, avec échange de clef valide
[^] # Re: Perdu d'avance
Posté par gUI (Mastodon) . Évalué à 3.
bin même ça je suis pas sûr que ça marche. c'est le mot de passe qui transite (chiffré) ou c'est un hash (chiffré aussi) ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Perdu d'avance
Posté par ted (site web personnel) . Évalué à 6.
Il faut que le honeypot fasse du reverse-bruteforce. Il doit accepter un seul mot de passe, et si jamais la connexion se fait tu sais que c'est ce mot de passe qui est utilisé \o/
Un LUG en Lorraine : https://enunclic-cappel.fr
# oeuils
Posté par papap (site web personnel) . Évalué à 3.
Un oeil, des oeufs
# Merci
Posté par Panhwein . Évalué à 3. Dernière modification le 07 février 2020 à 16:42.
En tout cas merci à vous, et commentaires très pertinents, surtout sur la faute de typo!
Je met cette idée de côté, mais j'ai trouvé ça: Cowrie
Il y a un article en français ici: https://ogma-sec.fr/mise-en-place-et-etude-dun-honey-pot-ssh-cowrie/
Je ne vais pas l'installer, mais oui simuler un serveur ssh et recuperer les mot de passes semble bien être possible!(mais si j'ai bien compris la connection doit être établie)
# Ou avec un module PAM qui le ferait
Posté par ninis666 . Évalué à 1.
J'ai pas testé mais avec un module PAM comme : https://github.com/cameron-gagnon/ssh_pass_logging , tu as une solution élégante pour logger les password.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.