Skip to content

Comment faire face à un serveur compromis ?

Nous effectuons une vérification approfondie de chaque écrit dans notre espace dans le but de toujours vous montrer des informations vraies et à jour.

Solution :

Solution 1 :

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 des lustres à l'époque où je pouvais encore être dérangé pour bloguer.

Ne paniquez pas

Tout d'abord, il n'y a pas de "solutions rapides" autres que de restaurer votre système à partir d'une sauvegarde prise avant l'intrusion, et cela pose au moins deux problèmes.

  1. Il est difficile de déterminer avec précision le moment où l'intrusion s'est produite.
  2. Cela ne vous aide pas à fermer le "trou" qui leur a permis de s'introduire la dernière fois, ni à gérer les conséquences d'un éventuel "vol de données" qui aurait également eu lieu.

Cette question ne cesse d'être posée par les victimes de pirates s'introduisant dans leur serveur web. Les réponses changent très rarement, mais les gens continuent à poser la question. Je ne sais pas trop pourquoi. Peut-être que les gens n'aiment tout simplement pas les réponses qu'ils ont vues en cherchant de l'aide, ou qu'ils ne trouvent pas quelqu'un de 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 la raison pour laquelle leur cas est spécial et différent des réponses qu'ils peuvent trouver en ligne et manquent les 95% de la question et de la réponse où leur cas est presque identique à celui qu'ils ont lu 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 le soit aussi, car il est le reflet de vous-même et de votre entreprise ou, à tout le moins, de votre travail acharné pour le compte d'un employeur. Mais pour quelqu'un qui regarde de l'extérieur, qu'il s'agisse d'une personne chargée de la sécurité informatique qui examine le problème pour essayer de vous aider ou même de l'attaquant lui-même, il est très probable que votre problème sera identique à au moins 95 % à tous les autres cas qu'ils ont déjà examinés.

Ne prenez pas l'attaque personnellement, et ne prenez pas les recommandations qui suivent ici ou que vous recevez d'autres personnes personnellement. Si vous lisez ceci après avoir juste été victime d'un piratage de site web, alors 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 moment de laisser votre ego se mettre en travers de ce que vous devez faire.

Vous venez de découvrir que votre ou vos serveurs ont été piratés. Que faire maintenant ?

Ne paniquez pas. N'agissez absolument pas dans la précipitation, et n'essayez absolument pas de faire comme si les choses n'étaient jamais arrivées et de ne pas agir du tout.

Premièrement : comprenez que la catastrophe a déjà eu lieu. Ce n'est pas le moment du déni ; c'est le moment d'accepter ce qui s'est passé, d'être réaliste à ce sujet 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 détienne une copie de mes coordonnées) je ne me soucie vraiment pas que vous ignoriez tout ou partie de ces étapes, c'est votre choix. Mais si vous les suivez correctement, les choses iront mieux au bout du compte. Le médicament peut avoir un goût affreux, mais il faut parfois passer outre si l'on veut vraiment que le remède fonctionne.

Empêchez le problème de devenir plus grave 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 les autres problèmes que vous avez, laisser le système connecté au web ne fera que permettre à l'attaque de continuer. Je veux dire cela très littéralement ; demandez à quelqu'un de visiter physiquement 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. Changez tous vos mots de passe pour tous les comptes de tous les ordinateurs qui se trouvent sur le même réseau que les systèmes compromis. Non vraiment. Tous les comptes. Tous les ordinateurs. Oui, vous avez raison, cela pourrait être exagéré ; d'un autre côté, cela pourrait ne pas l'être. Vous ne savez pas de toute façon, n'est-ce pas ?
  3. Vérifiez vos autres systèmes. Portez une attention particulière aux autres services tournés vers Internet, et à ceux qui détiennent des données financières ou d'autres données commercialement sensibles.
  4. Si le système détient les données personnelles de quelqu'un, informez immédiatement la personne responsable de la protection des données (si ce n'est pas vous) et EXIGEZ une divulgation complète. Je sais que celle-ci est difficile. Je sais que cela va faire mal. Je sais que de nombreuses entreprises veulent balayer ce genre de problème sous le tapis, mais l'entreprise va devoir s'en occuper - et doit le faire en tenant compte de toutes les lois pertinentes sur la protection de la vie privée.

