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.
Scan un par un les répertoires « /var/www/clientID/webID/web » pour lequel PHP est activé dans ISPconfig
On supprime tous les fichiers PHP dans web/stats (sauf liste blanche :$CONFIG['remove_php']['liste_blanche']["stats"])
Si un site Wordpress est détecté :
On supprime tous les fichiers PHP dans wp-content/uploads (sauf liste blanche :$CONFIG['remove_php']['liste_blanche']["uploads"])
On supprime les thèmes et plugins inactifs :(sauf liste include/exclude par domaine, voir : $CONFIG['wp']['theme_delete_if_disable']& $CONFIG['wp']['extension_delete_if_disable'] )
On crée un environnement (wordpress) similaire (même version de core, extension, thème…)
On lance un scan sur le site wordpress avec PHP-Antimalware-Scanner et en fonction des détections :
Les Malwaires détectés son comparé à l’environnement similaire installé précédaient et on remplace le fichier infecté par le fichier original. Si ce n’est pas du core wordpress, on le supprime.
Si la quarantaine est demandée $CONFIG['scanner']['quarantaine']['enable']on déplace le fichier en quarantaine
Sinon on ne fait rien, on alerte juste de la présence
On alerte $CONFIG['alerts']['enable'] par e-mail $CONFIG['alerts']['smtp_config'] le détenteur du site internet en cas de détection de Malwaire. Pour ça 2 plugins existe ($CONFIG['alerts']['plugins'])
ISPconfig : Avec l’e-mail indiqué dans le compte client rattaché au site
Dollibarr : Avec l’e-mail de l’adhérent pour lequel le « domaine » du site match avec le champ « site internet » de sa fiche adhérent
Voilà voilà… si ça peut aider d’autres gens… bien sûr ça ne fait que du curatif…
Merci pour cette idée.
De notre coté, on a un script bash spip-cleaner pour l’écosystème spip et qui peut s’appliquer aussi sur des wordpress.
(au passage projet qui porte mal son nom ; mais quand le manque d’inspiration te tiens …)
awscan est vraiment pas mal, je l’ai également testé. Comme indiqué il faut le personnaliser pour exclure les faux positifs.
Yara est sympa aussi mais faire l’ensemble des régles correctes pour un cms laborieux. Je m’étais essayé à le faire avec le plugin spip yara
mais cela n’a jamais dépassé la preuve de concept.
Ensuite il y a toute les astuces CMS par CMS avec les script de mise à jour de sécurité automatisé, les prepend pour bloquer certains motifs d’injection comme l’écran de sécurité, … Mais ces solutions sont vraiment du cas par cas.
Coté AlternC on est en train de travailler sur un cmscanner et un cmsschecker dont les principes ressemblent à ce qui a été déjà discuté. L’identification de cms par motif (fichier, extrait de code) et un contrôle sur la base de signature de groupes de fichiers à la yara. Pour le moment c’est encore très expérimental mais les premiers résultats nous semblent positifs.
ça m’intéresse si tu es capable de faire un ping quand vous avez avancé sur le sujet… (et si c’est pas « coincé » dans AlternC c’est encore mieux je pourrais proposé une version ISPconfig si c’est adaptable.
Le cmsscanner est un cli php indépendante, je peux te filer le lien du dépôt public en direct.
Pour le moment comme on est encore en POC je ne souhaite pas le mettre à disposition à tout vent. On ne saurait pas gérer les éventuels retours et le risque de mécontentement de part et d’autres non pertinent.
Le cmschecker sera en 2 parties, d’un coté un service API qui fournit signature et chemin relatif. Le cmscsanner qui ensuite ferait le comparatif et lèverait les alertes.
Pour le moment on a juste un script qui injecte en base les signatures et un bout d’api qui donne la liste pour un cms/version donné.
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…)
