En fait, d=C3=A9j=C3=A0 envisag=C3=A9 mais, j'aurais d=C3=BB le pr=C3=A9cis=
er dans mon premier mail d=C3=A9sol=C3=A9, une dizaine de milliers d'IP (he=
ureusement pas simultan=C3=A9es) provenant d'une 30aine de pays diff=C3=A9r=
ents...
Un peu dur =C3=A0 g=C3=A9rer :-)
Merci quand m=C3=AAme
JB
> Message du 15/05/07 18:52
> De : "Benjamin RIOU" <pandolphe@pandolphe-vision.net>
> A : "Jean-Baptiste FAVRE" <jean-baptiste.favre@wanadoo.fr>
> Copie =C3=A0 :=20
> Objet : Re: Protection contre un DDOS tcp open
>=20
> Salut !
>=20
> Que penses tu de limiter le nombre connexion par IP avec connlimit (si
> les attaques sont issues d'un sous r=C3=A9seau IP d=C3=A9fini) ou bien av=
ec le
> module recent d'iptables ?
>=20
> ++
> Ben
>=20
>
En fait, déjà envisagé mais, j'aurais dû le préciser dans mon p remier mail désolé, une dizaine de milliers d'IP (heureusement pas simu ltanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-)
Merci quand même JB
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur.
Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela contre le p2p déjà)
Une question que je me pose : pourquoi tant de haine envers ton serveur ? : -)
++ Ben
Le 15/05/07, Jean-Baptiste FAVRE<jean-baptiste.favre@wanadoo.fr> a écrit :
Salut,
En fait, déjà envisagé mais, j'aurais dû le préciser dans mon p remier mail désolé, une dizaine de milliers d'IP (heureusement pas simu ltanées) provenant d'une 30aine de pays différents...
Un peu dur à gérer :-)
Merci quand même
JB
Oui, mais tu peux peut être empecher plus de X connexions TCP
simultanées pour chaque IP (voir le module recent d'iptables).
Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur.
Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela
contre le p2p déjà)
Une question que je me pose : pourquoi tant de haine envers ton serveur ? : -)
En fait, déjà envisagé mais, j'aurais dû le préciser dans mon p remier mail désolé, une dizaine de milliers d'IP (heureusement pas simu ltanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-)
Merci quand même JB
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur.
Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela contre le p2p déjà)
Une question que je me pose : pourquoi tant de haine envers ton serveur ? : -)
++ Ben
Stephane Bortzmeyer
On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU wrote a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Tue, May 15, 2007 at 08:13:39PM +0200,
Benjamin RIOU <pandolphe@pandolphe-vision.net> wrote
a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP
simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU wrote a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean Baptiste Favre
Je fais une réponse un peu groupée:
Netfilter Recent: pourquoi pas mais il faudrait alors que je marque les connexions ouvertes et que je guette le paquet suivant dans une fenêtre de temps définie. Reste qu'Apache prendra quand même la connexion (puisqu'ouverte), et la fenêtre de temps pourrait bien rendre le timeou t d'Apache "obsolète".
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3 connexions simultanées depuis la même IP. En fait, le problème est qu'Apache attend sagement le timeout (et je ne peux pas le baisser, cause l'appli PHP qui tourne... je sais, faut refaire l'appli, mais là, je ne peux pas faire grand'chose.). Dans finalement, je ne suis pas certain de l'efficacité de la mesure. Mais je vais recreuser l'affaire.
Pourquoi tant de haine: ben, j'aimerais bien que le "proprio" du botnet me le dise :-s Plus sérieusement, soit je suis un dégât collatéra l, soit il se trompe d'IP.
J'vais p'tre creuser un mix des 2 solutions Netfilter. Je vous tiens au courant.
Merci pour les réponses, JB
Stephane Bortzmeyer a écrit :
On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU wrote a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
Je fais une réponse un peu groupée:
Netfilter Recent: pourquoi pas mais il faudrait alors que je marque les
connexions ouvertes et que je guette le paquet suivant dans une fenêtre
de temps définie. Reste qu'Apache prendra quand même la connexion
(puisqu'ouverte), et la fenêtre de temps pourrait bien rendre le timeou t
d'Apache "obsolète".
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3
connexions simultanées depuis la même IP. En fait, le problème est
qu'Apache attend sagement le timeout (et je ne peux pas le baisser,
cause l'appli PHP qui tourne... je sais, faut refaire l'appli, mais là,
je ne peux pas faire grand'chose.). Dans finalement, je ne suis pas
certain de l'efficacité de la mesure. Mais je vais recreuser l'affaire.
Pourquoi tant de haine: ben, j'aimerais bien que le "proprio" du botnet
me le dise :-s Plus sérieusement, soit je suis un dégât collatéra l, soit
il se trompe d'IP.
J'vais p'tre creuser un mix des 2 solutions Netfilter. Je vous tiens au
courant.
Merci pour les réponses,
JB
Stephane Bortzmeyer a écrit :
On Tue, May 15, 2007 at 08:13:39PM +0200,
Benjamin RIOU <pandolphe@pandolphe-vision.net> wrote
a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP
simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
Netfilter Recent: pourquoi pas mais il faudrait alors que je marque les connexions ouvertes et que je guette le paquet suivant dans une fenêtre de temps définie. Reste qu'Apache prendra quand même la connexion (puisqu'ouverte), et la fenêtre de temps pourrait bien rendre le timeou t d'Apache "obsolète".
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3 connexions simultanées depuis la même IP. En fait, le problème est qu'Apache attend sagement le timeout (et je ne peux pas le baisser, cause l'appli PHP qui tourne... je sais, faut refaire l'appli, mais là, je ne peux pas faire grand'chose.). Dans finalement, je ne suis pas certain de l'efficacité de la mesure. Mais je vais recreuser l'affaire.
Pourquoi tant de haine: ben, j'aimerais bien que le "proprio" du botnet me le dise :-s Plus sérieusement, soit je suis un dégât collatéra l, soit il se trompe d'IP.
J'vais p'tre creuser un mix des 2 solutions Netfilter. Je vous tiens au courant.
Merci pour les réponses, JB
Stephane Bortzmeyer a écrit :
On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU wrote a message of 24 lines which said:
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables).
connlimit
Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
Jean Baptiste Favre
Re, J'avais oublié le filtrage de couche 7: Vu qu'aucune requête HTTP ne parvient au serveur, je risque d'avoir un peu de mal :-)
Le fond du problème est donc bien de détecter qu'une connexion TCP légitime au sens TCP du terme ne l'est plus au niveau applicatif car aucune requête HTTP n'est envoyée dans un délai à définir (AMHA inférieur à 5 secondes en étant généreux). Et mes connaissances en iptables sont ici trop limitées :-(
@+ JB
Benjamin RIOU a écrit :
Le 15/05/07, Jean-Baptiste FAVRE a éc rit :
Salut,
En fait, déjà envisagé mais, j'aurais dû le préciser dans mo n premier mail désolé, une dizaine de milliers d'IP (heureusement pas simultanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-)
Merci quand même JB
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur.
Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela contre le p2p déjà)
Une question que je me pose : pourquoi tant de haine envers ton serveur ? :-)
++ Ben
Re,
J'avais oublié le filtrage de couche 7:
Vu qu'aucune requête HTTP ne parvient au serveur, je risque d'avoir un
peu de mal :-)
Le fond du problème est donc bien de détecter qu'une connexion TCP
légitime au sens TCP du terme ne l'est plus au niveau applicatif car
aucune requête HTTP n'est envoyée dans un délai à définir (AMHA
inférieur à 5 secondes en étant généreux).
Et mes connaissances en iptables sont ici trop limitées :-(
@+
JB
Benjamin RIOU a écrit :
Le 15/05/07, Jean-Baptiste FAVRE<jean-baptiste.favre@wanadoo.fr> a éc rit :
Salut,
En fait, déjà envisagé mais, j'aurais dû le préciser dans mo n premier
mail désolé, une dizaine de milliers d'IP (heureusement pas
simultanées) provenant d'une 30aine de pays différents...
Un peu dur à gérer :-)
Merci quand même
JB
Oui, mais tu peux peut être empecher plus de X connexions TCP
simultanées pour chaque IP (voir le module recent d'iptables).
Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur.
Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela
contre le p2p déjà)
Une question que je me pose : pourquoi tant de haine envers ton serveur
? :-)
Re, J'avais oublié le filtrage de couche 7: Vu qu'aucune requête HTTP ne parvient au serveur, je risque d'avoir un peu de mal :-)
Le fond du problème est donc bien de détecter qu'une connexion TCP légitime au sens TCP du terme ne l'est plus au niveau applicatif car aucune requête HTTP n'est envoyée dans un délai à définir (AMHA inférieur à 5 secondes en étant généreux). Et mes connaissances en iptables sont ici trop limitées :-(
@+ JB
Benjamin RIOU a écrit :
Le 15/05/07, Jean-Baptiste FAVRE a éc rit :
Salut,
En fait, déjà envisagé mais, j'aurais dû le préciser dans mo n premier mail désolé, une dizaine de milliers d'IP (heureusement pas simultanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-)
Merci quand même JB
Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur.
Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela contre le p2p déjà)
Une question que je me pose : pourquoi tant de haine envers ton serveur ? :-)
++ Ben
François Boisson
Le Tue, 15 May 2007 23:28:46 +0200 Jean Baptiste Favre a écrit:
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3 connexions simultanées depuis la même IP. En fait, le problème est qu'Apache attend sagement le timeout (et je ne peux pas le baisser,
Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse.
En fait je viens de tester sur mon serveur et une ligne comme
suffit à faire ce genre de choses. Effectivement, le serveur accumule les douilles (sockets) en ouverture, envoit des ACK un peu partout et reste avec ses connexions ouvertes comme un crétin.
J'ignore si il y a un moyen de retrouver l'origine sans doute unique de ces paquets.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Tue, 15 May 2007 23:28:46 +0200
Jean Baptiste Favre <jean-baptiste.favre@wanadoo.fr> a écrit:
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3
connexions simultanées depuis la même IP. En fait, le problème est
qu'Apache attend sagement le timeout (et je ne peux pas le baisser,
Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on
envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de
grande chances que l'IP d'origine soit fausse.
En fait je viens de tester sur mon serveur et une ligne comme
suffit à faire ce genre de choses. Effectivement, le serveur accumule les
douilles (sockets) en ouverture, envoit des ACK un peu partout et reste avec
ses connexions ouvertes comme un crétin.
J'ignore si il y a un moyen de retrouver l'origine sans doute unique de ces
paquets.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Tue, 15 May 2007 23:28:46 +0200 Jean Baptiste Favre a écrit:
Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3 connexions simultanées depuis la même IP. En fait, le problème est qu'Apache attend sagement le timeout (et je ne peux pas le baisser,
Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse.
En fait je viens de tester sur mon serveur et une ligne comme
suffit à faire ce genre de choses. Effectivement, le serveur accumule les douilles (sockets) en ouverture, envoit des ACK un peu partout et reste avec ses connexions ouvertes comme un crétin.
J'ignore si il y a un moyen de retrouver l'origine sans doute unique de ces paquets.
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
> Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse.
Je viens de voir que le ACK est renvoyé par le client à chaque fois (tu as donc SYN-- >, SYN/ACK<--- et ACK--->. Ce que j'ai dit ne marche pas sauf si il est possible de fabriquer un paquet ACK indépendamment du paquet SYN/ACK reçu (mais il me semble qu'il y a un numéro de séquence serveur à récupérer et renvoyer (en rajoutant 1). J'ai du mal à croire qu'un gars ait dix mille machines à sa disposition pour te polluer mais je ne comprends pas comment il fait... (Les ACK sont-ils tous valides?)
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
> Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse,
on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de
grande chances que l'IP d'origine soit fausse.
Je viens de voir que le ACK est renvoyé par le client à chaque fois (tu as
donc SYN-- >, SYN/ACK<--- et ACK--->. Ce que j'ai dit ne marche pas sauf si il
est possible de fabriquer un paquet ACK indépendamment du paquet SYN/ACK reçu
(mais il me semble qu'il y a un numéro de séquence serveur à récupérer et
renvoyer (en rajoutant 1). J'ai du mal à croire qu'un gars ait dix mille
machines à sa disposition pour te polluer mais je ne comprends pas comment il
fait... (Les ACK sont-ils tous valides?)
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse.
Je viens de voir que le ACK est renvoyé par le client à chaque fois (tu as donc SYN-- >, SYN/ACK<--- et ACK--->. Ce que j'ai dit ne marche pas sauf si il est possible de fabriquer un paquet ACK indépendamment du paquet SYN/ACK reçu (mais il me semble qu'il y a un numéro de séquence serveur à récupérer et renvoyer (en rajoutant 1). J'ai du mal à croire qu'un gars ait dix mille machines à sa disposition pour te polluer mais je ne comprends pas comment il fait... (Les ACK sont-ils tous valides?)
François Boisson
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Jean Baptiste Favre a écrit :
Le fond du problème est donc bien de détecter qu'une connexion TCP légitime au sens TCP du terme ne l'est plus au niveau applicatif car aucune requête HTTP n'est envoyée dans un délai à définir (AMHA inférieur à 5 secondes en étant généreux).
Oui, et qui est mieux placé que le processus serveur lui-même (ou un programme de contrôle des connexions placé en amont comme tcpd) pour gérer ce délai ?
Et mes connaissances en iptables sont ici trop limitées :-(
S'il n'y a pas de point commun entre les adresses IP sources, je vois mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peut apporter dans la mesure où le mal est fait : la connexion est établie, occupant des ressources du serveur, et plus aucun paquet n'est transmis.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean Baptiste Favre a écrit :
Le fond du problème est donc bien de détecter qu'une connexion TCP
légitime au sens TCP du terme ne l'est plus au niveau applicatif car
aucune requête HTTP n'est envoyée dans un délai à définir (AMHA
inférieur à 5 secondes en étant généreux).
Oui, et qui est mieux placé que le processus serveur lui-même (ou un
programme de contrôle des connexions placé en amont comme tcpd) pour
gérer ce délai ?
Et mes connaissances en iptables sont ici trop limitées :-(
S'il n'y a pas de point commun entre les adresses IP sources, je vois
mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peut
apporter dans la mesure où le mal est fait : la connexion est établie,
occupant des ressources du serveur, et plus aucun paquet n'est transmis.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le fond du problème est donc bien de détecter qu'une connexion TCP légitime au sens TCP du terme ne l'est plus au niveau applicatif car aucune requête HTTP n'est envoyée dans un délai à définir (AMHA inférieur à 5 secondes en étant généreux).
Oui, et qui est mieux placé que le processus serveur lui-même (ou un programme de contrôle des connexions placé en amont comme tcpd) pour gérer ce délai ?
Et mes connaissances en iptables sont ici trop limitées :-(
S'il n'y a pas de point commun entre les adresses IP sources, je vois mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peut apporter dans la mesure où le mal est fait : la connexion est établie, occupant des ressources du serveur, et plus aucun paquet n'est transmis.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
dans le meme style, il y a aussi *nmap* avec l'option -sS : SYN-SYN/ACK-RST, mais je ne sais pas si il lui est possible de ne pas envoyer le flag RST. On peut aussi regarder du cote de *netcat*.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
dans le meme style, il y a aussi *nmap* avec l'option -sS : SYN-SYN/ACK-RST,
mais je ne sais pas si il lui est possible de ne pas envoyer le flag
RST. On peut aussi regarder du cote de *netcat*.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
dans le meme style, il y a aussi *nmap* avec l'option -sS : SYN-SYN/ACK-RST, mais je ne sais pas si il lui est possible de ne pas envoyer le flag RST. On peut aussi regarder du cote de *netcat*.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Benjamin RIOU
> S'il n'y a pas de point commun entre les adresses IP sources, je vois mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peu t apporter dans la mesure où le mal est fait : la connexion est établie , occupant des ressources du serveur, et plus aucun paquet n'est transmis.
(ce qui suit est probablement une immense connerie)
Mettons que ton service à contacter sur le port 80. Serait-il possible de faire une erreur 301 "Moved Permanantly" vers un autre port ?
Je m'explique, X se connecte à ton serveur sur le port 80. Il fait un GET / La page lui répond d'aller voir sur le port 8040, sur laquelle ton serveur est doresetnavant. X se connecte alors au 8040 et tout va bien.
Formidable. Maintenant, le bot va pas aller sur le port 8040 car il fait pas de requette HTTP. Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port 80, et un timeout plus long sur le 8040.
Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être jetté sur le champ.
Qu'est-ce que t'en penses ?
++ Ben
> S'il n'y a pas de point commun entre les adresses IP sources, je vois
mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peu t
apporter dans la mesure où le mal est fait : la connexion est établie ,
occupant des ressources du serveur, et plus aucun paquet n'est transmis.
(ce qui suit est probablement une immense connerie)
Mettons que ton service à contacter sur le port 80.
Serait-il possible de faire une erreur 301 "Moved Permanantly" vers
un autre port ?
Je m'explique,
X se connecte à ton serveur sur le port 80. Il fait un GET /
La page lui répond d'aller voir sur le port 8040, sur laquelle ton
serveur est doresetnavant.
X se connecte alors au 8040 et tout va bien.
Formidable.
Maintenant, le bot va pas aller sur le port 8040 car il fait pas de
requette HTTP.
Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port
80, et un timeout plus long sur le 8040.
Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être
jetté sur le champ.
> S'il n'y a pas de point commun entre les adresses IP sources, je vois mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peu t apporter dans la mesure où le mal est fait : la connexion est établie , occupant des ressources du serveur, et plus aucun paquet n'est transmis.
(ce qui suit est probablement une immense connerie)
Mettons que ton service à contacter sur le port 80. Serait-il possible de faire une erreur 301 "Moved Permanantly" vers un autre port ?
Je m'explique, X se connecte à ton serveur sur le port 80. Il fait un GET / La page lui répond d'aller voir sur le port 8040, sur laquelle ton serveur est doresetnavant. X se connecte alors au 8040 et tout va bien.
Formidable. Maintenant, le bot va pas aller sur le port 8040 car il fait pas de requette HTTP. Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port 80, et un timeout plus long sur le 8040.
Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être jetté sur le champ.
