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

Quels sont les signes avant-coureurs qu'un serveur Linux a été piraté? Existe-t-il des outils permettant de générer et d'envoyer par courrier électronique un rapport d'audit sur une base programmée?

1. Conservez une copie vierge des fichiers système critiques (tels que ls, ps, netstat, md5sum) quelque part, avec un md5, et comparez-les régulièrement avec les versions en direct. Les rootkits modifieront invariablement ces fichiers. Utilisez ces copies si vous pensez que les originaux ont été compromis.
2. aide ou tripwire vous informera de tous les fichiers modifiés - en supposant que leurs bases de données n’ont pas été altérées.
3. Configurez syslog pour envoyer vos fichiers journaux à un serveur de journalisation distant où ils ne peuvent pas être altérés par un intrus. Surveillez ces fichiers journaux distants à la recherche d'activités suspectes
4. lisez vos journaux régulièrement - utilisez logwatch ou logcheck pour synthétiser les informations critiques.
5. Connaissez vos serveurs . Sachez quels types d'activités et de journaux sont normaux.

Vous pas.

Je sais, je sais - mais c'est la vérité paranoïaque et triste, vraiment;) Il y a de nombreuses allusions bien sûr, mais si le système était ciblé spécifiquement - il serait peut-être impossible de le savoir. C'est bien de comprendre que rien n'est jamais complètement sécurisé. Mais nous devons travailler pour plus de sécurité, alors je vais plutôt indiquer toutes les autres réponses;)

Si votre système était compromis, vous ne pouvez faire confiance à aucun de vos outils système pour révéler la vérité.

Tripwire est un outil couramment utilisé - il vous avertit lorsque des fichiers système ont été modifiés, bien que vous deviez évidemment l'avoir préalablement installé. Sinon, des éléments tels que les nouveaux comptes d'utilisateurs que vous ne connaissez pas, les processus étranges et les fichiers que vous ne reconnaissez pas, ou l'augmentation de l'utilisation 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 avertir lorsque des fichiers tels que / etc / passwd sont modifiés.

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

• Charge élevée sur un système qui devrait être inactif
• Segfaults étranges, par exemple. à partir d'utilitaires standard tels que 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 couvrir leurs traces)
• netstat montre des ports ouverts qui ne devraient pas être là
• Daemons dans la liste de processus que vous utilisez normalement différentes versions de (par exemple bind, mais que vous utilisez toujours djbdns)

De plus, j'ai découvert qu'il y a un signe fiable qu'une boîte est compromise: si vous avez un mauvais pressentiment face à la diligence (avec les mises à jour, etc.) de l'administrateur dont vous avez hérité d'un système, surveillez-le de près!

Il existe une méthode de vérification des serveurs piratés via kill-

Essentiellement, lorsque vous exécutez "kill -0 $ PID", vous envoyez un signal nop pour traiter l'identificateur $ PID. Si le processus est en cours d'exécution, la commande kill se ferme normalement. (FWIW, puisque vous passez un signal nop kill, rien ne se passera dans le 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 d'indiquer au noyau de masquer les processus affectés des tables de processus, etc. processus. Et si cela signifie que

a) Cette vérification n'est pas une vérification approfondie, car les rootkits bien codés / intelligents veilleront à ce que le noyau réponde avec une réponse "le processus n'existe pas" rendant cette vérification redondante. b) Quoi qu'il en soit, lorsqu'un serveur piraté exécute un "mauvais" processus, son PID n'apparaît généralement pas sous / proc.

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

Si certains processus arrivent en cours d'exécution, mais ne sont pas signalés dans / proc, vous avez probablement un problème quelle que soit la façon dont vous le regardez.

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 ne figure pas dans proc, vous devriez avoir une piste pour commencer à creuser.

HTH.

J'appuie les réponses données ici et j'ajouterai l'une des miennes.

find /etc /var -mtime -2

Cela vous indiquera rapidement si l’un des fichiers de votre serveur principal a été modifié au cours des 2 derniers jours.

Ceci est tiré d'un article sur la détection de piratage Comment détecter si votre serveur a été piraté.

De Comment puis-je détecter les intrusions indésirables sur mes serveurs?

• Utiliser un IDS

  SNORT® est un système de prévention et de détection des intrusions réseau open source utilisant un langage basé sur des règles, qui combine les avantages des méthodes d’inspection basées sur la signature, les protocoles et les anomalies. Avec des millions de téléchargements à ce jour, Snort est la technologie de détection et de prévention des intrusions la plus largement déployée dans le monde et est devenue le standard de facto pour l'industrie.

  Snort lit le trafic réseau et peut rechercher, par exemple, des "tests de lecteur par stylet" dans lesquels une personne exécute une analyse complète de métasploit sur vos serveurs. Bon à savoir ce genre de choses, à mon avis.