Aussi ennuyés que vos clients puissent être de vous voir leur faire part d'un problème, ils seront bien plus ennuyés si vous ne leur dites rien et qu'ils ne le découvrent par eux-mêmes qu'après que quelqu'un ait facturé 8 000 $ de marchandises en utilisant les détails de la carte de crédit qu'ils ont volés sur votre site.

Vous vous souvenez de ce que j'ai dit précédemment ? La mauvaise chose est déjà arrivée. La seule question maintenant est de savoir comment vous y faites face.

Comprenez bien le problème :

  1. Ne remettez PAS les systèmes concernés en ligne tant que cette étape n'est pas terminée, à moins que vous ne vouliez être la personne dont le message a été le point de bascule qui m'a décidé à écrire cet article. Je ne vais pas mettre un lien vers ce post pour que les gens puissent avoir un rire bon marché, mais la vraie tragédie est quand les gens n'apprennent pas de leurs erreurs.
  2. Examinez les systèmes " attaqués " pour comprendre comment les attaques ont réussi à compromettre votre sécurité. Faites tous les efforts possibles pour découvrir d'où les attaques " viennent ", afin de comprendre quels sont les problèmes que vous avez et que vous devez résoudre pour rendre votre système sûr à l'avenir.
  3. Examinez à nouveau les systèmes " attaqués ", cette fois pour comprendre où sont allées les attaques, afin de comprendre quels systèmes ont été compromis lors de l'attaque. Assurez-vous de suivre toutes les indications qui suggèrent que les systèmes compromis pourraient devenir un tremplin pour attaquer davantage vos systèmes.
  4. Assurez-vous que les "passerelles" utilisées dans toutes les attaques sont bien comprises, afin de pouvoir commencer à les fermer correctement. (Par exemple, si vos systèmes ont été compromis par une attaque par injection SQL, alors non seulement vous devez fermer la ligne de code défectueuse particulière par laquelle ils se sont introduits, mais vous voudriez auditer tout votre code pour voir si le même type d'erreur a été fait ailleurs).
  5. Comprenez que les attaques peuvent réussir à cause de plus d'une faille. 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 en eux-mêmes) pour compromettre un système. Par exemple, en utilisant des attaques par injection SQL pour envoyer des commandes à un serveur de base de données, en découvrant que le site Web ou l'application que vous attaquez s'exécute dans le contexte d'un utilisateur administratif et en utilisant les droits de ce compte comme tremplin pour compromettre d'autres parties d'un système. Ou, comme les pirates aiment l'appeler : "une autre journée au bureau en profitant des erreurs courantes que les gens font".

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

Dans des situations comme celle-ci, 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 pris le contrôle du système est de reconstruire le système. Bien qu'il y ait beaucoup de valeur à trouver et à corriger l'exploit utilisé pour s'introduire 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 effet, il n'est pas rare que les pirates qui recrutent des systèmes dans un botnet corrigent eux-mêmes les exploits qu'ils ont utilisés, pour protéger "leur" nouvel ordinateur des autres pirates, ainsi que pour installer leur rootkit).

Établissez un plan de récupération et de remise en ligne de votre site web et tenez-vous-en à ce plan :

Personne ne veut être hors ligne plus longtemps qu'il ne le faut. C'est une évidence. Si ce site web est un mécanisme générateur de revenus, alors la pression pour le remettre en ligne rapidement sera intense. Même si la seule chose en jeu est votre / la réputation de votre entreprise, cela va encore générer beaucoup de pression pour remettre les choses en place rapidement.

Cependant, ne cédez pas à la tentation d'une remise en ligne trop rapide. Au lieu de cela, déplacez-vous avec aussi vite que possible pour comprendre ce qui a causé le problème et pour le résoudre avant de revenir en ligne ou sinon vous serez presque certainement victime d'une intrusion une fois de plus, et rappelez-vous, "se faire pirater une fois peut être classé dans la catégorie des malheurs.".e; se faire pirater à nouveau juste après ressemble à de l'insouciance" (avec des excuses à Oscar Wilde).

  1. Je suppose que vous avez compris tous les problèmes qui ont conduit à l'intrusion réussie en premier lieu avant même de commencer cette section. Je ne veux pas exagérer, mais si vous ne l'avez pas fait avant, vous devez vraiment le faire. Désolé.
  2. Ne payez jamais d'argent pour le chantage ou la protection. C'est le signe d'une cible facile et vous ne voulez pas que cette expression soit utilisée pour vous décrire.
  3. Ne soyez pas tenté de remettre le(s) même(s) serveur(s) en ligne sans une reconstruction complète. Il devrait être beaucoup plus rapide de construire une nouvelle boîte ou de "nuke le serveur depuis l'orbite et de faire une installation propre" sur l'ancien matériel qu'il ne le serait d'auditer chaque coin de l'ancien système pour s'assurer qu'il est propre avant de le remettre en ligne. Si vous n'êtes pas d'accord avec cela, c'est que vous ne savez probablement pas ce que signifie vraiment s'assurer qu'un système est entièrement nettoyé, ou que vos procédures de déploiement de sites Web sont un véritable fouillis. Vous avez probablement des sauvegardes et des déploiements de test de votre site que vous pouvez utiliser pour construire le site réel, et si vous n'en avez pas, le piratage n'est pas votre plus gros problème.
  4. Faites très attention à ne pas réutiliser des données qui étaient "vivantes" sur le système au moment du piratage. Je ne vous dirai pas "ne le faites jamais" parce que vous m'ignorerez, mais franchement, je pense que vous devez réfléchir aux conséquences de conserver des données alors que vous savez que vous ne pouvez pas garantir leur intégrité. Idéalement, vous devriez les restaurer à partir d'une sauvegarde effectuée avant l'intrusion. Si vous ne pouvez ou ne voulez pas le faire, vous devez être très prudent avec ces données car elles sont entachées. Vous devez surtout être conscient des conséquences pour les autres si ces données appartiennent à des clients ou à des visiteurs du site plutôt qu'à vous directement.
  5. Surveillez attentivement le(s) système(s). Vous devriez vous résoudre à le faire en tant que processus continu à l'avenir (plus bas) mais vous vous donnez un mal supplémentaire pour être vigilant pendant la période qui suit immédiatement la remise en ligne de votre site. Les intrus seront presque certainement de retour, et si vous pouvez les repérer en train d'essayer de s'introduire à nouveau, vous pourrez certainement voir rapidement si vous avez vraiment bouché tous les trous qu'ils ont utilisés auparavant plus ceux qu'ils se sont faits, et vous pourriez recueillir des informations utiles que vous pourrez transmettre à vos forces de l'ordre locales.

Réduire les risques à l'avenir.

La première chose que vous devez comprendre 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 tourné vers l'Internet, et non quelque chose que vous pouvez coller quelques couches sur votre code après coup comme de la peinture bon marché. Pour être correctement sécurisés, un service et une application doivent être conçus dès le départ en gardant cet aspect à l'esprit comme l'un des principaux objectifs du projet. Je me rends compte que c'est ennuyeux et que vous avez déjà entendu tout cela et que je "ne réalise pas la pression man" d'obtenir votre service web2.0 (bêta) en statut bêta sur le web, mais le fait est que cela continue à être répété parce que c'était vrai la première fois que cela a été dit et ce n'est pas encore devenu un mensonge.

Vous ne pouvez pas éliminer le risque. Vous ne devriez même pas essayer de le faire. Ce que vous devriez faire en revanche, c'est comprendre quels sont les risques de sécurité qui sont importants pour vous, et comprendre comment gérer et réduire à la fois l'impact du risque et la probabilité que le risque se produise.

Quelles mesures pouvez-vous prendre pour réduire la probabilité de réussite d'une attaque ?

Par exemple :

  1. La faille qui a permis aux gens de s'introduire sur votre site était-elle un bogue connu dans le code du fournisseur, pour lequel un correctif était disponible ? Si c'est le cas, devez-vous repenser votre approche sur la façon dont vous patchez les applications sur vos serveurs tournés vers Internet ?
  2. La faille qui a permis aux gens de pénétrer sur votre site était-elle un bogue inconnu dans le code du fournisseur, pour lequel un correctif n'était pas disponible ? Je ne préconise certainement pas de changer de fournisseur chaque fois qu'un problème de ce genre vous touche, car ils ont tous leurs problèmes et vous serez à court de plates-formes dans un an tout au plus si vous adoptez cette approche. Cependant, si un système vous laisse constamment tomber, vous devriez soit migrer vers quelque chose de plus robuste, soit, à tout le moins, ré-architecturer votre système afin que les composants vulnérables restent enveloppés dans de la ouate et aussi loin que possible des regards hostiles.
  3. La faille était-elle un bogue dans un code développé par vous (ou par un entrepreneur travaillant pour vous) ? Si c'est le cas, devez-vous repenser votre approche sur la façon dont vous approuvez le code pour le déploiement sur votre site en direct ? Le bug aurait-il pu être 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 la probabilité de réussite 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 construire et déployer les serveurs lorsque cela est possible ? Celles-ci sont d'une grande aide pour maintenir un état "de base" cohérent sur tous vos serveurs, minimisant la quantité de travail personnalisé qui doit être effectué sur chacun d'eux et donc, espérons-le, minimisant l'opportunité de commettre une erreur. Il en va de même pour le déploiement du code - si vous avez besoin que quelque chose de "spécial" soit fait pour déployer la dernière version de votre application web, alors essayez de l'automatiser et assurez-vous qu'il est toujours fait d'une 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 sûr, une surveillance 24 heures sur 24 ou un système d'astreinte pour votre personnel n'est peut-être pas rentable, mais il existe des entreprises qui peuvent surveiller vos services Web pour vous et vous alerter 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 ainsi.mais tenez-en compte.
  6. Utilisez des outils tels que tripwire et nessus le cas échéant - mais ne les utilisez pas aveuglément parce que je vous l'ai dit. Prenez le temps d'apprendre à utiliser quelques bons outils de sécurité adaptés à votre environnement, maintenez ces outils à jour et utilisez-les régulièrement.
  7. Envisagez d'engager des experts en sécurité pour " auditer " la sécurité de votre site web sur une base régulière. Encore une fois, vous pourriez décider que vous n'avez pas les moyens de le faire ou que vous n'en avez pas besoin et c'est très bien ainsi.mais 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 de l'étage inférieur de votre maison est élevé, mais pas assez élevé pour justifier un déménagement, vous devriez au moins déplacer les objets de famille irremplaçables à l'étage. N'est-ce pas ?

  1. Pouvez-vous réduire la quantité de services directement exposés à l'Internet ? Pouvez-vous maintenir une sorte d'écart entre vos services internes et vos services exposés à Internet ? Cela garantit que même si vos systèmes externes sont compromis, les chances d'utiliser cela 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" alors qu'elles pourraient être archivées ailleurs. Il y a deux points à cette partie ; le plus évident est que les gens ne peuvent pas vous voler des informations que vous n'avez pas, et le second point est que moins vous stockez, moins vous devez maintenir et coder pour, et donc il y a moins de chances que des bogues se glissent dans votre code ou dans la conception des systèmes.
  3. Utilisez-vous les principes du " moindre accès " pour votre application web ? Si les utilisateurs n'ont besoin que de lire une base de données, alors assurez-vous que le compte que l'appli web utilise pour la desservir n'a qu'un accès en lecture, ne lui permettez pas d'accès en écriture et certainement pas un accès au niveau du système.
  4. Si vous n'êtes pas très expérimenté dans quelque chose et que ce n'est pas central pour votre activité, envisagez de l'externaliser. En d'autres termes, si vous gérez un petit site web parlant de l'écriture de code d'application de bureau et que vous décidez de commencer à vendre de petites applications de bureau à partir du site, alors envisagez d'"externaliser" votre système de commande par carte de crédit à quelqu'un comme Paypal.
  5. Dans la mesure du possible, faites en sorte que la récupération pratique des systèmes compromis fasse partie de votre plan de reprise après sinistre. Il s'agit sans doute d'un autre " scénario catastrophe " que vous pourriez rencontrer, simplement un scénario avec son propre ensemble de problèmes et de questions qui sont distincts de l'habituel " la salle des serveurs a pris feu "/" a été envahie par des furbies géants mangeurs de serveurs ".

. Et enfin

J'ai probablement laissé de côté une infinité de choses que d'autres considèrent comme importantes, mais les étapes ci-dessus devraient au moins vous aider à commencer à trier les choses si vous avez la malchance d'être victime de pirates informatiques.

Avant tout : Ne paniquez pas. Réfléchissez 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 de mesures.

Solution 2 :

On dirait que vous êtes un peu dépassé par les événements.ead; C'est bon. Appelez votre patron et commencez à négocier pour un budget d'intervention d'urgence. 10 000 $ pourrait être un bon point de départ. Ensuite, vous devez demander à quelqu'un (un PFY, un collègue, un manager) de commencer à 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 le fait 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. Rester calme. Si vous êtes en charge de la réponse à l'incident, ce que vous faites maintenant doit démontrer le plus grand professionnalisme et le plus grand leadership. Documentez tout ce que vous faites, et tenez votre responsable et l'équipe de direction au courant des principales actions que vous entreprenez.e; Cela inclut la collaboration avec une équipe d'intervention, la désactivation des serveurs, la sauvegarde des données et la remise en ligne. Ils n'ont pas besoin de détails gores, mais ils devraient avoir de vos nouvelles toutes les 30 minutes environ.

  2. Soyez réaliste. Vous n'êtes pas un professionnel de la sécurité, et il y a des choses que vous ne connaissez pas. Ce n'est pas grave. Lorsque vous vous connectez à des serveurs et regardez des données, vous devez comprendre vos limites. Allez-y doucement. Au cours de votre enquête, veillez à ne pas piétiner des informations essentielles ou à ne pas modifier quelque chose qui pourrait être nécessaire plus tard. Si vous vous sentez mal à l'aise ou si vous avez l'impression de deviner, c'est le moment de vous arrêter et de demander à un professionnel expérimenté de prendre le relais.

  3. Prenez une clé USB propre et des disques durs de rechange. C'est ici que vous recueillerez les preuves. Faites des sauvegardes de tout ce qui vous semble pertinent : communication avec votre FAI, vidage du réseau, etc. Même si les forces de l'ordre n'interviennent pas, en cas de procès, vous voudrez ces preuves pour prouver que votre entreprise a géré l'incident de sécurité de manière professionnelle et appropriée.

  4. Le plus important est d'arrêter les pertes. Identifiez et coupez l'accès aux services, données et machines compromises. De préférence, vous devez retirer leur câblage réseau.e; si vous ne pouvez pas, alors coupez le courant.

  5. Ensuite, vous devez éliminer l'attaquant et fermer le ou les trous. Vraisemblablement, l'attaquant n'a plus d'accès interactif parce que vous avez tiré le réseau. Vous devez maintenant identifier, documenter (à l'aide de sauvegardes, de captures d'écran et de vos propres notes d'observation personnelles ; ou même, de préférence, en retirant les disques des serveurs concernés et en faisant une copie complète de l'image du disque), puis supprimer tout code et processus qu'il a laissé derrière lui. Vous pouvez essayer de démêler l'attaquant du système à la main, mais vous ne serez jamais sûr d'avoir récupéré tout ce qu'il a laissé derrière lui. Les rootkits sont vicieux, et tous ne sont pas détectables. La meilleure réponse sera d'identifier la vulnérabilité qu'il a utilisée pour s'introduire, de faire des copies d'image des disques affectés, puis d'effacer les systèmes affectés et de les recharger à partir d'une bonne sauvegarde connue. Ne faites pas aveuglément confiance à votre sauvegarde ; vérifiez-la ! Réparez ou fermez la vulnérabilité avant que le nouvel hôte ne se remette sur le réseau, puis mettez-le en ligne.

  6. Organisez toutes vos données dans un rapport. À ce stade, la vulnérabilité est fermée et vous avez un peu de temps pour respirer. Ne soyez pas tenté de sauter cette étape, elle est encore plus importante que le reste du processus. Dans le rapport, vous devez identifier ce qui n'a pas fonctionné, comment votre équipe a réagi et les mesures que vous prenez pour éviter que cet incident ne se reproduise. Soyez aussi détaillé que possible ; ce n'est pas seulement pour vous, mais pour votre direction et comme défense dans un procès potentiel.

C'est une revue en ciel de ce qu'il faut faire ; la plus grande partie du travail est simplement la documentation et la gestion des sauvegardes. Ne paniquez pas, vous pouvez faire ce genre de choses. I fortement de faire appel à des professionnels de la 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 un équipement qui rend le processus plus facile et plus rapide. Si votre patron se rebiffe devant le coût, rappelez-lui que c'est très peu par rapport à la gestion d'un procès.

Vous avez mes consolations pour votre situation. Bonne chance.


Solution 3 :

Le CERT a un document Steps for Recovering from a UNIX or NT System Compromise qui est bon. Les détails techniques spécifiques de ce document sont un peu dépassés, mais beaucoup de conseils généraux s'appliquent encore directement.

Un résumé rapide des étapes de base est le suivant .

  • Consultez votre politique de sécurité ou votre direction.
  • Prenez le contrôle (mettez l'ordinateur hors ligne).
  • Analysez l'intrusion, obtenez les journaux, déterminez ce qui a mal tourné.
  • Réparez les choses
    • 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 final.
  • Mettez à jour les systèmes pour que cela ne puisse pas se reproduire.
  • Reprenez les opérations
  • Mettez à jour votre politique pour l'avenir et documentez

J'aimerais 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é, y compris
le noyau, les binaires, les fichiers de données,
les processus en cours, et la mémoire. Sur
En général, la seule façon d'être sûr qu'une
machine est exempte de portes dérobées et de
et de modifications par des intrus est de réinstaller
le système d'exploitation

Si vous n'avez pas un système déjà en place comme tripwire, il n'y a aucun moyen possible pour vous d'être sûr à 100% que vous avez nettoyé le système.


Solution 4 :

  1. Identifiez le problème. Lisez les journaux.
  2. Contenez. Vous avez déconnecté le serveur, donc c'est fait.
  3. Eradiquer. Réinstallez le système affecté, très probablement. N'effacez pas le disque dur de celui qui a été piraté cependant, utilisez-en un nouveau. C'est plus sûr, et vous pourriez avoir besoin de l'ancien pour récupérer les vilains hacks qui n'ont pas été sauvegardés, et pour faire de la médecine légale pour savoir ce qui s'est passé.
  4. Récupérer. Installez tout ce qui est nécessaire et récupérez les sauvegardes pour mettre vos clients en ligne.
  5. Suivi. Déterminez quel était le problème et empêchez-le de se reproduire.

Solution 5 :

La réponse de Robert "pilule amère" est ponctuelle mais complètement générique (enfin, comme l'était votre question). Il semble effectivement que vous ayez un problème de gestion et un besoin urgent d'un sysadmin à temps plein si vous avez un serveur et 600 clients, mais cela ne vous aide pas maintenant.

Je dirige une société d'hébergement qui fournit un peu d'aide dans cette situation. Je m'occupe donc de beaucoup de machines compromises, mais aussi des meilleures pratiques pour les nôtres. Nous disons toujours à nos clients compromis de reconstruire, sauf s'ils ne sont pas absolument sûrs de la nature de la compromission. Il n'y a pas d'autre voie responsable sur le long terme.

Cependant, vous êtes presque certainement juste la victime d'un script kiddy qui voulait une rampe de lancement pour des attaques DoS, ou des bouncers IRC, ou quelque chose de complètement sans rapport avec les sites et les données de vos clients. Par conséquent, à titre de mesure temporaire pendant que vous reconstruisez, vous pourriez 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 votre boîte compromise inutile pour celui qui vous l'emprunte, et atténuer l'effet sur le réseau de votre fournisseur à zéro.

Ce processus peut prendre quelques heures si vous ne l'avez jamais fait auparavant et si vous n'avez jamais envisagé d'utiliser un pare-feu, mais il pourrait vous aider à rétablir 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, je suppose 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 c'est le cas, cela peut être un risque acceptable pour vous, et remettre votre système en ligne plus rapidement que d'auditer 600 sites pour des bugs de sécurité.avant vous rameniez quoi que ce soit. Mais vous saurez quelles données sont là, et à quel point vous seriez à l'aise pour prendre cette décision.

Ce n'est absolument pas la meilleure pratique, mais si ce n'est pas ce qui s'est passé chez votre employeur jusqu'à présent, agiter votre doigt vers eux et demander des dizaines de milliers de livres pour une équipe SWAT pour quelque chose qu'ils pourraient penser être votre faute (même si elle est injustifiée !) ne semble pas être l'option pratique.

L'aide de votre FAI ici va être assez cruciale - certains FAI fournissent un serveur de console et un environnement de démarrage réseau (bouchon, mais au moins vous savez quel type d'installation à rechercher) qui vous permettra d'administrer le serveur tout en étant déconnecté du réseau. Si c'est du tout une option, demandez-la et utilisez-la.

Mais à long terme, vous devriez prévoir une reconstruction du système basée sur le post de Robert et un audit de chaque site et de sa configuration. Si vous ne pouvez pas obtenir un sysadmin ajouté à votre équipe, recherchez un accord d'hébergement géré où vous payez votre FAI pour une aide sysadminning et une réponse 24 heures sur 24 pour ce genre de choses. Bonne chance 🙂

Commentaires et notes du tutoriel



Utilisez notre moteur de recherche

Ricerca
Generic filters

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.