Réinstallation après une compromission de la racine ?

_Basé sur un post que j'ai a écrit il y a longtemps à l'époque où je pouvais encore me donner la peine de bloguer._

Cette question est posée de manière récurrente par les victimes de pirates informatiques qui s'introduisent dans leur serveur web. Les réponses changent très rarement, mais les gens continuent à poser la question. Je ne sais pas vraiment pourquoi. Peut-être que les gens n'aiment 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 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 la question et de la réponse où leur cas est presque identique à celui qu'ils ont lu en ligne.

Cela m'amène au premier élément d'information important. 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 de l'attaquant lui-même, il est très probable que votre problème soit identique à 95 % au moins à tous les autres cas qu'elle a 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 ces lignes après avoir été victime du piratage d'un site Web, je suis vraiment désolé et j'espère vraiment que vous trouverez quelque chose d'utile ici, mais ce n'est pas le moment de laisser votre ego vous empêcher de faire 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 rien ne s'était passé et de ne pas agir du tout.

Premièrement : comprenez que la catastrophe a déjà eu lieu. L'heure n'est pas au déni ; il s'agit 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 détienne une copie de mes coordonnées) je me moque bien que vous ignoriez tout ou partie de ces étapes, mais cela améliorera les choses au final. 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êcher que le problème ne devienne plus grave qu'il ne l'est déjà :

1. La première chose à faire est de déconnecter les systèmes concernés d'Internet. Quels que soient les autres problèmes que vous rencontrez, laisser le système connecté au Web ne fera que permettre à l'attaque de se poursuivre. Demandez à quelqu'un de visiter physiquement le serveur et de débrancher les câbles réseau si nécessaire, mais déconnectez la victime de ses agresseurs avant d'essayer de faire quoi que ce soit d'autre.
2. Changez tous vos mots de passe pour tous les comptes sur 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, c'est peut-être exagéré, mais peut-être pas. Vous ne savez pas ce qu'il en est, n'est-ce pas ?
3. Vérifiez vos autres systèmes. Accordez une attention particulière aux autres services Internet et à ceux qui contiennent 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, faites une divulgation complète et franche à toute personne potentiellement affectée immédiatement. Je sais que celle-ci est difficile. Je sais que cela va faire mal. Je sais que beaucoup d'entreprises veulent balayer ce genre de problème sous le tapis, mais je crains que vous ne deviez faire avec.

Vous hésitez encore à franchir cette dernière étape ? Je comprends, vraiment. Mais regardez-le comme ça :

Dans certains endroits, vous pourriez être légalement tenu d'informer les autorités et/ou les victimes de ce type de violation de la vie privée. Aussi ennuyés que vos clients puissent être de vous voir les informer d'un problème, ils seront bien plus ennuyés si vous ne les informez pas et qu'ils ne le découvrent par eux-mêmes qu'après que quelqu'un ait facturé 8 000 dollars de marchandises en utilisant les données de carte de crédit volées 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 qui se pose maintenant est de savoir comment vous allez faire face à cette situation.

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 post a été le point de bascule pour que je décide d'écrire cet article. Je ne mets pas un lien vers le message pour que les gens puissent se moquer de moi ; je le fais pour vous avertir des conséquences du non-respect de cette première étape.
2. Examinez les systèmes "attaqués" pour comprendre comment les attaques ont réussi à compromettre votre sécurité. Faites tout votre possible pour découvrir d'où les attaques "viennent", afin de comprendre quels sont les problèmes que vous avez et 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 savoir quels systèmes ont été compromis lors de l'attaque. Veillez à 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 parfaitement comprises, afin de pouvoir 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 par laquelle l'attaque a été lancée, mais aussi vérifier l'ensemble de votre code pour voir si le même type d'erreur a été commis 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 bogue majeur dans un système mais en enchaînant plusieurs problèmes (parfois mineurs et insignifiants 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 à profiter des erreurs courantes des gens".

