Comment savoir si mon serveur Linux a été piraté ?

Solution 1 :

Conservez une copie vierge des fichiers système critiques (tels que ls, ps, netstat, md5sum) quelque part, avec une somme md5 d'entre eux, et comparez-les régulièrement aux versions en direct. Les rootkits modifieront invariablement ces fichiers. Utilisez ces copies si vous pensez que les originaux ont été compromis.
aide ou fil de déclenchement vous indiquera tous les fichiers qui ont été modifiés - en supposant que leurs bases de données n'ont pas été altérées.
Configurez syslog pour envoyer vos fichiers journaux à un serveur de journal distant où ils ne peuvent pas être altérés par un intrus. Surveillez ces fichiers journaux distants pour toute activité suspecte
lisez vos journaux régulièrement - utilisez logwatch ou vérification du journal pour synthétiser les informations critiques.
Connaissez vos serveurs . Sachez quels types d'activités et de journaux sont normaux.

Solution 2 :

Vous ne le faites pas.

Je sais, je sais - mais c'est la vérité paranoïaque et triste, vraiment;) Il y a bien sûr beaucoup d'indices, mais si le système était spécifiquement ciblé - il pourrait être impossible de le dire. Il est bon de comprendre que rien n'est jamais complètement sécurisé. Mais nous devons travailler pour plus de sécurité, je vais donc pointer toutes les autres réponses à la place ;)

Si votre système a été compromis, aucun de vos outils système ne peut révéler la vérité.

Solution 3 :

Tripwire est un outil couramment utilisé - il vous avertit lorsque les fichiers système ont changé, bien qu'évidemment vous deviez l'avoir installé au préalable. Sinon, des éléments tels que de nouveaux comptes d'utilisateurs dont vous n'êtes pas au courant, des processus et des fichiers étranges que vous ne reconnaissez pas, ou une utilisation accrue de la bande passante sans raison apparente sont les signes habituels.

D'autres systèmes de surveillance tels que Zabbix peuvent être configurés pour vous alerter lorsque des fichiers tels que /etc/passwd sont modifiés.

Solution 4 :

Certaines choses qui m'ont averti dans le passé :

Charge élevée sur un système qui devrait être inactif
Défauts de segmentation étranges, par ex. à partir d'utilitaires standards comme ls (cela peut arriver avec des rootkits cassés)
Répertoires cachés dans / ou /var/ (la plupart des script kiddies sont trop stupides ou paresseux pour brouiller les pistes)
netstat affiche les ports ouverts qui ne devraient pas être là
Des démons dans la liste des processus dont vous utilisez normalement différentes variantes (par exemple, bind , mais vous utilisez toujours djbdns )

De plus, j'ai trouvé qu'il y a un signe fiable qu'une machine est compromise :si vous avez un mauvais pressentiment quant à la diligence (avec les mises à jour, etc.) de l'administrateur dont vous avez hérité d'un système, gardez un œil dessus !

Solution 5 :

Il existe une méthode pour vérifier les serveurs piratés via kill -

Essentiellement, lorsque vous exécutez "kill -0 $PID", vous envoyez un signal nop pour traiter l'identifiant $PID. Si le processus est en cours d'exécution, la commande kill se terminera normalement. (FWIW, puisque vous passez un signal nop kill, rien n'arrivera au processus). Si un processus n'est pas en cours d'exécution, la commande kill échouera (état de sortie inférieur à zéro).

Lorsque votre serveur est piraté / qu'un rootkit est installé, l'une des premières choses qu'il fait est de dire au noyau de masquer les processus affectés des tables de processus, etc. Cependant, il peut faire toutes sortes de choses sympas dans l'espace du noyau pour jouer avec le processus. Et donc cela signifie que

a) Cette vérification n'est pas une vérification approfondie, car les rootkits bien codés/intelligents s'assureront que le noyau répondra par une réponse "le processus n'existe pas", rendant cette vérification redondante.b) Dans tous les cas, lorsqu'un serveur piraté a un "mauvais" processus en cours d'exécution, son PID ne s'affichera généralement pas sous /proc.

Alors , si vous êtes ici jusqu'à présent, la méthode consiste à tuer -0 tous les processus disponibles dans le système (de 1 -> /proc/sys/kernel/pid_max) et de voir s'il y a des processus en cours d'exécution mais non signalés dans /proc.

Si certains processus s'exécutent, mais ne sont pas signalés dans /proc, vous avez probablement un problème de quelque manière que vous le considériez.

Voici un script bash qui implémente tout cela - https://gist.github.com/1032229 . Enregistrez-le dans un fichier et exécutez-le, si vous trouvez un processus qui n'est pas signalé dans proc, vous devriez avoir une piste pour commencer à creuser.

HTH.