Serveur compromis pour la 2ème fois, impossible de localiser la source d'attaque

Question

J'ai besoin d'aide pour tracer une vulnérabilité sur mon serveur. Pour la deuxième fois, mon serveur a été compromis avec des fichiers remplacés par des téléchargements Virus-Riden.

Selon les dates du système de fichiers, sur une période de 45 minutes 4 fichiers EXE sur mon serveur ont été remplacés par des versions renommées du même virus.

Mon serveur Web exécute Ubuntu 10.4.3 LTS avec le noyau version 2.6.32-31-générique, conservée complètement et à jour.

La seule façon d'accéder à la coquille est via SSH et une clé privée protégée par mot de passe que j'ai avec moi sur un bâton USB. Mot de passe SSH Login est désactivé et les journaux du serveur (que je connais peuvent être modifiés, mais j'ai une bonne raison de croire qu'ils ne l'ont pas) indiquent que SSH n'a pas été utilisé pour vous connecter au serveur.

La pile de logiciels de service Web est très compliquée. Il y a PHP (5.3.3-1) w/suhosin v0.9.29, NGinx 1.0.9 (maintenant mis à jour à 1.0.10), Tomcat (dans une prison et je soupçonne non associé) et mysql 5.1 .41.

J'avoue qu'à l'époque de la première attaque, je me suis contenté de blither chmod -r 777 mon répertoire Web à des fins d'atténuation des maux de tête. Maintenant, je gère un désordre complet de PHP _ scripts, y compris sans toutefois s'y limiter, WordPress, Vbulletin et plusieurs produits maison; Les deux premiers sont toujours à jour et ce dernier a été écrit avec des soins assez importants pour échapper ou normaliser les valeurs entrées par l'utilisateur.

Compte tenu des autorisations de fichier faibles mais un accès serveur fortement verrouillé, j'étais très tenté de soupçonner une vulnérabilité dans l'un des nombreux scripts PHP permettant d'exécuter du code aléatoire.

J'ai depuis entièrement verrouillé les autorisations de fichier. NGinx/PHP Exécutez comme www-Data: www-Data avec tous les fichiers donnés uniquement des autorisations d'exécution et de lecture (chmod -R 550 /var/www).

Pourtant, aujourd'hui, après tout cela, mon serveur a de nouveau été compromis.

La chose est que les fichiers qui ont été remplacés ont toujours 550 autorisations, les journaux SSH indiquent aucun connectement et je suis complètement perdu quant à quoi faire ou essayer ensuite.

J'ai essayé de recréer l'attaque sur les chemins qui ont été remplacés par un script très basique PHP:

$file = fopen('/var/www/mysite.com/path/to/file', 'w');
fwrite($file, 'test');
fclose($file)

Mais cela m'a donné les autorisations appropriées refusé une erreur.

Quelqu'un peut-il s'il vous plaît, veuillez m'informer où regarder la source de cette vulnérabilité? Est-ce que je manque quelque chose avec mes autorisations de fichier?

Je sais que ce serveur, une fois compromis, est à peu près "parti" pour toujours. Mais ce n'est pas vraiment une option ici. J'ai récursivement greffé mon dossier entier/var/journal pour les noms de fichiers affligés dans l'espoir de trouver quelque chose, mais rien ne vint.

J'ai également cherché n'importe quel scripts dans le dossier cron ou ailleurs qui aurait pu être placé au moment de la première attaque d'attaque à une date ultérieure, mais a) ne rien trouvé, et (b) ne devraient rien trouver comme le Les fichiers dans/etc/ne sont pas modifiables par les données www (en supposant un point d'infiltration NGinx/PHP).

Je devrais ajouter que les deux fois, j'ai Grep'd les journaux d'accès Nginx (style combiné) pour les noms des fichiers infectés, mais rien trouvé. Je comprends/réalisons que de nombreuses façons d'obscurcir les noms de fichiers de mes greps existent cependant.

Answer 1

Quelques techniques pour essayer de trouver la façon dont votre attaquant a obtenu:

