Comment savoir si mon serveur Linux a été piraté?
Quels sont les signes révélateurs qu'un serveur Linux a été piraté? Existe-t-il des outils qui peuvent générer et envoyer par e-mail un rapport d'audit de manière planifiée?
- Conservez quelque part copie vierge des fichiers système critiques (tels que ls, ps, netstat, md5sum), avec une md5sum, et comparez-les régulièrement aux versions live. Les rootkits modifieront invariablement ces fichiers. Utilisez ces copies si vous pensez que les originaux ont été compromis.
- aide ou tripwire vous indiquera tous les fichiers qui ont été modifiés - en supposant que leurs bases de données n'ont pas été falsifiées.
- Configurez syslog pour envoyer vos fichiers journaux à un serveur de journalisation distant où ils ne peuvent pas être falsifiés par un intrus. Surveillez ces fichiers journaux distants pour détecter toute activité suspecte
- lire vos journaux régulièrement - utilisez logwatch ou logcheck pour synthétiser les informations critiques.
- Connaissez vos serveurs. Sachez quels types d'activités et de journaux sont normaux.
Non.
Je sais, je sais - mais c'est la vérité paranoïaque, triste, vraiment;) Il y a beaucoup d'indices bien sûr, mais si le système était ciblé spécifiquement - 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 être fiable pour révéler la vérité.
Certaines choses qui m'ont informé dans le passé:
- Charge élevée sur un système qui devrait être inactif
- Segfaults étranges, par exemple. à partir d'utilitaires standard comme
ls(cela peut arriver avec des kits racine cassés) - Répertoires masqués dans
/ou/var/(la plupart des script kiddies sont trop stupides ou paresseux pour couvrir leurs traces) netstatmontre les ports ouverts qui ne devraient pas être là- Démons dans la liste de processus dont vous utilisez normalement différentes saveurs (par exemple.
bind, mais vous utilisez toujoursdjbdns)
De plus, j'ai trouvé qu'il y a un signe fiable qu'une boîte est compromise: si vous avez une mauvaise impression de la diligence (avec les mises à jour, etc.) de l'administrateur dont vous avez hérité d'un système, gardez un œil attentif!
Tripwire est un outil couramment utilisé - il vous avertit lorsque les fichiers système ont changé, bien que vous deviez évidemment l'installer au préalable. Sinon, les éléments habituels sont des éléments tels que les nouveaux comptes d'utilisateurs que vous ne connaissez pas, les processus et les fichiers étranges que vous ne reconnaissez pas ou l'augmentation de l'utilisation de la bande passante sans raison apparente.
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.
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 terminera normalement. (FWIW, puisque vous passez un signal nop kill, il ne se passera rien 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 cacher les processus affectés dans les tables de processus, etc. processus. Et cela signifie donc que
a) Cette vérification n'est pas une vérification approfondie, car les rootkits bien codés/intelligents garantiront que le noyau répondra avec une réponse "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 ne s'affiche généralement pas sous/proc.
Donc , 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 voir s'il existe des processus en cours d'exécution mais non signalés dans/proc.
Si certains processus apparaissent comme en cours d'exécution, mais ne sont pas signalés dans/proc, vous avez probablement un problème de quelque manière que ce soit.
Voici un script bash qui implémente tout cela - https://Gist.github.com/1032229 . Enregistrez cela dans un fichier et exécutez-le, si vous trouvez un processus qui n'apparaît pas dans proc, vous devriez avoir une piste pour commencer à creuser.
HTH.
J'appuie les réponses données ici et j'ajouterai la mienne.
find /etc /var -mtime -2
Cela vous donnera une indication rapide si l'un de vos fichiers de serveur principal a changé au cours des 2 derniers jours.
Ceci provient 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?
Utilisez un IDS
SNORT® est un système de prévention et de détection d'intrusion de réseau open source utilisant un langage régi par des règles, qui combine les avantages des méthodes d'inspection basées sur la signature, le protocole 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 la norme de facto de l'industrie.
Snort lit le trafic réseau et peut rechercher des choses comme des "tests au stylo" où quelqu'un exécute simplement une analyse métasploit entière sur vos serveurs. Bon à savoir ce genre de choses, à mon avis.
Utilisez les journaux ...
En fonction de votre utilisation, vous pouvez le configurer pour que vous sachiez à chaque fois qu'un utilisateur se connecte, ou se connecte à partir d'une adresse IP étrange, ou chaque fois que root se connecte, ou chaque fois qu'une personne tente de se connecter. En fait, le serveur m'envoie un e-mail chaque message de journal supérieur à Debug. Oui, même remarquez. J'en filtre certains bien sûr, mais chaque matin, quand je reçois 10 e-mails sur des trucs, cela me donne envie de les corriger pour que cela ne se produise plus.
Surveillez votre configuration - je garde en fait tout mon/etc dans Subversion pour pouvoir suivre les révisions.
Exécutez des analyses. Des outils tels que Lynis et Rootkit Hunter peuvent vous avertir d'éventuelles failles de sécurité dans vos applications. Il existe des programmes qui maintiennent un hachage ou un arbre de hachage de tous vos bacs et peuvent vous alerter des changements.
Surveillez votre serveur - Tout comme vous l'avez mentionné dans l'espace disque - les graphiques peuvent vous donner un indice si quelque chose est inhabituel. J'utilise Cacti pour garder un œil sur le CPU, le trafic réseau, l'espace disque, les températures, etc. Si quelque chose semble bizarre est impair et vous devriez découvrir pourquoi il est étrange.
Je voudrais juste ajouter à cela:
Vérifiez votre historique de bash, s'il est vide et que vous ne l'avez pas effacé ou vidé, il y a de bonnes chances que quelqu'un ait compromis votre serveur.
Vérifiez en dernier. Soit vous verrez des IP inconnus, soit ils seront très vides.
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 s'exécutant sur un port aléatoire. C'est souvent caché dans des endroits vraiment étranges. Notez qu'il sera normalement renommé en quelque chose d'autre que ssh. Vérifiez donc netstat (peut ne pas fonctionner car ils le remplacent souvent) et utilisez iptables pour bloquer tous les ports inconnus.
En tout cas, c'est une situation où mieux vaut 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 correctement nettoyé le hack.
Prenez note des points suivants pour éviter que votre serveur ne soit compromis.
- Changer le port ssh
- Empêcher root de pouvoir se connecter
- autoriser uniquement certains utilisateurs
- Empêcher la connexion par mot de passe
- Utilisez des clés ssh, des clés protégées par mot de passe de préférence
- Dans la mesure du possible, mettez sur liste noire toutes les adresses IP et ajoutez à la liste blanche les adresses IP requises.
- Installer et configurer fail2ban
- Utilisez tripwire pour détecter les intrusions
- 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 quelqu'un d'autre joue.
- Si possible, gardez votre serveur sur un vpn et autorisez uniquement ssh via vpn ip. Sécurisez votre VPN.
Il vaut la peine de noter qu'une fois sur un serveur, ils vérifieront votre historique bash et rechercheront les autres serveurs auxquels vous vous êtes connecté via ssh à partir de ce serveur. Ils tenteront alors de se connecter à ces serveurs. Donc, si vous êtes forcé brutalement en raison d'un mauvais mot de passe, il est très possible qu'ils puissent se connecter à l'autre serveur et compromettre ceux-ci aussi.
C'est un monde laid, je répète qu'il vaut mieux prévenir que guérir.
Après avoir cherché un peu, il y a aussi cela, 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é d'une manière visuelle agréable. Il ne nécessite pas d'agent et peut se connecter via SSH, vous n'avez donc pas besoin de regrouper votre machine et vos ressources avec un agent.
Mieux encore, c'est gratuit pour jusqu'à 5 serveurs.
Vérifiez le ici: