Comment savez-vous que votre serveur a été compromis?

Question

J'ai récemment aidé un client dont le serveur avait été piraté. Les pirates ont ajouté du code PHP dans l'en-tête de la page d'accueil redirigeant l'utilisateur vers un site Web porno - mais uniquement s'ils venaient de Google. Cela a rendu le repérage un peu plus difficile pour le client. Le client verrait bien le site Web. Seuls les nouveaux visiteurs du site Web de Google seraient dirigés vers le site porno.

Hier soir, une chose similaire semblait arriver à un autre client. J'ai supposé qu'il s'agissait d'un hack similaire, mais lorsque j'ai vérifié la base de code, je n'ai trouvé aucun code malveillant. Son navigateur chrome redirige depuis le site Web des clients vers www(dot)pc-site(dot)com. Je ne peux pas reproduire ce comportement. Je suppose qu'il est possible que du code malveillant soit ajouté et supprimé. J'ai donc besoin un moyen plus complet de savoir si le serveur a été piraté.

Seuls 2 développeurs ont accès à ce serveur dédié (et à la société d'hébergement Rackspace). Le serveur est Red Hat Linux.

Quelles sont les étapes à suivre pour savoir si le serveur a été piraté?

Bernie White · Accepted Answer

[~ # ~] mis à jour [~ # ~]

Je vérifierais les points suivants:

Journaux. Si vous avez un accès root, vous devriez vérifier des choses comme history qui vous donneront l'historique des commandes et les fichiers journaux dans /var/logs.
Référence. Si vous avez une base de référence comme des hachages de fichiers avec lesquels travailler pour les fichiers d'application et de système, cela vous aidera beaucoup. Vous pouvez également utiliser des sauvegardes pour comparer un état précédent. Si vous utilisez une sauvegarde pour comparer des fichiers, utilisez une version légèrement plus ancienne si vous le pouvez. Le site a peut-être été compromis un certain temps auparavant et ce n'est que maintenant que la redirection a été activée.
Vérifiez tous les inclus. Les fichiers ne sont peut-être pas sur votre serveur. Il peut s'agir d'inclusions de script telles que <script src=”http://baddomain.com/s.js” /> ou iframe balises de type. N'excluez pas non plus les images, les PDF de Flash (SWF), les fichiers vidéo. Il est assez courant d'incorporer des liens dans des fichiers d'un type de contenu différent. Je vous suggère de les inspecter à la main, en particulier au début et à la fin d'un fichier. Le fichier peut être complètement un lien/html/javascript ou peut être un fichier image légitime avec un lien à la fin du fichier.
Vérifiez les dates, tailles et autorisations de fichiers inhabituelles, par exemple 777.
Vérifiez les tâches cron pour les tâches inhabituelles. Quelqu'un qui compromet un système laisse souvent une porte dérobée pour y revenir encore et encore. Cron est un moyen très populaire de le faire s'ils ont réussi à aller aussi loin.
Vérifiez l'absence de fichiers, vous ne pourrez peut-être pas avoir accès aux journaux, mais leur absence est également un signe révélateur que quelqu'un a nettoyé après lui-même.
Utilisez des moteurs de recherche. Il n'est pas surprenant que les moteurs de recherche soient parfaits pour tout trouver. Utilisez des directives comme site: par exemple. site:yoursitehere.com baddomain.com voyez si vous obtenez des hits.
Souvent, un lien ou une redirection sera obscurci, de sorte que le long code javascript avec des variables à une seule lettre doit être analysé attentivement.
Effectuez une capture de paquets avec un outil comme Wireshark ou tcpdump d'un poste de travail sécurisé vers le site. Enregistrez-le dans un fichier et recherchez dans le fichier une partie de l'url.
Vérifiez les enregistrements de base de données qui peuvent être interrogés ou mis à jour. Le lien pourrait être injecté dans la base de données et non dans PHP.
N'excluez pas le poste de travail du client. Utilisez un antivirus en ligne gratuit si nécessaire. Vérifiez également nslookup et voyez ce que cela résout. Vérifiez les extensions du navigateur, videz le cache et vérifiez les fichiers hosts.

Pour le nettoyer (si vous êtes compromis), vous devez vraiment retourner au métal nu et réinstaller. C'est douloureux mais c'est vraiment le seul moyen de s'assurer que vous avez tout.

Pour l'empêcher à l'avenir, vous devez procéder comme suit (bien que vous puissiez déjà en faire certaines):

Renforcez les serveurs, notamment en utilisant les recommandations des fournisseurs sur les configurations sécurisées, en utilisant un logiciel à jour. Appliquez un contrôle de sécurité strict tel que les autorisations, les politiques de mot de passe Voir également autorisation partagée pour les dossiers et les fichiers .
Mettre en œuvre des procédures de contrôle qualité telles que les tests sur les environnements à faible sécurité, la révision et les tests de code.
Faites tester votre vulnérabilité d'application/site Web par un testeur professionnel certifié au moins une fois. Recherchez des testeurs certifiés EC-Council, ISO 27001 et PCI. http://www.eccouncil.org/certification/licensed_penetration_tester.aspx
Consultez OWASP www.owasp.org et http://phpsec.org/projects/guide/2.html pour les ressources de sécurité des applications Web.
Utilisez les outils du système de prévention des intrusions (IPS). Cependant, selon votre hébergeur, vous pouvez avoir des limitations sur ce que vous pouvez utiliser. Basé sur l'hôte IPS devraient être corrects si vous avez une machine virtuelle dédiée.

J'espère que cela pourra aider. Sinon, vous pourriez peut-être fournir plus d'informations sur les systèmes que vous utilisez?

Rory Alsop · Answer

Comme l'a dit @Dgarcia, une méthode rapide consiste à utiliser quelque chose comme Tripwire ou un autre outil qui surveille les fichiers ou les hachages de fichiers pour vérifier les modifications. Cela permet d'identifier les serveurs compromis par de nombreux types d'attaques.

Cela peut ne pas fonctionner pour ceux où un rootkit a été installé qui contrecarre ce processus.
Cela ne fonctionnera pas pour les serveurs qui sont en proie à un compromis de mémoire uniquement ou qui ne touchent pas les fichiers que vous surveillez.

Pour 1, votre seule option est une reconstruction à partir de zéro

Pour 2, votre meilleure option est une reconstruction à partir de zéro, car tout compromis pourrait implémenter des portes dérobées qui briseraient tout ce que vous essayez de réparer, mais d'autres étapes pourraient être utiles:

vérifiez vos versions de serveur Web et de php et utilisez-les pour rechercher sur une liste de conseils des exploits connus - cela vous aidera à identifier les zones qui pourraient avoir été compromises. alors
vérifier votre code d'application web
vérifiez vos configurations de serveur web
vérifier la machine du client (pour le fichier hosts, DNS, etc.) car cela peut en fait être le problème

Linders · Answer

Il est difficile de répondre à cette question car elle est très large. Il y a deux catégories de "hacks" dans mon livre - mineures et sérieuses. Je classerais un rootkit dans la catégorie sérieuse et votre attaque d'injection de script moyenne comme mineure. Alors qu'avec des attaques mineures, vous pouvez les nettoyer, vous ne pouvez pas être sûr à 100% que vous les avez supprimées ou fermé tous les accès pour répéter l'attaque, mais vous pouvez être certain à 99% en analysant l'attaque pour des facteurs clés tels que " Cette personne était-elle un bon programmeur? " et "Quelle était l'intention de la personne?" Les rootkits sont des affaires désagréables. La suppression d'un rootkit nécessite un nettoyage et une restauration complets. En détecter un à distance est presque impossible - vous devez avoir un accès physique à la machine et un disque de démarrage en main pour en être certain.

Plus important encore, la prévention. L'adage "une once de prévention vaut une livre de cure" est tout à fait vrai dans ce contexte. Installez un logiciel qui vous permet de surveiller divers aspects du système et envoie des rapports quotidiens, voire horaires. Tripwire a été mentionné, mais il existe également d'autres outils. Je recommande d'utiliser quelques outils différents - les outils locaux sont plus difficiles à localiser et ne sont pas difficiles à créer. Vous voulez construire une défense solide et limiter l'accès au système. Ne laissez pas n'importe qui dans le monde avoir accès au port SSH (au moins, restreignez-le par adresse IP/petite plage d'adresses IP). Collez un pare-feu dédié devant chaque serveur pour qu'il y ait une couche de protection supplémentaire. Vous ne voulez pas laisser la boîte elle-même être la seule ligne de défense. Gérez uniquement les données critiques avec le serveur via SSH/SSL afin que tout soit crypté et à l'abri des regards indiscrets. Ne gérez jamais vos serveurs à partir de réseaux WiFi ouverts.

De nombreux sites utilisent MySQL ou une base de données similaire. Détecter des éléments tels que les attaques XSS ou d'autres données non fiables dans une base de données n'est pas facile car il existe des problèmes liés au schéma. Je n'ai pas vu de solutions à ce problème mais je ne doute pas qu'elles existent.

dgarcia · Answer

Une méthode rapide consiste à avoir le md5 de tous les fichiers que vous connaissez sont sains. Si vous pensez que votre site se comporte mal ou que vous effectuez une inspection régulière, vous pouvez vérifier les fichiers. Si l'un des md5 ne correspond pas, vous pouvez différencier les fichiers et parcourir les modifications.

Évidemment, cela ne fonctionne pas avec les fichiers dinamic: journaux, vidages de base de données, etc. Si vous ne pouvez pas suivre les modifications.

Il existe, bien sûr, plusieurs méthodes (inspecter les journaux ...) et les empêchements, mais c'est un moyen simple et rapide.