Mon serveur Linux a été piraté. Comment savoir comment et quand cela a été fait?

J'ai un serveur domestique exécutant une distribution Ubuntu de bureau. J'ai trouvé ça dans ma crontab

* * * * * /home/username/ /.access.log/y2kupdate >/dev/null 2>&1

et en regardant dans ce répertoire (l'espace après le nom d'utilisateur / est un nom de répertoire), j'ai trouvé beaucoup de scripts qui font évidemment quelque chose qu'ils ne devraient pas faire.

Avant de nettoyer cet ordinateur et de réinstaller des éléments, j'aimerais savoir ce qui a causé la violation de sécurité et quand cela a été fait. Je n'ouvre donc plus le même trou.

Dans quels fichiers journaux dois-je regarder? Les seuls serveurs que je connais qui fonctionnent sur l'ordinateur sont sshd et lighttpd.

Que dois-je faire pour détecter si de telles choses se reproduisent?

Tout d'abord, assurez-vous que l'ordinateur est déconnecté de tout réseau.
Deuxièmement, assurez-vous de retirer toutes les données importantes des disques avant de redémarrer le système d'exploitation piraté.

Commencez par vérifier les horodatages des fichiers en question. Ils sont souvent précis.
Croisez ceux qui ont le journal httpd et le journal d'authentification s'ils n'ont pas été effacés. Si l'autre s'est essuyé, on peut parier que c'était le moyen d'entrée. S'ils sont toujours en contact, vous pourrez peut-être glaner plus d'informations sur la façon dont ils sont entrés dans le journal.

S'ils sont tous essuyés, vous êtes plutôt foutus. Il faudrait probablement plus de temps pour comprendre ce qui s'est passé que cela ne vaut.

Vous avez mentionné que ces deux services étaient en cours d'exécution, y avait-il un bon pare-feu en place pour empêcher tout autre accès? Avez-vous autorisé SSH sur le port 22; votre connexion est-elle raisonnablement facile à deviner; avez-vous autorisé les connexions par mot de passe; aviez-vous une sorte de limitation du débit réel pour les connexions par mot de passe? Avez-vous installé un logiciel supplémentaire avec lighttpd; perl; php; cgi; un CMS ou similaire? Exécutiez-vous une version mise à jour de tous les logiciels; vous abonnez-vous aux notifications de sécurité pour tous les logiciels que vous exécutez et évaluez soigneusement toutes les notifications pour voir si elles s'appliquent aux logiciels que vous exécutez / exposez au public?

C'est une sorte de sujet en soi; vous pouvez google for linux forensics pour plus d'informations. Fondamentalement, vous devez d'abord créer une image de vos disques pour une analyse hors ligne, puis essuyer l'ordinateur et installer à partir d'une table rase.

Et rappelez-vous tous les faux frais. Toute personne utilisant l'ordinateur aurait pu voir son mot de passe compromis. Modifiez les mots de passe, gardez-les hors ligne, etc. jusqu'à ce que vous les obteniez dans une «salle blanche» (machine virtuelle isolée).

Sinon, c'est beaucoup de vérification des journaux (qui peuvent être falsifiés) et de vérification de vos applications (scripts php? Bases de données? Mis à jour pour les derniers correctifs? D'autres utilisateurs donnent des mots de passe?)

Il n'y a littéralement aucun moyen facile de répondre à votre question, car vous devez effectuer un travail médico-légal sur le serveur et vérifier les trous. Vous pouvez utiliser certains outils automatisés, mais gardez à l'esprit que si l'attaquant avait des privilèges root, vous ne pouvez plus faire confiance aux binaires du système et vous ne pouvez pas faire confiance aux journaux.

En ce qui concerne les futures attaques, selon le niveau de sécurité que vous souhaitez sécuriser, vous pouvez commencer par rediriger vos journaux vers un système qui est juste utilisé pour enregistrer les journaux système. Aucun autre accès, pour réduire l'empreinte de l'attaque.

Vous devez également exécuter un logiciel de somme de contrôle sur votre système comme Tripwire pour vérifier l'intégrité de vos fichiers.

Et bien sûr, restez à jour avec les mises à jour et exécutez un logiciel d'analyse qui vérifie les rootkits.

Encore une fois, la sécurité n'est pas une chose à jeter. Cela peut aussi être une spécialité en soi. La sécurité en couches peut être aussi stricte que la vérification des hôtes / IP qui n'appartiennent pas à votre réseau, le chiffrement de tous les accès au système, l'envoi de journaux quotidiens des modifications trouvées sur votre système et la configuration d'un pot de miel sur votre réseau pour recherchez une activité étrange (pourquoi mon serveur essaie-t-il de se connecter au port 25 sur l'ordinateur du pot de miel?)

Tout d'abord, si vous souhaitez vérifier l'activité, obtenir l'image disque et réinstaller le logiciel serveur. De zéro. Les fichiers binaires du serveur ne sont plus fiables.

EDIT - d'autres choses qui me viennent à l'esprit depuis que vous exécutez SSH - installez denyhosts. Il peut être configuré de sorte que les attaques automatisées contre votre système sur SSHD soient bloquées après X nombre d'essais. Il peut également être configuré pour se mettre à jour à partir d'autres serveurs denyhost dans un «cloud» pour partager des IP verrouillées afin de minimiser les attaques automatisées. Vous pouvez également déplacer le port sur lequel il écoute; de nombreuses personnes soulignent que ce n'est que de la sécurité grâce à l'obscurité, mais étant donné le nombre de robots analysant, cela réduit considérablement les tentatives aléatoires de percée.