• Utilisez les journaux ...

  Selon votre utilisation, vous pouvez le configurer pour que vous sachiez chaque fois qu'un utilisateur se connecte ou se connecte depuis une adresse IP impaire, ou chaque fois que la racine se connecte ou chaque fois qu'une personne tente de se connecter. En fait, le serveur m'envoie par courrier électronique chaque message de journal supérieur à Debug. Oui, même avis. J'en filtre certains, bien sûr, mais chaque matin, lorsque je reçois 10 courriels sur des problèmes, cela me donne envie de les réparer pour que cela cesse.

• Surveillez votre configuration - je garde tout mon / etc dans la sous-version afin de pouvoir suivre les révisions.

• Exécuter des analyses. Des outils tels que Lynis et Rootkit Hunter peuvent vous donner des alertes sur les failles de sécurité possibles dans vos applications. Il existe des programmes qui maintiennent un hachage ou une arborescence de hachage de toutes vos corbeilles et peuvent vous alerter des modifications.

• Surveillez votre serveur - tout comme vous avez mentionné l'espace disque - les graphiques peuvent vous donner un indice si quelque chose d'inhabituel. J'utilise Cacti pour garder un oeil sur le processeur, le trafic réseau, espace disque, les températures, etc. Si quelque chose ressemble étrange est étrange et vous devriez savoir pourquoi il est étrange.

J'aimerais juste ajouter à cela:

Vérifiez votre historique bash, s'il est vide et que vous ne l'avez pas désinstallé ou vidé, il est fort possible que quelqu'un ait compromis votre serveur.

Vérifiez en dernier. Vous verrez soit une adresse IP inconnue, soit une apparence très vide.

Ensuite, comme indiqué dans la réponse acceptée, les fichiers système sont souvent modifiés, vérifiez la date de modification. Cependant, ils altèrent souvent la date modifiée.

Ils installent souvent une autre version de ssh fonctionnant sur un port aléatoire. Ceci est souvent caché dans des endroits vraiment étranges. Notez qu'il sera normalement renommé en autre chose que ssh. Vérifiez donc netstat (qui pourrait ne pas fonctionner car ils le remplacent souvent) et utilisez iptables pour bloquer les ports inconnus.

Dans tous les cas, il vaut mieux prévenir que guérir. Si vous avez été compromis, il est préférable de simplement formater et de recommencer. Il est presque impossible de confirmer que vous avez nettoyé le hack avec succès.

Prenez note de ce qui suit pour éviter que votre serveur ne soit compromis.

1. Changer le port ssh
2. Empêcher la racine de pouvoir se connecter
3. n'autoriser que certains utilisateurs
4. Empêcher la connexion par mot de passe
5. Utilisez des clés SSH, des clés préférables protégées par mot de passe
6. Dans la mesure du possible, répertoriez toutes les adresses IP et les adresses requises.
7. Installer et configurer fail2ban
8. Utilisez tripwire pour détecter les intrusions
9. Surveillez le nombre d'utilisateurs connectés avec Nagios ou zabbix. Même si vous êtes averti chaque fois que vous vous connectez, au moins vous saurez quand un autre joueur joue.
10. Si possible, conservez votre serveur sur un vpn et n'autorisez que ssh via vpn ip. Sécurisez votre vpn.

Cela vaut la peine de noter qu’une fois sur un serveur, ils vérifieront votre historique bash et rechercheront d’autres serveurs auxquels vous vous êtes connecté via ssh à partir de ce serveur. Ils tenteront ensuite de se connecter à ces serveurs. Donc, si vous êtes brutalement forcé à cause d'un mauvais mot de passe, il est fort possible qu'ils puissent se connecter à l'autre serveur et les compromettre également.

C'est un monde laid, je répète que mieux vaut prévenir que guérir.

Après avoir cherché un peu, il y a aussi ceci, il fait ce que j'ai énuméré ci-dessus, parmi d'autres choses: http://www.chkrootkit.org/ et http://www.rootkit.nl/projects/rootkit_hunter.html

Vous devriez vérifier GuardRail. Il peut analyser votre serveur quotidiennement et vous dire ce qui a changé de manière visuelle. Il ne nécessite pas d'agent et peut se connecter via SSH, vous n'avez donc pas besoin de casser votre machine et vos ressources avec un agent.

Le meilleur de tous, c'est gratuit pour un maximum de 5 serveurs.

Vérifiez le ici:

https://www.scriptrock.com/