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 d'installation de SSH sur Ubuntu et essayé de respecter les bonnes pratiques de sécurité. J'ai désactivé l'authentification par mot de passe, le seul moyen d'entrer était donc avec des clés RSA. Je n'avais que 2 clés répertoriées dans le fichier allowed_keys: le mien (utilisé lors des tests pour voir si ssh fonctionnait correctement) et un ami.
Ce soir, j'étais curieux de voir si mon ami était ssh'd dans mon système pendant que je l'utilisais, alors j'ai cherché sur Google pour une commande qui me dirait si quelqu'un était ssh'd, et si oui, qui. Le résultat que j'ai obtenu était:
Sudo netstat -tnpa | grep ESTABLISHED.*sshd
Je l'ai essayé et le résultat était:
tcp 0 0 192.168.1.86:22 59.47.0.150:44728 ESTABLISHED 7416/sshd: [accepte
Cela n'a pas l'air correct. J'ai contacté mon ami et il m'a assuré qu'il n'était pas connecté. J'ai réessayé la commande et vu:
tcp 0 0 192.168.1.86:22 59.47.0.150:44728 ESTABLISHED 7416/sshd: root [pr
À ce stade, j'étais un peu paniqué par le mot "racine" 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
qui a sorti:
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 complètement paniquée, alors même si je voulais attendre un peu et voir si je pouvais savoir qui était connecté, j'ai décidé de simplement Sudo stop ssh.
Après quelques recherches supplémentaires, j'ai découvert que 59.47.0.150 est une adresse IP située à/près de Shenyang, en Chine, et qui semble être spécialement connu pour ses attaques malveillantes attaques .
Alors mes questions à vous les gars sont:
Pouvons-nous affirmer avec certitude qu’une adresse IP de Chine est en quelque sorte une adresse SSH dans ma machine? Même si elle n’a accepté que l’autorisation de clé RSA?
Pouvons-nous dire avec certitude qu'il/elle a également un accès root? Dans ma ssh-config, j'avais la valeur par défaut
PermitRootLogin without-password. Je pensais à l'origine que cela signifiait que la connexion root n'était pas autorisée (je sais que les deux sons semblent contradictoires, mais je l'avais recherché sur Google et c'est le résultat que j'ai obtenu)Si c'est le cas, comment?
Est-ce que je peux voir quels dommages ont été causés jusqu'à présent?
Comment puis-je me protéger contre cela à l'avenir? J'ai toujours besoin de faire fonctionner ssh pour terminer mon projet de groupe.
Merci pour toute aide que vous pouvez offrir!
EDIT: Selon les suggestions de saiarcot895 et de Steven, j'ai vérifié auth.log, qui a souvent répété les lignes suivantes:
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 n'a pas réussi à se connecter à root, ou qu'il tente d'accéder directement à root, a échoué et n'a encore accédé à rien?
Pouvons-nous affirmer avec certitude qu’une adresse IP de Chine est en quelque sorte une adresse SSH dans 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 aient réussi à obtenir une clé valide. Essayez de vous connecter à partir d'un hôte que vous contrôlez sans clé et vérifiez les processus en cours. 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 aussi la racine? Dans ma ssh-config, j'avais la valeur par défaut
PermitRootLogin without-password. Je pensais à l'origine que cela signifiait que la connexion root n'était pas autorisée (je sais que les deux sons semblent contradictoires, mais je l'avais recherché sur Google et c'est le résultat que j'ai obtenu)
L'option 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 le plus étroitement possible. Sauf si vous avez activé une clé, il est peu probable que vous puissiez vous connecter à root à l'aide de SSH. without-password désactive les connexions avec mot de passe, mais pas la méthode d'authentification par mot de passe.
Si c'est le cas, comment?
Vous pouvez consulter le journal d'authentification pour voir si une authentification a réussi. Cependant, s’ils ont réussi, ils ont peut-être écrasé les preuves.
Est-ce que je peux voir quels dommages ont été causés jusqu'à présent?
L'exécution d'un vérificateur de rootkit et la vérification des signatures de fichiers hors connexion doivent indiquer si des fichiers ont été compromis. Prendre des signatures de fichiers et les stocker hors ligne pendant que vous êtes en sécurité vous donnera une base.
Comment puis-je me protéger contre cela à l'avenir? J'ai toujours besoin de faire fonctionner ssh pour terminer mon projet de groupe.
sshd prend en charge l'utilisation de tcpwrappers pour limiter l'accès. Créez un jeu de règles qui autorise uniquement l'accès à partir de plages d'adresses pour lesquelles vous attendez du trafic.
S'il ne s'agit que d'une attaque par force brute remplissant des journaux, changez simplement le port.
La plupart des scripts sont stupides et il y a suffisamment de serveurs pour écouter le port 22. Je mets toujours le mien à, par exemple. 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 alors être consulté avec une option supplémentaire à ssh
ssh -p224 [email protected]
Ma journaux étaient toujours pleins, j'ai changé de port et le bruit avait disparu.
Beaucoup d'attaques par force brute de ssh ont lieu. Il est possible que vous ayez un paquet ssh obsolète et ils l’ont obtenu de cette façon.
Vérifiez les échecs SSH dans les journaux, il peut simplement faire une force brutale contre vous.
accédez à/tmp et publiez sa sortie à partir de ls -al. S'il existe un kit racine, il peut s'afficher ici.
Vous pouvez définir autoriser les utilisateurs dans ssh et fail2ban est également utile.
Définir/tmp et/home comme non-exécutables dans fstab, si possible, aidera beaucoup.