Kioob

Bonjour, pour faire pas mal de Prestashop à gros trafic, le problème ne vient jamais de NginX. Dans les ~200ms de temps de réponse d'un Prestashop, il y a 1ms liés à NginX, et 199ms à PHP/Prestashop. Bref, non je n'ai pas testé litespeedtech, mais j'avoue que je ne vois pas du tout ce que ça pourrait apporter ici. Peux-tu en dire plus sur ce que tu as entendu dire ?

Bonjour, sans activer les logs complets, ne serait-ce qu'activer les logs binaires serait déjà une bonne aproche, non ?

@Dan : il me semble qu'ils ont été plus ou moins obligés de s'y mettre, à cause de l'utilisation massive de Git, composer, et autres webpacks. Mais jamais essayé non plus.

Je ne connais pas du tout les possibilités des hébergements mutualisés. Si vous avez un accès SSH, vous pouvez essayer de lancer le script directement dessus oui. Sinon ce sera en local, et ça requiert effectivement Python.

Bonjour, pour le nettoyage, j'utilise beaucoup ce script https://github.com/planet-work/php-malware-scanner Mais ça ne fait pas tout. Généralement il reste une ou deux backdoor, que j'identifie en comparant tous les fichiers avec le contenu des backups (ou Git).

Bonjour, j'aurais tendance à penser qu'il n'y a pas de vhost qui match le nom de domaine en question (ServerName & ServerAlias). Non ? En tous cas je ne connais pas d'option de log permettant de verifier le comportement du "routage" des virtualhost.

Bonjour, si tu veux un seul unique certificat pour plusieurs sites, ça va tout de suite être plus compliqué. Tu parles de combien de sites ? Y a t-il des sous-domaines à inclure ? As-tu regardé la solution de let's encrypt ? (je ne sais pas s'ils fournissent des outils pour Windows).

@Dan : merci Pour une fois que je ne débarque pas après la tempête !

Bonjour, oui c'est normal, le mode (f)CGI permet justement d'isoler PHP et Apache, si bien qu'Apache ne connait plus aucune inscruction de type php[_admin]_(value|flag). Ce qui implique qu'on ne peut plus modifier la configuration de PHP via un fichier .htaccess Toutefois il y a plusieurs alternatives, dont les deux principales : - généralement en (f)CGI chaque si a son propre fichier php.ini, dans lequel on peut ajuster la conf que l'on veut - depuis PHP 5.3 celui-ci gère les fichiers .user.ini (cf http://php.net/manual/fr/configuration.file.per-user.php), reproduisant le même mécanisme que les .htaccess, mais dédiés à PHP

Si si, pour moi les CDN sont très bien, et généralement super efficaces. Mais un client me l'a déjà refusé, car le CDN impliquait des IP non françaises, et que son référenceur lui a vivement déconseillé. À partir du moment où le client a plus confiance en son référenceur qu'en moi, je ne peux malheureusement rien faire de plus. Pour en ajouter une couche sur les garanties financières vendues avec les certificats, y a aussi le comparatif de Gandi : https://www.gandi.net/ssl/compare

Bonsoir, j'ai du mal à voir où tu veux en venir en fait. Ces technos sont plutôt complémentaires et n'ont pas grand chose à voir entre elles. Le CDN permet avant tout d'améliorer les performances, l'expérience utilisateur. Pour moi c'est son rôle principal, tandis que son rôle secondaire étant d'alléger la charge du serveur backend. Si gain de sécurité il y a, il ne me semble pas bien énorme. Le SSL est une technique de chiffrement des transferts. Incontournable ou presque si on parle sécurité quoi. Ce que tu appelles «EV SSL» est le nom d'une famille de certificats utilisés dans le cadre du SSL. Cela sert à garantir que le serveur avec lequel on dialogue est bien celui auquel on pense. Ça apporte également des garanties pécuniaires (assurances...), mais techniquement à ce que je sache, ça ne change rien. Quant aux honeypots, euh... dans quel cadre ? L'idée est de détecter des utilisations douteuses pour analyser, tracer ou bloquer le comportement d'un tiers. Bref, tu peux remettre tes idées dans l'ordre et nous dire ce que tu cherches à savoir au juste ? Dans l'élan : les CDN sont transparents pour l'utilisateur, et donc oui parfaitement compatibles les outils analytics basés sur un tag (JS ou image). D'un point de vue SEO, je dirais la même chose, si ce n'est qu'il est du coup impossible de choisir la langue de l'IP du site, chose qui n'a absolument aucune importance d'après moi, mais certains «référenceurs» jureront le contraire. Quant à la question : CDN ou hébergement SSL ? Bah les deux.

Sous Debian tu peux l'installer simplement via un : apt-get install clamav-base

Bonjour, dans le doute je t'invite à passer un petit coup de clamav sur le site. En effet ce dernier repère une bonne partie des backdoors habituellement laissées par ce genre de «script kiddies» : nice clamscan --infected --recursive /dossier-de-ton-site/

Pour ma part je préconise toujours de séparer le domaine et l'hébergement, pour des raisons historiques : beaucoup de «petits» hébergeurs frôlent la malhonnêteté et bloquent les mises à jour DNS lorsqu'on cherche à migrer ailleurs. Donc pour ma part au niveau du domaine j'estime qu'on devrait toujours prendre soit même le domaine chez un «vrai» registrar (comme Gandi et OVH, par exemple). Maintenant le fait de séparer les fournisseurs force également à comprendre la différence entre le domaine et l'hébergement, chose que beaucoup de monde confond encore.

Bonsoir, fail2ban utilisant le firewall du système, on peut directement interroger celui ci : # iptables -L -n -v | grep A.B.C.D