À l'origine de serverfault. Merci à Robert Moir (RobM)

Il est difficile de donner des conseils spécifiques à partir de ce que vous avez publié ici, mais je ayez quelques conseils génériques basés sur un article que j'ai écrit il y a longtemps à l'époque où je pouvais encore être dérangé pour bloguer.

Ne paniquez pas

Tout d'abord, il n'y a pas de "solution rapide" autre que la restauration de votre système à partir d'une sauvegarde effectuée avant l'intrusion, et cela pose au moins deux problèmes.

1. C'est difficile pour localiser le moment de l'intrusion.
2. Cela ne vous aide pas à fermer le "trou" qui leur a permis de s'introduire la dernière fois, ni à faire face aux conséquences d'un "vol de données" qui aurait pu également place.

Cette question ne cesse d'être posée par les victimes de pirates informatiques qui pénètrent dans leur serveur Web. Les réponses changent très rarement, mais les gens continuent de poser la question. Je ne sais pas pourquoi. Peut-être que les gens n'aiment tout simplement pas les réponses qu'ils ont vues 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% des 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 là où leur cas est assez proche du même. 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 le soit aussi, car il reflète votre personnalité et celle de votre entreprise ou, à tout le moins, votre travail acharné au nom d'un employeur. Mais pour quelqu'un de l'extérieur qui regarde à l'intérieur, qu'il s'agisse d'un spécialiste 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 soit au moins 95% identique à tous les autres cas. jamais regardé.

Ne prenez pas l'attaque personnellement et ne prenez pas personnellement les recommandations qui suivent ici ou que vous recevez d'autres personnes. Si vous lisez ceci après avoir simplement été victime d'un piratage de site Web, je suis vraiment désolé, et j'espère vraiment que vous pouvez trouver quelque chose d'utile ici, mais ce n'est pas le moment de laisser votre ego vous gêner. faire.

Vous venez d'apprendre que votre ou vos serveurs ont été piratés. Et maintenant?

Ne paniquez pas. N'agissez absolument pas à la hâte, n'essayez absolument pas de prétendre que les choses ne sont jamais arrivées et de ne pas agir du tout.

Premièrement: comprenez que le désastre est déjà arrivé. Ce n'est pas le moment du déni; il est temps 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 une copie de mes coordonnées) Je m'en fiche si vous ignorez tout ou partie de ces étapes, mais cela améliorera les choses à la fin. Le médicament peut avoir un goût horrible, mais parfois vous devez l'oublier si vous voulez vraiment que le remède fonctionne.

Empêchez le problème de s'aggraver qu'il ne l'est déjà:

1. Le 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. Je veux dire cela 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 sur tous les ordinateurs qui sont sur le 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'un autre côté, ce n'est peut-être pas le cas. Vous ne savez pas non plus, n'est-ce pas?
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 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 DEMANDER une divulgation complète. Je sais que celui-ci est difficile. Je sais que celui-ci va faire mal. Je sais que de nombreuses entreprises veulent balayer ce genre de problème sous le tapis, mais l'entreprise devra y faire face - et doit le faire en gardant un œil sur toutes les lois pertinentes sur la confidentialité.
ol >

Aussi ennuyés que soient vos clients de vous faire parler d'un problème, ils seront beaucoup plus ennuyés si vous ne leur dites pas, et ils ne le découvriront que par eux-mêmes après que quelqu'un ait facturé 8 000 $ de marchandises en utilisant le 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 qui se pose maintenant est de savoir dans quelle mesure vous le gérez.

Comprenez parfaitement le problème:

1. Ne remettez PAS les systèmes concernés en ligne avant cette étape est entièrement terminée, à moins que vous ne souhaitiez être la personne dont le message a été le point de basculement pour moi en décidant d'écrire cet article. Je ne vais pas créer de lien vers ce message pour que les gens puissent rire, mais la vraie tragédie est que les gens n'apprennent pas de leurs erreurs.
2. Examinez les systèmes «attaqués» pour comprendre comment les les attaques ont réussi à compromettre votre sécurité. Faites tout votre possible pour découvrir d'où «viennent» les attaques, afin de comprendre les problèmes que vous rencontrez et 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 sont allées, afin que vous compreniez quels systèmes ont été compromis dans l'attaque. Assurez-vous de suivre tous les indicateurs suggérant que des 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 que vous puissiez commencer à les fermer correctement. (par exemple, si vos systèmes ont été compromis par une attaque par injection SQL, non seulement vous devez fermer la ligne de code défectueuse par laquelle ils ont pénétré, mais vous voudrez auditer tout votre code pour voir si le même type d'erreur a été faite ailleurs).
5. Comprenez que les attaques peuvent réussir à cause de plusieurs défauts. 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 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, la découverte du site Web / de l'application que vous attaquez s'exécute dans le contexte d'un utilisateur administratif et l'utilisation des droits de ce compte comme tremplin 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 que font 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.

Le seul moyen 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 corriger 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 effet, ce n'est pas rare pour les pirates qui recrutent systèmes dans un botnet pour corriger les exploits qu'ils ont eux-mêmes utilisés, pour protéger "leur" nouvel ordinateur contre les autres pirates, ainsi que pour installer leur rootkit).

