Jusqu’à présent mes serveurs web étaient scanner au niveau fichier par clamav (qui trouve rarement grand chose…) , rkhunter. J’ai eu des incidents mineurs sur des sites (ajout de page « casino » et autres trucs du genre) principalement des failles PHP (parce que j’héberge uniquement ce langage)
Est-ce que vous utilisez ça ou autre chose pour détecter/mettre en quarantaine le code problématique ? (avant que j’investisse du temps dans PHP-Antimalware-Scanner… s’il y a encore mieux…)
Ça permet de limiter la surface d’attaque potentielle.
Perso j’activerais aussi open_basedir, ça réduit les perfs un peu (désactivation du realpath cache), et c’est potentiellement contournable, mais ça ajoute une couche de restrictions. Y’a une extension pour avoir de meilleures perfs : https://github.com/Whissi/realpath_turbo
Il y d’autres stratégies pour renforcer la séparation, par exemple moi j’utilise Apache-mpm-ITK, qui permet d’avoir Apache qui se met sous un user particulier pour chaque vhost. Pour chaque vhost je peux spécifier le nombre de clients simultanés maximums, ainsi que la priorité CPU. Encore une fois, ça restreint les perfs, mais bon j’utilise ça sur un serveur Atom / 4 Go de RAM depuis 10 ans, qui sert des millions de requêtes par jour, sans souci, mais ça dépend évidemment de la qualité/gourmandise de ce qui tourne derrière… Mon point de vue est que dans un environnement mutualisé c’est plus important de séparer les hébergés proprement plutôt que d’avoir des super performances. C’est la stratégie adoptée aussi par AlternC, avec succès jusque là j’ai l’impression
ha je connaissais pas (c’est vrai qu’avant j’utilisai Suhosin). C’est intéressant et une bonne idée mais j’ai peur de me faire dépasser de problème… là j’ai ~200 sites je peux pas affiner les règles site par site (si j’ai bien compris comment ça fonctionnait) ça va être paquet de temps…
C’est le cas déjà.
J’utilise aussi, ainsi que php-fpm ça réduit effectivement la surface d’attaque au global du serveur mais ça rend aussi plus vulnérable chaque site.
Chez moi l’utilisateur web123 est lié au virtualhost bidule.fr. Le code PHP dans ce virtualhost est exécuté en tant que web123. (aussi propriétaire des fichiers qui sont déposés par FTP/SFTP…) donc tout fichier présent dans ce DocumentRoot de ce virtualhost est modifiable (plus besoin de chmod pour autoriser certaine partie en écriture)
Typiquement dans un wordpress, si tu n’es pas dans cette config tu rends juste wp-content accessible en écriture. Dans mon cas tout est accessible donc potentiellement le « core » est plus corruptible…
C’est peut être pas limpide, je peux illustrer par des bout de conf si jamais, parfois ça vaut mieux qu’un grand discoure.
Tu peux faire les deux avec les ACL : l’utilisateur FTP/SFTP a accès rwX partout, mais l’utilisateur web, exécuté par PHP, peut n’avoir qu’un accès restreint en écriture aux répertoires. Après bon en pratique les utilisateurs ont tendance à mettre du chmod 777 partout quand ils installent un truc… Donc bon pas super utile.
Ça peut aussi remonter pas mal de faux positif suivant les jeux de règles de détection utilisés, mais j’étais très satisfait de l’outil dans l’ensemble. J’ai pour projet de mettre en place un scan régulier sur notre infra web et s’il y a détection d’un fichier pas clean : bloquer l’accès au domaine concerné + envoie d’un mail à la personne responsable du compte concerné et à l’équipe tech. Mais bon, comme souvent il faut trouver le temps pour s’y coller
Si tu veux, je peux partager les liens et notes que j’avais moissonné lors de mes recherches à ce sujet.
Bon après y’a pas mal de faux positif, pas simple de trier… (mais je découvre du code vraiment cochon dans des lib’ pear et autres composer…)