1. Regardez les horodatages sur tous les fichiers que vous connaissez que l'attaquant a changé, puis examinez tous vos journaux pour les entrées aussi proches de chaque horodatage possible. Comme d'autres l'ont dit, les journaux d'accès Web et les journaux d'erreur Web sont les plus susceptibles de contenir la preuve du vecteur d'attaque d'origine, mais d'autres fichiers journaux peuvent également conserver des indices. Les journaux d'erreur contiennent souvent les meilleurs indices. Les journaux de tous les démons accessibles au réseau sont également de bons endroits à regarder.
2. Cela peut également valoir la peine de rechercher d'autres fichiers avec des horodatages proches de ceux que vous connaissez. /etc/passwd est un élément évident mais même des fichiers journaux peuvent être suspects s'ils ont un horodatage inhabituel. Si la logrotate fonctionne à la même heure chaque jour et qu'un de vos fichiers journaux a un horodatage qui ne correspond pas à cette heure, il a probablement été modifié pour couvrir ses pistes, et maintenant, vous en savez un peu plus sur ce qu'il a fait. N'oubliez pas le .bash_history Fichiers dans les annuaires de la maison de l'utilisateur. La commande find doit pouvoir gérer cela pour vous.
3. Exécution cuir chevel sur vos journaux d'accès Web. L'attaque initiale peut avoir eu lieu quelque temps avant que les fichiers ne soient apparus. Le cuir chevelu produira des faux positifs, mais il devrait affiner les entrées de journal suspects potentielles pour que vous analyses manuellement pour des irrégularités. Cela peut également manquer l'attaque entièrement - ce n'est pas parfait - mais cela peut aider.

Ne passez pas trop de temps sur la criminalistique dans le système compromis. Comme d'autres l'ont noté, l'attaquant a eu l'occasion de supprimer toutes les preuves de l'attaque initiale et d'ajouter un rootkit pour cacher sa présence continue. S'il a manqué quelque chose ou s'il n'a même pas essayé, les tâches ci-dessus peuvent fonctionner, mais s'il s'est bien caché, vous perdriez simplement un temps précieux.

Si vous ne trouvez pas la source de l'attaque, effacez et réinstallez le serveur en question mais avec quelques ajouts afin de l'attraper la prochaine fois.