Établissez un plan de récupération et apportez votre site Web à nouveau en ligne et respectez-le:

Personne ne souhaite rester hors ligne plus longtemps que nécessaire. C'est une évidence. Si ce site Web est un mécanisme de génération de revenus, la pression pour le remettre en ligne rapidement sera intense. Même si le seul enjeu est la réputation de votre / 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 de revenir en arrière en ligne trop rapidement. Au lieu de cela, déplacez-vous aussi vite que possible pour comprendre ce qui a causé le problème et pour le résoudre avant de revenir en ligne, sinon vous serez presque certainement victime d'une intrusion une fois de plus, et rappelez-vous, "se faire pirater une fois peut être qualifié de malheur; être piraté à nouveau tout de suite après cela ressemble à de la négligence "(avec mes excuses à Oscar Wilde).

1. Je suppose que vous avez compris tous les problèmes qui ont conduit à l'intrusion réussie avant vous même commencer cette section. Je ne veux pas exagérer le cas, mais si vous ne l'avez pas fait d'abord, vous devez vraiment le faire. Désolé.
2. Ne payez jamais d'argent 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 (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 "détruire le serveur de 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 place à nouveau en ligne. Si vous n'êtes pas d'accord avec cela, vous ne savez probablement pas ce que signifie vraiment s'assurer qu'un système est entièrement nettoyé, ou les procédures de déploiement de votre site Web sont un désordre impie. Vous avez probablement des sauvegardes et des déploiements de test de votre site que vous pouvez simplement utiliser pour créer le site en direct, et si vous ne le faites pas, le piratage n'est pas votre plus gros problème.
4. Soyez très prudent lorsque vous réutilisez des données "en direct" sur le système au moment du piratage. Je ne dirai pas "ne jamais le faire" parce que vous allez simplement m'ignorer, mais franchement, je pense que vous devez tenir compte des 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 cela à 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 aux clients ou aux visiteurs du site plutôt qu'à vous directement.
5. Surveillez attentivement le (s) système (s). Vous devriez vous résoudre à le faire comme un processus continu à l'avenir (plus de détails ci-dessous), mais vous prenez des mesures supplémentaires pour être vigilant pendant la période suivant 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 serez certainement en mesure de voir rapidement si vous avez vraiment fermé tous les trous qu'ils utilisaient auparavant, ainsi que ceux qu'ils ont faits pour eux-mêmes, et vous pourriez vous en rendre informations que vous pouvez transmettre à votre service de police local.

---

Réduire le risque à l'avenir.

La première chose que vous Il faut comprendre 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 connecté à Internet, et non quelque chose que vous pouvez appliquer quelques couches sur votre code par la suite comme une 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 cela à l'esprit comme l'un des objectifs majeurs du projet. Je me rends compte que c'est ennuyeux et que vous avez déjà entendu tout cela et que je ne me rends tout simplement pas compte de la pression exercée par l'homme pour faire passer votre service bêta web2.0 (bêta) en version bêta sur le Web, mais le fait est 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.

Vous ne pouvez pas éliminer les risques. Vous ne devriez même pas essayer de faire ça. Ce que vous devez faire cependant, c'est comprendre quels risques de sécurité 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 étapes pouvez-vous prendre pour réduire la probabilité qu'une attaque réussisse?

Par exemple:

