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

Bonsoir, c'est ce qui m'intrigue le plus : le réseau d'OVH est désormais protégé contre les "gros" DDoS, et ça fonctionne plutôt bien. Tout ce que leur filtre laisse passer est sensé être «encaissable» par le serveur, c'est à dire qu'une simple solution logicielle devrait suffire. Donc comme suggéré par Dan, il faudrait déjà savoir de quel type d'attaque il s'agit vraiment, si toutefois il s'agit réellement d'une attaque...

@Dan : bah il arrive d'entrée de jeu en disant qu'il souhaite tes services, je me voyais mal faire ma pub . Sinon histoire de répondre à la question, si tu veux vraiment un dédié, je pense qu'aucun profe professionnel n'acceptera en dessus de ce modèle. Et si le tarif est trop élevé, j'aurais tendance à t'orienter vers la virtualisation, que ce soit chez OVH ou pas. La solution de Gandi est bon compromis, si ce n'est qu'à ma connaissance l'IP frontale est commune (pour Varnish), ce qui ne semble pas correspondre à tes souhaits. D'ailleurs cette histoire d'IP commune est à mon avis du flan, surtout avec la pénurie d'IPv4 ou encore les solutions de type CloudFlare. Pour moi ça fait belle lurette que les IP ne sont plus tellement «individuelles».

Bonjour, pourquoi ne demandes-tu pas à Dan justement ? Tu pourras présenter plus en détail ton projet, et il te conseillera en fonction.

Mais de rien

Bonsoir, sans être un expert, je n'ai jamais vu cette fonctionnalité parmi les principales techno de virtualisation (KVM, Xen, OpenVZ, LXC, VMWare). Par contre au travers du «transcendent memory» (ce qui concernerait donc probablement Xen, KVM, OpenVZ et LXC) il me semble qu'il est prévu de pouvoir mutualiser la mémoire de plusieurs machines physiques... plus tard. Coté disque, il y a déjà des solutions de ce style (RBD ?). Par contre en terme de CPU, je ne vois pas. Maintenant quand on voit l'impact qu'a l'utilisation du réseau sur la couche stockage, je me dis qu'un bus CPU via Ethernet ce doit être fichtrement lent.

Désolé mais là comme ça je vois pas : le fichier de conf a l'air ok, mais d'après tes logs il est clairement ignoré par MySQL.

130401 21:04:46 InnoDB: Initializing buffer pool, size = 128.0M InnoDB: Setting log file ./ib_logfile0 size to 5 MB Buffer de 128M au lieu de 20G, et logfile de 5M au lieu de 256M. Tu te serais pas planté dans ta conf ?

Mais si, c'est juste le «max connections» qui est atteint. Tes logs «slow» tu les avais bien réduits à 100ms ? Car c'est difficile d'imaginer une saturation sans en avoir de trace ici. De même, en surveillant en temps réel avec un outil type mytop ou innotop, le problème doit être facilement identifiable.

Je parlais du buffer InnoDB, as-tu laissé le temps à InnoDB de charger les données (en particulier les indexes), avant de lui couper la chique ? Sur un MySQL standard, «vanilla», il faut voir InnoDB comme un diesel : il peut mettre longtemps à atteindre sa vitesse de croisière. Le couper après 20/30 minutes est très étonnant. Mais hormis cela, vu que tu as du activer les logs slow queries, quelles sont les requêtes qui poseraient tant de mal à InnoDB ?

En 20 minutes MySQL avait déjà chargé son buffer ? Parce que si tu n'attends pas au moins ça, tu ne compares pas grand chose...