Il s'agit d'une question canonique sur la sécurité des serveurs - Réponse aux événements de violation (piratage).
Voir aussi:

• Astuces pour sécuriser un serveur LAMP
• Réinstaller après un compromis de racine?

Version canonique
Je suspecte qu'un ou plusieurs de mes serveurs soient compromis par un pirate informatique, un virus ou un autre mécanisme:

• Quels sont mes premiers pas? Lorsque j'arrive sur le site, dois-je déconnecter le serveur, conserver les "preuves"? Existe-t-il d'autres considérations initiales?
• Comment puis-je obtenir des services en ligne?
• Comment puis-je empêcher la même chose de se produire immédiatement à nouveau?
• Existe-t-il des meilleures pratiques ou méthodologies pour apprendre de cet incident?
• Si je voulais élaborer un plan de réponse aux incidents, par quoi commencerais-je? Est-ce que cela devrait faire partie de mon plan de reprise après sinistre ou de continuité de l'activité?

Version originale

2011.01.02 - Je rentre au travail à 21h30 un dimanche, car notre serveur a été compromis d'une manière ou d'une autre et provoquait une attaque DOS de notre fournisseur. Les serveurs d’accès à Internet ont été fermés, ce qui signifie que plus de 5 600 de nos sites clients sont en panne. Maintenant, cela pourrait être un piratage FTP, ou une faiblesse de code quelque part. Je ne suis pas sûr jusqu'à ce que j'y arrive.

Comment puis-je retrouver ceci rapidement? Nous aurons beaucoup de litiges si je ne fais pas la sauvegarde du serveur dès que possible. Toute aide est appréciée. Nous exécutons Open SUSE 11.0.

---

03.01.2011 - Merci à tous pour votre aide. Heureusement, je n'étais pas le seul responsable de ce serveur, juste le plus proche. Nous avons réussi à résoudre ce problème, même s’il peut ne pas s’appliquer à beaucoup d’autres dans une situation différente. Je vais détailler ce que nous avons fait.

Nous avons débranché le serveur du net. Il effectuait (tentait de mener) une attaque par déni de service sur un autre serveur indonésien, et le coupable y était également basé.

Nous avons tout d’abord essayé d’identifier l’origine du serveur. Étant donné que nous avons plus de 500 sites sur le serveur, nous nous attendions à travailler au noir pendant un certain temps. Cependant, avec un accès SSH toujours, nous avons exécuté une commande pour trouver tous les fichiers modifiés ou créés au moment où les attaques ont commencé. Heureusement, le fichier incriminé a été créé pendant les vacances d'hiver, ce qui signifie que peu d'autres fichiers ont été créés sur le serveur à ce moment-là.

Nous avons ensuite pu identifier le fichier incriminé qui se trouvait dans le dossier des images téléchargées sur un site Web ZenCart .

Après une courte pause-cigarette, nous avons conclu que, en raison de l'emplacement des fichiers, ceux-ci devaient avoir été téléchargés via une installation de téléchargement de fichiers non sécurisée. Après quelques recherches sur Google, nous avons constaté qu’une faille de sécurité autorisait le téléchargement de fichiers, dans le panneau d’administration de ZenCart, pour obtenir une photo d’une maison de disques. (La section qu’il n’a jamais vraiment utilisée), l’affichage de ce formulaire n’a chargé aucun fichier, il n’a pas vérifié son extension et n’a même pas vérifié si l’utilisateur était connecté.

Cela signifiait que tous les fichiers pouvaient être téléchargés, y compris un fichier PHP pour l'attaque. Nous avons sécurisé la vulnérabilité avec ZenCart sur le site infecté et supprimé les fichiers incriminés.

Le travail était terminé et j'étais à la maison pour 2 heures du matin.

---

The Moral - Appliquez toujours des correctifs de sécurité pour ZenCart, ou tout autre système CMS. Comme lors de la publication des mises à jour de sécurité, le monde entier est sensibilisé à cette vulnérabilité. - Faites toujours des sauvegardes et sauvegardez vos sauvegardes. - Employer ou organiser quelqu'un qui sera là dans des moments comme ceux-ci. Pour empêcher quiconque de s'appuyer sur un message panicy sur Server Fault.

Il est difficile de donner des conseils spécifiques à partir de ce que vous avez posté ici, mais j'ai quelques conseils génériques basés sur un post que j'ai écrit il y a longtemps, alors que je pouvais encore avoir la peine de bloguer.

Ne paniquez pas

Tout d’abord, il n’existe pas de «solution miracle» autre que la restauration du système à partir d’une sauvegarde effectuée avant l’intrusion, ce qui pose au moins deux problèmes.

1. Il est difficile de déterminer quand l'intrusion s'est produite.
2. Cela ne vous aide pas à combler le "trou" qui leur a permis d'entrer la dernière fois, ni à gérer les conséquences de tout "vol de données" qui aurait également eu lieu.

Cette question est fréquemment posée par les victimes d'intrusion de pirates sur leur serveur Web. Les réponses changent très rarement, mais les gens continuent à poser la question. Je ne sais pas pourquoi. Peut-être que les gens n'aiment pas les réponses qu'ils ont trouvées en cherchant de l'aide, ou ils ne peuvent pas trouver quelqu'un en qui ils ont confiance pour leur donner des conseils. Ou peut-être que les gens lisent une réponse à cette question et se concentrent trop sur les 5% de raisons pour lesquelles leur cas est spécial et différent des réponses qu'ils peuvent trouver en ligne et manquent les 95% de questions et réponses lorsque leur cas est assez proche de la même chose comme celui qu'ils lisent en ligne.

