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
>
Bonsoir à tous, La discussion continue, c'est cool :-)
Quelques précisions, adaptées à et motivées par ce cas précis.
Pourquoi je n'ai pas retenu la solution Redirect ? Parce que cela m'oblige à potentiellement renvoyer une information à l'attaquant, dévoilant par là même ma stratégie de défense ('tain, ça fait riche la phrase là. J'vais la noter pour quand je ferai consultant :-) ). Accessoirement, cela oblige à ouvrir à tout va le port xxxx sur leque l écoute HTTPD. Donc accessible aussi au méchant.
Pourquoi je n'ai pas retenu la solution RewriteRules ? Pour diverses raison, par exemple parce que la solution proxy est plus complète, plus souple et permet un plus grand contrôle, parce que je ne connais que très mal les RewriteRules, ...
Pourquoi je n'ai pas retenu la solution Iptables/* ? Parce que cela ne règle pas le problème puisque les connexions parviennent au serveur HTTP, ce que je veux à tout prix éviter.
Pourquoi j'ai finalement retenu la solution proxy (sous réserve des tests) ? Parce qu'elle répond à mon besoin sans dévoiler d'informat ions à l'attaquant qui n'aura qu'une seule porte d'accès au système: le proxy. Reste à trouver un proxy qui tienne la charge (pound et/ou haproxy en phase de tests).
Si vous avez d'autres idées, je suis preneur évidemment :-)
Bon week-end, JB
Benjamin RIOU a écrit :
Je ne comprends pas. Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont toujours presentes !
Je vois ce que tu as ecris de la facon suivante : Le client etablit une connexion sur le port 80, puis effectue un GET q ui est renvoyé en local sur le port 8040 (ou le serveur apache est à l'ecoute). Ensuite le dialogue entre le serveur apache et le client se fait sur le port (serveur) 8040. Ainsi, impossible pour le client d'ouvir une nouvelle connexion directement sur le port 8040.
je n'ai pas compris comme toi. Le client ouvre une connexion vers le port 80. Le port 80 lui renvoie une erreur 304 : Moved Permantly (@ip : 8040). ** Point barre. Une unique connexion vers le port 80 et un timeout trè s court. Y a rien de renvoyé en local ou quoi que ce soit.
Le client ouvre une connexion une connexion vers le port 8040, et est connecté au serveur.
Le botnet ne faisant pas de requete GET /, Jean Baptiste a choisi de le localiser les mauvaises connexions de cette manière. Ce qui revient à faire un filtrage de couche 7 (conso CPU en montée en charge ?)
++ Ben
Bonsoir à tous,
La discussion continue, c'est cool :-)
Quelques précisions, adaptées à et motivées par ce cas précis.
Pourquoi je n'ai pas retenu la solution Redirect ? Parce que cela
m'oblige à potentiellement renvoyer une information à l'attaquant,
dévoilant par là même ma stratégie de défense ('tain, ça fait riche la
phrase là. J'vais la noter pour quand je ferai consultant :-) ).
Accessoirement, cela oblige à ouvrir à tout va le port xxxx sur leque l
écoute HTTPD. Donc accessible aussi au méchant.
Pourquoi je n'ai pas retenu la solution RewriteRules ? Pour diverses
raison, par exemple parce que la solution proxy est plus complète, plus
souple et permet un plus grand contrôle, parce que je ne connais que
très mal les RewriteRules, ...
Pourquoi je n'ai pas retenu la solution Iptables/* ? Parce que cela ne
règle pas le problème puisque les connexions parviennent au serveur
HTTP, ce que je veux à tout prix éviter.
Pourquoi j'ai finalement retenu la solution proxy (sous réserve des
tests) ? Parce qu'elle répond à mon besoin sans dévoiler d'informat ions
à l'attaquant qui n'aura qu'une seule porte d'accès au système: le
proxy. Reste à trouver un proxy qui tienne la charge (pound et/ou
haproxy en phase de tests).
Si vous avez d'autres idées, je suis preneur évidemment :-)
Bon week-end,
JB
Benjamin RIOU a écrit :
Je ne comprends pas.
Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui
ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont
toujours presentes !
Je vois ce que tu as ecris de la facon suivante :
Le client etablit une connexion sur le port 80, puis effectue un GET q ui
est renvoyé en local sur le port 8040 (ou le serveur apache est à
l'ecoute). Ensuite le dialogue entre le serveur apache et le client se
fait sur le port (serveur) 8040.
Ainsi, impossible pour le client d'ouvir une nouvelle connexion
directement
sur le port 8040.
je n'ai pas compris comme toi.
Le client ouvre une connexion vers le port 80.
Le port 80 lui renvoie une erreur 304 : Moved Permantly (@ip : 8040).
** Point barre. Une unique connexion vers le port 80 et un timeout trè s
court.
Y a rien de renvoyé en local ou quoi que ce soit.
Le client ouvre une connexion une connexion vers le port 8040, et est
connecté au serveur.
Le botnet ne faisant pas de requete GET /,
Jean Baptiste a choisi de le localiser les mauvaises connexions de
cette manière.
Ce qui revient à faire un filtrage de couche 7 (conso CPU en montée en
charge ?)
Bonsoir à tous, La discussion continue, c'est cool :-)
Quelques précisions, adaptées à et motivées par ce cas précis.
Pourquoi je n'ai pas retenu la solution Redirect ? Parce que cela m'oblige à potentiellement renvoyer une information à l'attaquant, dévoilant par là même ma stratégie de défense ('tain, ça fait riche la phrase là. J'vais la noter pour quand je ferai consultant :-) ). Accessoirement, cela oblige à ouvrir à tout va le port xxxx sur leque l écoute HTTPD. Donc accessible aussi au méchant.
Pourquoi je n'ai pas retenu la solution RewriteRules ? Pour diverses raison, par exemple parce que la solution proxy est plus complète, plus souple et permet un plus grand contrôle, parce que je ne connais que très mal les RewriteRules, ...
Pourquoi je n'ai pas retenu la solution Iptables/* ? Parce que cela ne règle pas le problème puisque les connexions parviennent au serveur HTTP, ce que je veux à tout prix éviter.
Pourquoi j'ai finalement retenu la solution proxy (sous réserve des tests) ? Parce qu'elle répond à mon besoin sans dévoiler d'informat ions à l'attaquant qui n'aura qu'une seule porte d'accès au système: le proxy. Reste à trouver un proxy qui tienne la charge (pound et/ou haproxy en phase de tests).
Si vous avez d'autres idées, je suis preneur évidemment :-)
Bon week-end, JB
Benjamin RIOU a écrit :
Je ne comprends pas. Qu'est ce que cela apporte en plus de travailler sur le port 8040, qui ne pourrait etre fait sur le port 80 ? Les nouvelles connexions sont toujours presentes !
Je vois ce que tu as ecris de la facon suivante : Le client etablit une connexion sur le port 80, puis effectue un GET q ui est renvoyé en local sur le port 8040 (ou le serveur apache est à l'ecoute). Ensuite le dialogue entre le serveur apache et le client se fait sur le port (serveur) 8040. Ainsi, impossible pour le client d'ouvir une nouvelle connexion directement sur le port 8040.
je n'ai pas compris comme toi. Le client ouvre une connexion vers le port 80. Le port 80 lui renvoie une erreur 304 : Moved Permantly (@ip : 8040). ** Point barre. Une unique connexion vers le port 80 et un timeout trè s court. Y a rien de renvoyé en local ou quoi que ce soit.
Le client ouvre une connexion une connexion vers le port 8040, et est connecté au serveur.
Le botnet ne faisant pas de requete GET /, Jean Baptiste a choisi de le localiser les mauvaises connexions de cette manière. Ce qui revient à faire un filtrage de couche 7 (conso CPU en montée en charge ?)
++ Ben
Sylvain Sauvage
Jean Baptiste Favre, mercredi 16 mai 2007, 23:17:50 CEST
On Wed, May 16, 2007 at 07:54:59AM +0200, Benjamin RIOU wrote:
(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 ?
Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou 8040, cela ne va pas aider. C'est un peut le meme principe que de faire ecouter son serveur SSH sur un port different de 22 : aucun interet.
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh. depuis que j'ai bougé le port, j'en vois plus (plus que des logs iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Le but c'est d'arriver a mettre en place une procedure pour apprendre a ton serveur a reconnaitre les attaquants, autrement tu ne fais que deplacer le probleme.
"Je suis d'accord, Serge" (ça me rappelle que ça fait longtemps que j'ai pas regardé les guignols).
-- 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
Franck Joncourt wrote:
On Wed, May 16, 2007 at 07:54:59AM +0200, Benjamin RIOU wrote:
(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 ?
Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
8040, cela ne va pas aider. C'est un peut le meme principe que de faire
ecouter son serveur SSH sur un port different de 22 : aucun interet.
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh.
depuis que j'ai bougé le port, j'en vois plus (plus que des logs
iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Le but c'est d'arriver a mettre en place une procedure pour apprendre a
ton serveur a reconnaitre les attaquants, autrement tu ne fais que
deplacer le probleme.
"Je suis d'accord, Serge" (ça me rappelle que ça fait longtemps que j'ai
pas regardé les guignols).
--
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 Wed, May 16, 2007 at 07:54:59AM +0200, Benjamin RIOU wrote:
(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 ?
Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou 8040, cela ne va pas aider. C'est un peut le meme principe que de faire ecouter son serveur SSH sur un port different de 22 : aucun interet.
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh. depuis que j'ai bougé le port, j'en vois plus (plus que des logs iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Le but c'est d'arriver a mettre en place une procedure pour apprendre a ton serveur a reconnaitre les attaquants, autrement tu ne fais que deplacer le probleme.
"Je suis d'accord, Serge" (ça me rappelle que ça fait longtemps que j'ai pas regardé les guignols).
-- 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 Sun, May 20, 2007 at 01:15:21PM +0200, mouss wrote:
Franck Joncourt wrote: > >Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou >8040, cela ne va pas aider. C'est un peut le meme principe que de faire >ecouter son serveur SSH sur un port different de 22 : aucun interet. >
-- 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 Sun, May 20, 2007 at 01:15:21PM +0200, mouss wrote:
Franck Joncourt wrote:
>
>Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou
>8040, cela ne va pas aider. C'est un peut le meme principe que de faire
>ecouter son serveur SSH sur un port different de 22 : aucun interet.
>
--
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 Sun, May 20, 2007 at 01:15:21PM +0200, mouss wrote:
Franck Joncourt wrote: > >Avant d'attaquer on apprend a connaitre son adversaire. Donc port 80 ou >8040, cela ne va pas aider. C'est un peut le meme principe que de faire >ecouter son serveur SSH sur un port different de 22 : aucun interet. >
-- 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
Le Sun, 20 May 2007 13:15:21 +0200 mouss a écrit:
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh. depuis que j'ai bougé le port, j'en vois plus (plus que des logs iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Ponctuellement, pour ssh, ipt_recent a réglé le problème. Un inconvénient, ça limite l'usage de scp...
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 Sun, 20 May 2007 13:15:21 +0200
mouss <mlist.only@free.fr> a écrit:
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh.
depuis que j'ai bougé le port, j'en vois plus (plus que des logs
iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Ponctuellement, pour ssh, ipt_recent a réglé le problème. Un inconvénient, ça
limite l'usage de scp...
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
si. eviter le bruit. avant, j'avais des tonnes de lignes de logs ssh. depuis que j'ai bougé le port, j'en vois plus (plus que des logs iptables). ça ne protège certes pas plus, mais c'est plus tranquille.
Ponctuellement, pour ssh, ipt_recent a réglé le problème. Un inconvénient, ça limite l'usage de scp...
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
Oui c ca. Une fois la sequence effectuee (match sur les ports et les protocoles, flags), le firewall ouvre son port SSH pour des connexions de t ypes NEW, et le referme une fois que le client a etabli la connexion.
La sequence reste cependant possible a reproduire. On peut aussi creer une sequence variable.
-- 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
Oui c ca. Une fois la sequence effectuee (match sur les ports et les
protocoles, flags), le firewall ouvre son port SSH pour des connexions de t ypes
NEW, et le referme une fois que le client a etabli la connexion.
La sequence reste cependant possible a reproduire. On peut aussi creer
une sequence variable.
--
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
Oui c ca. Une fois la sequence effectuee (match sur les ports et les protocoles, flags), le firewall ouvre son port SSH pour des connexions de t ypes NEW, et le referme une fois que le client a etabli la connexion.
La sequence reste cependant possible a reproduire. On peut aussi creer une sequence variable.
-- 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