1. La faille qui permettait aux internautes de s'introduire sur votre site était-elle connue bogue dans le code fournisseur, pour lequel un correctif était disponible? Si tel est le cas, avez-vous besoin de repenser votre approche de la façon dont vous corrigez les applications sur vos serveurs Internet?
2. La faille qui permettait aux gens de pénétrer sur votre site était-elle un bogue inconnu dans le code du fournisseur, pour quel patch n'était pas disponible? Je ne préconise certainement pas de changer de fournisseur chaque fois que quelque chose comme ça vous mord, car ils ont tous leurs 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 soit migrer vers quelque chose de plus robuste ou, à tout le moins, réorganiser votre système afin que les composants vulnérables restent enveloppés dans du coton et aussi loin que possible des yeux hostiles.
3. La faille était-elle un bogue dans le code développé par vous (ou quelqu'un qui travaillait pour vous)? Si tel est le cas, avez-vous besoin de repenser votre approche de la façon dont vous approuvez le code pour le déploiement sur votre site en ligne? Le bogue aurait-il été détecté avec un système de test amélioré ou avec des modifications de votre «standard» de codage (par exemple, bien que la technologie ne soit pas une panacée, vous pouvez réduire la probabilité d'une attaque par injection SQL réussie 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 tel est le cas, utilisez-vous des procédures automatisées pour créer et déployer des 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 fait sur chacun et donc, espérons-le, minimisant les possibilités d'erreur. Il en va de même pour le déploiement de code - si vous avez besoin de faire quelque chose de "spécial" pour déployer la dernière version de votre application Web, essayez de l'automatiser et de vous assurer que cela est toujours fait de manière cohérente.
5. Pourrait l'intrusion a été 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 «sur appel» pour votre personnel peut ne pas être rentable, mais il existe des entreprises qui peuvent surveiller vos services Web et vous alerter en cas de problème. Vous pourriez 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 simplement en considération.
6. Utilisez des outils tels que tripwire et nessus le cas échéant - mais ne vous contentez pas utilisez-les 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 de faire appel à des experts en sécurité pour «auditer» la sécurité de votre site Web régulièrement. 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 simplement 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 à 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 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 deuxième point est que moins vous stockez, moins vous avez besoin de maintenir et de coder, et donc il y a moins de chances que des bogues se glissent dans votre code ou la conception de vos systèmes.
3. Utilisez-vous les principes du "moindre accès" pour votre application Web? Si les utilisateurs ont uniquement besoin de lire à partir d'une base de données, assurez-vous que le compte utilisé par l'application Web pour la traiter ne dispose que d'un accès en lecture, ne lui autorisez pas l'accès en écriture et certainement pas l'accès au niveau du système.
4. Si vous n'êtes pas très expérimenté dans un domaine et ce n'est pas au cœur de votre entreprise, pensez à l'externaliser. En d'autres termes, si vous gérez un petit site Web qui parle d'écrire du 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. Si dans la mesure du possible, intégrez la pratique de la récupération à partir de systèmes compromis à votre plan de reprise après sinistre. C'est sans doute juste un autre "scénario catastrophe" que vous pourriez rencontrer, simplement un avec son propre ensemble de problèmes et de problèmes qui sont distincts de l'habituel 'salle des serveurs a pris feu' / 'a été envahi par le genre de chose qui mange des serveurs géants.

... Et enfin

Je n'ai probablement oublié aucune fin 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 ê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.

Making a file "undeletable" in Linux is done with attributes, specifically the "immutable" attribute. See lsattr to see attributes, chattr to change them.

However, this only answers to the proximal cause. The important thing is that your machine was put through hostile control, and the hijacker installed things for his own devious goals. In particular, he most probably installed a rootkit in order to keep the entry open despite cleansing attempts like what you are trying to do. Rootkits may have altered the kernel and/or the system binaries in ways that will not be visible from the machine itself, and which will prevent their own removal. The bottom-line is that your machine cannot be saved; there is no way you can reliably make your machine clean again, save by reformatting the disk and reinstalling from scratch.

Save yourself from future worries and headaches; nuke your system from orbit.

Comme je le disais dans la réponse au message croisé de ServerFault. C'est une bonne explication. En outre, cela dépend certainement du type d'attaque; espérons ou malheureusement, cette attaque est suffisamment bruyante pour que vous la reconnaissiez comme une attaque en cours. Ou, à ce que vous pouvez être raisonnablement certain que sont les premières étapes d'une attaque, je dirais que cet ordre des opérations est un bon plan à suivre.

Mais, il est possible que les indicateurs de compromis dont vous êtes conscient ne donnent pas une image complète de l'infection et que la déconnexion de ce PC ne soit peut-être pas dans votre meilleur intérêt tant que vous ne comprenez pas l'étendue, je soutiens que il pourrait être préférable de trouver les points d’entrée et les systèmes sur lesquels vous n’avez peut-être pas le contrôle avant de commencer à supprimer les systèmes / périphériques concernés du réseau.

La vérité est peut-être que ces acteurs ont été dans vos systèmes plus longtemps que vous ne le pensiez et montrer votre main trop tôt (c'est-à-dire que j'ai finalement remarqué que vous êtes assis dans mes systèmes) pourrait rendre leur éradication beaucoup plus difficile.

Il n'y a pas de réponse vraiment facile , mais celui fourni par RobM est un point de départ plus que suffisant. Avec toutes les pressions, il y a plusieurs bonnes réponses qui pourraient tout aussi bien être de mauvaises réponses. Presque comme le principe d'incertitude s'applique, vous ne savez pas si la réponse sera exacte jusqu'à ce que vous l'essayiez.

Le (PDF) NIST Computer Security Incident Handling Guide devrait également être lu.

Sauvegardez tout - pour que vous puissiez effectuer des recherches dans un environnement de type sandbox.

Ensuite - commencez à partir de 0 - oui de RIEN.

Nouveau O / S - entièrement patched.Applications - Fichiers de données à jour actuels .... de vos sauvegardes (avant le moment où vous avez été compromis si possible). Sinon, vous devez analyser le contenu et les autorisations TOUT.

Ensuite, effectuez un examen approfondi de la façon dont les pirates sont entrés et assurez-vous que cela ne se reproduira plus.

Lorsque vous saurez quoi s'est produit - prenez des mesures pour vous assurer que cela ne peut plus se reproduire et publiez (en interne et / ou en externe) ce que vous avez trouvé (vous pouvez choisir d'omettre les contre-mesures).

