Re: Protection contre un DDOS tcp open

Le
Jean-Baptiste FAVRE
Salut,

En fait, déjà envisagé mais, j'aurais dû le précis=
er dans mon premier mail désolé, une dizaine de milliers d'IP (he=
ureusement pas simultanées) provenant d'une 30aine de pays différ=
ents
Un peu dur à gérer :-)

Merci quand même
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 à :
> Objet : Re: Protection contre un DDOS tcp open
>
> Salut !
>
> Que penses tu de limiter le nombre connexion par IP avec connlimit (si
> les attaques sont issues d'un sous réseau IP défini) ou bien av=
ec le
> module recent d'iptables ?
>
> ++
> Ben
>
>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Benjamin RIOU
Le #9556471
Le 15/05/07, Jean-Baptiste FAVRE
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 ? : -)

++
Ben
Stephane Bortzmeyer
Le #9556401
On Tue, May 15, 2007 at 08:13:39PM +0200,
Benjamin RIOU 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
Le #9556361
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 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
Le #9556341
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
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 #9556291
Le Tue, 15 May 2007 23:28:46 +0200
Jean Baptiste Favre
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

# hping2 -S -p 80 --rand-source <IP_de_ton_serveur>

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
Franck Joncourt
Le #9556281
--Km1U/tdNT/EmXiR1
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 15, 2007 at 11:19:16PM +0200, Stephane Bortzmeyer wrote:
On Tue, May 15, 2007 at 08:13:39PM +0200,
Benjamin RIOU 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




Au fait, Pascal, avait mis en evidence la mise en place du
patch-o-matic-ng dans un mail sur la liste.

En l'occurence cela pourrait etre bien de mettre en oeuvre les deux
correspondances (recent, connlimit), non ?

--
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--Km1U/tdNT/EmXiR1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGSjElxJBTTnXAif4RAr1EAJ938avD83QjPRXQmaTJ5n48r7FpdwCgmwvR
mfXn8Pl3VJgxt3rpj5/Wgcg =tZuV
-----END PGP SIGNATURE-----

--Km1U/tdNT/EmXiR1--


--
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 #9556271
> 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
Le #9556251
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
Franck Joncourt
Le #9556261
--5xSkJheCpeK0RUEJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 16, 2007 at 12:03:33AM +0200, François Boisson wrote:
Le Tue, 15 May 2007 23:28:46 +0200

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 re vient. 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

# hping2 -S -p 80 --rand-source <IP_de_ton_serveur>



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*.

--
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

--5xSkJheCpeK0RUEJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGSjPcxJBTTnXAif4RAlP0AKCb/RWuRt1jiG1cIEvwAR3/1Aq6TACfRmUp
zewySbnYaCyDlM9VNGo3WyM =S+AP
-----END PGP SIGNATURE-----

--5xSkJheCpeK0RUEJ--


--
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
Le #9556231
> 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
Publicité
Poster une réponse
Anonyme