Le 10 juin 14 à 00:44, Daniel Caillibaud a écrit :
PG> PG> Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit : PG> PG> > PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu PG> > PG> peux t'inspirer de ça: PG> > PG> PG> > PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de PG> > PG> requêtes avec cette chaîne : PG> > PG> > En quoi c'est gênant ? PG> > PG> > Répondre à ce genre de requete avec une 404 coûtera bcp moins de PG> > ressources qu'une règle PG> > iptables qui va analyser tous les paquets http. PG> PG> Ah, bon ? Je veux bien le croire, mais ça demande à être confirmé. PG> Parce que si ce n'est pas PG> iptables qui analyse les paquets, c'est le serveur virtuel qui va le PG> faire ensuite, non ? Donc le PG> résultat serait identique au niveau du temps d'attente, non ?
Je pense pas, le serveur web n'aura que les urls à pbs à traiter, alors que iptable va traiter tous les paquets tcp du port 80.
Pas faux :-D (chez moi les scripts kiddies c'est qq centaines de requetes, milliers quand ils s'excitent, sur pas mal de millions, j'ai jamais vu d'impact sur les temps de réponse des utilisateurs légitimes)
J'ai quand même remarqué un impact sur le chargement des pages sur le frontend, mais pas limitant pour l'utilisateur lambda. Comme ce sont mes sites, mon œil est exercé et exigeant :-)
PG> > Si vraiment ça dérange, ajouter une règle nginx (location ~ PG> > w00tw00t) pour écrire l'ip dans un PG> > fichier tmp (sans passer par du php, avec echo dans nginx) et une PG> > tâche cron qui récupère les PG> > listes pour les blacklister avec iptables et les recopier ailleurs PG> > pour les enlever au prochain PG> > passage me parait plus efficace, mais j'ai jamais pris la peine de PG> > le faire malgré des milliers PG> > de requetes comme ça par jour. PG> PG> Oui, ça me parait une bonne idée. Comment comparer la vitesse PG> d'exécution des 2 règles ?
La mesurer... Mais amha c'est de l'énergie gaspillée, sauf si tu veux étudier ce cas en détails...
Pendant que j'y suis… Sur PHP.net, j'ai vu un type mesurer "elseif" et "else if", alors je n'aurai pas peur du ridicule en vous présentant les résultats !
PG> > Même chose pour la dernière règle de la page, lancer une regex plus PG> > un algo pour les PG> > paquets qui match me parait un gaspillage important, mieux vaudrait PG> > créer un vhost par défaut PG> > qui va prendre les requetes directes sur l'ip (http:// PG> > xxx.xxx.xxx.xxx/) pour bannir tout le PG> > monde qui arrive là (faudrait être sûr que les googlebot & co PG> > lancent jamais ces requetes, pas PG> > étudié la question car me sens pas concerné avec un varnish en PG> > frontal). PG> PG> C'est déjà le cas chez moi. Je ne crois pas que les crawlers PG> s'intéressent aux IP, je ne l'ai jamais PG> remarqué. Mais ça pourrait venir, on ne sait jamais… PG> > PG> > J'ai l'impression que ce genre de "protection" ne protège que des PG> > scripts kiddies assez PG> > inoffensifs, les vrais méchants sont pas assez stupides pour se PG> > faire repérer avec des attaques PG> > aussi connues. PG> PG> Je suis complètement d'accord avec cette assertion. Le problème, PG> c'est que les script kiddies sont PG> très gourmands, et vraiment très envahissants.
C'est là que j'ai du mal à suivre, si qq milliers de requetes sur une 404 ralentissent ton appli c'est l'appli qui a un pb.
C'est du Wordpress, donc ce n'est déjà pas très performant à la base… Mais ce ne sont pas des erreurs 404 dont il s'agit, mais 403 (Forbidden). (c'est vrai que certains cms envoient toutes les 404 au controleur principal, qui doit charger toute l'appli pour répondre à la fin 404, si c'est du php utiliser apc doit pas mal réduire la charge en général, et notamment dans ces cas là).
J'utilise Memcached + Xcache (équivalent à APC, 1 poil moins performant, mais très fiable).
PG> J'aimerais bien réserver l'accès de mon serveur à des utilisateurs PG> légitimes, car il est tout petit, pas PG> très costaud, donc le compromis est difficile à trouver entre une PG> certaine tolérance avec les bots, et PG> une discrimination rigoureuse…
Si c'est trop compliqué de modifier l'appli faut ajouter qq location pour ces urls à pb, même avec qq milliers d'appels sur une petite machine, c'est pas ça qui va fatiguer ton nginx.
Je crois que NginX s'en fout, il bloque l'accès sans se poser de question. C'est moi qui fatigue.
L'idée que tu as exposée, j'y ai réfléchi cet après-midi, et je la trouve super.
De plus, elle irait bien avec un anti-spam que j'ai développé en PHP, mais que je souhaiterais améliorer pour le faire bosser plus vite. Coupler les 2 serait tout simplement mortel :-)
-- Daniel
Pour atteindre le bonheur il y a deux règles : 1. Contentez vous de ce que vous avez. 2. Essayez d'en avoir un maximum.
-- Lisez la FAQ de la liste avant de poser une question :
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
|