web-dev-qa-db-fra.com

Quelles mesures dois-je prendre après avoir découvert qu'un de mes scripts est vulnérable?

Je gère quelques sites Web basés sur PHP pour une petite entreprise sur un serveur LAMP. Les scripts incluent des CMS tels que Joomla ou Wordpress, ainsi que des installations SilverStripe et Drupal.

Il y a une semaine, j'ai découvert que les sites avaient été compromis. Les seules causes réelles des problèmes étaient que tous les fichiers .php avaient été supprimés lors de l'attaque. Restaurer ceux de la sauvegarde a tout remis dans un état normal.

Bien entendu, la faille de sécurité existe toujours quelque part. Voici ce que j'ai fait immédiatement après l'attaque:

  • Les sites sont tous enregistrés dans /var/www et les fichiers et dossiers utilisés appartiennent à www-user. J'ai maintenant créé un utilisateur pour chaque site, par exemple. drupal et a exécuté chown -R drupal:www-data . sur le dossier Drupal.

  • J'ai vérifié les autorisations afin que les fichiers soient u=rwx,g=rx,o= et les répertoires u=rw,g=r,o=. Cela, je suppose, empêchera une attaque via PHP de supprimer des fichiers ou de les modifier de quelque manière que ce soit.

Maintenant mes questions:

  • Ces hypothèses sur les autorisations sont-elles correctes et vont-elles au moins me sauver d'une attaque imminente?

  • Quelles autres précautions puis-je prendre, hormis la mise à niveau des scripts vers la dernière version et le contrôle du bon fonctionnement de mes sauvegardes?

phpsecurityapache2chmod
5
slhck

Le fait que vous ayez créé des utilisateurs supplémentaires pour chacun des sites soit un avantage, car si un utilisateur est piraté/exploité, le reste n’est pas affecté, mais vous pourriez aller plus loin.

Vhosts dans les dossiers de départ

Vous pouvez déplacer les hôtes dans leurs dossiers personnels afin qu'ils soient emprisonnés pour ainsi dire, ce qui ajoutera un peu de sécurité supplémentaire. Vous pouvez configurer les hôtes virtuels de manière à ce que les chemins soient dans/home/drupal/public_html, par exemple, puis les configurer de manière à ce que chaque utilisateur ne puisse pas entrer dans la maison des autres utilisateurs.

Chmod

Je suis sûr que vous avez déjà fait cela. Vous semblez avoir la tête basse sur la sécurité, mais les fichiers clés qui sont injectés dans la plupart des exploits sont les fichiers de modèle, le fichier index, le fichier de configuration et le fichier .htaccess. Donc, CHMOD, ces fichiers sont extrêmement importants.

Bien que le réglage de CHMOD soit essentiel, vous pouvez également sécuriser votre site par quelques autres éléments clés.

Injections SQL

Les injections SQL sont toujours très populaires et, en utilisant de bonnes mesures de sécurité, vous pouvez éviter cela, il peut être utile de désactiver des éléments tels que error_reporting dans le fichier php.ini, ainsi que la configuration de .htaccess sécurisé pour ajouter une couche supplémentaire. Mais vous devriez toujours essayer de voir si votre placement de données dans le SQL est correct. Il est important de vérifier que les plugins que vous utilisez utilisent mysql_real_escape_string ou pg_escape_string (si vous utilisez PHP) ou utilisez des instructions préparées pour toutes les requêtes en utilisant des variables depuis un POST ou GET. Cela facilitera l’injection de code SQL, ce qui en fait un joli prêt pour indiquer exactement comment procéder, mais vous devez également effectuer une recherche sur Google et en apprendre un peu plus sur les injections de code SQL afin de les éviter complètement.

Sécurité PHP

Vous devriez envisager d'utiliser un fichier php.ini pour chacun de vos sites dans leurs répertoires personnels afin de pouvoir désactiver les éléments dont ils n'ont pas besoin pour fonctionner. Plus vous désactivez de choses, moins vous aurez de pirates informatiques à utiliser contre votre site.

