Trouver comment un serveur piraté a été piraté

Je parcourais simplement le site et j'ai trouvé cette question: mon serveur a été piraté d'URGENCE . Fondamentalement, la question dit: Mon serveur a été piraté. Que devrais-je faire?

La meilleure réponse est excellente mais elle a soulevé quelques questions dans mon esprit. L'une des étapes suggérées consiste à:

Examinez les systèmes «attaqués» pour comprendre comment les attaques ont réussi à compromettre votre sécurité. Faites tout votre possible pour savoir d'où viennent les attaques, afin de comprendre les problèmes que vous avez et que vous devez résoudre pour sécuriser votre système à l'avenir.

Je n'ai fait aucun travail d'administrateur système, je n'ai donc aucune idée de la façon dont je commencerais à le faire. Quelle serait la première étape? Je sais que vous pouvez consulter les fichiers journaux du serveur, mais en tant qu'attaquant, la première chose que je ferais serait d'errer les fichiers journaux. Comment "comprendre" comment les attaques ont-elles réussi?

Je commencerai par dire ceci, si vous n'avez AUCUN FICHIER DE JOURNAL , il y a de fortes chances que vous ne compreniez JAMAIS où ni comment l'attaque a réussi. Même avec des fichiers journaux complets et appropriés, il peut être extrêmement difficile de comprendre pleinement le qui, quoi, où, quand, pourquoi et comment.

Ainsi, sachant à quel point les fichiers journaux sont importants, vous commencez à comprendre à quel point vous devez les conserver. C'est pourquoi les entreprises investissent et devraient investir dans la gestion des informations et des événements de sécurité ou SIEM.

En résumé, la corrélation de tous vos fichiers journaux avec des événements spécifiques (temporels ou autres) peut être une tâche extrêmement ardue. Jetez un œil à vos syslog de pare-feu en mode débogage si vous ne me croyez pas. Et ce n'est qu'à partir d'un seul appareil! Un processus SIEM place ces fichiers journaux dans une série d'événements logiques, ce qui facilite la compréhension de ce qui s'est passé.

Pour commencer à mieux comprendre le comment, il est utile d'étudier les méthodologies de pénétration .

Il est également utile de savoir comment un virus est écrit. Ou comment écrire un rootkit .

Il peut également être extrêmement bénéfique d'installer et d'étudier un pot de miel .

Il est également utile d'avoir un analyseur de journal et de devenir compétent avec lui.

Il est utile de rassembler une base de référence pour votre réseau et vos systèmes. Quel est le trafic «normal» dans votre situation par rapport au trafic «anormal»?

Le CERT a un excellent guide sur ce qu'il faut faire après le piratage de votre ordinateur, notamment (qui se rapporte directement à votre question spécifique) la section "Analyser l'intrusion":

• Recherchez les modifications apportées au logiciel système et aux fichiers de configuration
• Rechercher des modifications aux données
• Recherchez les outils et les données laissés par l'intrus
• Examiner les fichiers journaux
• Recherchez les signes d'un renifleur de réseau
• Vérifiez les autres systèmes de votre réseau
• Vérifier les systèmes impliqués ou affectés sur des sites distants

De nombreuses questions similaires aux vôtres ont été posées sur SF:

1. Comment faire un post-mortem d'un piratage de serveur
2. Éléments étranges dans le fichier Hosts et Netstat
3. est-ce une tentative de piratage?
4. Comment puis-je apprendre Linux du piratage ou du point de vue de la sécurité

Cela peut être un processus extrêmement compliqué et complexe. La plupart des gens, moi y compris, embaucheraient simplement un consultant s'il s'impliquait davantage que ce que mes appareils SIEM pouvaient assembler.

Et, apparemment, si vous voulez comprendre COMPLÈTEMENT comment vos systèmes ont été piratés, vous devez passer des années à les étudier et à abandonner les femmes.

La réponse à cela peut être un million de kilomètres de large et de haut, et déceler ce qui est arrivé à un serveur piraté peut être presque une forme d'art autant que toute autre chose, donc encore une fois je donnerai des points de départ et des exemples plutôt qu'un ensemble définitif des étapes à suivre.

Une chose à garder à l'esprit est qu'une fois que vous avez fait face à une intrusion, vous pouvez auditer votre code, votre administration / configuration des systèmes et vos procédures en sachant qu'il y a définitivement une faiblesse. Cela aide à stimuler la motivation plus que la recherche d'une faiblesse théorique qui peut ou non exister. Très souvent, les gens mettent des choses en ligne tout en sachant que le code aurait pu être audité un peu plus dur, si seulement nous avions eu le temps; ou le système s'est verrouillé un peu plus fermement, si seulement ce n'était pas si gênant; ou les procédures rendues un peu plus strictes, si seulement cela ne dérangeait pas le patron de se souvenir de longs mots de passe. Nous savons tous où sont nos points faibles les plus probables, alors commencez par ceux-ci.

Dans un monde idéal, vous aurez des journaux stockés sur un serveur syslog différent (espérons-le non compromis) , non seulement à partir de serveurs, mais à partir de pare-feu, routeurs, etc. qui enregistrent également le trafic. Il existe également des outils comme Nessus qui peuvent analyser un système et rechercher des faiblesses.

Pour les logiciels / cadres de tiers, il existe souvent des guides de bonnes pratiques que vous pouvez utiliser pour auditer votre déploiement, ou vous pouvez accorder plus d'attention aux actualités de sécurité et aux calendriers de correctifs et découvrir certains trous qui auraient pu être utilisés.

Enfin, la plupart des intrusions laissent une trace ... si vous avez le temps et la patience de la trouver. Les intrusions ou les introductions par effraction de kiddies de script en utilisant des trousses d'outils de piratage ont tendance à se concentrer sur les faiblesses courantes et peuvent laisser un modèle qui vous indique la bonne direction. La chose la plus difficile à analyser peut être une intrusion dirigée manuellement (par exemple, quelqu'un ne voulait pas pirater "un" site Web, mais voulait plutôt pirater "votre" site Web spécifiquement), et ce sont bien sûr les choses les plus importantes à comprendre.

Pour quelqu'un qui ne sait vraiment pas par où commencer (ou même pour les personnes expérimentées qui ont d'autres fonctions), la première étape consiste probablement à embaucher une personne ayant une bonne expérience des étapes ci-dessus. Un autre avantage de cette approche est qu'ils examineront votre configuration sans aucune notion préconçue ni intérêt personnel dans les réponses.

"Je sais que vous pouvez consulter les fichiers journaux du serveur, mais en tant qu'attaquant, la première chose que je ferais serait d'errer les fichiers journaux."

Selon le type de compromis, l'attaquant peut ne pas disposer de privilèges suffisamment élevés sur le serveur compromis pour pouvoir effacer les journaux. Il est également recommandé de conserver les journaux du serveur hors boîte sur un autre serveur, pour éviter toute falsification (exportée automatiquement à certains intervalles).

Au-delà des journaux de serveur compromis, il existe toujours des journaux de mise en réseau (pare-feu, routeur, etc.) ainsi que des journaux d'authentification du service d'annuaire, s'il y en a un (Active Directory, RADIUS, ect)

Donc, regarder les journaux est toujours l'une des meilleures choses qui puissent être faites.

Lorsqu'il s'agit d'une boîte compromise, le filtrage des journaux est toujours l'un de mes principaux moyens de reconstituer ce qui s'est passé.

-Josh