1. Expédiez vos journaux sur un autre serveur en utilisant une variante de Syslog. (- rsyslog et syslog-ng sont les choix recommandés) de préférence, ce serveur ne doit faire que recevoir des journaux et ne doit pas partager les touches de connexion ni les mots de passe avec un autre serveur. L'objectif est de vous assurer que vos journaux ne peuvent pas être altérés ni supprimés.
2. Ajouter une journalisation supplémentaire au-delà de la valeur par défaut. Jeff a déjà mentionné Apparmor et puisque vous utilisez Ubuntu, ce sera probablement le meilleur choix. Assurez-vous que ses journaux sont envoyés dans la zone de journalisation.
3. Installez et allumez le Démon d'audit . Assurez-vous que ses journaux sont envoyés dans la zone de journalisation.
4. Exécutez des identifiants tels que Snort, PHP-IDS ou MOD_Security. (ou plus d'un, ces outils ne font pas tous exactement le même travail) Certains pare-feu matériels sont livrés avec des modules IDS/IPS. Assurez-vous que les journaux des ID sont envoyés dans la zone de journalisation.
5. Ajoutez un système de surveillance de l'intégrité de fichier tel que AIDE ou tripwire . Assurez-vous que les journaux de ces outils sont envoyés dans la zone de journalisation.
6. Surveillez vos journaux. Tomber d'un système commercial SIEM, quelque chose comme Splunk peut être installé gratuitement et peut analyser une quantité limitée de journaux. Configurer des règles pour correspondre à ce que c'est NORMAL Pour vos serveurs et filtrez-les. Tout ce qui reste est digne d'une inspection plus étroite.

Il y a beaucoup plus que vous puissiez faire si vous avez le temps et l'argent, tels que les captures de paquets de réseau complètes, mais de manière réaliste, il est à propos de toute une sysadmin solide à utiliser. Si l'attaquant apparaît à nouveau, vous serez beaucoup plus susceptible de trouver le vecteur d'attaque et beaucoup plus susceptibles de le détecter dès que l'attaque est faite.

Answer 2

@Iszi est absolument correct ici. Vous devez complètement essuyer et reconstruire, car un bon rootkit vous empêchera de voir toute preuve de son existence.

Sinon, il est fort probable que tout ce que vous faites maintenant est inutile. Dans tous les cas, vous ne pouvez plus faire confiance au serveur.

Answer 3

Muhammad, dans certains cas, j'ai vu l'attaque a été menée par un bot qui a exploité une vulnérabilité sur le système (généralement phpmyadmin) et des fichiers téléchargés sur le serveur (principalement/TMP). Ce qui se passe, c'est que ces fichiers restent là-bas et l'administrateur ne remarquera pas tant que l'attaquant passe sur leurs bûches de bot et commencez à construire sur le premier compromis.

Il est tout à fait possible qu'une vulnérabilité dans Phpmyadmin ou Vbulletin ou certains script que vous utilisez était exploitée. Plus tard, vous avez mis à jour l'application vulnérable, mais le compromis est déjà arrivé.

Si vous ne faites pas de reconstruction, ce qui se passe, c'est que les fichiers laissés par l'attaquant ont été utilisés pour compromettre votre système, encore une fois. Installation d'OSSEC sur votre système et la surveillance des fichiers/dossiers critiques vous aidera à détecter une telle activité et vous permet de prendre des mesures plus rapidement.

Answer 4

Juste pour ajouter quelques pensées aux commentaires déjà fournis. Comme @symcbean dit, le code tiers est une source probable de problèmes.

Si je devais endommager une supposition, je regarderais l'application Wordpress _ Application et les plugins associés comme une source probable de votre compromis. Il y a eu un grand nombre de problèmes de sécurité découverts dans Wordpress _ plugins récemment et beaucoup d'entre eux sont activement exploités, donc si vous avez installé et non à 100% à jour, vous pourriez bien avoir des problèmes.

En termes d'adressage de la pièce Wordpress _ Pièce de votre problème, vous pouvez regarder WPSCAN qui est un scanner de sécurité wordpress et le Secure wordpress plugin

Answer 5

Habituellement, lorsque les gens disent qu'ils ne peuvent pas se permettre d'essuyer un serveur, ils signifient que le temps nécessaire pour réinitialiser la configuration sera trop. Cependant, il y a un moyen d'y aller et de ne pas avoir à trouver la vulnérabilité immédiatement - bien que vous devez remplacer les fichiers compromis. Je vous suggère d'implémenter la sécurité avant d'exposer vos fichiers propres à Internet. Qu'est-ce qui les a cassé une fois les brisera à nouveau.

Les étapes ci-dessous sont axées sur Debian (vous n'avez pas dit que vous avez eu, alors j'ai pris mes propres préférences), mais vous pouvez également les effectuer sur les systèmes de Red Hat. Sur un système basé sur le chapeau rouge, vous pouvez avoir une solution plus facile à remplacer les suggestions de l'APPARMOR avec la configuration SELINUX correspondante. Modifiez "DPKG" pour correspondre aux commandes "miam".

• Construisez un nouveau système à l'aide des packages que vous avez déjà installés. dpkg --get-selections vous donnera une liste qui peut être canalisée dans le nouveau système à l'aide de dpkg --set-selections.

• Configurez l'APPARMOR pour restreindre lourdement NGinx et tout autre démons (Tomcat, etc.) utilisé par celui-ci. Autoriser la lecture uniquement de fichiers de configuration et de page Web. Certaines écritures devraient être activées pour le répertoire Web en fonction de ce que vous faites. Assurez-vous que votre configuration force tout enfant traite d'hériter des restrictions Apache.

• Copier tout le reste.

Portez une attention particulière à vos journaux APPARMOR. Lorsque vous voyez Apache, essayez de violer ses autorisations, vous pouvez le corréler avec vos journaux d'accès HTTP/Error et de déterminer ce qui se conduit mal.

En outre, je vais déclarer que l'établissement de contrôles d'accès obligatoire autour de tout démon est une meilleure pratique moderne et attendue. Veuillez noter que cela n'excuse pas en laissant la vulnérabilité non corrigée. La défense en profondeur est d'aider à attraper des défauts, de ne pas modifier complètement le fardeau. En outre, soyez très attentif à l'idée que votre serveur peut servir de compromis aux visiteurs de votre site.

Answer 6

4 fichiers EXE sur mon serveur ont été remplacés par des versions renommées du même virus ... Mon serveur Web exécute Ubuntu 10.4.3

Implique que vous avez déjà eu des fonctionnalités de téléchargement de fichier sur votre serveur - ce qui serait un bon endroit pour commencer à chercher des trous.

Je sais que ce serveur, une fois compromis, est à peu près "parti" pour toujours

Pas ça. Si vous effectuez des préparations adéquates, il est toujours possible de récupérer le système à un état connu (ID et sauvegardes basées sur l'hôte). Mais même alors cela n'élimine pas la vulnérabilité initiale. Mais il éliminerait les portes de dos supplémentaires installées.

y compris mais non limitée à WordPress, Vbulletin et plusieurs produits maison

OMG. Ce n'est pas parce que quelqu'un d'autre a écrit, cela ne signifie pas que c'est sécurisé. Juste parce que c'est une source ouverte ne signifie pas que c'est sécurisé. Même si vous avez les compétences nécessaires pour vérifier le code correctement, le Wordpress Base est énorme et que vbulletin est grand aussi. Ce sera une grosse tâche. Aussi tous les deux Wordpress et Vbulleting (IRC) Support Plugins tiers - qui sont souvent de grande qualité plus médiocre que les produits principaux.

Si vous exécutez Apache, alors je suggérerais d'utiliser mod_security pour essayer d'identifier le vecteur d'attaque. Mais même à un niveau de charge assez élevé, vous devriez pouvoir réconcilier le MTIME sur le fichier avec le journal d'accès (comme vous l'avez découvert, en regardant les noms de fichiers est une perte de temps).