J’envisage de les désactiver, bien que selon votre site, vous pourriez avoir besoin de choses comme fopen pour faire des mises à jour, ou le faire manuellement et vous pouvez probablement le désactiver.

allow_url_fopen = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /home/yourUserID/public_html/phperr.txt
expose_php = Off
magic_quotes_gpc = Off
magic_quotes_sybase = Off
register_globals = Off

Robots.txt

Les robots peuvent ajouter un peu de sécurité à votre site en empêchant les moteurs de recherche d’accéder à vos dossiers de plugins. De nombreux problèmes de sécurité sont causés par des plugins obsolètes et exploitables. Le plus souvent, les pirates informatiques utilisent Google pour trouver ces sites. Assurez-vous que vos plugins de blocage empêchent les gens de les trouver sur votre site.

3
Simon Hayter

Vous devez vraiment identifier comment l'attaquant est entré. Si c'était via le serveur Web, c'est en fait relativement facile:

  1. Déterminez quand les fichiers ont disparu. Vous avez déjà remis les fichiers, nous ne pouvons donc pas regarder l'heure de modification du répertoire. Au lieu de cela, recherchez dans les journaux du serveur Web les erreurs 404 de ces fichiers.
  2. Déterminez quelles demandes sont entrées sur le serveur Web immédiatement avant la disparition des fichiers. Examinez les journaux du serveur Web ... s’il s’agissait d’une requête GET ou HEAD, il y aurait quelque chose d’évident dans les journaux. Recherchez des éléments autres que GET/HEAD & POST. Si vous ne trouvez toujours rien, il s'agissait d'un POST et, à moins que vous n'exécutiez mod_security ou que vous ne crachez une sortie de débogage ad-hoc, vous n'aurez aucun journal de ce qu'ils ont réellement fait. Vous pouvez rechercher des adresses IP qui semblent traiter des requêtes anormales ou consulter le journal des erreurs pour voir s’il contient des indices.

Comme cela a déjà été mentionné, vous devez vraiment changer tous les mots de passe. Je suggérerais également de modifier la propriété du répertoire du serveur Web afin que l'utilisateur avec lequel le serveur Web s'exécute ne soit pas autorisé à modifier les fichiers. Si vous effectuez un téléchargement de fichier ou un autre contenu dérivé de l'utilisateur, attribuez-lui un sous-répertoire dans lequel il peut écrire, mais ne pas au niveau supérieur. (et assurez-vous que le sous-répertoire en question ne peut pas contenir de CGI, PHP ou quoi que ce soit qui serait servi autrement que sous forme de fichier statique). Vous voudrez regarder les journaux d'erreurs de votre serveur Web pour voir s'il y a quelque chose qui nécessite (veut?) Des autorisations plus permissives, puis donnez-lui ces autorisations ou modifiez son comportement.

Si vous souhaitez un niveau de sécurité encore plus élevé, si vous êtes prêt à utiliser votre ressource et à disposer d'un deuxième serveur, vous stockez tous les fichiers sur un serveur complètement différent, puis NFS les monte en lecture seule sur le serveur Web. Cela signifie que si (quand?) Il y a une vulnérabilité, ils doivent travailler beaucoup plus dur pour causer des dommages durables.

Vous devez également regarder benchmarks CIS pour Apache qui est un guide pour renforcer votre serveur (ils ont aussi des guides sur le système d’exploitation et la base de données) - mais sachez que vous devez comprendre chaque étape, comme vous le ferez souvent casser un site existant, en particulier pour les clients dotés de navigateurs plus anciens, si vous les appliquez à l’aveuglette. C’est un autre exemple de situation dans laquelle vous devez surveiller les journaux d’erreurs pendant une semaine environ après avoir apporté les modifications.

4
Joe