Cela m'amène à la première pépite d'information importante. J'apprécie vraiment que vous soyez un flocon de neige unique et spécial. J'apprécie que votre site Web soit aussi, car il reflète votre entreprise et à tout le moins votre travail acharné pour le compte d'un employeur. Mais pour quelqu'un de l'extérieur qui regarde, que ce soit un responsable de la sécurité informatique qui essaie de vous aider ou même de l'attaquant lui-même, il est très probable que votre problème soit au moins identique à 95% à tous les autres cas qu'ils ont rencontré. jamais regardé.

Ne prenez pas l'attaque personnellement, et ne prenez pas les recommandations qui suivent ici ou que vous recevez personnellement d'autres personnes. Si vous lisez ceci après être juste devenu la victime d'un piratage de site Web, je suis vraiment désolé, et j'espère vraiment que vous pourrez trouver quelque chose d'utile ici, mais ce n'est pas le temps de laisser votre ego vous empêcher de faire ce que vous voulez. faire.

Vous venez de découvrir que votre serveur a été piraté. Maintenant quoi?

Ne panique pas. Absolument, n'agissez pas dans la précipitation, et n'essayez absolument pas de faire comme si rien ne s'était jamais passé et de ne rien faire du tout.

Premièrement: comprenez que le désastre est déjà arrivé. Ce n'est pas le moment de nier; il est temps d'accepter ce qui s'est passé, d'être réaliste et de prendre des mesures pour gérer les conséquences de l'impact.

Certaines de ces étapes vont faire mal et (à moins que votre site Web ne contienne une copie de mes détails), peu m'importe si vous ignorez tout ou partie de ces étapes, à vous de décider. Mais les suivre correctement améliorera les choses à la fin. Le médicament a peut-être un goût désagréable, mais vous devez parfois le négliger si vous voulez vraiment que le traitement guérisse.

Empêchez le problème de devenir pire qu’il ne l’est déjà:

