3 votes

Mon serveur SSH a-t-il été compromis? Si oui, comment, et quelles mesures dois-je prendre?

J'ai récemment activé l'accès ssh à ma machine pour travailler sur un projet de groupe avec mes camarades de classe. J'ai lu le guide pour configurer ssh sur ubuntu et j'ai essayé de suivre de bonnes pratiques en matière de sécurité. J'ai désactivé l'authentification par mot de passe, donc le seul moyen d'accéder était avec des clés RSA, et j'avais seulement 2 clés répertoriées dans le fichier authorized_keys : la mienne (je l'ai utilisée pendant les tests pour vérifier que ssh fonctionnait correctement) et celle d'un ami.

Ce soir, j'étais curieux de voir si mon ami était connecté en ssh sur mon système pendant que je l'utilisais, donc j'ai cherché sur Google une commande qui me dirait si quelqu'un était connecté en ssh, et si c'était le cas, qui. Le résultat que j'ai obtenu était :

sudo netstat -tnpa | grep ESTABLISHED.*sshd

Je l'ai essayé, et la sortie était :

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: [accepte

Cela n'avait pas l'air correct. J'ai contacté mon ami et il m'a assuré qu'il n'était pas connecté. J'ai essayé à nouveau la commande, et j'ai vu :

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: root [pr

À ce stade, le mot "root" m'a un peu effrayé et j'ai envoyé un message à un ami qui en savait plus que moi sur ce sujet. Il m'a dit d'essayer :

 ps aux | grep ssh

ce qui a produit :

root      3702  0.0  0.0  61364  2872 ?        Ss   Apr12   0:00 /usr/sbin/sshd -D
root      7473  0.0  0.0 112692  3920 ?        Ss   20:46   0:00 sshd: root [priv]   
sshd      7474  0.0  0.0  62784  1516 ?        S    20:46   0:00 sshd: root [net]    
sid       7476  0.0  0.0  22476   936 pts/1    S+   20:46   0:00 grep --color=auto ssh

Maintenant j'étais vraiment inquiet, donc même si je voulais attendre un peu pour voir si je pouvais découvrir qui était connecté, j'ai décidé de simplement sudo stop ssh.

Après avoir fait quelques recherches, j'ai découvert que 59.47.0.150 est une IP à Shenyang, en Chine, et semble être spécifiquement connue pour des attaques malveillantes.

Donc mes questions pour vous sont :

  1. Pouvons-nous affirmer avec certitude qu'une IP chinoise s'est somehow connectée en ssh à ma machine ? Même si elle n'acceptait que l'autorisation par clé RSA ? < /p>

  2. Pouvons-nous affirmer avec certitude qu'il/elle a également obtenu un accès root ? Dans mon fichier de configuration ssh, j'avais le PermitRootLogin without-password par défaut. Je pensais à l'origine que cela signifiait que la connexion root n'était pas autorisée (je sais que les deux semblent contradictoires, mais j'avais cherché sur Google et c'est le résultat que j'ai obtenu) < /p>

  3. Si c'est le cas, comment ? < /p>

  4. Y a-t-il un moyen de voir les dommages qui ont été causés jusqu'à présent ? < /p>

  5. Comment puis-je me prémunir contre cela à l'avenir ? J'ai toujours besoin d'avoir ssh en cours d'exécution pour terminer mon projet de groupe. < /p>

Merci pour toute aide que vous pourrez offrir !< /p>

EDIT: Comme sugéré par saiarcot895 et Steven, j'ai vérifié auth.log, qui contenait les lignes suivantes répétées à plusieurs reprises :< /p>

    Apr 13 20:43:50 PrometheusU sshd[7392]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:55 PrometheusU sshd[7394]: reverse mapping checking getaddrinfo for 150.0.47.59.broad.bx.ln.dynamic.163data.com.cn [59.47.0.150] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 13 20:43:55 PrometheusU sshd[7394]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:58 PrometheusU sshd[7394]: Failed password for root from 59.47.0.150 port 54813 ssh2
Apr 13 20:44:03 PrometheusU sshd[7394]: message repeated 2 times: [ Failed password for root from 59.47.0.150 port 54813 ssh2]
Apr 13 20:44:04 PrometheusU sshd[7394]: Received disconnect from 59.47.0.150: 11:  [preauth]

Cela signifie-t-il que l'attaquant est entré dans mon système et a échoué à se connecter en tant que root, ou qu'il/elle tente d'accéder directement à root, a échoué et n'a pas accédé à quoi que ce soit du tout ?< /p>

3voto

AdamB Points 1290

Pouvons-nous dire avec certitude qu'une IP de Chine s'est connectée en SSH sur ma machine? Même si elle n'a accepté que l'autorisation de clé RSA?

Il est peu probable qu'ils aient été authentifiés, à moins qu'ils n'aient réussi à obtenir une clé valide. Essayez de vous connecter depuis un hôte que vous contrôlez sans clé et vérifiez les processus en cours d'exécution. Ils devraient être similaires à ce que vous avez vu. Le fait que le processus [net] s'exécute en tant que sshd indique qu'ils n'ont pas réussi à se connecter.

Pouvons-nous dire avec certitude qu'il/elle a également obtenu les droits root? Dans ma configuration ssh, j'avais le PermitRootLogin without-password par défaut. Au départ, je pensais que cela signifiait que la connexion en tant que root n'était pas autorisée (je sais que les deux sons contradictoires, mais j'ai cherché sur Internet et c'était le résultat que j'ai obtenu)

L'option que vous avez utilisée autorise les connexions à root, mais désactive l'authentification par mot de passe pour root. Il est recommandé de ne pas autoriser les connexions root via SSH sauf si vous en avez vraiment besoin. Si vous restreignez l'accès, faites-le le plus strictement possible. À moins que vous n'ayez activé une clé, il est peu probable que vous puissiez vous connecter à root en utilisant SSH. Le without-password désactive les connexions basées sur les mots de passe, mais n'empêche pas la méthode d'authentification par mot de passe.

Si c'est le cas, comment?

Vous pouvez vérifier le journal d'authentification pour voir si des authentifications ont réussi. Cependant, s'ils ont réussi, ils ont peut-être effacé les preuves.

Y a-t-il un moyen de voir les dommages qui ont été causés jusqu'à présent?

Exécuter un vérificateur de rootkit et vérifier les signatures de fichiers hors ligne devrait indiquer si des fichiers ont été compromis. Prenez des signatures de fichiers et stockez-les hors ligne pendant que vous êtes sécurisé vous donnera une ligne de base.

Comment puis-je me protéger contre cela à l'avenir? J'ai encore besoin d'avoir ssh en cours d'exécution pour terminer mon projet de groupe.

sshd prend en charge l'utilisation de tcpwrappers pour restreindre l'accès. Élaborez un ensemble de règles qui n'autorisent l'accès que depuis des plages d'adresses dont vous attendez du trafic.

1voto

Steven Jones Points 11

Beaucoup d'attaques par force brute ssh ont lieu. Il est possible que vous ayez un package ssh obsolète et qu'ils soient entrés de cette manière.

Vérifiez les échecs ssh dans les journaux, il est peut-être simplement en train de faire une attaque par force brute contre vous.

allez à /tmp et postez sa sortie à partir de ls -al, s'il y a un root kit, il pourrait apparaître là-bas.

Vous pouvez définir les utilisateurs autorisés dans ssh et fail2ban est également utile.

Définir /tmp et /home comme non exécutables dans fstab si possible aidera beaucoup.

1voto

s1mmel Points 1794

Si c'est seulement une attaque par force brute remplissant les journaux, il suffit de changer le port.

La plupart des scripts sont stupides et il y a suffisamment de serveurs qui écoutent sur le port 22. Je configure toujours le mien par exemple sur 30200 ou 225. Ceci peut être fait facilement dans le

/etc/ssh/sshd.conf

Il suffit de changer le numéro de port et de redémarrer le démon.

Le système peut ensuite être accessible avec une option supplémentaire pour ssh

ssh -p224 user@example.com

Mes journaux étaient toujours pleins, j'ai changé le port et le bruit a disparu.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X