Bonsoir,
Le 07/06/2014 20:31, Philippe Gras a écrit :Non, justement pas quel que soit l'état de la connexion, et c'est
logique.
On n'aurait pas de règle pour les connexions établies, sinon ;-)
Euh ...
-m précise un module complémentaire à ta règle .
en l'occurrence -m state
S'il n'est pas précisé , ta règle matche quelque soit le 'state' .
Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ...
@+
Christophe.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Bonsoir,
Le 07/06/2014 20:31, Philippe Gras a écrit :
Non, justement pas quel que soit l'état de la connexion, et c'est
logique.
On n'aurait pas de règle pour les connexions établies, sinon ;-)
Euh ...
-m précise un module complémentaire à ta règle .
en l'occurrence -m state
S'il n'est pas précisé , ta règle matche quelque soit le 'state' .
Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ...
@+
Christophe.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/53935B96.6080003@stuxnet.org
Bonsoir,
Le 07/06/2014 20:31, Philippe Gras a écrit :Non, justement pas quel que soit l'état de la connexion, et c'est
logique.
On n'aurait pas de règle pour les connexions établies, sinon ;-)
Euh ...
-m précise un module complémentaire à ta règle .
en l'occurrence -m state
S'il n'est pas précisé , ta règle matche quelque soit le 'state' .
Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ...
@+
Christophe.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 07/06/14 à 18:16, Philippe Gras a écrit :
PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu
PG> peux t'inspirer de ça:
PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG>
PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de
PG> requêtes avec cette chaîne :
En quoi c'est gênant ?
Répondre à ce genre de requete avec une 404 coûtera bcp moins de
ressources qu'une règle
iptables qui va analyser tous les paquets http.
Si vraiment ça dérange, ajouter une règle nginx (location ~
w00tw00t) pour écrire l'ip dans un
fichier tmp (sans passer par du php, avec echo dans nginx) et une
tâche cron qui récupère les
listes pour les blacklister avec iptables et les recopier ailleurs
pour les enlever au prochain
passage me parait plus efficace, mais j'ai jamais pris la peine de
le faire malgré des milliers
de requetes comme ça par jour.
Même chose pour la dernière règle de la page, lancer une regex plus
un algo pour les
paquets qui match me parait un gaspillage important, mieux vaudrait
créer un vhost par défaut
qui va prendre les requetes directes sur l'ip (http://
xxx.xxx.xxx.xxx/) pour bannir tout le
monde qui arrive là (faudrait être sûr que les googlebot & co
lancent jamais ces requetes, pas
étudié la question car me sens pas concerné avec un varnish en
frontal).
J'ai l'impression que ce genre de "protection" ne protège que des
scripts kiddies assez
inoffensifs, les vrais méchants sont pas assez stupides pour se
faire repérer avec des attaques
aussi connues.
--
Daniel
On croit mourir pour la patrie; on meurt pour des industriels.
Anatole France
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 07/06/14 à 18:16, Philippe Gras <ph.gras@worldonline.fr> a écrit :
PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu
PG> peux t'inspirer de ça:
PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG>
PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de
PG> requêtes avec cette chaîne :
En quoi c'est gênant ?
Répondre à ce genre de requete avec une 404 coûtera bcp moins de
ressources qu'une règle
iptables qui va analyser tous les paquets http.
Si vraiment ça dérange, ajouter une règle nginx (location ~
w00tw00t) pour écrire l'ip dans un
fichier tmp (sans passer par du php, avec echo dans nginx) et une
tâche cron qui récupère les
listes pour les blacklister avec iptables et les recopier ailleurs
pour les enlever au prochain
passage me parait plus efficace, mais j'ai jamais pris la peine de
le faire malgré des milliers
de requetes comme ça par jour.
Même chose pour la dernière règle de la page, lancer une regex plus
un algo pour les
paquets qui match me parait un gaspillage important, mieux vaudrait
créer un vhost par défaut
qui va prendre les requetes directes sur l'ip (http://
xxx.xxx.xxx.xxx/) pour bannir tout le
monde qui arrive là (faudrait être sûr que les googlebot & co
lancent jamais ces requetes, pas
étudié la question car me sens pas concerné avec un varnish en
frontal).
J'ai l'impression que ce genre de "protection" ne protège que des
scripts kiddies assez
inoffensifs, les vrais méchants sont pas assez stupides pour se
faire repérer avec des attaques
aussi connues.
--
Daniel
On croit mourir pour la patrie; on meurt pour des industriels.
Anatole France
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/
20140609133206.49bf705e@quad.lairdutemps.org
Le 07/06/14 à 18:16, Philippe Gras a écrit :
PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu
PG> peux t'inspirer de ça:
PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG>
PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de
PG> requêtes avec cette chaîne :
En quoi c'est gênant ?
Répondre à ce genre de requete avec une 404 coûtera bcp moins de
ressources qu'une règle
iptables qui va analyser tous les paquets http.
Si vraiment ça dérange, ajouter une règle nginx (location ~
w00tw00t) pour écrire l'ip dans un
fichier tmp (sans passer par du php, avec echo dans nginx) et une
tâche cron qui récupère les
listes pour les blacklister avec iptables et les recopier ailleurs
pour les enlever au prochain
passage me parait plus efficace, mais j'ai jamais pris la peine de
le faire malgré des milliers
de requetes comme ça par jour.
Même chose pour la dernière règle de la page, lancer une regex plus
un algo pour les
paquets qui match me parait un gaspillage important, mieux vaudrait
créer un vhost par défaut
qui va prendre les requetes directes sur l'ip (http://
xxx.xxx.xxx.xxx/) pour bannir tout le
monde qui arrive là (faudrait être sûr que les googlebot & co
lancent jamais ces requetes, pas
étudié la question car me sens pas concerné avec un varnish en
frontal).
J'ai l'impression que ce genre de "protection" ne protège que des
scripts kiddies assez
inoffensifs, les vrais méchants sont pas assez stupides pour se
faire repérer avec des attaques
aussi connues.
--
Daniel
On croit mourir pour la patrie; on meurt pour des industriels.
Anatole France
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Le 09/06/14 à 14:38, Philippe Gras a écrit :
PG>
PG> Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit :
PG>
PG> > Le 07/06/14 à 18:16, Philippe Gras 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.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
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.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/
20140610004417.3fd6628e@quad.lairdutemps.org
Le 09/06/14 à 14:38, Philippe Gras a écrit :
PG>
PG> Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit :
PG>
PG> > Le 07/06/14 à 18:16, Philippe Gras 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.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/