Élaborez un plan de récupération et de remise en ligne de votre site Web et respectez-le :

Personne ne veut être hors ligne plus longtemps qu'il ne le faut. C'est un fait. Si ce site Web est un mécanisme générateur de revenus, la pression pour le remettre en ligne rapidement sera intense. Même si la seule chose en jeu est votre réputation ou celle de votre entreprise, la pression pour une remise en ligne rapide sera forte.

Toutefois, ne cédez pas à la tentation de vous remettre en ligne trop rapidement. Au contraire, faites le plus vite possible pour comprendre ce qui a causé le problème et le résoudre avant de vous remettre en ligne, sinon vous serez certainement victime d'une nouvelle intrusion. N'oubliez pas que "se faire pirater une fois peut être considéré comme une malchance ; se faire pirater à nouveau juste après ressemble à de la négligence" (avec les excuses d'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 en ligne le ou les mêmes serveurs sans procéder à une reconstruction complète. Il devrait être beaucoup plus rapide de construire une nouvelle boîte ou de "détruire le serveur depuis l'orbite et de faire une installation propre" sur l'ancien matériel que de vérifier 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 devez vous résoudre à le faire de manière continue à l'avenir (voir ci-dessous), mais vous devez redoubler de vigilance pendant la période qui suit immédiatement la remise en ligne de votre site. Il est presque certain que les intrus reviendront, et si vous pouvez les repérer en train d'essayer de s'introduire à nouveau, vous serez certainement en mesure de voir rapidement si vous avez vraiment bouché toutes les brèches qu'ils ont utilisées auparavant, ainsi que celles qu'ils ont créées eux-mêmes, et vous pourriez recueillir des informations utiles que vous pourrez transmettre aux forces de l'ordre locales.

Réduire le risque à 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 plaquer 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 sais que c'est ennuyeux, que vous avez déjà entendu tout cela et que je ne me rends pas compte de la pression qu'il y a à faire passer votre service web2.0 (bêta) en statut bêta sur le web, mais le fait est que cela continue d'être répété parce que c'était vrai la première fois que cela a été dit et que ce n'est pas encore devenu un mensonge.

On ne peut pas éliminer le risque. Vous ne devriez même pas essayer de le faire. Ce que vous devez 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 le 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 pénétrer 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 la façon dont vous appliquez les correctifs aux applications sur vos serveurs Internet ?
2. La faille qui a permis aux personnes 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 type se pose, 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 contractant travaillant pour vous) ? Si c'est le cas, devez-vous repenser votre approche de l'approbation du code à déployer sur votre site réel ? Le bogue aurait-il pu être détecté grâce à un système de test amélioré ou à 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 ? Dans l'affirmative, utilisez-vous des procédures automatisées pour construire et déployer les serveurs lorsque cela est possible ? Ces procédures sont d'une grande aide pour maintenir un état de base cohérent sur tous vos serveurs, réduisant ainsi la quantité de travail personnalisé à effectuer sur chacun d'eux et, espérons-le, réduisant les risques d'erreur. Il en va de même pour le déploiement du code - si vous avez besoin de quelque chose de "spécial" pour déployer la dernière version de votre application web, essayez de l'automatiser et de vous assurer qu'il est toujours fait de manière cohérente.
5. L'intrusion aurait-elle pu être détectée plus tôt grâce à 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 pas forcément 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 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" régulièrement la sécurité de votre site web. Là encore, 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 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 suffisamment 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 un certain écart entre vos services internes et vos services exposés à Internet ? Ainsi, même si vos systèmes externes sont compromis, les chances qu'ils servent de tremplin pour attaquer vos systèmes internes sont limitées.
2. Stockez-vous des informations que vous n'avez pas besoin de stocker ? Conservez-vous ces informations "en ligne" alors qu'elles pourraient être archivées ailleurs. Cette question comporte deux aspects : le plus évident est que les gens ne peuvent pas vous voler des informations que vous n'avez pas, et le second est que moins vous stockez d'informations, moins vous devez en assurer la maintenance et coder, ce qui réduit les risques que des bogues se glissent dans votre code ou dans la conception de vos 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, assurez-vous que le compte utilisé par l'application Web pour la gérer n'a qu'un accès en lecture, ne lui accordez pas d'accès en écriture et encore moins un accès au niveau du système.
4. Si vous n'avez pas beaucoup d'expérience dans un domaine et que celui-ci n'est pas essentiel à votre activité, envisagez de l'externaliser. En d'autres termes, si vous gérez un petit site Web qui parle 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, envisagez d'"externaliser" votre système de commande par carte de crédit à quelqu'un comme Paypal.
5. Dans la mesure du possible, intégrez la récupération pratique des systèmes compromis dans votre plan de reprise après sinistre. Il s'agit sans doute d'un autre "scénario catastrophe" que vous pourriez rencontrer, mais qui comporte ses propres problèmes et questions, distincts des habituels "incendie de la salle des serveurs"/"invasion par des furbies géants mangeurs de serveurs". (edit, per XTZ)

