Linux – Log Qu'est-ce nom d'user et mot de passe a été essayé

J'utilise Ubuntu Server et je suis curieux s'il existe de toute façon pour save quel nom d'user et mot de passe un attaquant potentiel a essayé.

Je peux grep /var/log/auth.log et voir toutes les tentatives échouées mais j'aimerais voir quel nom d'user et passwords ils essayent.

Vous pouvez visualiser les noms d'user ayant échoué après avoir sshd_config la verbosité du journal dans sshd_config , mais il est impossible de voir les passwords ayant échoué, car cela pourrait constituer un problème de security potentiel et violerait la confidentialité des users mistype votre mot de passe et il serait divulgué dans un file journal).

Tous les passwords sont traités comme des données extrêmement sensibles et ne sont stockés dans la memory et jamais écrits dans un journal afin qu'ils ne puissent pas sortir de leur context de security.

Pour ce faire, vous devez utiliser un pot de miel spécialement conçu pour ce cas d'utilisation, et non des produits de security de production standard.

¹ Voir man sshd_config pour plus d'informations

La raison pour laquelle cela n'est PAS fait est facilement révélée en regardant ce qui peut arriver sur un site où il est fait.

Il m'a été demandé d'améliorer la force de hachage du mot de passe d'un site qui a enregistré de mauvais passwords (pour quelle raison possible ils l'ont fait, je ne peux pas l'imaginer). Pour minimiser les désagréments de l'user, je l'ai d'abord converti automatiquement les users pendant qu'ils se connectaient, mais comme ceux qui ne s'étaient pas connectés pendant un certain time avaient aussi besoin d'une protection améliorée, j'ai essayé de les craquer en convertissant tous les passwords devenus .

Après une semaine passée à essayer tout ce que je savais, les lists de passwords connus de grandes fuites comme facebook et donc les dictionarys de plusieurs langues, permutations et ainsi de suite, il me restait environ 4000 passwords de personnes qui n'étaient pas connectées et que je ne pouvais pas fissure.

J'ai pris le mauvais journal des passwords ces dernières années, j'ai utilisé ces passwords contre les passwords incrustables et j'ai craqué un quart du rest . C'est-à-dire qu'il a deviné le quart des passwords très dur du système, y compris plusieurs counts d'administration, ce qui signifie que je n'avais qu'à réinitialiser les passwords de 3000 users plutôt que 4000.

Je pense donc que la valeur d'un tel journal, pour un attaquant malveillant, ne peut pas être surestimée.

Il n'y a simplement aucune bonne raison valable de consigner les passwords manquants, et toutes les raisons pour éviter de le faire – si ces données fuient, vous avez communiqué des informations de connection pour une grande partie de vos users. Ces «mauvais passwords» seront des passwords qu'ils ont redéfinis ou qu'ils utilisent sur d'autres counts de votre système ou qu'ils utilisent sur un autre système (leur banque, leur adresse e-mail …)

En conservant un tel journal, vous mettez en danger vos users sans réel avantage en matière de security.