web-dev-qa-db-fra.com

SSH cassé pour utilisateur sans shell

Je pense que ma boîte Ubuntu a été cassée et que le pirate a tenté de spammer des courriels (via le port 25) avec mon ordinateur.

Une partie de /var/log/auth.log est extraite comme ci-dessous (j'ai remplacé l'utilisateur réel par myuser et une adresse IP externe par 1.2.3.x):

Feb 20 06:07:12 ubuntu systemd-logind[954]: New session 77 of user myuser.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.4 port 25: failed.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.5 port 25: failed.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.5 port 25: failed.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.6 port 25: failed.
...(thousands of similar lines follows)...

Étant donné que le message d'erreur a été généré par sshd, je suppose que le pirate informatique a pu y accéder en se connectant à SSH en tant que myuser. Son enregistrement respectif dans /etc/passwd est comme ci-dessous:

myuser:x:1003:1004:myuser:/home/myuser:/bin/false

Je suppose que le pirate informatique n'aurait pas dû être en mesure de se connecter car le shell pour myuser est /bin/false, c'est-à-dire qu'il devrait être expulsé immédiatement même s'il peut se connecter. Je ne parviens pas à me connecter myuser à travers PuTTY aussi. L’enregistrement de ma propre connexion est quelque chose comme:

Feb 22 10:26:58 ubuntu sshd[3653]: pam_unix(sshd:session): session opened for user myuser by (uid=0)
Feb 22 10:26:58 ubuntu systemd-logind[734]: New session 2 of user myuser.
Feb 22 10:26:58 ubuntu sshd[3653]: pam_unix(sshd:session): session closed for user myuser

Donc, évidemment, il y a un problème avec mes réglages et/ou /bin/false ne fonctionne pas dans le fichier /etc/passwd. Quel est le problème avec mon paramètre actuel, et comment dois-je corriger la faille?

sshsecurityauthentication
5
Kenneth L

This article dans commandline.ninja sur/bin/false,/sbin/nologin et SSH semble répondre à votre question.

Résumé

Un pirate informatique peut contourner la protection consistant à utiliser /bin/false en tant que shell pour cet utilisateur utilisant le transfert de port via la commande ssh comme:

[user@panel~] ssh -N [email protected] -L 2525:127.0.0.1:25

Correctifs temporaires

Désactiver le transfert de port

Le plus simple et le plus radical, si possible dans votre scénario, consiste simplement à désactiver le transfert de port TCP dans votre fichier de configuration sshd (/etc/ssh/sshd_config sur de nombreux systèmes):

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

Bloquer le compte utilisateur/mot de passe

  • Éditez /etc/shadow et définissez le mot de passe de l'utilisateur sur *
  • Confirmez qu'aucune clé SSH pour cet utilisateur n'existe dans votre système.

mot de passe fantôme ayant * comme mot de passe crypté dans /etc/shadow signifie que le compte est verrouillé, l'utilisateur ne pourra pas se connecter via l'authentification par mot de passe mais d’autres méthodes (par exemple, la clé SSH) peuvent toujours être autorisées .

Pour plus d’informations, consultez la page commandline.ninja à propos de/bin/false,/sbin/nologin et SSH .

5
Yaron