Que faire lorsque quelqu'un s'est connecté en tant que root sur mon serveur

J'ai un serveur exécutant Debian 6.0 avec logcheck installé. Hier, j'ai reçu ce message:

Jan 19 19:15:10 hostname sshd[28397]: Authentication tried for root with correct key but not from a permitted host (host=4.red-2-140-77.dynamicip.rima-tde.net, ip=2.140.77.4).

Je ne sais pas qui c'est et je doute qu'il soit là par accident.

Maintenant, que dois-je faire?

La première chose que j'ai faite a été de désactiver l'authentification par mot de passe ssh et de passer à la clé publique / privée. Je vérifie également le fichier authorized_keys et n'ai vu que ma clé publique

Et ensuite?

Comment puis-je savoir ce que l'autre gars a fait sur ma machine?

— Ben
source

Êtes-vous sûr que ce message électronique n'est pas un faux? Avez-vous vérifié vos journaux?

— César

Réponses:

Je pense que c'est un bug qui traîne depuis trop longtemps et qui est corrigé dans les versions ultérieures (6.0p1).

Il devrait être assez facile de vérifier cela en essayant de vous connecter vous-même au système à partir d'un hôte qui serait restreint, en utilisant une clé différente et en voyant les messages que vous recevez.

— user9517
source

J'ai en effet essayé avec une autre machine, je n'ai pas pu me connecter et j'ai reçu le même message de vérification du journal. Je suppose que c'est le bug ...

— Ben

Il s'agit peut- être d' un bogue de longue date dans OpenSSH qui n'a été corrigé que dans 6.0p1 . Dans ce cas, vous pouvez l'ignorer en toute sécurité. Cependant, si vous voulez être sûr, la réponse originale (en supposant que vous n'êtes pas affecté par ce bogue) est:

Vos clés privées ssh ont probablement été compromises, car quelqu'un avait une clé privée valide pour se connecter à votre compte root. Le fait que quelqu'un ne se soit pas connecté à partir d'une adresse IP autorisée vous a épargné d'autres compromis. Il s'agit néanmoins d'un compromis important; cela suggère que votre poste de travail (ou une autre machine à partir de laquelle vous travaillez généralement) a été compromis.

Vous devez considérer chaque poste de travail et serveur que vous touchez comme potentiellement compromis. Formatez et réinstallez vos postes de travail. Révoquer / détruire toutes vos clés ssh existantes et tout ressaisir. Modifiez tous les mots de passe. Envisagez sérieusement d'effacer et de réinstaller tous les serveurs sur lesquels vous avez accès pour vous connecter avec cette clé.

— Michael Hampton
source

Merci pour votre réponse, ce que je trouve très étrange, c'est qu'aucune tentative n'a échoué avant cette connexion réussie. Habituellement, lorsque quelqu'un essaie de se connecter en tant que root sur mon serveur, je vois plusieurs tentatives infructueuses. Ici, la connexion a réussi directement ... et le mot de passe root n'est pas qwerty: c'est un mot de passe généré

— Ben

Si vous utilisez réellement des fromrestrictions dans votre authorized_keyscomme indiqué dans les liens, alors vous êtes probablement affecté par ce bogue. Mais je me méfierais de la prudence ...

— Michael Hampton

Ben, la complexité du mot de passe root est sans importance pour cette entrée de journal, car l'accès s'est fait par clé.

— MadHatter

mmmh ... L'authentification par mot de passe a été activée, j'ai donc pensé que l'intrus avait trouvé ce mot de passe, pas qu'il utilisait des clés privées / publiques. Comment est-ce possible?

— Ben