web-dev-qa-db-fra.com

Journalisation des tentatives d'accès SSH

J'ai configuré un serveur ubuntu avec openssh afin de s'y connecter et d'exécuter des commandes à partir d'un système distant comme un téléphone ou un ordinateur portable. Le problème est ... je ne suis probablement pas le seul.

Existe-t-il un moyen de connaître toutes les tentatives de connexion effectuées sur le serveur?

sshlogs
64
UserK

Sur les serveurs Ubuntu, vous pouvez trouver qui s'est connecté quand (et d'où) dans le fichier /var/log/auth.log. Vous y trouverez des entrées comme:

May  1 16:17:02 owl CRON[9019]: pam_unix(cron:session): session closed for user root
May  1 16:17:43 owl sshd[9024]: Accepted publickey for root from 192.168.0.101 port 37384 ssh2
May  1 16:17:43 owl sshd[9024]: pam_unix(sshd:session): session opened for user root by (uid=0)
59
Anthon

Sur les distributions basées sur Red Hat telles que Fedora/CentOS/RHEL, vous pouvez rechercher les utilisateurs connectés dans le fichier /var/log/secure.

Si vous voulez plus d'informations, lisez ce Q&R SuperUser intitulé: Comment puis-je enregistrer les tentatives d'accès SSH et garder une trace de ce que les utilisateurs SSH finissent par faire sur mon serveur? .

30
Ramesh

Sur Ubuntu, vous pouvez vous connecter via SSH et utiliser la commande Linux tail pour afficher le dernier x nombre de lignes de votre /var/log/auth.log fichier. Lorsque vous êtes connecté via SSH, utilisez la commande suivante pour afficher les 100 dernières lignes de votre journal SSH:

tail /var/log/auth.log -n 100

ou encore plus propre

tail -100 /var/log/auth.log | grep 'sshd'
9
WebComer

Notez que la configuration par défaut sur Ubuntu est de NE PAS connecter les connexions ssh au /var/log/auth fichier. Il s'agit du niveau de journalisation INFO.

Si vous souhaitez inclure des tentatives de connexion dans le fichier journal, vous devrez modifier le /etc/ssh/sshd_config fichier (en tant que root ou avec Sudo) et changez le LogLevel de INFO en VERBOSE.

Après cela, redémarrez le démon sshd avec

Sudo service rsyslog restart

Après cela, les tentatives de connexion ssh seront enregistrées dans le /var/log/auth.log fichier.

7
Shay Walters

Ma recommandation est d'utiliser auditd . C'est la journalisation en utilisant le sous-système d'audit du noyau Linux et à mon avis la bonne façon de le faire si vous êtes sérieux. Et étant donné la nature de la question {liée à la sécurité}, vous devriez également utiliser [~ # ~] pam [~ # ~] . Au niveau par défaut d'avoir simplement auditd et [~ # ~] pam [~ # ~] installés, vous devriez automatiquement obtenir tous les SSH réussis et infructueux tentatives enregistrées dans votre fichier audit.log. Donc, vous n'avez vraiment rien à configurer, il suffit d'installer auditd et [~ # ~] pam [~ # ~]. Je connais cette première main pour SLES. Et je parierais que RHEL et toute autre version enterprise de linux fonctionneraient de la même manière.

http://manpages.ubuntu.com/manpages/precise/man8/auditd.8.html

dans le journal d'audit brut généré par auditd vous pouvez utiliser soit utiliser quelque chose comme aureport pour le filtrer, ce qui est décrit dans les pages de manuel auditd , écrivez votre propre analyseur de texte ou utilisez simplement VI et recherchez des mots clés.

voici une exception de mon /var/log/audit/audit.log fichier avec moi ssh'ing dans mon serveur linux.

node=shark type=CRED_DISP msg=audit(1480622612.317:2211277): user pid=117768 uid=0 auid=23456 ses=2201 msg='op=PAM:setcred acct="ron" exe="/usr/sbin/sshd" (hostname=abc415.mycompany.us, addr=172.16.152.5, terminal=ssh res=success)'
  • à partir de ce qui précède, mon nom de serveur est requin.
  • de nombreuses lignes comme celle-ci sont dans audit.log, je veux que celle-ci soit basée sur exe = "/ usr/sbin/sshd"
  • l'uid du compte en cours de ssh est la valeur de auid, qui est 23456 pour cet exemple
  • le nom du compte utilisateur associé à auid est spécifié par acct = "ron"
  • la plupart du temps, le système d'audit enregistre le nom d'hôte DNS du système essayant de se connecter, mais il a toujours son adresse IP
  • la date de l'entrée qui est dans le temps Epoch, vous devrez donc le convertir via quelque chose comme date --date @1480622612.317 ce qui donne Thu Dec 1 15:03:32 EST 2016 et c'est quand j'ai été transféré sur mon serveur.

Quand res=failed est lorsque vous souhaitez rechercher ces adresses IP et noms d'hôtes pour voir quels systèmes tentaient de se connecter, sous quel nom d'utilisateur. Et évidemment, le ssh réussi tente de comprendre ce qui se passe sur votre système - par exemple, votre collègue Bob qui est assis au même bureau tous les jours avec hostname = bobscomputer et ip address = 192.168.5.5; si vous voyez une tentative ssh réussie à 2h du matin hier sous son nom d'utilisateur à partir de l'adresse IP 10.10.5.6 par exemple, alors il pourrait être dans votre intérêt de parler à bob pour enquêter. Possible tentative de piratage par quelqu'un d'autre? Et peu de temps après, y a-t-il des tentatives d'enracinement dans le journal d'audit du compte de Bob?

quand vous voyez répétitif res=failed et auid=0 et acct=root alors c'est quelqu'un qui essaie de ssh dans votre boîte dans le compte root, et c'est quand vous modifiez /etc/hosts.deny avec cette adresse IP pour SSHD.

4
ron

Je sais que c'est vieux mais j'ai écrit quelque chose pour surveiller les connexions/tentatives ssh réussies et échouées. Ainsi que les adresses IP interdites si vous utilisez sshguard. Le logiciel est écrit en Python. Il vous enverra un e-mail lorsque quelqu'un se connectera avec succès via ssh, lorsque le mot de passe ssh est incorrect ou lorsque quelqu'un est banni en raison de nombreuses tentatives infructueuses. J'espère que cela aidera quelqu'un à l'avenir qui recherchera ce problème et trouvera mon code!

https://github.com/amboxer21/SSHMonitor

Pour le script python, j'ai écrit un script bash pour surveiller le processus. Il vérifie s'il s'exécute toutes les minutes via la tâche cron racine. S'il n'est pas en cours d'exécution, il démarre un autre processus. Ce qu'on appelle par une tâche cron root toutes les minutes.

2
Aguevara

La meilleure chose que j'ai jamais rencontrée pour la journalisation des commandes SSH est rootsh cet outil permet à l'administrateur d'obtenir chaque commande de chaque session avec un niveau de journalisation étendu.

J'ai écrit un script pour installer et configurer ROOTSH dans Ubuntu et CentOS/RHEL

télécharger depuis github voici le lien

https://Gist.githubusercontent.com/mansurali901/e1e3acc7dca13aeca25b68a69571c60f/raw/b1b16f73ec9a974486e4c0c0d65a7d41f2eca718/setup_rootssh.sh

chmod +x setup_rootssh.sh ; Sudo ./setup_rootssh.sh
0
Mansur Ali