1. La première chose à faire est de déconnecter les systèmes affectés d’Internet. Quels que soient vos autres problèmes, laisser le système connecté au Web ne permettra que l'attaque se poursuive. Je veux dire cela littéralement; demandez à quelqu'un de se rendre physiquement sur le serveur et de débrancher les câbles réseau si c'est ce qu'il faut, mais déconnectez la victime de ses agresseurs avant d'essayer de faire autre chose.
2. Modifiez tous vos mots de passe pour tous les comptes de tous les ordinateurs connectés au même réseau que les systèmes compromis. Pas vraiment. Tous les comptes. Tous les ordinateurs. Oui, vous avez raison, cela pourrait être exagéré; d'autre part, il se pourrait que non. Vous ne savez pas de toute façon, et vous?
3. Vérifiez vos autres systèmes. Portez une attention particulière aux autres services Internet et à ceux qui détiennent des données financières ou autres données sensibles sur le plan commercial.
4. Si le système contient des données personnelles, informez immédiatement le responsable de la protection des données (si ce n'est pas vous) et DEMANDEZ une divulgation complète. Je sais que celui-ci est difficile. Je sais que celui-ci va faire mal. Je sais que beaucoup d'entreprises veulent régler ce problème sous le tapis, mais elles vont devoir le gérer - et doivent le faire en gardant un œil sur toutes les lois pertinentes en matière de protection de la vie privée.

Même si vos clients sont agacés par le fait que vous leur parliez d'un problème, ils le seront encore plus si vous ne le leur dites pas. volé de votre site.

Rappelez-vous ce que j'ai dit précédemment? La mauvaise chose est déjà arrivée. La seule question qui se pose maintenant est de savoir si vous vous en sortez bien.

Comprenez bien le problème:

1. Ne remettez PAS les systèmes concernés en ligne tant que cette étape n'est pas complètement terminée, à moins que vous ne souhaitiez être la personne dont le message a été le point de basculement pour moi qui ai décidé d'écrire cet article. Je ne ferai pas de lien vers ce message pour que les gens puissent bien rire, mais la vraie tragédie est lorsque les gens ne tirent pas les leçons de leurs erreurs.
2. Examinez les systèmes "attaqués" pour comprendre comment les attaques ont compromis votre sécurité. Efforcez-vous de savoir d'où proviennent les attaques, afin de comprendre les problèmes que vous rencontrez et que vous devez résoudre pour sécuriser votre système à l'avenir.
3. Examinez à nouveau les systèmes "attaqués", cette fois pour comprendre où les attaques ont eu lieu, afin de comprendre quels systèmes ont été compromis lors de l'attaque. Assurez-vous de suivre tous les indicateurs suggérant que les systèmes compromis pourraient devenir un tremplin pour attaquer vos systèmes.
4. Assurez-vous que les «passerelles» utilisées dans toutes les attaques sont bien comprises afin que vous puissiez commencer à les fermer correctement. (Par exemple, si vos systèmes ont été compromis par une attaque par injection SQL, vous devez non seulement fermer la ligne de code défectueuse qu’ils ont interrompue, mais vous souhaitez également vérifier l’ensemble de votre code pour voir s’il s’agit du même type d’erreur. a été faite ailleurs).
5. Comprenez que les attaques peuvent réussir en raison de plusieurs défauts. Souvent, les attaques réussissent non pas en trouvant un bug majeur dans un système, mais en enchaînant plusieurs problèmes (parfois mineurs et triviaux par eux-mêmes) pour compromettre un système. Par exemple, utiliser des attaques par injection SQL pour envoyer des commandes à un serveur de base de données, découvrir que le site Web / l'application que vous attaquez est exécuté dans le contexte d'un utilisateur administratif et utiliser les droits de ce compte comme point de départ pour compromettre d'autres parties de un système. Ou comme les pirates aiment à l'appeler: "un autre jour au bureau en profitant des erreurs courantes commises par les gens".

Pourquoi ne pas simplement "réparer" l'exploit ou le rootkit que vous avez détecté et remettre le système en ligne?

Dans de telles situations, le problème est que vous n’avez plus le contrôle de ce système. Ce n'est plus votre ordinateur.

La seule façon d'être certain que vous avez le contrôle du système est de reconstruire le système. Bien qu'il soit très utile de trouver et de réparer l'exploit utilisé pour pénétrer dans le système, vous ne pouvez pas être sûr de ce qui a été fait d'autre au système une fois que les intrus ont pris le contrôle (en fait, ce n'est pas inédit pour les pirates qui recrutent systèmes dans un botnet pour patcher les exploits qu’ils ont eux-mêmes utilisés, pour protéger "leur" nouvel ordinateur des autres pirates, ainsi que pour l’installation de leur rootkit).

Élaborez un plan de reprise pour remettre votre site Web en ligne et respectez-le:

Personne ne veut être déconnecté plus longtemps que nécessaire. C'est une donnée. Si ce site Web génère des revenus, la pression pour le remettre en ligne rapidement sera intense. Même si la réputation de votre entreprise est la seule en jeu, cela va encore générer beaucoup de pression pour que les choses reprennent rapidement.

Cependant, ne cédez pas à la tentation de revenir en ligne trop rapidement. Déplacez-vous plutôt vite que possible pour comprendre la cause du problème et le résoudre avant de vous reconnecter, sinon vous risquez à nouveau d'être victime d'une intrusion et rappelez-vous, "se faire pirater une fois peut être qualifié de malheur; se faire pirater de nouveau tout de suite après ressemble à de la négligence "(avec nos excuses à Oscar Wilde).

1. Je suppose que vous avez compris tous les problèmes qui ont conduit à l'intrusion réussie avant même de commencer cette section. Je ne veux pas exagérer le cas, mais si vous ne l'avez pas déjà fait, vous devez le faire. Pardon.
2. Ne payez jamais de chantage / protection. C'est le signe d'une marque facile et vous ne voulez pas que cette phrase soit jamais utilisée pour vous décrire.
3. Ne soyez pas tenté de remettre le même serveur en ligne sans une reconstruction complète. Il devrait être beaucoup plus rapide de créer un nouveau boîtier ou de "réorganiser le serveur en orbite et de procéder à une nouvelle installation" sur l'ancien matériel, plutôt que de procéder à l'audit de chaque coin de l'ancien système pour s'assurer qu'il est propre avant de le remettre en place. en ligne à nouveau. Si vous n’êtes pas d’accord avec cela, vous ne savez probablement pas ce que cela signifie vraiment de s’assurer que le système est entièrement nettoyé ou que les procédures de déploiement de votre site Web sont un foutoir désastreux. Vous avez probablement des sauvegardes et des déploiements de test de votre site que vous pouvez simplement utiliser pour construire le site en direct, et si vous ne le faites pas, alors votre piratage informatique n'est pas votre plus gros problème.
4. Soyez très prudent lors de la réutilisation de données "en direct" sur le système au moment du piratage. Je ne dirai pas "ne le fais jamais" parce que vous allez simplement m'ignorer, mais franchement, je pense que vous devez envisager les conséquences de la conservation des données lorsque vous savez que vous ne pouvez pas garantir leur intégrité. Idéalement, vous devriez restaurer ceci à partir d'une sauvegarde effectuée avant l'intrusion. Si vous ne pouvez pas ou ne voulez pas faire cela, vous devez être très prudent avec ces données car elles sont corrompues. Vous devez en particulier être conscient des conséquences pour les autres si ces données appartiennent à des clients ou à des visiteurs du site plutôt que directement à vous.
5. Surveillez le (s) système (s) avec soin. Vous devez être résolu à le faire en tant que processus continu à l'avenir (voir ci-dessous), mais vous prenez des efforts supplémentaires pour être vigilant pendant la période qui suit immédiatement la remise en ligne de votre site. Les intrus seront certainement de retour, et si vous pouvez les repérer en essayant de vous replonger, vous serez certainement en mesure de voir rapidement si vous avez réellement fermé tous les trous qu’ils utilisaient auparavant et tous ceux qu’ils ont faits pour eux-mêmes, informations que vous pouvez transmettre à vos forces de l'ordre locales.

Réduire les risques à l'avenir.

La première chose que vous devez comprendre, c'est que la sécurité est un processus que vous devez appliquer tout au long du cycle de vie de la conception, du déploiement et de la maintenance d'un système orienté Internet. Vous ne pouvez pas, par la suite, appliquer plusieurs couches sur votre code comme bon marché. peindre. Pour être correctement sécurisés, un service et une application doivent être conçus dès le départ, avec cet objectif à l'esprit, comme l'un des objectifs majeurs du projet. Je réalise que c'est ennuyeux et que vous avez déjà entendu tout cela avant et que je "ne réalise tout simplement pas la pression" pour que votre service bêta web2.0 (bêta) devienne bêta sur le Web, mais le fait est que cela continue se répéter parce que c'était vrai la première fois que cela a été dit et que ce n'est pas encore devenu un mensonge.

Vous ne pouvez pas éliminer les risques. Vous ne devriez même pas essayer de faire ça. Cependant, vous devez savoir quels risques de sécurité vous importent et comment gérer et réduire l'impact du risque et la probabilité qu'il se produise.

Quelles mesures pouvez-vous prendre pour réduire la probabilité qu'une attaque réussisse?

Par exemple:

1. La faille qui permettait aux personnes de pénétrer sur votre site était-elle un bogue connu dans le code du fournisseur, pour lequel un correctif était disponible? Si tel est le cas, avez-vous besoin de repenser votre approche en ce qui concerne la correction des applications sur vos serveurs Internet?
2. La faille qui permettait aux personnes de pénétrer sur votre site était-elle un bogue inconnu dans le code du fournisseur, pour lequel aucun correctif n'était disponible? Je ne préconise certainement pas de changer de fournisseur chaque fois que quelque chose de ce genre vous dérange, car ils ont tous des problèmes et vous manquerez de plates-formes dans un an au maximum si vous adoptez cette approche. Toutefois, si un système vous laisse constamment tomber, vous devez migrer vers quelque chose de plus robuste ou au moins restructurer votre système pour que les composants vulnérables restent enveloppés dans du coton et le plus loin possible des yeux hostiles.
3. La faille était-elle un bug du code développé par vous (ou par un contractant travaillant pour vous)? Si tel est le cas, devez-vous repenser votre approche pour approuver le code à déployer sur votre site actif? Le bogue aurait-il été détecté avec un système de test amélioré ou avec des modifications de votre "norme" de codage (par exemple, bien que la technologie ne soit pas une panacée, vous pouvez réduire le risque de succès d'une attaque par injection SQL en utilisant des techniques de codage bien documentées ).
4. La faille était-elle due à un problème de déploiement du serveur ou du logiciel d'application? Si oui, utilisez-vous des procédures automatisées pour créer et déployer des serveurs dans la mesure du possible? Ils sont d'une grande aide pour maintenir un état de "base" cohérent sur tous vos serveurs, en minimisant la quantité de travail personnalisé à effectuer sur chacun d'eux et, partant, en espérant minimiser les risques d'erreur. Il en va de même pour le déploiement de code: si vous souhaitez effectuer une opération "spéciale" pour déployer la dernière version de votre application Web, essayez de l'automatiser et assurez-vous que l'opération est toujours effectuée de manière cohérente.
5. L'intrusion aurait-elle pu être détectée plus tôt avec une meilleure surveillance de vos systèmes? Bien entendu, une surveillance 24 heures sur 24 ou un système "sur appel" pour votre personnel peut ne pas être rentable, mais certaines entreprises peuvent surveiller votre service Web et vous avertir en cas de problème. Vous pouvez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... prenez-le en considération.
6. Utilisez des outils tels que tripwire et nessus, le cas échéant - mais ne les utilisez pas simplement à l'aveuglette car je l'ai dit. Prenez le temps d'apprendre à utiliser quelques outils de sécurité adaptés à votre environnement, mettez-les à jour et utilisez-les régulièrement.
7. Envisagez de faire appel à des experts en sécurité pour «auditer» régulièrement la sécurité de votre site Web. Encore une fois, vous pouvez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... prenez-le en considération.

Quelles mesures pouvez-vous prendre pour réduire les conséquences d'une attaque réussie?

Si vous décidez que le "risque" d’inondation au rez-de-chaussée de votre maison est élevé, mais pas assez élevé pour justifier un déménagement, vous devriez au moins déplacer les héritages irremplaçables de la famille à l’étage supérieur. Droite?

1. Pouvez-vous réduire la quantité de services directement exposés à Internet? Pouvez-vous maintenir une sorte de décalage entre vos services internes et vos services Internet? Cela garantit que même si vos systèmes externes sont compromis, les chances de l'utiliser comme un tremplin pour attaquer vos systèmes internes sont limitées.
2. Stockez-vous des informations que vous n'avez pas besoin de stocker? Stockez-vous ces informations "en ligne" quand elles pourraient être archivées ailleurs? Il y a deux points à cette partie; la plus évidente est que les gens ne peuvent pas vous voler des informations que vous n'avez pas, et le deuxième point est que moins vous stockez, moins vous avez besoin de maintenir et de coder, et il y a donc moins de chances que des bugs se glissent votre code ou conception de systèmes.
3. Utilisez-vous les principes du "moindre accès" pour votre application Web? Si les utilisateurs n'ont besoin que de lire à partir d'une base de données, assurez-vous que le compte utilisé par l'application Web pour la gérer dispose uniquement d'un accès en lecture, n'autorisez pas l'accès en écriture et certainement pas au niveau du système.
4. Si vous n’êtes pas très expérimenté et qu’il n’est pas essentiel pour votre entreprise, envisagez de l’externaliser. En d'autres termes, si vous exploitez un petit site Web qui parle d'écrire du code d'application de bureau et décidez de commencer à vendre de petites applications de bureau à partir du site, envisagez de "sous-traiter" votre système de commande par carte de crédit à une entreprise telle que Paypal.
5. Dans la mesure du possible, intégrez dans votre plan de reprise après sinistre la restauration des systèmes compromis. Ceci est sans doute un autre "scénario catastrophe" que vous pourriez rencontrer, simplement un avec ses propres problèmes et problèmes distincts de l'habituel "salle des serveurs pris feu" / a été envahi par le genre de chose que les serveurs géants mangent.

... Et enfin

J'ai probablement laissé de nombreuses choses que d'autres considèrent comme importantes, mais les étapes ci-dessus devraient au moins vous aider à résoudre les problèmes si vous êtes assez malchanceux pour être victime de pirates informatiques.

Surtout: ne paniquez pas. Pense avant d'agir. Agissez fermement une fois que vous avez pris une décision et laissez un commentaire ci-dessous si vous avez quelque chose à ajouter à ma liste d'étapes.

On dirait qu'ils sont légèrement au-dessus de votre tête; c'est bon. Appelez votre patron et commencez à négocier un budget de réponse d'urgence à la sécurité. 10 000 $ pourrait être un bon endroit pour commencer. Ensuite, vous devez faire appel à une personne (un PFY, un collègue, un responsable) pour pouvoir appeler des entreprises spécialisées dans la réponse aux incidents de sécurité. Beaucoup peuvent répondre dans les 24 heures, et parfois même plus rapidement s’ils ont un bureau dans votre ville.

Vous avez également besoin de quelqu'un pour trier les clients; Sans doute, quelqu'un l'est déjà. Quelqu'un doit être au téléphone avec eux pour leur expliquer ce qui se passe, ce qui est fait pour gérer la situation et pour répondre à leurs questions.

Ensuite, vous devez ...

1. Reste calme. Si vous êtes responsable de la réponse aux incidents, ce que vous faites maintenant doit faire preuve d'un professionnalisme et d'un leadership sans faille. Documentez tout ce que vous faites et informez votre responsable et votre équipe de direction des principales actions que vous prenez. cela comprend le travail avec une équipe de réponse, la désactivation des serveurs, la sauvegarde des données et la remise en ligne de certains éléments. Ils n'ont pas besoin de détails sanglants, mais ils devraient vous entendre toutes les 30 minutes environ.

2. Être réaliste. Vous n'êtes pas un professionnel de la sécurité et vous ne savez pas certaines choses. C'est bon. Lorsque vous vous connectez à des serveurs et consultez des données, vous devez comprendre vos limites. Marchez doucement. Au cours de votre enquête, veillez à ne pas piétiner des informations vitales ou à modifier quelque chose qui pourrait être nécessaire ultérieurement. Si vous vous sentez mal à l'aise ou si vous devinez, c'est un bon endroit pour faire une pause et demander à un professionnel expérimenté de prendre la relève.

3. Obtenez une clé USB propre et des disques durs disponibles. Vous allez collecter des preuves ici. Faites des sauvegardes de tout ce que vous jugez pertinent. communication avec votre FAI, vidage réseau, etc. Même si les forces de l'ordre n'interviennent pas, vous voudrez, en cas de procès, que ces preuves prouvent que votre entreprise a traité l'incident de sécurité de manière professionnelle et appropriée.

4. Le plus important est d'arrêter la perte. Identifiez et supprimez l'accès aux services, données et machines compromis. De préférence, vous devez tirer leur câble de réseau; si vous ne pouvez pas, alors tirez le pouvoir.

5. Ensuite, vous devez supprimer l'attaquant et fermer le (s) trou (s). Vraisemblablement, l'attaquant n'a plus d'accès interactif parce que vous avez utilisé le réseau. Vous devez maintenant identifier, documenter (avec des sauvegardes, des captures d'écran et vos notes d'observation personnelles; ou de préférence en retirant les disques des serveurs affectés et en créant une copie complète de l'image disque), puis supprimez le code et les processus qu'il a laissés. . Cette prochaine partie sera nulle si vous n'avez pas de sauvegardes; Vous pouvez essayer de dégager l’attaquant du système à la main, mais vous ne serez jamais sûr d’avoir tout ce qu’il a laissé. Les rootkits sont vicieux, et tous ne sont pas détectables. La meilleure solution consiste à identifier la vulnérabilité qu’il a utilisée pour entrer, à créer des copies d’image des disques affectés, puis à effacer les systèmes affectés et à recharger à partir d’une sauvegarde en bon état. Don' t aveuglément confiance à votre sauvegarde; vérifiez-le! Réparez ou fermez la vulnérabilité avant que le nouvel hôte ne se reconnecte sur le réseau, puis mettez-la en ligne.

6. Organisez toutes vos données dans un rapport. À ce stade, la vulnérabilité est fermée et vous avez du temps à respirer. Ne soyez pas tenté de sauter cette étape. c'est encore plus important que le reste du processus. Dans le rapport, vous devez identifier ce qui ne va pas, la réaction de votre équipe et les mesures que vous prenez pour éviter que cet incident ne se reproduise. Soyez aussi précis que possible. ce n'est pas juste pour vous, mais pour votre gestion et comme défense dans un procès potentiel.

C'est une révision sans précédent de ce qu'il faut faire; l'essentiel du travail consiste simplement en de la documentation et du traitement de sauvegarde. Ne paniquez pas, vous pouvez faire ce genre de choses. Je vous recommande fortement de faire appel à une aide professionnelle en matière de sécurité. Même si vous pouvez gérer ce qui se passe, leur aide sera précieuse et ils viennent généralement avec du matériel pour rendre le processus plus facile et plus rapide. Si votre patron résiste au coût, rappelez-lui que c'est très petit comparé au traitement d'un procès.

Vous avez mes consolations pour votre situation. Bonne chance.

CERT contient un document Étapes pour la récupération d'un compromis système UNIX ou NT qui est bon. Les détails techniques spécifiques de ce document sont quelque peu dépassés, mais de nombreux conseils généraux s'appliquent toujours directement.

Voici un résumé rapide des étapes de base.

• Consultez votre politique de sécurité ou de gestion.
• Prenez le contrôle (mettez l'ordinateur hors ligne)
• Analyser l'intrusion, obtenir des journaux, comprendre ce qui a mal tourné
• Trucs de réparation
  • Installez une version propre de votre système d'exploitation !!! Si le système a été compromis, vous ne pouvez pas lui faire confiance, point à la ligne.
• Mettre à jour les systèmes pour que cela ne se reproduise plus
• Reprendre les opérations
• Mettre à jour votre politique pour l'avenir et documenter

Je voudrais vous indiquer spécifiquement la section E.1.

E.1. Gardez à l'esprit que si une machine est compromise, tout ce qui se trouve sur ce système pourrait avoir été modifié, notamment le noyau, les fichiers binaires, les fichiers de données, les processus en cours et la mémoire. En général, le seul moyen de s’assurer qu’une machine est exempte de portes dérobées et de modifications d’intrus consiste à réinstaller le système d’exploitation.

Si vous n'avez pas déjà installé de système tel que tripwire, vous ne pouvez absolument pas être sûr à 100% que vous avez nettoyé le système.

1. Identifiez le problème. Lire les journaux.
2. Contenir . Vous avez déconnecté le serveur, c'est donc fait.
3. Éradiquer . Réinstallez le système affecté, le plus probablement. N'effacez pas le disque dur du disque piraté, utilisez-en un nouveau. C'est plus sûr, et vous aurez peut-être besoin de l'ancien pour récupérer les horribles hacks qui n'ont pas été sauvegardés et pour faire de la médecine légale afin de découvrir ce qui s'est passé.
4. Récupérer . Installez ce dont vous avez besoin et récupérez des sauvegardes pour mettre vos clients en ligne.
5. Suivi . Déterminez quel était le problème et évitez qu'il ne se reproduise.

La réponse de Robert à la "pilule amère" est précise mais parfaitement générique (comme ce fut votre question). On dirait que vous avez un problème de gestion et que vous avez un besoin urgent d’un administrateur système à temps plein si vous avez un serveur et 600 clients, mais cela ne vous aide pas pour le moment.

Je dirige une société d’hébergement qui fournit un peu de prise en main dans cette situation. Je traite donc avec beaucoup de machines compromises, mais je gère également les meilleures pratiques pour nous-mêmes. Nous disons toujours à nos clients compromis de reconstruire à moins qu'ils ne soient pas absolument sûrs de la nature d'un compromis. Il n'y a pas d'autre voie responsable à long terme.

Cependant, vous êtes presque certainement la victime d'un script kiddy qui souhaitait une rampe de lancement pour les attaques par déni de service, ou des videurs IRC, ou quelque chose de complètement indépendant des sites et des données de vos clients. Par conséquent, à titre de mesure temporaire pendant la reconstruction, vous pouvez envisager de mettre en place un pare-feu sortant lourd sur votre boîte. Si vous pouvez bloquer toutes les connexions UDP et TCP sortantes qui ne sont pas absolument nécessaires au fonctionnement de vos sites, vous pouvez facilement rendre inutile votre boîte compromise à celui qui vous l'emprunte, et atténuer à zéro l'effet sur le réseau de votre fournisseur.

Ce processus peut prendre quelques heures si vous ne l'avez pas déjà fait et si vous n'avez jamais envisagé de pare-feu, mais pourrait vous aider à restaurer le service de vos clients au risque de continuer à donner à l'attaquant l'accès aux données de vos clients . Puisque vous dites que vous avez des centaines de clients sur une seule machine, j'imagine que vous hébergez des sites Web de petites brochures pour les petites entreprises et non 600 systèmes de commerce électronique remplis de numéros de cartes de crédit. Si tel est le cas, cela peut constituer un risque acceptable pour vous et remettez votre système en ligne plus rapidement que l'audit de 600 sites pour rechercher des bogues de sécurité avant de rapporter quoi que ce soit. Mais vous saurez quelles données sont là et dans quelle mesure vous prendrez cette décision avec facilité.

Ce n’est absolument pas une bonne pratique, mais si ce n’est pas ce qui se passe chez votre employeur jusqu’à présent, agitez-le du doigt et demandez des dizaines de milliers de livres à une équipe SWAT pour quelque chose qu’elle pourrait penser de votre faute (même si elle est injustifiée!). ) ne ressemble pas à l'option pratique.

L’aide de votre fournisseur de services Internet sera cruciale - certains fournisseurs de services Internet fournissent un serveur de console et un environnement d’amorçage réseau (plug, mais au moins, vous savez quel type d’installations rechercher) qui vous permettront d’administrer le serveur sans vous connecter au réseau. S'il s'agit d'une option, demandez-la et utilisez-la.

Mais à long terme, vous devriez prévoir une reconstruction du système basée sur le poste de Robert et un audit de chaque site et de sa configuration. Si vous ne parvenez pas à ajouter un administrateur système à votre équipe, recherchez un contrat d’ hébergement géré dans lequel vous payez votre fournisseur de services Internet pour obtenir de l’aide et une réponse 24 heures sur 24 pour ce genre de choses. Bonne chance :)

Vous devez ré-installer. Enregistrez ce dont vous avez vraiment besoin. Mais gardez à l'esprit que tous vos fichiers exécutables peuvent être infectés et altérés. J'ai écrit ce qui suit en python: http://frw.se/monty.py qui crée MD5-sumbs de tous vos fichiers dans un répertoire donné et la prochaine fois que vous l'exécutez, il vérifie si quelque chose a été changé, puis affiche ce les fichiers ont changé et ce qui a changé dans les fichiers.

Cela pourrait être pratique pour vous, pour voir si les fichiers étranges sont changés régulièrement.

Mais la seule chose que vous devriez faire maintenant, est de supprimer votre ordinateur d’Internet.

REMARQUE: ceci n'est pas une recommandation. Mon protocole spécifique de réponse aux incidents n'appliquerait probablement pas non modifié au cas Grant unwin.

Dans nos établissements universitaires, environ 300 chercheurs ne font que des calculs. Vous avez 600 clients avec des sites Web, votre protocole sera probablement différent.

Les premières étapes de notre protocole Lorsqu'un serveur est compromis, sont les suivantes:

1. Identifier que l'attaquant a pu obtenir un compte root (privilèges élevés)
2. Débranchez le ou les serveurs affectés. Réseau ou pouvoir? S'il vous plaît voir une discussion séparée .
3. Vérifier tous les autres systèmes
4. Démarrer le (s) serveur (s) concerné (s) à partir d’un cd en direct
5. (facultatif) Saisissez les images de tous les lecteurs du système avecdd

6. Commencez à faire la criminalistique post-mortem. Consultez les journaux, déterminez l'heure de l'attaque, recherchez les fichiers modifiés à cette heure. Essayez de répondre au comment? question.

   • En parallèle, planifiez et exécutez votre récupération.
   • Réinitialiser tous les mots de passe root et utilisateur avant de reprendre le service

Même si "toutes les portes dérobées et les rootkits sont nettoyés", ne faites pas confiance à ce système, réinstallez-le à partir de zéro.

Dans mon expérience limitée, les compromis système sur Linux ont tendance à être plus «complets» que sous Windows. Les rootkits sont beaucoup plus susceptibles d’inclure le remplacement des fichiers binaires du système par un code personnalisé pour masquer les programmes malveillants, et la barrière contre les correctifs à chaud du noyau est un peu plus basse. De plus, c'est le système d'exploitation domestique de nombreux auteurs de programmes malveillants. La recommandation générale est toujours de reconstruire le serveur affecté à partir de zéro, et c'est la recommandation générale pour une raison.

Formatez ce chiot.

Mais, si vous ne pouvez pas reconstruire (ou les-pouvoirs-qui-seront ne vous laisseront pas reconstruire malgré votre ferme insistance qu'il en a besoin), que cherchez-vous?

Comme il semble que cela fait longtemps que l’intrusion a été découverte et qu’une restauration du système a été effectuée, il est très probable que les traces de leur entrée ont été écrasées dans la débandade pour rétablir le service. Malheureux.

Le trafic réseau inhabituel est probablement le plus facile à trouver, car cela n'implique rien d'exécuter sur la boîte et peut être effectué pendant que le serveur est en marche et quoi que ce soit. En supposant, bien sûr, que votre équipement de réseau permette d’étendre les ports. Ce que vous trouvez peut ou peut ne pas être diagnostique, mais au moins c'est de l'information. L'obtention d'un trafic inhabituel constituera une preuve solide que le système est toujours compromis et doit être aplati. Il serait peut-être suffisant de convaincre TPTB qu’un reformatage vaut vraiment la peine d’être arrêté.

À défaut, prenez une copie dd de vos partitions système et montez-les sur une autre boîte. Commencez à comparer le contenu avec un serveur du même niveau de correctif que celui compromis. Cela devrait vous aider à identifier ce qui est différent (ces sommes encore une fois md5) et peut indiquer des zones ignorées sur le serveur compromis. C’est BEAUCOUP de passer au crible les répertoires et les fichiers binaires, et cela demandera beaucoup de travail. Cela peut même nécessiter plus de main-d’œuvre qu’un reformat / reconstruction, et peut-être une autre chose que de dire à TPTB de réellement effectuer le reformat dont il a réellement besoin.

Je dirais @Robert Moir, @Aleksandr Levchuk, @blueben et @Matthew Bloch sont tous très bien placés dans leurs réponses.

Cependant, les réponses des différentes affiches diffèrent - certaines sont plus générales et parlent des procédures à mettre en place (en général).

Je préférerais séparer ceci en plusieurs parties distinctes 1) Triage, AKA Comment traiter avec les clients et les implications juridiques, et identifier où aller à partir de là (très bien énuméré par Robert et @blueben 2) Atténuation de l'impact 3 ) Réponse à l’incident 4) Analyse judiciaire post mortem 5) Éléments de correction et modifications de l’architecture

(Insérer ici la déclaration de réponse certifiée SANS GSC.) D'après les expériences passées, je dirais ce qui suit:

Quelle que soit la manière dont vous gérez les réponses des clients, les notifications, les plans juridiques et les projets futurs, je préférerais me concentrer sur le problème principal. La question initiale du PO ne concerne en réalité que les points 2 et 3, essentiellement, comment arrêter l'attaque et remettre les clients en ligne dès que possible dans leur état d'origine, ce qui a été bien décrit dans les réponses.

Le reste des réponses est excellent et couvre un grand nombre de meilleures pratiques identifiées, ainsi que des moyens d'éviter que cela se produise à l'avenir et de mieux y répondre.

Cela dépend vraiment du budget du PO, du secteur d'activité dans lequel il se trouve, de la solution souhaitée, etc.

Peut-être ont-ils besoin d'embaucher une SA sur place. Peut-être ont-ils besoin d'une personne de sécurité. Ou peut-être ont-ils besoin d'une solution entièrement gérée, telle que Firehost ou Rackspace Managed, Softlayer, ServePath, etc.

Cela dépend vraiment de ce qui fonctionne pour leur entreprise. Peut-être que leur compétence principale n’est pas la gestion de serveurs et que cela n’a aucun sens de les développer. Ou peut-être sont-ils déjà une jolie organisation technique, capables de prendre les bonnes décisions en matière d’embauche et de mettre en place une équipe dédiée à plein temps.

Une fois au travail et en regardant le serveur, nous avons réussi à comprendre le problème. Heureusement, les fichiers incriminés ont été téléchargés sur le système un dimanche, lorsque le bureau est fermé, et aucun fichier ne doit être créé, à l'exception des journaux et des fichiers en cache. Avec une simple commande shell pour savoir quels fichiers ont été créés ce jour-là, nous les avons trouvés.

Tous les fichiers incriminés semblent se trouver dans le dossier / images / de certains de nos anciens sites zencart. Il semble qu'une faille de sécurité ait permis (à l'aide de curl) à tout idiot de télécharger des non-images dans la section de téléchargement d'images de la section admin. Nous avons supprimé les fichiers .php incriminés et corrigé les scripts de téléchargement afin d'empêcher tout téléchargement de fichier non-image.

Rétrospectivement, c’était assez simple et j’ai posé cette question sur mon iPhone en allant au travail. Merci pour toute votre aide les gars.

Pour la référence de toute personne visitant ce post à l'avenir. Je ne recommanderais pas de débrancher le cordon d'alimentation.

J'ai peu de choses à apporter aux nombreuses réponses techniques, mais veuillez en noter quelques-unes:

Actions non techniques:

• Signaler l'incident en interne.
  Si vous ne possédez pas déjà de plan de réponse aux incidents qui peut sembler être une technique CYA, le service informatique n'est pas le seul et souvent même le meilleur endroit pour déterminer l' impact commercial d'un serveur compromis.
  Les exigences commerciales peuvent l'emporter sur vos préoccupations techniques. Ne dites pas "je vous l'avais bien dit" et que la priorité des entreprises est la raison pour laquelle vous avez ce serveur compromis en premier lieu. (" Laissez cela pour le compte rendu après action. ")

• Cacher un incident de sécurité n'est pas une option.

• Rapport aux autorités locales.
  ServerFault n'est PAS l'endroit pour obtenir des conseils juridiques, mais c'est quelque chose qui devrait être inclus dans un plan de réponse aux incidents.
  Dans certaines localités et / ou industries réglementées, il est obligatoire de signaler (certains) incidents de sécurité aux forces de l'ordre locales, aux organismes de réglementation ou d'informer les clients / utilisateurs concernés.
  Quoi qu'il en soit, ni la décision de rapporter ni le rapport réel ne sont pris uniquement par le service informatique. Attendez-vous à une implication de la direction et des services juridiques et de communication d'entreprise (marketing).
  Vous ne devriez probablement pas vous attendre à trop, Internet est un grand endroit où les frontières ont peu de signification, mais les départements de cybercriminalité qui existent dans de nombreux départements de police résolvent les crimes numériques et peuvent traduire les coupables en justice.

Je pense que tout se résume à ceci:

Si vous appréciez votre travail, vous feriez mieux d'avoir un plan et de le réviser régulièrement.

L'absence de planification, c'est la planification d'échec, et ce n'est pas plus vrai que dans la sécurité des systèmes. Lorsque <expurgé> frappe le fan, vous feriez mieux de vous préparer.

Il y a un autre dicton (quelque peu cliché) qui s'applique ici: mieux vaut prévenir que guérir .

Un certain nombre de recommandations ont été formulées pour que des experts vérifient vos systèmes existants. Je pense que cela pose la question au mauvais moment. Cette question aurait dû être posée lors de la mise en place du système et la consignation des réponses. En outre, la question ne devrait pas être "Comment pouvons-nous empêcher les gens d'entrer par effraction?" Cela devrait être "Pourquoi les gens devraient-ils pouvoir entrer du tout?" L'audit de plusieurs trous de votre réseau ne fonctionnera que jusqu'à ce que de nouveaux trous soient trouvés et exploités. D'autre part, les réseaux conçus depuis le sol pour ne répondre que de certaines manières à certains systèmes dans une danse soigneusement chorégraphiée ne bénéficieront d'aucun audit et les fonds seront un gaspillage.

Avant de mettre un système sur Internet, demandez-vous - est-ce que cela doit être 100% Internet? Sinon, ne le faites pas. Pensez à le placer derrière un pare-feu où vous pouvez décider de ce que voit Internet. Mieux encore, si ce pare-feu vous permet d'intercepter les transmissions (via un proxy inverse ou un filtre de transfert), envisagez de l'utiliser pour ne permettre que des actions légitimes.

Cela a été fait - il existe (ou existait) une configuration bancaire sur Internet qui dispose d’un proxy d’équilibrage de charge face à Internet, qu’ils allaient utiliser pour éloigner les attaques de leur pool de serveurs de leurs attaques. L'expert en sécurité, Marcus Ranum, les a convaincus d'adopter l'approche inverse en utilisant le proxy inverse pour n'autoriser que les URL valides connues et envoyer tout le reste à un serveur 404 . Il a étonnamment bien résisté à l'épreuve du temps.

Un système ou un réseau basé sur une autorisation par défaut est voué à l'échec lorsqu'une attaque que vous n'aviez pas prévue se produit. Le refus par défaut vous donne un contrôle bien plus important sur ce qui entre et ce qui ne rentre pas, car vous ne laisserez rien voir de l'intérieur à l'extérieur, à moins que ce ne soit vraiment nécessaire .

Cela dit, tout cela n’est pas une raison pour faire preuve de complaisance. Vous devriez toujours avoir un plan en place pour les premières heures après une violation. Aucun système n'est parfait et les humains font des erreurs.

Un bon onliner m'a récemment aidé à comprendre comment un attaquant pourrait compromettre un système. Certains pirates tentent de cacher leurs traces en fixant l’heure de modification des fichiers. En modifiant l'heure de modification, l'heure de changement est mise à jour (ctime). vous pouvez voir le temps avec stat.

Ce liner répertorie tous les fichiers triés par ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Donc, si vous connaissez à peu près l'heure du compromis, vous pouvez voir quels fichiers sont modifiés ou créés.