À moins que vous n'en tiriez des leçons, vous subira à nouveau le même sort.

La méthodologie est soumise au scénario réel exact mais ci-dessous serait une approche possible.

• Quelles sont mes premières étapes? Quand j'arrive sur le site, dois-je déconnecter le serveur, conserver les «preuves», y a-t-il d'autres considérations initiales?

Ans: Bien sûr, vous devez déconnecter le serveur du réseau, mais ne doit pas mettre hors tension / arrêter le serveur, car vous devrez peut-être faire une analyse approfondie pour comprendre la situation, l'impact de l'incident et conserver les preuves (les données sur votre mémoire peuvent être effacées si vous arrêtez le serveur).

Gestion de crise et communication - Si vous avez une politique de gestion de crise et de DR / BCP, suivez les procédures indiquées. Ceci est à nouveau soumis au scénario dans ce cas, il pourrait s'agir d'une propagation de virus, vous devrez peut-être suivre votre processus.

• Comment puis-je remettre les services en ligne?

Rép: Comme indiqué ci-dessus, suivez vos instructions de gestion de crise / DR / BCP. Cela peut varier en fonction de la situation.

Par exemple, si ce virus était une bombe à retardement ou s'il était déclenché par une action sur le serveur et une attaque de Ransomware, il est préférable de ne pas augmenter votre DR immédiatement (cela pourrait déclencher un autre malware s'est propagé à partir de votre serveur DR). La meilleure méthode serait d'évaluer l'impact de l'incident sur votre réseau, puis de prendre les mesures nécessaires pour rétablir vos services.

• Comment éviter que la même chose ne se reproduise immédiatement?

Ans: La cause première de l'incident doit être déterminée dès que possible pour éviter que le même incident ne se reproduise. Comme indiqué dans la réponse ci-dessus, dans un scénario de Ransomware, vous devrez peut-être vous assurer que le malware n'est pas propagé à votre DR / Sauvegarde.

Si l'incident s'est produit en raison d'une vulnérabilité de votre réseau (par exemple, un port de pare-feu a été ouvert par erreur et que l'attaque est passée par ce port, des mesures immédiates à prendre pour fermer la vulnérabilité connue / identifiée pour éviter que l'incident ne se produise à nouveau.

• Existe-t-il des bonnes pratiques ou des méthodologies pour tirer des leçons de cet incident?

Réponse: Oui, chaque incident pourrait être de nature unique. Par conséquent, mettez à jour vos procédures de gestion de crise / DR / BCP pour refléter l'apprentissage de tels incidents.

Il est toujours recommandé d'avoir une surveillance proactive / une identification des incidents en place pour éviter tels incidents. Par exemple, vous pouvez déployer un outil SOC (Security Operations Center) ou SIEM (Security Incident Event Management).

• Si je voulais mettre en place un plan de réponse aux incidents, où devrais-je Cela doit-il faire partie de ma planification de reprise après sinistre ou de continuité des activités?

Rép: uld faire partie de votre plan BCP / DR et généralement couvert dans la gestion de crise (partie du plan BCP).