Basé sur un post que j'ai écrit il y a longtemps, à l'époque où je pouvais encore avoir la peine de bloguer.
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 trouvent 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, qu'il s'agisse d'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és. 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 moment de laisser votre ego vous empêcher de faire ce dont vous avez besoin 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), je m'en fiche si vous ignorez tout ou partie de ces étapes, mais cela améliorera la situation à 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 fonctionne.
Empêchez le problème de devenir pire qu’il ne l’est déjà:
- 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.
- 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?
- 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.
- Si le système contient des données personnelles, communiquez-les franchement à toutes les personnes potentiellement concernées. 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 j'ai bien peur que vous n'ayez plus qu'à vous en occuper.
Vous hésitez toujours à faire ce dernier pas? Je comprends, je comprends. Mais regardez comme ça:
Dans certains endroits, vous pourriez avoir l'obligation légale d'informer les autorités et / ou les victimes de ce type d'atteinte à 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, et ils ne le découvriront que lorsque quelqu'un aura facturé pour 8 000 $ de biens en utilisant les détails de sa carte de crédit. 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:
- 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 fais pas de lien vers le message pour que les gens puissent avoir un rire bon marché; Je vous relie pour vous avertir des conséquences de ne pas suivre cette première étape.
- 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.
- 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.
- 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 si le même type d’erreur a été faite ailleurs).
- 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".
É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).
- 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.
- 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.
- 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.
- 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.
- Surveillez attentivement le (s) système (s). 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 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. 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. Ce que vous devez faire, cependant, est de comprendre quels risques de sécurité sont importants pour vous et de savoir 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:
- 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?
- 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. Cependant, 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.
- 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 a-t-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 ).
- 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.
- L'intrusion aurait-elle pu être détectée plus tôt grâce à 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.
- 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.
- 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?
- 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.
- 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.
- 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.
- Si vous n’êtes pas très expérimenté et qu’il n’est pas essentiel à 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.
- 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. (éditer, par XTZ)
... 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.
