Re: [IPTABLES] Comment lister les paquets rejetés ?
Le 09/06/14 à 14:38, Philippe Gras <ph.gras@worldonline.fr> a écrit :
PG>
PG> Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit :
PG>
PG> > Le 07/06/14 à 18:16, Philippe Gras <ph.gras@worldonline.fr> a écrit :
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> http://spamcleaner.org/fr/misc/w00tw00t.html
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.
(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)
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...
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 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à).
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.
--
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.
Reply to: