Utilisez vous un anti-malware / un scanner de code PHP?

Bonjour à tous,

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)

Autres mesures prises : Je force les mises à jours hebdomadairement de tout les wordpress hébergés de mes clients (ils sont au courant) par défaut : https://framagit.org/kepon/wp-cli-isp , j’utilise crowdsec pour bloquer des attaques bruteforce, et autres scan : https://app.crowdsec.net/hub/author/crowdsecurity/collections/wordpress

Mais voilà forcé de constaté qu’il y a encore pas mal de trou dans la raquettes… Je me suis tenté un petit scan avec GitHub - marcocesarato/PHP-Antimalware-Scanner: AMWScan (PHP Antimalware Scanner) is a free tool to scan php files and analyze your project to find any malicious code inside it. et là « ho surprise » y’en a de partout… :sweat_smile: :face_with_peeking_eye: :sleepy: 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…)

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…)

D’avance merci,
David

1 Like

Hello, j’utilise pas de scanner, mais snuffleupagus qui bloque certaines fonctionnalités : https://snuffleupagus.readthedocs.io/

Ç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 :slight_smile:

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.

Tu n’as pas à faire une config par site, tu peux utilise une config globale pour tout le monde, la config fournie par défaut est déjà pas mal :slight_smile:

Je vois pas en quoi ça rend plus vulnérable ?

Ok merci je vais le tester

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.

Chez @infini on a pu jouer avec yara Running YARA from the command-line — yara 4.5.0 documentation

Ç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 :stuck_out_tongue:

Si tu veux, je peux partager les liens et notes que j’avais moissonné lors de mes recherches à ce sujet.

1 Like