... Et enfin

J'ai probablement oublié des tas de choses que d'autres considèrent comme importantes, mais les étapes ci-dessus devraient au moins vous aider à commencer à faire le tri si vous avez la malchance d'être victime de pirates informatiques.

Par-dessus 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 d'étapes.

Toujours le faire exploser depuis l'orbite. C'est la seule façon d'être sûr.

_{(source : <a href="https://farm3.static.flickr.com/2224/1800234736_7861106fbe.jpg?v=0" rel="nofollow noreferrer">flickr.com </a>)}

La plupart des systèmes sont des entités holistiques qui ont une confiance intérieure implicite. Faire confiance à un système compromis, c'est déclarer implicitement que vous faites confiance à la personne qui a violé votre système au départ. En d'autres termes :

Vous ne pouvez pas vous y fier. Ne vous embêtez pas à le nettoyer. Déconnectez et isolez la machine immédiatement. Comprenez la nature de l'intrusion avant de procéder, sinon vous risquez de recommencer la même chose. Essayez, si possible, d'obtenir la date et l'heure de l'intrusion, afin d'avoir un cadre de référence. Vous en avez besoin car si vous restaurez à partir d'une sauvegarde, vous devez vous assurer que la sauvegarde elle-même ne contient pas une copie de la compromission. Nettoyez avant de restaurer - ne prenez pas de raccourcis.

En pratique, la plupart des gens ne le font pas parce qu'ils pensent que cela prendra trop de temps ou sera trop perturbant. J'ai informé d'innombrables clients de la probabilité de problèmes persistants, mais une réinstallation est souvent rejetée par un décideur pour l'une de ces raisons.

Ceci étant dit, sur les systèmes où je suis sûr de connaître la méthode d'entrée et l'étendue complète des dommages (journaux hors-machine solides, généralement avec un IDS, peut-être SELinux ou quelque chose de similaire limitant la portée de l'intrusion), j'ai fait un nettoyage sans réinstallation sans me sentir trop coupable.

Il est fort probable qu'ils ne disposent pas d'une routine de reprise après sinistre suffisamment testée pour se sentir en confiance lors d'une reconstruction, ou qu'ils ne savent pas exactement combien de temps cela prendrait ou quel serait l'impact... ou encore que les sauvegardes ne sont pas fiables ou que leurs analystes des risques ne comprennent pas l'ampleur d'un système compromis. Je peux penser à de nombreuses raisons.

Je dirais que c'est surtout quelque chose qui ne va pas dans les routines et les politiques de base et ce n'est pas quelque chose que vous voulez admettre ouvertement - et au lieu de cela vous adoptez une position défensive. Au moins, je ne peux pas voir ou défendre le fait de ne pas effacer un système compromis, quel que soit l'angle sous lequel on le regarde.